The problem of putting a pipe into the renderchain is that the rendering order will be disturbed. This means, the gemhead does some setup for the whole chain, like resetting the coordinate system, colors, translation matrix etc but the pipe will "break" this chain, and therefore the result of the whole operation will be more or less unpredictable.
Short: No pipe in the renderchain, you will have to delay the controls. If your abstraction takes a parameter list this is easy to do.
GG.
On Wed, 29 Oct 2003 ben@ekran.org wrote:
Hey Martin,
I just taught a large class of college students pd/Gem. I think the real confusion is that each object in PD seems to have a unity to itself. This is not the case with gem objects (which only have meaning in chains, rotate by itself does not make any sense.) Putting a pipe in a gemchain does not make sense because a gemchain is a single object. Putting a pipe into a square for example does not make conceptual sense. The pipe would always alter some aspect of the square, not the square itself. Aspects of gemchains are done by objects yes, but they are always controlled by messages.
I don't have gem on this machine, what happens if you put a pipe in a gemchain??? (since a gemchain is not passing the same kind of data as all other PD obejcts)
Good luck!
Ben
PS: Working with a lot of Gem you get used to having to interpolate or mess with a lot of control data. I've had to make arrays of up to 90 interpolators! Anyone have hints on manageing arrays of interpolators? I guess I could wip up an abstraction that dynamically patches the number of interpolators needed, but this is ugly! any other ideas? (this is why I'm wanting grid-flow features in Gem) then I just need to interpolate the "grid" and have Gem parse the grid into control data for each point (or whathave you)
Sorry I didn't make this clearer. I have about 50 instances of the abstraction, and they all have translateXYZ and rotateXYZ objects that receive global data. I suppose what I could do is, as you say, delay the control data in the abstractions.
Somehow, conceptually I thought it made much more sense to just delay the whole chain in the abstraction, rather than have something like 20 pipes in each abstraction. Intuitively it seems simpler, but I suppose delaying the control data would actually be more efficient.
- martin
----- Original Message ----- From: ben@ekran.org To: martin.dupras@uwe.ac.uk Sent: Wednesday, October 29, 2003 8:12 PM Subject: Re: [PD] 'pipe' in Gem chain
Ok, I'm just confused why you need to "pipe" the gem chain rather than piping the control data that is causing what you want to happen... Or am I misunderstanding? What are you delaying? The video signal? When the object gets rendered? When the object is visible?
B.
What I'm trying to do is this. I have a partial gem chain, which
"sends" to several instances of the other end of the chain. In other words, something like this:
[gemhead] | [pix_video] | [pix_texture] | [s mygemchain]
and the abstractions:
[r mygemchain] | [translateXYZ $1 $2 $3] ! [pipe $4] | [cube]
I'm doing this from memory since the patch is not in front of me,
but in that's the essence of it. I would like to be able to declare each instance of the abstraction with its own delay.
- martin
----- Original Message ----- From: ben@ekran.org To: martin.dupras@uwe.ac.uk Cc: pd-list@iem.kug.ac.at Sent: Wednesday, October 29, 2003 7:40 PM Subject: Re: [PD] 'pipe' in Gem chain
What problem are you trying to solve by delaying?
Ben
Is it possible to delay execution in a gem chain, say the
equivalent
of putting a 'pipe' object?
Thanks,
- martin
This incoming email to UWE has been independently scanned for
viruses and
any virus detected has been removed using McAfee anti-virus software
This incoming email to UWE has been independently scanned for viruses and
any virus detected has been removed using McAfee anti-virus software
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list