Tempo Sync Clock unstable.

jaytrax

I use clock myself in order to sync tempo based fx on my GX100 like delay

The drift in tempo as far as I’m aware is a limitation of midi clock and not ST3 it’s never 100% solid

The only workaround would be setting the time fx via midi for each song in the lyrics editor

For me the slight drift is usable for the most part,
However it can warble fx on less busy tracks

Thinking outside the box, you could possibly set up a button or midi to stop the clock after the initial start of the track once tempo is sent

The above may be possible using the assignable midi action 1 or 2 set in playback settings

Travmeister

jaytrax thanks for that info too. I’ll try the cc tempo message in the lyrics editor, but how does the cc value relate to the bpm? Is 0-127 the only tempo range or is their some kind of conversion involved?

peter

MIDI clock is unfortunately very sensitive to slightest timing drift. It is a continuous stream of heartbeat messages every couple of milliseconds and being a millisecond off could already mean that the tempo will change a bit. If the tempo changes by about 2% or 3% I would not worry too much. You won't hear it on delay fx for example. If the difference is bigger, you might try to check if it is stable when you do not interact with ST3 or when you disable some internal processing or increase the audio buffer. All this will lighten up the load on the iPad and that could lead to better timing when sending midi messages.

Travmeister

peter Thanks Peter for the quick reply. Unfortunately the drifts are up to 10% which makes it super noticeable. I’ll try again with increasing the buffer size but from memory this did not improve things all that much.

Travmeister

peter is there any way that clock jitter can be improved in future updates of the app? Or are you at the mercy of IOS?

jaytrax

Travmeister
Unfortunately there’s no CC for tap tempo

In your song details make sure Tempo is set first

Make sure Clock is enabled and increase buffer to 2048 in the playback settings

Hopefully this will yield better results

If that doesn’t work let us know and I might have other (more complex) workarounds

jaytrax

Looking at the manual
Tap Tempo is assignable using

CC.44 VALUE 0-127

you’ll need to experiment with this

Travmeister

jaytrax thanks again for the info. I’ve been reading that the Quad Cortex recognises this CC as a ‘tap’, so then you need to enter another CC ‘tap’ at the correct tempo spacing after it. Im going to try entering
[midi@play: CC44.127] [midi@xx.xx.xx: CC44.127]
and see if that works. I’m going to turn the clock off also so there’s no disruption. I’ll post the results if it works ok.
It’s bizarre to me that a digital instrument like an iPad can’t produce steady clock data. It’s 2023 already.

peter

With the way midi messages are currently sent, I see not much room for improvement. I am currently at the mercy of iOS timers which do not guarantee to fire at certain intervals. It could most likely be improved by prescheduling midi events but that would require a complete rewrite of the midi code.

But a 10% drift sounds too much. In my tests the clock drifted between 117 and 123 when set to 120. What type of iPad are you running? Is the drift the same if you run a stereo song without any processing enabled?

Travmeister

peter thank you for your answer. I’m currently using a 2023 iPad Air but I’m going to try a different ipad to see if the problem still exists on that. The 10% drift is present on stereo tracks, I haven’t tried it on multitracks yet. When you say ‘no processing enabled’ are you talking about eq? I’m using that on a ‘per song’ basis rather than globally. Also, if ST3 is running on my ipad as a guest (the other band member would be the host), would my iPad still output midi and clock info? Cheers

peter

So, maybe try the approach with the CC44 command. That way the tempo would at least not drift during a song. Make sure to use timed midi messages for both commands and calculate the delay with this formula: 60 / bpm. So if you have 120bpm the result will be 0.5 (seconds) that you need to place both commands apart. Then write (assuming midi channel 1):

[midi@00:00.00: CC44.127@1]
[midi@00:00.50: CC44.127@1]

Travmeister

peter thanks Peter, I’ll try that and let you know. Cheers

Hansenhaus

Quad Cortex user here as well and had the same issue with clock sync. I ended up programming tap tempo (Like Peter's example) at the beginning of each of my tracks to get around the problem. It works perfectly.

You can quicky program the tap tempo by opening the lyric editor, start play back and tap the clock icon on the lower right on beat. It will create time stamp entries which you can then edit with the CC44 MIDI command.

Travmeister

Hansenhaus thanks mate, I appreciate the input and relieved to know it works so well. Cheers.

Travmeister

Post script to this post: The Quad Cortex analogue delay rate is quite unstable below 100 bpm, even without any clock input. So when a clock input is used at 100 bpm or below, this QC delay issue gets much worse.

bens

Coming back to this thread, I've tried both of these strategies with my QC.

As stated, MIDI clock tends to drift a little (₁-2%), which causes Tape Delay to start warping in really odd ways. I'd love for clock to be send for a few seconds at the beginning of the song and then stop sending.

I tried the timed CC tap tempo trick, and even with just 2 taps it ends up opening up the Tap Tempo full screen display, which I'd love to disable. Anyone know how to do this? I've also been unable to get the time just right with 2 taps.