[PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array

[Jonathan Wilkes]

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

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Miller Puckette <msp at ucsd.edu>
> Cc: Jonathan Wilkes <jancsika at yahoo.com>; Lorenzo Sutton <lorenzofsutton at gmail.com>; "pd-dev at iem.at" <pd-dev at iem.at>
> Sent: Sunday, October 28, 2012 11:34 PM
> Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
> 
> 
> On Oct 28, 2012, at 4:10 PM, Miller Puckette wrote:
> 
>>> 
>>>  Why not use the same throttling mechanism Miller put for data 
> structures
>>>  for iemguis and see if it's suitable?
>>> 
>>>  I think what you'll find is that this is a complex problem, and you 
> certainly
>>>  won't get a consensus that "just make the gui get out of the 
> way for the sound"
>>>  is the right approach.  In fact for anything that is handling user 
> input through
>>>  the GUI you'd better make sure the GUI responds when it's 
> supposed to, 
>>>  otherwise it _will_ appear to be broken from the standpoint of the 
> user.  Just
>>>  look at the history of video games-- game developers are willing to 
> remove
>>>  entire voices at will in the audio in order to keep the interface from 
> becoming
>>>  sluggish.  You might say this is just the visual bias in our culture, 
> but the more
>>>  significant factor is that a light switch that reacts to the force from 
> your finger
>>>  one second after you flip it is no longer a switch-- it's a 
> physical anomaly.
>>> 
>>>  Anyway, I think the problem is often on the c side instead of the tk
>>>  side.  If you load a 20sec sample into an array while dsp is on and 
>>>  soundfiler isn't threaded, what do you really expect to happen?[1]
>>> 
>>>  -Jonathan
>>> 
>>>  [1]  Hm... rather than threaded... what if you could set a flag that 
> tells
>>>  [soundfiler] the maximum amount of the soundfile to process every 
> block?
>>>  Or maybe have an object called [soundfiler~], where you can give it an 
> arg
>>>  to set the number of samples to be loaded every block?
>>> 
>>  That's what readsf~ does... just dump the output into a tabwrite~ and 
> you're
>>  got it.
>> 
>>  But the question of how to smoothly update table graphics without messing 
> up
>>  real-time behavior is still wode open.
> 
> Ideally there would be some way of sharing the table memory with the GUI 
> process.  Then the GUI process would just read that table using the clock of the 
> screen refresh, at something like 60Hz, and handling the drawing itself.  Then 
> the DSP code could be totally ignorant of the drawing.  That would also make it 
> easy to set the DSP processing priority higher than the redrawing priority.
> 
> .hc

I'm about to add a ttk::progressbar to my search plugin and maybe this
kludge relates somehow to the array not updating in the GUI:

http://wiki.tcl.tk/946

Looks like the hack here is that you build your own recursive event loop so that you
can set the clock as needed for the GUI animation junk.  For the progress bar,
I'm just thinking about dividing the total number of files to be searched by 8, search
the files in each chunk asap, and throttle in between each chunk enough to draw the next
section of the progress bar.  That way I'm only adding 8 * throttle period to the total
search time which should be insignificant.  (It only takes 3-4 seconds to do a single-word
search through all the pd-extended docs/libs.)

The part that might relate to array-redrawing is that if I didn't use this kludge and
instead had a foreach loop, I'd be guaranteed that the progress bar would only redraw
_after_ the entire search process was finished.  I'm guessing that's exactly what's happening
with the array-- you're hitting a wall where you're sending so many damn drawing instructions
to tk that it no longer has any idle time to draw anything.

For example-- notice that when you turn off the metro tk finally decides it's time to draw
something.

I have a hard time believing modern gui toolkits would end up forcing workarounds like that,
even in light of how terribly inefficient Pd is about sending loads of data back and forth.  Does
Qt give the dev tools to refresh the screen then spend a page and a half in the wiki guiding
users never to use it because it's buggy (like [update] )?

-Jonathan