Hello everyone. I am trying to setup a sequencer with quantization in which I can set the root note. I have it currently functioning so that when the root is changed, the slider range is adjusted so that its minimum value reflects the new root note. However, I noticed that adjusting this does not clamp its values within the new range, this does not happen until the slider is actually touched. Is there any way to force a slider to clamp itself within a newly set range via a message?

@lo94 [set "value"( message will move the fader to that value or as close as it can get.
So a fader that was 1-127 and has been reset to 1-12 will go to 12 when sent a [set 50( message, but not output anything and then output 12 as you first move the fader.
If that is what you need?
David.

@whale-av Close but the issue is that I'm trying to essentially only adjust sliders that are below the new root note. I think I will likely need to have a wonky workaround because the send and receive channels of the slider are incorporated into a much larger system (so banging them directly causes a lot of extra code to be executed, may just need to set some global value and use a [select] to pipe the flow of data into an update root section). I was just curious if there was any sort of simple "if outside new range, clamp to closest value" sort of message that could be sent

@lo94 Maybe something like this:

slider_range.pd

@ingox Ahhh right I forgot about clip, that's probably the easiest route to go. Thanks! Had just been staring at it for too long I think haha

There is a subtle but very important detail in ingox's example -- the [f] box.

One of the things I learned from SuperCollider is that, often/usually, you gain flexibility by separating the GUI away from the program's main logic. (In SC, a rule of thumb that I follow is to make every operation possible to call strictly in code -- there should be no operation that requires you to touch a GUI. Then the GUI is only a shell on top of the programming interface. If I can touch a slider to change a controller's value, I can also write theController.value = x -- the GUI isn't necessary, just helpful.)

Pd encourages users to integrate the GUI into the logic. This is easier for simple cases. But eventually, you run into a problem like "I want to clamp the slider's value, but if I get the value out of the slider, then it triggers all this other logic that I don't want to run at that time" ... which is exactly the type of problem you have when GUI and logic are not encapsulated as separate entities!

Here, slider --> [s $0-slider] transfers to [r $0-slider] into an [f] cold inlet. Now the GUI's value is freely accessible, without affecting the data flow coming out of the slider itself.

You could have a dozen places in your patch with [r $0-slider] --> (cold) [f]. Each of these places could query and use the value independently. That's difficult/impossible with an in-line GUI design.

hjh

@ddw_music Funny thing is, I did this for every other use case but broke it just for this. The issue is more that it's part of a larger system. I didn't want radio buttons, went with toggles instead, but only one within that row of toggles can be on at a time. I have a fairly good idea of how I'll rework it. It's mostly that in this case, a change in value should always trigger an update to the other toggles within the change. Likely I'll just add a second receive channel within my control abstraction for handling cases like this. Then I can keep it compartmentalized where the primary receive channel simply updates the values and the secondary receive channel will both send an update to the values and then output a bang if there's extra logic needed.

@ddw_music Yes, seperating GUI and logic is key!

@ingox Not sure.
A Gui is used to control, but also to show.
That's why they also have an inlet.
And faders have "jump on click" and "steady on click" so we can decide how to interact.
David.

while your original question ultimately is one about how to deal with a certain object, i would recommend to rethink the whole approach.

problems like this can be reduced if you strictly divide up your patch into a.) mouse input objects b.) display objects and then c.) scale or distort number ranges where needed.

for example all sliders could always be 0. - 1. and then the other components, i.e. which values are shown to the user and which values are sent to some other part of the patch, could rely on this range.

that sliders accept messages to set their range does not mean that this is always the best practice.

and don´t overuse s/r

@lo94
yes, [clip] followed by [change] is the "default" way for most custom graphics elements with mouse coord input.

there is a simple mapping abstraction:
https://forum.pdpatchrepo.info/topic/12871/how-do-i-set-x-range-from-0-to-1-properties-for-a-graphic-array/10
unlike common Pd conventions, all its' inlets are hot, you might change that.