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:
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
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list