[PD] packed floats to select object changes the select value

Matt Davey hard.off at gmail.com
Tue Sep 22 15:46:51 CEST 2020


>I don't quite see why you are singling out [select]

It's the only object that has ever given me trouble in this way.  My guess
is because almost all other objects that allow a list to modify their
internal state will also output differently once that state has been
modified.  If your [+ 1] object suddenly starts adding 100 to every input,
it's pretty obvious what's gone wrong, and can be quickly fixed.  I think
the reason why it's so sneaky with [sel] is that its main outlet only
outputs a bang, and not a value.  There's never a "wrong" value being
passed, unless you are connected to its last outlet (which usually you
aren't).

Anyway, i can fully accept that this is not considered a bug, but rather a
feature that keeps the [sel] object consistent with all others.  I'm not
trying to stir up trouble, was just trying to point out the issue, cos it
cost us a lot of time and effort to get to the bottom of a bug that was
caused by that behaviour.

I did have a good think about possible uses for the current behaviour, and
i can think of one.

[pack f f]
|
[sel ]

is quicker than

[pack f f]
|
[== ]
|
[t b]

personally i would definitely use the second case, as it much more
obviously shows the intent, but i guess the first way would also be
legitimate.

thanks everyone for the discussion.  happy to consider this one closed
now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200922/a445900a/attachment.html>


More information about the Pd-list mailing list