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...
Message: 2Date: Thu, 11 May 2023 08:30:01 -0400From: William Huston <williamahuston@gmail.com>To: Jo?o Pais <jmmmpais@gmail.com>Cc: PD-List <pd-list@lists.iem.at>Subject: Re: [PD] Number atom box limits oversteppedMessage-ID: <CA+HRq4mgC-YZT7PH=WAb5Rhj0OpT9gaeJi0MBH3bcViaFAawDA@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, orwhen 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 themainline 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 breakingcompatibility 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