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
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
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" msp@ucsd.edu An: "João Pais" jmmmpais@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
I wouldn't say that: in this particular case all the scalars are drawn in abstractions with gop (or even without gop). The same happens in the help files of the abstractions in my jmmmp library. The $0 might not be the problem as well, as there aren't that many loose scalars starting with 10.. as there should be.
I think as well, changing the struct definition isn't the problem: I didn't change the patch that often, and after deleting the data from the file, it appears again next time the patch is saved. It might be the case that the main patch creates a kind of copy of the struct definitions?
Am 08.06.2017 10:45 nachm. schrieb "Christof Ressi" christof.ressi@gmx.at:
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" msp@ucsd.edu An: "João Pais" jmmmpais@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
Am 08.06.2017 8:49 nachm. schrieb "Miller Puckette" msp@ucsd.edu:
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
-
Christof Ressi -
João Pais -
Miller Puckette