Abstractions don't loadbang when created via [; pd-mycanvas obj 10 10 myabs(
Luckily I was doing something simple and was able to catch what was going on pretty quickly, but I'd imagine this could be a huge pain in a more complex patch. I doubt this is intended behavior, can anyone check on this?
The new [initbang] does the job, but loadbang should probably be fixed.
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
Abstractions don't loadbang when created via [; pd-mycanvas obj 10 10 myabs(
Send "loadbang" to "pd-mycanvas" to loadbang the subpatch and its abstractions:
[obj 10 10 myabs, loadbang( | [s pd-mycanvas]
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Sure, I can do this... but I'm trying to determine why the loadbang would not occur when created with internal messaging?
On 12/30/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
Abstractions don't loadbang when created via [; pd-mycanvas obj 10 10 myabs(
Send "loadbang" to "pd-mycanvas" to loadbang the subpatch and its abstractions:
[obj 10 10 myabs, loadbang( | [s pd-mycanvas]
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
Sure, I can do this... but I'm trying to determine why the loadbang would not occur when created with internal messaging?
This has been discussed in the past, although in the distant past like 2002 for example: http://lists.puredata.info/pipermail/pd-list/2002-07/007352.html
Not loadbanging dynamically created abstractions is a design decision. It is intentional.
The main reason for it is that abstractions may generate output at their outlets as a result of a loadbang inside. Normally abstractions do the loadbang *before* the parent patch does its own loadbangs. So a loadbang in an abstraction may change the parent's patch behaviour, through an outlet or through a sender/receiver.
However with dynamically created abstraction instances, the time, when the outlet is connected to something will be after the abstraction was created dynamically so it's loadbang-output would be sent into nirvana, whereas when loading from a file or when recreating a previously created abstraction manually, the connections are already there, when the loadbang inside the abstraction fires.
To avoid ambiguities it was decided, that loadbangs in dynamically created abstractions need to be activated manually e.g. with the "loadbang" message to the parent (sub)patch.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht ha scritto:
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
Abstractions don't loadbang when created via [; pd-mycanvas obj 10 10 myabs(
Send "loadbang" to "pd-mycanvas" to loadbang the subpatch and its abstractions:
[obj 10 10 myabs, loadbang( | [s pd-mycanvas]
Ciao
hello, I remember having played with this. but why manually created objects (i.e. with CTRL+1, objname, CTRL+E) do receive their loadbang, while there isn't an equivalent for dynamically patched objects? (yes, you can only loadbang the *parent* of the object you've just created)
I remember a (perhaps dirty) workaround for this was to enclose the new [dynamically created] object in a subpatch, but this solution has a big drawback, that is: you can't do it in an abstraction, because accessing 'pd-subcanvas-name' would not be unique.
otherwise one would have used [namecanvas ...], but someone is saying it's deprecated??
...
big inconsistencies?
note: I'm not sure if dollarg expansion now works in a place different from beginning, it est: would-$1-get-replaced-with-its-value-and-also-$2-will?
my two cents
-
Federico -
Frank Barknecht -
Luke Iannini (pd)