Yes, you'd have to iterate. I'm sure there are algorithms for this kind of thing that are better, like in programs like Audacity. Those would be the ones to use.
.hc
(by the way, bottom-posting on a top-posted thread is bad form, IMHO. Whether you hate either top or bottom posting, I think its clear that its bad to mix).
On Apr 10, 2012, at 2:40 PM, Jonathan Wilkes wrote:
----- Original Message -----
How do you calculate the median/mean without iterating through the array?
-Jonathan
From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-list@iem.at Sent: Tuesday, April 10, 2012 1:38 PM Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
Makes sense to me. Each individual point can have its own coords, fill, color, tags, etc. while a polygon just has one set of all those for the whole thing.
This whole discussion makes me think that arrays should be available to the GUI via shared memory. Then the 'pd' side can freely update things on its own clock, while 'pd-gui' can update things using its own clock (much slower, like 60hz) and also its own resolution. For example, if a 400 million point array is drawn in a 400 pixel wide box, then the GUI can just read every 100,000th value in the array. Or for more accuracy, take the median of those 100,000 points, or mean for perhaps more accuracy. That should drastically speed up array drawing.
.hc
On Apr 10, 2012, at 1:31 PM, Miller Puckette wrote:
Hi all -
It's a wierd thing abut TK that drawing polygons is far more efficient than drawing arrays of points; "polygons" are primitive objects
that
are apparently optimized internally to TK whereas arrays of points have to be drawn one by one (TK thinks they're each a separate object).
cheers Miller
On Tue, Apr 10, 2012 at 07:24:31PM +0200, katja wrote:
Thanks for your tips, Jonathan. Anyway, while you were writing the mail I was already doing a test patch where update times of a 32 million samples array and table are tested, see attached.
I ran the test with Pd-extended 0.43.1 and Pd-double on OSX. For an array with that length, update takes ~3 seconds. For a table displayed graphically, ~3.1 seconds. Surprisingly, drawing as points (instead of polygon) takes almost 5 seconds. The deviation between repeated measurements, a few dozen milliseconds, was about as large as the difference between Pd-extended and Pd-double. I've verified that double precision numbers are indeed displayed with a maximum of 14 significant digits in Pd-double.
I also checked the time for writing 32 million samples to a table without graphical display. This took ~170 milliseconds for Pd-extended and ~ 220 milliseconds for Pd-double.
Later I'll do another test where transmission over network is more specifically tested.
Katja
On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes
jancsika@yahoo.com wrote:
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Tuesday, April 10, 2012 9:45 AM Subject: Re: [PD] why does PD round numbers? (in tables, in
messageboxes, etc)
2012/4/10 IOhannes m zmölnig zmoelnig@iem.at: > On 04/10/12 10:33, katja wrote:
> i was talking about pd/pd-gui communication (and keep the
number format for
> both saving and pd/gui communication the same). > when displaying/updating a table every single number is
converted to text
> using printf, send over the wire and then converted back
to a number for
> drawing the table. > it makes a difference if you have to transmit 44100 > *4 bytes or 44100*12 bytes.
Ah I see. It is not uncommon to display complete audio files,
much
more than 44100 samples.
I've never seen a patch that _displays_ all the data for an
array that large. To
transmit 44,100 drawing instructions you need a _canvas_ size of
"44100" and
if anyone has actually needed to do that in a patch I'd really
like to see it.
So all these samples are converted to text and back to numbers, as they go over the network?
No. See plot_vis inside g_template.c. There is not a 1-to-1
correspondence between
# of array elements and rectangles/polygon-coords on the tk canvas
(at least for
garrays, not sure about data structures). If you create a 44100
element array
and make the "size" field in that arrays canvas dialog
"2", Pd will only send
data to the gui for those 2 pixels, not for the entire array.
However, it will loop
through the entire array on the c side _every_ time plot_vis is
called, in order to
figure out what info should be sent to the gui.
For example: running with -d 3, create an array with 10,000,000
elements.
Now make the "size" field in its canvas dialog
"2".
Select the array. Click an array key to move it. Notice the lag, but also notice Pd is only sending two commands to
the gui to
draw the elements. It's because Pd must loop through 5,000,000 elements before it
hits the next pixel
where it needs to send another drawing instruction to the gui!
(While in the end, only a couple hundred values are displayed). And every
character goes
through the loop in binbuf_text() with all it's cases...
well that is
a bottleneck which should not be further aggravated. At least this performance issue can be quickly tested, using Pd vs Pd-double.
I'll
make a test patch for that.
Keep in mind that you're using a horribly implemented feature
of Pd to do your
test-- that is, if you're using garrays. For example, moving
an array shouldn't
send _any_ element data to the gui. It doesn't in Pd-l2ork
because it just moves
everything by tag, using one line of tk, thus there is no
bottleneck in that case.
A practical test I can think of to compare 4byte vs 12byte payload
is
something like [metro 100]--[tabwrite~] animation for a visible
garray. I'd be
curious to know if there is a significant performance difference
there.
-Jonathan
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.