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

[Iain Duncan]

With regard to your comments (can't recall whether they were here or on
hacker news) about CLOS - Common Music 3 does include a CLOS-style object
system. I am also building such a thing for Scheme for Max as part of my
PhD work. My intent is to make something CLOSish, but more targeted at
live-coding and scoring in scheme - so supporting conventions that make the
code one must type as compact as possible. I hope to have this out sometime
mid next year.



On Thu, Nov 9, 2023 at 7:33 AM Iain Duncan <iainduncanlists at gmail.com>
wrote:

> 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/bd6eb985/attachment-0001.html>