I’m happy to announce a new package I’ve made, RealtimeMusicTheory.
Initially, my main goal was to take the package MusicTheory.jl by @dpsanders and see what I could do in the way of refactoring it for performance, in order to use it for a music application I’m building where performance is a critical concern. I wanted to get the fastest possible performance from low-level musical operations that I could manage. At first I thought of simply contributing to his existing registered package, but then it became clear that my vision was growing into something that was quite a substantial departure and was perhaps not suitable for all, or even most, use cases.
What it turned into will maybe be a little controversial, because I arguably rely too much on a proliferation of types and on compile-time computation of everything. Everything works at the level of types in this package, and parameters to types – there’s no runtime data. Once function specializations are compiled, however, practically everything benchmarks at less than 1 nanonsecond runtime, zero allocations.
To the extent that the proliferation of types and specializations should become a problem in any way (so far for me, it has not), I will see what I can do to rework the implementation to lessen such problems with minimal impact on runtime performance. I will also consider what tricks I can do to minimize compilation overhead for first-time function calls/specializations.
There are some obvious things from the original MusicTheory.jl that I have not implemented yet, like scales and chords. I will later build those on top of what we’ve already got. But first I want to spend some time using this in the real world and get a good idea of how I like the interface in practice, how it makes sense to build further upon it, and how the performance claims hold up.
There is also a continuous-space counterpart to this that I’m working on, TuningsAndTemperaments.jl, coming soon.
