ComfortableInClouds

Hi - I am looking to be able to load different effects on the fly for live performances. I am going to do this by encapsulating all the effects into bpatchers, then, using [thispatcher], change what file is loaded into the bpatcher. I remember reading that you could do this a little bit ago, but can't recall what message I need to send to thispatcher to load a new patch into the bpatcher. Thanks for your help.

how-to-use-thispatcher-to-load-different-bpatchers-without-breaks-in-audio-output

try to use the message 'offset $1 $2' connected to thispatcher inside bpatcher to move around your patch.

yes, i am familiar with the offset message, but what i'd like to do is load a completely different patch. for example, i have one bpatcher called "delay.maxpat" and another bpatcher called "filter.maxpat". if delay.maxpat is loaded into the bpatcher, i'd like to be able to send the bpatcher a message so that it loads filter.maxpat.

found out how to do it in the bpatcher reference, but am still having trouble. In the reference it states:

use the replace message via scripting, give the bpathcer a scripting name then use the message script send replace to replace the loaded file.

....actually, nevermind. this only seems to work when there is nothing loaded into the bpatcher.

i guess ill just try creating/deleting the objects rather than just replacing the file in the bpatcher. though it would be so much simpelr to just be able to replace bpatcher files.

use the replace message via scripting, give the bpathcer a scripting name then use the message script send replace  to replace the loaded file.

i guess ill just try creating/deleting the objects rather than just replacing the file in the bpatcher. though it would be so much simpelr to just be able to replace bpatcher files.


I try to do that a few months ago, but no success... I ended using the offset message to thispatcher. If you came whit a good solution show us...

ComfortableInClouds wrote on Thu, 20 August 2009 12:44

[script sendbox BPATCHER_SCRIPTING_NAME replace PATCH_NAME(

I would use [poly~] instead, as it gives you the ability to do this without any audio clicks/cuts.

Of course, you don't have the Bpatcher GUI thing but you can find workarounds (like have some GUI inside [poly~].. a bit trickier but still works perfectly).

ComfortableInClouds wrote on Thu, 20 August 2009 12:44Hi - I am looking to be able to load different effects on the fly for live performances. I am going to do this by encapsulating all the effects into bpatchers, then, using [thispatcher], change what file is loaded into the bpatcher. I remember reading that you could do this a little bit ago, but can't recall what message I need to send to thispatcher to load a new patch into the bpatcher. Thanks for your help. 

[script sendbox BPATCHER_SCRIPTING_NAME replace PATCH_NAME(
 |
[thispatcher]

I would use [poly~] instead, as it gives you the ability to do this without any audio clicks/cuts.
Of course, you don't have the Bpatcher GUI thing but you can find workarounds (like have some GUI inside [poly~].. a bit trickier but still works perfectly).

yvan, thanks for the help! i see what you mean about the audio clicks/cuts....not ideal for a live situation. to avoid these i tried to put the bpatcher inside a poly~, and mute the poly~ while the bpatcher is being changed, but i still got the cuts. how might i use poly~ to avoid breaks in the audio when something new is introduced to the signal chain?

ah, yvan, perhaps you mean i should keep my different FX in different instances of poly~, then mute~ the ones that aren't being used?

What I meant was to do it like in the patcher called DynamicPoly in the [poly~] helpfile.

This (new) feature of [poly~] and the "parallel" argument are the 2 best features of max5 IMO (did I say "only"? ,)

i dont see any chance to load a new patch and close another one

without interrupting the DSP. the same is probably true for begin~ and gate~.

the only situation where you dont interrupt would be when all

parts are aready running (and you only use a gate~)

what might work is to setup your DSP in the bpatcher with a

fade in fade out automatism similar to the way you would do it in 

poly~ for a synth. it will still interrupt, but no longer click.

of course, just using poly~s inside the bpatcher (i.e. instaed of

loading new patches from disk) will aready not interrupt, too.

i dont see any chance to load a new patch and close another one
without interrupting the DSP. the same is probably true for begin~ and gate~.

the only situation where you dont interrupt would be when all
parts are aready running (and you only use a gate~)

what might work is to setup your DSP in the bpatcher with a
fade in fade out automatism similar to the way you would do it in 
poly~ for a synth. it will still interrupt, but no longer click.

of course, just using poly~s inside the bpatcher (i.e. instaed of
loading new patches from disk) will aready not interrupt, too.

Roman Thilenius wrote on Thu, 20 August 2009 23:25

Just give a try to the example in the helpfile I mentioned earlier.

[poly~] has now this great feature: just load a new patch from disk in it, no interruption of the audio process anymore ,)

Having all parts running and (un)muting them could be *very* expensive in a big patch.

Roman Thilenius wrote on Thu, 20 August 2009 23:25i dont see any chance to load a new patch and close another one
without interrupting the DSP.

Hi.
Just give a try to the example in the helpfile I mentioned earlier.
(Max5 only)
[poly~] has now this great feature: just load a new patch from disk in it, no interruption of the audio process anymore ,)
Having all parts running and (un)muting them could be *very* expensive in a big patch.

I made a dynamic effects chain patch a long time ago. Try this:

- Pre-load all of the available effects into different bpatchers.

- Use mute~ objects to mute effects that aren't being used to save on CPU overhead

- Send outputs of all effects bpatchers to a matrix~ object. Use the matrix~ object to manage routings of inputs and outputs without clicks.

If you still have a copy of Max 4.6, you can see a somewhat overcomplicated example of a dynamic effects chain in this patch (doesn't work with Max 5):

http://interchanzheblique.snottywong.com/

It uses a big js script to create all of the bpatchers, the matrix~ object, and wire them all up together. If you want to look at the patch that does it, download that patch, go to the "lib" folder, go to the "main bpatchers" folder, and open up "effects1" patch.

I made a dynamic effects chain patch a long time ago.  Try this:

- Pre-load all of the available effects into different bpatchers.
- Use mute~ objects to mute effects that aren't being used to save on CPU overhead
- Send outputs of all effects bpatchers to a matrix~ object.  Use the matrix~ object to manage routings of inputs and outputs without clicks.

It uses a big js script to create all of the bpatchers, the matrix~ object, and wire them all up together.  If you want to look at the patch that does it, download that patch, go to the "lib" folder, go to the "main bpatchers" folder, and open up "effects1" patch.

If you use the [matrix~] approach remember to use [send~] and [receive~] objects to add a vector of delay so as not to confuse the audio processing. Here's a little example where you could replace the [patcher] objects with [bpatcher]s. The other alternative is to have a [poly~] inside each [bpatcher] and use the "patchername" message to swap the contents as shown in the "DynamicPoly" subpatch in the [poly~] help file.

gusanomaxlist wrote on Fri, 21 August 2009 10:44Roman Thilenius wrote on Thu, 20 August 2009 23:25

well for poly~ i dont see the need to load new patchers, you

can just have the polys you need and choose between them.

very expensive? why that? thats why we are turning it off 

when not needed, and that is why we are using it, or do i 

it is still a good idea to implement an interpolating on/off

fucntion in the polys. no interrupt might still click ...

gusanomaxlist wrote on Fri, 21 August 2009 10:44Roman Thilenius wrote on Thu, 20 August 2009 23:25i dont see any chance to load a new patch and close another one
without interrupting the DSP.

well for poly~ i dont see the need to load new patchers, you
can just have the polys you need and choose between them.

very expensive? why that? thats why we are turning it off 
when not needed, and that is why we are using it, or do i 
miss something? 

it is still a good idea to implement an interpolating on/off
fucntion in the polys. no interrupt might still click ... 

In my live impro patch, I have some "boxes" in which I wanna be able to load any of my favourite synths (20 or so). Each of them takes between 15 and 40% of my cpu.

I'd rather have in each "box" 1 [poly~] and load any synth I want inside it than have 20 [poly~] per "box" and mute/unmute them 1 by 1 (that would mean load the patch with all the synths in it, and the patch might not even load because all synths are active before [loadbang] mutes them all (if I remember correctly, this actually happened to me, under max 4.x era).

Also, the 1 [poly~] solution makes my patches much cleaner

ps: this plus some [matrix~] tweaks don't produce any clicks, even with already huge cpu noise patch =)

In my live impro patch, I have some "boxes" in which I wanna be able to load any of my favourite synths (20 or so). Each of them takes between 15 and 40% of my cpu.
I'd rather have in each "box" 1 [poly~] and load any synth I want inside it than have 20 [poly~] per "box" and mute/unmute them 1 by 1 (that would mean load the patch with all the synths in it, and the patch might not even load because all synths are active before [loadbang] mutes them all (if I remember correctly, this actually happened to me, under max 4.x era).

Also, the 1 [poly~] solution makes my patches much cleaner 

gusano - the dynamic poly~ solution was perfect. all i've done is create poly~ patches containing the bpatchers of my effects/samplers/synths/sequencers. Then I use a umenu object with all the files names of these poly~'s and connect the middle outlet to a [patchername $1] connected to a poly~. 2 objects, 2 patchcords, 1 message, and i now have access to any of my patches spontaneously, with no clicks in the DSP. beautiful 

How To Use [thispatcher] to Load Different Bpatchers Without Breaks in Audio Output?