Is it possible for a StreamByter script loaded in Audiobus to receive the MIDI clock generated by Audiobus? I tried to do this without success, detecting the F8 clock message. But I found a Mozaic script that can do this, using the @onmetropulse event. That script sends a clock message which StreamByter receives with no problem. Using Mozaic like this is a viable solution, but seems unnecessary. I can also do it by having Audiobus send clock to the external FreEWI app and receiving it back, but this is very roundabout.
What does Mozaic do that StreamByter does not? Is StreamByter explicitly blocking the internal clock messages, but receiving others? Is there a trick that causes Audiobus to send clock to internal modules?
(I have also posted this question on the Audiobus forum, but hoping someone here may have the secret.)
Obviously I am no expert in the inner workings of other apps, but I doubt Audiobus is sending in MIDI clock over AUv3. What is more probable is that @onmetropulse is being generated by the plugin. You could do something like this in a StreamByter to effectively generate clock events inside AU3. A cut-down Dynamic Clock if you will:
if load set include factory standard_includes define tick_event F0 7D 42 F7 alias L0 ticking assign ticking = 0
sub issue_tick send F8 calc P0 = bpm * $100 calc P0 = $250000 / P0 send tick_event +I +DP0 end end
if control_tx_start send FA assign ticking = 1 issue_tick end
if control_tx_end send FC assign ticking = 0 end
if M0 == tick_event if ticking == 1 issue_tick end end I have not tested this or anything (and somewhat rusty on StreamByter syntax); just typed it in. It's the method I am trying to show here ;-)
It should follow tempo changes too since the next tick interval is recalculated from the current bpm each time.
Hi nic, This is a little scary, dead-reckoning what should be common clock pulses. I was sceptical at first, then I reread the Mozaic manual, and it does sound like the "metronome" is something that you create. Mozaic just hides the clock generating steps you describe behind a nice user interface. Thanks for the suggestion; I'll give it a try. Cheers, Dave.
Hi nic , Here's my updated version of your code. When I first got it running, using 90 BPM and 4 ppqn, I was surprised to see that the beats were coming early, so pretty soon I was declaring a new bar on the fourth beat of the measure. That's because the interval should be 166.666 ms, and we were only using a delay of 166 ms. I took me a while to remember the technique of accumulating the underflow until it reached the divisor, and adding an extra ms at that time. I just tried it for 93 BPM and 4 ppqn. For that scenario, it completes a cycle in 31 steps, with 9 added ms, in exactly 5000 ms, which is exactly correct.
I dropped recalculating the delay every time, to save time. It will update only on every Play.
Also, one little error. You didn't need to multiply the SB bpm value by 100, because it's already multiplied.