I wonder if we could as part of the setup call for each external somehow infer default behaviors for each object e.g.:
something_bang() { Error("this inlet does not support bang message\n"); } etc.
Then if that particular object has another addmethod after it referencing its own genuine bang (or whatever) method, such call would override the original. I am just not sure if this is possible in the first place and whether that could produce some misleading messages as well (e.g. I just fixed cxc/ascseq crash when receiving a bang but this was solved without having the bang function--this may be fixed by the aforesaid approach as long as this is somehow possible as part of the setup function and without having to manually alter every single external's setup function and assuming that bang function will take precedence over the anything function).
Thoughts?
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Jonathan Wilkes Sent: Monday, February 25, 2013 8:18 PM To: pd-list Subject: [PD] bang vs empty list
Seems like for any object that doesn't have a bang method nor list method, an empty list silently gets discarded.
compare
[bang( | [sin]
to
[list( | [sin]
or, more likely
[bang(
| [t a] | [sin]
Same for [select] and many others.
Is there a way to fix this?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list