[DONE] Audio sync without 1 bar delay

[hez]

Hi all,

I was wondering whether there's any possibility of having the option to remove the 1 bar pre-roll sync when syncing the Midronome to a DAW via audio. I use Bitwig and typically spend a lot of my composition time working in the clip launcher (which is very similar to Ableton's clip launcher). This makes it impossible to start things in sync, as all my software based clips start playing the second I hit play, whereas all my synced hardware starts up one bar later!

This is fine to work around in the arrangement stage as I can just start playback from one bar before the section I want to listen to, but it's very awkward to work around in a clip launcher based workflow.

I would be totally happy with a.) this being an optional setting and b.) this setting requiring the Midronome to assume that the tempo/time signature hasn't changed since the last received audio clock, thus having to correct itself at bar 2 if the tempo has indeed changed.

On another note, if anyone else uses Bitwig, I've built a little Grid patch that will send the correct audio clock required by the Midronome at whatever tempo your project is set at I need to test it a bit more thoroughly under different conditions but can share it if anybody else needs it!

[Simon]

Awesome hez, thank you so much for sharing I'm sure a lot of people would love it if we could put a link to that Bitwig Grid Patch somewhere

As for this - it could be changed, in particular using your two assumptions. I would love to hear if other people feel the same way

Simon

[Jozz]

Same workflow’s problem here but with ableton ! Thanks for Explain This clearly !

[Jozz]

Answer from Simon on facebook « Hey JO To start syncing the Midronome needs one pulse before the bar (the "high pulse"). So if you press play in your DAW just before bar 2, it will also sync from bar 2. But don't you like having a bar before your song starts anyways? When in the studio, I personally always record from bar 1 so there is one bar where I can hear the metronome before the recording starts.
Anybody else has some opinion/thoughts about this? This could be changed in a future firmware update if it is a problem for most people »

[hez]

Awesome hez, thank you so much for sharing I'm sure a lot of people would love it if we could put a link to that Bitwig Grid Patch somewhere

As for this - it could be changed, in particular using your two assumptions. I would love to hear if other people feel the same way

Simon

Thanks Simon, I'll test the Grid sync patch a bit more today and then share it in another thread if it's working correctly.

Regarding your response to Jozz on facebook - in a typical linear arranger workflow it totally makes sense to leave 1 bar at the start of the arrangement (or to start playback from 1 bar before the section that you intend to track/loop/audition). Unfortunately this is impossible with the Bitwig/Ableton clip launcher paradigm, as there's not really a sense of continuous linear time - instead every track is 'triggered' when you press play, and as far as I know neither software offers the possibility of a 1 bar countdown before this happens.

[J. John Mixson]

[This is to correct a assertion I made here and delete the irrelevant.]

Midronome is compatible with iConnectivity mio X-Series.

Happy Syncing!

[amaeland]

For my workflow, the 1-bar delay is quite annoying. Right now I am actually experimenting with turning audio sync off and just setting the Midronome tempo to the same as Logic manually. Logic is only sending start/stop. So far it works better. The Midronome doesn't have to "think" about the sync signal this way, which should make it more stable too.

[amaeland]

I am experiencing that there is a small static timing offset that is not always the same amount (when stopping playback and starting again). In my use case, being an electronic music producer with a need for as close to sample accurate sync as possible, this is an issue.

Presumably the problem occurs because the MIDI start/stop messages are sent to the Midronome over USB?

If so, I have an idea for a solution: start/stop messages via audio signal instead of MIDI. For example a DAW track with constant white noise on it throughout the whole song. Signal would then mean Play and silence would be a Stop message.

What do you think, Simon? I am worried the problem could be due to jitter in the start/stop response of the external sequencers, but hopefully not!

[MPrinsen]

I understand that Midronome needs to calculate the BPM and also determine the correct step in the bar first before it can start correctly, but in a DAW environment when working on a track, you are usually working on the same track and starting/stopping the track over and over again. Most tracks have the same BPM from start to end. So in my opinion, it would make sense to just start playing directly at the first pulse it receives.

Even if it means that it may not start at the correct step in the bar, it would resync at the beginning of the next bar, so that's not a problem to me. If you just always start from the beginning of a bar, it would always be in sync directly.

It would be great if an option would be added to start playing at the first pulse received. Just ignore the midi Start message that comes from the DAW, always start when a pulse is received (and the playback is not started already). That would be perfect to me.

Also, USAMO (which I'm trying to replace with the Midronome) actually does start immediately when pressing play. Even without sending midi transport messages over USB (it only communicates over audio with the DAW). But USAMO has its own problems (like doubling/halving the tempo when changing the playhead in the DAW to "keep up", which doesn't make sense to me at all).

[Simon]

I am experiencing that there is a small static timing offset that is not always the same amount (when stopping playback and starting again). In my use case, being an electronic music producer with a need for as close to sample accurate sync as possible, this is an issue.

If the only communication between DAW and Midronome is Start/Stop, then they are not sync'ed together. Simply setting the same tempo on both of them means they each run on their internal clock, which cannot be exactly the same, so after some time (usually 2-3 minutes) you will start to hear the drift. I'm afraid the only way is Audio Sync

[Simon]

I understand that Midronome needs to calculate the BPM and also determine the correct step in the bar first before it can start correctly, but in a DAW environment when working on a track, you are usually working on the same track and starting/stopping the track over and over again. Most tracks have the same BPM from start to end. So in my opinion, it would make sense to just start playing directly at the first pulse it receives.

That's a very fair request and yes it should be possible to implement, I will look into it. Basically set the beginning of the bar on the first tick received. The tricky part is that in the Midronome there is a lot happening just before the new bar. And to keep the tight timing, most of these things have to be set up before the new bar starts, so that when it actually starts everything runs smoothly and in time. Yes, that 5ns jitter does not happen without compromises

It would be great if an option would be added to start playing at the first pulse received. Just ignore the midi Start message that comes from the DAW, always start when a pulse is received (and the playback is not started already). That would be perfect to me.

If you mean that on top of starting the sync the Midronome will also send MIDI Start automatically to devices, ths would require some tricky dodgy fiddling, because the MIDI Start message (and SPP 0,0 message) needs to be sent before the first MIDI Clock.
Besides, what if you do not want to start your sequencers right away but later in the sequence? I would suggest to keep the implementation as it is with reacting to Start/stop from the DAW sent over USB.

[MPrinsen]

Makes sense. But maybe you can just send midi start and spp0 at the first pulse and then send the first midi clock tick as soon as possible after that. This will result in a slightly delayed start, but (correct me if I'm wrong) this will be corrected at the very next clock tick, right?

So we will have a direct start when pressing start in the DAW at the cost of a slightly less accurate first beat. I can live with that. Obviously, this would ideally be optional, since there may be people who do want the first beat to be perfectly tight.

[amaeland]

If the only communication between DAW and Midronome is Start/Stop, then they are not sync'ed together. Simply setting the same tempo on both of them means they each run on their internal clock, which cannot be exactly the same, so after some time (usually 2-3 minutes) you will start to hear the drift. I'm afraid the only way is Audio Sync

ah okay, I thought the Logic clock would have more jitter but not slide more and more out of time. Fair enough then, guess I’ll have to continue troubleshooting the glitching.

MPrinsen’s suggestion sounds great to me. I am fine with the first beat being slightly out of time if everything syncs up right afterwards. When it’s time to record I will just start a bar early to ensure the first beat is tight too.

Speaking of first beat, sometimes it takes two bars for the Midrinome to start playing. What could cause this behaviour? (It’s not consistent)

[MPrinsen]

MPrinsen’s suggestion sounds great to me. I am fine with the first beat being slightly out of time if everything syncs up right afterwards. When it’s time to record I will just start a bar early to ensure the first beat is tight too.

Exactly!

[Simon]

Noted, guys, I'll update this post when I have investigated.

Speaking of first beat, sometimes it takes two bars for the Midrinome to start playing. What could cause this behaviour? (It’s not consistent)

This sounds like a bug - would you mind reporting it? Thanks

[MPrinsen]

Noted, guys, I'll update this post when I have investigated.

Awesome!

[spacialrob]

Would appreciate the option to disable the 1 Bar Sync Delay for audio sync, as my looping gear sometimes needs to begin synchronizing in time with the start command.

[Simon]

All done - implemented in FW 2.0 which will be released in September.
See viewtopic.php?t=212

[MPrinsen]

Awesome!!

[amaeland]

Great! :———D

[Simon]

Just FYI - that will definitely require a fair amount of beta-testing, ideally with as many different devices as possible.

I had to do some pretty nasty things to be able to start the sync right away, in particular DIN sync / sync24 could be an issue (technically, from the first tick of the DAW it would need at least 20ms to send a decent start signal, which is already one tick length at 125bpm!).
MIDI is not much better, as some machines need a few ms after receiving MIDI Start before they start to sync on MIDI Clock, while other machines do not like receiving MIDI Start without receiving the clock (and would just start at their own tempo - Korg Volcas for ex)...

Basically it is difficult because the Midronome gets no warning, just a "NOW - GO" (=the first tick from the DAW) and it has to start syncing, start internal counting, send MIDI Start to the MIDI machines, send Start over DIN Sync, and start sending the clock on both MIDI and ANLG ports. All of that before the next tick arrives, which could be 6.25ms later (at 400bpm)... So quite a mess to implement!

[MPrinsen]

Just FYI - that will definitely require a fair amount of beta-testing, ideally with as many different devices as possible.

I had to do some pretty nasty things to be able to start the sync right away, in particular DIN sync / sync24 could be an issue (technically, from the first tick of the DAW it would need at least 20ms to send a decent start signal, which is already one tick length at 125bpm!).
MIDI is not much better, as some machines need a few ms after receiving MIDI Start before they start to sync on MIDI Clock, while other machines do not like receiving MIDI Start without receiving the clock (and would just start at their own tempo - Korg Volcas for ex)...

Basically it is difficult because the Midronome gets no warning, just a "NOW - GO" (=the first tick from the DAW) and it has to start syncing, start internal counting, send MIDI Start to the MIDI machines, send Start over DIN Sync, and start sending the clock on both MIDI and ANLG ports. All of that before the next tick arrives, which could be 6.25ms later (at 400bpm)... So quite a mess to implement!

Awesome, looking forward to beta test it!