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.
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.