> > 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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
