[GEM-dev] Timing and PD....

[Hans-Christoph Steiner]

I agree.  I think for any indeterminate operation, like anything in a  
separate thread, there should be a bang when that operation is  
complete.  That way you can guarantee that things are ready when you  
run a process.  If you want to make sure that things will be there on  
time, then these threaded/indeterminate operations should run well in  
advance.  Using guesswork and delays is not a real solution...

.hc

On Oct 30, 2008, at 4:25 AM, cyrille henry wrote:

> helo,
>
> i'm also having this kind of problem.
> specially when loading a picture in pix_image.
> i think the best would be the have a bang when things are ready...
>
> C
>
>
> B. Bogart a écrit :
>> Hey all,
>>
>> I'm having more and more problems with sync in PD. By sync I mean  
>> that
>> parts of my patches have processing delays that mess up timing. In
>> general I've been using buffers and delays to keep things working.
>>
>> This approach is not very scalable.
>>
>> I find myself using the "timer" object all the time to see if  
>> there is a
>> processing delay I have to worry about. That is in cases where  
>> there is
>> a bang saying an operation is done.
>>
>> Two examples I'm working on now (in Gem):
>>
>> First there is a delay between sending a message and the  
>> pix_buffer to
>> store, and then again for pix_buffer_read to read the pixels. The  
>> delay
>> is long enough that trigger does not work, there needs to be a  
>> delay to
>> make sure the image in the buffer is the right one. (sometimes as  
>> much
>> as 200ms)
>>
>> A second example is that I'm using pix_share and and second PD  
>> instance
>> to offload some CPU usage. Making sure the image sent to that PD
>> instance and the image received later in the chain is difficult.
>>
>> I'm not writing for specific advice, hence the generalities, but  
>> wanted
>> to start a discussion on the issue.
>>
>> What is the long-term solution for PD to solve these issues?  
>> Should all
>> objects that introduce a delay send a bang when they are complete?  
>> (for
>> example pix_buffer? Of course an additional delay occurs when when  
>> the
>> pix_buffer is written to memory and when it gets to the gfx card for
>> display.
>>
>> I'm banging my head over these issues a lot lately and wonder if  
>> there
>> is a better approach.
>>
>> Back to attempting kludging a solution.
>> .b.
>>
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev



------------------------------------------------------------------------ 
----

                   ¡El pueblo unido jamás será vencido!