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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
