Fwd: [PD] GEM pix delay loop

vade doktorp at mac.com
Mon Mar 21 17:38:39 CET 2005


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 at mac.com>
> Date: March 21, 2005 11:25:57 AM EST
> To: "B. Bogart" <ben at 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 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: not available
Type: text/enriched
Size: 2378 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050321/d2057f77/attachment.bin>


More information about the Pd-list mailing list