[PD] GEM pix delay loop

Ian Smith-Heisters heisters at 0x09.com
Mon Mar 21 20:01:47 CET 2005

B. Bogart wrote:
> Ah.. I wish there were enough windows developers to help with the
> windows stuff!!! I wonder what the stats are for what OSs people use PD
> on. I get the feeling it has an inverse relationship to what the
> developers are using! ;)

Usually I use and love Linux + PDP, but when the computer isn't mine... 
I guess what I need to do here is not try to use GEM as a substitute for 
PDP and give in to its paradigm.

> What are you actually doing with the add and multiply? for a test you
> could try using pix_data to create a pd message of the image, and then
> dumping that as a message back into the chain above.

What I'd like to do is apply successive blurs and pix_curves at a slight 
delay, so the effect would be a very slow-to-fade motion blur with color 
difference over time. In general, I use delay loops a lot to apply 
temporal layering effects of all sorts.

I don't see how [pix_data] could be of help here, from the help file: 
"[pix_data] will get the colour of a specified pixel within an image 
when triggered." Unless I used... 307,200 [pix_data]s to totally 
reconstruct the image ;)

Is this sort of what pix_buf is supposed to be for? I can't get it to do 
anything, and the help file isn't exactly clear to me: "All images use a 
pull system, so as long as nothing is modified in the pix "upstream", 
the pix_buf is still valid."

> I've done very little with pix_ stuff in Gem, since I'd not consider it
> the strength of Gem... so maybe some other Gem pix_ gurus have some ideas??

I suppose not. Perhaps there are some snazzy, similar things I could do 
with OpenGL. Do you have any tricks for using video input as an input to 
GEM's OpenGL? I could see a similar effect being accomplished with 
semi-transparent objects laid over one another, but how could I use pix_ 
information to effect the shape of an OpenGL object?

> could you do something using multiple gem-chains? perhaps using
> pix_separator and/or the pix buffer stuff.

I thought of that, but a [pix_video] object can only exist in one 
gemlist per camera.

Thanks for the tips.

> B.
> Ian Smith-Heisters wrote:
>> Well I guess PDP would be the preferred way to do this, but AFAIK no one
>> has compiled it for Windows, which, by unfortunate necessity, is what I
>> need to write this for.
>> Any way to apply a recursive filter with a delay would be good. I just
>> tried using [repeat], since looping is basically a kind of recursion,
>> but no luck since I couldn't incrementally delay them.
>> Really all I need is to be able to copy the dereferenced pointer once,
>> apply effects to it, and add that back to the original. Doing that
>> recursively would be just what I need. I thought that's what a
>> [pix_separator] would do.
>> Any thoughts?
>> -ian
>> 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 at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list

More information about the Pd-list mailing list