I totally get what Joao means, I had wondered about that myself. This problems happens for GOP patches which draw scalars on the toplevel canvas. The reclaiming doesn't work if the struct name has a $0. if you reload the abstraction, the $0 will have another value.
but here's a solution: you actually don't have to draw the scalars on the toplevel canvas. you can also draw them in a subpatch with GOP enabled which you can clear without destroying your whole patch :-). > Gesendet: Donnerstag, 08. Juni 2017 um 20:48 Uhr > Von: "Miller Puckette" <m...@ucsd.edu> > An: "João Pais" <jmmmp...@gmail.com> > Cc: PD-List <pd-list@lists.iem.at> > Betreff: Re: [PD] wild structs on pd files > > Yep, if there are "data" in your patch and you remove the "struct" object > that defines them, Pd keeps teh objects around anyway, so that you can > reclaim them by reloading the "structs" later. Put the abstractions back > in the patch (or even just load them separately) and you can see the > invisible scalars again. > > There's no way to globally delete all scalars belonging to a given "struct" > except by manually editing the patch. > > cheers > Miller > > On Thu, Jun 08, 2017 at 08:04:58PM +0200, João Pais wrote: > > 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 > > _______________________________________________ > 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