Hi Miller,
the tenth test version of PD 0.37 is out. It looks pretty stable now.
great news!
I've finally stuck in Thomas Grill's new "quit" and thread-safety stuff. I haven't moved on his other edits (array update sensing, and something
else)
because I wasn't sure the right way to support them.
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.
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?
greetings, Thomas
...
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
Hi Miller,
...
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.
the idea is that an external that need update information stores the time that it has processed the array. Thus, by comparing this with the update time it will know when the array has changed, no matter how many times the latter has been updated in the meantime.
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).
Hmmm, i didn't know of that.... i'll look into it!
best greetings, Thomas
-
Miller Puckette -
Thomas Grill