Wish Gapless sound: "Smart" Channel Switch (if same type) and Preset Switch (if same layout)

BobXX

BobXX

Inspired
Always thinking about tricks to eliminate/reduce sound gap when switching sounds... :)

CHANNELs SWITCH:

NOTE: there are a good number of blocks that don't cause any sound gap when switching their channels.​
For people interested, I've listed them here:​

For the other blocks, I assume (not sure!) that the gap is caused by loading & activation time of the chosen type of block,
longer for AMPs due to the their really huge complexity.

The wish/idea for AF3/FM9/FM3 is to do not load block type switching channel if it's the same type of the one already active:
just use the current one and apply the new settings.

E.g. if I have to switch from RHYTHM to LEAD, and I want to avoid the gap, I could use the same AMP type in two channels,
changing Gain, a little the Input EQ, maybe the out EQ etc...., like the real AMP world (with more controls).

This will also avoid to use all the 4 scene controllers for that purpose, since in the whole preset they are probably kept for other purposes (e.g. general volume, reverb, delay).


PRESETs SWITCH:

It's a similar concept of the previous one.

For AF3/FM9/FM3, switching a preset, not load the new one if it is the same layout of the one already in use,
Just apply the new settings, maybe with some restrictions if there are technical issues.

It's somehow similar to "Ignore Reduntant PC" MIDI function, but applying ON/OFF changes and possibly some parameters' changes.

This will also virtually unleash the limitation of 8 scenes per preset (I would like they will be more than 8).

With the power of AF3 we could build a single big preset for e.g. 30 sounds, with better control/elimination of the gap.

On the development point of view, to understand rapidly if a preset is equal or not to the previous,​
we could make a checksum of all blocks and their links or positions, saved in memory along all presets' data.​
Whenever a switch preset command arrives, the system will first compare old/new checksum to decide in a while to load the new preset or just keep the current one.​

I will appreciate if some people better knowing than me the development history and internal architecture of AF3/FM9/FM3 could comment all this, hope they won't crush my assumptions... :sweatsmile:
 
Last edited:
The amp (and the drive, and many other block) require some time to load and run. The virtual capacitors needs time to charge. The signal need time to stabilize. The systems needs time to solve the solutions. I remember discussing with Cliff himself for axefx II: doable if all the value are the same, but he doubt people change scene and preset to maintain the exact settings... (try changing the parameters when playing, some parameters do horrible noise....).
The only way for gapless is to load another instance of the block, let it stabilize, then fade the old/new instances. It will double CPU & memory.
 
Smilzo said:
The amp (and the drive, and many other block) require some time to load and run. The virtual capacitors needs time to charge. The signal need time to stabilize. The systems needs time to solve the solutions. I remember discussing with Cliff himself for axefx II: doable if all the value are the same, but he doubt people change scene and preset to maintain the exact settings... (try changing the parameters when playing, some parameters do horrible noise....).
The only way for gapless is to load another instance of the block, let it stabilize, then fade the old/new instances. It will double CPU & memory.
Click to expand...

Thank you for your information, I imagined something like that. There's a lot complexity under the cover.

But I'm still asking myself why switching to an identical type of block, maybe with just few parameters adjusted,
cannot be much faster or act like scene controllers already do.
 
Last edited:
unix-guy said:
You are assuming it can know the type of the other channel without loading it... I'm not sure that's the case.
Click to expand...
The firmware know the actual state, and the recalled (yet unload) state. The problem is to load in any cpu load conditions...!
A simple solution is to halve the instances in any block, and reserve the saved istances for gapless... but people will complain not having 2 amps... do it global option? The people complain some preset do lot load... or wasted cpu power... or who knows what... :)
 
Smilzo said:
The firmware know the actual state, and the recalled (yet unload) state. The problem is to load in any cpu load conditions...!
Click to expand...

My suggestion is to not load a block channel / preset that is already active, to save (I suppose) al lot of time.
Is something like the "Ignore Redundant PC" for MIDI PC mapping.

Smilzo said:
A simple solution is to halve the instances in any block, and reserve the saved istances for gapless... but people will complain not having 2 amps... do it global option? The people complain some preset do lot load... or wasted cpu power... or who knows what... :)
Click to expand...

I agree people will complain that available resources will be halven !
But, If I correctly understood, this is something we can better already manage manually when required, switching two blocks put in parallel instead of switching the channels of one.
 
Last edited:
BobXX said:
My suggestion is to not load a block channel / preset that is already active, to save (I suppose) al lot of time.
Is something like the "Ignore Redundant PC" for MIDI PC mapping.
Click to expand...
Now I got what you say. No, that not work.

The main gap time is not for "loading from memory", but "loading the modeling" (have a proper signal output).

In DSP the data and istruction are (almost) in the same fast memory. "Load" values from non volatile memory for scenes/patch require very low time (a 1/1000000 of a second maybe...?).
1) signal fade out (some ms).
2) values are loades, and model is "loaded" (signal start from initial to a stationary point, meanwhile it will contain noise, burst, burps, chirps and many more bad artefacts): it require many ms, hence a gap time is needed (should be "worst case") to avoid unwanted random noise bursting out during scene switches (many ms, up to 30 or more...).
3) signal fade in (some ms).
 
Smilzo said:
Now I got what you say. No, that not work.

The main gap time is not for "loading from memory", but "loading the modeling" (have a proper signal output).

In DSP the data and istruction are (almost) in the same fast memory. "Load" values from non volatile memory for scenes/patch require very low time (a 1/1000000 of a second maybe...?).
1) signal fade out (some ms).
2) values are loades, and model is "loaded" (signal start from initial to a stationary point, meanwhile it will contain noise, burst, burps, chirps and many more bad artefacts): it require many ms, hence a gap time is needed (should be "worst case") to avoid unwanted random noise bursting out during scene switches (many ms, up to 30 or more...).
3) signal fade in (some ms).
Click to expand...
I've measured those fade-ins and fade-outs 😊, have fun in seen them in my series of 6 posts here: https://forum.fractalaudio.com/thre...r-effective-for-all-blocks-tip-tricks.197091/

I also understand from you now that my "concept 1" isn't feasible since loading from memory isn't affecting the overall switching time. Right ?
 
You must log in or register to reply here.
Back
Top Bottom