Zitiere bbogart@ryerson.ca:
Wah!?
Johannes, did you take a look at my example patch? It works as I describe, arguments to separator DO change render order as they do with gemheads... Oh was it a fluke? I'm using 87 on Windows...
hi sorry to say, but i still haven't really had a look at your example-patch, just because there is no pd on the machine i am sitting right now.
I tried it again with three objects, using 1 5 and 10 as the separator arguments and it seems to work fine, I don't have any source on this machine so I can't tell you whats going on...
what i guess, is that you are *creating* the objects in a certain order. for instance, you first make just [separator]s, then you add a "1" to the "first" separator, a "5" to the second and a "10" to the third. since you have created the separators in this certain order, pd's message system will first pass the gemlist to separator #1, then to #5 and finally to #10.
however, as i have pointed out before, this behavious of pd is so by chance and must in no way relied on. it is "undefined" (but happens to be as it is)
I disagree that its confusing, its just as intuitive as gemhead's render priority. Actually I think using a [t a a] confuses things more significantly.
actually (without wanting to be rude, but i am *very* concerned about getting people to really use pd, which involves using "trigger" when appropriate, since it is one of the most important concepts in pd's message domain) [t a a] will not confuse anyone, who has read 2.control.examples/3.connections.pd relying on a separator id a) makes things inconsistent with pd b) gives the ones who has to implement it, a hell of a time, since it means breaking the execution to do scheduling.
c) might be simpler for various other reasons (i don't say, that the trigger thig doesn't have any drawbacks)
mfg.a.rd IOhannes