[chuck-users] chuck and midi clock (again), ignoreTypes() method

[Kassen]

On 19/12/2007, Stefan Blixt <stefan.blixt at gmail.com> wrote:
>
> 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't need other messages like stop/start or
> timecode.



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.

This means that our MidiIn would need to deal with that.

However, worse is if people *don'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.

What I'm getting to is that if we simply pass on clock ticks as bytes this
smoothing will have to be done in ChucK. It's possible but it'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.

Because of this I think it'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.

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's need it :¬).


My cents.
Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071219/aed5f412/attachment.htm