...
I'm glad to hear that some of my suggestions have been incorporated. I designed the said array update sensing this way because the same method is used in Max/MSP.
I'm worried that, if an array gets updated multiple times at the same logical
time, there won't be any way to see the difference. Pd has a different way
of dealing with "change detection" in glists (the gl_valid field which is
a counter incremented everytime the thing changes in a specific way).
Parhaps it's wise to try to make a unified approach...
finally, audio latency from portaudio should be 5 msec or so better. I believe I'm getting about 20 msec through-delay on a MSWindoes machine using ASIO now. I haven't tested this in Mac yet. (of course, linux is still by far the best in this respect.)
20 msec is still not acceptable for use in live electronics. Do you think that <= 10 ms can be reached with the current architecture?
I _think_ there's nothing in either portaudio or ASIO that would prevent Pd from getting down to 5 msec latency or so (as people have managed on linux). There may be limitations somewhere else that I don't know about. There might also be something loose in the code somewhere. And it might be that, on Windows or some other OS, callback-based audio is inherently lower-latency than the poll-and-sleep loop Pd uses. (I thought for a while this was true on OSX but now I'm getting confusing results from it.)
I think this is where the remaining tested is needed in preparation for sewing up version 0.37.
cheers Miller
greetings, Thomas
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list