Dear @paul,
I have been following your work on Ardour and Linux audio generally for about 20 years. I recently finished reading your post titled “Is Open Source a diversion from what users really want?” (but I have not read the resulting discussion).
In the time since I first lurked on various mailing lists where you posted, I led the development of a (now defunct) music player which shared files freely licensed under Creatives Commons licenses and later worked at the Software Freedom Law Center as an advocate for free/libre and open source software during the drafting of the third version of the GNU General Public License.
There is one point in your post I think I can provide some additional insight on.
I think your overall thinking is on the right track, but to me the answer to this precise question is “no,” and I will explain why I think this.
For the past decade, I have worked as a theoretical/computation physicist. For a long time, my code for performing research was written in a mixture of C++ and Python – C++ for the performance, and Python for the flexibility. I would often spend a lot of time wrestling with this problem of where precisely the interface should be between the (slow) “script extension system” and the (fast) performant code in C++. My PhD advisor was (and is) a very creative person, and requirements would often change rapidly as we brainstormed new ideas. I found time and time again that I could never successfully predict where the boundary between the two languages ought to be, despite thinking carefully about this each time.
In the end, I never found the perfect boundary between scripting and performant code. Instead, I discovered and began using (and contributing to) the Julia programming language, a high-level language that performs nearly as well as C++. Julia plays well with other languages, but importantly, once I have ported code to Julia, there is no looking back for me. There is no more thinking about where the optimal interface is between my main code and the prototyping language I use to wrap it. The Julia developers refer to this as solving the “two language” problem. They claim the language combines “the ease of use of Python and R with the speed of C++.” I have found that this is no exaggeration.
In addition, the Julia developers have done a pretty amazing job of making sure its users can install binary dependencies easily and in a cross platform way. This is no easy feat, as many of these libraries must be configured with the right compiler flags to both work and perform well. As a user, this is mostly transparent to me.
Julia is truly a lisp with syntax – in fact, has macros and even a built-in LISP interpreter, called FemtoLisp. Building a language around “multiple dispatch” allows using mathematical notation for common operations and can be considered unreasonably effective for others. Ardour depends on FFTW, and one of the authors of FFTW is one of the top contributors to Julia.
I think the best way forward toward making music with Julia is to start small and to make it accessible to users of a Linux audio system. There is a package called JackAudio.jl which aims to do this, but it could use a bit of help. Or perhaps the effort should instead be put into PortAudio.jl, as that thread suggests. I would welcome your expertise here.
If one were to attempt to make an Ardour-like GUI in Julia today, I expect that the single greatest problem would be startup latency, which is improving but remains a big issue. I have also not thought deeply about using Julia for low latency workloads, but I see nothing inherently that prevents it once the JIT has warmed up, and supposedly it can work pretty well in practice, if not quite as good as C. Or perhaps the lowest level above Jack should be written in C or C++, with Julia sitting somewhere above it.
In any case, I want to make sure Julia is on your radar. I think it offers a potential path toward building an open source music system in which even casual users can experience the benefits of it being open source – without them having to compile a single thing. I think, in the end, this could provide an experience without bounds on creativity – one the makers of proprietary solutions could only dream of.