I’m not sure where else these phantom SPP events might be coming from?
I mention in the video about the “Route MIDI Clock” option on MIDI Input Ports. If you’ve turned this on, and you have another device sending SPP events, they might be getting mixed into the stream.
Also, what is you MIDI clock source in Cantabile? Metronome, media player or sync to another external MIDI clock?
Hi @brad
Thanks for looking at this for me. I understand everything in the video and I double-checked the items you mentioned.
I have nothing routed, or even connected. Only the laptop and iPad. The Song rack is empty. I have all my Background Rack bindings switched off. None of my MIDI In ports have Clock Routing enabled, and nothing is connected to my laptop anyway - it’s just me and my laptop/iPad here on the sofa.
There’s nothing attached or running that could be creating additional messages. The only thing plugged into my laptop is its power supply.
I’ve used both wired and wireless connections - same result.
I tried switching on the ‘Send MIDI Clock Tempo When Stopped’ option. With that option switched on the clock data transmitted when Cantabile is stopped is clean - just clock messages. As soon as I press ‘play’ the ‘STOP’ and ‘CONTINUE’ messages again begin appearing spuriously in the clock data.
Thanks for sending those. I loaded your settings and background in Cantabile here and I’m not seeing spurious MIDI Clock events.
I also reviewed all the code that sends MIDI clock song position events and if the transport is playing, it first sends a Stop, then Set Song Position, then a Continue event. So I’m pretty sure these events are coming from somewhere else.
One thing I did notice, you’ve got MIDI Clock for a device called MIDIIN4 (MIDI USB-USB) enabled. Can you try disabling that and let me know if the problem persists before I dig deeper.
Also, I’ve just put up build 4175 which has the MIDI clock logging I mentioned yesterday. I’d be interested to see the output of this:
Install 4175
Go to Tools → Options → Diagnostics and turn on Console Logger and Verbose Logging
Run the transport and take a look in the console logger.
You should only see “MIDI Clock! NNN” messages while the transport is running. If you see “MIDI Clock Position” while running then this is definitely related to Cantabile’s MIDI clock generation. If not, then there’s something else putting those events into the output stream.
@brad
I’ve done everything above as asked, including disabling that clock input (which isn’t connected anyway). I’m still seeing the spurious messages. The clock numbers seem to jump around too. Hopefully this begins to narrow it down?
One thought… I was having this problem below a short time ago. I seemed to be getting a timing glitch every 64 bars from bar 5. I suspected it was the plug-in and stopped using it. Maybe connected?: Weird timing glitch
OK, so these are definitely coming from Cantabile’s MIDI clock generator.
The stop/reposition/continue events happen when the clock generator thinks the transport position has “seeked” to different location and you can see in the log after each of those repositions, the time stamp on the MIDI clock events has stepped backwards.
Until I really dig into this, I’m not sure what might be causing that but seems like some sort of clock/timing jitter. My suspicion is you’re not getting very regular audio cycles from the WASAPI driver.
What happens if you switch to the Null Audio driver and set sample rate/buffer size to 44100/512 - does it still happen?
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.
)