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...
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...
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. Does this patch work for anyone else?
Here is an other example with three layers.
Ben
----- Original Message ----- From: zmoelnig@iem.at Date: Friday, July 18, 2003 9:42 am Subject: Re: [PD] GEM and transparency
Zitiere bbogart@ryerson.ca:
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.
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)
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
IOhannes,
Maybe the gem help files need to be updated. This is from the help/gemhead.pd help patch (second paragraph):
"gemhead takes an argument to determine when it receives the render command. The default value is 50. The lower the value is, the sooner the gemhead will receive the rendering command (a value of 1 is the lowest possible value.) This values becomes important when you are doing alpha blending and for certain objects (such as light). "
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of zmoelnig@iem.at Sent: 18 July 2003 21:50 To: bbogart@ryerson.ca Cc: zmoelnig@iem.at; pd-list@iem.kug.ac.at Subject: Re: [PD] GEM and transparency
Zitiere bbogart@ryerson.ca:
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.
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
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Martin Dupras wrote:
you misunderstood something: you cannot give arguments to [separator] to define a execution order of sub-gemchains.
however: [gemhead]s have this very argument. and you can even change it at run-time with a [set $1( message (replace $1 with the wanted value). so the documentation is all right.
mfg.as.rd IOhannes