From CSWiki
< Talk:ChucK
Revision as of 08:39, 18 March 2008 by Kassen (talk | contribs)

Jump to: navigation, search

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
    • Very good, the we'll talk here and hope people will join us! (Kas)

Advance time until the I/O queue is cleared, by writing something like myIO => now;.

  • Would it make sense to use the same syntax here that's also used for the HID cue? With HID you use while( hi.recv( msg ) ){//parsing goes here} 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 while( hi.send( msg ) ){ms => now;}. 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 while (hi.recv(msg)) works for input device queues because this input is stored in memory, but when you are reading, say, a 10 MiB file from disk, it 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.
      • Yes, I see. Still, we have to face that it does take time, like sending MIDI takes time and right now there are no ways to link these things that will inherently take time to the way ChucK deals with things being defined as "taking time". There is nothing preventing me from telling ChucK to send tens of MIDI messages per ms or from telling ChucK to write a gigabyte to disk every second. I think these are similar in the sense that we might like to be able to define things to run as quickly as they can without going too fast and clogging the buffers. So far it seems that nobody is running into it but this could become a very real issue with MIDI as well... You are right that HD are slow... but MIDI is SLOOOOOOOOOOW as well so we could use a similar syntax there? I know you would like to focus on fileI/O here but it would be nice to treat similar issues with similar syntax.