Synchronization of the TimeIndex to an external MIDI clock signal

Question

Hello,

I'm currently trying to sync Ableton Live, an external sequencer and Kyma via MIDI with the Multiclock. With the Multiclock you can generate a very precise MIDI clock via audio and send it to up to 4 sequencers. In Kyma I want to synchronize the OscillatorWithTimeIndex or similar. That succeeds with only conditionally. Because at !SongStart or !SongContinue I reset the TimeIndex and the fullRamp looks like it has a short dropout:
  

In the input fields of the TimeIndex I entered the following codes:

 It also doesn't work with: (!SongStart \/!SongContinue ramp0: 1 ms reset: !SongStop) as start gate.
Interestingly, I can achieve the desired result of a clan reset of the TimeIndex with !Reset.
In addition I must say that I have switched off all foreign clock signals at the Kyma MIDI input by means of MIDIFilter, so that Kyma gets only clock signals (also !SongStart and !SongContinue) from the Multiclock. What could be the reason for this?

Comments

Interesting. Since the multiclock is an audio signal, could you extract the reset from that audio signal (rather than using SongStart)?

---

That can be, because the Multiclock has an analog output at channel 1. The manual says: "Channel 1 additionally has a 1⁄4" TRS output jack to provide analog clock or analog LFO."
Further it says in the manual:"Due to an enormous variety of clock polarities, start/stop be- haviour and necessary dividers in the modular world, you can fully configure all settings when Chn Mode is set to Analog.
STARTModecan be set to emit a trigger pulse (Trig.), optionally skip the first clock pulse after start (Trigsk) or simply act as a gate (Gate). Be sure to check your modular sequencers manual if you are in doubt."
There is no mention of an extra audio reset in the manual. This is probably solved via the start trigger.
But actually I don't want to use the analog output, because I have connected the Pacamara via host USB to the Mac and I don't have another audio interface available.

---

I also tried to place the (!SongStart \/!SongContinue ramp0: 1 ms reset: !SongStop) not in the frequency field, but right before the TimeIndex in a mixer in the fields "Left" and "Right".
However, this "initial clock stutter" remained.

---

I can’t tell you how many hours I’ve spent in my life trying to get things to sync perfectly - preceding Kyma also. Is the initial clock stutter perhaps caused by either it needing a certain portion of time to determine the time between midi clock ticks (e.g. at least two) or the fact that Capytalk runs at 1khz max?

Edit: I’ve explored having the time between triggers calc wrapped in a min and max calc - for example, so you can constrain the range of BPM it will allow - this might help with that initial hiccup if for a very brief moment Kyma doesn’t know the BPM because two triggers/ticks have not elapsed?
The tightest Ive got is from MPC4000 (which sends clock continuously even when stopped, useful for keeping Kyma’s estimate of duration between triggers accurate - better than for example Ableton where clock is only sent one running - which always results in a hiccup when started).

---

FunctionGenerator has an audio Trigger field. Perhaps you can use the audio from multiclock in "trigger" or "gate" mode to directly start the FunctionGenerator (which, if you use FullRamp as its waveform, could be used as a TimeIndex)

---

What should be entered under Duration? Is there a way to calculate the durationBetweenTriggers with this audio clock? With the Capytalk ([ Audio Clock] durationBetweenTriggers: 24) s bpm removeUnits it does not work.
The only way I can see at the moment with this variant is that only start/stop are sent to Kyma as audio triggers and the clock is sent to Kyma normally as MIDI clock, right?
With the FunctionGenerator there is also no loop option. That means you would have to re-trigger the FunctionGenerator every time you want the fullRamp to run through a clock, right?

---

@ghood: The Multiclock is something special, because on the one hand it can generate a nearly jitter-free MIDI clock from an audio signal of the DAW (a plugin sends the signal) and on the other hand 4 external sequencers/instruments can be connected, which can be started and stopped individually and that timing-exactly - so the theory. That would be great if that works with Kyma.

---

I had an Innerclock Systems Sync-Lock years ago -before ERM was a thing actually I think. Same concept - worked well.

---

The innerclock solution looks really interesting. Is it possible to start each output of the hardware again independently by pressing a key, so that everything still remains in timing?
Do you still use the hardware clock?

Answer 1

Since the timing clock source is not being sent continuously, it's necessary to give the receiver some time to compute the BPM from the timing clock.

Similar to the way you would "count someone in" before beginning to play together, you can send the song start 4 beats before you want your time index to start. That gives Kyma a chance to measure the duration between triggers and set the rate of the time index to match the timing clock.

Here's an example. (We've aso added this example to the Kyma Sound Library.)

Comments

Thank you for the elegant solution!

Answer 2

In the Frequency field, you should avoid toggling the durationBetweenTriggers expression on and off; it should be running all of the time.

Please try the following in the Frequency field:

((!TimingClock durationBetweenTriggers: 24) s bpm / 4) hz * (!SongStart \/ !SongContinue setReset: !SongStop)

Comments

Thanks for the tip. But unfortunately it does not work either.

---

Could you please give more details about how it does not work?

---

The OscillatorWithTimeIndex always has a fullRamp delay at the beginning after activating !SongStart or !SongContinue (so the fullRam starts with the wrong slope and then corrects its run). This is similar to the first picture above.
If I set a reset of the OscillatorWithTimeIndex manually in the run, then I get again the correct course of the TimeIndex.

---

I have monitorted all parts of the equation in the frequency field separately. The only thing that really shows an incorrect value at the beginning - at !SongStart and !SongContinue - is: ((!TimingClock durationBetweenTriggers: 24) s bpm / 4) hz
The value is briefly low and then jumps to the correct value.
This is also true if I just enter (!TimingClock durationBetweenTriggers: 24) s bpm / 4) hz in the Frequency field and don't multiply with (!SongStart \/ !SongContinue setReset: !SongStop) but still receive !SongStart and !SongContinue from the Multiclock.

---

Is the midi clock sending continuously? If not there will always be a brief period where it doesn’t know the time between triggers because it hasn’t received a second trigger?