<br><br><div><span class="gmail_quote">On 4/21/06, <b class="gmail_sendername">Perry R Cook</b> <<a href="mailto:prc@cs.princeton.edu">prc@cs.princeton.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>In the original MIDI, clock was just a one byte<br>message that subdivided musical time into either<br>12ths of 24ths of quarter notes. That, combined<br>with MIDI start and stop, allowed drum machines to<br>talk to each other and sequencers, etc. It should
<br>be easy to implement this using our standard MIDI<br>and event framework:</blockquote><div><br><br>Sure, that would work for me. Wait for one of those messages, store "now", wait for the next, store the new now. Substract those two, chuck the result to "dur click" and my example code would run already, in essense. We could average them out depending on wether long-term smoothness or a fast reaction to clock modulations would be preferable. It's simple, it's consistent and syncing to drum machines will open the way for lots of jokes about "crash cymbals". I like it.
<br><br>One thing that has me a little woried is that currently incoming MIDI messages can be depended on to be three bytes. Clock messages aren't so if we are going to have this then from then on sorting MIDI notes and cc's will need to be done starting with the first byte because otherwise trying to build conditions on what
msg.data2 or msg.data3 are is going to cause trouble since they won't be there. This might break existing code. Not the end of the world and your idea is certainly both more simple and more consistend then my own proposal.
<br></div><br></div><br>Yours,<br>Kas.<br>