Sim'n Tonic Forums

(please follow this template when submitting a new bug report - feel free to add more information)


Name of Software or Plugin and version:
Midronome Plugin 1.0.1 AAX

DAW (if any) and version:
Pro Tools 2023.6

Operating System and version:
OSX Ventura 13.4

Short description of the issue:
In Pro Tools, the audio from the plugin doesn't maintain a consistent sync relationship with multiple recording passes. Generating a sync file is totally consistent. Using the plugin is not.

Steps to Reproduce:
Create an aux track, insert Midronome plugin, route audio output to input on Midronome. Midronome picks up sync as expected. Connect midronome midi din output to external hardware input. Create an audio track and import an audio sync file, created using the sync file generator. Do multiple recording passes using the plugin output (sync file muted) and then multiple passes with the sync file output (plugin track muted). I've tested on both a MicroBrute (triggering the internal step sequencer) and Behringer TD3 (again, triggering the internal sequencer). Both have the same results.

Expected Behavior:
Each pass should have a consistent relationship to the Pro Tools grid. The recorded audio might be late on the grid due to internal latency on the hardware, buffer size, input latency, etc - but it should be roughly the same with every recording pass.

Actual Behavior:
When using the sync file, the relationship of the recorded audio is consistent with the grid. When using the Midronome Plugin to generate sync audio, the results are inconsistent. Sometimes the recorded audio is late, sometimes early. Seems completely random, sometimes it takes 5 or 6 passes for the inconsistency to happen, but it always happens eventually. I can provide a video link to a screen recording which demonstrates the issue if required

Thank you for reporting!

A few questions:

1. What is the tempo you are using - is it changing?
2. Are each recording pass from the same place in the song?
3. Is that place snapped to the grid? Is it at the beginning of a bar?
4. What is your sample rate?
5. What size if your audio buffer?

One way to check if the plugin is sending what it should, is to simply record it (create another audio track that records the output of the plugin).
Especially since you have the sync file as a reference - then just look at the audio output of the plugin, see if there are some weirdly placed pulses, or if some pulses are missing.



------------------------------------
------ long technical stuff coming ------

Just FYI, there is a video coming, called "Plugin limitations". This could be the reason you are experiencing this, but it could also be you found an actual bug in the plugin (if so, thank you so much!!). The limitations of the plugin are the reasons I tried to make an ARA plugin first - unfortunately ARA is too new, not supported in many DAWs, and not pratical/easy to set up.
In short (sorry if this is quite technical):

• With an ARA plugin, the plugin gets a tempo map, so it knows precisely what tempo is happening when. Then all it needs during the live playing is the position of the marker, which thank god is one of the very (!) few info that DAWs give correctly.
• With a "normal" (non-ARA) plugin, all the plugin gets is the Live tempo from the DAW. And gosh you'll be suprised how often this is wrong, in particular in Pro Tools. Even if the DAW gives the right tempo every time, there is still an issue: if there is a tempo change within a sample block, there is absolutely no way for the plugin to know until on the next block, which might be too late already.

Anyways - I'll explain it better with a video, but basically you cannot have it all: the plugin is easy to set up and practical, but not accurate 100% of the time. The MidroSync file is not practical but it is accurate 100% of the time (as long as the DAW does not modify it, stretch it badly, add fades to it, or miss part of it when looping).

Hi Simon, thanks for getting back to me on this.

The screen recording I took during my initial test yesterday can be viewed here in case it helps - https://youtu.be/GgCe3tW7dNk

Here are the answers to your questions:

1. The tempo starts with 4 bars at 145 bpm @ 4/4. then switches to 110 bpm @ 3/4 for a few bars, before a slow, linear ramp up to 140 bpm over 5 bars - I was putting it through its paces
2. Each record pass is starting from zero on the timeline
3. So yes, it's the very start of the session, so bar/beat grid 1:1:000
4. The sample rate is 48khz
5. Audio buffer is 256

I've since gone down the rabbit hole and done a bunch more testing to see if I can narrow things down, here are the rambling observations - sorry it's a bit long...

Good shout on recording the output from the plugin - I've just tried recording a load of passes of audio pulses from the plugin and they look totally consistent. The pulses are 11 samples longer than in the generated sync file and the sync file has an 'emphasis' pulse towards the end of each bar, but other than that, timing-wise the plugin and sync file are the same (except for a 1 sample difference in the start point of a few pulses which I assume is just a sample rate rounding up/down). No missing pulses.

I've recorded the plugin audio output whilst I record the passes from the hardware and on the passes where the synth comes in early on the grid, there's no visual difference that I can see in the plugin pulses. I've also taken the analog clock output from the midronome and recorded that as audio at the same time - there's no change in that during any of the recording passes either.

I then tried doing a load of recording passes using the recording of the plugin output, rather than the 'live' plugin output or the sync file - this resulted in exactly the same consistent grid relationship as the generated sync file. So the 'live' audio from the plugin creates the inconsistency, but playing back the recorded output doesn't. Makes absolutely no sense to me! Also, weirdly, using the sync file, the recorded audio from the synths is coming in around 600-700 samples later than using the recorded pulses from the plugin.

The analog clock from the midronome doesn't change, the audio from the plugin doesn't change on each recording pass. It can't be a hardware issue as I've tried on multiple synths and it never happens when using the recorded plugin output or a generated sync file. I am absolutely stumped as to what could be causing it. The only thing I can't easily test is if there is any difference in the midi clock output from the midronome DIN port on the passes that are early.

So still, I get the same behaviour - an absolutely consistent grid relationship with the sync file or the recorded output of the plugin but occasionally the audio comes in early when using the live output from the plugin. I've got the plugin still instantiated and running when I'm using the sync file, it's just the audio and midi outputs of the plugin which are muted when I'm using the sync file and vice versa when using the plugin. Nothing in the Pro Tools session is changing other than which tracks are muted.

Thanks for the technical explanation of the differences between how the plugin and sync file operate. It seems that this might just be some weird inconsistency of DAWs/computers in general, but it's a shame that the plugin can't be the 100% accurate solution. Don't get me wrong, the timing itself seems great! It's just the offset that seems to change at random with the plugin.

I think I now have a workaround which isn't too bad. I've created a track preset where the plugin is routed through an audio track and I can immediately commit the output of the plugin to audio. Then I can just re-commit it if I make any changes to the tempo/meter during the production. It's slightly slicker than using the sync file generator as I can guarantee all the tempo changes are in the right place, rather than counting how many bars each tempo change lasts for.

I think I've broken my brain now. Hopefully, some of this makes sense

Ok, the video helps visualize it well actually.


Plugin limitations
Everything I've mentioned about the limitations of the plugin would not happen before the tempo change (as shown on the video). And if you record from the beginning of the session then I'm sure the plugin gets the correct tempo from Pro Tools. So the issue must be somewhere else.



My guess - the issue is with the MIDI note
The thing I learnt from the video though, is that you also send a MIDI note to your gear!
I know the idea of the plugin is to start recording right away, but right now, at the beginning of the session you are:

• sending a MIDI note to the Midronome which is forwarded to your sequencer
• asking the Midronome to start sending the clock
• asking your sequencer to start playing the sequence

And that's a lot happening in one go - so my very strong guess is this is where the problem is. Because it all depends in what order these reach your sequencer. And since you are all sending them at the same time there is no way to know.

• if your sequencer receives the note after the first clock, then it will be delayed by one clock
• if it receives it before, then it will take the clock into account (in most cases)

Have a look at this video if it helps you visualize where the note ends compared to the clock: https://www.facebook.com/groups/1044389 ... 8680388517 (it's from the Midronome Facebook group).



Try with a sequencer which reacts to MIDI Start
When sending MIDI Start (to start a sequence) instead of a MIDI note, then the Midronome takes care of it, and makes sure MIDI Start is always sent before the first clock, even in the "2.4.P." mode without delay. If you have another sequencer which does not need a MIDI note - I strongly suggest you try it to see if you get the same results. Turn the Auto-Play mode one so that the Midronome starts it automatically.

What is strange is why you do not have the issue when using the sync file - this I do not know why.



Check if the issue is from the plugin with more recordings
Regarding the recordings, no need to look in that much detail at the samples, just check the pulses - it will be very obvious if one is missing, added, or completely out of place (and yes the sync file has the higher pulse that's because it is designed for MidroSync, i.e. the "Syn" setting. but it will work in 24PPQ modes as well - see the user guide section 5).

But if you want to check the recordings of the plugin, you need to record the output of the plugin:

1. When the sequencer is playing right after the beat
2. When the sequencer is playing way before the beat

If the output of the plugin is the same in both those cases, then we know for sure that the issue is not there.




I hope this all makes sense - if you feel like it we could jump on a video call next week and have a proper look at it. You decide

Cheers
Simon

Hey Simon,

Another bit of testing...

https://youtu.be/pN8z4ST361I

I've taken the midi note stuff out of the test session now and I'm just running the Behringer TD3 and Arturia Microbrute from their internal sequencers (Microbrute just has a physical key taped down so that the Arpeggiator will run without needing a midi note). I still get the same behaviour. I think it has to be a Pro Tools thing because I've just tried using the same sync method in Ableton and I'm getting a consistent grid relationship every time. I'm not sure what is different about the way that Pro Tools or the AAX format works, but it does seem to only occur when I'm in PT.

It's not a huge deal for me anyway, because the Midronome Plugin can be committed to audio so quickly in Pro Tools and then it seems totally solid every time I hit play. It's just really weird and I'd be interested if anyone else using Pro Tools has the same issue or can recreate the problem. In the meantime, I just need to calculate and compensate for my recording path latency so that my hardware is a little closer to the grid and then I'm a happy camper

Thanks for making Midronome and for all the support, it's the first time I've actually been able to lock the components of my studio together and benefit from their internal timing vs shoddy DAW clock. Everything actually sounds tighter and as it should.

Wow, thanks again for the video this is super helpful!!
Hopefully we can get to the bottom of this.

Clearly my previous theory was wrong. I have a new theory: looking at the recording it looks like the sound is exactly 2 pulses early. So maybe the plugin sends 2 pulses before the DAW starts playing/recording. Because it's before the recording that would explain why you cannot see the difference.

If you have a minute, could you record the metronome/click of the Midronome? If I'm right this will be early some of the time, and some time on the beat, just like in your synths recordings.

Either way, I'll do some testing tomorrow trying to reproduce the issue - I'll let you know!

Simon

PS: yes it sends pitch bend ha ha That was a funky decision, it was because some DAWs (Ableton ) do not support sending MIDI CC from a plugin, and many DAWs send MIDI notes weirdly, so I needed some MIDI message that I knew was working - I chose Pitch Bend. The plugin sends both pitch bend and CC, and so far there has not been a DAW that supports neither. The PitchBend message and the CC message do the exact same thing (in this case change the time signature).

Ok I tried to reproduce the issue and yes it's very easily reproducible

Sorry about that - I should have tried to reproduce the error right away. For my defense I very often get "issues" because people's setup is wrong so I assumed it was the same

Anyways - you can leave this to me, this is clearly a bug in the plugin. Hopefully it is solvable

It seems the issue only appears when recording, and only when recording from a bar. For some reason Pro Tools gets the plugin to send 2 extra pulses before the recording starts

Quick workaround: do not record from the beginning of the session and use a tiny preroll (for ex 0|0|001).

Ah amazing, I'm glad it reproducible, that's always half the battle with these strange little bugs!

I should have thought to try using a pre-roll myself, I'll give that a go and see if I still have the issue. Thanks again for all the work on this.

Good news, I found the bug, expect a 1.0.2 version soon with the fix.

That's great news! Thanks, Simon!

Now fixed in v1.1.0 released today.

Lovely stuff! I'll give it a test ASAP