[PD] GEM and transparency

[zmoelnig at iem.at]

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