Troubleshoot, share solutions, and explore Lemur programming with a community tailored to your need.
https://community.midikinetics.com/
Hey Lucasparis,lucasparis wrote:Hooray, thanks nicks, that's great support!
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.nick_liine wrote:Hi Andreas,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.
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
Code: Select all
decl obj.x =getobject();
decl value = OSC_ARGS[0];
decl slider = OSC_ARGS[1];
obj.x[slider] = (value-1);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.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