<br><br><div><span class="gmail_quote">On 19/12/2007, <b class="gmail_sendername">Stefan Blixt</b> &lt;<a href="mailto:stefan.blixt@gmail.com">stefan.blixt@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I am also interested in this. I have tried to make a homebrewed MIDI clock to OSC in Java, but find it hard prevent the ChucK application (that receives my OSC messages) to lose sync if more MIDI messages than the clocks appear in the midi stream. It would be great to be able to receive 0xf8 in ChucK apps - I personally don&#39;t need other messages like stop/start or timecode.
</blockquote><div><br><br>Yes. I too have been after MIDI clock for a long time now but I think there are some big questions in *how* to implement it. MIDI Clocks in practice are often quite anoying; the actual clock message -according to the specs- is very high priority and can interrupt another message which will then continue after the clock byte.
<br><br>This means that our MidiIn would need to deal with that.<br><br>However, worse is if people *don&#39;t* implement MIDI clock that way which is sadly often the case (or so I heard). In that case any one specific clock pulse may be delayed by two MIDI bytes so if we would simply count the number of pulses since we started and act after a certain number has been reached (say to know when the next quart-note is) that quart note will jitter by as much as a single tick did. This is quite annoying so often manufacturers of gear and programs smooth it out and interpolate.
<br><br>What I&#39;m getting to is that if we simply pass on clock ticks as bytes this smoothing will have to be done in ChucK. It&#39;s possible but it&#39;s also quite tricky and may require a fair amount of code that runs at the speed of the ticks, so quite fast. That sort of thing is often a performance bottleneck in ChucK.
<br><br>Because of this I think it&#39;s worthy of consideration to make a separate MidiClockIn (and out?) class that would send events named after notes (and tick, possibly) and do the smoothing for us as well as provide start/stop and reset and take advantage of the higher degree of optimisation in C.
<br></div><br>Despite these questions I think clock would be a very good thing to have, jamming with groove-box users would be lots of fun as would using ChucK to supplement a traditional DAW, IMHO DAW&#39;s need it :¬).<br>
<br><br>My cents.<br>Yours,<br>Kas.<br></div>