Way to have more than one instance of bpatcher without renaming s/r objects
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.
If you use [s #0-destination] a unique number will be allocated to the #0:
----------begin_max5_patcher---------- 212.3ocoP1jCBBCDEdc6onYbKZnHnQ244vPLErp0.sDnDQIb2k1B5FCQia5O euY575qEifDUCuBHaI6IHTKFgrHC.MbGA4rlzLVksLPxuoRtBdNIMuQawkjY 9yKXRc0njrNWHy3Zaa9ugpZ8HkNPOo56S7faYAKFKtfoSuHjmOTxS0NORoa5 kIzHey1pHyZP+YR7POhiV6zaw4AiNwMQ88Bt6Q.3U4lIKY4VAXWofkAFgNL1 r38eYR0zYB8iYh+umIKcwPXnMSVOUlPgu5iShwc3mztb7oH -----------end_max5_patcher-----------
Open bpatcher Inspector and check "Embed Patcher in Parent".
I think is what you looking for.
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?
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.
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…
----------begin_max5_patcher---------- 448.3ocwU0rTCBCD9L7TjIds1Ig.Tpmz2Au4zwIEh13.ILPpsZm9tKYoToZK Ess5kjIaV186mEXkqCdpdonDitA8.xwYkqiCDxFvYyYGbFeYbJuDRCGqyxDJ CdP8cFwRCDOga3HiFMUfJaceN2DOSpd9wBQrotO9ACICPTehcKBVoQCInIad DYBTP8zWtl0TlmzJihmIfatqPxSatQMOSpREF.czVoWJeGRmZ6v1b0yMMISr AW65ZWFzS1CspCtEEAzIjZ27BZV2G2nMkoFRl2xE00.i2l9Nja+rngxM9hs7 3eAyThEUn5a1ZQUqrNZWjlxpczHXKXDvZxAXMgcXdOnM2OEK26.Vt24SXxKD 4BUhcXO43ZiGYLLs62s132iYhKgtPOe5h59o4nqnnaS0wbiTqPupSmWA2iO+ D5AaArtEofymHQ9mDomzEK3E8YtgENLbDIhMp5EKZ25RH9BNgz9ikP6woR0W +yAvCa7cUjR87h3FOZym9PeRhDQoQpfYk14X4SqrlISRDp1lVlLIWKUlMfX7 ngAVAiU+2E+smPS1qw0avZG35AbY+L3dxnh0KT4+GiJ+Kg0tCppNr18CKp1+ 8A -----------end_max5_patcher-----------
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…