Way to have more than one instance of bpatcher without renaming s/r objects
Hi,
Ive made a patch and wish to add more than one instance of the patch into another with bpatchers. I have many send and receive objects in the patch that im opening into the bpatchers.
Do i have to manually rename each send receive object so they dont conflict with the other instances of the same patch in the bpatchers.
Is there way to make each bpatcher contain itself without talking to other patches?
Hope this makes sense.
Thanks Stu.
If you use [s #0-destination] a unique number will be allocated to the #0:
hi,
Open bpatcher Inspector and check "Embed Patcher in Parent".
I think is what you looking for.
Thanks
Luis Marques
I ran into the same problem a while back and came up with a little system that is working for me. In my case I wanted to be able to communicate remotely with my bpatchers (from another application) and had to keep the send and receive names simple (no unique numbers).
Here it is.
Hope it’s useful.
MIB thanks very much, excellent patch! Did you put that together yourself, its great?
Baz I will play around with your example but it doesnt quite make sense for what I need, maybe im not getting it.
Thanks as usual. Stu.
MIB i just noticed, that locations are still numbered differently so is this not just the same as renaming each send and r in each bpatcher differently? I can see it has some benefits by having an input into each bpatcher?
MadBeat
The #0 will be allocated unique numbers (ie, sends and receives unique to each instance) if you save the patch and load it into bpatchers. From what you said that’s what I assumed you wanted.
You see it all over the Max/MSP examples (like classic_vocoder.maxpat), where it is used so multiple instances of the examples can be used simultaneously.
Baz
http://www.youtube.com/BazTutorials
you have to give each bpatcher a number argument in the inspector. that number will then be added to each instance of nTbp. So if you have three bpatchers loaded, each should have a different number argument. Let’s say you have a [r volume] in the bpatchers. By using [nTbp #1 @location volume] you will have [r volume1], [r volume2], [r volume3] if you set your arguments to be 1, 2, 3. make sense??
if you don’t number your bpatchers in the inspector [nTbp] will default to the @location argument without any number!!
it doesn’t work for [send], but [forward] works just fine…
I usually prefer to use the scripting name of a bpatcher as reference. This has the advantage that you simply duplicate a named bpatcher, and get the a clearly distinguishable name within the pattr name space (MyName[x]). Instead of a [send] you just use [pattrforward]…
I have in my collection also the [mynamber] abhaxion to get the pattr name from inside the bpatcher, in case you want to script some objects dependent on the pattr name or its number within the name…
http://dl.getdropbox.com/u/288305/St.ools%20for%205.zip
Stefan