#0, unique identifiers for abstractions within abstractions
Hello all.
I am creating a rather large synth patch with quite a few abstractions, bpatchers and poly~s. There are also quite a few send/receive objects, as well as colls. I would like to be able to run various iterations of this synth patch at once without the send/receive pairs or referenced colls communicating with those of the other iterations of the same patch.
I understand #0 can be used as a unique identifier for each instance of an abstraction and its subpatchers. However, unfortunately this identifier does not work with an abstraction and its abstractions. In such a case, the abstractions within the abstractions are given different four-digit identifiers, and therefore cannot communicate.
I suppose it could be said I would like to create a unique name space for each iteration of the synth, although I haven't had any luck with --- either.
I have pasted a patch to illustrate the problem - The #0 technique fails to communicate with the bpatcher inside the bpatcher, while the --- technique fails to create a unique name space, and communicates with the bpatcher inside the other bpatcher.
Any help would be very much appreciated.
Thank you,
Daniel
Instead of #0, use #1 with unique names in the top-level instances (like HugeSynth01, HugeSynth02, etc.) and transmit the names as #1 in all sub-patches. So you could create a unique send like [s HugeSynth01_filter2_Q] ("filter2" could be an instanciation of a #2 if you have more filter instances).
What I have done, and is similar to what pdelges describes, is use #0 in the top level abstractions, then #1 in the lower level abstractions. #0_HugeSynth —> 1234_HugeSynth_filter2_Q. I include a screenshot to illustrate.
To add to that point: use #0 as an argument for the abstraction, then in the abstraction use #1 or [patcherargs] to get reference to the parent's unique identifier. If the abstraction contains an abstraction, it would then use #1 as an argument to access the top level #0, and so on.
Oh hi @terenceformer! Yes, thanks for clarifying. It's in the pic but I did not describe it fully.
Oops, I meant to add to PDELGES point, looks like SLO was faster than me ;)
Thank you everybody for your assistance.
This has helped me very much :)