With Windows MIDI Services running, there’s no real advantage to using WinRT MIDI vs “Windows MIDI” (WinMM).
I need to double-check (Gary did the re-plumbing for WinRT MIDI 1.0), but I don’t believe MMCSS is used in the same way anymore. But don’t quote me on that just yet.
Reading through this, the only issue is the port sort order, right? It may simply be that the Steinberg code sorts the results when it’s one set of code, and not the other. The code paths for enumerating the devices are going to be quite different, even if the displayed results look similar.
Edit: I see the sort order is what made you decide to use WinRT MIDI, but it results in a hang. There’s a fixed issue (I need to see when the fix goes out) where WinRT MIDI calls don’t start up the service. But if you’re already seeing devices, then the service must be running so this may not be the issue.
On Port Naming: Under Windows MIDI Services, the port names for WinRT MIDI 1.0 and WinMM MIDI 1.0 are identical.
Only kernel code can overstay a DPC (a DPC itself is perfectly normal for getting work done in the kernel). Common causes are GPU drivers, and WiFi drivers when you aren’t close enough to the WiFi access point. Gaming RGB lighting and network accelerates are also common causes.
Finally, Power Management is increasingly a big one. When working in the DAW, always go into Windows Settings and set performance (it’s under Power Management) to “Best Performance”. This works somewhat differently from the old power plans, depending on your processor generation.
Thanks for the clarification! In terms of DPC, I am referring to the “overstay” you mention, specifically one that we pursued over a year ago that was provably occurring every 15 minutes (with a few seconds) that ultimately appeared to be related to Windows Diagnostic. Of course, if it were not causing audio issues, it never would have been pursued.
Concerning GPU drivers, it seems unlikely that the 15-minute interval would be related to GPU, but anything is possible, I suppose. There’s an old thread about it where several of us were experimenting. To the point where some of the analysis “tools” we were using may themselves be an issue, this further illustrates the difficulty with end-users troubleshooting these issues.
At any rate, I am using the NVIDIA Studio driver and keeping it up to date (currently 596.36) in case that’s helpful. The GPU is NVIDIA RTX3060.
You were probably referring to the VSTs as causes for Cubase crashes, not DPC. Apologies for conflating the two!
It’s not really solved, I found a workaround that avoids the problem - but the problem still exists and should be looked into.
But then also, because of the problem-avoidence workaround, there is a secondary problem of my MIDI ports not being sorted alphabetically in the MIDI track input/output selection menu.
I’m not sure if this documentation will shed any light onto your situation. Read the “Drawback of WinRT MIDI” section.
Are you able to provide some insight into why “WinRT” is essential for your setup ?
I’m just curious because I have always had the “Use Device WinRT MIDI” setting disabled in Cubase and I have never had any issues with external hardware or MIDI port number / ordering. Shouldn’t something like a USB MIDI I/O allow you to use all of your hardware devices without any issue ?
I’m just trying to understand your setup, external hardware and Cubase settings a bit more in depth, because I don’t really understand much about this topic.
Hey @wavefunktion , I described this briefly in an edit of the OP.
With ‘Use Device WinRT MIDI’ disabled, all the MIDI ports in the MIDI/Instrument track input/output selection menu were out of order.
So I randomly without knowledge of what it was, tried enabling the WinRT setting as I read something about it using a different sort methodology (sort by device grouping then alphabetically).. And that fixed the port sorting in the track input/output menus
With WinRT MIDI disabled, my port menus look like this:
No. It’s just the names on the mio make it look especially bad. Here’s mine (I can’t try WinRT MIDI here because I have a private build that uses MIDI 2 when that option is selected)
WinRT MIDI doesn’t have any concept of a port number – it’s a WinMM “Windows MIDI” thing.
If they were to sort it by name, you’d have some issues, like the three U6MIDI Pro ports (14, 15, 16) would not be next to each other when using the default WinMM naming scheme.
Ah interesting, so you’d say the problem is hardware side on the MioXL?
Maybe Steinberg having a ‘Sort by ‘Show As’ Names’ option would be good, in the event hardware port numbering is weird? Because I’m not sure it’s something iConnectivity could change now without messing up all their clients setups.
From what I understand, Cubase already unifies saved project MIDI Track Input/Output port names with user ‘Show As’ names, so you’d figure they would be able to sort as well?
Why is in WinRT MIDI sorts them properly, but with it off, it doesn’t?
We create the ports in the order we see them, so it’s part hardware, and part what else you have going on on the system.
If you want to see the order we see ports for a device, open up a console window and type midiksinfo. That’s the device information before the service processes it.
Presumably because WinRT MIDI used to not use the ugly compatible names (it actually had worse issues where things like the MOTU would just have 16 ports named “MIDI”) and it doesn’t have a natural order (no port numbers) they sort it.
Cubase doesn’t know what style of name you are using, so that won’t matter.
When they switch over to the new SDK, this will also be less of an issue because the new SDK makes it easy to get parent device information for grouping.
Are you replying to my comment/idea on utilizing ‘Show As’ naming for alphabetical organization?
Because they do indeed use the ‘Show As’ name as a reference for connecting to saved track in/out ports.
For example, when I was switching back and forth between WinRT MIDI on/off, it would reset the port the names in setup, thus breaking connections to the saved selected track in/out ports for the project. All had to do was rename the ‘Show As’ names to be exactly the same, reload the project, and they’d all reconnect.
So my idea is to have an option in setup to organize track in/out list based off ‘Show As’ names.
But perhaps, this won’t be needed with the new SDK?
You posted a screenshot showing that you have selected the option to use new-style names. I said Cubase doesn’t know you’ve done that. It just sees the resulting names.
Thanks for the info, but i’m just also wondering about how @awesomeaudio will know when this fix will be downloaded and installed onto his Windows 11 OS ? Is this fix tied to a Windows Update Knowledge Base (KB) number at all ? Or will we need to be reliant on you to inform us ?
I am just curious to see whether this update will solve his Cubase application hanging issue or not.
Awesomeaudio is on the Discord server, and that #key-release-updates channel has a post explaining how the rollout works, and when the fixes go out.
I don’t know the KB # until shortly before the fix goes out, and I update the posts there with that information when I have it. For example, here’s April:
I get that folks don’t all want to join the Discord server, but we’re a super small team, and I post the stuff on that server so I don’t have to keep answering the same questions multiple times everywhere on the internet (here, cakewalk forums, gearspace, KVR, reddit, etc.).
