Ganging 3 numbers, can't believe I am stuck!
I need to gang (at least) 3 numbers (ultimately sliders or dials) so they can be at different values and move together proportionally when 1 of them is changed by the user. It is also necessary to set them individually. This did not seem like a difficult prospect, but I am at my wit's end with trying to accomplish it as a rather small part of a project.
My attempt is below-- It is probably a bit tricky to follow at this point. I thought it was working, and it does to an extent. But at some point the input and output values get out-of-sync, I can't determine where. That's the immediate question.
Secondarily: This is good example of how Max has become an absolute time black-hole for me. I would call myself a reasonably competent novice user in some areas at this point (maybe some would beg to differ), so I'm not sure how much longer the "it takes awhile" argument is going to be a valid one. I am not at strong with the range of math that could apply in a given Max project, so I'm sure that doesn't help. But in this case, I think I'm lost in the logic somewhere.
I need some way to diagnose and modify my working approach, because the amount of unproductive time I end up spending on a problem like this is not sustainable-- Hitting this kind of wall is the rule, not the exception, for me in a given Max project. I am at a loss for exactly how what seems like a simple task gets my into this kind of quagmire, and how to manage it once I'm in. Maybe my expectation is off, and at this level I *should* expect to spend 3 days getting an element like this working the way I need it to (which is admittedly quite specific)? Or something in my approach or skills is deeply flawed?
In search of practical and spiritual Max-guidence...
Brian
I agree that this task should not be difficult to achieve in Max, but to my knowledge there is not a really simple way to do it. (There may very well be a way I'm unaware of.) A gangable multislider-like object would be a great new UI object in Max. Maybe someone has already written one? In any case, below is an example of how you can DIY. (JavaScript would also be useful for this.) It's not exactly what you requested, because it retains the offset between sliders, not the proportion, but you could make a proportional version. See what you think of it. (It's meant to be used in Presentation mode.)
I don't blame you for getting stuck on this one, it's not that straightforward, at least I wasn't able to find an easy way to do it. I tried one myself awhile back and gave up eventually. Looking forward to investigating the versions on here.
However, I did create an interesting hackaround for this by using filtergraph~ as the control and then grabbing however many levels across the band, then sending them into multislider. With the right filter type (like "resonant") you can easily create gangs of various shapes and acuteness, especially because the mouse interaction is more complex in filtergraph~. And with a switch ("gang off") you can set the filtergraph~ to "ignore click", then click through to the multislider, thereby being able to set individual sliders.
Thanks a lot, all. Actually, the fact that others also report it is difficult is very, very useful to know. I guess I just don't know enough to expect when something will be harder to accomplish than I think it will be. I had no idea this would be anything more the trivial, so it tends to get me down when I can't get it done with trivial effort.
Nicolas, thanks for the tips. I see exactly what you mean. I tried multislider, it actually would not work for some exact reason I don't recall now; Or at least it wasn't any benefit over individual sliders. So I thought breaking-up the list would be more flexible. Maybe that was not the correct priority or didn't turn out to be the case.
The problem I run into are the these confusing recursive loops when I want to include more than 1 interface object, which is often the case. For example, a slider and a number box, and they should both be changeable by the user and in-sync with each other. Add the need to set the objects via a message and then pattr, and it gets confusing. Since I know interface objects are expensive on CPU and I'm already not often taking the most efficient route, I usually hate to add what seem like 'excess' objects-- but Christopher's solution, for example, works beautifully, so maybe I just need accept it sometimes. :)
I want power, flexibility, extensibility, efficiency, and elegance in the work! All from my little novice-level skills. :)
Any further sage advice on the topic is welcomed. Thanks again,
Brian
This recursive loop issue that Nicolas mentioned is definitely something that hangs me-up. Really, it can't be *this* hard to keep to 2 simple UI objects in-sync in Max. Inevitably, one will want a UI object (slider/dial) and to know what the value of it is (number); Since the number box is there, it seems natural (and useful) to be able to set it directly. This is starting to seem like a very tricky thing to do!
Set msgs are fine, as in the example I found here:
https://cycling74.com/forums/continuous-update-between-two-ui-elements
But now the value this (presumably) single parameter may be coming from 2+ different places. So if you want to send the number anywhere, it has to be connected to both the UI objects.
I tried [pvar], which I haven't used much in the past-- Maybe there is a way to be more clever with it than I am, but it wasn't much more help in avoiding stack overflows. Seems like [pattr] might be useful, but also kind of unnecessary to use every time this comes up. Or is that the best option?
Are there any other techniques here that seem less hacky? I'm a big enough hack as it is...
Many thanks!
Brian
BTW, Christopher your patch-guts worked beautifully! Not all the way out of the woods, but thus far I was able to remove the 'presentation' sliders and it does just what it needs to. Please consider adding it to the Tools part of the Cycling site. I'm happy to do it (under my account, but crediting you) if you'd prefer not to, and are OK with it...