hi all,
i'm currently thinking about an elegant way to get rid of the problem of ordering loadbangs.
from what i understand, at the moment, there is only the following order of loadbangs: abstractions, subpatches, canvas.
but having two sub-patches, i can't be sure, which one is loadbanged first. this can be a problem when having abstractions that should be initialized from other abstractions somewhere in pd (not from a parent canvas). thus i'd propose the following: there are basically two ways how abstractions communicate with each other: inlets and receives. i'd propose that every inlet / outlet / receive declares a loadbang function. before this loadbang function has been run, the outlet events are queued (maybe using clock callbacks), then then the behaviour is the same as currently. for the outlets it's more tricky, since they'd have to register a loadbang on the parent canvas.
if someone can think of a more elegant way / has a different opinion, i'd like to hear ...
cheers ..... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i'm currently thinking about an elegant way to get rid of the problem of ordering loadbangs.
from what i understand, at the moment, there is only the following order of loadbangs: abstractions, subpatches, canvas.
Hm, is this "specified" somewhere? Or is it just "the way it is" currently, similar to the way, two connections of a message outlet are currently handled by creation order, however by specification the order there is undefined?
My practical view to loadbang ordering is simple: The only elegant way to solve the problem is triggers. They make the ordering explicit and printable.
Ciao
Loadbangs are "depth first", i.e., loadbangs in abstractions (and subpatches in general) go off before loadbangs in the parent. This is so that abstactions can initialize themselves before receiving messages coming from other loadbangs.
Two loadbangs in the same canvas (window), or in canvases neither of which is a parent of the other, might go off in either order.
cheers Miller
On Tue, Aug 09, 2005 at 09:41:29AM +0200, Frank Barknecht wrote:
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i'm currently thinking about an elegant way to get rid of the problem of ordering loadbangs.
from what i understand, at the moment, there is only the following order of loadbangs: abstractions, subpatches, canvas.
Hm, is this "specified" somewhere? Or is it just "the way it is" currently, similar to the way, two connections of a message outlet are currently handled by creation order, however by specification the order there is undefined?
My practical view to loadbang ordering is simple: The only elegant way to solve the problem is triggers. They make the ordering explicit and printable.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 9 Aug 2005 10:28:58 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
Loadbangs are "depth first", i.e., loadbangs in abstractions (and subpatches in general) go off before loadbangs in the parent. This is so that abstactions can initialize themselves before receiving messages coming from other loadbangs.
Two loadbangs in the same canvas (window), or in canvases neither of which is a parent of the other, might go off in either order.
right ... having a patch like (which might be a common performance setup): |pd presets|
|pd dsp|
|pd midi|
one can't be sure, that the preset loadbangs are executed in advance. would be a big problem if the dsp objects are created dynamically (using pd or dyn~), but the initialisation has not yet occurred ...
the algorithm i proposed makes sure, that no information is sent to an uninitialized canvas.
cheers ... tim
On Tue, 9 Aug 2005, Miller Puckette wrote:
Loadbangs are "depth first", i.e., loadbangs in abstractions (and subpatches in general) go off before loadbangs in the parent. This is so that abstactions can initialize themselves before receiving messages coming from other loadbangs.
That's not the usual definition of depth-first. You mean post-order.
Suppose you have a tree like this:
A |-B | |-C | `-D `-E |-F `-G
Then here are a few example enumerations:
a depth-first post-order may be: C D B F G E A a depth-first pre-order may be: A B C D E F G a breadth-first post-order may be: C D F G B E A a breadth-first pre-order may be: A B E C D F G
... but there are several of each of those because the order of the children of a node is not specified. (In this case there are eight possible depth-first post-orders, for example)
Depth-first is enumeration that uses a stack (or recursion or special voodoo tricks).
Breadth-first is enumeration that uses a queue (or anything equivalent).
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Indeed, "C D B F G E A" (or one of the other 7) is the order loadbangs go off in... so something in my explanation was confusing, but you and I do agree on the meaning of "depth first"...
cheers Miller
On Wed, Aug 10, 2005 at 06:13:13PM -0400, Mathieu Bouchard wrote:
On Tue, 9 Aug 2005, Miller Puckette wrote:
Loadbangs are "depth first", i.e., loadbangs in abstractions (and subpatches in general) go off before loadbangs in the parent. This is so that abstactions can initialize themselves before receiving messages coming from other loadbangs.
That's not the usual definition of depth-first. You mean post-order.
Suppose you have a tree like this:
A |-B | |-C | `-D `-E |-F `-G
Then here are a few example enumerations:
a depth-first post-order may be: C D B F G E A a depth-first pre-order may be: A B C D E F G a breadth-first post-order may be: C D F G B E A a breadth-first pre-order may be: A B E C D F G
... but there are several of each of those because the order of the children of a node is not specified. (In this case there are eight possible depth-first post-orders, for example)
Depth-first is enumeration that uses a stack (or recursion or special voodoo tricks).
Breadth-first is enumeration that uses a queue (or anything equivalent).
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 10 Aug 2005, Miller Puckette wrote:
Indeed, "C D B F G E A" (or one of the other 7) is the order loadbangs go off in... so something in my explanation was confusing, but you and I do agree on the meaning of "depth first"...
Well, ... no.
On Wed, Aug 10, 2005 at 06:13:13PM -0400, Mathieu Bouchard wrote:
On Tue, 9 Aug 2005, Miller Puckette wrote:
Loadbangs are "depth first", i.e., loadbangs in abstractions (and subpatches in general) go off before loadbangs in the parent. This is so that abstactions can initialize themselves before receiving messages coming from other loadbangs.
That's not the usual definition of depth-first. You mean post-order.
That post-order stuff is what Pd requires.
Pd also does it depth-first, but that's not a requirement, it's an implementation detail. Pd could use breadth-first or any hybrid of depth-first and breadth-first, and even picking randomly among all $0's that are ready for loadbanging (!!!), and it shouldn't make a difference, as long as the post-order requirement is satisfied.
It's like when running the "make" command. it's solving dependencies depth-first usually, but it doesn't have to, and in fact, if you use the -j option (multitasking), it will usually solve dependencies in a different order, due to tasks being of nonequal durations.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
hi miller, hi devs ...
On Tue, 9 Aug 2005 10:28:58 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
Loadbangs are "depth first", i.e., loadbangs in abstractions (and subpatches in general) go off before loadbangs in the parent. This is so that abstactions can initialize themselves before receiving messages coming from other loadbangs.
Two loadbangs in the same canvas (window), or in canvases neither of which is a parent of the other, might go off in either order.
having a look at the html documentation again ...
2.6.2. persistence of data Among the design principles of Pd is that patches should be printable, in the sense that the appearance of a patch should fully determine its functionality.
does anyone have a proposal, how to fit the loadbang problem to this design principal?
cheers ... tim
i'm currently thinking about an elegant way to get rid of the problem of ordering loadbangs.
from what i understand, at the moment, there is only the following order of loadbangs: abstractions, subpatches, canvas.
Hm, is this "specified" somewhere? Or is it just "the way it is" currently, similar to the way, two connections of a message outlet are currently handled by creation order, however by specification the order there is undefined?
are you referring to a language specification ;-)
My practical view to loadbang ordering is simple: The only elegant way to solve the problem is triggers. They make the ordering explicit and printable.
well, this only works as long as you are the maker of all loadbangs. when you start to distribute a collection of abstractions (don't you ;-), you can't be sure any more that your user's loadbang occurs after your loadbang. basically ANY abstraction that should be reusable by others can't use loadbangs/loadbang-based externals.
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
Hm, is this "specified" somewhere? Or is it just "the way it is" currently, similar to the way, two connections of a message outlet are currently handled by creation order, however by specification the order there is undefined?
are you referring to a language specification ;-)
Somehow yes. But Miller clarified this point for me.
My practical view to loadbang ordering is simple: The only elegant way to solve the problem is triggers. They make the ordering explicit and printable.
well, this only works as long as you are the maker of all loadbangs. when you start to distribute a collection of abstractions (don't you ;-), you can't be sure any more that your user's loadbang occurs after your loadbang. basically ANY abstraction that should be reusable by others can't use loadbangs/loadbang-based externals.
More correctly it would be like this: others can't use loadbangs/loadbang-based externals that rely on being activated in a specific order.
I see, that it is useful, that abstractions are loadbanged before their parents. However I really don't know a simple and practical solution to the case where you'd want to have one abstraction bang before another, maybe even an instance of the same abstraction, in a case, where they are on the same hierarchical level
Or rather, somehow it feels wrong to me to have to rely on a kind of automatic ordering of loadbangs in abstractions/subpatches which are on the same hierarchical level. This is something I would rather let the user of these abstractions to ... probably using triggers. ;)
The good thing is: A loadbang only happens once.
Ciao
On Mon, 8 Aug 2005, Tim Blechmann wrote:
there are basically two ways how abstractions communicate with each other: inlets and receives. i'd propose that every inlet / outlet / receive declares a loadbang function. before this loadbang function has been run, the outlet events are queued (maybe using clock callbacks), then then the behaviour is the same as currently. for the outlets it's more tricky, since they'd have to register a loadbang on the parent canvas.
I don't understand what you mean by all of this. Do you have an example?
I also have a proposal for solving the [loadbang] problem.
My suggestion would be that [loadbang] would take a single argument which would be an integer interpreted as a priority order, with a default value of zero. Negative values would be accepted.
The first [loadbang] to be triggered is the one that has the largest argument, because that's consistent with the fact that in a [t] the first outlet to be active is the one with the biggest index.
Two [loadbang]s with the same priority get executed in whatever order.
The scope of [loadbang] priorities is the same as the scope of a $0, that is, a subpatch is considered to be part of its parent, whereas an abstraction instance is not. Therefore, in the priority hierarchy (the post-order tree traversal in the mail to Miller), a $0 corresponds to one node, and the priority numbers fine-tune the ordering within its node.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
there are basically two ways how abstractions communicate with each other: inlets and receives. i'd propose that every inlet / outlet / receive declares a loadbang function. before this loadbang function has been run, the outlet events are queued (maybe using clock callbacks), then then the behaviour is the same as currently. for the outlets it's more tricky, since they'd have to register a loadbang on the parent canvas.
I don't understand what you mean by all of this. Do you have an example?
it's like having an abstraction like this after the inlets:
|inlet data| | | |loadbang| | | | |flush( |/ |pipe infinity| | |outlet data|
misusing pipe as message queue ...
My suggestion would be that [loadbang] would take a single argument which would be an integer interpreted as a priority order, with a default value of zero. Negative values would be accepted.
similar to gemheads ... this would solve about about 99.999% of the cases, unless someone uses loadbang f, where f is the lowest number represented by t_float / the lowest number that a pd patch can save...
well, i somehow like to have a solution covering all cases ...
still thinking ... tim
On Thu, 11 Aug 2005, Tim Blechmann wrote:
it's like having an abstraction like this after the inlets: |inlet data| | |loadbang| | |flush( |/ |pipe infinity| |outlet data| misusing pipe as message queue ...
Why do you call it a misuse ?
similar to gemheads ... this would solve about about 99.999% of the cases, unless someone uses loadbang f, where f is the lowest number represented by t_float / the lowest number that a pd patch can save...
Well I don't claim to protect the user against him/herself and using such numbers in loadbang priorities has to be a quite deliberate act *and* loadbang priorities don't propagate across .pd files so no person can inflict that upon another.
well, i somehow like to have a solution covering all cases ...
Which cases am I missing???
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
it's like having an abstraction like this after the inlets: |inlet data| | |loadbang| | |flush( |/ |pipe infinity| |outlet data| misusing pipe as message queue ...
Why do you call it a misuse ?
because it's a workaround ...
well, i somehow like to have a solution covering all cases ...
Which cases am I missing???
well, if you compare an abstraction with a class in oo programming languages (i think this somehow makes sense), the loadbangs would be the equivalent to a constructor. since you know more programming languages than i do ... how many programming languages allow the use of classes, before the constructor was executed? i don't know any ...
if we want to see pd as a programming language, we should start to treat it as one ;-)
cheers ... tim
-
Frank Barknecht -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann -
Tim Blechmann