The future of WoA, MIDI 2.0 and ASIO on Windows

I don’t recommend disabling Defender. That’s why I put in the step-by-step instructions for how to add exclusions to real-time scanning. :slight_smile:

Pete
Microsoft

Ahh, ok. If you’re using AVB that makes more sense why browser activity might be a factor, assuming it’s connected to your network port.

And yes, if you have a very old machine, then I understand why you might hit some performance limits.

Pete
Microsoft

Are we saying that specific classes of device(s), are going to be able to support MIDI 2.0 (with or without backwards compatibility), and that a native driver, will work directly with device drivers on the OS, which may also support Multi-Client operation?

Thanks for the reply, @Psychlist1972 !

If internet connections are disabled though, is there still a risk?

I was thinking, all things being equal, why not minimize potential slowdowns by safely keeping Defender from using resources …?

Hi @emotive !

I looked at a few links, Microsoft PC Manager looks very interesting!

Can you give a word or two on how to “link” the two please?

You will have to install it and see!

It’s a fine piece of software that has made my life easier, but it can take some time to detect that the real-time AV component isn’t currently active.

Thanks @emotive

Do I gather correctly you’ve got an old rig?

Mine is a 2014, I haven’t read about much older on these forums (though I’ve updated it with SSDs, more RAM, etc. ).

I wasn’t implying a potential outcome that far with my post, my main point in that post was that there are a bunch of devices on the market that use Thesycon-based drivers, far more than perhaps many of us realized. I’m kind of surprised. And since at least two of those Thesycon-based drivers already support Arm64 natively, it’s obvious Thesycon has done a lot of work already under the hood. And that’s a good thing, and bodes well IMO in general. Speculating forward, that MIGHT also mean some (or hopefully many!) of those other devices with Thesycon-based drivers are much closer to native Arm64 support than perhaps we thought. Again, a good thing in theory.

It would of course be great to get confirmation from some of these audio device developers and get official word. So I plan on reaching out myself and seeing what some of them say. If I hear anything back, I’ll post.

Now I don’t know how much effort the extra bits (GUI, mixer, routing, DSP, MIDI features, etc.) on TOP of the Thesycon-based main driver the developers will have to make 100% Arm64-native. And again, perhaps they are working on it, perhaps not, who knows? But my observation was that clearly a lot of core work has already been done by Thesycon, and the last customizations to the unique versions of the Thesycon-based drivers could theoretically (cross fingers!) be in the pipeline, subject to whatever development/licensing deals those hardware manufacturers have.

In other words, things might be coming along better for Arm64 than it may appear on the surface, and that’s not including the work MS is doing on their in-box driver and other improvements to Windows in general for better pro audio support.

I’m also just trying to get a better sense for when DAWs on Windows/Arm64 laptops will be at the level I would like for my own use cases. Cubase/Nuendo on Arm? Check! Bravo! Steinberg drivers? Check. RME drivers? Check. MS in-box driver? In development! Other improvements, MIDI 2.0, etc.? In development! Most notably, for me, is that iLok support is still missing (but it’s being worked on!) and more audio devices need native Arm64 support (and that’s being worked on too, potentially in a big way), so things are looking better each month IMO.

Looking like this is a big year for Windows on Arm!

It’s kind of odd to consider the “multiple apps through the same [ASIO] endpoint” on MacOS because I’ve never NOT been able to do that. It’s not a consideration, so I’ve never had to stop and think how I would have to change my workflow. I’ve have Ableton, C14P, and N14 all running simultaneously, all concurrently using core audio (UAD). I can play what I want when I want, and can even have all apps playing at the same time. Same with WL/SL and other 3rd party apps like Fission which I still use.

I’m sure I could not do that and work around it, but I like not even having to think about it (FWIW).

2 Likes

On a related matter, I’ve similarly always been able to use aggregate devices with macOs, so that for example if I want to aggregate my Zoom H6 and Zoom H8 for some on-location fun, I have a compact 16 track mobile recording rig, all of which can (since Apple silicon) run on battery. I don’t mean to add irrelevant stuff to this thread, more to point out what WoA needs to match to make it a compelling choice, and I hope it can.

Steve

3 Likes

I will never recommend to folks to disable system-wide protection on any computer. It completely depends on your habits, what random USB drives you plug in, how secure your local network is, etc. The disabling of real-time scanning for specific locations was included to address this very concern. Scanning is event-driven. If you’re not writing to a place it is set up to scan, you won’t have a performance hit of any sort.

Edit: I also hate for folks to feel they need to disconnect something fundamental like Internet in order to safely use the PC.

Pete
Microsoft

1 Like

Aggregate devices are not in scope at this time. I get the reasons why they are useful and needed (so no need to explain), but it’s just not something we have resources to do at the moment.

On Windows x64, you can use tools like ASIO4All to aggregate devices. There may be some equivalent to that functionality in the future, but it’s not in immediate plans. We’re focusing on making ASIO performance and experience excellent and at least on par with what folks have on x64 today, but without having to go download a driver from somewhere.

Pete
Microsoft

2 Likes

Thank you for your quick and unvarnished reply - appreciated.

Steve

2 Likes

Hi @Psychlist1972, I was wondering, since the Windows Audio services, also encompass MIDI, can these services one day be separated so that MIDI devices can be used independently of audio devices?

When I set a system up, I always turn off windows audio, since if you don’t, it means you need to manually disable devices, notwithstanding issues associated with changing ports; it would seem rather a cumbersome arrangement so for WoA, as well as future Intel/AMD systems, it would be great if MIDI could work on its’ own and not be dependent on Windows Audio at all.

Regards,

Garth