----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: Jonathan Wilkes jancsika@yahoo.com; Lorenzo Sutton lorenzofsutton@gmail.com; "pd-dev@iem.at" pd-dev@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:
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