how to use "send" in more advanced ways
I'm looking to create multiple instances of a send and receive object to acquire their name/target based on the parent device id.
so that multiple instances of an m4l device in an ableton rack could send messages to each other, without interferring with m4l instances in another device.
I've seen some advanced usage of the send object before, but its not in the manual. I'd love to learn everything I can about that amazing nebulous thing.
Something like this ?
loadbang
i #0
prepend set
forward, receive
@110 modular im not sure what you mean there, but i do recall # being very useful with these objects. its not in the documentation.
@nat, ill take a look at the zip
its not clear though how i could dynamicly rename a send and recieve object based on the current instance on an m4l device by using something like an id
#1 is still locked to the name of the parent patcher which is typed manually by me when its created.
You can use a device id for naming and renaming send/receive objects dynamically.
You also want to check out the forward object as well as try giving receive no arguments. Both of these will allow you to change targets dynamically.
Caveat: send and receive are not super reliable in terms of timing in M4L. (I think this is still the case)
Ill definitely check it out. sorry if this is a double post, browser went weird.
thats really helpful@ I'm wondering though, if i have 256 instances of some bpatcher, how can i set them all to a unique recieve easily without having to connect up 256 patch chords to a "set" message on each of them? is there a method to do this procedurally possibly?
the other situation that arises from this approach that I need to append an id based on the current m4l instance. i believe there was some ability to use #0 or @1 or something like that but searching for these strings tends to break search engines.
i got something going. its quite large though.
basically all the instances send their ids out to be received. then the hub gets that list of ids and can send messages out to those ids. it means that the bpatchers dont have to have wires connected and you can just copy past to make as many instances as you want. it would be good if they could be aware of their position in the path to determine some kind of execution order. its random at the moment.