Yes I use the menu at the top of this forum and it was hard to find through that set of links. 
No matter,  they should still fix that because it would make more people aware of its existence. 
I even used Google and all the pages where about the older version, so that's bad too. 
 
And that little comparison chart would be super handy but without the link you posted you'll never find it. I was not even sure that TTS-1 was included until i saw that chart. Then I installed it to a fresh machine with no other prior versions and now I know exactly what is included plug in wise. 

Cactus Music
So if anybody else reading this has bought HS and is running Windows 10 could you please try the test.

FWIW, I did a real-time test of ASIO vs. WASAPI Exclusive latency in Platinum under Win10 using a different method (looping back SONAR's metronome, and using a delay to make it null with the direct output from the metronome one measure later). Doing a real-time nulling test eliminates any possible effect of record compensation or the driver incorrectly reporting sample position to SONAR.
 
I tested with a 128-sample buffer (2.7ms at 48kHz) which is as close as ASIO can get to the WASAPI Shared buffer of 144 samples = 3ms.
 
With a 128-sample buffer, the MOTU's measured ASIO Roundtrip is 7.2ms. This has been previously verified using CEntrance latency tester so I know my null-test method is valid. Call it 7.8ms if it were possible to set a 144-sample buffer.
 
In WASAPI Exclusive mode, the actual measured Roundtrip is 15.5ms - twice the ASIO latency.
 
So ASIO still spanks WASAPI at an equivalent buffer size, and I can run easily run light projects with a 32-sample buffer on this machine which gives a 3.2ms actual RTL - little more than a fifth of WASAPI's best time.

I just tried a loopback test, playing the metronome out from the computer earphone jack to the laptop's internal mic input. Referring to the screen shot, the metronome hit at 7.500 seconds and the audio was recorded at 7.508, so that's 8 ms RTL. Not 3 ms, but certainly better than previous Windows audio (and better than what I typically get from USB 2.0 ASIO interfaces).
 

 
 
I wonder if the 3 ms figure quoted by Windows is incoming only instead of RTL? In any event, not sure why I'm getting 8 and you're getting 15; I know you're very knowledgeable about this kind of thing. 
 
I've pinged Noel for comment, but he's away ATM so not sure when there will be a response.

Recorded clips are subject to record latency compensation (i.e. the recorded clip is laid down earlier in the timeline after recording stops than it actually arrived). This compensation is automatic for WDM and WASAPI, and can't be disabled as it can be for ASIO. That's why I did the real-time test. I'm guessing that what you're seeing is insufficient compensation of a larger actual latency value.
 
I'll try testing onboard audio when I get a chance.
 
P.S. I think the 3ms figure refers to the minimum possible buffer size. it doesn't include D/A/D conversion or other hardware/firmware/driver latencies. And there will be input and ouput buffers, so the starting point for RTL is 6ms.

Anderton
Yes, it's replacing Music Creator. 

I thought as much. MC7 is on sale for $20. SHS for $35. They both have the same regular price of $50 which could be a clue to MC's demise. I paid $100 for HS9 in 1999. $29 for MC3 in 2006. $129 for SHS7 XL upgrade. So $50 for SHS sounds great.

brundlefly
Recorded clips are subject to record latency compensation (i.e. the recorded clip is laid down earlier in the timeline after recording stops than it actually arrived). This compensation is automatic for WDM and WASAPI, and can't be disabled as it can be for ASIO. That's why I did the real-time test. I'm guessing that what you're seeing is insufficient compensation of a larger actual latency value.
 
I'll try testing onboard audio when I get a chance.
 
P.S. I think the 3ms figure refers to the minimum possible buffer size. it doesn't include D/A/D conversion or other hardware/firmware/driver latencies. And there will be input and ouput buffers, so the starting point for RTL is 6ms.

Okay, more data...I downloaded the release candidate, which is one build past what I had. This time I inserted a spike on quarter notes instead of playing back the metronome to eliminate a possible variable. Now the recorded sound is only 6 ms after the quarter note...so your estimate of 6 ms seems pretty right on. To quote myself, "I know you're very knowledgeable about this kind of thing" 
 
And I must say, the response from the virtual controller does indeed feel instantaneous. At this point I'm less concerned about the actual numerics than I am about the fact that I can play virtual instruments from a laptop in what feels insignificantly different from real time, without an audio interface. This will change my life, given how much I travel!
 
Do test the onboard audio and see what you find, my understanding is that's what WASAPI is all about and where the benefits will appear.

The reason I do the test the way I do it is important because that is what will be happening to anybody recording new tracks alongside already recorded audio tracks. 
And using the metronome does not give you a visual comparison of the wave form. Good trick, but I prefer the visual. 
 
This test is for testing the accuracy of the audio driver reporting to Sonar. This is NOT a RTL test. Please don't get the two confused. 
I have a reported RTL of 26ms,, but the Tascam ASIO driver and Sonar sort that out and my tracks, under ASIO, are bang on the money.
 
I've tested many ASIO (and WDM ) drivers on a few different interfaces, and others here have reported in on the thread I started in Hardware forum, conclusion-  all the good well known brands are always right on the money... It is only when you try and use something other than a good ASIO driver that things run amok. 
This is defiantly true of on board audio cards and any USB device that does not include ASIO drivers. They always have been way out of sync. 
 
Sonar , it is said will compensate using the reported latency from the driver, if it is wrong, your new audio tracks will be recorded either late, or even early. This is unexceptionable. 
 
So I found WASPI so far is no better under W7,  if it does work under W10 this is good news for many people who are not that interested in spending $200 on an interface. I'm just skeptical about the offset still. Until I see a screenshot like mine. 
 
Thanks for the shots so far, good stuff keep them coming.

On further testing, I found two problems:
 
1. The real-time latency is not consistent from one session to the next. After working on some other projects in ASIO mode and coming back to my test project in WASAPI mode, the real-time latency had dropped to 11.8ms from 15.5.
 
2. I did some recording tests (not yet having read your clarification above), and found that record compensation was not only insufficient, but also variable. The recorded audio landed in a different place every time, and was short of being fully compensated by anywhere from about 5 to 6.5 ms. This is surprising given that within the session, the playback RTL was 100% consistent to the sample.
 
This was with the MOTU interface. I haven't yet tested the onboard Realtek because I couldn't readily put my hands on the one 1/8" stereo patch cord I have to do the loopback.

Some notes:
 
1. The core goal for us developing WASAPI support was for better supporting the plethora of consumer audio devices. USB/Bluetooth speakers, mic's, headsets as well as USB guitar cables. We now have great built in support for many consumer audio devices and onboard audio chipsets. 
 
2. You will get the best performance with WASAPI in Windows 10. It has several internal optimizations that Win 8 or earlier won't be able to match.
 
3. The advantage of WASAPI over ASIO is that you can couple together devices from different manufacturers. e.g use a rocksmith guitar cable and output to your onboard audio or a USB speaker and play at low latency. 
In WASAPI shared mode you can also jam along with your favorite youtube video.
 
4. The Windows 10 "inbox" HDAudio driver has been optimized for the new low latency API's. With it you will be able to dial back the buffer size to about 3 msec on supported onboard audio devices even in WASAPI shared mode. On Win 8 and below the min shared mode latency is 10 msec.
 
5. Its hard to measure WASAPI performace with pro audio devices currently. I've seen great variances with pro audio devices since driver vendors are only optimizing for ASIO mode and not testing with WASAPI since there aren't many pro audio apps that support it well. As a result you may get sub par performance with some pro audio devices. I will be contacting some vendors with problem reports. This isn't a problem with WASAPI per se but the vendors implementation itself.
 
6. WASAPI will typically work with any device that shows up and works in WINDOWS itself (right click on speaker icon / playback devices in windows). I've tried it on several pro audio interfaces as well such as an RME UFX and a MOTU. With pro audio devices you may also need to set the device latency independently in the driver control panel to get low latency
 
7. The new WASAPI support allows us to dial back the buffer size on supported drivers/hardware down to 3 msec. This doesn't mean that round trip latency will be 3 msec, since that depends on the hardware implementation. However on a Surface Pro 4 I got imperceptable latency playing guitar through onboard audio while patched in with a rocksmith cable and running in exclusive mode at 3 msec.

Does this mean Bluetooth headphones can be used or is the lag time still too much for them?