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.
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@iem.at http://lists.puredata.info/listinfo/gem-dev
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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
¡El pueblo unido jamás será vencido!
Internally, objects like pix_image and pix_film set flags for whether an image is new or not. This tells other objects to update. Perhaps a generic object (pix_info ?) can output when that flag is set.
pix_share is a little different than image loading as it just dumps a new image into the gemlist each frame. It is not designed to do sync between instances of pd, but rather to be an asynchronous way to distribute processing. Making it sync would remove the performance gains.
On Thu, Oct 30, 2008 at 9:32 AM, Hans-Christoph Steiner hans@eds.orgwrote:
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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
¡El pueblo unido jamás será vencido!
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hey all,
I'll try and work on some test patches, right now I'm trying hard to get an installation ready, and these issues turned out to be a large stumbling block.
I suppose I'm doing lots of processing that may be unusual, like:
Grab an image from video device put the image in a buffer for each frame send the image in the buffer to a second buffer on each bang from a metro. pix_share the image in the second buffer send a bang to tell second pd instance to pix_dump. turn off the metro. pix_dump (640x480 GRAY) to ann_som in a second thread netreceive the winning BMU use that BMU as the index in which the image has saved in a third buffer. turn the metro back on.
I'm not thinking pix_share should do sync!! But I feel the need for some infrastructure better than trigger for complex timing problems like those I'm having.
I'm still debugging my patch, but adding a whole lot of arbitrary delays (150ms) are being used to get PD to wait a little bit before accessing the image in a buffer once it has been written.
Seems the safest way...
I remember Cyrille did mention needing to use these delays to make things work. I had to use them in parts of pixelTANGO also (when a message gets passed through many objects and many routes it takes time...)
As I have not noticed any render blocks with pix_buffer stuff, can I assume it uses a thread like pix_image and so on? I think a "done" bang would be really useful there.
I also had issues with things like pix_histo, where I would try and save the hist, but the hist had not changed for the new pix_buffer_read frame, just because the delay was slower than t b b delay.
Are cyrille and I the only ones seeing these kinds of issues?
Thanks for the comments. .b.
chris clepper wrote:
Internally, objects like pix_image and pix_film set flags for whether an image is new or not. This tells other objects to update. Perhaps a generic object (pix_info ?) can output when that flag is set.
pix_share is a little different than image loading as it just dumps a new image into the gemlist each frame. It is not designed to do sync between instances of pd, but rather to be an asynchronous way to distribute processing. Making it sync would remove the performance gains.
On Thu, Oct 30, 2008 at 9:32 AM, Hans-Christoph Steiner <hans@eds.org mailto:hans@eds.org> wrote:
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@iem.at <mailto:GEM-dev@iem.at> >> http://lists.puredata.info/listinfo/gem-dev >> > > > _______________________________________________ > GEM-dev mailing list > GEM-dev@iem.at <mailto:GEM-dev@iem.at> > http://lists.puredata.info/listinfo/gem-dev ------------------------------------------------------------------------ ---- ¡El pueblo unido jamás será vencido! _______________________________________________ GEM-dev mailing list GEM-dev@iem.at <mailto:GEM-dev@iem.at> http://lists.puredata.info/listinfo/gem-dev
hello all
i just ran into a similar problem. for the logic of some video players we used the end 'bang' of [pix_film] for triggering some other filmplayer. as soon, as the movie should be started again, we first set the frame number to 1 and then in zero logical time we started the according [gemhead] to start film playing / rendering of the gemchain. by doing this, [pix_film] sent the end bang, although we've set the frame number to 1 before. it took me some time to figure out, that this is probably related to what you're discussing here. after i added a delay between setting frame no to 1 and starting [gemhead], it worked well (no bogus end 'bang' from [pix_film]). don't know how this could be solved in an meaningful and understandable way. however, i think that having to use a [delay] is the worst imaginable case. in this particular case, we found a clean solution by setting the startframe number on filmend instead of filmstart.
a generic solution to achieve something like that within 'pseudo-zero' logical time would be good, i think. by 'pseud-zero' logical time i mean, that instead of waiting to the left bang of [t b b], one could wait on the 'ready' bang from the [pix_[film|image|etc]] object.
roman
On Thu, 2008-10-30 at 10:32 -0400, Hans-Christoph Steiner wrote:
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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
¡El pueblo unido jamás será vencido!
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hi ben
B. Bogart wrote:
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.
do you mean you are using buffers and delays to distribute the workload over time, in order to not get cpu peaks?
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)
i am not sure i understand you here. it seems like you are having problem to synchronize 2 threads (e.g. the main Pd thread an an image-loading thread). if everything is done in a single thread, then no timing problems should occur, as everything will happen in 0 logical time (though it might block the main thread considerably long so that the patch will "stutter"). if multiple threads are involved (e.g. to avoid the stuttering), then you might experience problems where you try to access images before they are actually loaded.
when using [pix_buffer] to load images with the [open $1( message, then afair, everything will be in a single thread. thus, no timing problems should occur. using [pix_image] to load images will default to using threads (if available), at least on linux. you can turn this off by sending a [thread 0( message to [pix_image].
it would be interesting to see examples that expose your problem.
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.
the solution is timestamps. (which i think [pix_share] doesn't have right now...)
I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue.
sorry to give specific answers.
fgmasdr IOhannes
-
B. Bogart -
chris clepper -
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Roman Haefeli