Ge;
Indeed there is no underlying functionality to interpret a MIDI clock at the current time. If we can work it cleanly into the timing framework it would certainly be worth having. It is now on the TODO list.
Yeah, the "cleanly" bit might be a bit of a issue here. Compensation for latency to the MIDI clock like Live uses might not be possible in Chuck. Still, even being able to extract the time between clock pulses would be valuable for paterned effects and so on. Very few implementations get it right. Stricktly speaking the clock is just one byte and it's one that should be able to interupt other messages, then have those continue yet not all implementations do that. Oh, and I have another matter; Considder this little fragement; if (msg.data2==60) !patern[0] => patern[0]; if (msg.data2==62) !patern[1] => patern[1]; if (msg.data2==64) !patern[2] => patern[2]; etc. This refers to white key midi notes toggeling bits in a array called "patern" which holds ones and zeros which in turn represent my steps. (So I can do "if(patern[step]) 0=> buf.pos;" which I personally found rather elegant) This works perfectly fine but I couldn't find active use of the "!" operator documented anywhere. Checks involving it are all around but nothing like this active usage (as far as I could see) while this is quite handy. I figured it out by simply trying but it might be nice to have it documented somewhere. Yours, Kas.