I’m sending MIDI clock from Cantabile 4171 to my iPad to sync up a sequencer. It’s a long time since I needed to do this, and it used to work fine, but today it’s not working well. MIDI Wrench on the iPad is saying that the clock data is corrupted.
Running from Cubase and Reaper gives clean clocks, so I’m thinking there’s something going on in Cantabile.
Can anyone confirm?
Updating to 4173 to see if the problem persists. Back on it tomorrow.
Same result. When I send MIDI clock from, say, Cubase, my iPad sequencer syncs happily. When I send the clock from Cantabile the sequencer chokes after one note.
My iPad’s MIDI monitor shows clean clocks coming in from Cubase, but invalid messages coming from Cantabile. I’ve taken a screen shot:
Nobody else clock external gear?
Looks like I’m on my own with this one, then.
@brad Is there anything I can check to understand what’s happening?
Hi @The_Elf,
Sorry for slow reply.
I’m not sure why this is being reported as invalid:
F2 is the MIDI song position pointer event and it’s a 3 byte event as described here. I’ll get in contact with MIDI wrench developers and see if they have any insight.
Also, I don’t think anything has changed in Cantabile in this area for a long long time…
Brad
Thanks, @brad.
MIDI Wrench shows clocks from (say) Cubase as clean. The only invalid data I see is when sending clocks from Cantabile.
I just now created an empty Cantabile Song and I’m getting the same results with the invalid statusByte=F2 rawSize=3. It’s consistent.
Got a reply the MIDI Wrench developers - they think it’s a bug and will get it fixed.
Doesn’t explain the other issues though… are those F2 status byte messages coming through when the transport is playing, stopped or both?
Brad
Only coming in when the transport is playing.
For comparison, here’s MIDI Wrench with MIDI clocks received from Cubase:
…and from (and ampty Song) Cantabile:
Wondered if I have something in my Background Rack that’s causing this. I just tried a quick test with all my Background Rack bindings disabled and no difference.
Your screenshots seem to indicate that Cubase just isn’t sending Song Position Pointer messages. That’s why you aren’t getting errors from Cubase - looks like MidiWrench doesn’t understand SPP
Fair enough, but (leaving aside MIDI Wrench, which I’m only using as a diagnostic aid) why do none of my sequencers cope with Cantabile clocks? Surely they can’t all be failing to handle SPPs?
I’m using several iPad sequencers, e.g. Neon, Nordbeat, StepPolyArp… All work fine when clocked from Cubase, but malfunction when they receive clocks from Cantabile.
Should Cantabile be repeatedly sending SPPs as seems to be happening? Shouldn’t they only be sent on transport start? Or am I misunderstanding what I’m reading?
I took a closer look at this and best I can tell Cantabile is working correctly and not sending SPP events while playing.
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.
Yet here are my latest screenshots:
I also tried a different MIDI monitor:
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.
Hrm… something weird going on. Can you send me some files:
From the folder opened in step 2, send me log.txt, log-previous.txt, settings.json. Also a copy of your background rack.
Brad
Hi @The_Elf
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:
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
@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?
Here’s what the Console Logger shows:
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
Hi,
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?
Brad
