Simon Blakely

I am building a M4L device using javascript, and I am having issues understanding how to manage multiple instances of the same object when using callback functions.

So the M4L device is added to a group track, and maintains some state information for the child tracks (in this case, only one track can be in an 

 state at a time), and also reports the state for the child tracks (i.e which track is currently unmuted). This works for a single instance of the M4L device - child tracks can be muted/unmuted, additional child tracks added/removed, and the correct state information is maintained and reported correctly.

The problem occurs if I want to have more than one device in the project. Each device instance sets the "tracks" callback function in the Live Object Model, but they overwrite each other (

). Because of this, the last instantiated device gets the "tracks" callback function when the tracks change. Even though the callback function correctly handles the multiple instances, I need to find a way to ensure that the status change notifications end up going to the correct M4L device.

I guess what I need to do in each device instance is create a global inlet with a unique name based on the track ID, so that I can send a message from whatever instance gets the "tracks" callback to the instance that needs to handle that particular change.

So the M4L device is added to a group track, and maintains some state information for the child tracks (in this case, only one track can be in an unmuted state at a time), and also reports the state for the child tracks (i.e which track is currently unmuted). This works for a single instance of the M4L device - child tracks can be muted/unmuted, additional child tracks added/removed, and the correct state information is maintained and reported correctly.

The problem occurs if I want to have more than one device in the project. Each device instance sets the "tracks" callback function in the Live Object Model, but they overwrite each other (there can be only one). Because of this, the last instantiated device  gets the "tracks" callback function when the tracks change. Even though the callback function correctly handles the multiple instances, I need to find a way to ensure that the status change notifications end up going to the correct M4L device.

I am building a M4L device using javascript, and I am having issues understanding how to manage multiple instances of the same object when u

multiple-max4live-instances

I would also be very interested how to solve this. 

When I use twice the same device in one ableton project, the send and receive objects interact between the devices, which destroys the function of all the devices, cause they get double information on each receive object.

I would also be very interested how to solve this. 
When I use twice the same device in one ableton project, the send and receive objects interact between the devices, which destroys the function of all the devices, cause they get double information on each receive object. 

i dont fully understand the question because i dont use live, but you can solve these things best when you look at it from the major design level. for example check out if you eventually can solve it by leaving certain things to a special "master" version of your plug-in/device only. (if it is a different plug-in, there are no longer other instances of it.)

qnd as for send/receives, you need a unique identifier : it's #0 in Max, in Live it is --- . When you instantiate a device, all --- in your device will become a random value, the same for all the --- in the device, and it's unique so no other device instance in your session will have the same value for --- .

Yeah - so the (eventually) obvious solution is to add a couple of pairs of send/receive objects into the max4live instances - one pair with symbol 

 for messages that target back into the specific M4L instance, and one pair for 

 that reflects messages across all the M4L instances.

I think I have now got an approach that should work - some more refactoring is required before I can be confident.

Yeah - so the (eventually) obvious solution is to add a couple of pairs of send/receive objects into the max4live instances - one pair with symbol ---<name> for messages that target back into the specific M4L instance, and one pair for <global_name> that reflects messages across all the M4L instances.

I think I have now got an approach that should work - some more refactoring is required before I can be confident.  

I'm having the same probelm; whenever I load two instances of the same device on two different channels in Live, they affect each other.

So, if I write "---" before each one of my send and receive messages that won't happen anymore?

I just want to ask before I start this rather gigantic work!

I'm having the same probelm; whenever I load two instances of the same device on two different channels in Live, they affect each other.
So, if I write "---" before each one of my send and receive messages that won't happen anymore?
I just want to ask before I start this rather gigantic work!


Use "s ---whatever" and "r ---whatever" throughout to keep all send/receive pairs from communicating with other patches in your Live set. The "---" portion will auto-instantiate with a unique ID for each instance you open within Live.

..but don't take our word for, do a small test with an otherwise empty patch and see for yourself. ;)

It's extremely unlikely that you don't already know this, but for the benefit of anyone newer to Max who may be reading this in the future: using Command+F to search your patch for all the current send and receive objects will likely come in handy during big object re-naming efforts like this.

Use "s ---whatever" and "r ---whatever" throughout to keep all send/receive pairs from communicating with other patches in your Live set. The "---" portion will auto-instantiate with a unique ID for each instance you open within Live. 

It's extremely unlikely that you don't already know this, but for the benefit of anyone newer to Max who may be reading this in the future: using Command+F to search your patch for all the current send and receive objects will likely come in handy during big object re-naming efforts like this. 

The "name space" in Max is global - when you have objects that have names associated with them such as 

 , you can share data between Max for Live devices. In these cases, the Max name space is shared, but the "signal processing space" is independent - each Max for Live device processes its audio or data separately.

If you want a named object to be unique to a device, use three dashes (

When your patch is initialized, it will replace the three dashes with a unique-to-Live number (e.g. s 024filtercutoff);

The "name space" in Max is global - when you have objects that have names associated with them such as coll, send, receive, table, or buffer~ , you can share data between Max for Live devices. In these cases, the Max name space is shared, but the "signal processing space" is independent - each Max for Live device processes its audio or data separately.

If you want a named object to be unique to a device, use three dashes (---) to start the name of your buffer~ or send/receive destination (e.g. s ---filtercutoff).

Multiple Max4Live instances