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

[Jonathan Wilkes]

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