[PD] Regression Issue/Bug: Range-limited [hsl] responds differently on out-of-range input

[Miller Puckette]

This gets complicated... I think it's best to have all the controls act the same
(and the only reasonable way to ensure this is to pass values through without either
quantizing them to the pixel or clipping them to the range.)  One can easily [clip] the
control's output to force it to the control's range but one cannot easily un-clip it.

I'm neutral on whose bug-reporting chanel is the least evil, but if some of our browsers
are refusing to play with SF, that could be a good reason to migrate elsewhere.

cheers
M

On Sun, Dec 20, 2015 at 07:35:19PM -0700, Dan Wilcox wrote:
> I’d also note that, as far as I recall, the atom number box has always worked in a similar way to the now updated slider: the min & max control the UI interaction limits but do not clip the incoming/outgoing numbers.
> 
> --------
> Dan Wilcox
> @danomatika <https://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> > On Dec 20, 2015, at 6:03 PM, William Huston <williamahuston at gmail.com> wrote:
> > 
> > Thanks for the fast response, Dan.
> > 
> > > Also judging form the commit, you can simply launch pd with an older compatibly mode.
> > 
> > From the update summary:
> > 
> > updates to other guis. sliders and radios now pass values through without
> > quantizing them, and toggles don't reset their non-zero values on incoming
> > float messages.  Reverts to old behavior if "pd cpmpatibility" is set
> > <= 0.45  (change committed Aug 4, 2014)
> > 
> > Well "quantizing" is different from range-limiting. 
> > 
> > I actuallly raised the issue about quantizing on FB here: (March 9, 2015) but not on pd-list.  https://www.facebook.com/groups/4729684494/permalink/10152864120779495/ <https://www.facebook.com/groups/4729684494/permalink/10152864120779495/>
> > 
> > I've added the range limit issue to the bottom here. 
> > 
> > <quantization vs range-limiting.gif>
> > ​(apologies to anyone with a text-based email client)
> > 
> > Also, the "pd cpmpatibility" (and is that a typo?) mode is not ideal IMO because there are other side-effects, i.e., effect on toggles. 
> > 
> > I think the proper behavior is that when sliders pass input, the value is identical to the input, i.e., not "quantized" by e.g., a log-slider 
> > AND ALSO respects range-limits (if specified). 
> > 
> > The general rule being, that if you want to create a change in behavior, PD should default to the OLD, behavior to maintain regression compatibility....
> > 
> > Unless the behavior is very badly broken. Quantization is such an example of "badly broken" IMO, as it is a side-effect, where floats are subtly and unexpected modified (and can become large changes if these floats are taken as integers (or compared as integers). 
> > 
> > It is perfectly reasonable to expect specified range-limits to be respected by input messages, and rather surprising to me that they are not. 
> > 
> > Also, there is a very easy workaround (assuming the OLD behavior of HSL):
> > 
> > source
> > | \
> > |     \
> > [hsl]   \
> > |            non-range limited output here
> > |
> > range limited output here
> > 
> > Again-- this should be caught by a full suite of regression tests. 
> > Do they exist?
> > 
> > Regression tests should make sure that the language specification is followed, and errors are not introduced in new versions.
> > 
> > If there are no regression tests, 
> > then maybe there is no language specification...? 
> > 
> > Look, how are we going to get the US Department of Defense to accept PD for MILSPEC applications like this!?   
> > 
> > (It's a joke!)
> > 
> > Thanks,
> > BH
> > 
> > 
> > 
> > On Sun, Dec 20, 2015 at 6:55 PM, Dan Wilcox <danomatika at gmail.com <mailto:danomatika at gmail.com>> wrote:
> > Judging from this commit, the new behavior is by design: https://github.com/pure-data/pure-data/commit/f0a3a0c621dacc1f617cf07b38d8dc563703d12e <https://github.com/pure-data/pure-data/commit/f0a3a0c621dacc1f617cf07b38d8dc563703d12e>
> > 
> > I seem to remember a long discussion where people *did not* like the clipping behavior. The rational was that the min/max values are meant for the UI min and max without enforcing direct clipping which you can do using [clip] explicitly.
> > 
> > Also judging form the commit, you can simply launch pd with an older compatibly mode.
> > 
> > --------
> > Dan Wilcox
> > @danomatika <https://twitter.com/danomatika>
> > danomatika.com <http://danomatika.com/>
> > robotcowboy.com <http://robotcowboy.com/>
> >> On Dec 20, 2015, at 4:07 PM, pd-list-request at lists.iem.at <mailto:pd-list-request at lists.iem.at> wrote:
> >> 
> >> From: William Huston <williamahuston at gmail.com <mailto:williamahuston at gmail.com>>
> >> Subject: [PD] Regression Issue/Bug: Range-limited [hsl] responds differently on out-of-range input
> >> Date: December 20, 2015 at 4:06:36 PM MST
> >> To: "pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>" <pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>>
> >> 
> >> 
> >> Regression Issue/Bug: 
> >> 
> >> Issue: Range-limited [hsl] responds differently on out-of-range input
> >> PD Versions: 0.43.4-extended vs 0.46.7
> >> OS: Raspbian 
> >> 
> >> The patch is:
> >> 
> >> [1000(
> >> |
> >> [hsl] # range limted 0-127 (default setting)
> >> |
> >> [nbx]  
> >> 
> >> Upon a bang to the message box, 
> >> 0.43.4-extended the answer is 127.
> >> On 0.46.7 the answer is 1000. 
> > 
> > 
> > 
> > 
> > -- 
> > --
> > May you, and all beings
> > be happy and free from suffering :)
> > -- ancient Buddhist Prayer (Metta)
> 

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list