Re: [PD] Number atom box limits overstepped
Em qui., 11 de mai. de 2023 às 13:23, Antoine Rousseau 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 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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
On 5/11/23 19:32, Dan Wilcox wrote: I can't find the commit for this, f0a3a0c621dacc1f617cf07b38d8dc563703d12e fdmsa IOhannes OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
On 5/11/23 16:53, William Huston wrote: Come to think of it, I think we've had this conversation before, years ago. I guess I just keep needing to be reminded of the PD Paradigm. i wouldn't call it "the Pd Paradigm". i would like it to be *the* Pd paradigm, but I think there's evidence that it is not (generally speaking). fgmdsa IOhannes OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
Howdy all, there is a changelog fr sorts included with the HTML docs. For Pd 0.46, it says: "Bug fixes to IEM GUIs: sliders and radio buttons pass floating-point numbers through without limiting them to the GUI's range or resolution. Also, the toggle no longer resets its "value" (the nonzero number it outputs) when receiving numbers in messages. Set compatibility to 0.45 or earlier to get the old behavior (using "pd compatibility" message or a startup flag)." This change brought the behavior of those GUIS to be in line with atoms and can be disabled, although it probably also disables other need things you might want. I can't find the commit for this, but I think it came from Miller, so maybe he can weight in. In any case, someone could always examine and port the Pd-L2ork approach to further discussion... > On May 11, 2023, at 4:54 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 2 > Date: Thu, 11 May 2023 08:30:01 -0400 > From: William Huston <mailto:williamahus...@gmail.com>> > To: Jo?o Pais mailto:jmmmp...@gmail.com>> > Cc: PD-List mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] Number atom box limits overstepped > Message-ID: ><mailto:CA+HRq4mgC-YZT7PH=wab5rhj0opt9gaeji0mbh3bcviafaa...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > 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 Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
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 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
Re: [PD] Number atom box limits overstepped
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 signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
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 OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
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 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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Number atom box limits overstepped
Pd-L2Ork offers this as a user-settable property. Best, Ico -- Ivica Ico Bukvic, D.M.A. Director, Creativity + Innovation Institute for Creativity, Arts, and Technology Virginia Tech Creative Technologies in Music School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 i...@vt.edu ci.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net On Thu, May 11, 2023, 04:23 Peter P. wrote: > * João Pais [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-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
Re: [PD] Number atom box limits overstepped
* João Pais [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-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Number atom box limits overstepped
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
