[PD] GEM pix delay loop

[B. Bogart]

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! ;)

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.

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??

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

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
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050321/822daca5/attachment.pgp>