Problem with Knob Update

[honki-bobo]

Wouldn't it be possible to set knob min and max values just during designing? Or is it really necessary to change min and max even during runtime?

Sure. You could also do something like this in Notify():

Code: Select all

if (component == knob1) {
    knob1Val = doubleValue;
    if (knob1Val > knob2Val) {
        knob2.SetValue(knob1Val);
    }
} else if (component == knob2) {
    if (doubleValue >= knob1Val) {
        knob2Val = doubleValue;
    } else {
        knob2.SetValue(knob1Val);
    }
}

This way you don't have to mess with the range of knob2 and knob2 can always be used over its full range, but only updates its value if it is >= knob1Val.

One way or another, you will have to implement the dependency of knob2 on the value of knob1.

[seal58]

Now I see.

[UrbanCyborg]

Thanks for the insightful analysis, honki-bobo. Your first method is one I considered, then rejected, because it would really make a mess of the interface pretty quickly. The second doesn't do quite what I intended (I had to try it out to be sure I wasn't speaking through my hat), in that it changes the value of the non-moving control, and not the moving one. Furthermore, the one that got moved can still be moved itself to invalidate the invariant. I think providing the converse case might stop the latter from happening, but haven't yet tried it.

In other words, this method changes the invariant, rather than enforcing it. The actual situation I'm working with is a bit messier yet, because there are three knobs, one of which must stay between the other two, and, of course, the outside ones can't be allowed to move past the middle one. I think, though, that you've given me enough of a hint that I can sort things out. The solution to the problem appears to be that you can't expect a graphics update from the knob that was just mouse-moved; I think delaying the change to a timer-based test might solve it, but I haven't tested that, either. Ah, well, something to do in the wee hours.

Thanks, again, honki-bobo. I appreciate it.

[ColinP]

I suspect quite a few devs have come across this design problem as there are many situation where one might want ordered parameters.

One neat solution would be a variation on the VoltageSlider component that had two (or more) knobs on it.

In horizontal orientation something like...

Min----knob1----knob2----Max

Where knob1 can vary between Min and knob2 and knob2 can vary between knob1 and Max. Ideally with the option of allowing either knob to push the other along or not.

It wouldn't be a massive job to code a slider like this by hand but it'd be nice if there was a standard solution in the component library.

[seal58]

It was mentioned, that Info about second SetValue parameter is part of Voltage API documentation. Until now I don't even know, where I can find such a documention. Neither on CA web pages nor in VMD or VMD PDF help nor in this forum I could find any link. Where is it hidden?

[ColinP]

It was mentioned, that Info about second SetValue parameter is part of Voltage API documentation. Until now I don't even know, where I can find such a documention. Neither on CA web pages nor in VMD or VMD PDF help nor in this forum I could find any link. Where is it hidden?

It's in the SDK which I believe you can download here...

https://store.cherryaudio.com/software/ ... eloper-kit

Once you've downloaded that you'll find the specific info in your download folder at...

Voltage-Developer-Kit-2.5.3/Documentation/JavaDocs/voltage/core/VoltageKnob.html

But more generally you might want to start browsing at...

Voltage-Developer-Kit-2.5.3/Documentation/JavaDocs/overview-tree.html

But don't get too excited, unfortunately there's not actually some massive treasure trove of information in the SDK, just one or two extra bits and bobs.

[seal58]

O God! That's my fail. Sure I know VMD Manual, but I did not go for details into JavaDocs so far. In future I will do.
Thank you!

[UrbanCyborg]

Just a final message to give the thread a bit of closure. I did get it working, but not quite the way I originally intended. The earlier parts of this thread showed that the problem was that the mouse code sort of walked on the last update with its own update. So the fix would be to move the modification of the knob that was mouse-moved to a later time. I first tried using a timer, but although it mostly worked, you could still bollix it just by moving the mouse slowly. Strange. I finally got reasonable results by setting all three knobs to accept mouse input, then putting the knob updates in the left-mouse-click-release handler. That guaranteed that the updates would fall after anything the mouse did.