SilkTone
Yes I was also talking about the WinRT API (for all hardware), not Windows RT (Windows build for ARM only) which is a dead horse. The WinRT API is supposed to be the feature for both desktop and "modern" apps. However I'm pointing out that it has a very music-unfriendly foundation as MS ripped out things that are required for low latency audio. We no longer have the ability to change thread priorities. All low-latency audio APIs have been removed, leaving only WASAPI shared mode.
 
Also, the async/await pattern permeates the WinRT API. It doesn't work with traditional thread locking primitives (due to that it now results in a compiler error if you mix the two). Async/await also causes thread priority inversion, which is most likely why they removed all ability to change thread priorities, and hence had to remove WASAPI exclusive mode also [read: It isn't going to be easy to fix it after the fact].
 
I while ago I did an extensive set of micro benchmarking showing how async/await kills performance. I first realized there was a problem when I tried to port a real audio application to a "modern"/metro/toy app. Yet if you read Windows dev blogs etc people are going gaga over async/await.
 
It is somewhat concerning to me.

Hey SillkTone! As Noel mentions, our team has been engaged with Cakewalk folks (including Noel) about our Windows 10 enhancements. We are hoping to talk about this in much more detail at this year's //build conference. We definitely are aware that low latency is very important in this area. As Pete Brown and I mentioned in our talk at //build last year (something like "Sequencers, Synthesizers, and Software Oh My!"), this is an area that we recognize we dropped the ball in Windows 8 and Windows 8.1.
 
To succeed in getting new apps on all our platforms, we _have_ to solve this problem. We will be pushing the ball forward in Windows 10 and continuing to push push push in future updates as well. This will be an ongoing focus of our audio team as we strive to get it lower and lower and solve the problem in a way that is satisfactory for running apps in a shared multitasking environment. 
 
Can you shoot me an email at jasolson AT microsoft DOT com? I would _love_ to connect you with the PM on our team driving our efforts in this space so we can make sure your voice is heard directly on the team. Especially given your experience in trying to port apps, we really want to hear more of the frustrations you ran into. And we definitely want to hear about your benchmarking with WinRT APIs to ensure future plans on our end don't succumb to the same issue. As WinRT is basically COM + Metadata, and COM can be a very chatty protocol if not careful, we will need to stay on top of that. 
 
Thanks for your effort in the past SilkTone! I only wish we would have had our ears to the ground with Windows 8 and Windows 8.1. There's a lot of work for us to do to repair these issues, which is one of the reasons I'm so excited we have an entire team now dedicated to "Media Creation" and can focus on issues like audio latency and MIDI :). 

I have the 10074 version installed.  Compared to Windows 7 or 8.1 that are on the same PC (it is triple boot 7/8.1/10 each on a separate hard drive) it is slow.  On line apps that are almost instantaneous on 8.1 take minutes to load.  Updates fail the first time the install is attempted, takes two or more attempts to install.  I have nothing extra installed on my Win 10 other than Sonar (for testing) and the driver for my Roland Studio-Capture (and it works).   I realize Win 10 is still "beta" but these are basic functions, not functionality that may be added in the RTM version.