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