I am working on a Max For Live patch with a Lemur template. If I have multiple instances of the M4L patch running in Ableton, the Osc messages from Lemur hit all instances of the device at once. Has anyone run into this problem? Or come up with a solution?
Using Midi instead of Osc is somewhat of a solution, but it does not have the same bi-directional capabilities. Or at least it appears that way.
OSC on multiple instances
Re: OSC on multiple instances
There are a couple of ways:
Make all the controls use the parent container OSC assignment. Add an "OSC channel" select to the M4L patch that selects the UDP port. Edit the container mapping in each template instance.
If you want to have a single template to send to multiple "channels" then a more complex arrangement is needed. The most flexible but most work is to script the OSC messages with oscout(). That will likely be a lot of rework for an existing template.
A slightly more convoluted solution might be to have an OSC loop back. Add an output select to the template. Have all messages send out on OSC8 that is pointing at the loop back address (or the fixed ip of the lemur) which is listening on 7. Then have a script that fires on OSC and re outputs the message with a modified path or on a specific OSC output depending on the value of the output select. I haven't tried this with OSC but I did it with midi on the legacy lemur a while back, the principal is essentially the same.
I haven't found a way to change the osc mapping of a container in a script yet. That would be the Most elegant way. There may be a clue in the coms protocol spec and the lemur loader patch as that has the ability to find a lemur on the network and set the target OSC port for output 0 - see how mu auto configures for an example.
Make all the controls use the parent container OSC assignment. Add an "OSC channel" select to the M4L patch that selects the UDP port. Edit the container mapping in each template instance.
If you want to have a single template to send to multiple "channels" then a more complex arrangement is needed. The most flexible but most work is to script the OSC messages with oscout(). That will likely be a lot of rework for an existing template.
A slightly more convoluted solution might be to have an OSC loop back. Add an output select to the template. Have all messages send out on OSC8 that is pointing at the loop back address (or the fixed ip of the lemur) which is listening on 7. Then have a script that fires on OSC and re outputs the message with a modified path or on a specific OSC output depending on the value of the output select. I haven't tried this with OSC but I did it with midi on the legacy lemur a while back, the principal is essentially the same.
I haven't found a way to change the osc mapping of a container in a script yet. That would be the Most elegant way. There may be a clue in the coms protocol spec and the lemur loader patch as that has the ability to find a lemur on the network and set the target OSC port for output 0 - see how mu auto configures for an example.
Re: OSC on multiple instances
Thanks. Interesting solutions. A little over my head since I'm new to lemur, but I think I get the general concepts.
My goal is to control multiple instances of a single m4l device on separate ableton tracks, all through a single lemur template. I was thinking there would need to be some sort of variable sent from the specific M4L device once it's selected to lemur. And based on this variable, lemur would send different osc messages to that device. But the device would also need to dynamically alter the osc messages it recieves as well.
It's too bad osc data can't be funneled to tracks with record enabled in Ableton similar to how Midi data works. That would fix everything.
My goal is to control multiple instances of a single m4l device on separate ableton tracks, all through a single lemur template. I was thinking there would need to be some sort of variable sent from the specific M4L device once it's selected to lemur. And based on this variable, lemur would send different osc messages to that device. But the device would also need to dynamically alter the osc messages it recieves as well.
It's too bad osc data can't be funneled to tracks with record enabled in Ableton similar to how Midi data works. That would fix everything.
Re: OSC on multiple instances
OSC can be funneled exactly like MIDI, except more flexibly.
Think of the OSC outs on Lemur as being exactly the same as a MIDI channel except instead of being numbered 1 -16 they are set to a port number (default is 8000).
if you set up Lemur to use all the outputs on different numbered ports, then tell you M4L device to listen to a port using the port message to udpreceive then it will only get messages from that port.
How you get your Lemur template to switch ports as you want is the trickier bit.
Think of the OSC outs on Lemur as being exactly the same as a MIDI channel except instead of being numbered 1 -16 they are set to a port number (default is 8000).
if you set up Lemur to use all the outputs on different numbered ports, then tell you M4L device to listen to a port using the port message to udpreceive then it will only get messages from that port.
How you get your Lemur template to switch ports as you want is the trickier bit.
Re: OSC on multiple instances
Ok. I thought port number was a system level thing, but it sounds like it's more flexible than that.
So on the m4l side of things, have the udp port change dynamically per m4l device based the ableton track number it resides on. Live API could be used for that. So for example, receive port 1000 on track 1, 2000 on track 2, etc. then whenever that track is selected in Live, send a variable of the current track number out to Lemur. And then have lemur somehow change the port number it's sending OSC to, to match the current track in Live. But the hard part is getting a single lemur template to dynamically switch udp ports based on an incoming variable.
Am I understanding this concept correctly? That on the m4l side of things, it's relatively straightforward.
So on the m4l side of things, have the udp port change dynamically per m4l device based the ableton track number it resides on. Live API could be used for that. So for example, receive port 1000 on track 1, 2000 on track 2, etc. then whenever that track is selected in Live, send a variable of the current track number out to Lemur. And then have lemur somehow change the port number it's sending OSC to, to match the current track in Live. But the hard part is getting a single lemur template to dynamically switch udp ports based on an incoming variable.
Am I understanding this concept correctly? That on the m4l side of things, it's relatively straightforward.
Re: OSC on multiple instances
Yeah that sounds like a good approach.Rtech wrote: So on the m4l side of things, have the udp port change dynamically per m4l device based the ableton track number it resides on. Live API could be used for that. So for example, receive port 1000 on track 1, 2000 on track 2, etc. then whenever that track is selected in Live, send a variable of the current track number out to Lemur. And then have lemur somehow change the port number it's sending OSC to, to match the current track in Live. But the hard part is getting a single lemur template to dynamically switch udp ports based on an incoming variable.
Am I understanding this concept correctly? That on the m4l side of things, it's relatively straightforward.
I am not sure if there is a way to make lemur use dynamically assigned targets without making all the objects do there coms via a script rather than the standard mapping. The dynamic send target is fine (in my head at least) but what about responding to changes in the Live device? will the communication be two way and will Lemur always follow the selected device in Live?
Re: OSC on multiple instances
Hi
I realise the values you picked are probably just examples plucked out of thin air but be aware that there are certain rules regarding what ports can be used . . .
Many are basically 'registered/standard' port numbers used for particular services or protocols and using them could cause problems . . .
Many others are also just freely available for use but commonly used or shared by various things, apps or hardware etc
A net search should enlighten you a bit more about the topic and a port scan of your computer can reveal what is in use on your system
Lemur is hardwired to receive standard OSC comms on 8000 but it also use 8001,8002 & 8003 . ..
You only have 8 possible output ports available to setup from within Lemur . . .
The important difference between MIDI and OSC is that OSC use an address schema so you can send stuff to particular addresses
That is probably how I would approach what ever you are wanting to do - via an address schema.
All your channel one stuff starts with /1/Fader, channel 2 /2/Fader etc etc
So you could use one port but address things differently to access the different streams . . .
Cheers
MM
I realise the values you picked are probably just examples plucked out of thin air but be aware that there are certain rules regarding what ports can be used . . .
Many are basically 'registered/standard' port numbers used for particular services or protocols and using them could cause problems . . .
Many others are also just freely available for use but commonly used or shared by various things, apps or hardware etc
A net search should enlighten you a bit more about the topic and a port scan of your computer can reveal what is in use on your system
Lemur is hardwired to receive standard OSC comms on 8000 but it also use 8001,8002 & 8003 . ..
You only have 8 possible output ports available to setup from within Lemur . . .
The important difference between MIDI and OSC is that OSC use an address schema so you can send stuff to particular addresses
That is probably how I would approach what ever you are wanting to do - via an address schema.
All your channel one stuff starts with /1/Fader, channel 2 /2/Fader etc etc
So you could use one port but address things differently to access the different streams . . .
Cheers
MM
iMac 2.8G i7 12G 10.6.8/10.7.2, Legacy Dexter/Lemur, Liine Lemur/iPad2, KMI SoftStep, 12Step & QuNeo , B-Controls, Mackie C4 etc
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
Re: OSC on multiple instances
Yeah - the network ports are more properly used to address different target applications or hardware devices than to multiplex the comms at the single (target) application level.
In MIDI terms . . . think of the eight OSC ports (targets) available FROM Lemur as equivalent to eight sepatate hardware MIDI (DIN) ports (pairs / triplets of In / Out /Thru).
If they WERE hardware MIDI (DIN) ports you'd have only the standard sixteen channels available PER PORT - whereas with OSC you have an arbitrary number of "channels" to play with since as Macciza pointed out, it's an "address-based" schema.
In MIDI terms . . . think of the eight OSC ports (targets) available FROM Lemur as equivalent to eight sepatate hardware MIDI (DIN) ports (pairs / triplets of In / Out /Thru).
If they WERE hardware MIDI (DIN) ports you'd have only the standard sixteen channels available PER PORT - whereas with OSC you have an arbitrary number of "channels" to play with since as Macciza pointed out, it's an "address-based" schema.
Re: OSC on multiple instances
Is there a way to have a single lemur template dynamically change osc message output addresses based on an incoming osc variable?
It sounds like this would be a better approach if possible rather than changing the port number on the fly inside lemur, if that's even possible.
It sounds like this would be a better approach if possible rather than changing the port number on the fly inside lemur, if that's even possible.
Re: OSC on multiple instances
Do you mean the /path/to/some/device address?
Yes that can be scripted, as ever more than one way to do it.
I have been doing some template work to make Lemur companions to the Push controller and have been going through the various abstractions and whatnot for Mu.
Have a look at the Mu Framework examples. There are likely to be some things in there that will be a big help to you.
In particular the Mu.LemurHost.amxd to manage the communications and the Mu.device-container.maxpat have probably just the thing you want.
The latter allows you to set a M4L device to talk only to a specific container in your template. This would give you the option to have multiple instances of your UI in containers that stack on top of one another. You then just bring the one you want to manipulate to the top of the stack when you want to send and using the device container abstraction the message would only go back to the linked instance of the M4L device.
Yes that can be scripted, as ever more than one way to do it.
I have been doing some template work to make Lemur companions to the Push controller and have been going through the various abstractions and whatnot for Mu.
Have a look at the Mu Framework examples. There are likely to be some things in there that will be a big help to you.
In particular the Mu.LemurHost.amxd to manage the communications and the Mu.device-container.maxpat have probably just the thing you want.
The latter allows you to set a M4L device to talk only to a specific container in your template. This would give you the option to have multiple instances of your UI in containers that stack on top of one another. You then just bring the one you want to manipulate to the top of the stack when you want to send and using the device container abstraction the message would only go back to the linked instance of the M4L device.