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

[Hans-Christoph Steiner]

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