Labels for switches from OSC_ARGS

[pwdm]

Hello Good People,

I have a MaxForLive patch that sends OSC messages to the Lemur containing the names of pads in Ableton drum pads.

I seem top be having a problem using these names to label a bank of switches.

Here is the script I am using. Also I have MultiLabel on.

Code: Select all

decl this, def_lab;

this = getobject();

def_lab = OSC_ARGS;

setattribute(this,'labels',def_lab[1]);

Any Ideas?

Thanks in advance.

[ndivuyo]

I'm not sure exactly what your data is, probably because I've never sent OSC through m4l in this method (meaning I never use "on OSC" executed scripts)

I'm assuming OSC_Args is your list of labels maybe?? One thing is you can't set the labels attribute with just one value (it will just change the first switch's label).

you need to set all the labels at once with an array, not with individual index values.

[ndivuyo]

You are using [udpsend] right? Just send an array(list) of the names over to lemur into a matching expression. Then set the labels attribute to that expression

Maybe you can send me your max patch if you are still having trouble though.

[pwdm]

Thanks ndivuyo. I can see where I was going wrong now.

Yes I am using udpsend, and I can see that I am sending each individual label, one at a time.

If you could look at my M4L patch that would be great. Not used list before in Max.

https://drive.google.com/file/d/0B-ZQJe ... sp=sharing

I think the Lemur side of things I understand now, as you said just create an expression and assign to the incoming OSC_ARGS.

Many Thanks ndivuyo

[ndivuyo]

Ok, I attached a picture at the bottom of some posibilites you can do for a max patch. I would probably use the [thresh] object, BUT once I used a thresh to catch some API stuff and turn it into a list, and for some reason I don't understand it acted very laggy and strange... So if you have trouble try the zl.group or let me know.

Also, witht he uzi object, you shouldn't need a counter there (unless there is some issue you need to use it for). You can just use the far right outlet on the uzi as an index count, and add your offset to that.

I would execute the script that renames the pads to "on expression" and then make the expression the one that has the list of pad names. Therefore whenever you change that expression, the pads are renamed.

Hope it helps.

[ndivuyo]

Also, you shouldn't need the last "/" in your OSC address.
should just be: /FxLabels

[pwdm]

Thanks ndivuyo

I had to use zl.group as I think thresh is only for ints (I might be wrong).

Took a bit of pondering but finally got it to work. Will post my results soon (bit late for me now) if anyone is interested.

Cheers

[ndivuyo]

Ok good. Yea I just looked at my patch that I compiled a list with strings from API objects. I didn't end up using thresh or zl.group because I had issues with both. I just sent the values individually, but each value I added an index integer before it. Then when the values arrived at lemur I put them into a larger array at the corresponding index, and then the larger array becomes the array that is for the labels attribute.
So if zl.group gives you trouble, maybe try a method like that? (if you need to keep the correct ordering, sometimes zl.group may get off depending on how the values arrive)

[Macciza]

There is also a visible_drum_pads property that can be read or observed.
Possibly a listener that sends when ever it changes would be easier?

[pwdm]

So if zl.group gives you trouble, maybe try a method like that?

No problems so far using zl.group. Will look into the other options at a later date. Thanks.

I did start by looking at visible_drum_pads property but I could not figure out how to use it. And there was a lack of examples/tutorials online that I could use.