hi i found, that if i create a subpatch using "pd mysubp" and i have a loadbang inside it, it is sending two (!) bangs in the beginning. w2k / 0.34 and 0.35. sÃme.
Hmm, doesn't appento me. You just make a patch with a subpatch with a loadbang in it, load the patch, and the loadbang goes off twice?
cheers Miller
On Fri, May 10, 2002 at 12:46:01PM +0200, sme wrote:
hi i found, that if i create a subpatch using "pd mysubp" and i have a loadbang inside it, it is sending two (!) bangs in the beginning. w2k / 0.34 and 0.35. sÜme.
hi it is a patch with a subpatch, and in the subpatch i have an abstraction that contains a loadbang. sorry, i didnŽt write this correctly in my first e-mail. so there is the abstraction "blob" that has the loadbang (connected to a print). and then i have the patch "testlodbangg" where i make a subpatch "pd subpatch" and in this subpatch i have the blob-object. and when i open the testlodbangg-patch i have printed bang twice. sÃme.
----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: "sme" marius.schebella@chello.at Cc: pd-list@iem.kug.ac.at Sent: Friday, May 10, 2002 5:32 PM Subject: Re: [PD] loadbang in subpatches
Hmm, doesn't appento me. You just make a patch with a subpatch with a
loadbang
in it, load the patch, and the loadbang goes off twice?
cheers Miller
On Fri, May 10, 2002 at 12:46:01PM +0200, sme wrote:
hi i found, that if i create a subpatch using "pd mysubp" and i have a loadbang inside it, it is sending two (!) bangs in the beginning. w2k / 0.34 and 0.35. sÃme.
hi Marius, hi Miller,
right, there is a bug in canvas_loadbang()/canvas_loadbangabstractions() combo. It appears to be easy to fix in g_canvas.c: either delete lines 968 and 972, or delete lines 959-960 (test23). But I am somewhat baffled -- actually I do not see any reason why abstractions are handled separately in canvas_loadbang(). Maybe a new feature is going to bang in that requires such differentiation?
Krzysztof
sme wrote: ...
it is a patch with a subpatch, and in the subpatch i have an abstraction that contains a loadbang.
Sure enough. "loadbang" is complicated because you should allow abstractions to field their loadbangs before everyone else, and once that is done, subpatches before the "main" patch. (Or perhaps I'm overdoing it...)
Krzysztof's fix would give the right number (one a piece) of bangs, but I found that getting the order right as well took a bit more work (to appear in next test version...)
cheers Miller
On Sat, May 11, 2002 at 01:16:10PM +0200, Krzysztof Czaja wrote:
hi Marius, hi Miller,
right, there is a bug in canvas_loadbang()/canvas_loadbangabstractions() combo. It appears to be easy to fix in g_canvas.c: either delete lines 968 and 972, or delete lines 959-960 (test23). But I am somewhat baffled -- actually I do not see any reason why abstractions are handled separately in canvas_loadbang(). Maybe a new feature is going to bang in that requires such differentiation?
Krzysztof
sme wrote: ...
it is a patch with a subpatch, and in the subpatch i have an abstraction that contains a loadbang.
hi,
maybe you have a connection duplicate? Try to reconnect the loadbang.
Btw, Miller has just fixed this (on editor's side), so that you cannot make duplicates in .35-test23.
Krzysztof
sme wrote: ...
i found, that if i create a subpatch using "pd mysubp" and i have a loadbang inside it, it is sending two (!) bangs in the beginning.