Note that we, early upgraders, work for your safety. Bugs and glitches will be discovered and fixed so that you can then safely upgrade.
I’m not expecting instant resolution to the problem, but certain update on the progress - ideally, a tentative timeframe - would be helpful.
IB
An update only is possble if at least the cause of the problem is clear, and that might not be.
No one is waiting for an update: “still searching”.
Unfortunately none so far has responded, in this thread at least to @dspreadbury request.
I have also noticed that issue since I own that device.
@TonH I have already posted the raw MIDI findings and a working conversion test in post #29 and post #34. I have now also compared a working keyboard with the affected one.
The important detail is that MIDI Monitor’s normal display labels both types of release message as “Note Off”, hiding the difference we need to examine. That initially misled me too, as you can see in my earlier post #23.
Here is MIDI Monitor’s output for the same note on both keyboards:
From iRig KEYS 37 Note On 1 C3 72
From iRig KEYS 37 Note Off 1 C3 85
From Clarett+ 2Pre Note On 1 C3 61
From Clarett+ 2Pre Note Off 1 C3 0
Both show “Note Off”, but checking the actual status byte reveals:
-
iRig KEYS 37:
128/0x80— explicit Note Off. Works correctly in Dorico. -
Fatar through Clarett:
144/0x90, with velocity0— Note On with zero velocity. Notes hang in Dorico.
Both are valid MIDI 1.0 ways of ending a note.
The decisive test was with the same Fatar keyboard: routing through Bidule unchanged still produced hanging notes. Converting only the release message from 90 nn 00 to 80 nn 00 fixed the problem. The note number and zero velocity remained unchanged.
So there is already a specific, reproducible difference and a successful workaround in this thread. It does not yet establish whether the underlying fault is in Apple’s or Steinberg’s code, but comparing the “Note Off” labels in MIDI Monitor alone misses precisely this distinction.
But how would a different OS change the values that the MIDI keyboard sends?
Surely these keyboards were sending Note On with Velocity=0 before?
My problem with OS27 is that my Roland A-49 keyboard doesn’t work at all. There have been some changes to way that peripherals are powered, and the Mac is not powering the keyboard, even though it’s connected.
There is one thing we all missed: one can turn on Expert Mode in MidiMonitor preferences and see the exact data in hex format. In normal mode there is no difference displayed between NoteON vel0 and real noteOFF
|09:41:17.420|From Clarett+ 2Pre|Note On|1|90 4A 3D|
|09:41:17.531|From Clarett+ 2Pre|Note On|1|90 4A 00|
A possible explanation is that macOS used to normalise Note On, velocity 0 (0x90 nn 00, status 144) into an explicit Note Off (0x80 nn 00, status 128) somewhere in the CoreMIDI path before Dorico saw it, and that this behaviour changed in macOS 27.
(BTW. Pianoteq for example works just fine, interpreting Note On, velocity 0 correctly.)
That is the only change in my setup: same Fatar keyboard, same Focusrite interface, same Dorico version. Before the OS update it worked; after updating from macOS 26 to 27 it started hanging. So some change in the OS/CoreMIDI path is the most plausible place to look.
The Roland A-49 power issue sounds like a completely separate macOS 27 peripheral/power-management problem. It may also have appeared with the same OS update, but it is not related to the Note On velocity 0 versus explicit Note Off behaviour discussed here.
I am sure the @Ulf has already found what is wrong and a fix is planned.
I seem to remember that Dorico’s handling of Velocity=0 has been mentioned before (i.e. years ago); but I can’t find anything yet.
Well, of course.
Unfortunately not, I am currently busy with something completely different, but will come to this one here as soon as possible.
Are you a Monty Python fan?
Most certainly, yes. How about you?
I have been looking into this and am reasonably confident that this is indeed a bug in Core MIDI’s MIDI 2.0 support in macOS 27. My sense is that other apps might not be vulnerable to the bug because they’re only using Core MIDI via the MIDI 1.0 APIs. I’ve submitted the necessary information to Apple via Feedback Assistant for them to consider.
We will investigate whether a workaround is possible on the Dorico side in the meantime, but we are not in an ideal position to release a new Dorico 6.2.x update imminently. We’ll report back as and when we have more information.
There is a simple freeware workaround for this issue on macOS 27 using MidiPipe.
Download the latest version here:
http://www.subtlesoft.square7.net/data/MidiPipe.zip
After downloading, unzip it and move MidiPipe.app to the Applications folder.
Because the app is downloaded outside the App Store, macOS may initially block it because of Apple’s quarantine/Gatekeeper protection. If that happens:
- Try to open MidiPipe once.
- Open System Settings.
- Go to Privacy & Security.
- Scroll down until you see the message that MidiPipe was blocked.
- Click Open Anyway.
- Confirm again when macOS asks whether you really want to open it.
After that, MidiPipe should open normally.
I have attached a small MidiPipe patch that performs the workaround.
DoricoFIX.mipi.zip (1.8 KB)
It converts MIDI Note On messages with velocity 0 into explicit Note Off messages before they reach Dorico.
In the attached patch you only need to change the MIDI input and output:
- In MIDI In, select the MIDI input device you actually use.
- In MIDI Out, I recommend using an IAC Bus.
Using an IAC Bus is preferable to using MidiPipe’s own virtual output, because the IAC Bus is provided by macOS and remains permanently available once enabled. This means the setup does not depend on the order in which MidiPipe and Dorico are launched.
If you have not enabled an IAC Bus yet:
- Open Audio MIDI Setup.
- Choose Window > Show MIDI Studio.
- Double-click IAC Driver.
- Enable “Device is online”.
- Use one of its buses as the MidiPipe output.
Then, in Dorico, disable the original hardware MIDI input and enable the IAC Bus instead.
The signal path is:
MIDI keyboard
↓
MidiPipe
↓
Note On velocity 0 → explicit Note Off conversion
↓
IAC Bus
↓
Dorico
This completely fixes the hanging-note problem for me on macOS 27 while leaving Dorico playback untouched.
I installed OS 27 today and so far all works well with my regular setup - no problems with Dorico handing input from an NI KKS88, NI S61N and an Arturia Keystep 37.
However, I did plug in a Nektar SE25 and, like some others here, found all notes were sustaining. The Midi Monitor messages from all 4 controllers are attached.
All controllers are on mains powered USB, none are connected directly to my Mac Studio.
Mac OS 27 - 4 controllers.zip (13.1 KB)
Thank you for the solution! (Felt like a hacker!
)
For me, it resolves the hanging note issue, but not the chord input issue mentioned in the first comment
.
Also, I didn’t find how to “disable the original hardware MIDI input and enable the IAC Bus instead”, but since it worked, maybe Dorico did it itself?
So, still looking for a solution to enter chord symbols via the midi keyboard. I have a Yamaha digital piano p-115.
Does it not work even playing just one note for the “chord”?
Nektar keyboards seem to be affected by this in general. I arrived at my cottage that has GXP61 for note entry and had to use MidiPipe to be able to work.
Hi, this works! But do you have to save the Midpipe file for it to keep working?
When I close it, it stops working.
So, does the app need to be open for this to work?
Thanks
