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