Hi,
Thanks for your interest on the subject and your answers.
Now with Kassen explanations I have an idea why it is not implemented
("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"...losing sync etc).
But to my mind, we should allow ignoreTypes() to be accessible in
ChucK language. By default we should leave the default values so that
the clock messages are not parsed, but only if the user choose to
handle them he would be able to call ignoreTypes() and change the
booleans to have midi clock messages parsed.
Adding the ignoreTypes method to chuck language should be transparent
to users and existing scripts, only if you call it ChucK behaviour
will change.
In my case, my chuck scripts do only MIDI + OSC : I receive OSC
messages, send OSC messages + MIDI messages (+ now I've tested
receiving midi clock). I do not have a high CPU usage in chuck. And
with my test I think I keep the MIDI sync.
I guess I have to modify the lex + yacc parser to add
MidIn::ignoreTypes recognition in ChucK language.
I also love the idea of
"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. "
But I think it is better but harder to implement (at least too hard for me...).
I would like to try (I say try because I am not deep into ChucK code)
to modify chuck to accept midiIn.ignoreTypes; if I succeed, I will
post my changes in code to see if it is agree to commit them.
Who is still developing on ChucK code?
Best regards,
Julien
On Dec 19, 2007 5:23 PM, Kassen
On 19/12/2007, Stefan Blixt
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.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users