[PD] why does PD round numbers? (in tables, in messageboxes, etc)

Jonathan Wilkes jancsika at yahoo.com
Tue Apr 10 21:41:36 CEST 2012

----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Miller Puckette <msp at ucsd.edu>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Tuesday, April 10, 2012 2:43 PM
> Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
> 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.

Pd already does iterate through the array.  As I wrote, that's the source of the 
sluggishness users experience when they move one that has more than a couple 
hundred elements in anything other than pd-l2ork.

It might be worthwhile to look at Audacity, but then again I don't think those devs 
would be optimizing the code for the kind of realtime user interaction we deal with 
in Pd.  I mean, one isn't going to record a track while at the same time drawing a 
waveform on another area of the screen, are they?

Garrays really cover a lot of user interface ground, which is a problem when you 
want to optimize any of their behavior.  On the one hand, maybe it would be nice 
to accumulate element changes on the tcl side and only send them when the 
mouse button comes up (kind of like Max's [mousefilter]), but that would be to the 
detriment of the realtime response when that array is used in a signal object (as 
garrays are in many of the audio tutorials).  Similarly, it would be a _vast_ improvement 
if array elements could jump-on-click, as so many people use them as a kind of poor man's 
Max-style multi-slider.  But then graphs can hold multiple arrays...

In a way a garray is the most Max-like object in Pd, in that it is a monolithic 
multi-featured object that tries to cover as many use cases as it can at the expense of 
not being very extensible (I think of [coll], that lcd object, multislider, etc.).  I guess the 
opposite would be something like the set of data structure objects, each of which have 
clear/simple functions which can be combined to do very powerful things with data and 
visualizations of it.  But I suppose a measure of their power is whether or not they can 
be used to both replace and extend garrays; they cannot, and I haven't been able to 
think of any future additions to them that would make this possible.


> .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).

I was responding to the point you made directly before what I wrote.  That's called 
"inlinereplying", and it is suggested in this FAQ:

That is linked from the Pure Data Netiquette guide at:


More information about the Pd-list mailing list