Midi clock - on the fly connection

The midi clock receiver could gain a lot by being able to connect to a clock on the fly. This would ensure sync whatever the situation.

As of now, it connects only upon receiving a "start" or "continue" message, not on a "measure change" or "beat change" message.

Feature request resulting from this discussion: http://kineme.net/Discussion/DevelopingCompositions/Midiclockpatchworkso...

dimitri's picture
Reformulation

After further (and enlightening) discussion in the above thread, I am reformulating this feature request. Letting the "position" counter aside (irrelevant). It might be a separate patch.

Can you pass the raw clock message - beat pulse (0xf8)?

cwright's picture
Re: Reformulation

120bpm x 24 messages per beat = 48 messages per second. Your composition is likely running at 60fps or less. At most you'll get 30 transitions per second (to pulse, there has to be a low frame and a high frame, so that cuts the 60fps into 30 2-frame cycles). At 48 messages per second, you're either going to drop messages, or you're going to have the pulse be high almost every frame. This would be totally meaningless for synchronization.

dimitri's picture
(120/60x24) x4

cwright,

your feedback makes me look deeper and deeper! :)

According to the following document on the MIDI Consortium site:

Quote:
System Real-Time Messages

11111000 Timing Clock. Sent 24 times per quarter note when synchronization is required (see text).

At 120 BPM it represents 192 messages per seconds, more than 3 per frame. That's not meaningless :)

cwright's picture
Re: (120/60x24) x4

dim wrote:
At 120 BPM it represents 192 messages per seconds, more than 3 per frame. That's not meaningless :)

Your QC graph will execute at most 60 frames per second (maybe 70 on a fancy display, and possibly more if you're not in vbl sync mode, but then you're tearing, so it's not going to be pretty).

To detect a pulse, you need a single frame with a high value, and a single frame with a low value. So, your QC graph is limited to 30 pulses per second. If you don't want a transition, you can just use Highs, and have up to 60 messages per second.

At 60 fps, a pulse is equivalent to a Math expression patch with the expression set to 1. At 30 fps, it's equivalent to a frame counter mod 2. Neither of those mean anything related to the music you're trying to sync with, because you're dropping hundreds of messages per second that convey sync information. So, let's say you want to manually track sync yourself. You get 192 sync messages per second. Your QTZ only renders/evaluates 60 times per second. Where do the remaining 132 messages go? they either get ignored, or you need a composition that can do at least 192 frames per second. Neither of those are at all practical (192 fps isn't impossible, but it's unlikely, and will be inconsistent).

That's why I say it's meaningless -- there are way too many events for QC to respond in any useful manner. The hypothetical sync message patch would only ever output true, unless the BPM was very very low.

dust's picture
Re: (120/60x24) x4

well that puts some things into perspective. chris your really diligent with these things. i find this site a very valuable resource. i was having a hard time trying to figure out the frame rate verse execution etc.. i normally negate to think of such things but recently have been doing some things that require me to be aware. in particular reference to a java script patch lets say executing a simple loop maybe just counting from 0-60 and your frame rate of lets say 60 how long would it take for that for loop to execute a basic count ? im trying to find the fastest way to iterate through a structure ideally i would like it to evaluate compile but sometimes that is not possible.

cwright's picture
Re: (120/60x24) x4

dust wrote:
i was having a hard time trying to figure out the frame rate verse execution etc..

This is very very simple: For each output frame, every red patch will execute once (or more, if inside an iterator). Each green patch will execute once per frame/iteration if any inputs change, or the timebase changes and it uses time (i.e. LFO, Interpolation). Each blue patch will execute once. (I'm perhaps mistaken on the blue patches -- I'm a bit rusty with those).

dust wrote:
in particular reference to a java script patch lets say executing a simple loop maybe just counting from 0-60 and your frame rate of lets say 60 how long would it take for that for loop to execute a basic count ? im trying to find the fastest way to iterate through a structure ideally i would like it to evaluate compile but sometimes that is not possible.

How Long is dependent upon how complex your loop is -- if you're just adding a number, it's pretty quick. If you're doing computational fluid dynamics, 60 iterations can take days. JavaScript will execute all the loops inside completely before continuing -- thus, if you have an infinite loop, you hang QC (because the JS is running endlessly, never completing to let other things operate).

franz's picture
Re: Midi clock - on the fly connection

sorry to jump in late, but have you tried Plogue Bidule ? You could easily convert your beat tick into a midi note on another channel, and use this note as beat information in QC.

Regarding this beat sync issue, i personally use an extra midi track with one note every beat. I find it way cleaner (for graphic stuff) than using midi clock. It has the advantage of getting sync'ed whatever the situation is.

gtoledo3's picture
Re: Midi clock - on the fly connection

Dude.

:o)

dust's picture
Re: Midi clock - on the fly connection

plogue bidule seems really cool i haven't had much time to investigate but the samples are wicked. i like stochastic music i actually taught my computer to play stochastically damn thing plays better than me. f!@#$ computer. i guess it had a good teacher. yes the midi note can be translated into a clock and can even give you some more harmonic information that can be used to mix colors or something.

dimitri's picture
For the low-techies

Hey franz,

I've even been using a separate audio channel for this - just the same, a kick on every beat. Sounds rough, but it works!

If you play with a dj who uses Traktor or Serato, you can have the midi clock sent over a wifi network. And this works perfectly too!

The ONLY downside being that you must start your receiver BEFORE he starts his clock… Still thinking :)

ps. love bidule!