Csound and SuperCollider heavily inspire it and have some innovations, including sample accuracy and other desirable things.
For inspiration and comments.
1 Like
I dislike lisps because they are hard to read and require unusually functional ways of thinking… they are also powerful, offer so much flexibility, and kinda magic — my main experience is with lilypond.
Supercollider’s hard enough for most people and I think this goes in the wrong direction to engage a wider audience of musicians.
I (vaguely) remember “common lisp music” , made in lisp, “overtone”, a system made in clojure,
“haskore”, a system made in haskell, and “strasheela”, a system made in mozart-oz.
Despite looking very promising on the surface, none of these have managed to attract a lot of attention and to be honest, I think it’s mostly caused by the languages they are written in which feel pretty alien and unnatural to many people without some sort of computer science background (which - I’m guessing - most musicians don’t have?).
I’m not sure what the remedy is here… better tutorials? have some masterpieces made with it that are just too good to ignore (which I’m guessing is the reason that lilypond sort of succeeds, although very few manage to customize stuff with guile)? (Or just accept it as a fact of life and move on? 
)
My intention was not to shed light on the language’s syntax, but on the modern features.
Anyway, are your examples really the case? I think Tidal (written in Haskell) is maybe as popular as SC itself.
1 Like
Common Lisp Music is very old and was very popular in academic circles when it was created. Common Music was a strong influence on the patterns language in SuperCollider. Ircam are heavy users of LISP. Several well known composers also use LISP (e.g. OpenMusic). Overtone was successful while it was actively maintained - Sam Aaron just moved on to other things.
There’s a long history of Musicians/Composers being taught LISP and doing just fine with it. There’s also a long history of non-programmers using LISP in AutoCad and Emacs.
May I humbly suggest that your limited experience of using a LISP dialect in one (poorly written) project may not be the definitive word on it.
Common Lisp supports object orientation (with what many consider to be the best implementation out there), functional code as well as imperative code. Many of the things that people take for granted in modern languages were invented in Common Lisp, along with things that are still not standard in other languages.
offer so much flexibility, and kinda magic
LISP is powerful. This means that like any powerful tool it can be abused. See also C++.
Some other things in a similar vein that may be of interest:
- GitHub - digego/extempore: A cyber-physical programming environment
- https://incudine.sourceforge.net/
- GitHub - byulparan/cl-collider: A SuperCollider client for CommonLisp
The main advantages of a LISP (particularly those based upon Common LISP) for livecoders are:
- The REPL. You can change stuff on the fly. Kind of like SuperCollider’s IDE, but more so.
- Macros allow you to construct mini-languages very easily and just use them seamlessly in your code.
- Macros also allow you to shape the language to the problem, which can result in code that looks more like the problem you’re trying to solve.
Common LISP also has the advantage of having a very fast implementation (SBCL), excellent FFI (you can livecode your c interface if that’s your thing) and some surprisingly good libraries. Unfortunately the GC is stop the world (though someone is working on that), so incudine (which allows livecoding of DSP) doesn’t work brilliantly for livecoding.
I’ve been using cl-collider for a little bit and I really like it. The library doesn’t quite support all the features of sc-lang, but it’s pretty mature. And it’s easy to add features to it.
Is Lilypond poorly written? I’ve done a lot of guile programming in it, it would be good to know if it really is that different from other lisps?
For reference
I’m not qualified to say whether LP is poorly written or not, but its output looks significantly better than both Finale and Sibelius, to my eye.
hjh
The quality of its output is excellent, but the code used to develop it is not great.
Which is fine (I heavily rely upon Lilypond), but I would never use it as an example of good programming practice.
If you define a LISP language as anything that uses parentheses, then judging LISP based upon Guile is a little like judging C++ based upon your experiences of Perl. Yes, superficially, there are some syntactical similarities - but they’re very different languages.
If you want a highly imperfect analogy: Guile is Lua, while Common LISP is sort of what Julia might be if it was a general purpose systems language (or Ruby, if it had the performance/low level features of Rust).
If parentheses don’t bother you, then you might well like Common LISP. It’s a great language, particularly if you’re looking for a multi-paradigm language that can do almost anything (including stuff that other languages still can’t). But it’s obviously not the right language for everyone.
1 Like
Common LISP is probably my favorite language still, and the one that keeps teaching / informing me. I wish I could use it for my day job… alas…
/*
Josh Parmenter
www.realizedsound.net/josh
*/
LilyPond uses Scheme as an extension language for C/C++. Scheme code does not require recompiling the entire project while hacking it dynamically.
So what makes LilyPond code bad, is it related to Scheme or something else? (Curious to know)
Common Lisp and Scheme are very different languages and have very different use cases. Scheme can be very nice if you make it fit you. That’s the beauty of it.
I imagine it’s the fact that it was developed by academics with little experience of writing industrial strength code. I’m sure there are projects that use Guile effectively. Emacs would be my example of LISP used very effectively for scripting.
Common Lisp and Scheme are very different languages and have very different use cases. Scheme can be very nice if you make it fit you. That’s the beauty of it.
Yes, but this also means you have to reimplement libraries that are taken for granted in other languages. And also the tooling that we take for granted these days just doesn’t exist, even for Racket/Guile. This is the problem with niche languages.
The one niche that Scheme has is for embedded languages. But I don’t think it’s been the best choice there for a long time unfortunately. There’s a reason LUA dominates. Maybe Guile can turn things around.
It was not random, this is the GNU project design. In RMS words:
I’m not sure what this is in response to.
There’s really only one standard scripting language these days and it’s Lua. Guile is obscure, even in open source communities. I would guess that Fennel on Lua (a type-2 LISP inspired by Clojure) is used more widely than Guile at this point.
Racket (also scheme family) is a very interesting project, more to do with metaprogramming than scripting. That’s a more developed branch of scheme.
It is, though that’s more of an academic thing. Scheme has always had more success as a teaching and research language. Racket is an amazing environment for prototyping new languages - not that this is something most of us have to do very often
The reason there is so much area in this area that’s emerged out of the Scheme community is because Scheme makes metaprogramming more difficult. Macro hygiene is a fairly minor inconvenience in LISP with simple workarounds for 99.999% of the problems. In Scheme it’s a huge problem, that requires highly complex solutions (ironic given Scheme’s main selling point is simplicity) and results in a less powerful macro system (because non-hygienic macros can be really useful).
An interesting Scheme you should probably look into is s7, which was created by Bill Schottstaedt after the implosion of the Common Lisp ecosystem in the 90s. He built it for music and synthesis purposes, and while its relatively obscure, it’s surprisingly powerful. It’s also fast and I think that’s a testament to Scheme’s simplicity. It’s what the modern forms of Common Music/Common Lisp Music are written in, as well as the Grace system. It’s kind of interesting, though not many people use it sadly. But I think you can use it with SuperCollider.
The only thing that I miss from Scheme when using other languages btw is continuations. Schemes continuations are very powerful, and are amazing for musical purposes. It’s the one thing LISP doesn’t have, and I do feel the loss of it sometimes (though supporting it comes at the cost of performance).
SC is not particularly suitable for designing DSL, but I think you might be wrong. Not rarely people come up with small languages in SC.
Sure, but very few people are trying to design the next Java in SuperCollider, which is kind of where Racket’s niche is. It’s kind of off topic, but there’s an excellent book by Matthew Butterick on how to do this in Racket, and the tooling/support is really cool. Most of the boiler plate is taken care of for you. But I don’t think Racket is well suited to do what SuperCollider does.
LISPs generally are excellent environments for designing DSLs. Common LISP actually allows you to embed your own mini languages into ordinary LISP code. So recently I used this to write a mini-interpreter for GUIDO, so I could succinctly write musical phrases with little effort, but still embed this in normal LISP code. Which for me is the best of both worlds. I don’t use this often (it’s more typical to extend LISP with macros), but it’s very nice when you need it.
I don’t have a problem with Scheme in theory, it’s just in practice I’ve found them disappointing. The tooling/libraries are either not there (most of them), or pale compared to what you’d expect in a modern language like Rust/Python etc (Racket). Common Lisp and Clojure are the only LISPs that feel modern to me. And if I want to embed a scripting language then it’s hard to compete with LUA for most things.
If you want to play around with LISPs then I’d recommend Incudine (Common Lisp DSP/livecoding - very powerful), CL-Collider (a really nice interface to SuperCollider), Extempore (a powerful DSP/livecoding system written in Scheme, that unfortunately is a bit bare bones) and Grace (more Scheme - this is the modern implementation of Common Music, Common Music Notation. Supports synthesis, scheduling [including SuperCollider] and music notation).
You can also get Common Music and Common Music Notation working in Common Lisp, though they seriously lag the Scheme implementations.
I am currently porting some of the quarks in SuperCollider I use to CL-Collider, as I really like how it works. I’ve also used Incudine, which I like, but it lacks the wide library of UGens you get with CSound/SuperCollider - and I’ve not found a way to use it reliably for livecoding.