[PD] wild structs on pd files

João Pais jmmmpais at gmail.com
Thu Jun 8 20:04:58 CEST 2017


Hi again Miller,

I had a question regarding structs. When editing my patches in a text  
editor, I noticed that at the top of the patch there were some "stowaway"  
structs (and scalars), which can only come from abstractions I used in the  
main patch - but these abstractions should have the structs inside them,  
and not on the main patch. Nevertheless, the main patch begins now with  
some #N struct .... lines, before the first #N canvas ... . I also noticed  
that if I delete the #N struct .... lines there won't be any (visible)  
problem with the patch.

Do you know this behaviour? Is it normal, or is it an open issue that  
should be dealt with? E.g. like arrays, should scalars have a "don't save  
with patch" option?

Furthermore, this brings up the subject of old data (i.e. trash) hanging  
around a patch that isn't visible to the "naked eye":
- does this data in any way affects or conflicts with the patch?
- does it get ignored, thrown away or rewritten at restart of the patch?  
Adding to that, I use $0-variables in my struct names, which will mean  
that in one session they will be called 1007-bla, and 1920-bla in the next  
one.
- since the only way to know how many structs are saved within a patch is  
by looking at the patch code, and the only way to delete structs in Pd is  
graphically, would it make sense to add a struct-scanning and delete  
methods in [pointer], or a way to scan it by sending it a pd-canvas  
identifier?
- or looking at it from another angle, since inside Pd the only way to be  
sure to clean a canvas is the send a "clear" method, would it help to  
implement a "clear-struct" method to a pd canvas? Or even "clear-struct  
all" that could be sent to the top canvas of a patch, and clean all  
subpatches recursively?

Best,

Joao



More information about the Pd-list mailing list