Seems like a fun DSL. Do you have any plans for a simplified notation for entering notes and durations once you’ve finished designing your instruments?
Yep, that’s the plan! I don’t see why there needs to be a distinction between instruments and scores like CSound does it though. I’m hoping to figure out something that composes better (pun intended).
VCV Rack does this pretty well IMO (its a totally different paradigm with one whole type - ‘wire’) I think what makes it work is that it turns 12-tone equal temperament (i.e. ‘notes’) into frequency (i.e. floating point hz) really high in the stack.
The term is a bit disappointing, because one of the trills of Lisp is that you embed languages into Lisp, that simply interoperate with the rest of the language just like primitives. Think of the picture language in SICP. This seems to have conventional lisp syntax and a few forms, but sadly it’s totally disconnected from the rest of any lisp environment. “Lispy” is to Lisp, as hoverflies are to wasps.
The language is being developed in conjunction with the structural editor, and so it was a lot easier to start with some very simple fundamentals and build from there. It has a lot of guarantees an impure Turing-complete language doesn’t.
In the meantime, “lispy” seems a reasonable shorthand for a language that uses S-expressions and lisp evaluation rules.
I know how “lispy” is used, I just consider it a pity when people go down that route, instead of embedding, because I feel like it looses a lot of the power it could very easily have.
Sure, but sometimes power is bad! :)
Or rather, it’s a trade-off.
Some things I can do with this simple language that I wouldn’t be able to do if I embedded a general lisp:
It is much easier to provide tooling for non-turing complete languages. Take a look at Dhall for more of this philosophy.
Why couldn’t these things be guaranteed within a Lisp-DSL? Racket’s Plot library seems to do all these things (in a way that makes sense for it’s application). The lesson of Lisp is realizing that there is no difference between the given (Scheme RnRS, ANSI Lisp), the created (whatever code one writes in the given language) and the “limited” (the language created by the “created” language) language. Embedding is just the step from the “created” to the “limited” language.
They can be guaranteed within a DSL. That’s what this is!
If you’re trying to say I can increase power by using a general purpose lisp and still guarantee termination, you’re on shaky ground ;)
All I’m saying is that if you’re going to make a “lispy” DSL, you might just as well make a DLS in Lisp.
My read here is that the interactive realtime hybrid text/graphic interface is the current focus of this project, and to that end, I’m not surprised that metaprogramming isn’t a top priority. There are plenty of realtime1 audio-oriented2 lisps with macro systems to play with.
Also from ccrma is this, which uses scheme instead of common lisp—the excellent s7
What did you implement it in? Before compiling to wasm
The audio engine is written in C and uses the SoundPipe library. I’ll open source this at some point.
The UI is written in Elm and TypeScript.
I have never had a more enlightening conversation with a cat.