[PD] why does PD round numbers? (in tables, in messageboxes, etc)
Jonathan Wilkes
jancsika at yahoo.com
Tue Apr 10 20:40:01 CEST 2012
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Miller Puckette <msp at ucsd.edu>
> Cc: pd-list at 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.
How do you calculate the median/mean without iterating through the array?
-Jonathan
>
> .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 at yahoo.com> wrote:
>>>> ----- Original Message -----
>>>>
>>>>> From: katja <katjavetter at gmail.com>
>>>>> To: pd-list at 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 at 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 at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>
>>>>
>>
>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> _______________________________________________
>> Pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list