Switching off double-buffered audio gives me fewer spurious stop/continue messages, but it doesn’t cure it.
If I also increase the buffer size to 1024 the problem is ‘cured’, and my sequencers sync without trouble.
So it seems to be related to buffer size.
Switching to Null Audio I can go down to a buffer of 64 and still clean clocks showing. Same with ASIO4ALL - even double-buffered.
So I’m guessing that this is just a problem when I’m using the WASAPI driver? Normally I would be using an ASIO audio interface, but for expedience I’ve been using WASAPI for scratch work.
Now you mention buffer size, it makes me wonder if I had the same problem when I was setting up for my Spectral Stream Gigs.
I had a song that was at a particular tempo (faster than my other songs) and my Montage was not syncing correctly - displaying the wrong tempo on its display. It was driving me nuts, but when I increased the buffer size it all came good. I was going to look at it further after the pressure to get ready was over, but forgot.
When I get five minutes I will see if I can replicate. I could also send the clock to my video laptop and monitor it on MIDIOX or something.
So I guess @The_Elf if you go back to your usual buffer settings, what happens if you slow the tempo of your song, say halving it?
Hi. I couldn’t quite reproduce the issues I had a few months back, but I did some experimentation in the time I had available this morning before I need to get out, and I can get the same results by dropping the buffer size right down. The clock is fine in STOP (I am really grateful for @brad for doing that feature )
In the condition as shown below (feeding MIDIOX via loopMIDI) when the song temp was 115 BPM, my Montage and Summit were showing it as 83 BPM
@Derek If I take the tempo down to 60bpm I get clean clocks. If I raise the tempo to 140 I get more stop/continue glitches. So yes, tempo makes a difference.
Hopefully that will give @brad a few pointers in that buffer size, double buffering and tempo can have an impact on a stable clock, and more than just your good self has seen it, so not something unique to your rig.
The MIDI clock generator is basically trying to synchronize real time with musical time and there was a weird situation where if there’s just the right amount of jitter on one or the other it thought time had travelled backwards and freaked out.
The fix I’ve made puts some generous tolerance on the time comparisons (about 1 second) and instead just lets whoever is behind to catch up. I’ve done some experiments with a wide range of audio buffer sizes/rates and tempos and it seems much cleaner now but will be interested in feedback from anyone who was having issues with this.
This will be in the next build 4176 which should be up as later today.
Great news. I am away from home this week, but will try it when I get back home this weekend.
Thinking about it I used to get the odd little glitch which is really noticeable when you have tempo synced delays (as I do). So hopefully this will be the cure for that as well.
Just reporting back, as the weather is not good here today, that I updated to the latest build and clock stability to my external units looks a lot better behaved over a large tempo Range. A “stupidly low” buffer size can throw things out of kilter still, but given the audio is unusable on those settings, then it is not a realistic test.
)