it's super-simple to just add a [clip 0 127] (or whatever) before or after the slider to achieve the behavior you are looking after.
The problem is that now you have to make sure that these two ranges always stay in sync. (It is easy to accidentally change one while keeping the other.)
that would mean, that they cannot be used for "filtering" (out-of-bound values).
It's not only about filtering. The "set" message has the same problem.
I think we should generally follow the principle of least surprise. If a numberbox allows to set a lower and upper bound, I guess most users would expect that this range is always respected.
But that's just my 22¢ :)
Christof
On 11.05.2023 16:37, IOhannes m zmoelnig wrote:
On 5/11/23 14:30, William Huston wrote:
Joao,
IIRC, some objects in pd-extended, like hsliders, would always respect the limits whether dialed-in, or when coming from an input.
When i finally switched to vanilla, I noticed the same thing, limits were not respected on the inputs, and a lot of my patches broke.
I don't know whether the "sensible" behavior was ever in the mainline branch, or only in -extended.
for me the "sensible" thing is to keep the GUI-objects as minimal as possible. that would mean, that they cannot be used for "filtering" (out-of-bound values). it's super-simple to just add a [clip 0 127] (or whatever) before or after the slider to achieve the behavior you are looking after. otoh, it is not *so* super-simple to build a patch that prevents a user from dragging a numberbox out of bounds, so i understand why this functionality is in. (it's of course possible).
otoh, the GUI objects are already full of various cruft (starting with the possibility to set lower and upper ranges in sliders, and various characteristics... ideally they would just output 0..1 and the user can then map that to whatever they need).
but that is just my 2¢ (from a minimalistic POV).
masd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list