[PD] GEM pix delay loop
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.
> 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?
>> 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.
>>> Ian Smith-Heisters wrote:
>>>> I'm trying to create a pix delay loop in GEM, but it doesn't work as
>>>> | [r loop]
>>>> | |
>>>> [pix_delay 100]
>>>> | [pix_gain]
>>>> | |
>>>> | [s loop]
>>>> It doesn't seem to do anything at all. I noticed that the [pix_add]
>>>> 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?
>>>> PD-list at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
More information about the Pd-list