Hello list,
after all this time, I just noticed something which I'm not sure if it was always like that or it changed without me noticing it: in atom boxes one can define the lower/upper limits, which work when dragging with the mouse, but don't work when inputting a number or sending a message - the numbers go further. Since usually these limits are there to make sure that unwanted information doesn't go further, wouldn't it make sense to make those limits work on all cases?
For what it's worth, I checked on Max and that's the behaviour there. It seems strange to say "here are the limits, but in this and that situation they're ignored".
Best,
Joao
- João Pais jmmmpais@gmail.com [2023-05-11 09:18]:
Hello list,
after all this time, I just noticed something which I'm not sure if it was always like that or it changed without me noticing it: in atom boxes one can define the lower/upper limits, which work when dragging with the mouse, but don't work when inputting a number or sending a message - the numbers go further. Since usually these limits are there to make sure that unwanted information doesn't go further, wouldn't it make sense to make those limits work on all cases?
For what it's worth, I checked on Max and that's the behaviour there. It seems strange to say "here are the limits, but in this and that situation they're ignored".
I guess the idea is that number boxes are transparent with regard to messages input into them, and that they will not act on the data according to something set (and hidden) in the properties dialog. You have a [clip] object for this functionality, with the added plus of making its function well visible.
Peter
Pd-L2Ork offers this as a user-settable property.
Best,
Ico
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.
It would be nice if we could request the sensible behavior in a PD patch. I know it's always hard to change the behavior of an object w/o breaking compatibility with older patches.
But it would be nice to be able allow a checkbox that says "enforce limits on inputs" (which is the sensible thing).
BH
On Thu, May 11, 2023 at 3:19 AM João Pais jmmmpais@gmail.com wrote:
Hello list,
after all this time, I just noticed something which I'm not sure if it was always like that or it changed without me noticing it: in atom boxes one can define the lower/upper limits, which work when dragging with the mouse, but don't work when inputting a number or sending a message - the numbers go further. Since usually these limits are there to make sure that unwanted information doesn't go further, wouldn't it make sense to make those limits work on all cases?
For what it's worth, I checked on Max and that's the behaviour there. It seems strange to say "here are the limits, but in this and that situation they're ignored".
Best,
Joao
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
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
FYI, it's still possible to restore the previous (clipped) behaviour by adding "-compatibility 0.45" to the startup flags.
It's not possible to simply go back, it would probably break a lot of the patches that have been written since Pd 0.46 (around 2014).
Antoine
Le jeu. 11 mai 2023 à 17:11, Roman Haefeli reduzent@gmail.com a écrit :
On Thu, 2023-05-11 at 16:54 +0200, Christof Ressi wrote:
I think we should generally follow the principle of least surprise.
+1
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 11 de mai. de 2023 às 13:23, Antoine Rousseau antoine@metalu.net escreveu:
FYI, it's still possible to restore the previous (clipped) behaviour by adding "-compatibility 0.45" to the startup flags.
for iemgui's nbx it is actually 'pd compatibility 0.52', for atom boxes it's always been like that, so no compat flag
after all this time, I just noticed something which I'm not sure if it was always like that or it changed without me noticing it: in atom boxes
the documentation is clear about this. It might not be intuitive, but it's known and documented to say that values over limits are passed through. I personally don't have a problem with it and can see a reasoning for it.
It's not possible to simply go back, it would probably break a lot of the patches that have been written since Pd 0.46 (around 2014).
Antoine
Le jeu. 11 mai 2023 à 17:11, Roman Haefeli reduzent@gmail.com a écrit :
On Thu, 2023-05-11 at 16:54 +0200, Christof Ressi wrote:
I think we should generally follow the principle of least surprise.
+1
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Antoine Rousseau -
Christof Ressi -
Ico Bukvic -
IOhannes m zmoelnig -
João Pais -
Peter P. -
Roman Haefeli -
William Huston