[PD] gemhead order

Martin Dupras martin.dupras at uwe.ac.uk
Sat Jul 19 02:38:51 CEST 2003


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). "

- martin

-----Original Message-----
From: pd-list-admin at iem.at [mailto:pd-list-admin at iem.at] On Behalf Of
zmoelnig at iem.at
Sent: 18 July 2003 21:50
To: bbogart at ryerson.ca
Cc: zmoelnig at iem.at; pd-list at iem.kug.ac.at
Subject: Re: [PD] GEM and transparency

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







More information about the Pd-list mailing list