Hung notes when using Unify Midi Filter with input from multiple midi channels

@nico

Excellent sleuthing, and thank you so much for including a complete set of tests!

You've found an important limitation in MIDI Filter -- It doesn't handle cases where the same note (MIDI note number) is active on more than one MIDI channel. I'll work on this and devise a solution to include in the next release.

In the meantime, you can use the work-around illustrated in the attached modified version of your patch, where I replace the single MIDI Filter instance with two, wired in parallel inside a ComboBox. One filter isolates MIDI channel 1, the other channel 2.

@getdunne

Thanks for confirming the limitation and the new test patch.

Your workaround proved successful when playing single notes (which, because of MidiBox of course became multiple notes).

In my additional testing however, it seems that stuck notes also occur when the Midi Filter receives multiple note on events on the same midi channel in quick succession?

To do that I played a whole bunch of notes very quickly on my keyboard (a very rapid three finger arpeggio was able to reproduce the issue reliably for me). The result of the rapid three finger arpeggio each triggering a MidiBox multi-channel midi note stream creating an even higher onslaught of midi notes.

And just to eliminate ComboBox as a potential wildcard, I've implemented your workaround idea by having a separate Midi Filter in each layer (see attached patch).

The midi monitors (also added on each layer in front of Midi Filters), seemed to confirm that each layer only sees notes for its designated midi channel. - But I still got stuck notes when rapid fire playing and MidiBox active.

Just to be sure, I also tested with and without selecting the respective midi channels (1 vs 2) in each layer's Midi Filter, but that also didn't make a difference in getting stuck notes with really rapid fire playing.

Some keyboards don't send note-off messages in between rapid-fire note-ons. This can confuse a lot of software.

The new "Multiple Note-On events" checkbox in MIDI Filter will re-insert these missing note-offs. Give that a try, please.

Posted by: @getdunne

Some keyboards don't send note-off messages in between rapid-fire note-ons. This can confuse a lot of software.

The new "Multiple Note-On events" checkbox in MIDI Filter will re-insert these missing note-offs. Give that a try, please.

Tried it (as per attached patch), but still produced hung notes when rapid firing notes at it.

@getdunne

Update: It gets even more interesting - another scenario for hung notes when the note number is the same, but the channels are different.

This time without Midi Filter, but with Unify in Unify. And just two notes with midi note on and off events separated by at least 250ms.

The attached MidiBox file "Hung Notes - Unify in Unify.mid" needs to be put into the User Library > MIDI Files folder.
It has just 2 overlapping notes with the same note number, one each on midi channels 4 and 3; The notes start and end about 250 ms apart at 120 bpm.

The also attached test patch "n5 test unify in unify pad" contains a Unify in Unify to illustrate the hung notes. This time it uses the Unify sampler with a pad sound from the standard library.

I've also included a screen capture of the test case with the 4 midi monitors showing what I get when letting the MidiBox play the file once (i.e. just sending the 2 overlapping notes on different midi channels) It shows:

• The first Midi Monitor right after MidiBox already surprised me with an apparently duplicated note off event. But the other events are consistent with the midi file being played and the times displayed are consistent with what I expected at 120 bpm.
  • Channel 4 note on - expected
  • Channel 3 note on - expected
  • Channel 4 note off- expected
  • Channel 4 note off- unexpected - where did that duplicate event come from -- although in theory it shouldn't hurt?
  • Channel 3 note off - expected
• However the midi monitor in the parent Unify INST 1 layer shows more surprises (wrong channel for one of the note off events and the other note off event just disappeared).
  • Channel 4 note on - expected
  • Channel 3 note on - expected
  • Channel 3 note off- unexpected; this should have been a channel 4 note off at that time
  • nothing else - unexpected
• And the two remaining midi monitors are consistent with the prior midi monitor (including the mistakes)

The stuck notes behaviour for this particular scenario was similar using Unify as VST 3 in Cubase without MidiBox, but using a Cubase midi track with the exactly same events as the MidiBox file.

And a couple of assorted observations during the many hours trying to trim complex patches and midi streams to simplified repeatable scenarios. But my experience wasn't always consistent and easily repeatable - also some things at times behaved differently depending on using Unify standalone or the VST3 version).

• It seemed to me that inserting Midi Monitor at times changed the flow of midi events in some way
  • i.e. a hung notes scenario might not have hung notes after inserting a Midi Monitor.
• But removing that midi monitor again didn't seem to restore the original behaviour.
  • Sometimes it seemed like removing an empty midi layer would change things back, but not always.
• Removing the empty midi layer, saving the patch file and reloading it seemed to get me to the original state prior to loading midi monitors.
• Using Unify as VST 3 in Cubase, the Midi Panic button didn't seem to pass through to the child Unify, while in Unify standalone, it generally would.
• Generally the Midi Panic button was more reliable in stopping hung notes during my testing than the Stop Latched Notes button (which may point at different internal scenarios of hung notes).

Hi Shane, is this still on your radar, or is it a low priority?

From what I can tell it's not a common problem for driving Unify from a single keyboard controller sending note data on a single midi channel - which I assume is the huge majority of use cases for Unify.

Simultaneously flying in note data from multiple midi channels ends up being something more common for a guitar to midi interface, where each string sends data on a different midi channel. And the same midi note but set on different channels can overlap.

It's ok if it's not a high priority item - but I'd like to know, since then I'll spend some time to look for a different way to achieve the thing I had been after: Creating and playing a sampled 12 string acoustic guitar from a 6 string electric fitted with a Fishman TriplePlay pickup.

The reason for needing multiple midi channels is that the lower 4 strings E-A-D-G on an acoustic 2 string have octave twins, while the 2 highest strings B-A are doubling up on the same pitch. So the same midi note may need an octave or not, depending on the string it is played on. That's why multiple midi channels to show the originating string are essential.

But the real prize I'm after is much beyond the simple 12 string guitar idea: The multi-channel guitar input idea can also lead to amazing other layered sound possibilities, that's why I'm fascinated by the idea of using a guitar as midi input as a new sonic horizon when compared to a midi keyboard: Same note, but different sounds, depending on the string being played. On a keyboard it would be impossible to achieve the same thing, since one hand doesn't easily reach 6 different keyboards simultaneously. In theory Unify could be the natural target platform for such a sonic palette, but for now the hung notes across channels have killed that idea.

@nico

Updating the MIDI filter to deal with multi-channel data is on my list, but there are more pressing issues, so priority is not high.

For now, I suggest you concentrate on setting up patches with six layers, each on a separate MIDI channel. The work-flow may not be ideal, and you may end up using more plug-in instances than would be optimal (rarely more than six), but you should be able to achieve playable results.

that sounds good - thanks Shane!