Difference between revisions of "Talk:ChucK/Dev/IO"

From CSWiki
Jump to: navigation, search
Line 2: Line 2:
 
*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
 
*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
  
::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.)
+
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.)

Revision as of 16:46, 17 March 2008

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 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.)