chuck and midi clock (again), ignoreTypes() method

Julien Canet

17 Dec 2007 17 Dec '07

1:20 p.m.

Dear All, I am learning chuck and I've made some scripts for the monome 40h interface (if someone wants I can post them). I really need to sync my script with another software, using MIDI. I saw on the users mailing list ( https://lists.cs.princeton.edu/pipermail/chuck-users/2006-April/000503.html ) that midi sync wasn't possible. I didn't really understood why at first, because I thought we just have to make a midi input handler that waits for MIDI clock messages, just like the example in the message : 0 => int device; // number of the device to open (see: chuck --probe) MidiIn min; // the midi event MidiMsg msg; // the message for retrieving data if( !min.open( device ) ) me.exit(); // open the device spork ~ handleMIDI(); fun void handleMIDI() { while (1) { min => now; // wait on the event 'min' while( min.recv(msg) ) // get the message(s) { if (msg.data1 == 248) { // MIDI Clock // Do clocky stuff, count to 24, determine delta-now, whatever } } } } So I wrote a little loop waiting for midi clock message, similar to the script above. I never received midi clock messages... (I am sure they are sent using a MIDI monitor). I read on chuck forum that MIDI clock messages were not parsed. So I had a quick look into Chuck source code and try to found why. I said quick look because I do not understand the whole code to 100%, I've just tried to find more about these MIDI clock messages. I saw that in the midiInputCallback, the midi time code and tick messages (and some other midi messages) are ignored depending on some RtMidiInData flags : the ignoreFlags, initialized to true (ignoreFlags set to 7 in fact) in the constructor. If these flags are true, the size of the message is set to 0 and it is ignored. I saw that there is a method called RTMidiIn::ignoreTypes that can changes these flags. But my BIG question : how to access this ignoreTypes method in chuck language? I recompiled chuck with ignoreFlags initialized to 0. And now I received them... So what is the problem with the midi clock messages? Why disabling them? Can the end-user re enable them without recompiling? Thanks and congratulations for chuck, this is really wonderful, Best regards, Julien.

Show replies by date

Stefan Blixt

19 Dec 19 Dec

10:02 a.m.

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. /Stefan On Dec 17, 2007 7:20 PM, Julien Canet wrote:

...

Dear All,

I am learning chuck and I've made some scripts for the monome 40h interface (if someone wants I can post them). I really need to sync my script with another software, using MIDI. I saw on the users mailing list (

https://lists.cs.princeton.edu/pipermail/chuck-users/2006-April/000503.html ) that midi sync wasn't possible. I didn't really understood why at first, because I thought we just have to make a midi input handler that waits for MIDI clock messages, just like the example in the message :

0 => int device; // number of the device to open (see: chuck --probe) MidiIn min; // the midi event MidiMsg msg; // the message for retrieving data if( !min.open( device ) ) me.exit(); // open the device

spork ~ handleMIDI();

fun void handleMIDI() {

while (1) { min => now; // wait on the event 'min' while( min.recv(msg) ) // get the message(s) { if (msg.data1 == 248) { // MIDI Clock // Do clocky stuff, count to 24, determine delta-now, whatever } } } }

So I wrote a little loop waiting for midi clock message, similar to the script above. I never received midi clock messages... (I am sure they are sent using a MIDI monitor). I read on chuck forum that MIDI clock messages were not parsed.

So I had a quick look into Chuck source code and try to found why. I said quick look because I do not understand the whole code to 100%, I've just tried to find more about these MIDI clock messages. I saw that in the midiInputCallback, the midi time code and tick messages (and some other midi messages) are ignored depending on some RtMidiInData flags : the ignoreFlags, initialized to true (ignoreFlags set to 7 in fact) in the constructor.

If these flags are true, the size of the message is set to 0 and it is ignored.

I saw that there is a method called RTMidiIn::ignoreTypes that can changes these flags.

But my BIG question : how to access this ignoreTypes method in chuck language?

I recompiled chuck with ignoreFlags initialized to 0. And now I received them...

So what is the problem with the midi clock messages? Why disabling them?

Can the end-user re enable them without recompiling?

Thanks and congratulations for chuck, this is really wonderful,

Best regards,

Julien. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Read Marx and Lenin, it will really turn you loose!

Kassen

11:23 a.m.

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.

Julien Canet

21 Dec 21 Dec

2:52 a.m.

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 wrote:

...

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

Kassen

11:05 a.m.

On 21/12/2007, Julien Canet 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.

6215

Age (days ago)

6219

Last active (days ago)

List overview

Download

4 comments

3 participants

participants (3)

Julien Canet
Kassen
Stefan Blixt