On Mon, Jan 13, 2014 at 2:24 PM, Thomas Strathmann <tho...@pdp7.org> wrote: > > On 13.01.14 09:46, Frank Sheeran wrote: > > At this point, the #1 goal is to evaluate the language itself. Is a > > functional, textual, programming language the best way to design a > > patch? Better than Csound, better than visual environments like Buzz > > or Cycling '74's Max? Can I write a patch in Moselle that someone > > with no Moselle experience can understand at a glance? Can I write > > one that even a Max expert understands better than the same sound > > written in Max? I THINK so, but I haven't heard any feedback on this > > yet. > > This question has probably come up before: How does your language > compare to FAUST? FAUST is quite elegant because it has an underlying > formal semantics in terms of an algebra of data flow graphs, but the > resulting programs (even simple examples) are hard to read because of > the inherent impedance mismatch you run into when trying to describe > arbitrary directed graphs (especially those with cycles) in a linear > format. I guess the question I'm really interested in here is: How does > your language attack this basic problem.
Actully, I have basically the same question. Have you evaluated/investigated Common Lisp Music (https://ccrma.stanford.edu/software/clm/clm/clm.html)? A couple of years ago I took a course in Nyquist (http://www.cs.cmu.edu/~music/nyquist/), which I believe is based on Lisp. I found Nyquist to be quite powerful, althought I always found myself writing very complicated structures instead of composing scores, but maybe that's just because I'm such a nerd ;) Stefan -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
