----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; Lorenzo Sutton lorenzofsutton@gmail.com; "pd-dev@iem.at" pd-dev@iem.at Sent: Sunday, October 28, 2012 4:10 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
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.
And how do I set the right size for the array?
-Jonathan
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
cheers M