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/
I've added the range limit issue to the bottom here.
(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@gmail.com wrote:
Judging from this commit, the new behavior is by design: https://github.com/pure-data/pure-data/commit/f0a3a0c621dacc1f617cf07b38d8dc...
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 robotcowboy.com
On Dec 20, 2015, at 4:07 PM, pd-list-request@lists.iem.at wrote:
*From: *William Huston williamahuston@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@lists.iem.at" pd-list@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. *
