multiple instances of a bpatcher / different object names
hi there,
i have a patch with multiple instances of the same bpatcher.
i'm trying to give a [live.dial] in each of these bpatchers a unique name (such as "dial 1" for a dial in the first instance, "dial 2" for a dial in the second ...).
i'm trying to do this in order to have distinguishable objects in live's undo history.
is it possible? patcher arguments don't seem to work.
did you try sending your dial a message [varname #1] where #1 is an argument of your bpatcher?
thanks florent – i'll give it a try. only two question:
1) isn't "varname" the scripting-name? i guess i somehow need the "long name" or "short name" attribute.
2) would i do either or via loadbang?
yes you're right varname is the scripting name
not sure how you could do that with long and short names though
wow!! you are incredible – thanks so much!
do you have any experience as for how this works in a m4l device?
are parameter settings still stored and recalled correctly?
old post i know, but maybe someone can still help. This es perfect and exactly what i was trying to do except, that "#1" only seems to work if its at the beginning of an objects scripting name. so chance to get it working in a scripting name like "/Channels/#1/WaveOnOff/x" any ideas or to i have to use [sprintf varname /Channels/%d/WaveOnOff/x] which would make the whole thing quite a bit more messy seeing as it would need to be done fore every UI-object in the bpatcher, which is quite a few (30+). thanks in advance!
If you want to route those messages, then you could use CNMAT's OSC-Route instead of Max' standard route object. It does accept arguments like [OSC-Route slash Channels slash #1 slash WaveOnOff slash x] to allow the use of #placeholders. It is explained somewhere in a sub patch in the help file.
Now, maybe /Channels is useless in your system, or you could define #1 as "/Channels/1"…
Or you could use combine instead of sprint
…
Hey pdelges, thanks for the quick reply, yeah i know about the osc-route object.
the thing is, using multiple ipad interfaces (lemur) that should stay synced, all the messages that come in to my max patch automatically get sent out again, and also when changing a UI object in max it should update the lemurs. So taking the OSC message apart to get to the UI object is a bit of a pain because it then has to be reconstructed to be passed out again.
the advantage of having the UI objects have the same name as the OSC address is, that i can just send all incoming OSC to an autopattr that automatically resends the correct value to the udpsend with a get"address" message, parallel to that the patterstorage device with @outputmode 6 sends all in max UI changes out to udpsend aswell. like this it actually takes just about 10 objects taking care of all the OSC send/receive. Also i can add any UI object in both max and lemur give them the same name and don't have to do any rerouting/parsing of OSC-messages.
the fallback i have is just changing the OSC messages coming from the lemurs to a custom message without the /Channels so that the #1 i need is at the beginning of the message so it can be used in the scripting name. was just wondering if i was missing some functionality of maybe having to put the #1 in [] , {} or "" but none of that seems to work.
Any chance of a feature request to making scriptingnames more flexible to patcherargs? i mean it already works just slightly restricted, don't know how much hassle something like that would be to change...
thanks again for the inputs though. always good to hear other ideas!
take care
Hello @LORENZO.PAGLIEI thanks for the zip - I tried to pass the sprintf object to a thispatcher from inside a patch which is called in a bpatcher but it didnt work. Is it only M4L objects you can do that with?
what do you mean "pass to a thispatcher"?
I don't think you can send "varname" to a thispatcher