[CM] What motivated the change from CL to Scheme?

Iain Duncan iainduncanlists at gmail.com
Thu Nov 9 07:33:43 PST 2023


For what it's worth, I think that language is indeed Scheme. I wrote Scheme
for Max after looking for the right language to use inside the Max
environment for representing music symbolically, and I looked at a lot of
options. I chose s7 for the combination of three factors: great for
representing music and music symbols, used in other computer music
projects, and super easy to embed. I mean, I haven't learnt every language
obviously, but of the dozen odd I've used (including Python, Ruby, and JS),
representing music in Scheme is so much nicer IMHO.  (I am aware that there
are those who would argue an ML family language is better, but I think they
are outnumbered by the Lispers). I wrote a bit about this in my thesis
paper here:
https://iainctduncan.github.io/papers/design.html#why-use-a-lisp-language

Having looked closely at other options (CL, Clojure, Racket, Gambit, etc),
nothing except Guile came close to as easy for embedding, and this made a
huge difference to the practicality of making Scheme for Max and Scheme for
Pd. The ease of extension with the FFI is wonderful.

If you want to see the performance of the Scheme code running a large
amount of code in realtime while the host does heavy audio rendering, here
is a demo video of a comprehensive sequencing system running inside Max
inside Ableton Live. TLDR: it's totally practical on modern machines.
(Especially Apple Silicon!)

https://vimeo.com/user29372309/scmseq-demo

(project page here, btw: http://github.com/iainctduncan/scheme-for-max

On Thu, Nov 9, 2023 at 6:50 AM Rochus Keller <me at rochus-keller.ch> wrote:

> @ Mike, Bil:
>
>
> Thank you both very much for your quick response and the interesting
> information.
>
>
> > Scheme is a somewhat easier language to learn and use ... I think the
> motivation was to simplify teaching computer music.
>
>
> Ok, that seems like a decent motivation to switch to Scheme, since it is
> or was used in basic programming courses at universities anyway. But am I
> wrong to assume that this change created a rather incompatible version,
> i.e. all existing compositions based on CLOS, and the published papers and
> books about Common Music became virtually obsolete, and the way to compose
> with version 3 is significantly different than with version 2? Or do I have
> a misconception in this respect?
>
>
> > if you are looking to use specifically Common Lisp for computer-based
> composition
>
>
> Actually I currently rather try to find out which language is best suited
> to represent music on a symbolic, compositional (not physical or sound
> design) level. I'm not sure Common Lisp or Scheme are the best solution,
> neither Python. SAL is an interesting approach, but essentially Scheme with
> a kind of Pascal syntax as far as I understand it.
>
>
> > so I wrote s7, starting with TinyScheme
>
>
> Can I conclude from this that your change from Lisp to Scheme and finally
> your own interpreter was an important reason for Common Music to follow?
>
>
> I had a look at S7 and its implementation which is impressive. Have you
> also experimented with threaded interpreters? Is the performance of the
> Scheme code an issue at all in this application domain?
>
>
> Best
>
> R.K.
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20231109/a1756484/attachment.html>


More information about the Cmdist mailing list