buffer in bpatcher doesnt rem
hi there! i built a simple sampler, and want to use it across my project with different instances of a bpatcher. i called the buffer #0-XY, so that it will create a new unqie name everytime i duplicate the bpatcher, and i am able to load differnet samples in each instance. It all works fine but when i save the patch and re-open it, all buffers will have that same sample loaded which i used in the patch which is the parent patch of that bpatcher. Any ideas how to solve this?
This is how the parent sampler patch looks like:
the argument to object ("#0_myname") loads before the loadbang so the buffer name is overwritten.
furthermore, since #0 does not resolve in a top level patcher, the #0 is only part of the name.
makes sense! ok i tried tbb loading that sample first and giving that buffer a name afterwards. didnt really work out =D any hints roman in which direction i shell go with this are deeply apreciated :)
how does your bpatcher patch look like and where is it placed (relative to the buffer in the mother patch?)
one cas easily mke errors with load order with bpatchers and in the past there were also some strange bugs with bpatcher init (cant remember if with in- or outgoing messages, but something did not work)
Hi roman! this is what my latetst attempt looked like, didnt work, same proble as above. I know you mentioned that #0 is not optimal but i ddint find another way working this out, as info~ will not accept to be named dynamically with a name$1 message. help =D
so this is the bpatcher? it looked like this is the mother patch.
still not really sure what you are trying to archive, why you want to use #0 names when you also load files anyway, and what does not work. but maybe that is not too important for now.
while you are right about the general problem when one of the required objects would not allow to be set from outside, for info~ that should not be the case; it supports the "set" message analogous to buffer~.
setting names from outside has advantages and disadvantages. but if the current situation confuses you or it objectively "does not work", it is time to try another attempt. :)
i often do things like that from "outside". and playing the #0_ game using an abstraction patch means that it will now also "work" in top level patchers.
however you now must take care about the load order when you want to initialise other things in addition to the buffer name, because the command triggered from the subpatch will always execute first.
to not lose overview about the sub-to-top load order i would place additional init jobs left from the init jobs coming from subpatchers, then the patch remains readable.
