hi miller, hi list...
In theory at least, the GUI process can handle large, atomic updates like redrawing an entire array without disrupting Pd; the main catch is that if Pd throws too many of these at the GUI then Pd itself can stall waiting for the GUI to catch up to it.
it's really good to hear, that you are working on that... there would be the possibility to add a thread on the pd side, that's sending the messages to the gui ... the pd process adds the messages to a queue, the helper thread sends the messages to the gui... more or less the same thing i did for the soundfiler ...
Then there's the question of how to draw very large (100,000+ points) arrays meaningfully without having to examine every single point. I'm leaning toward just doing a monte carlo hack for that: look at up to 10,000 points at pseudo-random somehow.
that _is_ an interesting approach ... but in order to make this threadsafe it would be possible to do this in a gui helper thread, too... i'd prefer loosing the syncronization between the gui and the dsp kernel to gain a click-free performance :-)
cheers ... tim