What's the core benefit in comparison to all the other existing open-source audio/music programming environments (https://en.wikipedia.org/wiki/List_of_audio_programming_lang...)?
This syntax is also deeply integrated with the customised audio engine under the hood. And this audio engine can be used as an independent Rust audio library.
You can also use Glicol's DSL in Rust projects.
There are many use cases in this YouTube channel, such as Glicol running on Bela, functioning as a VST, and as a CLI tool:
https://youtube.com/playlist?list=PLT4REhRBWaOOrLQxCg5Uw97gE...
But all in all, I just feel comfortable coding with it for experimenting sound design and improvisation.
I wonder what is the dynamic behind that longevity. Music hasn't changed ofcourse but on tech side I would think there are significant new possibilities.
Is it something related to the difficulty of implementing low level algorithms (famously a lot of linear algebra stuff goes back decades and rests on C / Fortran libraries). Is it that there isn't enough interest to justify new efforts or are those systems already near "perfection"?
Some indeed started long ago; e.g. Common Music had its roots in the eighties and became a pretty popular composition environment during the nineties; in 2008 there was even a fundamental redesign and it's still developed. But there was also a certain abundance of new tools; many were released that essentially had the same goal and offered the same features, just implemented a little differently.
> Music hasn't changed ofcourse
Music and the way music is composed, produced and consumed has changed tremendously over the years, and so have the tools. In the past the focus was on algorithmic composition, and tools allowed to extend the possibilities of a composer also to sound design, but it took years until computers were fast enough to render a composition in real-time. Then came the time of the DAW's when eventually everyone could produce music with little investments. In the last ten years live coding became popular which is yet another way of composing and producing music, with new requirements for interactivity and ergonomic efficiency of the tools, and yet a different view of the composer and the composition process.
I discuss this a bit here: https://iainctduncan.github.io/papers/introduction.html
What's the topic of your PhD? Who is your supervisor?
My PhD is an interdisciplinary between music and CS, working with George Tzanetakis and Andy Schloss at University of Victoria in BC Canada, continuing the same work I did for the Masters. So that is Scheme for Max and other Scheme related music work, targeting algorithmic composition, mainstream production, and live coding contexts. Some of the current initiatives include a browser based Scheme algorithmic music system (not yet published, but using a WASM C++ worker for a sample-based scheduler), further work on s4m, s4pd, and Ableton Live tools, integrations with Csound (I wrote the csound6~ port for Max), likely a standalone host (similar to Grace), an object system and score tool, and some actual music!
(EDIT: I was wrong and thinking Nyquist, not SAL!)
SAL was designed and published in 2008 by Rick Taube; the present implementations are transpilers to Scheme or XLisp, but SAL is quite different from both Scheme and Lisp (in syntax and semantics).
> My PhD is...
Sounds interesting; but what is the actual research focus (besides the programming work and tool implementation)?
My PhD is interdisciplinary, so it is not a pure research CS - it's a combination of CS work, project work, and music composition & performance. The research side will be into how Scheme and recent developments in the Scheme side of PLT can be used in modern machines/environments for exploring algorithimic composition and live-coded composition and improvisation.
Lisp and Scheme are indeed very flexible to represent about anything, but on a very fundamental and general purpose level; of course you can do some kind of "DSL" with macros, but it's still "Lispy". SAL has less degrees of freedom and helps users not to get lost or bogged down, but it's still a general purpose programming language, not a specification system covering the essence of musical structures and processes.
> My PhD is interdisciplinary, so it is not a pure research CS..
Here in Switzerland "interdisciplinary" means that the research topics concern more than one research area, not that it's not pure research. Usually the PhD students are more challenged than with a "traditional" PhD, because there are more professors involved, each with his own research focus, that is most important to him (so it happens that the student does actually work for more than one PhD).
Concerning Scheme, depending on how big the "composition" is and whether it does sound generation and has to be controlled in real-time, a traditional byte-code interpreter will likely get to its limits, even on present HW.
But as far as practical use goes, I run 16 algorithmic sequencers implemented completely in s7 in real-time, inside Ableton Live, at an output latency of 8ms, and do so for long enough for compositions. This is while Live does a ton of software synthesis and FX dsp too, and all of the sequencers can be altered on the fly without audio dropouts! This is on the cheapest M1 you can get too. So it's absolutely practical for real time work. This is also without even a ton of attention to real-time GC in s7 - I haven't dug into that yet, but Bill has told me that while he did a lot of work to make it fast, it doesn't use an implementation specifically targeted at lowest possible pause times.
Whether the tradeoffs of Scheme vs other options are worth it for a particular composer/producer/performer varies of course, but it really is time to put to rest the notion that we can't run a Scheme interpreter for real-time music generation.