send and receive objects across multiple devices in live using --- ids
ive got two devices in live where i want to send messages from one to the other, trouble is they dont generate the same unique id in the s and r objects using ---. is there a way round this?
live.remote instead?
cheers
ned
:)
hey Ned.
tbh, I would generate my own id instead of using "---" - Is there a specific reason to use the built in unique ID system? Seems like what you're looking for isn't actually a unique id, but I've been way off-base before.
Im gonna try that then report back.
Sweet. If I recall correctly you will have some plugin latency going across like that, but it shouldn't be that bad.
the only reason i ask is when i need multiple instances of the same two devices (two talking to each other, the other two talking to each other etc)
what I'm using is ---hello too ---hello, but when i drop them one after the other i get 001hello and 002hello.
---hello should always evaluate to the same ID in the same device... are you getting 001hello and 002hello in the same device??
as wetterberg says, if you're looking for cross device comms, you don't want the ---
but then if i drop multiple instances of the same two devices then they will all talk to each other?
yes, if you don't use --- then it will be global (i.e. across all devices) unless you do something else to limit the scope.... what are you trying to achieve?
Correct, you'll have to think of a way to make the pairs unique. Using [s ---name] creates unique IDs within THAT patch only. Ive done something like this before, but its a little messy. In order to talk across patches you have to use the standard send and receive pairs, so you;ll have to assign unique ids to the messages, then route them accordingly at the destination.
here is an example.
lets say i have one m4l device at the start of lives chain sending messages to a device at the end of the chain. this works fine if i don't use ---, but when i duplicate that chain to another track, its global, but i need these devices to work independently, device 1 controlling device 2 on track 1 will control device 2 on track 2 and visa versa. this is why I'm thinking live.remote would be better, but if i can avoid the api i will because i suck at it.
ok, in that instance you want to create your own unique name for the send/receive pair on the track - for example, when initialising the device, you can use the 'this_device' path to determine what track you are on and then use this to form a name unique to the track which can then be used to communicate only on that track. Instead of using [send] though, you will need to use [forward] which you can change the target by sending it a 'send' command. Your receive object can be connected to it by sending it a 'set' command with the same name - follow?
im gonna try that and report back.
k, bed time for me now - i can knock up example in the morning if you don't get it sorted... good luck!
Yeah Lee's idea is solid. I've never used forward before. You learn something new everyday around here.
@lee id certainly take a look at that. cheers.
confused. how can i create a name and send that name across to another device to name the object receiving it when that object is not named in the first place?
:)
gimme 10 mins...
thanks for that. now am i going to run into problems using multiple pairs in both devices? e.g., filter cutoff dial in one device to filter in the other, and same for other controls, res etc?
they key is in the sprintf statement - that's what gives you your uniqueness - in the patch you modified, they are both the same. if your looking to send individual control values across then you have 2 choices:
1) create a new send/receive pair for each, e.g. [sprinff my_send_receive_name_%d_cutoff] and [sprintf my_send_receive_name_%d_res]
2) send the name of each parameter through e.g. [cutoff 0.5], [res 0.75] and then do a route on the receiving side to send it to the appropriate dial
2 would be more preferable...
@Wetterberg : there's no latency involved by the standard send and receive objects, only with their MSP versions.
@Stephane : here are some quotes from the documentation.
"Communication between devices using send and receive is supported, but there may be some latency involved when sending data between devices."
"The use of the send~ and receive~ objects to pass audio between Max for Live devices is not supported."
I've got a small/large issue regarding loading the two devices using lees method. I can't post the patch right now so I'll just explain.
I have packed some filter controls with default values and load bangs into the forward object to send down stream to the filter in the other object. When both devices load the messages don't get picked up downstream until I turn all the controls, despite loading to there initial values. How can I forward all the messages on loading so that they are received immediately?
Thanks
Ned
I guess that initialization of Live parameters via send/receive is basically not reliable since receiver devices may be loaded after senders.
Why not roll your own addressing system. Send data as a list, prepending it with the desired recipient. Then in each receiver device have a dynamic route (I think you can use a set message to a route). Manage that set message with a textbox and pattr.
Hey,
This thread saved me some head scratching when I had similar inter-track conflicts.
Big help, thank you so much!
midierror
i want to give each of you a piece of some kind of ornate cake.
this was very helpful.