Max msp need to update only one slider on lemur multislider

Hi,
In my max patch I need a way to change the value of only one slider in a multislider at a time, is there a way over OSC to specify the index of the fader then a value?
thanks

Subject: Re: Max msp need to update only one slider on lemur multisli

Have a look at this example. you should be able to adapt this to a MultiSlider. The example outputs only what you press instead of the whole array:
http://liine.net/en/community/user-library/view/87/

Best regards,
Nick

Subject: Re: Max msp need to update only one slider on lemur multisli

thanks for the reply nick. actually what i'm trying to do is change only one slider at a time from max, so not going out of the lemur but coming into the lemur. Ideally what would be nice would be to send an OSC message like this to the lemur /Multislider/x[2] 0.75 to update only slider 2 (or three is you count from zero) instead of sending the entire list from max (/Multislider/x 0. 0. 0.75 0.). Is there a way to do this that i've missed?

Subject: Re: Max msp need to update only one slider on lemur multisli

You could create a little "On OSC" triggered script in your Lemur template which takes an OSC message and assigns the value of a specific slider in a MultiSlider object. For example:

set_slider(OSC_ARGS)

decl slider = OSC_ARGS[0];
decl value = OSC_ARGS[1];
MultiSlider.x[slider] = value;

Then from MaxMSP or any other software you can send:
/set_slide <no_of_slider> <value>

Hope this helps, let me know.

Best regards,
Nick

setfader_on_OSC_example.jzml.zip

Subject: Re: Max msp need to update only one slider on lemur multisli

Need to try it out be I think it's exactly what i was looking for! thanks

Subject: Re: Max msp need to update only one slider on lemur multisli

The need to do scripting for this to work is, I think, precisely why it's still a viable feature request - monome-style single-value updating via plain osc.

for what it's worth, what I do is maintain a multislider in Max, and then update *that*, and have that fill out the entire multislider. Super easy, but maintaining the values in two locations is kind of a hack, I guess.

Subject: Re: Max msp need to update only one slider on lemur multisli

wetterberg wrote:The need to do scripting for this to work is, I think, precisely why it's still a viable feature request - monome-style single-value updating via plain osc.

for what it's worth, what I do is maintain a multislider in Max, and then update *that*, and have that fill out the entire multislider. Super easy, but maintaining the values in two locations is kind of a hack, I guess.

Hi Andreas,

I disagree. The point of the scripting system (and Lemur as a whole!), is to provide a flexible framework so that an infinite variety of use cases can be accomodated, including monome style messages. With the two examples I've given above, you can easily create a JZLIB consisting of a single object (Pads or MultiSlider for example). Within each object, you would have two scripts: one to send monome-style messages, one to receive. You can then re-use this object whenever you want to use monome-style messages and you don't need to hold the data in MaxMSP on the computer.

Adding features which simply reproduce what can already be accomplished requires a very compelling reason. It ranks very low on the development priority list as it doesn't really add anything. It can happen sometimes, for example we're thinking about adding some functions on top of midi_clocks to make external syncing more intuitive. I don't believe this case is one of them because the scripts to provide the functionality you request already exist in clear and re-usable examples.

We truly do appreciate the input though, thank you very much for the feedback and suggestions.

Best regards,
Nick

Subject: Re: Max msp need to update only one slider on lemur multisli

Hey thanks it works great.
to get to the debate, I couldn't have used the multislider way in max msp since I'm doing some stuff with poly~ and each slider of the multi slider controls an instance of poly. This scripting is really why I love the Lemur!!!! So great!

to get back to your script

decl slider = OSC_ARGS[0];
decl value = OSC_ARGS[1];
MultiSlider.x[slider] = value;

I'm a little bit lazy and I don't want to have to change the name of the multislider for each one I was wondering if I can replace Multislider.[slider] with something like ThisObject.[slider] , that I way I can quickly copy the script into each object without bothering to rename each one.

I think being lazy in programming is a good thing ^^

Subject: Re: Max msp need to update only one slider on lemur multisli

nick_liine wrote:

wetterberg wrote:The need to do scripting for this to work is, I think, precisely why it's still a viable feature request - monome-style single-value updating via plain osc.
for what it's worth, what I do is maintain a multislider in Max, and then update *that*, and have that fill out the entire multislider. Super easy, but maintaining the values in two locations is kind of a hack, I guess.

Hi Andreas,
I disagree. The point of the scripting system (and Lemur as a whole!), is to provide a flexible framework so that an infinite variety of use cases can be accomodated, including monome style messages. With the two examples I've given above, you can easily create a JZLIB consisting of a single object (Pads or MultiSlider for example). Within each object, you would have two scripts: one to send monome-style messages, one to receive. You can then re-use this object whenever you want to use monome-style messages and you don't need to hold the data in MaxMSP on the computer.

While I do appreciate the scripting system, the highlighted text here is what I've heard before, but also in part what confuses me.

The Lemur system has always occupied this sort of "neither/nor" space - if it was to be the ultimate in flexibility it would provide a "dumb terminal mode", that separated the GUI output from the user input. This isn't there.
I latch onto the monome approach, not because it's a favourite of mine, far from it, I think there's a lot of things "wrong" with that approach, but I *Can* see the democratic aspect of making things easier in this way, so that even the original mlr patch (which is a hideous mess!) actually worked.

While I would think that adding (yes, I think it *adds) more or less in-the-box monome ease of use while minimizing scripting, I also recognize that I - and others like me - can work our way around this.

Were I to choose I would much rather focus on the Z-value wishes. And with that I'll leave you wonderful people to it
Andreas (who is now disgustingly decked out with Lemurs).

Subject: Re: Max msp need to update only one slider on lemur multisli

Hi
I would much rather the Lemur stick with implementing the full/canonical OSC protocol then to bother with variations like monome addressing . . .
TimeTags, TypeTags, Bundles, Querys, Wildcards, Blobs etc should be implemented where ever possible . . . Any comments, Niick?

I would much rather see an OOP-style implementation exposing '@' attributes natively then the multi-parameter approach used by monome

Cheers
MM

Subject: Re: Max msp need to update only one slider on lemur multisli

Just a bump to get back to the original thread and the script that niick found as a solution, is there a way in scripting to get the name of the object the script is located in?(without looking of course, to make the script universal for all objects you copy it in without having to change things in the script each time)

Subject: Re: Max msp need to update only one slider on lemur multisli

Hi everybody,

I created an example which can send and receive single units instead of the whole array. The scripts are name-neutral: you can rename and copy the objects as you wish. Hope this helps, let me know.

http://liine.net/en/community/user-library/view/152/

FYI, the trick here is the getexpression() and setexpression() functions. Check out the set(OSC_ARGS) script.

Nick

Subject: Re: Max msp need to update only one slider on lemur multisli

Hooray, thanks nicks, that's great support!

Subject: Re: Max msp need to update only one slider on lemur multisli

lucasparis wrote:Hooray, thanks nicks, that's great support!

Hey Lucasparis,

Very glad to help. If you have time to leave us a positive review and star rating on the iTunes App Store that would be greatly appreciated. Feedback on the iTunes App Store is a huge help to us.

Best,
Nick

Subject: Re: Max msp need to update only one slider on lemur multisli

nick_liine wrote:

wetterberg wrote:The need to do scripting for this to work is, I think, precisely why it's still a viable feature request - monome-style single-value updating via plain osc.

for what it's worth, what I do is maintain a multislider in Max, and then update *that*, and have that fill out the entire multislider. Super easy, but maintaining the values in two locations is kind of a hack, I guess.

Hi Andreas,

I disagree. The point of the scripting system (and Lemur as a whole!), is to provide a flexible framework so that an infinite variety of use cases can be accomodated, including monome style messages. With the two examples I've given above, you can easily create a JZLIB consisting of a single object (Pads or MultiSlider for example). Within each object, you would have two scripts: one to send monome-style messages, one to receive. You can then re-use this object whenever you want to use monome-style messages and you don't need to hold the data in MaxMSP on the computer.

Adding features which simply reproduce what can already be accomplished requires a very compelling reason. It ranks very low on the development priority list as it doesn't really add anything. It can happen sometimes, for example we're thinking about adding some functions on top of midi_clocks to make external syncing more intuitive. I don't believe this case is one of them because the scripts to provide the functionality you request already exist in clear and re-usable examples.

We truly do appreciate the input though, thank you very much for the feedback and suggestions.

Best regards,
Nick

I completely agree with you on the redundancy of adding features for functionality that can be accomplished in scripts. However, it might be wise in that case to create a richer "factory library" that is installed with the editor by default, and addresses some of these feature requests. That's the way things are done in Reaktor, where there are very low level and fine grained construction tools like the Core DSP level, but a large directory tree bursting with usable examples ships with the product. Perhaps this will come with time in the case of the Lemur too.

And speaking of which - thanks for the scripting example you posted here - I certainly learned some tricks from it!

Subject: Re: Max msp need to update only one slider on lemur multisli

Hello again,
The script is working great for what I wanted to do! But, there is one problem.

It seems that when I set a single slider from max using the method you gave me (script "on OSC"...etc), the lemur also sends the values back to max.
I tested some things out and when you update the lemur via the normal OSC feedback it doesn't resend it's values via OSC... but when using the "on OSC" script it does!
Would you have a workaround for this?

Also a kind of related thing I've been trying to do:

decl obj.x =getobject();
decl value = OSC_ARGS[0];
decl slider = OSC_ARGS[1];
obj.x[slider] = (value-1);

wanted to use this to make the script universal but I can't get it to work!
Thanks in advance niick, I left a review on the french itunes for the lemur!

Subject: Re: Max msp need to update only one slider on lemur multisli

nick_liine wrote:Hi everybody,

I created an example which can send and receive single units instead of the whole array. The scripts are name-neutral: you can rename and copy the objects as you wish. Hope this helps, let me know.

http://liine.net/en/community/user-library/view/152/

FYI, the trick here is the getexpression() and setexpression() functions. Check out the set(OSC_ARGS) script.

Nick

This is fantastically useful and I'm kicking myself for only discovering it almost a year later. However as lucasparis points out retransmission is a problem when the multislider uses "on OSC" to update its sliders. This is THE paradigm example where a Z value for the multislider would be useful, as it could be used to gate output - that is, only transmit when the object is being touched on the iPad.