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:
Hey Martin,
your problem is render-order not transparency. transparency only
workstrue
Gemheads with smaller numbers get rendered first (0-1-2-3-4
etc..) and
the same goes for separators,
hey, this is news to me. i cannot think of any way how to achieve this (from the programmer's side, of course), without getting a *lot* of timing problems. if you really need a specific rendering order with several separators, you'll have to do what you have to do in pd to acchieve a certain order of message- execution (basically Gem is message based): use "trigger"
sketch:
[gemlist( | [t a a] | | [gemlist2( [gemlist1(
I've attached a demo example to make things more clear
i'll have a look at this. however, i will *strongly* recommend to not rely on a feature like the ordering of several gem-sublists by giving an argument to [separator]. it will be really confusing to ignore pd's way of handling such problem.
mfg.as.r IOhannes