|
Midi clock - on the fly connectionThe 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...
|
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)?
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.
cwright,
your feedback makes me look deeper and deeper! :)
According to the following document on the MIDI Consortium site:
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.
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.
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).
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).
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.
Dude.
:o)
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.
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!