From taube at illinois.edu Sat Nov 4 15:08:52 2023 From: taube at illinois.edu (Taube, Rick) Date: Sat, 4 Nov 2023 22:08:52 +0000 Subject: [CM] musx 3.0.0 release Message-ID: Hi folks, just an FYI that I have released a major new version of the musx package on the pypi website https://pypi.org/project/musx/ Here are the highlights: * The musx demo scripts have been converted from .py files into Jupiter Notebooks (.ipynb) to better facilitate interactive exploration. * A new tutorials directory contains a number of Jupyter Notebooks adapted from my CS+Music classes at UIUC. The topics are wide ranging, from basic data representation to spectral composition and 'real time' extensions. * Support for loading data from MusicXML files into data structures that can be easily mapped for analysis. The MusicXML support is located in the musx.mxml module and contains notation classes (enumerations), parts and scores. * A new pattern.py module provides a base Pattern class that support for sub-patterns (patterns inside patterns), a new Range pattern, a new Graph pattern, "dynamic values" (values that can be constants or lambda expressions of zero arguments), and dynamic weighting in the Choose pattern. The new patterns.py module replaces the older gens.py module, which can be still loaded using the explicit command 'import musx.gens'. * New module frac.py adds methods to Python's Fraction class for working with tuples and other mensural quantities. You can access the code, documentation, demos, and tutorials on the musx github website: https://github.com/musx-admin/musx Please see the INSTALL.md file for instruction on how to set up the musx package in a hygenic virtual environment. My next step will be to integrate Todd Ingalls' pysndlib wrapper around sndlib to generate audio files -- at that point musx will be doing pretty much everything that Grace did with some new things as well. --Rick From gray at nxg.name Sun Nov 5 10:32:45 2023 From: gray at nxg.name (Norman Gray) Date: Sun, 05 Nov 2023 18:32:45 +0000 Subject: [CM] Are s7 GC questions in scope here? Message-ID: <179B89B7-310D-4C39-9C3E-335E02A0244C@nxg.name> Greetings. Would s7 questions be in-scope on this list? Specifically questions about s7's FFI and GC? Is there any wisdom about how to approach, or reason about, s7's garbage collection support? I confess to being stumped. I'm writing something which goes back and forth between the s7 world and the C world. The C main program promptly hands over to a scheme main program, which calls out to C (specifically lex/yacc parsers), which in turn call back to scheme for non-trivial bits of work. I _thought_ I was doing the right thing by employing s7_gc_protect_via_stack strategically, while being aware that having C functions call back to scheme ones could stress my reasoning there. The programs in the fairly comprehensive test-suite probably aren't big enough to test that I'm doing the right thing, though, even when I compile with GC_TEMPS_SIZE quite low. I think I'm right that, if scheme procedure (sf1) is implemented in C function cf1(), which calls (sf2) via s7_call, then if cf1() creates an s7 object, or obtains one returned from (sf2), and calls s7_gc_protect_via_stack with it, then that object, and anything it directly or indirectly refers to, is protected until (sf1) returns. Right? I presume that implies that the caller of (sf1) takes ownership of the return value in time for that return value to be safe from GC? It appears to me that, if the above reasoning is correct, then I'm doing something wrong enough that my program seems to simply die abruptly, at the time that the return value of (sf1) is received. No error messages, no stack traces, no non-zero exit value, no mention of free cells, just... end. I'm fairly sure this is a GC-related problem, since it emerges only when it works on a larger quantity of input. My problem is that, after lots of fprintfs, and scattering some s7_gc_protect here and there (which should be a pretty blunt instrument), and compiling with -DGC_TEMPS_SIZE=1000000 and 128, and casting around to see if there's a handy rooster I can sacrifice, I remain sufficiently in the dark, that I can't work out where to look next, nor how I'd make a reduced toy program to demonstrate this. Any toy program that worked could of course be just luck. I've tried invoking the support in "debug.scm", but even when adding (load "debug.scm") (break parse-aux-file) -- where the latter is what I'm confident is the problematic function -- the program still exits, apparently normally, just after parse-aux-file returns. Including in a debugger. Is there perhaps a way of doing valgrind-like memory accounting that might show me what I'm missing? Any wisdom about what stones to look under would be most appreciated. *weep*... Best wishes, Norman -- Norman Gray : https://nxg.me.uk From bil at ccrma.Stanford.EDU Sun Nov 5 11:45:15 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sun, 05 Nov 2023 11:45:15 -0800 Subject: [CM] =?utf-8?q?Are_s7_GC_questions_in_scope_here=3F?= In-Reply-To: <179B89B7-310D-4C39-9C3E-335E02A0244C@nxg.name> References: <179B89B7-310D-4C39-9C3E-335E02A0244C@nxg.name> Message-ID: <2fa0d29a88f02e40d2e727fc66e814b2@ccrma.stanford.edu> Any s7 questions are ok in this list. I can't tell what you're doing, but this doesn't strike me as a GC problem. If you can send me enough of your program that I can run it, I'm willing to try to see what is wrong. From gray at nxg.name Sun Nov 5 13:54:35 2023 From: gray at nxg.name (Norman Gray) Date: Sun, 05 Nov 2023 21:54:35 +0000 Subject: [CM] Are s7 GC questions in scope here? In-Reply-To: <2fa0d29a88f02e40d2e727fc66e814b2@ccrma.stanford.edu> References: <179B89B7-310D-4C39-9C3E-335E02A0244C@nxg.name> <2fa0d29a88f02e40d2e727fc66e814b2@ccrma.stanford.edu> Message-ID: <546A38B7-3D6F-485E-AEE9-1638543EE87B@nxg.name> Bill, hello. On 5 Nov 2023, at 19:45, bil at ccrma.Stanford.EDU wrote: > Any s7 questions are ok in this list. I can't tell what you're doing, but > this doesn't strike me as a GC problem. If you can send me enough of your > program that I can run it, I'm willing to try to see what is wrong. Very kind of you -- I've sent you a message off-list. Best wishes, Norman -- Norman Gray : https://nxg.me.uk From me at rochus-keller.ch Thu Nov 9 04:36:23 2023 From: me at rochus-keller.ch (Rochus Keller) Date: Thu, 09 Nov 2023 13:36:23 +0100 Subject: [CM] What motivated the change from CL to Scheme? Message-ID: An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Nov 9 05:33:52 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 09 Nov 2023 05:33:52 -0800 Subject: [CM] =?utf-8?q?What_motivated_the_change_from_CL_to_Scheme=3F?= In-Reply-To: References: Message-ID: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> 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. From michael.gogins at gmail.com Thu Nov 9 05:41:02 2023 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu, 9 Nov 2023 08:41:02 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: I have never discussed these questions with Rick Taube, but having watched his work for decades and even worked with him a tiny bit, I am willing to speculate. I can't answer your question about a formal specification of SAL. But I will speculate about Common Music. First, Taube is a teacher as well as a musician and programmer. He has used the software that he writes in classes and to support music education. In this context, Scheme is a somewhat easier language to learn and use. It's clear to me that a motive for SAL was to simplify programming. Taube also wrote an all-in-one computer music system, Grace, that embeds Scheme. Again, I think the motivation was to simplify teaching computer music. Taube has also ported much of Common Music to Python as musx ( https://github.com/musx-admin/musx) and, indeed, he is still continuing to develop this system. I myself have contributed to musx by enabling musx to render pieces using Csound in a somewhat more direct way than the original design. Taube continues actively to develop musx. For what it's worth, if you are looking to use specifically Common Lisp for computer-based composition, Common Music in Lisp continues to be maintained (sort of). I myself have a repository that includes many impressive extensions to Common Music by Drew Krause at https://github.com/gogins/csound-extended-nudruz. It's a bit of a mess that spits out lots of warnings and takes its time loading, but it does definitely work and it does much more (thanks to Drew) than the original Common Music in Lisp. The Lisp version of Common Music is also hosted at https://github.com/andersvi/cm2. I myself do not normally compose with Lisp. I write my compositional algorithms mostly in C++ with JavaScript or WebAssembly interfaces, and do my actual composition in JavaScript/HTML, as JavaScript provides a kind of "glue" for using many different software packages in the same context. You can see some examples of that here: https://gogins.github.io/. I keep looking to see if Common Lisp will ever compile as WebAssembly and run in a JavaScript context. I would love to use some of what Drew has added to Common Music in my HTML5 pieces. Regards, Mike ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Thu, Nov 9, 2023 at 7:36?AM Rochus Keller wrote: > I'm looking for articles, design rationales or comments explaining why > Common Music switched from the Common Lisp to the Scheme based > implementation. > > > As far as I've read the past publications, object-orientation (i.e. CLOS) > has been an important aspect of the Common Music composition approach. > Scheme is quite different from Common Lisp, so apparently Common Music made > quite a paradigm shift from version 2 to 3. > > > What was the motivation for this? Have the expectations associated with > this change been fulfilled in retrospective? > > > Another question: is there a formal specification of SAL somewhere (EBNF, > language report, or the like)? > > > Thanks > > 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: From me at rochus-keller.ch Thu Nov 9 06:49:45 2023 From: me at rochus-keller.ch (Rochus Keller) Date: Thu, 09 Nov 2023 15:49:45 +0100 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Thu Nov 9 07:33:43 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 9 Nov 2023 07:33:43 -0800 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: 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 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: From iainduncanlists at gmail.com Thu Nov 9 07:36:19 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 9 Nov 2023 07:36:19 -0800 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: 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 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 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: From bthaleproductions at gmail.com Thu Nov 9 08:01:48 2023 From: bthaleproductions at gmail.com (Brandon Hale) Date: Thu, 9 Nov 2023 11:01:48 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> Message-ID: <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> 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 and/or 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bthaleproductions at gmail.com Thu Nov 9 08:13:08 2023 From: bthaleproductions at gmail.com (Brandon Hale) Date: Thu, 9 Nov 2023 11:13:08 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: > 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 need to run anything with Common Music 2, you can still get it to work...with incudine ! I can also confirm, as someone who learned lisp with cm-incudine, that Taube's book "Notes from the Metalevel" works with cm-incudine, thanks to Orm Finnendahl's help. I use the cm-incudine system for my own endeavors, like this piece (hopefully it's okay to show a piece, not trying to advertise). Check out this link: https://github.com/ormf/cm-incudine to learn more. Cm-incudine relies heavily on Jack, so using it on Linux works the best, but I've gotten it to work on Macos before at work. I also wrote an installer for it for Arch Linux distros and a docker image that can work on any system that docker will run on, without the realtime audio support of course: https://github.com/brandflake11/install-cm-incudine https://github.com/brandflake11/cm-incudine-docker Brandon Hale On 11/9/23 9:49 AM, Rochus Keller 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: From cian.oconnor at gmail.com Thu Nov 9 08:22:32 2023 From: cian.oconnor at gmail.com (Cian) Date: Thu, 9 Nov 2023 11:22:32 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: Orm recently merged my pull request that added support for the Mac, so jack is no longer needed. I use cm-incudine on the Mac, and so far I haven't run into any issues. I wrote a blog post a while back which explains how to install commonmusic and incudine on the Mac: https://cianoc.github.io/2023/09/12/Installing.html It's a little fiddly, but it's not a huge deal. I mostly use CommonMusic for composed stuff, so I'm not sure how reliable it is for livecoding. But I would guess if you're using SuperCollider/CSound as a backend then it's fine. I've used MIDI a little, but not enough to really stress it, so I can't speak to latency/jitter issues. But again I'd guess it's probably fine. On Thu, Nov 9, 2023 at 11:13?AM Brandon Hale wrote: > 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 need to run anything with Common Music 2, you can still get it to > work...with incudine ! I can also > confirm, as someone who learned lisp with cm-incudine, that Taube's book > "Notes from the Metalevel" works with cm-incudine, thanks to Orm > Finnendahl's help. I use the cm-incudine system for my own endeavors, like this > piece (hopefully it's > okay to show a piece, not trying to advertise). > > Check out this link: https://github.com/ormf/cm-incudine to learn more. > Cm-incudine relies heavily on Jack, so using it on Linux works the best, > but I've gotten it to work on Macos before at work. > > I also wrote an installer for it for Arch Linux distros and a docker image > that can work on any system that docker will run on, without the realtime > audio support of course: > > https://github.com/brandflake11/install-cm-incudine > > https://github.com/brandflake11/cm-incudine-docker > > Brandon Hale > On 11/9/23 9:49 AM, Rochus Keller 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 listCmdist at ccrma.stanford.eduhttps://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: From cian.oconnor at gmail.com Thu Nov 9 08:33:17 2023 From: cian.oconnor at gmail.com (Cian) Date: Thu, 9 Nov 2023 11:33:17 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> Message-ID: > > Do you think something like incudine > and/or 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 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 > and/or 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: From orm.finnendahl at selma.hfmdk-frankfurt.de Thu Nov 9 08:42:04 2023 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Thu, 9 Nov 2023 17:42:04 +0100 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: Am Donnerstag, den 09. November 2023 um 08:41:02 Uhr (-0500) schrieb Michael Gogins: > > For what it's worth, if you are looking to use specifically Common Lisp for > computer-based composition, Common Music in Lisp continues to be maintained > (sort of). I myself have a repository that includes many impressive > extensions to Common Music by Drew Krause at > https://github.com/gogins/csound-extended-nudruz. It's a bit of a mess that > spits out lots of warnings and takes its time loading, but it does > definitely work and it does much more (thanks to Drew) than the original > Common Music in Lisp. The Lisp version of Common Music is also hosted at > https://github.com/andersvi/cm2. maybe it's worth mentioning in this context that there is an actively maintained version of the Common Lisp version of cm2 here as well: https://github.com/ormf/cm The github account also hosts many extensions to cm regarding realtime work (using incudine), additional packages for import and export from/to svg, sfz, a maintained version of the CL version of Fomus, gui extensions for browser based interaction, live coding packages, SPEAR like Fourier Analysis/Resynthesis etc. I did the transition from Common Lisp to Scheme around the time, Rick changed to scheme (around 2000 I guess), mainly due to the easier setup and teaching of Scheme to students, but went back to Common Lisp some years later. Although I always really liked scheme and still do, the major motivation to go back to Common Lisp was the speed of sbcl compared to guile back then, the availability of many high quality libraries in the Common Lisp world and the expressiveness and flexibility due to the multitude of paradigms already implemented in the standard. In the meantime, the Common Lisp IDE and other things have evolved quite a bit and quicklisp, sly/slime, changes to CFFI and especially incudine (which is a real gamechanger) put me in a situation similar to what Bill describes concerning S7. But my use case is much more high level than what Bill needs (which might explain the difference of choices). -- Orm From bthaleproductions at gmail.com Thu Nov 9 08:51:56 2023 From: bthaleproductions at gmail.com (Brandon Hale) Date: Thu, 9 Nov 2023 11:51:56 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: <9fb8fe1e-7105-48e3-bdfb-bd2deac74430@gmail.com> > Orm recently merged my pull request that added support for the Mac, so > jack is no longer needed. I use cm-incudine on the Mac, and so far I > haven't run into any issues. > > I wrote a blog post a while back which explains how to install > commonmusic and incudine on the Mac: > https://cianoc.github.io/2023/09/12/Installing.html Haha, I ran Jack on macos to get it to work and it was...stable-ish. :) That's cool though, I didn't know this even happened. Brandon Hale On 11/9/23 11:22 AM, Cian wrote: > Orm recently merged my pull request that added support for the Mac, so > jack is no longer needed. I use cm-incudine on the Mac, and so far I > haven't run into any issues. > > I wrote a blog post a while back which explains how to install > commonmusic and incudine on the Mac: > https://cianoc.github.io/2023/09/12/Installing.html > > It's a little fiddly, but it's not a huge deal. > > I mostly use CommonMusic for composed stuff, so I'm not sure how > reliable it is for livecoding. But I would guess if you're using > SuperCollider/CSound as a backend then it's fine. I've used MIDI a > little, but not enough to really stress it, so I can't speak to > latency/jitter issues. But again I'd guess it's probably fine. > > On Thu, Nov 9, 2023 at 11:13?AM Brandon Hale > wrote: > >> 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 need to run anything with Common Music 2, you can still get > it to work...with incudine ! I > can also confirm, as someone who learned lisp with cm-incudine, > that Taube's book "Notes from the Metalevel" works with > cm-incudine, thanks to Orm Finnendahl's help. I use the > cm-incudine system for my own endeavors, like this piece > (hopefully it's > okay to show a piece, not trying to advertise). > > Check out this link: https://github.com/ormf/cm-incudine to learn > more. Cm-incudine relies heavily on Jack, so using it on Linux > works the best, but I've gotten it to work on Macos before at work. > > I also wrote an installer for it for Arch Linux distros and a > docker image that can work on any system that docker will run on, > without the realtime audio support of course: > > https://github.com/brandflake11/install-cm-incudine > > https://github.com/brandflake11/cm-incudine-docker > > Brandon Hale > > On 11/9/23 9:49 AM, Rochus Keller 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 > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cian.oconnor at gmail.com Thu Nov 9 11:50:04 2023 From: cian.oconnor at gmail.com (Cian) Date: Thu, 9 Nov 2023 14:50:04 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: Message-ID: In case people aren't familiar with it, Incudine is a real-time (though it also supports offline rendering) audio/DSP library for Common Lisp. It is incredibly powerful, as it allows you to do low level DSP in a LISP language and get decent performance. Fomus has also been a game changer for me. Simplifies so many tasks. On Thu, Nov 9, 2023 at 11:42?AM Orm Finnendahl < orm.finnendahl at selma.hfmdk-frankfurt.de> wrote: > Am Donnerstag, den 09. November 2023 um 08:41:02 Uhr (-0500) schrieb > Michael Gogins: > > > > For what it's worth, if you are looking to use specifically Common Lisp > for > > computer-based composition, Common Music in Lisp continues to be > maintained > > (sort of). I myself have a repository that includes many impressive > > extensions to Common Music by Drew Krause at > > https://github.com/gogins/csound-extended-nudruz. It's a bit of a mess > that > > spits out lots of warnings and takes its time loading, but it does > > definitely work and it does much more (thanks to Drew) than the original > > Common Music in Lisp. The Lisp version of Common Music is also hosted at > > https://github.com/andersvi/cm2. > > maybe it's worth mentioning in this context that there is an actively > maintained version of the Common Lisp version of cm2 here as well: > > https://github.com/ormf/cm > > The github account also hosts many extensions to cm regarding realtime > work (using incudine), additional packages for import and export > from/to svg, sfz, a maintained version of the CL version of Fomus, gui > extensions for browser based interaction, live coding packages, SPEAR > like Fourier Analysis/Resynthesis etc. > > I did the transition from Common Lisp to Scheme around the time, Rick > changed to scheme (around 2000 I guess), mainly due to the easier > setup and teaching of Scheme to students, but went back to Common Lisp > some years later. > > Although I always really liked scheme and still do, the major > motivation to go back to Common Lisp was the speed of sbcl compared to > guile back then, the availability of many high quality libraries in > the Common Lisp world and the expressiveness and flexibility due to > the multitude of paradigms already implemented in the standard. In the > meantime, the Common Lisp IDE and other things have evolved quite a > bit and quicklisp, sly/slime, changes to CFFI and especially incudine > (which is a real gamechanger) put me in a situation similar to what > Bill describes concerning S7. But my use case is much more high level > than what Bill needs (which might explain the difference of choices). > > -- > Orm > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From taube at illinois.edu Thu Nov 9 12:03:59 2023 From: taube at illinois.edu (Taube, Rick) Date: Thu, 9 Nov 2023 20:03:59 +0000 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> Message-ID: <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> I originally switched from CL to Scheme because I wanted to embed common music in a graphical environment. I managed to do it using swig, but it was a nightmare and clunky. Bill's s7 scheme, on the other hand, was embeddable by design, and built to support music systems, so it was a no-brainer to move the Common Lisp code to s7 scheme (easy) and embedded it in JUCE (pretty easy) and that worked out really well. Todd Ingalls came along and started working on a real-time scheduler, and that took the software to a new level. Sadly for me, when I started the CS+Music curriculum at UIUC, the agreement was for my classes to use 'standard' programming languages. So looking around I decided to port as much as possible to Python, which is fairly lisp-y (it's brain-dead lambda expression not-withstanding...), has almost no learning curve, and 80% of my student coming into the curriculum already using. I also liked being able to leverage excellent tools like pip, Jupyter notebooks and matplotlib for teaching and now I cant live without them. I just started working with Todd's new cython wrapper around sndlib (type 'pip install pysndlib' and you have it) and -- as a first experiment yesterday -- I mostly have bill's wonderful old 'birds.scm' file chirping away in python. It made me laugh!! --Rick On Nov 9, 2023, at 8:01 AM, Brandon Hale 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 and/or 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://urldefense.com/v3/__https://cm-mail.stanford.edu/mailman/listinfo/cmdist__;!!DZ3fjg!6hhQlBvqxRF_zJnBWxvV0dh8Z9y4ny0s4svnNFwY9bwQUh4Uf-gkHekdUWQPeC_zr0TJ-1KT8WCTIeb40_g8D_JW$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Nov 9 12:30:00 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 09 Nov 2023 12:30:00 -0800 Subject: [CM] =?utf-8?q?What_motivated_the_change_from_CL_to_Scheme=3F?= In-Reply-To: <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: > I mostly have bill's wonderful old 'birds.scm' file chirping > away in python. It made me laugh!! When Jonathan Harvey used file that in a piece (almost unedited!) a reviewer said they were recordings. Can't win sometimes. From iainduncanlists at gmail.com Thu Nov 9 13:44:46 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 9 Nov 2023 13:44:46 -0800 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: On a related note, I have been debating for a while whether to put in the work to ensure CM3 code (or at least, what is in the Notes book) could run unchanged on Scheme for Max and/or Scheme for Pd. My reservations are mostly around the fact that Notes is out of print and not available digitally so I don't really have a good resource to point potential users too. Which is unfortunate, because I think the ability to run inside the Ableton Live environment is pretty compelling to younger users, or anyone also involved in mainstream production. Dr. Boulanger, for example, uses csound in Max at Berklee, and gets a lot of interest because of the ability to run in Live. (and I ported Lazzarini's more recent csound~ object from Pd to Max to support that). But... if anyone here would use such a thing for courses or what not, please do let me know. If there would be sufficient uptake I could certainly justify including it in my work plan. iain On Thu, Nov 9, 2023 at 12:30?PM wrote: > > I mostly have bill's wonderful old 'birds.scm' file chirping > > away in python. It made me laugh!! > > When Jonathan Harvey used file that in a piece (almost unedited!) > a reviewer said they were recordings. Can't win sometimes. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From taube at illinois.edu Thu Nov 9 14:19:44 2023 From: taube at illinois.edu (Taube, Rick) Date: Thu, 9 Nov 2023 22:19:44 +0000 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: <86771A06-C62C-4E97-924F-2F8FA0CBFC05@illinois.edu> I could contact the publisher and see if they would release it now in the public domain. I might have the manuscript on some old hard drive but I would need a release for that as well. --Rick On Nov 9, 2023, at 1:44 PM, Iain Duncan wrote: My reservations are mostly around the fact that Notes is out of print and not available digitally so I don't really have a good resource to point potential users too -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Thu Nov 9 14:46:07 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 9 Nov 2023 14:46:07 -0800 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: <86771A06-C62C-4E97-924F-2F8FA0CBFC05@illinois.edu> References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> <86771A06-C62C-4E97-924F-2F8FA0CBFC05@illinois.edu> Message-ID: Hi Rick, if you can get it released, I would make porting CM over part of my PhD work. I have now down both piggy-backing on the Max scheduler and written my own scheduler for WASM s7 (driven from the C++ dsp loop in the audio worklet), so I don't think there is any technical obstacle. I know George Tzanetakis (my supervisor) shares the sentiment and the book really is a great introduction to doing music in a lisp. Please keep me posted! It would be a wonderful addition to s4m if we had the book available. iain On Thu, Nov 9, 2023 at 2:19?PM Taube, Rick wrote: > I could contact the publisher and see if they would release it now in the > public domain. I might have the manuscript on some old hard drive but I > would need a release for that as well. > > --Rick > > On Nov 9, 2023, at 1:44 PM, Iain Duncan wrote: > > My reservations are mostly around the fact that Notes is out of print and > not available digitally so I don't really have a good resource to point > potential users too > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.gogins at gmail.com Thu Nov 9 14:53:53 2023 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu, 9 Nov 2023 17:53:53 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> <86771A06-C62C-4E97-924F-2F8FA0CBFC05@illinois.edu> Message-ID: There's a WASM s7?? That's great! I may have some use for that.... ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Thu, Nov 9, 2023 at 5:46?PM Iain Duncan wrote: > Hi Rick, if you can get it released, I would make porting CM over part of > my PhD work. I have now down both piggy-backing on the Max scheduler and > written my own scheduler for WASM s7 (driven from the C++ dsp loop in the > audio worklet), so I don't think there is any technical obstacle. I know > George Tzanetakis (my supervisor) shares the sentiment and the book really > is a great introduction to doing music in a lisp. Please keep me posted! It > would be a wonderful addition to s4m if we had the book available. > > iain > > > > > > On Thu, Nov 9, 2023 at 2:19?PM Taube, Rick wrote: > >> I could contact the publisher and see if they would release it now in the >> public domain. I might have the manuscript on some old hard drive but I >> would need a release for that as well. >> >> --Rick >> >> On Nov 9, 2023, at 1:44 PM, Iain Duncan >> wrote: >> >> My reservations are mostly around the fact that Notes is out of print and >> not available digitally so I don't really have a good resource to point >> potential users too >> >> >> _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Thu Nov 9 15:31:47 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 9 Nov 2023 15:31:47 -0800 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> <86771A06-C62C-4E97-924F-2F8FA0CBFC05@illinois.edu> Message-ID: To Rick's comment: I would even be willing to author an s4m-targeted revision as an online e-book, in case that simplifies the process any. (As in, we would only need the publisher to release the work into creative commons and neither you nor them would need to do anything else.) Michael, yes s7 "just works" as WASM. There are two examples of getting it going. I have a private repo with a (naive but functional) scheduler too, and I can cut out the s7 + Scheduler part some time if that is of use. It uses an audio worklet in C++ for the scheduler so we do jitter to the nearest 128 sample boundary for event onsets (why didn't they use 64 WASM??) but it might be useful as a proof of concept. https://github.com/actondev/s7-playground https://github.com/iainctduncan/s7-wasm On Thu, Nov 9, 2023 at 2:54?PM Michael Gogins wrote: > There's a WASM s7?? That's great! > > I may have some use for that.... > > ----------------------------------------------------- > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com > Michael dot Gogins at gmail dot com > > > On Thu, Nov 9, 2023 at 5:46?PM Iain Duncan > wrote: > >> Hi Rick, if you can get it released, I would make porting CM over part of >> my PhD work. I have now down both piggy-backing on the Max scheduler and >> written my own scheduler for WASM s7 (driven from the C++ dsp loop in the >> audio worklet), so I don't think there is any technical obstacle. I know >> George Tzanetakis (my supervisor) shares the sentiment and the book really >> is a great introduction to doing music in a lisp. Please keep me posted! It >> would be a wonderful addition to s4m if we had the book available. >> >> iain >> >> >> >> >> >> On Thu, Nov 9, 2023 at 2:19?PM Taube, Rick wrote: >> >>> I could contact the publisher and see if they would release it now in >>> the public domain. I might have the manuscript on some old hard drive but >>> I would need a release for that as well. >>> >>> --Rick >>> >>> On Nov 9, 2023, at 1:44 PM, Iain Duncan >>> wrote: >>> >>> My reservations are mostly around the fact that Notes is out of print >>> and not available digitally so I don't really have a good resource to point >>> potential users too >>> >>> >>> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orm.finnendahl at selma.hfmdk-frankfurt.de Fri Nov 10 01:24:34 2023 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Fri, 10 Nov 2023 10:24:34 +0100 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <63615289540e3a9e2e32a65e92f1235f@ccrma.stanford.edu> <431ec202-c69d-473e-a7be-83c3fd41da52@gmail.com> <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: Am Donnerstag, den 09. November 2023 um 12:30:00 Uhr (-0800) schrieb bil at ccrma.Stanford.EDU: > > When Jonathan Harvey used file that in a piece (almost unedited!) > a reviewer said they were recordings. Can't win sometimes. which arises the question: "How do we pay royalties to the birds?" ;-) From me at rochus-keller.ch Fri Nov 10 04:37:27 2023 From: me at rochus-keller.ch (Rochus Keller) Date: Fri, 10 Nov 2023 13:37:27 +0100 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: An HTML attachment was scrubbed... URL: From michael.gogins at gmail.com Fri Nov 10 06:06:40 2023 From: michael.gogins at gmail.com (Michael Gogins) Date: Fri, 10 Nov 2023 09:06:40 -0500 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: I'm taking the liberty to also reply to your question for Rick. I have experience doing algorithmic composition since 1983 in (alphabetical order, * means I have compositions on streaming music services or Web sites realized using that language): Basic*, C, C++*, CMix, Csound, Common Lisp, Fortran, Java*, JavaScript*, Lua and LuaJIT*, Mathematica, Pascal, Python*, Quickbasic, Reaktor, Strudel*, Tidal Cycles, and Visual Basic. I have worked professionally as a software engineer on trading systems using C, C++, C#, Java, and Python. In my opinion, there are too many systems for doing algorithmic composition in too many languages. This has fragmented the field of algorithmic composition and skilled people have wasted a great deal of their time re-inventing the wheel. You can see from my list that I, myself, have wasted a lot of that time. Currently, I use mostly JavaScript and C++, compiled to WebAssembly (WASM) to be used by JavaScript. The choice of language is secondary. The important things are community and history. Look for the largest and most diverse community of composers that you can find, with the longest history of compositions and the biggest library of shareable code. As far as actual programming languages go, if at all possible use industry standard languages that have proved themselves in the real world and have deep support. If we count only standard languages that feature algorithmic composition software, that's essentially just C/C++, Python, and JavaScript. But I also include Common Lisp, because although it's not a standard language it does have a deep history in algorithmic composition and an important community, especially around OpenMusic. And I include Scheme because the WASM implementation of s7 brings Scheme into the Web browser or NPM world where it can be used with JavaScript. In fact, I think WASM will become increasingly important because anything compiled to WASM can be used from JavaScript, which thus serves to glue together many different systems and packages in one environment. Good luck, Mike ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Fri, Nov 10, 2023 at 7:37?AM Rochus Keller wrote: > @ Rick: > > > Thank you very much for your response. So it was mostly a technical reason > to switch from CL to Scheme, not because of the language. It's also amazing > to learn, that you even ported the system to Python. > > > Since you therefore have experience in algorithmic composition in at least > four languages - Common Lisp, Scheme, SAL and Python - the question arises > which of these languages you consider most useful to represent compositions > and musical information. > > > I'm also curious whether you think object-orientation brings added value > to algorithmic composition. In your papers and book you emphasized CLOS; in > the Scheme version of Common Music object-orientation doesn't seem to be of > importance, and - as far as I understood - SAL doesn't support > object-orientation at all. Am I right to conclude from this that > algorithmic composition has little benefit from object-orientation? > > > Thanks > > 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: From iainduncanlists at gmail.com Fri Nov 10 09:55:18 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 10 Nov 2023 09:55:18 -0800 Subject: [CM] What motivated the change from CL to Scheme? In-Reply-To: References: <50C755A1-0778-433A-8774-9A7E2946694A@illinois.edu> Message-ID: I'll throw my two cents in. Like Mike, I have done both work code and music code in a whack of languages, though professionally for 20 years and not forty! However, I fancy I have some valuable insights from my last 5 years of doing technical due diligence for software acquisitions, in which I talk to companies ranging from startups to billion dollar things on everything tech related including the ramifications of their technical choices.. The 50+ diligences have provided very interesting insights - especially because we get the real goods as opposed to what people say publicly. In one sense, it doesn't matter too much - I have seen roaring success in all kinds of languages. At the end of the day, if you have a super smart team with deep experience in a language that can easily outweigh other concerns, and they are all pretty capable now. In another sense, it matters a great deal, in that every language is optimized for different things and if those optimizations match your needs, strengths, weaknesses, and priorities, that can make a very big productivity difference. Optimizations can be over code base size, short term vs long term goals, safety versus expressiveness, performance vs flexibility, verbosity, readability, etc. What I have come to the conclusion on though is that what *really matters* is dependency management. I believe you can use all kinds of languages well provided you make sure the way you are building software does not inextricably wed you to a certain language or platform. This, done wrong, has resulted in the silent death of countless startups who wrote products on overcoupled vendor-lock-in frameworks and were completely screwed when they outgrew some of their original assumptions. So that is a major reason I use the tools I do, and the way I do, which includes Scheme, C/C++, Max, and some csound and Python. If Max, or Pd became poor options, whether because things happened to them or my priorities changed, I can move work to a new host in short order. If s7 went away, I could move it to a new Scheme implementation. If csound went away, I could move that element to Faust, or Gen, or Chuck. Like Mike, I (generally) avoid things that put one in a walled garden. I think Nyquist and SAL are cool, but code in those languages isn't going to be useful absent their hosts. While one could say the same thing about Csound, the way I use it is very minimal and is part of a larger stack. Scheme (particularly s7) is also optimized for MY tradeoffs. I am specifically doing work for small teams, small code bases (pieces), that build on libraries (implemented in DSLs) and that I use to compose interactively *while the music plays* inside a host app. Essentially live-coding but not on stage. For this use case, I don't think you can beat Scheme. If the interactive live-coding aspect were not a priority, I don't know if I would have arrived here. For me, this significantly outweighs ease of using other people's code, but YMMV! hope that is marginally interesting.. :-) On Fri, Nov 10, 2023 at 6:07?AM Michael Gogins wrote: > I'm taking the liberty to also reply to your question for Rick. > > I have experience doing algorithmic composition since 1983 in > (alphabetical order, * means I have compositions on streaming music > services or Web sites realized using that language): Basic*, C, C++*, CMix, > Csound, Common Lisp, Fortran, Java*, JavaScript*, Lua and LuaJIT*, > Mathematica, Pascal, Python*, Quickbasic, Reaktor, Strudel*, Tidal Cycles, > and Visual Basic. > > I have worked professionally as a software engineer on trading systems > using C, C++, C#, Java, and Python. > > In my opinion, there are too many systems for doing algorithmic > composition in too many languages. This has fragmented the field of > algorithmic composition and skilled people have wasted a great deal > of their time re-inventing the wheel. You can see from my list that I, > myself, have wasted a lot of that time. Currently, I use mostly JavaScript > and C++, compiled to WebAssembly (WASM) to be used by JavaScript. > > The choice of language is secondary. The important things are community > and history. Look for the largest and most diverse community of composers > that you can find, with the longest history of compositions and the biggest > library of shareable code. > > As far as actual programming languages go, if at all possible use industry > standard languages that have proved themselves in the real world and have > deep support. If we count only standard languages that feature algorithmic > composition software, that's essentially just C/C++, Python, and > JavaScript. > > But I also include Common Lisp, because although it's not a standard > language it does have a deep history in algorithmic composition and an > important community, especially around OpenMusic. > > And I include Scheme because the WASM implementation of s7 brings Scheme > into the Web browser or NPM world where it can be used with JavaScript. > > In fact, I think WASM will become increasingly important because anything > compiled to WASM can be used from JavaScript, which thus serves to glue > together many different systems and packages in one environment. > > Good luck, > Mike > > > > > > > > > ----------------------------------------------------- > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com > Michael dot Gogins at gmail dot com > > > On Fri, Nov 10, 2023 at 7:37?AM Rochus Keller wrote: > >> @ Rick: >> >> >> Thank you very much for your response. So it was mostly a technical >> reason to switch from CL to Scheme, not because of the language. It's also >> amazing to learn, that you even ported the system to Python. >> >> >> Since you therefore have experience in algorithmic composition in at >> least four languages - Common Lisp, Scheme, SAL and Python - the question >> arises which of these languages you consider most useful to represent >> compositions and musical information. >> >> >> I'm also curious whether you think object-orientation brings added value >> to algorithmic composition. In your papers and book you emphasized CLOS; in >> the Scheme version of Common Music object-orientation doesn't seem to be of >> importance, and - as far as I understood - SAL doesn't support >> object-orientation at all. Am I right to conclude from this that >> algorithmic composition has little benefit from object-orientation? >> >> >> Thanks >> >> R.K. >> _______________________________________________ >> 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: From iainduncanlists at gmail.com Mon Nov 20 16:35:21 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Mon, 20 Nov 2023 16:35:21 -0800 Subject: [CM] doc update suggestion. Message-ID: Hi Bill, I just wanted to let you know that I have made an example of using s7 in wasm that is significantly easier to get going for the casual developer than the one Christos did, in that it does not depend on any JS build tools (it just uses vanilla JS and emscriptem). It might be good to mention that alongside the link to his - I've had a number of folks express interest in this when mentioning it in other contexts. Here is the repo: https://github.com/iainctduncan/s7-wasm -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Tue Nov 21 06:24:15 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 21 Nov 2023 06:24:15 -0800 Subject: [CM] doc update suggestion. In-Reply-To: References: Message-ID: <1e1dcfb6ffacae30b019bdc61876f9d4@ccrma.stanford.edu> Thanks! I added that to the s7 README.md file, and also added a short section to s7.html. From iainduncanlists at gmail.com Tue Nov 21 07:29:38 2023 From: iainduncanlists at gmail.com (Iain Duncan) Date: Tue, 21 Nov 2023 07:29:38 -0800 Subject: [CM] doc update suggestion. In-Reply-To: <1e1dcfb6ffacae30b019bdc61876f9d4@ccrma.stanford.edu> References: <1e1dcfb6ffacae30b019bdc61876f9d4@ccrma.stanford.edu> Message-ID: Great. I have plans (in my ever increasing work backlog, lol) to publish a more comprehensive example too that I have going as part of a pedagogy app, with a scheduler that runs in the audio worklet. I will let you know when that published. iain On Tue, Nov 21, 2023 at 6:24?AM wrote: > Thanks! I added that to the s7 README.md file, > and also added a short section to s7.html. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Fri Nov 24 13:11:24 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 24 Nov 2023 13:11:24 -0800 Subject: [CM] Snd 23.9 Message-ID: <61fab57986b4a304d465abe6cbcfa204@ccrma.stanford.edu> Snd 23.9: s7: added optional let argument to immutable? and immutable! finally added error checks to the tree-* functions see lint.scm for the previous versions s7_make_c_pointer_wrapper_with_type ' (apostrophe) now is (#_quote ...) and similarly for the quasiquote helpers, apply-values, and list-values. Thanks!: Norman Gray From anders at avinjar.no Wed Nov 29 02:38:04 2023 From: anders at avinjar.no (Anders Vinjar) Date: Wed, 29 Nov 2023 11:38:04 +0100 Subject: [CM] snd: set working dir? Message-ID: <87zfywc0ab.fsf@avinjar.no> Hi all, does anybody know a way to set cwd in snd from scheme? -anders From bil at ccrma.Stanford.EDU Wed Nov 29 03:12:46 2023 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 29 Nov 2023 03:12:46 -0800 Subject: [CM] =?utf-8?q?snd=3A_set_working_dir=3F?= In-Reply-To: <87zfywc0ab.fsf@avinjar.no> References: <87zfywc0ab.fsf@avinjar.no> Message-ID: <99c2f13e78488b59afccce05d5221dfe@ccrma.stanford.edu> Is that chdir (haven't had my coffee yet) -- if so, maybe ((*libc* 'chdir) "new-dir")?