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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> >
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
