Curious about the fixed number of block types paradigm versus as many as the CPU can handle

Just for completeness:

CPU = Central Processing Unit (an actual, physical microchip)
DSP = Digital Signal Processing. In Audio Hardware, dedicated CPUs that perform DSP are often just referred to as "DSP" for short.
 
I suspect it's about managing the "mapping" of parameters, etc from each potential block within a preset.

Additionally, think about the Midi and internal control complications of the "CPU limited" model.

Take Bypass controls as one example. You have 4 Delay blocks, you have a global setting that allows Bypass assignment for each. Now you add 8 Delays in one preset. How do you manage them? The global settings couldn't handle it.

There is a lot of internal "housekeeping" that needs to happen to make the system work.

Allowing an indefinite number of all blocks would make that incredibly hard, I think.
Have a unique identifier based on its position on the grid? For example, there’s a cc# for whatever block is in position 1A (top left space)
 
@Seven2Eleven, no disrespect intended, but IMO us giving Cliff recommendations about technical implementation details is pretty useless. We don't have even a basic idea of the capabilities, strengths, weaknesses, or constraints of the hardware, much less the code infrastructure Fractal has built on top of it. The existence of this industry-leading family of devices, and their constant rapid evolution, makes a pretty strong argument that they've got a decent handle on the situation.

We can wish for features, but we kind of have to leave their feasibly and priority in Cliff & Company's hands.
 
Last edited:
Have a unique identifier based on its position on the grid? For example, there’s a cc# for whatever block is in position 1A (top left space)

Hmmm, compared to the way it currently works where you assign a midi cc to bypassing a particular block? Using grid coordinates would mean in one preset a CC controls filter, but another preset it controls amp, which would probably be rather confusing.


As unix-guy says, the issue here is not the ability to add as many blocks as you want of a given type. From personal experience I can tell you it's actually quite simple to implement a system that allows you to add as many of each type of effect as you'd like, subject to limits of cpu and grid capacity.

The issue is addressing the parameters of those blocks. Offering a user interface that efficiently gives the user the ability to assign modifiers and remote control over parameters becomes more difficult for the developer to implement and the user to use when you have an open ended number of each type of block. It's not impossible, but challenging.
 
@Seven2Eleven, no disrespect intended, but IMO is giving Cliff recommendations about technical implementation details is pretty useless. We don't have even a basic idea of the capabilities, strengths, weaknesses, or constraints of the hardware, much less the code infrastructure Fractal has built on top of it. The existence of this industry-leading family of devices, and their constant rapid evolution, makes a pretty strong argument that they've got a decent handle on the situation.

We can wish for features, but we kind of have to leave their feasibly and priority in Cliff & Company's hands.
I'm just spitballing and responding to the idea that it would be impossible for the global settings couldn't handle it. I fully acknowledge I'm not a programmer though so of course I'll let the people smarter than me handle this stuff.

But I see people regularly post stuff on how about how to theoretically implement stuff. It's nice when Cliff or anyone from fractal responds to posts like that and they can explain their rationale as to why it would or wouldn't work. That's one of the best things about a forum like this where we get to hear directly from the horse's mouth
 
Hmmm, compared to the way it currently works where you assign a midi cc to bypassing a particular block? Using grid coordinates would mean in one preset a CC controls filter, but another preset it controls amp, which would probably be rather confusing.
Yeah that's definitely a downside to that approach.
 
Using grid coordinates would mean in one preset a CC controls filter, but another preset it controls amp, which would probably be rather confusing.
^My thought too^

Having the CC change from preset to preset would be a horrible implementation.
 
The fact that there isn’t and never has been a processor that allows this should speak for itself.
Is this not how Helix works? The number of instances of a certain block isn't limited by anything more than the remaining DSP. It doesn't abide by the same "you are allowed this many instances of this block" model of the Axe Fx.

This was done on a Helix Rack, so I wasn't "cheating" by using HX Native and avoiding hardware modeler limitations.

1693777660057.png
 
Here's my conspiracy theory...
I can buy a cheap Sahara version of a Jeep Wrangler. It should be able to have all the nice "luxury" stuff that the Rubicon version has.
But it doesn't. If you want the nice interior and cool amenities of the Rubicon you have to buy the Rubicon version for tens of thousands of dollars more.
COULD the FM9 be packed with a lot more "punch"? Hell yes it could.
SHOULD it? No. Then there would be no need for the more expensive "top of the line" Axe FX unit.

As a side note...it does everything I need to play guitar and kick ass. More than my biggest rack mount rigs from the 1980's could ever dream of doing.
 
Here's my conspiracy theory...
I can buy a cheap Sahara version of a Jeep Wrangler. It should be able to have all the nice "luxury" stuff that the Rubicon version has.
But it doesn't. If you want the nice interior and cool amenities of the Rubicon you have to buy the Rubicon version for tens of thousands of dollars more.
COULD the FM9 be packed with a lot more "punch"? Hell yes it could.
SHOULD it? No. Then there would be no need for the more expensive "top of the line" Axe FX unit.

As a side note...it does everything I need to play guitar and kick ass. More than my biggest rack mount rigs from the 1980's could ever dream of doing.
But that logic doesn't apply to this discussion because the Axe Fx III can't do it, either...
 
I suspect it's about managing the "mapping" of parameters, etc from each potential block within a preset.

Additionally, think about the Midi and internal control complications of the "CPU limited" model.

Take Bypass controls as one example. You have 4 Delay blocks, you have a global setting that allows Bypass assignment for each. Now you add 8 Delays in one preset. How do you manage them? The global settings couldn't handle it.

There is a lot of internal "housekeeping" that needs to happen to make the system work.

Allowing an indefinite number of all blocks would make that incredibly hard, I think.
There was a thread of the many on this topic where I decided to press this issue. The above was the argument that made the most sense to me and convinced me to drop it.

Just look through the midi implementation tables and you'll realize that it would not just be the "trivial" task of removing limits on the number of blocks. You'd also have to have a user-programmable midi mapping function among possibly other obscure side effects.

I suspect the effort to implement and support those features would not pay off.

My solution: buy an additional fractal unit or two.
 
Is this not how Helix works? The number of instances of a certain block isn't limited by anything more than the remaining DSP. It doesn't abide by the same "you are allowed this many instances of this block" model of the Axe Fx.

This was done on a Helix Rack, so I wasn't "cheating" by using HX Native and avoiding hardware modeler limitations.

View attachment 126159
The whole time I was thinking, "isn't that the way Helix works?" Lol.

Regardless, while I'd really like one more pitch block and I wouldn't actually mind a third amp block :) I'm pretty damn happy with the unit as-is.
 
Is this not how Helix works? The number of instances of a certain block isn't limited by anything more than the remaining DSP. It doesn't abide by the same "you are allowed this many instances of this block" model of the Axe Fx.
The Headrush Prime allows you to do the same thing. From the manual:

“As you add blocks, you will notice the CPU meter in the top left screen fill up. There is no limit to the number of the same type of blocks you can add; however, if this CPU meter reaches 100%, you may experience some unwanted tonal side effects (popping, clicks, etc.).”

I also checked the Quad Cortex manual and found no mentions of block limitations; CPU limit is 90% before things start going janky.

It appears that yek’s assertion is incorrect, and that possibly Fractal is the only one of the “big boys” that actually has these limitations. I have no doubt that there are good reasons behind this, but it’s not because it’s impossible to go the other route.
 
Last edited:
The Headrush Prime allows you to do the same thing. From the manual:

“As you add blocks, you will notice the CPU meter in the top left screen fill up. There is no limit to the number of the same type of blocks you can add; however, if this CPU meter reaches 100%, you may experience some unwanted tonal side effects (popping, clicks, etc.).”

I also checked the Quad Cortex manual and found no mentions of block limitations; CPU limit is 90% before things start going janky.

It appears that yek’s assertion is incorrect, and that possibly Fractal is the only one of the “big boys” that actually has these limitations. I have no doubt that there are good reasons behind this, but it’s not because it’s impossible to go the other route.
How does the Helix or QC manage external control of those blocks and their parameters?
 
Back
Top Bottom