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

[cyrille henry]

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
>