Windows RT-WDM?

it seems most of my crash logs are to do with windows WDM according to @Martin.Jirsak . apparetly this is a know issue???

I’ve tried using the RT driver and my doremi midi device I use for expression stops working as does my drawbars I use with hammmond VI’s.

I also lose the RME midi inputs my 88 not keyboard is attached to, however it stil works it’s just not listed anymore.

So, anyone shed any light on how and why I’m getting WDM crashes and why RT doesnt work?

to put this into perspective, on the same machine I’ve run reaper all year without a single crash, litteraly not one with the same hardware

yesterday I had to reboot 4 times trying to working in Cubase :frowning:

TIA

It is best to use ASIO drivers with Cubase.

Hi,

Yes, this is on the Windows side. The WDM MIDI Driver is old and not maintained anymore. And there is a process, which crashes the MIDI Driver and takes Cubase with.

If you search for the WDM MIDI Driver here on the forum, you get quite some results.

The To WinRT or not to WinRT, that is the question thread might be interesting for you.

Unfortunately some (old) MIDI Devices don’t support the WinRT MIDI Driver.

This thread is not about the WDM Audio Driver. This is about the WDM MIDI Driver. Another story. :wink:

Oops, my bad!

@Martin.Jirsak both the devices in question here have been bought this year and work perfrctly in Reaper. Also My RME card was also bought this year and is NOT seen by windows RT midi.

Are you saying to get trouble free usage from cubase I need to get rid of these devices I’ve jut bought and set up and use only devices that use windows RT? that’s a big ask at the moment TBH as Reaper has run smoothly for over a year now.

I love Cubase and have been a user since the Atari days but I need stability and reliability as I run a professional studio. What changed from V 11? Cubase 11 ran perfectly and I have zero issues, C12 changed things and i was forced into trying out a different DAW as I couldn’t rely on C12 , it seems perhaps this midi WDM changed things around that time. It’s just strange another DAW can run with the same hardware without issue though

M

1 Like

Might try having something like Bome or Bidule run standalone and grab the device first.

Blacklist it in Cubase.

Use a virtual MIDI port to get the data in/out of Cubase.

if it’s blacklisted then it wont work, no?
Basically if i use the win midi RT driver I lose my RME midi and my expresion pedal from the Doremidi and the drawbars for my Hammond VI’s and also the X touch one stops working as well!!!

If the windows WDM is an issue for Cubase it should be made very clear that ONLY devices with windows RT midi should be used…or …a solution should be found. If other DAW’s can use windows WDM without issue then it show’s that it is possible .

M

Only blacklist the MIDI driver part of the device in Cubase by toggling it inactive in Studio Setup/MIDI Port Setup.

Always run Bome or Bidule ‘before’ launching Cubase.

Cubase should then ignore those MIDI ports, but Bome or Bidule grabs it instead.

Direct the output from your intermediary MIDI controller app into a virtual port.

Have Cubase listen to the virtual port.

While it’s a bit of a ‘work-around’ to hopefully avoid Cubase crashes. at least in this case, you’d get a huge array of excellent real time MIDI transforming features. All possible before the data even enters Cubase.

I’ve been using a Bidule that boots with my system for years for a variety of reasons. Now I can route and manipulate MIDI controller data in all sorts of ways before it ever touches the input of a DAW. I can also get around the problem of lousy USB/MIDI drivers that don’t do well with multiple clients (usually the MIDI IN ports). Fortunately, all of the virtual MIDI ports I’ve used to date have no problem supporting multiple clients.

This bidule shows my Keylab mpkII being diverted to some virtual ports A/B and C. On the C port in this case, I’m also ‘tansforming’ a bunch of messages in real time to run the transport and other things in Dorico and Sibelius.

I’ve also got bidules I can quick load for my wind jammers and other controllers.

I have my MIDI apps configured to ignore any devices I wish to route through bidule first. Instead of directly connecting to the devices, such apps use my Virtual Ports A, B, and C to listen to those controllers.

Meanwhile the home of that instance ‘routes and manipulates’ audio streams (Via ASIOLink Pro).

So, with the combo of Bidule, ASIO Link Pro, and some virtual ports, I can route MIDI and AUDIO (including WDM audio apps) among apps on my system at will (can also stream stuff over the LAN). I also get an OSC networking server/client in the process (comes in handy for using things like tablets and mobile phones as a remote in all my MIDI controllable apps) :slight_smile:

Several virtual midi ports options are out there. I’ve personally been using loopMIDI, and rtpMIDI for quite some time. I like them because it’s easy to name each port what you like, and there are not limits to how many you set up. It’s easy to add/remove them on the fly.

Bome is quite good as well, but I registered Bidule instead, as that thing is a beast of a sound designing and diagnostics/monitoring tool. It does WAY MORE than just work with MIDI streams. Also comes in handy for simple but essential things like chaining plugins, bridging in older VST2 plugins (at some point in the near future Cubase plans to drop VST2 support). It also gets my VST3 only plugins like HALion7 working in VST2 only hosts (Finale, Sibelius, Band in a Box, etc).

2 Likes

Brian,

Thanks for the detailed reply :slight_smile: I see you don’t use the RT midi either? s you have no problems using the windows WDM midi drivers?

My issue is I don’t know which of my devices is causing problems and switching to the RT driver means I lose a lot of them :frowning:

TBH I don’t have a complex set up either.
1 x 61 note midi keyboard direct via USB
1x Crumar D9U drawbar controller

1x DOREMIDI MIDI Pedal Converter MPC-10 which is attached via USB which gives me an expression pedal for the hammond volume pedal.

and finally my Roland RD 770- 88 note weighted keyboard that goes in via the RME midi port.

Basic stuff… and it’s all worked flawlessly in Reaper for the past year, so I’m at a bit of a loss as to why there’s an issue with Cubase? I mean Cubases whole trump card is it’s midi implementation , so why the issues?

Does everyone on windows here use the RT drivers? I’d not heard of it until now and I’ve been using Cubase since the 80’s… Bizzare…

M

Just to put this in perspective: I am only using the old WDM MIDI on Windows all the time. I have never used WinRT at all so far.
Of course that doesn’t help you. It is just a note that WDM is not broken within Cubase for all users.

Johnny, I suspect ‘most’ users will be using the WDM drivers as that’s the default setup, which is strange if there’s a known issue with WDM.

I only found out about this ‘issue’ recently when my crash logs were looked at by @Martin.Jirsak and he said there’s a known issue with WDM midi drivers and that was the cause of my crashes/freezes.

TBH, I started a new track yesterday and worked half a day on it with no issues , however I didn’t use any midi so that may be why.

I was surprised that this was even an issue as I’d never heard of it, so it would be interesting to see how many windows users 1: are using WDM and 2: If they have problems.

I need to look at this again when I get back to the studio tomorrow .

thanks for everyone’s comments though.

M

I’ve had those disabled in Cubase since I’ve never needed them to this point. I disabled them a long time ago because the RT ports were named a little different. They worked well as far as I know, but any time I opened older projects I’d have to spend time to ‘fixing’ the project to point to the proper devices. So, I just disabled it and never looked back.

I’ve had problems, yes, but I don’t think it was because of Cubase. It’s ‘windows/driver’ level stuff. Some kit simply comes with ‘crappy drivers’.

My number one beef is that every single MIDI controller I have ever owned that does USB>MIDI uses drivers that are NOT multi client friendly for the inputs. In short, the first app that runs grabs the thing and locks it down so nothing else can use it!

Having Bidule run when my system boots and grab these things has been my cure. Bidule forwards them to virtual ports. Apps get input from those.

What started as a simple fix for an age old problem with WINDOWS USB>MIDI drivers ended up becoming a power user dream come true though.

I can take a single dumb controller and make it very smart with bidule. I can spawn off as many virtual variations of said controller as I like over unique virtual ports.

I.E. I could do a 30/70 keyboard split over a virtual port named SplitMe1. At the same time, from the same controller, build a setup that compresses velocity a bit, and makes an X/Y crossfade from a single fader (Pick two CCs, make it so moving a single fader brings one CC up and the same time it brings another CC down) over another port called XYcomp, and so on.

Picking the ‘modifed/transformed’ variant I want is as easy as changing the input port for a track in Cubase. Same controller could even play/record two different armed tracks in unique ways at the same time!

There’s so much more. Bidule (and Bome too), also make it easy ‘merge’ multiple controllers into a single unified one sharing a port.
I.E. bridge the faders from three different devices, and the key-bed from yet a 4th one into one unified virtual port.

Another plus with Bidule is OCS support (send/receive events as network ip packets on localhost, or even over your LAN/WAN). Bring in input from a tablet or phone, and it can manipulate and send that to my MIDI apps too. It also comes in handy for having different instances of Bidule (or any other app with OCS support) communicate with each other.

So, in the process of curing a simple issue like, “This driver only supports one App at a time”…I end up with endless power user options.

Brian.
again, thanks for the detailed response. It seems like a lot of work to go through though to get a basic thing like midi working in Cubase though…as i said previously my hardware/midi all worked fine for the past year in reaper so it’s baffling there’s a problem with cubase.

I just spoke to pete Brown @microsoft and as a guy who works on the windows midi side of things he told me there isn’t ‘an issue’ with WDM apart from the fact it’s a bit old.

more confusion then…

I’m ging to send some of the crash logs to him at Microsoft and he’ll take a look, I’m going to send fabio @steinberg a message as well and speak to him, perhaps pete and fabio can sort this out between them :slight_smile:

talking of Bidule…i just did a search in my G mail and found my license file for Bidule from 2008 … I’ll install it tomorrow if it still works and have a play with it, it may end up being a positive thing in the end.

M

It is. On my home rig I have two keyboards, a Yamaha edrum kit and a faderport attached to my Cubase 13 machine (all via USB). I’m using the standard WDM Midi config and everything does what it’s supposed to do… and always has (on earlier versions of Cubase).
I’ve read about this apparent WDM Midi problem elsewhere on the forum but I’ve yet to see an explanation for why it occurs with some users and not others.

It has always ‘worked’ fine for me. The issue is that on Windows, a good 95% or more of ALL WDM USB<>MIDI drivers are NOT able to be used by multiple clients at the same time, no matter what hosts are involved (Cubase, Ableton, REaper, Sibelius, Finale, etc). This is a Windows/Driver level thing. In fact, USB<>MIDI drivers that somehow could be used by multiple clients were ‘breaking’ Microsoft rules in building drivers. When drivers follow the MS ‘rules’, the input side of the driver goes into ‘exclusive mode’ and the first app to grab it, locks it down, and owns it. Nothing else can connect.

So ‘my issue’ was…I need to run Two or three hosts at the same time on my system. I.E. A scoring APP, a tracking DAW, and maybe even an instance of Band in a Box. I don’t want to need 3 different controllers plugged in to do this!

There has also been quite a lot of hardware released over the years that doesn’t include RT drivers, so it’s single client WDM or nothing.

As for the RT thing, those have always worked for me too. Thing is, WINDOWS gave those ports slightly different names from the WDM drivers I had been using for near a decade. I was too lazy (and embarrassed when it happened in front of clients) to fix that every time I revisited an old project. If one more random client who uses a system maybe 4 hours a month for realtime multi-media gave me the “This wouldn’t happen if you’d switch to a Mac” speech I feared I might toss cookies on the console.

Cubase does do some things ‘differently’. I use several apps with a Plogue engine under the hood, and it’s obvious Plogue and Steinberg have taken different approaches to some things. I haven’t used Reaper in years, but no surprise they take even a different approach.

I suspect Steinberg have valid reasons for designing it the way they have. It has a unique way of grabbing all the ports on a system and offering the ‘ALL MIDI IN’ option with filters. Other apps I have used aren’t quite as intuitive and efficient in that regard. While they ‘can’ deal with complex setups involving multiple controllers and apps, they typically cannot do it ‘out of the box’ after the first installation. Users must go deep into settings and set it all up. In contrast, Steinberg hosts just ‘do it’ right out of the box. For 98% or more of the customer base, it ‘just works’ as intended.

Still, for my own personal reasons, I’ve chosen to bypass Stienberg on that first level when it comes to MIDI controller . I still rely on the Stienberg MIDI engine for nearly everything else .

It’s possible to merely install a virtual MIDI port, and use empty cubase MIDI tracks to process things the way I’m doing in bidule, forward MIDI to other apps this way, and so forth. Cubase MIDI tracks are pretty powerful in their own right. Still, for me, a third party utility like Bidule or Bome is well worth the ‘trouble’. If it were only a band-aid to fix a small issue I’d be more upset. Ultimately, I’m thrilled that the ‘problem’ led to the realization that I could have a MUCH better set of options and workflows.

I have no clue what the deep issue is with your system. No idea who if anyone is at ‘fault’ and responsible for ‘fixing’ it.

In my experience, every single DAW out there has ‘sensitive’ areas. The ‘older’, bigger, and more bloated a DAW is, the more likely it is that some things can go wrong and might never really get properly fixed. I suppose the logic is…“Out of tens of thousands of customers that run this, only 2 have an issue. A workaround exists, so we’ll give them that and move on rather than having the team spend time/money on this one.” Really, I don’t know…and I’m not about to say that is ethical or proper, but I do believe that it happens often in the software world.

What I’ve offered is a ‘possible’ solution. In my case, hooking MIDI controllers directly to the Steinberg engine ‘works’ fine, but it’s crippled when compared to the Bidule setup I’ve been using. I get features and abilities of $3,000+ controllers using sub $500 gear. Bidule was not ‘free’ to register, but it turns out to be the most used plugin in my arsenal for a load of reasons beyond snooping/routing/manipulating MIDI. The small expense, and minimal ‘trouble’ has paid for itself thousands of times over given everything it brings to the table.

1 Like

I’m i missing something here , are you not using the RME midi driver ? Mine works flawlessly and has done through every version for the last 16 years .

In case anyone’s not aware, WinMM and WinRT MIDI are going to be replaced in the not-too-distant future by a new architecture called Windows MIDI Services, which is a complete rewrite which will also support MIDI 2.0 devices. I’ve found both WinMM and WinRT MIDI problematic in their own ways, but WinMM is least worst for me - the naming convention on WinRT is buggy and confusing. I’ve been using RME PCI(e) cards for years and I’m not aware of any compatibility issues with their cards and WinRT MIDI, but I’ve not tested it with the new card I’ve just bought.

More details on Windows MIDI Services here: GitHub - microsoft/MIDI: Windows MIDI Services

1 Like

Is there an actual separate midi driver that’s needed to install for the RME? it was always plug and play with the WDM drivers and it just works.

If i switch to the RT drivers the RME just dissapears… it still works though…perhaps as it’s a PCIe device it gets renamed . That’s another issue with the RT drivers…I get a list of ports just labeled:

Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen
Ryzen

what are these?..

M

The RME driver installer package for your interface will have the drivers built-in for your MIDI ports on the card, there are no separate driver packages you need to install. Are all these ‘Ryzen’ devices appearing on the Windows Device Manager or in the MIDI setup in Cubase?

Um it’s all one package , dunno mate if the RME shows in the device manager then there’s no reason why it shouldn’t work with Cubase BUT you may think i im picking but just being honest , the last 5 ive downloaded AA plugins it’s wiped out my midi and ive had to force the TM to find them again . just a thought

Rme midi