Re: [PD] Regression Issue/Bug: Range-limited [hsl] responds differently on out-of-range input
Judging from this commit, the new behavior is by design: https://github.com/pure-data/pure-data/commit/f0a3a0c621dacc1f617cf07b38d8dc... 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@lists.iem.at wrote:
From: William Huston <williamahuston@gmail.com mailto: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 mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto: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.
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. *
On Dec 20, 2015, at 6:03 PM, William Huston <williamahuston@gmail.com mailto:williamahuston@gmail.com> wrote:
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/
Please move bug tracking OFF Facebook.
It is a well known fact that FB has joined the Dark Side,
;)
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Thanks for the report, William. It looks like Pd-l2ork currently has the behavior you desire.
However, I'd like to know more about the history of this change. Can anyone test what happens on Pd versions less than (and perhaps equal to) 0.42? All I can find on the list is this:http://thread.gmane.org/gmane.comp.multimedia.puredata.general/93682/focus=9... But I think it's a separate issue. -Jonathan
On Sunday, December 20, 2015 8:07 PM, Dan Wilcox <danomatika@gmail.com> wrote:
On Dec 20, 2015, at 6:03 PM, William Huston williamahuston@gmail.com wrote: 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/
Please move bug tracking OFF Facebook.
It is a well known fact that FB has joined the Dark Side, ;)
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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 hereAgain-- 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 mailto:danomatika@gmail.com> wrote: Judging from this commit, the new behavior is by design: https://github.com/pure-data/pure-data/commit/f0a3a0c621dacc1f617cf07b38d8dc... 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@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: William Huston <williamahuston@gmail.com mailto: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 mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto: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.
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
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@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 hereAgain-- 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 mailto:danomatika@gmail.com> wrote: Judging from this commit, the new behavior is by design: https://github.com/pure-data/pure-data/commit/f0a3a0c621dacc1f617cf07b38d8dc... 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@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: William Huston <williamahuston@gmail.com mailto: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 mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto: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.
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Dan Wilcox -
Jonathan Wilkes -
Miller Puckette -
William Huston