[PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
Miller Puckette
msp at ucsd.edu
Sun Oct 28 21:10:29 CET 2012
>
> 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
More information about the Pd-dev
mailing list