Hi,
After debugging a problem I’ve encountered in my setup I finally narrowed it down to midihub eating note offs for me in certain situations when notes are overlapping.
In this case I am sending notes that are stacked on top of each other in Cubase, and Midihub discards all note offs but one no matter how many note ons there are. I know Studio 1 can also send multiple overlapping notes like this, and it causes one of my synths to get hanging midi notes when I do this, either on purpose or by accident. I’d very much like these note offs to remain to prevent this problem for me:
I got the same issue on my setup where I also get stuck notes if overlapping notes occurs (like playing along to a midi playback). Midihub silently dropping NoteOff after logging them in Midi Monitor wasn’t obvious as I did my troubleshooting. I’m thankful for Shor discovering this!
Behaviour can be observed by routing USB A → Virtual A → Midi A:
Just wanted to add to this, I’m guessing it’s the same root problem -
Running one arppegiator into a second arpeggiator it’s quite common to make this happen.
I did reproduce this with arpeggiators set up in…creative ways. So yeah I’d think so.
This should be very easy to reproduce, and I hope we have a fix coming for this, as it does make midihub unusable for certain things.
Did you manage to reproduce this?
Meanwhile I also noticed another behaviour where events were filtered.
If you send a note on with velocity 0 (yes I know this is note off really with velocity 0, but I made a pipe where I wanted to use note on velocity 0-127 for logic operations, not to send out as notes in the end), midihub filters it out if you start a pipe with the virtual port you send it to.
I.e.
Event->Transform into Note on with velocity 0 → (monitoring here shows my event just fine) → Virtual A
New pipe:
Virtual A (here it is gone, and ideally I’d like it if nothing was filtered here so I could use my newly created event for other logic).
Can you confirm these? Also any chance these earlier posted bugs can make it before christmas? Unfortunately for certain things, this means midihub is unusable with some hardware.
Fixing this has a couple of implications that are difficult to predict… I’ll send you a custom firmware build with a fix, so you can test it out and see if something unexpected appears.
So far so good.
Tested just my specific cases, and will try out some more later to see if I run into any other issues due to this, but yeah…right now it works exactly as I’d hope!
So for the note on with velocity 0 getting filtered out on the device from my virtual port, this works now: