Wish 8 channels

+1

In the case that 8 channels are an inconvenient for memory if every channel have a different amp and a different cab (8 amps and 8cabs per preset), it could be a good solution to put a limitation of 4 selections of different amps, cabs, reverbs, etc per preset, but allow the possibility to use that 4 selections with variations in the 8 channels.

6 channels would be also a good improvement if 8 is too much!
 
it could be a good solution to put a limitation of 4 selections of different amps, cabs, reverbs, etc per preset, but allow the possibility to use that 4 selections with variations in the 8 channels.
Can you elaborate? What is a selection? a variation?

Cliff implemented scenes after wishes to have "pedalboard-like" multiple fx activation (I asked it before Ultra...). Later Cliff added x/y state for any block. People asked to implement amp channel in amp block, and 4 channel was born (bonus it was for every block!).
If memory is an issue, the simpler an logical evolution is to drop channel and allow the 8 scenes parameters to be stored within each scene. Channel is also a way to select differet effects on the fly so, to maintain these feature, 8 channels is the way to go. IMO!
 
Can you elaborate? What is a selection? a variation?

Cliff implemented scenes after wishes to have "pedalboard-like" multiple fx activation (I asked it before Ultra...). Later Cliff added x/y state for any block. People asked to implement amp channel in amp block, and 4 channel was born (bonus it was for every block!).
If memory is an issue, the simpler an logical evolution is to drop channel and allow the 8 scenes parameters to be stored within each scene. Channel is also a way to select differet effects on the fly so, to maintain these feature, 8 channels is the way to go. IMO!
Of course 8 channels is the best option. I only say that if FM3 cannot support a preset that have 8 different amps, 8 different cabs, 8 different reverbs, etc, a limitation of maximum 4 different amps, 4 different cabs, etc can be a solution.

In other words, the best is 8 channels without limitation. If it is not possible, I would be happy with 8 channels with a limitation of maximum 4 different amps, 4 different cabs, etc
 
In other words, the best is 8 channels without limitation. If it is not possible, I would be happy with 8 channels with a limitation of maximum 4 different amps, 4 different cabs, etc
Except few blocks, there are already 4 channels.
 
I still don't get what's your alternative wish.
I wish 8 channel per preset. So we could have each scene his own channel (effect tuned for the preset) or use only some channel (down to only one) per preset.

I suspect you wish 8 channel per scene (64 channel per preset) or 4 (32 channel per preset)...
 
The point of the request is to have 8 different channels to be used across 8 scenes.

It may be an overall issue if 8 channels for every block uses up too much storage/memory. But if it can support 8 channels, then it has 8 channels of data whether or not a preset is "restricted" to only using 4 of them. A channel will use storage whether it has the same parameters as another channel or not.
 
The point of the request is to have 8 different channels to be used across 8 scenes.
Yes, that would be great!!
It's what I want!!

I still don't get what's your alternative wish.
I wish 8 channel per preset. So we could have each scene his own channel (effect tuned for the preset) or use only some channel (down to only one) per preset.

I suspect you wish 8 channel per scene (64 channel per preset) or 4 (32 channel per preset)...
8 channels per scene or 4 channels per scene is not my idea.

I will do my best to tell again my point of view:

Nowadays there are 4 channels availables in almost all blocks types. There are 3 blocks (Megatap Delay, Ring Modulator, and Resonator) restricted to only 2 channels. I suppose that this restriction to 2 channels is a specific software solution to a specific software problem. I assume that having 4 channels availables in these 3 blocks would cause a problem.

So, when I read the wish of Smilzo of having 8 channels per block, I say "+1". I also want 8 channels.

But maybe is not possible to have 8 channels per block, as we can not have 4 channels in the Megatap Delay.

So, what I say is: In the case that having 8 channels per block is impossible, I propose a limitation as a solution to make it possible.

I will try to tell this limitation with an example in 2 different scenarios.
Let's use the amp block as example. The scenarios are scenario 1 with no limitation and scenario 2 with limitations.

Scenario 1 with NO limitation
AMP BLOCK CHANNEL A: FAS MODERN
AMP BLOCK CHANNEL B: Capt Hook 1A
AMP BLOCK CHANNEL C: Angle Severe 1
AMP BLOCK CHANNEL D: Deluxe Tweed
AMP BLOCK CHANNEL E: USA IIC++
AMP BLOCK CHANNEL F: USA Lead
AMP BLOCK CHANNEL G: Hot Kitty
AMP BLOCK CHANNEL H: CA3+ Clean

Scenario 2 restricted to 4 differnt amp models
AMP BLOCK CHANNEL A: FAS MODERN
AMP BLOCK CHANNEL B: Capt Hook 1A
AMP BLOCK CHANNEL C: Angle Severe 1
AMP BLOCK CHANNEL D: Deluxe Tweed
AMP BLOCK CHANNEL E: FAS MODERN with less bass than ChA
AMP BLOCK CHANNEL F: FAS MODERN with more treble than ChA
AMP BLOCK CHANNEL G: Capt Hook 1A with less input drive than ChB
AMP BLOCK CHANNEL H: Capt Hook 1A with more presence than ChB

The changes in channels E, F, G, H of scenario 2 can be done with controllers also, but this option would give more flexibility to the system.

I vote for the scenario 1.
But in the case scenario 1 is not possible, I vote for the scenario 2.

Because I prefer scenario 2 than the current scenario we have now, with only 4 channels.
 
Last edited:
So a "variation" is: channel, parameter, value.
Yes, clever solution limited to one parameter, it could be a problem to implement.
The drawback is the one parameter variation. Often I do multiple changes (more gain, less bass, less master, more level).

The idea could be more useful if a variation store many parameters. If we have only one channel with 3 variations, the memory used to store the setting would be lower than now! Maybe a paradigm shift, for an upcoming product... :)
 
So a "variation" is: channel, parameter, value.
Yes, clever solution limited to one parameter, it could be a problem to implement.
The drawback is the one parameter variation. Often I do multiple changes (more gain, less bass, less master, more level).

The idea could be more useful if a variation store many parameters. If we have only one channel with 3 variations, the memory used to store the setting would be lower than now! Maybe a paradigm shift, for an upcoming product... :)
The solution is not limited to one parameter.

In the previous example of the Amp Block, the unique limitation would be the quantity of amp models.

I repeat the example of 2 scenarios with more details:

Scenario 1 with NO limitation
AMP BLOCK CHANNEL A: FAS MODERN
AMP BLOCK CHANNEL B: Capt Hook 1A
AMP BLOCK CHANNEL C: Angle Severe 1
AMP BLOCK CHANNEL D: Deluxe Tweed
AMP BLOCK CHANNEL E: USA IIC++
AMP BLOCK CHANNEL F: USA Lead
AMP BLOCK CHANNEL G: Hot Kitty
AMP BLOCK CHANNEL H: CA3+ Clean

Scenario 2 restricted to 4 different amp models
AMP BLOCK CHANNEL A: FAS MODERN
AMP BLOCK CHANNEL B: Capt Hook 1A
AMP BLOCK CHANNEL C: Angle Severe 1
AMP BLOCK CHANNEL D: Deluxe Tweed
AMP BLOCK CHANNEL E: FAS MODERN with less bass, more treble, more presence, less input drive than ChA
AMP BLOCK CHANNEL F: FAS MODERN with all knobs to minimum value
AMP BLOCK CHANNEL G: FAS MODERN with all knobs to maximum value
AMP BLOCK CHANNEL H: FAS MODERN with all knobs to half value

In the scenario 1 there are 8 different amp models.

In the scenario 2 there are 4 different amp models, because it's the maximum qty allowed (nowadays is the maximum). FAS MODERN is the amp assigned in channels A, E, F, G and H. Every channel stores all parameters of the FAS MODERN at a different values.
 
Let's suppose we have variation with one parameter. The channel is loaded, variation parameter is read, the value change in the channel, then run.
Let's suppose we have "n" parameter. Channel load, repeat read variation and change for "n" times, then run.
Let's suppose we have all parameter available, the process is channel load then read every variation, then run. CPU processing is the worst, it is better to have a fresh channel, to reduce gap between channel/patch/preset switching (more than double memory: the worst).

So variation, for me, is useful if only few parameter can change (the best compromise cpu-store-user wise).
 
Let's suppose we have variation with one parameter. The channel is loaded, variation parameter is read, the value change in the channel, then run.
Let's suppose we have "n" parameter. Channel load, repeat read variation and change for "n" times, then run.
Let's suppose we have all parameter available, the process is channel load then read every variation, then run. CPU processing is the worst, it is better to have a fresh channel, to reduce gap between channel/patch/preset switching (more than double memory: the worst).

So variation, for me, is useful if only few parameter can change (the best compromise cpu-store-user wise).

There are 2 options
option a - Loading a new channel with a new amp with all parameters to read
option b - Loading a new channel with an amp already loaded in other channel with all parameters to read

The option b doesn't need to load a new amp so it should save cpu processing, because is one big task less.

Now with 4 channels we can make several variations with controllers in the 8 scenes. That's the main reason for thinking that variations can be an alternative for having 8 channels.

I think CPU control of FM3 can alert when too much parameters are changed, so I think it can be managed.
 
Would it help if we could select which blocks had channels - freeing up those "channel slots" for other blocks from memory - Wah for instance - I for one don't use multiple Wah channels in a preset - same with In/Outs and Cabs for that matter - surely that channel count could be used elsewhere?
 
Would it help if we could select which blocks had channels - freeing up those "channel slots" for other blocks from memory - Wah for instance - I for one don't use multiple Wah channels in a preset - same with In/Outs and Cabs for that matter - surely that channel count could be used elsewhere?
Fully agree, very good idea!!!!!!
 
Would it help if we could select which blocks had channels - freeing up those "channel slots" for other blocks from memory - Wah for instance - I for one don't use multiple Wah channels in a preset - same with In/Outs and Cabs for that matter - surely that channel count could be used elsewhere?
Let's merge the idea.
8 channels, each channel have a flag: used/unused. An unused channel has not stored parameters, it's no useable in the patch/scene. A ghost!
 
Would it help if we could select which blocks had channels - freeing up those "channel slots" for other blocks from memory - Wah for instance - I for one don't use multiple Wah channels in a preset - same with In/Outs and Cabs for that matter - surely that channel count could be used elsewhere?

Let's merge the idea.
8 channels, each channel have a flag: used/unused. An unused channel has not stored parameters, it's no useable in the patch/scene. A ghost!
I'd say the chances of this happening are between zero and none ;)

Aside from being very complicated to "manage", I don't think that will fit the paradigm Fractal uses to store the presets.

Maybe I'm wrong...
 
I'd say the chances of this happening are between zero and none ;)

Aside from being very complicated to "manage", I don't think that will fit the paradigm Fractal uses to store the presets.

Maybe I'm wrong...
I think you're right!
So I raise: the default is ABCD used EFGH unused, the authentic page show only used channels, like vintage firmware (pre 21.0). Advance page allow to change the flag status of all the channel except A (always used)! Cliff will have an epiphany with only one channel active. The radiation from channel will interact with the atmosphere, and the amp will "breath and chug" more. ;)
 
Back
Top Bottom