Talk:ChucK/Dev/IO

From CSWiki
< Talk:ChucK
Revision as of 06:27, 22 March 2008 by Kassen (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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.
        • I see, so you propose a similar asynchronously-queued API for MIDI? Sounds interesting to me, although my opinion doesn't count for much here since I don't really know anything about MIDI. To give you some context, I am implementing the file I/O as part of a one-semester independent work project. I guess a reexamination of the MIDI API can go on ChucK's (rather lengthy) to-do list as well?
          • Well, to trade context for context; my opinion is based on writing in ChucK rather often and finding consistent syntax a lot easier to remember and deal with :¬). Ge might be the one who has to make calls here. I have long advocated that MIDI needs a cleanup, compared to HID it's interface is really quite primitive at the moment and I feel that similar things should have a similar syntax. I think a new MIDI syntax could borrow from the HID one and likely borrow from your ideas here to indicate space in the outgoing cue. These matters of how a computer (as hardware) has lots of timing-related aspects and ChucK has it's own "synthetic timing" (and the two have potential interactions) will likely pop up a few more times regardless of what is done now but it can't hurt to try to establish a way of dealing with them. I think your ideas on this page are a excellent first step in addressing these questions. As far as I can see now there are no real issues with your design and I like this usage of events, we'll see how it works out in practice. Personally I think the todo-list is wonderful. Countries have their constitution, religions have their holy books and ChucKian culture has a todo-list. Gives one something to hold on to ;¬).