live.slider, can I change range/enum on the fly?
Is it possible to remotely change range/enum's values for the live.slider object?
i.e. by pressing a toggle button.
Thanks!
You can do it with the regular slider, but I don't think you can do it with the live.slider.
Thanks, you are right!
In case you depend on live.slider i.e for automatation or MIDI control you can normalize the slider ie beteeen 0 and 1 and scale the output.
Jan,
I totally agree.
But when you have i.e. an 8 steps parameter, you won't have value quantisation for the envelopes, would you?
you'r right, you would lose quantization in the envelope. Are the amount of steps always the same, just the values different? in this case you could just route the live.slider output to different colls. If you need different amount of steps as well the only workaround I can think of is to use multiple live.sliders - for every case one and dynamically show/hide the active one in the UI.
The Live application requires that things like parameter ranges need to be set at instantiation and not messed with afterward. For that reason, NO live.* UI object lets you change slider or dial ranges - you'll need to use standard Max UI objects for that. There may be some interesting attempts out there to circumvent this, so perhaps others may wish to contribute their interesting and idiosyncratic approaches to the problem that differ from going with vanilla Max objects. :-)
Hi Gregory, you are right. Gravetti's point was that he was looking for the flexibilty of the vanilla objects in combination with the abilitiy of midi mapping in live. Hence the hacks. Sure this is not how live parameters are conceived, but hey isn't max also about finding solutions ;)
Hey,
I'm actually having a wonderful time setting the range with the "_parameter_range" attribute. The slider range dynamically adjusts and the UI graphically updates and scales exactly as it should.
In general I guess it's a stupid thing to want to do, with automation disasters waiting to happen, but its possible...
I agree, I've experienced these automation disasters. But I see this as a tremendously powerful patch building resource, to cut down on setting up controls for certain attributes(esp. jit.gl).
The automation crash could be avoided if the changing attr was only availble when when building the patch.
It would be fantastic to select the attribute and automatically be given ui objects, named and with the correct range. I've been able to modify the getattr help file to do all but set the correct range. Would someone mind checking it out and seeing if they have any ideas on how to accomplish that?
these threads don't seem so encouraging, but i have no doubt that anything is possible!
https://cycling74.com/forums/getattr-for-live-objects
https://cycling74.com/forums/get-minmax-value-for-live-parameter
Ive put a sketch on the top left of the patch on how i think it could be done, and if i figure it out i will post!
thanks :)
Neal
ps be sure to check out patch in locked/pres mode to see the show/hide scripting of UI elements
Neal, I just stumbled on this thread looking for something related, and realized one of the threads you linked was something I posted. :)
Turns out, I've since found a couple workarounds for my use cases. I'm setting enum ranges for live.dials in bpatcher abstractions at patch instantiation, and using another UI object to display and change their values. And in other cases, I'm simply using the offset message to scroll the bpatcher view to show a different live.dial, rather than changing the range of a live.dial.
I'd imagine that, if you wanted the user to be able to change a range/enum or min/max value for a live.dial or slider at runtime, you'd be better off using Max objects for the UI, keeping the live UI object hidden in a bpatcher, and simply scale the output to rawfloat for the live.dial based on the given parameter range for the Max object.