It would be great if the subpatch mode: 'mono with bypass' could be implemented. I hope I understand it right. Bypass means: The objects inside the subpatch are excludeded from processing, which reduces its processor load to nearly 0%.
Sub patch - bypass/processing
Im not sure what the intentions were of this, as I don't remember seeing any related code - @johannes?
Id be surprised if it was going to really allow, bypassing of processing... as I thought one of the central tenets of axoloti, was constant processing load... to ensure, switching things on/off would not potentially result in audio glitches.
... that said, I understand, the use-case for this, IF the user is well aware of the dangerous of switching in and out sub patches.
In principle, it seems trivial to implement, we need to add an bool parameter to the patch, so that it can controlled, and then it just a matter of not calling the submodule dsp() .
( there is a small question over , I think, over if the module should be re-initialised when it goes from bypass to active ... as the inputs may have jumped considerably in the meantime whilst it was offline)
I actually think it should be a subpatch property... as I see no reason it should be limited to mono patches, and arguably more useful on poly patches.... you could then have multiple synths, that could be turned on/off.
Jan
#3
It would be great for stomp-box patches. You could e.g. use one footswitch to select the active modulation subpatch and a second one to select the active distortion subpatch. The processor load would not change drastically. As an axoloti beginner, I'm trying to put everything I need for live guitar-playing in one patch, just to keep things as simple as possible. Such a bypass mode would be a great help.
Jens_Groh
#4
Hmm... doesn't processing load change when the number of active voices in polyphony changes? I would have thought so.
yes, which is exactly why you cannot change it at 'runtime', you can only change before you compile/upload to the board
makes no difference, the oscillators/filters are all constantly being updated regardless of if a note is played or not.
all that is happening is the VCA is just multiplying the resulting signal by 0, which when summed with other outputs means its not heard.
in this regard, axoloti is like a real modular, the objects are always running, wether you can hear it or not is a different matter 
you may think this is 'inefficient', but the point is, its constant - no peaks, no troughs ... so its a consistent performance.
(of course, if you look at the code at a low level then you will see of course load does vary slightly, but not to a point where it would jeopardise the audio buffer being updated in time... if an object did do this, it would be considered a 'bad object' )
johannes
#9
My fear is greatly varying dsp workloads, causing unanticipated buffer underruns.
Re-initializing states 'd make it even worse - for example clearing a delay line. But not re-initializing is also likely to result in clicks - for example a filter.
I think it is hard to make the resulting constraints obvious to the user.
Unless all cpu cycles are accounted, then it can be ensured that disabling a certain dsp chain creates enough room for another.
Jan
#10
I would have tried to quickly fade out input and output of the active subpatch, then switch the subpatch and finally fade in again.
thetechnobear
#11
Ive moved this to a separate topic, as I think its an interesting discussion point.
my fears are pretty much identical to johannes.
(I'll point out, perhaps an obvious thing... its unacceptable that an audio glitch can occur, i.e. we can't do this, and just say, well it happens on some patches and not others, it must work 100%)
there appear to be a few options when you reactivate.
a) re-initialise
everything in the patch starts in a known state (good) but it may vary from the state it needs to be.
more worryingly, if its the 'normal' init(), then these are not optimised for frequent call. so someone may initialise a large table, or load something from an sdcard ... with could cause a buffer underrun
b) just activate it.
almost certainly will cause clicks, as inlet values will have changed (causing potential discontinuity), and internal tables etc will suddenly be getting new data... these possibly could be coded around by a patch developer, but hard to explain to everyone whats needed
c) fade in.
yeah, I thought of this... actually in a slightly different way.
I was thinking, of letting the subpatch run for a while ( a few processing cycles), to allow for the data within the patch to 'catchup' , then outlets could be activated.
I consider rather than fade in, as sub patches may not be audio, they could be doing something completely different e.g. midi output/calculations
the issue with my warm up approach, is you can place objects within a subpatch that directly cause outputs (i.e not everything goes via the outlets e.g. audio/out midi/out objects)
also the length of time for a patch to 'warm up' is unknown, a simple voice for a synth, could be immediate, but something with a big delay, could be 15 seconds...
also there are a few other issues..
reverbs/delay - most would expect these to 'ring out' when bypass is applied.
(this means in implementation, the dsp() has to be called BUT just not to accept new inputs from inlets or things like midi/in)
midi (and perhaps others) - just turning on bypass is not quite enough... there is a certain amount of 'state' with midi, e.g. which notes are active and allocated to voices. this would need to be cleared when activating bypass, to avoid oddities when re-activating
midi out (related to above) - if you bypass a subpatch which sends midi out, e.g. note data, then if it has an active note, then when you activate bypass you will need to send a midi note off to avoid a note off.
I think these kind of things highlight the kind of corner-cases that will turn up (over and above the inconsistent cpu load) ... cases that users will report as bugs if we supply a bypass feature, and are difficult to explain to users what they need to do.
it would be useful, if others can think of 'corner cases', if we can build a complete list, this will help us determine the solution has to cover... and might even lead to a possible idea for implementation.
also Id point out, if we provided this, this is not some 'advance' feature a few would use (so we could explain constraints etc). this is very likely to be something almost everyone (beginner to advanced) would start using, as they would see it as an alternative to switching patches. so I think this means it has to be bulletproof and easily understood, and almost invisible to users.
all that said, I do think its a really useful feature, and in some cases (e.g. switching synth voices) unlikey to cause many issues.
anyway, I suspect, it needs a bit more thought, and perhaps needs to be something thats thought of as a "key new feature' rather than an easy addition.