Several patches in one
i would like to have some advices. I have a piece splitted in 3 parts,
with corresponding patches and tracks. I need to make one big patch with
the ability to switch in the same patch between the 3 parts setups.
There are too many tracks in each parts to put them all on one screen
and i know i’ll have only one. So, i have to do some scripting in order
to "update" the patch according to the parts. The problem is : i’ll need
to do this while playing (audio on) and the signal chords canno’t be
erased/redrawn while dac on without glitches, of course…
I got a first subpatch that handles midi / sensors. A second one that
handles recorded audio tracks with lots of polys inside. And different
generators (VST’s, max built-in, …). Then, the mix console.
I can keep the midi patch state, but i’ll have to load different audio
tracks in the poly~’s and change the generators while playing…
Any ideas, advices ? how do you manage this, usually ?
it’s probably not what you had in mind, but bpatchers with matrix~ and mute~ could do the trick.
scripting would be nicer though, I’d love to know how to do it with clean audio.
I did some tests a while ago to compare various solutions. More
details and the test patch used can be found here:
Please let me know if you come to different results than I did. These
things might depend on OS, Max versions, changes in the code of the
externals, optimalisations, etc, so it’s worth investigating every
2nd year or so.
> You cannot "load" a poly~ without
> click while audio is on. You need to have as many [poly~] as parts you want
> to mute. Then, you will turn [poly~] on/off with mute message.
Another thing to try is to turn all of your parts into vst plugins and
then load them dynamically using a single vst~ object. Plugins can be
loaded dynamically without clicking. I suspect that this would not be
as efficient as the multiple-poly~ solution, but I’m not sure!
Vaio is not so bad, respective values (in order) are :
-(sorry, i didn’t understand this one…)
Makes me think that, i forgot to say cpu’s raising i’ve mentionned
previously (with pcmcia in the slot, but default crappy driver) was on
my GLOBAL’s CPU (shown in the task manager), not the DSP’s cpu shown in
max ! I think it’s a really big difference.
Btw, i’m trying to make an external for windows which could show the
"real" total cpu usage in max, not only the dsp one. Not easy, but
doable. I got all the handy headers and cpp codes to include. Now i just
have to figure how to make the bridge in a max/msp external…