On Oct 28, 2012, at 11:34 PM, Hans-Christoph Steiner wrote: > > 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.
This is a potential way to do it: http://tcl-mmap.sourceforge.net/ .hc _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
