Consider seperating timing logic into new project

[jhimes144]

The high resolution timing logic contained in this library is a hidden gem. Would anyone consider separating it out into a new open source project?

[melanchall]

I should notice that:

1. right now this logic implemented for Windows and macOS only;
2. implementation for Windows can be more accurate via usage of undocumented WinAPI functions NtQueryTimerResolution, NtSetTimerResolution and NtDelayExecution.

Can you please say why you're so excited by timing logic with DryWetMIDI? :)

[jhimes144]

@melanchall

I'm sorry for replying so late. I appreciate that you kept this issue open for half a year :)

I am using the timing logic for a .net application to control entertainment lighting fixtures with the DMX protocol and other ip based protocols. These IP protocols (ArtNet) require that I send packets at 45fps intervals, I wish to maintain a main "loop" in my application that is locked to 45fps. I currently use my own fork of just your multimedia code to accomplish this with precision. The alternative is a combination of Thread.Sleep(1) and then busy waiting an entire processor core the entire time the app is open. I also use this entire project for other midi-related things in the same app.

I'm now looking at making my own solution for Linux, using hrtimers. As an aside, can I ask why you chose to forego implementing Linux in this project?

[melanchall]

Thanks for explanation!

Well, regarding Linux. Initially the library was a Windows-only one. Then I noticed that some people ask about macOS support. I came to thought that I need implement Devices API for this platform.

I have plans on Linux support but can't provide any estimates since this feature has low priority for me. Number of music/MIDI-related users on Linux is much less than on Windows and macOS. Right now I'm in the process of providing iOS support. After that Android looks the main goal in terms of cross-platform API.