Thanks for the fast response, Dan.
> Also judging form the commit, you can simply launch pd with an older compatibly mode.
(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.
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> 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
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 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).
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):
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] \
[hsl] \
| non-range limited output here
|
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,