I’ve been using Ardour for some weeks and I recently bought a MIDI Keyboard. I finally got it working with the MacBook but now what I notice is that Ardour is only getting roughly half of the messages from the keyboard. I don’t have this issue when playing on the Model D app for example, just with Ardour.
I could confirm this by opening the MIDI Tracer and playing a single key per second on the keyboard. I see many NoteOn messages without a corresponding NoteOff message and vice-versa so it’s clearly not receiving all messages for some reason. What happens because of this is that some notes don’t play and others don’t stop playing when I stop pressing the key.
Is this a known issue or is there something I might be doing wrong? I’m using CoreAudio and the keyboard is a Korg nanoKey Studio.
very disappointing when something doesn’t work.
I found something on the web that might help.
Please read this website carefully to the end.
Thank you for the reply but the link you sent is for the Reaper DAW, that plugin is for Windows and Linux (I’m on a Mac) and it’s for a KORG Nanokontrol2 (I have a nanoKey Studio). It also looks like they were having issues connecting it while I don’t. I have it connected, the issue is only that half of the MIDI messages are lost and never make it to Ardour. I don’t have this issue with other software, only Ardour.
It is not a know problem.
Perhaps the actual issue are dropouts? top-right in Ardour’s status-bar, is there a number in parentheses after DSP load percentage?
What settings do you use in Ardour Menu > Window > Audio/MIDI Setup? If you use a very low buffersize, try to increase it.
To rule out hardware issues, I suggest to check if it work on other software e.g. GarageBand (comes with macOS).
Thank you for your reply. I had a 1 inside parenthesis. I checked my settings and I had the buffersize set to 1024. I increased it to 4096, it got better and the number inside parenthesis disappeared. Then I tried lower values just out of curiosity and it definitely got worse.
I believe it’s still not good with 4096 though. Pressing a single key twice per second I get something like this (two sequential NoteOn messages means it missed a NoteOff and vice-versa):
17661524 NoteOn chn 1 3c 57
17667918 NoteOff chn 1 3c 40
17689657 NoteOn chn 1 3c 61
17721148 NoteOn chn 1 3c 6b
17726918 NoteOff chn 1 3c 40
17754047 NoteOn chn 1 3c 57
17759199 NoteOff chn 1 3c 40
17784767 NoteOn chn 1 3c 6b
17790183 NoteOff chn 1 3c 40
17817808 NoteOn chn 1 3c 6b
17823455 NoteOff chn 1 3c 40
17852258 NoteOff chn 1 3c 40
17876096 NoteOn chn 1 3c 61
17882067 NoteOff chn 1 3c 40
17907684 NoteOn chn 1 3c 57
17912960 NoteOff chn 1 3c 40
17938470 NoteOn chn 1 3c 57
17943802 NoteOff chn 1 3c 40
17967774 NoteOn chn 1 3c 57
17973302 NoteOff chn 1 3c 40
17996287 NoteOn chn 1 3c 57
18001793 NoteOff chn 1 3c 40
18032251 NoteOff chn 1 3c 40
18057755 NoteOn chn 1 3c 61
18063050 NoteOff chn 1 3c 40
18102339 NoteOn chn 1 3c 6b
18106664 NoteOff chn 1 3c 40
When it doesn’t receive a NoteOn it just makes me feel like I missed a key but when it doesn’t receive a NoteOff message and the note keeps playing it’s definitely noticeable.
I tried with FL Studio Trial and it didn’t seem to have this issue. Also with Model D.
Which version of macOS are you using? Intel Mac or Arm (M1/M2)?
We have recently tweaked realtime-setup for modern macOS (you could try an Ardour 7-pre release, demo is fine: Ardour - Nightly Builds) which may or may not help.
It’s a MacBook Air with an M1 processor.
I tried downloading the macOS ARM64 build but it asks for a login.
EDIT: I just tried with my account and it’s downloading.
EDIT 2: macOS ARM64 didn’t start. I’m running the Intel build. Still had dropped MIDI messages with buffersize set to 1024. After setting it to 4096 it feels more “stable” than Ardour 6. Thank you.
After playing with it for a while I’m realizing that it didn’t really get better. I’m getting missing notes when playing on the keyboard and also notes that keep playing indefinitely and I have to figure out which key I have to press just for it to stop playing. At this point it’s unusable. Is there anything else I can do?
EDIT: I just tried an app called MidiView for the sake of confirming that it’s not a hardware or communication issue. Even when pressing keys at a faster pace I don’t get a single missing message.
You are running the Intel build on an M1 laptop? But MidiView is a native application?
Large buffersizes is not really a solution (latency is huge, and playing not great), it was just something I thought worth to investigate.
Sadly I do not know what could cause this. I have a macPro (intel) and a recent Air (M2), and both work fine, here with an m-audio keyboard.
Old (6.9) builds do have issues on Big Sur and Monterey, mainly because Apple changed how an application acquires reatime permissions. But both the 7.0-pre Intel and apple ARM builds have been updated.
One thing you could try: get a debug build from Ardour - Nightly Builds
then check the file
~/Library/Preferences/Ardour7/stdout.log (a text file) if there are any messages like
Dropped Stale Midi Event. dt: <num> ms. By default Ardour ignores any MIDI events that are older than 10msec.
PS. I have also just added debug information for future events, in case there is some issue with event-timestamps, available in Ardour >= 7.0-pre0-3515, should be available 7-8 hours from now).
Also many thanks for staying around and helping to track down this issue!
The reason why I was using the Intel build was because the ARM build wasn’t starting. According to the Nightly Builds page I tried
xattr on the
dmg file but yesterday I figured out it only works if I run it on
/Applications/Ardour7.app so if that’s the right way to do it, maybe update the info on that page for anyone having the same issue. I’m a “recent” Mac user so I didn’t know this, I have mostly Linux experience.
Regarding the debug build, I just tried
Ardour 7.0.pre0.3519 (rev 7.0-pre0-3519-gaf28394bfd) Intel 64-bit - debug and after hitting a couple notes to reproduce the “stuck key” situation, I can see a dozen lines in the log file that look like:
Dropped Stale Midi Event. dt:12.85ms
What should I look for in the log file regarding those future events that you mentioned?
I was going to also try the ARM Debug build but yesterday I noticed that the URL for that file doesn’t have
-dbg- like the Intel Debug URL does. Even today I can see that both ARM builds (debug and non debug) have the same SHA1 so apparently both are non debug?
Also, I didn’t want to add more entropy to this thread but on Linux, Ardour doesn’t even show the MIDI Keyboard on the Inputs selection box (or matrix) even though I can use the keyboard with other apps. If there’s any suggestion on getting that working and if that might help figuring out the issue with the keyboard somehow, then I’ll be happy to try that too. Thank you.
Aha! So event do arrive late. What is the largest number in the log? (could you upload the log somewhere? pastebin.com or tracker.ardour.org)
Perhaps 10ms is a bit low and Ardour should allow even older events. Then again a delay of 10ms is the threshold that most human can discern…
The largest number is 44.61ms and I believe I know why this is happening. Maybe I didn’t mention this but I’m connecting via bluetooth. I just tested connecting with a USB cable and I don’t see any Dropped messages. I do see a few
Ignored future Midi Event messages though.
I uploaded the content of both log files. One connecting with bluetooth and one with USB cable.
I hope this helps. In the meantime, is there any easy way for me to increase the 10ms limit?
Thank you! I did not know that you could connect a nanoKey via Bluetooth. Bluetooth has a rather long latency, so this is rather surprising.
So when you play it directly with a USB-connection, it worked correctly with no lost notes, is that correct?
No, it is fixed in the source code, but I have just increased it to 60ms in Ardour 7.0-rc1-7: Increase coreMIDI robustness, do not drop late events · Ardour/ardour@7e5fe69 · GitHub
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.