[PD] GUI and DSP

[Jonathan Wilkes]

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

> From: Ivica Ico Bukvic <ico at vt.edu>
> To: Mathieu Bouchard <matju at artengine.ca>; Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "pd-list at iem.at List" <pd-list at iem.at>
> Sent: Wednesday, February 8, 2012 3:33 PM
> Subject: Re: [PD] GUI and DSP
> 
> 
> 
> Mathieu Bouchard <matju at artengine.ca> wrote:
> 
>> Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit :
>> 
>>>  While technically correct that's misleading because there's a 
> lot of 
>>>  stuff happening on the 'pd' side that a reasonable person would
>> assume 
>>>  to be handled on the 'pd-gui' side.  Well, more than that-- 
> there's 
>>>  stuff happening on the 'pd' side that doesn't need to 
> happen at all,
>> but 
>>>  it can use massive amounts of CPU and consequently a reasonable
>> person 
>>>  gets dropouts when moving an array that has only 100 points visible
>> and 
>>>  erroneously thinks, "Wow, I get dropouts just moving some polygons 
> 
>>>  around on the screen? Tk stinks!"
> 
> Or you could simply use pd-l2ork and a move arrays and other complex graphical 
> user interface objects using tags and never worry about that problem again.

But even in pd l2ork, if you have a million element array with 100 elements showing, 
every time you click-drag a point in the array 'pd' recalculates the relationship between 
points/elements for the _entire_ array, right?  At least that's what the code in g_array.c 
looked like it was doing when I last looked at it.

If I understand it correctly, the 'pd-gui' waits for that c code to loop through the entire array before 
it updates-- thus if you swoop the mouse through the entire array it may look like a 
sluggish redrawing on Tk's part when actually it's redrawing just fine once it gets the 
new coords, which takes time (and can cause dropouts).

That's a purposely exaggerated example, as it doesn't make a lot of sense to draw a 
100-point garray that represents a 1000000-element array.  But it makes me wonder 
whether the "strobing" effect you get with a ds-array that has a lot of elements 
happens because of similar heavy processing on the c side of things.

Has anyone tried to make a big polygon with lots of moving parts purely in tcl/tk and 
measured the cpu?  Might help to see Tk's limits separated out from pd.

-Jonathan

> 
> 
>> Besides, you could save some cpu, ram and bandwidth if all those array 
>> floats were hex-encoded instead of dec-encoded. Don't use "%g" 
> nor "%d"
>> 
>> when you can use "%x" and similar... especially fixed-width %x 
> such as 
>> "%04x".
>> 
>> If Tcl had fast base64 support (like Perl/Ruby), the difference would
>> be 
>> even bigger. And it would bigger with the ability to send binary data 
>> (which can't happen now because "}" counts as end-of-block).
>> 
>>  ______________________________________________________________________
>> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal,
>> QC_______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
> 
> 
> Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound & Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Assistant Director, CCTAD
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
>