Hi!
I have a question about the expected behaviour of loadbang when it's used in a sub-patch that's built dynamically. It appears that it isn't getting triggered. I've attached a simplified example.
Should it get triggered? Does anyone know of a workaround for this? In other words, something that's functionally equivalent? I want certain events to happen once when I build a sub-patch dynamically, to initialize some objects. I guess I could use creation arguments to do that, but I'd rather not have to do that.
Thanks, David.
Hello David,
Set you message box like :
; pd-WORKSPACE clear; pd-WORKSPACE obj 20 20 loadbang-test; pd-WORKSPACE loadbang
++
Jack
Le 16/02/2017 à 17:18, David a écrit :
Hi!
I have a question about the expected behaviour of loadbang when it's used in a sub-patch that's built dynamically. It appears that it isn't getting triggered. I've attached a simplified example.
Should it get triggered? Does anyone know of a workaround for this? In other words, something that's functionally equivalent? I want certain events to happen once when I build a sub-patch dynamically, to initialize some objects. I guess I could use creation arguments to do that, but I'd rather not have to do that.
Thanks, David.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
basically that works too. however, it gets a bit messy once you have nested loadbangs because these will get called more than once (I don't know why). as long as you doesn't relay on loadbangs firing exactly once, this shouldn't be a big problem, though.
Gesendet: Donnerstag, 16. Februar 2017 um 17:43 Uhr Von: Jack jack@rybn.org An: pd-list@lists.iem.at Betreff: Re: [PD] Question about loadbang and dynamic sub-patches
Hello David,
Set you message box like :
; pd-WORKSPACE clear; pd-WORKSPACE obj 20 20 loadbang-test; pd-WORKSPACE loadbang
++
Jack
Le 16/02/2017 à 17:18, David a écrit :
Hi!
I have a question about the expected behaviour of loadbang when it's used in a sub-patch that's built dynamically. It appears that it isn't getting triggered. I've attached a simplified example.
Should it get triggered? Does anyone know of a workaround for this? In other words, something that's functionally equivalent? I want certain events to happen once when I build a sub-patch dynamically, to initialize some objects. I guess I could use creation arguments to do that, but I'd rather not have to do that.
Thanks, David.
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
[loadbang] doesn't fire in dynamically created patches. The easiest workaround: use [iemguts/initbang].
Christof
Gesendet: Donnerstag, 16. Februar 2017 um 17:18 Uhr Von: David dfkettle@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] Question about loadbang and dynamic sub-patches
Hi! I have a question about the expected behaviour of loadbang when it's used in a sub-patch that's built dynamically. It appears that it isn't getting triggered. I've attached a simplified example. Should it get triggered? Does anyone know of a workaround for this? In other words, something that's functionally equivalent? I want certain events to happen once when I build a sub-patch dynamically, to initialize some objects. I guess I could use creation arguments to do that, but I'd rather not have to do that. Thanks, David. _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
FWIW in pd-l2ork/purr-data loadbang fires even in dynamically created patches. You can also click on it to invoke a manual bang. HTH
On 2/16/2017 12:52 PM, Christof Ressi wrote:
[loadbang] doesn't fire in dynamically created patches. The easiest workaround: use [iemguts/initbang].
Christof
Gesendet: Donnerstag, 16. Februar 2017 um 17:18 Uhr Von: David dfkettle@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] Question about loadbang and dynamic sub-patches
Hi!
I have a question about the expected behaviour of loadbang when it's used in a sub-patch that's built dynamically. It appears that it isn't getting triggered. I've attached a simplified example.
Should it get triggered? Does anyone know of a workaround for this? In other words, something that's functionally equivalent? I want certain events to happen once when I build a sub-patch dynamically, to initialize some objects. I guess I could use creation arguments to do that, but I'd rather not have to do that.
Thanks, David. _______________________________________________ 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
On 02/17/2017 02:25 AM, Ivica Ico Bukvic wrote:
FWIW in pd-l2ork/purr-data loadbang fires even in dynamically created patches.
so does that mean, that if i have an abstraction "foo":
[loadbang] | [f 1] | [outlet]
and i dynamically create a patch including that abstraction, the loadbang will be lost on the created patch? (meaning: the following will not print: #X obj 100 100 foo; #X obj 100 200 print; #X connect 0 0 1 0; )
if it does print, i would be interested in the heuristic you used.
if it does indeed not print, then i think i just hit a bug (as the patch behaves different when created dynamically or not¹)
gfmsrda IOhannes
¹ it doesnt't in Pd vanilla, if you don't forget to send a "loadbang" message after doing the dynamic patching as a kind of "finalize".
Since you too mentioned the |loadbang( message method, do you (or others) have an idea why nested loadbangs fire more than once with this method? [initbang] on the other hand works just as expected. This is not an issue if one uses loadbang only to initialize some variable, but it can induce subtle bugs once it triggers some action which should only happen once (e.g. incrementing a counter, dynamically creating objects etc.)
Is this expected, known behaviour or rather a bug?
See attached patch.
Christof
Gesendet: Freitag, 17. Februar 2017 um 10:41 Uhr Von: zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] Question about loadbang and dynamic sub-patches
On 02/17/2017 02:25 AM, Ivica Ico Bukvic wrote:
FWIW in pd-l2ork/purr-data loadbang fires even in dynamically created patches.
so does that mean, that if i have an abstraction "foo":
[loadbang] | [f 1] | [outlet]
and i dynamically create a patch including that abstraction, the loadbang will be lost on the created patch? (meaning: the following will not print: #X obj 100 100 foo; #X obj 100 200 print; #X connect 0 0 1 0; )
if it does print, i would be interested in the heuristic you used.
if it does indeed not print, then i think i just hit a bug (as the patch behaves different when created dynamically or not¹)
gfmsrda IOhannes
¹ it doesnt't in Pd vanilla, if you don't forget to send a "loadbang" message after doing the dynamic patching as a kind of "finalize".
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
hello in you example, you have 2 subpatch named sub. both of them receive the loadbang. the 1st transfert it to the 2nd, and the 2nd receive also it's own.
rename one of the subpatch to have only 1 loadbang.
anyway. why using loadbang/initbang in dynamic patching? why not using a less confusing [r init] and manually send "init"... KISS (one can use $arg to restrict the scope of the init)
Cheers C
Le 17/02/2017 à 11:56, Christof Ressi a écrit :
Since you too mentioned the |loadbang( message method, do you (or others) have an idea why nested loadbangs fire more than once with this method? [initbang] on the other hand works just as expected. This is not an issue if one uses loadbang only to initialize some variable, but it can induce subtle bugs once it triggers some action which should only happen once (e.g. incrementing a counter, dynamically creating objects etc.)
Is this expected, known behaviour or rather a bug?
See attached patch.
Christof
Gesendet: Freitag, 17. Februar 2017 um 10:41 Uhr Von: zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] Question about loadbang and dynamic sub-patches
On 02/17/2017 02:25 AM, Ivica Ico Bukvic wrote:
FWIW in pd-l2ork/purr-data loadbang fires even in dynamically created patches.
so does that mean, that if i have an abstraction "foo":
[loadbang] | [f 1] | [outlet]
and i dynamically create a patch including that abstraction, the loadbang will be lost on the created patch? (meaning: the following will not print: #X obj 100 100 foo; #X obj 100 200 print; #X connect 0 0 1 0; )
if it does print, i would be interested in the heuristic you used.
if it does indeed not print, then i think i just hit a bug (as the patch behaves different when created dynamically or not¹)
gfmsrda IOhannes
¹ it doesnt't in Pd vanilla, if you don't forget to send a "loadbang" message after doing the dynamic patching as a kind of "finalize".
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
in you example, you have 2 subpatch named sub
Ouch... forgot to add a dollar zero... how stupid. thanks!
Gesendet: Freitag, 17. Februar 2017 um 15:03 Uhr Von: "cyrille henry" ch@chnry.net An: pd-list@lists.iem.at Betreff: Re: [PD] Question about loadbang and dynamic sub-patches
hello in you example, you have 2 subpatch named sub
both of them Reserve the loadbang.
the 1st transfert it to the 2nd, and the 2nd receive also it's own.
rename one of the subpatch to have only 1 loadbang.
anyway. why using loadbang/initbang in dynamic patching? why not using a less confusing [r init] and manually send "init"... KISS (one can use $arg to restrict the scope of the init)
Cheers C
Le 17/02/2017 à 11:56, Christof Ressi a écrit :
Since you too mentioned the |loadbang( message method, do you (or others) have an idea why nested loadbangs fire more than once with this method? [initbang] on the other hand works just as expected. This is not an issue if one uses loadbang only to initialize some variable, but it can induce subtle bugs once it triggers some action which should only happen once (e.g. incrementing a counter, dynamically creating objects etc.)
Is this expected, known behaviour or rather a bug?
See attached patch.
Christof
Gesendet: Freitag, 17. Februar 2017 um 10:41 Uhr Von: zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] Question about loadbang and dynamic sub-patches
On 02/17/2017 02:25 AM, Ivica Ico Bukvic wrote:
FWIW in pd-l2ork/purr-data loadbang fires even in dynamically created patches.
so does that mean, that if i have an abstraction "foo":
[loadbang] | [f 1] | [outlet]
and i dynamically create a patch including that abstraction, the loadbang will be lost on the created patch? (meaning: the following will not print: #X obj 100 100 foo; #X obj 100 200 print; #X connect 0 0 1 0; )
if it does print, i would be interested in the heuristic you used.
if it does indeed not print, then i think i just hit a bug (as the patch behaves different when created dynamically or not¹)
gfmsrda IOhannes
¹ it doesnt't in Pd vanilla, if you don't forget to send a "loadbang" message after doing the dynamic patching as a kind of "finalize".
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2/17/2017 4:41 AM, zmoelnig@iem.at wrote:
On 02/17/2017 02:25 AM, Ivica Ico Bukvic wrote:
FWIW in pd-l2ork/purr-data loadbang fires even in dynamically created patches.
so does that mean, that if i have an abstraction "foo":
[loadbang] | [f 1] | [outlet]
and i dynamically create a patch including that abstraction, the loadbang will be lost on the created patch? (meaning: the following will not print: #X obj 100 100 foo; #X obj 100 200 print; #X connect 0 0 1 0; )
If you had a print inside the abstraction it would print. If you dynamically create objects, chances are you will first dynamically create the abstraction which can initialize itself using a loadbang, then the print, then the connection. In this respect its behavior is synonymous to, for example [f 42] which initializes itself to 42 but does not output anything until asked to do so. This way initialization of individual abstractions is handled gracefully, whereas the example you are suggesting would require manual interaction regardless whether you are using an abstraction foo or an [f 42]. In other words, pd-l2ork/purr-data's loadbang implementation allows for parity between built-in objects and abstractions. This feature is used extensively inside pd-l2ork's k12 mode.
As a side-note, pd-l2ork also has an internal pre-loadbang call that is reserved for dealing with presets and occurs before the loadbang. This way you can gracefully handle multiple instances of the same abstraction (as is the case inside K12) and store their states through a single preset_hub object located on the parent canvas.
Best,
Ico
if it does print, i would be interested in the heuristic you used.
if it does indeed not print, then i think i just hit a bug (as the patch behaves different when created dynamically or not¹)
gfmsrda IOhannes
¹ it doesnt't in Pd vanilla, if you don't forget to send a "loadbang" message after doing the dynamic patching as a kind of "finalize".
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 02/18/2017 05:38 AM, Ivica Ico Bukvic wrote:
If you had a print inside the abstraction it would print. If you dynamically create objects, chances are you will first dynamically create the abstraction which can initialize itself using a loadbang, then the print, then the connection. In this respect its behavior is synonymous to, for example [f 42] which initializes itself to 42 but does not output anything until asked to do so. This way initialization of individual abstractions is handled gracefully, whereas the example you are suggesting would require manual interaction regardless whether you are using an abstraction foo or an [f 42]. In other words, pd-l2ork/purr-data's loadbang implementation allows for parity between built-in objects and abstractions.
the thing is, that pd-vanilla's [loadbang] has slightly different semantics: it allows you to implement [init 666] as an abstraction (rather than just only [f 42]).
you are of course free to change the semantics of any built in object. however, it comes at the cost of deliberatly breaking compatibility.
gfmards IOhannes
-
Christof Ressi -
cyrille henry -
David -
Ivica Ico Bukvic -
Jack -
zmoelnig＠iem.at