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

[Miller Puckette]

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

cheers
M