(implemented) Eliminate gap when using the same amp block across different channels.

Status
Not open for further replies.
axe3 -
Two 1.0 GHz floating-point “Keystone” DSPs (TMS320C66x) (2.8 times faster than the TigerSHARC DSPs in the Axe-Fx II). The Turbo module has a 1.25 GHz processor.

fm9 -
Two dual-core SHARC+ DSPs (original: 450Mhz, Turbo: 500Mhz)

fm3 -
SC587, a 3-Core “Griffin” DSP with one ARM and two SHARC+ cores. Dedicated GUI processor. Cabinet modeling runs in a CPU accelerator

fact. hardware determines what software can do.

Is this a fact or speculation?
 
axe3 -
Two 1.0 GHz floating-point “Keystone” DSPs (TMS320C66x) (2.8 times faster than the TigerSHARC DSPs in the Axe-Fx II). The Turbo module has a 1.25 GHz processor.

fm9 -
Two dual-core SHARC+ DSPs (original: 450Mhz, Turbo: 500Mhz)

fm3 -
SC587, a 3-Core “Griffin” DSP with one ARM and two SHARC+ cores. Dedicated GUI processor. Cabinet modeling runs in a CPU accelerator

fact. hardware determines what software can do.
How does a list of components determine what these units are ultimately capable of?

The Axe FX II was less than the FM9 on paper but it does more...
 
Sure that's why actual circuits pop but this is a modeler. Also, why is it possible to switch from one amp to another with zero gap as long as they're on the same channel?
1. This modeler have virtual component that behave like the real counterpart. It not some function that shave the signal.
2. I don't get it. If you don't change channel, how do you change amp? Editing the amp block with type? And you don't hear gap and lag?
 
How does a list of components determine what these units are ultimately capable of?

The Axe FX II was less than the FM9 on paper but it does more...
i'm responding specifically to your notion that the units are "tiered" by software choices to keep them worse than the higher one.

it's the hardware that's tiered, and that hardware determines what the software can do and how many features it can have. a less-powerful processor cannot do everything a more powerful processor can do.

what they choose to put in to each one is up to the developer. but it's not just that choice determining what each unit is capable of. the hardware is the main factor.

can we have gapless switching in the future? sure. is it possible now? no.

a while ago a firmware was released for the Axe3 that had almost instant gapless amp channel switching, but there was a pop or other type of sound. people agreed that it's worse to have a pop vs a short audio gap. at this time, there is no way to get rid of the pop and audio gap, so the choice was made to have the audio gap.

do we want every feature to be perfect? sure. and fractal has clearly been improving things at a rate not seen in any other similar product. if it was possible now, we'd have it.

many people share this wish. there's really nothing to argue about. it just can't be done right now.
 
many people share this wish. there's really nothing to argue about. it just can't be done right now.

This thread has devolved a bit, but I think you might be misunderstanding the wish this thread is about. In case it wasn't clear, he's wishing for no gap only in the specific case where the amp type doesn't change when changing amp channels.
 
This thread has devolved a bit, but I think you might be misunderstanding the wish this thread is about. In case it wasn't clear, he's wishing for no gap only in the specific case where the amp type doesn't change when changing amp channels.
I am not misunderstanding. Does that affect anything?
 
It might be as simple as loading AxeIII OS and firmware onto an FM9... How different can the hardware be?

The general firmware framework is already unified, but the hardware and hardware "OS" are not the same as chris pointed out and as Cliff has said many times: the III is much faster but has additional components/complications to make it work. The other units (FM9, FM3) are simpler yet slower. IIRC the III has a whole DSP dedicated to amps and cabs.

Although most of the code base is probably directly ported, some aspects have to be tweaked / optimized for each unit.
 
1. This modeler have virtual component that behave like the real counterpart. It not some function that shave the signal.
2. I don't get it. If you don't change channel, how do you change amp? Editing the amp block with type? And you don't hear gap and lag?
Build a preset with two amps in parallel. If both amps are on the same channel you can switch between them and there’s no gap.
 
Build a preset with two amps in parallel. If both amps are on the same channel you can switch between them and there’s no gap.
A better example would be:

Use scene controllers to change the parameters of an amp block when changing scenes. Notice that there is no gap, provided the amp type is unchanged. This proves your wish is feasible. The wish then becomes: extend that scene controller concept to change all amp block parameters that differ between the channels (except the amp type) when changing the amp block channel, without requiring the user to explicitly assign scene controllers. If some advanced parameters need to be excluded to make this work, that would be fine.

Whether such a thing would be high priority is another matter, but what you're asking for is demonstrably possible.
 
Chris…..you’re back!,!! Yay!

axe3 -
Two 1.0 GHz floating-point “Keystone” DSPs (TMS320C66x) (2.8 times faster than the TigerSHARC DSPs in the Axe-Fx II). The Turbo module has a 1.25 GHz processor.

fm9 -
Two dual-core SHARC+ DSPs (original: 450Mhz, Turbo: 500Mhz)

fm3 -
SC587, a 3-Core “Griffin” DSP with one ARM and two SHARC+ cores. Dedicated GUI processor. Cabinet modeling runs in a CPU accelerator

fact. hardware determines what software can do.
 
A better example would be:

Use scene controllers to change the parameters of an amp block when changing scenes. Notice that there is no gap, provided the amp type is unchanged. This proves your wish is feasible. The wish then becomes: extend that scene controller concept to change all amp block parameters that differ between the channels (except the amp type) when changing the amp block channel, without requiring the user to explicitly assign scene controllers. If some advanced parameters need to be excluded to make this work, that would be fine.

Whether such a thing would be high priority is another matter, but what you're asking for is demonstrably possible.
I’m going to load your 8 scene preset tomorrow and figure it all out. Thanks!
My concern with scene controllers is being able to re EQ the amp but I’ll see how it all works before making a big deal about it.
 
Cool, they should do that with channels.




Now tell me why that can’t be done.
Because you can't run more than 100% of one CPU. Each amp block run on 60% in one CPU. When you load preset, amps are loaded in the proper CPU. They both run, like Unix-guy wrote. Channels run ON THE SAME CPU, but only ACTIVE CHANNEL is load. When you switch channel (by any means: manualy, with scenes...) the current istance must be discharged, cleared and the new channel loaded, than run till stationariety. Think about real one channel amp in one cab: you have to shut down, change cable, open main, open standby. In virtual amp this is FAST, but require some ms. This is my guess, could be wrong, but It is what I could understand as a programmer from Cliff & Fractal.

Scene controllers are different: the code is tweaked to NOT CAUSE NOISE/GAP/... Not ALL parameters can be controlled. Guess why...

Could Fractal lower the load on CPU? Yes. How? Simplifying and cutting code, hence less autenticity. L6 like. They can run 8 shitty sounding amp at 10% CPU. They choose the best autenticity, the higher quality algo, given the constrains of the best DSP(s) on the market. So FM3 can run 1 amp, Fm9 2.
 
Status
Not open for further replies.
Back
Top Bottom