View source for Talk:ChucK/Dev/IO

Aschran, please excuse me if it was inappropriate for me to comment on your process. My reasoning was that using a WiKi page is public but I realize it's not linked to (yet?). Yours, Kassen.
*No worries, I appreciate the input. The article page itself is meant to be a working copy of the API spec only and not to hold comments, so I copied your input to the discussion page. Thanks! Andrew

Advance time until the I/O queue is cleared, by writing something like <code>myIO => now;</code>.
*Would it make sense to use the same syntax here that's also used for the HID cue? With HID you use <code>  while( hi.recv( msg ) ){//parsing goes here}</code> to make sure all messages in the cue get processed before we go on to the next event. I could imagine dealing with a out-going cue using something like <code>  while( hi.send( msg ) ){ms => now;}</code>. Actually this would make sense for MIDI as well. There is currently nothing preventing you from writing ChucK code that attempts to send MIDI much faster then the protocol could possibly handle... which could lead to issues. I realize all of these are equivalent in functionality, I'm commenting in the interest of consistency. I could also imagine some of your ideas could be applied to HID/MIDI/etc as well.(Kas.)
**This syntax might not be appropriate in this case, because the point of I/O asynchrony is to avoid disruption to real-time audio output. Code like <code>while (hi.recv(msg))</code> works for input device queues because this input is stored in memory, but when you are reading, say, a 10 MiB file from disk, this is orders of magnitude slower. If you have code like io.write(file) operate in-line, then every shred in the VM could potentially be held up waiting for the disk operation to finish.