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

[Julien Canet]

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 <signal.automatique at gmail.com> wrote:
>
>
>
> 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.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>