MIDI Kinetics Forum

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

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

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?

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) 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

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

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.

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

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 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 ^^

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).

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