Wish Send/return blocks to get to next line

cje

cje

Inspired
As someone who uses a kitchen/sink preset, I’m always on the edge of 80% CPU usage. I’d like to not take the (small) CPU hit just so I can have more effect blocks on the grid. Why can’t we just connect the last effect on line 3 to the first on line 4, for example?
 
IMHO it should work like a word processor and automatically wrap to the next row without the need to add send/return blocks to the grid.

It would be nice if the wrapping happened automatically. It's a pain to have a full row and need to add one more block, especially when making room for the send/return breaks connections.

Here's a thread about that:
https://forum.fractalaudio.com/threads/block-insertion-improvement.160661/

It's the same thing with the mixer block. Why is there a mixer block? There should be an automatic mixer wherever there's a signal path junction, without the need to put a block in the grid. And that automatic mixer should only have controls for the paths that join, instead of having controls for all rows, most of which don't make any sense because they don't have a signal path to the mixer.

P.S. Apologies, this sounds grumpier than I intended it to. But these are annoyances I run across every day.
 
Last edited:
Actually, I use the send/return blocks - is feedback send/return different? I was under the impression that the send/return blocks and a CPU charge associated with them. When I get home, I’ll try to find that reference.
 
if the end of row 1 connected to row 2 automatically it would probably increase CPU usage the same amount.
 
Feedback send/Feedback return are sometimes referred to in the UI as send/return. They are the same thing. And they are not to be confused with the send/return labeled on the back of an FM3 :).
 
There's a small amount of cpu usage associated with using send/return, and a small amount of latency. If the send/return was done automatically instead of you explicitly inserting blocks into the grid, that wouldn't change. There's no free lunch.

The advantage of automatic send/return would be more efficient preset editing, not a savings on cpu usage.
 
Actually, latency was the other thing I worry about, because I definitely feel it in some instances. In fact, that's the more frustrating aspect of those blocks. If the chain were one long line of effects (or the equivalent of that in the grid without the send/return blocks) I feel like we could cut down on latency. It all adds up.
 
Also, there WOULD be a savings on CPU usage, correc?t You state there's a small amount of latency, just to pass from one line to the other. My wish is for a better way to string everything together without the CPU and latency costs of the send/return blocks.
 
Well, yes, that's yet another shortcoming of the AxeFX grid architecture. It artificially restricts how much you can put in a single row. The row length should be limited by your cpu capacity, not the UI presentation. I'm pretty sure we'll see the grid go away in in the next gen, to be replaced with a chain that expands in length to meet your needs, subject to available cpu, and allows you to freely insert blocks where you want them in the signal chain.
 
cje said:
Actually, latency was the other thing I worry about, because I definitely feel it in some instances. In fact, that's the more frustrating aspect of those blocks. If the chain were one long line of effects (or the equivalent of that in the grid without the send/return blocks) I feel like we could cut down on latency. It all adds up.
Click to expand...

The send and return blocks do not add any additional latency. You can run them in parallel to a row of shunts and there is no phase cancelation between the two. Don't confuse CPU load with latency. The two are not the same.
 
mr_fender said:
The send and return blocks do not add any additional latency. You can run them in parallel to a row of shunts and there is no phase cancelation between the two. Don't confuse CPU load with latency. The two are not the same.
Click to expand...

Send/return add 16 samples of latency, except for the rare/redundant case where the return block is to the right of the send block.
 
Ah, in my test I had them in the same row. Sure enough moving the return block to another row added the 16 samples. I stand corrected.

That said, 16 samples = 0.00033 seconds. That's the equivalent of moving about 4 inches further from your speakers. I seriously doubt anyone can feel that.
 
You must log in or register to reply here.
Back
Top Bottom