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

[Kassen]

On 21/12/2007, Julien Canet <jools at free.fr> wrote:
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071221/787f91ad/attachment.htm