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. 