Especially with [select], it's hard to check its internal state. Maybe
a possibility for introspection is lacking here?
[select] doesn't have any more internal state than, say, [+]. It is not special in any way.

A new 'introspect' method, that would print the current state to the console?
Please no :-)

On 22.09.2020 09:37, Roman Haefeli wrote:

On Mon, 2020-09-21 at 17:16 +0800, Matt Davey wrote:
I am aware of the workarounds, and have put one in place to fix this
now.

That's not the issue here.  The issue is that accidentally sending a
list to the select object invisibly changes its behaviour and can
produce some hard to find bugs in big patches.
I don't quite see why you are singling out [select]. To my knowledge,
all control objects distribute incoming lists across there inlets.
There is nothing special in [select] here. Also, it's pretty common in
Pd that you can override creation arguments without the visual
representation not reflect it. Personally, I find this discussion moot.
There are lots of other objects where this could happen, but [sel] is
somewhat unique in that it won't output incorrect values to its main
outlet but rather just stops sending bangs and sends to its second
outlet.
Especially with [select], it's hard to check its internal state. Maybe
a possibility for introspection is lacking here? A new 'introspect'
method, that would print the current state to the console?

Roman

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

Reply via email to