Re: [PD] wild structs on pd files

[João Pais]

Am 08.06.2017 8:49 nachm. schrieb "Miller Puckette" :

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"


Ah, so this happens when the struct object is deleted? Does it also happens
when the struct is changed? Because some of the data doesn't come from
deleted 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

Re: [PD] wild structs on pd files

[Christof Ressi]

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

Re: [PD] wild structs on pd files

[Miller Puckette]

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