ugh.

someone needs to set the reply-to address in the mailing list robot to default to the PD list... :\

Begin forwarded message:

From: vade doktorp@mac.com Date: March 21, 2005 11:25:57 AM EST To: "B. Bogart" ben@ekran.org Subject: Re: [PD] GEM pix delay loop

Would using pix_separate to separate the pix_data in the chain right above your [s loop] generate a 'new gemhead' type instance?? (havent tried it)

On Mar 21, 2005, at 10:34 AM, B. Bogart wrote:

...

This looks a lot more like a problem for a PDP solution.

I would not think one could send the whole gemlist [s loop] back up the chain into itself. Remeber that in Gem it is NOT the video data passing through the gemchain but control data and pointers.

Perhaps some Gem developers may have an idea of how to make this work... Gem is not the solution to all problems, and if you are working with the video-data passing through cords mind-set PDP/PiDiP is a better choice.

I know Jamie is working on some PDP to Gem bridge stuff, maybe when that is ready you could combine the two and use PDP only for the pix_ stuff.

Also in gridflow the data is actually passing through cords... but I'm not sure what OS your running or if Gridflow is the best solution to your particular problem.

B.

Ian Smith-Heisters wrote:

...

Hi.

I'm trying to create a pix delay loop in GEM, but it doesn't work as expected.

[pix_video] | | [r loop] | | [pix_add] | [pix_delay 100] |
| [pix_gain] | | | [s loop] | [gemlist...]

It doesn't seem to do anything at all. I noticed that the [pix_add] help file has pix_ sources with their own gemheads. I tried throwing in [pix_separator]s all over the place, and that didn't help. Any tips or suggestions? I find the whole GEM dataflow a bit odd since it's all pointers (right?), and I'm used to PDP. Is there another way I can go about the same thing?

Thanks! -Ian

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list