hi !
i just went across a problem that makes me guess that iemguts' [closebang] seems to be relying on creation order to work correctly.
attached are two simple example patches that should write the content of a [text] object to a file on the disk when the patch is closed. both seem to work (as a connected [print] object reports its bang correctly), but only example nr 1 actually writes the file.
the difference is, that in example 1 [closebang] was created as the very first object in the main patch. in the second example [closebang] was created after everything else.
can someone please test it and confirm/falsify ? if this is a bug, can it be corrected, or is that impossible due to PD's patching design ? probably just needs some note in the helpfile ...
best
oliver
hi oliver,
TLDR: have both [clonebang] and the object to be notified together in the same subpatch - but not on the toplevel! *) - then the order doesn't matter. see attached modified example.
when a glist is destroyed the following happens for each object: 1) is object itself a glist? call canvas_closebang, 2) delete object.
canvas_closebang does the following for each object: is *not* a glist? send closebang message
if your [closebang] is in a subpatch and the subpatch comes after the object you want to notify, the latter will already be gone once [closebang] is triggered. however, if you have both in the same subpatch, your [closebang] will be triggered before any objects in the subpatch are deleted.
one could argue that Pd should really send the "closebang" message in the same order as "loadbang" (subpatches first and before any object is actually deleted)...
Christof
*) in old versions of [iemguts], [closebang] didn't trigger on the toplevel. this has been fixed about 4 month ago.
Gesendet: Freitag, 24. August 2018 um 17:26 Uhr Von: oliver oliver@klingt.org An: pd-list@mail.iem.at Betreff: [PD] [closebang] issue ...
hi !
i just went across a problem that makes me guess that iemguts' [closebang] seems to be relying on creation order to work correctly.
attached are two simple example patches that should write the content of a [text] object to a file on the disk when the patch is closed. both seem to work (as a connected [print] object reports its bang correctly), but only example nr 1 actually writes the file.
the difference is, that in example 1 [closebang] was created as the very first object in the main patch. in the second example [closebang] was created after everything else.
can someone please test it and confirm/falsify ? if this is a bug, can it be corrected, or is that impossible due to PD's patching design ? probably just needs some note in the helpfile ...
best
oliver_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
thanks christof, for your nice and detailed explanation !
Christof Ressi wrote:
hi oliver,
TLDR: have both [clonebang] and the object to be notified together in the same subpatch - but not on the toplevel! *) - then the order doesn't matter. see attached modified example.
yep, that works !
one could argue that Pd should really send the "closebang" message in the same order as "loadbang" (subpatches first and before any object is actually deleted)...
or even that PD would need a native [closebang] ;-)
Christof
*) in old versions of [iemguts], [closebang] didn't trigger on the toplevel. this has been fixed about 4 month ago.
but this version is not yet on deken, right ?
best
oliver
On 2018-08-28 01:50, oliver wrote:
one could argue that Pd should really send the "closebang" message in the same order as "loadbang" (subpatches first and before any object is actually deleted)...
or even that PD would need a native [closebang] ;-)
why? (of course you could wish for each and every object that is currently not native to Pd to be included; but what makes [closebang] so special that it should be included? it's widespread use cases?)
fgamdr IOhannes
or even that PD would need a native [closebang] ;-)
why? (of course you could wish for each and every object that is currently not native to Pd to be included; but what makes [closebang] so special that it should be included? it's widespread use cases?)
well, it would make sense as a complementary object to [loadbang] and yes, i use it frequently to do save-on-patch-closing stuff. which is how i stumbled across the "order" problem with iemguts' [closebang].
but of course, that's really only a personal preference, and so far i'm fine using externals.
best
oliver
Save on patching closing is a strong point for having a native closebang.
But, on the other side, why is not good to have closebang as native?
Em Qua, 29 de ago de 2018 08:39, oliver oliver@klingt.org escreveu:
or even that PD would need a native [closebang] ;-)
why? (of course you could wish for each and every object that is currently not native to Pd to be included; but what makes [closebang] so special that it should be included? it's widespread use cases?)
well, it would make sense as a complementary object to [loadbang] and yes, i use it frequently to do save-on-patch-closing stuff. which is how i stumbled across the "order" problem with iemguts' [closebang].
but of course, that's really only a personal preference, and so far i'm fine using externals.
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
IOhannes m zmoelnig -
José de Abreu -
oliver