Cakewalk SONAR: Win32 lighting up on Windows 10

Play Cakewalk SONAR: Win32 lighting up on Windows 10

The Discussion

  • User profile image

    This one is slightly different from the previous one. Noel demonstrates how SONAR uses pen and touch, and I get a friend to jam using MIDI over Bluetooth LE.

  • User profile image

    Is there a UWP equivalent to the Win32 Multimedia Timer services? The ThreadPoolTimer only goes down to 15ms. The only way to bring that lower is to use the Win32 Multimedia Timer services from the Win32 side, which isn't possible for a standard UWP app.

    The 15ms threshold is not accurate enough for Pro level MIDI work, so what option would you suggest to obtain a higher resolution clock for UWP?

    It would be very helpful to have a user opt in option for a high resolution timer mechanism for UWP. Having an app level opt in option would allow a user to forfeit battery life for the sake of having highly accurate timing when that is essential to the user. If the higher resolution timer was somehow decoupled from the kernels scheduler, it might limit battery impact system wide?

  • User profile image


    Agreed on the timer resolution. From my discussions with DAW creators, one thing they often do is use the audio samples as a type of timer. One of the guys on the team here had also recommended doing something like that for sample-accurate timing. 

    For a sample clock generator, I use a rather inefficient (IMO) method, but one that is available to UWP and fairly easy to understand. You can see the code here:


    Note that I do that in C++. Doing that in C# is likely to have way too much jitter due to garbage collection.

    Hope that helps.


  • User profile image

    Your MidiClockGenerator code was the inspiration for my current approach. I was disappointed that Sleep(0) doesn't seem to work the same way in WinRT. The MidiClockGenerator approach would have been ideal if Sleep(0) worked as it does under Win32. Having some way of controlling thread CPU affinity would also help.

    As it is, I haven't been able to resolve a good way to throttle back the CPU utilization of a spin loop. I need 1ms accuracy as I'm trying to pull off a pro level MIDI solution with UWP. I tried the sample buffer approach, but it just didn't feel right as a final solution.

    It's crazy that in 2017 we don't have high resolution timer events. I'd be ok with a tiny time slice. A circular buffer can be filled in from a non-deterministic thread.

  • User profile image

    For anyone stumbling into this at some point in the future, we were eventually able to get the result we were after, namely sub 1ms accuracy with UWP. Pete's MidiClockGenerator is a good starting point. Creators Update is noticeably better for MIDI apps that need precision timing.

    We have yet to see GC related jitter issues even when using a ThreadPoolTimer (maybe because of the way we code). The primary issue seems to be inconsistent thread dispatching at the OS level for WinRT apps, something not seen for the Win32 equivalent.

    WinRT threads != Win32 threads

  • User profile image

    Its true that many DAW's use audio buffer callbacks as the mechanism for timing. However, its not always the best solution. For example you may be triggering a hardware MIDI device from a MIDI only app.
    Or perhaps the audio device doesn't do low enough latency. In such cases the Win32 multimedia timer is a better solution.

  • User profile image

    Great to hear about Audio at build !

    Microsoft still has ways to go to make Wasapi as good as CoreAudio, at least regarding pro audio and next-to-zero latency, and I hope it's what it is aiming for.

    I personally feel that there should be a sense of urgency, as it would be the last creative bastion where Macs are indeed better than PCs (also better thunderbolt support for top audio interfaces).

    On the other fronts, Microsoft did indeed surpass Apple: touch, pen, way better graphic card choices, ... And that didn't go unnoticed by many creative pros.



Add Your 2 Cents