Hi,
Thanks for your interest on the subject and your answers.
I think a lot of people would be interested in this, it would help a lot in integrating ChucK with other (consumer) programs and tools.
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).
I don't think this will lead to lost sync, in fact if it is implemented according to those specs it should be easier to keep sync. What it does need is a sort of small stack to keep yet unfinished messages. Let me explain by pretending to be a MIDI module.
I receive the first byte of a note on message, it says it's a note on channel 3.
I receive a clock tick.
Now I have to put the note-on byte on my stack
and process the tick
put the note-on back where it was.
I receive the note number (C4)
I receive the velocity (107)
Now I have all three bytes to construct a note on
I process it.
No sync is lost but it's definitely a bit more complicated then only taking note and cc messages and sending off a block of three bytes every time we have a complete one.
One of the advantages of the current -simple- MIDI implementation is that we never have to figure out how many bytes there are in the input signal as it's always 3, this makes it easy to use and protects us from how arbitrary and flat out weird MIDI can be.
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.
You don't? Well, maybe I'm just a bit paranoid about high-speed loops. How much processing are you applying to the clock? Just figuring out where the quarter notes are or something more complicated?
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...).
Oh, the C part would definitely be more complicated in that scenario but OTOH it would save complexity at the ChucK-side. I'm suggesting this because a larger ChucK program that would be synced to MIDI and base the amount of time it advances in various shreds on it might run into sync and internal synchronisation issues if there would be a lot of jitter. Perhaps we could work around that by basing it all on events generated by a shred that parses the clock, I never tried that as I never had clock :¬)
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?
Mainly Ge, I think? It seems like he has been very busy since moving; I haven't heard from him in a while. It'd also be good to merge the ASIO stuff into the main Win release, now that we know it works and is stable, I haven't heard a single complaint about that one.
Looks to me like your investigation is very worthwhile, I'd love to hear how using clock in ChucK works out for you in practice. Has anybody ever tried if we can already use clock-out by ending the message with dummy bytes like we can with program-change? I seem to remember there was a issue there too yet I'm quite interested in that functionality as well.
Yours,
Kas.