I have been investigating an issue with stuck notes when using the sustain pedal in Cubase with Serum 2. I have been testing with the latest build of Cubase 14 on macOS 14.3 and Windows 11 and Serum 2.0.16. This issue is only present on Windows.
I could get a stuck note by re-triggering the same note with the sustain pedal down. The problem appears to be down to mis-matched noteIDs. Here is what I am seeing in Cubase with a debugger attached (I’m using example note IDs here but you’ll get the idea)…
Press C3, plug-in receives note on message, ID = 1
Release C3, plug-in receives note off message, ID = 1
Press C3 again, plug-in receives note on message. ID = 2
Release C3 again, plug-in receives note off message, ID = 2
That’s all good. Then…
Sustain pedal down, plugin receives CC64 message val 127
Press C3, plug-in receives note on message, ID = 3
Release C3, plug-in receives note off message, ID = 3
Press C3 again, plug-in receives note on message, ID = 4
Release C3 again, plug-in receives note off message, ID = 3
Release sustain pedal, plugin receives CC64 message val 0
So the plug-in still thinks a key is held, because it hasn’t seen a note off with ID = 4, hence stuck note. Once again, this issue is only present on Windows. When I tried this on macOS, the second note-off message had the correct ID when sustain pedal was held.
Apologies, I should have said Serum 2 is a VST3, so it is receiving VST3 note events, which do have a noteID. I have been debugging in Xcode on Mac and Visual Studio on Windows. I am looking at the events the plug-in receives from the host in the process() call, in ProcessData::inputEvents.
Are you encountering the same behavior with other VST Instruments? Could it be that there is an issue with Serum 2?
If you disregard these ID numbers, which I do not believe are sent from the host, everything looks correct.
In VST3 each NoteOnEvent has an ID. This ID is indeed generated by the host.
VST3 works slightly different then MIDI. In MIDI 1.0 a NoteOff basically silences one of the 128 pitches. In VST3 it silences an individual note event. In theory you could have overlapping note events on the same pitch with VST3.
This is consistently reproducible. Something to note is that it only happens when MIDI data is coming from an external source (i.e. my MIDI controller). It doesn’t happen when MIDI data is being played back from the Cubase sequencer. I have tested with a Novation Impulse 49 and a Novation 25 SL MkII, using an M-Audio SP-2 sustain pedal. Other Serum 2 users have reported this with other controllers though, so I think we can rule out it being specific to the controllers I am using.
This issue can only be demonstrated with plug-ins that don’t disregard note IDs. One such is the note expression synth example plug-in which comes with the VST3 SDK. You can build this yourself and debug in Visual Studio. Even though it doesn’t respond to sustain pedal messages, you can still get stuck notes with it if you use the sustain pedal owing to mis-matched note IDs. Build and instance it in Cubase, then follow these steps:
Depress sustain pedal
Play C3 on MIDI controller, then release.
Play C3 on MIDI controller again, then release, note continues to play.
Release sustain pedal, note continues to play.
Look at the debug output of note expression synth whilst doing this and you will see why the note sticks, here is an example from when I tried:
NoteOn :203
NoteOff:203
NoteOn :220
Voice for kNoteOffEventNotFound : 203
This matches what I originally posted, the second note off event has the ID of the first note on event.
I think I’ve provided everything I can to make a case for this being a bug in Cubase. I have given steps to repro and debug. If you try this and don’t get the same results I’d be interested to hear.
Please do not wait for me. I am not into coding too much and I don’t have anything that can send Sustain data. I will not even try to reproduce it. But I can maybe help to bring this to the attention of the people who can.
Can you kindly please ensure that you are using Cubase 14.0.20 build 240? You know, the term “latest build” is often not helpful enough.
Indeed I have been testing with Cubase 14.0.20 Build 240 (x64). Once again I only encountered this issue with the Windows build.
Much appreciated. I was under the impression this is the best place to report potential bugs to Steinberg, but if there is a better way do let me know.
I don’t know how Halion is handling note IDs and sustain internally, it may be doing something to handle the mis-matched note IDs. Without that info I cannot say whether this would be an issue with Halion or not.
Try with the note expression synth example plug-in from the VST3 SDK, as I mentioned. Debug and look at the note IDs received from the host. Tell me if you do not see what I reported.
have the exact same issue with Cubase 12 and Serum 2 with an Arturia KeyLab 49.
I have never had that issue before, and Serum 1 does not have that problem.
The way you described it is exactly the right way to reproduce the issue. I would add a few things to that (let me know if that’s your experience as well):
The problem doesn’t just show up when you play a single note. Any note that is played twice or more during one phase of sustain pedal down will be stuck, even if you played many other notes in between.
It does not happen on patches using the arpeggiator. When notes are stuck, enabling the arpeggiator will unstick them. Playing the note again after it has been released by the arp, it will be stuck again.
While a note is stuck, after disabling (not bypassing) the plugin and re-enabling it, the note will still be playing. After bypassing the plugin and re-enabling it, the note is not playing anymore. Hitting the note again, it will be stuck again.
The only way I’ve found to unstick the note for good is to re-instantiate Serum. Anything else I’ve tried will just have the note stop playing, but the problem comes back as soon as you play that note again.
You say that you’ve seen this issue discussed before. Can you point me towards it? This is the only thread I found on Google. Also, do you know if this has been reported and acknowledged by the devs?
Serum 1 ignores note IDs, so this is to be expected.
It does not happen on patches using the arpeggiator
When the arp is enabled in Serum 2, the sustain pedal controls arp latch instead of note sustain, so this is also expected. Owing to this, Serum 2 kills any sustained notes on enabling the arp.
You say that you’ve seen this issue discussed before. Can you point me towards it?
It was reported in the Serum forum on the Xfer website and also in the Serum users Discord. I have not seen it discussed anywhere else though.
Also, do you know if this has been reported and acknowledged by the devs?
I am one of the Serum devs. This thread is my attempt to report the bug to Steinberg! Is there a better way to do so?
Serum 2 is not the only instrument mentioned, read above where I write this issue can also be demonstrated with the note expression synth example plug-in from the VST3 SDK.
This is an important bug as soon as more developers start using note ID.
This developer is just the first to use it and stumble upon this bug.
Hope they pick it up and fix it!