I have searched the list archives but not exactly found any answer to
this question. I'm running OSX with the 0.37.1 installer from Hans. I
have a patch which uses the xsample stuff to record real-time audio
coming in from the adc~, which records the data into an array.
Whenever the array display is redrawn (whether with an explicit [draw(
msg to xrecord~, or just automatically by xrecord when recording
stops), there is a noticeable pause/glitch any sound playback which is
going on. It seems that the source of the problem is the redraw on
screen of the array.
Is this a known issue with PD in general, or maybe just the particular version / OS / installer I'm using, or what? Any suggestions from anyone who has also seen this, or suggestions on how to track down / debug this problem?
I can send my patch if anyone thinks that would help....
Thanks much,
- David
Oh, and I'm using Tcl/Tk 8.5a0.
-dwd
On Jul 3, 2004, at 3:41 PM, david daniell wrote:
I have searched the list archives but not exactly found any answer to this question. I'm running OSX with the 0.37.1 installer from Hans.
I have a patch which uses the xsample stuff to record real-time audio coming in from the adc~, which records the data into an array.
Whenever the array display is redrawn (whether with an explicit [draw( msg to xrecord~, or just automatically by xrecord when recording stops), there is a noticeable pause/glitch any sound playback which is going on. It seems that the source of the problem is the redraw on screen of the array.Is this a known issue with PD in general, or maybe just the particular version / OS / installer I'm using, or what? Any suggestions from anyone who has also seen this, or suggestions on how to track down / debug this problem?
I can send my patch if anyone thinks that would help....
Thanks much,
- David
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
generally array drawing is very slow. i generally try to use the [table arrayname size] object, (which just hides the table in a subpatch) to avoid the drawing.
and if you are now thinking "hey, this radically reduces the usefulness of the pd gui!".. well.. yes, you would be right.
pix.
On Sat, Jul 03, 2004 at 04:02:40PM -0400, david daniell wrote:
Oh, and I'm using Tcl/Tk 8.5a0.
-dwd
On Jul 3, 2004, at 3:41 PM, david daniell wrote:
I have searched the list archives but not exactly found any answer to this question. I'm running OSX with the 0.37.1 installer from Hans.
I have a patch which uses the xsample stuff to record real-time audio coming in from the adc~, which records the data into an array.
Whenever the array display is redrawn (whether with an explicit [draw( msg to xrecord~, or just automatically by xrecord when recording stops), there is a noticeable pause/glitch any sound playback which is going on. It seems that the source of the problem is the redraw on screen of the array.Is this a known issue with PD in general, or maybe just the particular version / OS / installer I'm using, or what? Any suggestions from anyone who has also seen this, or suggestions on how to track down / debug this problem?
I can send my patch if anyone thinks that would help....
Thanks much,
- David
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, pix hat gesagt: // pix wrote:
generally array drawing is very slow. i generally try to use the [table arrayname size] object, (which just hides the table in a subpatch) to avoid the drawing.
and if you are now thinking "hey, this radically reduces the usefulness of the pd gui!".. well.. yes, you would be right.
You might want to try using plotted arrays, if you need to see the data all the time. Data structure plots are faster than the graph-arrays. See 7.stuff/data-structures/ for an introduction or the Help for a [plot] object. Some proper "level of detail" scaling would help, too.
Ciao
Frank Barknecht _ ______footils.org__
Is this a known issue with PD in general, or maybe just the particular version / OS / installer I'm using, or what? Any suggestions from anyone who has also seen this, or suggestions on how to track down / debug this problem?
it is a known issue that tcl / tk (re)draws cause glitches and problems
in audio performance.
audio processing and user interface should be less coupled. I think
there are at least two attempts now in this direction, but probably
they have not reached the public binaries yet.
by now, trying to aviod the redraws is the best you can do imho.
. g
I have searched the list archives but not exactly found any answer to this question. I'm running OSX with the 0.37.1 installer from Hans. I have a patch which uses the xsample stuff to record real-time audio coming in from the adc~, which records the data into an array.
Whenever the array display is redrawn (whether with an explicit [draw( msg to xrecord~, or just automatically by xrecord when recording stops), there is a noticeable pause/glitch any sound playback which is going on. It seems that the source of the problem is the redraw on screen of the array.
this is a quite known problem ... and the only workaround is, as pix mentioned, to hide the arrays in |table|s. the kernel/gui communication of pd has the problem that the gui socket is running in the same thread as the dsp, there is a patch for that on the cvs (devel_0_37 branch) that's using a low priority thread for the pd/gui communication (you would have to recompile pd yourself). i _have_ to run this to be able to run my graphic heavy patch without clicks. (it's also recommended to run in with -rt) but iirc guenther mentioned, that the gui communication is not the only problem of slow array redraws. since mathieu was working on the gui code on the impd branch, i'd like to know, if he was looking at that part of the gui code... btw, mathieu i haven't read anything about impd on the lists for some time... what's it's current state?
cheers ... tim
On Sun, 4 Jul 2004, Tim Blechmann wrote:
the kernel/gui communication of pd has the problem that the gui socket is running in the same thread as the dsp,
[...]
but iirc guenther mentioned, that the gui communication is not the only problem of slow array redraws.
Actually It's a matter of the client-server socket being flooded by array refresh data, and so the gui socket is blocking, as it is not set in nonblocking mode nor anything like it (SIGALRM timeouts, etc)
since mathieu was working on the gui code on the impd branch, i'd like to know, if he was looking at that part of the gui code...
I'm not there yet, but I
btw, mathieu i haven't read anything about impd on the lists for some time... what's it's current state?
I've not been working on IMPD for a while, as I've prepared 2 or 3 exhibitions and working on another one; plus, I'm adding new features to GridFlow, too, as you can see here:
http://artengine.ca/gridflow/gallery/spectrogram.gif
http://artengine.ca/gridflow/gallery/peephole3.png
(Those subwindows are very fast, but they are Linux-only; actually they only require that Pd uses a Tk that uses X11)
Mathieu Bouchard http://artengine.ca/matju
Ok so I understand why the redrawing of arrays is so slow.... it seems like there's no data reduction in the redraw process, so for instance if I have an array that's 10 seconds long @ 44100 hz, it runs through all 441,000 data points in the rendering of the array on-screen. So, of course there's a slow-down for that. But is there any way to impose some sort of data-reduction in the visual rendering of the arrays?
As an example, if I have 3 one-second arrays on screen being redrawn every 500 ms, there is no noticeable glitching etc - but for 3 10-second arrays, there's a very clear interruption in the audio-stream when the redraws occur. So perhaps there would be some way to modify the array-drawing code to skip samples in the drawing process and only the minimum required to display the data?
If nothing else, maybe this would be a suggestion for the GUI speed-improvements....
- dwd
yeah i had a hint that this was the problem when this problem seemed to appear many versions ago. theoretically you need to look at every point to accurately draw an array. imagine a 44100 point array with a single impulse being rendered as 100 pixels wide... with the most basic downsampling, the impulse would only show up if it was in one ofthe 441 locations that actually get rendered.
possibly a workaround is to have a phasor running a tabread over your longer sample and playing it into a smaller sample. then you can choose how much smoothing to do (atleast, by choosing tabread4, tabread, or one of the many options in xsample).
pix.
On Mon, Jul 05, 2004 at 11:16:06AM -0400, david daniell wrote:
Ok so I understand why the redrawing of arrays is so slow.... it seems like there's no data reduction in the redraw process, so for instance if I have an array that's 10 seconds long @ 44100 hz, it runs through all 441,000 data points in the rendering of the array on-screen. So, of course there's a slow-down for that. But is there any way to impose some sort of data-reduction in the visual rendering of the arrays?
As an example, if I have 3 one-second arrays on screen being redrawn every 500 ms, there is no noticeable glitching etc - but for 3 10-second arrays, there's a very clear interruption in the audio-stream when the redraws occur. So perhaps there would be some way to modify the array-drawing code to skip samples in the drawing process and only the minimum required to display the data?
If nothing else, maybe this would be a suggestion for the GUI speed-improvements....
- dwd
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Mon, 5 Jul 2004, david daniell wrote:
Ok so I understand why the redrawing of arrays is so slow.... it seems like there's no data reduction in the redraw process, so for instance if I have an array that's 10 seconds long @ 44100 hz, it runs through all 441,000 data points in the rendering of the array on-screen. So, of course there's a slow-down for that. But is there any way to impose some sort of data-reduction in the visual rendering of the arrays?
Well, I have reviewed most of that code (g_array.c), with the intent of reorganizing and/or partially rewriting later, but that was a few months ago.
I recall there's something that, beyond a certain array size (2000?) picks up only 300 values in the array for the redraw. So IMHO the problem is not there.
The biggest bandwidth problem from the array editor, is that when refreshing the array's waveform, it resends all of the viewable values. Even if that's limited to 300, if it's to be done several times a second, it sucks bandwidth like mad, especially if that's transmitted as a Tcl "line coords" command with no possible way for the Tcl side to decide how/if/when to redraw it.
What I want is: modified array data must be sent as a diff; Tcl side stores a data-reduced version of the array at all times (level of indirection) and/or shared memory is used (if possible); Tcl side renders when it wants to, based on received notifications of modifications; Tcl side gets several rendering options, instead of just one big "create line"; my intuition tells me that joining several "create line" might help with redraw speeds (?) ... well at least when array-editing.
So perhaps there would be some way to modify the array-drawing code to skip samples in the drawing process and only the minimum required to display the data?
The "2000" and "300" constants mentioned above should be automatically adjusting in a smarter way... and then manually adjustable a bit.
Mathieu Bouchard http://artengine.ca/matju
hi daniel, hi list...
As an example, if I have 3 one-second arrays on screen being redrawn every 500 ms, there is no noticeable glitching etc - but for 3 10-second arrays, there's a very clear interruption in the audio-stream when the redraws occur. So perhaps there would be some way to modify the array-drawing code to skip samples in the drawing process and only the minimum required to display the data?
there should be no problem to find an apropriate algorithm to improve the array drawing... but someone would have to do it ... therefor it would be needed to set up a todo list and to assign certain tasks to certain developers ...
as hcs wrote a short time ago, pd development is kind of "coordinated
disorganization"...
there are some of these "nearly-bugs" in pd that should be solved (and not only by a workaround) ... probably it would be useful to install and use a bugtracker system (maybe the bugtracker on sourceforge), but it would have to be _used_ to be useful...
cheers... tim
Well, this is probably the largest item on my "dolist" -- but it's bigger than just arrays: in general, some kind of flow control mechanism is needed to protect against Pd flooding the GUI with updates.
In theory at least, the GUI process can handle large, atomic updates like redrawing an entire array without disrupting Pd; the main catch is that if Pd throws too many of these at the GUI then Pd itself can stall waiting for the GUI to catch up to it.
Then there's the question of how to draw very large (100,000+ points) arrays meaningfully without having to examine every single point. I'm leaning toward just doing a monte carlo hack for that: look at up to 10,000 points at pseudo-random somehow.
cheers Miller
On Mon, Jul 05, 2004 at 08:17:29PM +0200, Tim Blechmann wrote:
hi daniel, hi list...
As an example, if I have 3 one-second arrays on screen being redrawn every 500 ms, there is no noticeable glitching etc - but for 3 10-second arrays, there's a very clear interruption in the audio-stream when the redraws occur. So perhaps there would be some way to modify the array-drawing code to skip samples in the drawing process and only the minimum required to display the data?
there should be no problem to find an apropriate algorithm to improve the array drawing... but someone would have to do it ... therefor it would be needed to set up a todo list and to assign certain tasks to certain developers ...
as hcs wrote a short time ago, pd development is kind of "coordinated
disorganization"...there are some of these "nearly-bugs" in pd that should be solved (and not only by a workaround) ... probably it would be useful to install and use a bugtracker system (maybe the bugtracker on sourceforge), but it would have to be _used_ to be useful...
cheers... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Well after realizing it wasn't some core problem with my version of pd or tcl or my OS, I implemented a suitable workaround for the problem of displaying large arrays on-screen without having to pump tons of data to the GUI. Basically it's just a data reduction that every so often reads from the (invisible) source array and writes 0.1% of the data (interpolated) to the (visible) destination array. I've attached the PD patch (an excerpt from a larger app, but I think I've commented it enough to see how it should be used.
Can anyone think of a more efficient way to do this sort of workaround in PD without hacking C code?
- David
hi miller, hi list...
In theory at least, the GUI process can handle large, atomic updates like redrawing an entire array without disrupting Pd; the main catch is that if Pd throws too many of these at the GUI then Pd itself can stall waiting for the GUI to catch up to it.
it's really good to hear, that you are working on that... there would be the possibility to add a thread on the pd side, that's sending the messages to the gui ... the pd process adds the messages to a queue, the helper thread sends the messages to the gui... more or less the same thing i did for the soundfiler ...
Then there's the question of how to draw very large (100,000+ points) arrays meaningfully without having to examine every single point. I'm leaning toward just doing a monte carlo hack for that: look at up to 10,000 points at pseudo-random somehow.
that _is_ an interesting approach ... but in order to make this threadsafe it would be possible to do this in a gui helper thread, too... i'd prefer loosing the syncronization between the gui and the dsp kernel to gain a click-free performance :-)
cheers ... tim
-
0001 -
david daniell -
Frank Barknecht -
Mathieu Bouchard -
Miller Puckette -
pix -
Tim Blechmann