Syntakt BPM Clock Unstable

Hi everyone,

I’m trying to record audio from the Syntakt through my apollo interface. The reason is that, on Overbridge mode, the signal is simply too low, as you know (-12db). And I want to record the sounds as it’s coming out of the Syntakt through a pre-amp.

My issue is that, if I record in midi / usb - audio midi mode, the bpm on the syntakt is unstable. For example, I have a track at 123 bpm. The syntakt will oscillate between 122.9-123.1 during the recording, which is not ideal. Sometimes it even jumps shortly to 121.5.

I have the syntakt configured to track & sync input and track output in ableton (12.1) and clock receive on the syntakt. I tried the opposite, which is have the syntakt send clock, but that becomes very unpredictable.

Any thoughts? I imagine quite a few of you are recording without Overbridge. What’s your setup?

I have the Syntakt on the latest Version 1.30B.

Many thanks in advance for for your input.

Jonny

My understanding is that any device receiving clock is going to hover around (above and below) the actual tempo of the master clock (a result of the latency in MIDI messages), that it all evens itself out, and that the instantaneous inaccuracies are small enough as to not produce any noticeable lack of sync. If the Syntakt were always displaying a BPM that was below or above the master, I suppose that would be a problem, however.

4 Likes

hi i think if you put swing on your tempo that’s how swing appears trough midi clock

That’s just the nature of MIDI. If you need completely jitter free, then you need a more solid MIDI clock. Otherwise, keep them unsynced for BPM but still sync for transport, and then just set the tempo on your machine to match Ableton.

1 Like

MIDI on a computer is not critical enough for the processor to provide clock that is stable in time.

If you really must have more stable clock for some reason, look into devices such as

5 Likes

So just set the Syntakt to receive clock and hope for the best with that fluctuation? What’s your approach to recording your Syntakt in Ableton?

Ok interesting, honestly I didn’t know about this. Thought there’s gotta be a better way. Add to that the latency of good 4-5ms. Which I understand is also pretty standard. What’s your approach to recording your Syntakt/machine in Ableton?

There are a few devices available, like expert sleepers USAMO, which will produce an audio output from your DAW and translate it to midi clock output sent from a dedicated peripheral. It’s supposed to be more stable than the DAW’s native midi clock output.

There is also an option for something like MIDIgal which will sample your clock input and then stabilize it and output the stabilized version of your DAW clock, but I don’t know how well that will improve sync with your DAW timeline.

A little bit of jitter like the .2 or .3 you describe in your initial post should probably only be audible if the actual clock output is deviating and not just the visual readout. I’d try to confirm that you actually have measurable drift before you spend any money.

Unfortunately i dont really have any other input because its not an integral part of my setup so I haven’t spent a lot of time researching this. Joe @jmkmusic is pretty knowledgable though, i think he might even make a product to help with this. I’ll let him chime in about it if he has time.

Don’t receive clock. ONLY receive transport. Set the Syntakt to clock itself and just match the tempos. I record in FLStudio, but it’s the same concept.

3 Likes

Gotcha. At this point I’m just accepting that jitter. The biggest nightmare is latency, with or without OB. Seems like the only way (to me so far) to stay at a safe range is to record at the beginning of the project, before adding too much to it. Which is, well, less than ideal :frowning:

1 Like

I think the main purpose of the audio to midi like usamo, is that it reduces latency. You’d have to read about it and see if it’s really worth spending money on though. It sounds like the latency is pretty noticeable at this point.

1 Like

I mean if you’re not changing the tempo while playing, this is the best solution. It’s not syntakt. I’ve seen many other devices acting erratic with midi clock.

Here’s a brain salad; maybe try to clock sync with PPQN?

Thanks, I’ll give it a try. This topic can go pretty deep, and I know people are more like, “just tell me what I need to click or what I need to buy”. I wish it was always as simple as that, but the responders are usually acting on too little information and there are many variables.

@jonnylust The very first thing is to know whether or not the jitter is as bad as the BPM readout suggest. After lining up the tracks in the DAW, hearing or seeing issues on the grid line is certainly a jitter issue, but as others have alluded to, BPM readouts in gear alone is often not a great indication for the amount of jitter that’s really there.

If you want to follow me for a second, I’ll try to break it down. The reason we employ sync in the first place is because no 2 electronic devices calculate time exactly the same. This is due to minor differences in their internal components (an oscillating crystal in most cases). Think of it like 2 stop watches that drift apart. You may have 2 watches that are very close and stay together longer, but you may have 2 that immediately begin to drift apart. This is due neither to jitter nor latency. It’s just what each stopwatch is able to calculate given the accuracy of internal components. Which is right and which is wrong? We don’t really know that in our position. (and in all actuality, they are both wrong)

Regardless, when 1 device is following another device through any sort of sync, it’s overriding it’s internal timing calculations and allowing the incoming pulses to push the sequence along. BUT, here’s the thing that’s easy to get hung up on …

If the sequencer also has a read-out that will show you BPM, it has to calculate that BPM using it’s own internal clock. The sequence may be following the external pulses tightly (ie: being pushed along by the pulses), but the distance between the pulses is being calculated by the internal clock in order to then turn those into a BPM that shows on the screen. The difference is the same difference that you would get if you set each sequencer loose on its own internal clock. And there are still other factors that make the BPM read-out more or less jumpy. For instance, how often does the BPM calculation occur? How often does it refresh the screen? How is it rounding the value? What level precision is it rounding the value to? How much jitter is present in its own internal process of producing the BPM? And yes, how much Jitter is there in the incoming pulses.

There’s also a whole other level to this that I’m not going to get into here where the clock and the sequencer also use different resolutions. BPM calculations have a much bigger impact on the final result then, instead of just being a “glitch” seen in the BPM read-out.

So, as I and a couple others have said, what really matters the most is what you can observe through hearing or visually examination on the timeline for the track that was recorded. If jitter is low, you will know by that.

If you are truly getting a lot of jitter, then the problem could be the master clock, the signal chain, or simply the sequencer’s own inability to lock into the pulses well. You usually will know where the problem is by experimenting with more than 2 pieces of gear in different permutations. Then the problem will get narrowed down to which piece of gear is behaving poorly, and that might suggest a new approach.

The other part of this is latency. Latency isn’t about whether the clock is tight or not. You can have practically zero jitter and still have loads of latency. And you can have practically no latency and have lots of jitter. Each of these is a separate concern technically.

It sounds like you are recording the external synths into the DAW while also sending clock from the DAW (a very common thing). So, there’s probably a little bit of latency added on the clock signal going out of the DAW, and a little latency added by the external sequencer’s own processing, but there’s a whole lot of latency on the signal coming back into the DAW, especially if you need to set recording buffers higher and higher as the project grows. And there’s so many settings and adjustments to make in a modern DAW to try and combat latency, it’s getting hard to keep track of knowing what they are and what they effect, because latency is all about finding that exact point on the signal chain where latency is the worst and applying the appropriate fix. I’ll give an example …

You are monitoring an external audio source through a track in Ableton while recording it. The external source latency is severe, so you look at ways to adjust latency settings. Finding the latency setting that automatically slides the recorded track over after the fact will only fix the recording, it will do nothing for the latency you heard while monitoring the source while you were recording.

One way to nullify latency between a DAW and an external Sequencer in real-time is to have the clock pulses sent early. Actually making the external sequencer start and run early. You might be able to achieve that without any external help, it depends on the DAW and figuring out if there is a way to get those pulses going at a negative offset against the DAW timeline. The Transport control is also a concern, because if you can get the pulses sent early, the Transport control is also related to that.

When a clock device is sitting between the DAW and the external Sequencer, physically or virtually, and it’s receiving the pulses from the DAW (let’s say Audio Pulses, as that is the best form a tempo-based clock going out can take), there’s an opportunity to read those pulses and offset them AS CLOSE TO THE SEQUENCER AS POSSIBLE. What I mean by that is, without changing any DAW settings, the external clock is offsetting the pulses right before the pulses reach the Sequencer. It’s literally like moving the track backward just as you would do manually, EXCEPT, it is happening in Real-time, not after the fact. But, as you investigate this more, you’ll find that it works by having the DAW pre-roll 1 bar in silence, allowing that bar to be used by the external clock to create a negative offset (because it can’t perform magic … it can’t really start before the DAW is running). And that can be a big caveat for some, though if you can get away with that technique, it is fairly easy to manage.

Man, this was a tome. I’m sorry about that. Just buy XYZ product. :rofl:

4 Likes

I would give overbridge another shot. If you go in to audio routing settings in Syntakt you can change the Int to Main setting to on, this will allow you to still use the overbridge sync (which I’ve personally found to be a lot tighter than the sync you get from midi/usb mode) but will send the audio out of the outputs so that you can still process it through your apollo.

-12dBFS (TPK) is not a low signal in a 24/32bit audio environment. It is perfectly acceptable for any scenario I can think of. Why do you think you need to record things hotter than that would be my first question?

Its not the 90s anymore, nobody records at 16 bits, you dont need to peg the meters