[CM] What motivated the change from CL to Scheme?
Cian
cian.oconnor at gmail.com
Thu Nov 9 08:33:17 PST 2023
>
> Do you think something like incudine <https://incudine.sourceforge.net/>
> and/or cm-incudine <https://github.com/ormf/cm-incudine> would have
> fixed the problem of relying on C, even though it is too late at this point?
No, as things have improved dramatically since then. Incudine uses SBCL to
support realtime audio, and while it uses a little bit of C, it's only for
low level things where C makes more sense (memory management). The main
limitation with SBCL is that it has a fairly conservative stop the world
garbage collector (whereas S7 has a realtime GC I believe), so you can
occasionally experience pauses. There is currently some work happening on
creating a RT Garbage Collector for SBCL which would be quite exciting.
At some point I'd like to look at getting Drew Krause's stuff working on
Orm's port (and eliminating warnings, and probably modernizing it as well).
But it's not a priority for me at the moment.
On Thu, Nov 9, 2023 at 11:05 AM Brandon Hale <bthaleproductions at gmail.com>
wrote:
> This is a very interesting thread that I always wondered about.
>
> The Common Lisp Music system which grew out of Mus10
> at SAIL, had become unmanageable because (despite the insistent hype) the
> only
> way to get any performance was to write the generators in C and tie them
> into
> Lisp via the clumsy FFI's of the day. Even that was too slow, so CLM
> ended
> up writing C code on-the-fly for entire instruments (or rather the "run
> loop" portion),
> compiling that and loading it into CL, sort of like Chicken Scheme.
> This was a nightmare to debug, and it was obvious to me that my sanity
> depended
> on finding a simpler way (while staying in the lisp family of course --
> Cmix and
> CSound had the C-side covered). Guile filled the bill for awhile, so both
> Snd and CLM used it.
>
> Do you think something like incudine <https://incudine.sourceforge.net/>
> and/or cm-incudine <https://github.com/ormf/cm-incudine> would have fixed
> the problem of relying on C, even though it is too late at this point?
>
> Brandon Hale
> On 11/9/23 8:33 AM, bil at ccrma.Stanford.EDU wrote:
>
> I can speak to the CLM/Snd side of this which was closely associated with
> Common Music.
> I followed Rick's lead, but I was already searching for an alternative to
> Common Lisp. The sound editor, Snd, was a C version of an earlier editor
> named
> Dpysnd, written in SAIL at SAIL in the 70's and 80's. I wanted to add an
> extension language, but at the time (say mid-to-late 90's), this was all
> but
> impossible in Common Lisp (like later Schemes, CL wanted to be the "main
> program").
> I looked at elisp (emacs), then someone mentioned Guile, so I started
> using it.
>
> The Common Lisp Music system which grew out of Mus10
> at SAIL, had become unmanageable because (despite the insistent hype) the
> only
> way to get any performance was to write the generators in C and tie them
> into
> Lisp via the clumsy FFI's of the day. Even that was too slow, so CLM
> ended
> up writing C code on-the-fly for entire instruments (or rather the "run
> loop" portion),
> compiling that and loading it into CL, sort of like Chicken Scheme.
> This was a nightmare to debug, and it was obvious to me that my sanity
> depended
> on finding a simpler way (while staying in the lisp family of course --
> Cmix and
> CSound had the C-side covered). Guile filled the bill for awhile, so both
> Snd and CLM used it.
>
> Guile became comatose in the 2000's, then came back to life as a compiler.
> The new Guile was not compatible with my code, so I wrote s7, starting
> with
> TinyScheme. At this point I am very happy with s7+C in both programs.
> If I need something from s7, I can just implement it. If I were using
> CL, nothing would happen because that community is hyper-conservative,
> and if using any other Scheme than my own, nothing would happen because
> Schemers love to bicker until everyone is exhausted. With s7 I can just
> sit and type and hum a happy tune.
>
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
> _______________________________________________
> 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/3c348cce/attachment.html>
More information about the Cmdist
mailing list