[Jerzy Karczmarczuk
(And there was even a music generator ("tracker") called Buzz which had such an interface, quite well adapted to all kind of DSP algorithms, but I cannot find it any more.)
buzz is still around and under active development, but i don't have a reference for it. in a similar vein, but somewhat more advanced (and professional), are MAX/MSP, as commercial product from cycling74, Pd (which is a different, open-source, offshoot of the project that originally kicked off MAX), and jMax (also open source), which is related to Pd and MAX, but done in Java and also open-source. all of those products are primarily the work of miller puckette at ircam, although i'm not sure how involved he is in MAX anymore. MAX/MSP: http://www.cycling74.com/products/max.html Pd: http://www.pure-data.org jMax: http://www.ircam.fr/jmax/ all of these products (particularly MAX) are quite successful and highly regarded in the experimental music community, but there is, in my opinion, a lot of ugliness in the implementation. one look at the example code for writing new "externals" in Pd will put a pretty sour taste in the mouth of most programmers -- it consists of a lot of very ugly c code. it's crossed my mind on many occasions that this is a field that could potentially see quite a fuitful real-world application of functional programming, for two main reasons: - in many cases, the end user is not a hugely experienced programmer, and either lacks enough knowledge or is too intimidated to write extensions his or herself. functional programming solves this problem in some cases by being much clearer (MANY MANY times clearer than the Pd code) and easier to learn and read (for some people). - functional programming seems like it may map quite well to many of the concepts already used in these visual languages. - because of the success of this type of software, and the increasing popularity of the music made using it, this area could be a good opportunity for functional programming in the real world, as well as a good opportunity to introduce a whole new class of users to its concepts and advantages. it also may be an interesting proving ground for some more advanced features of modern functional languages: - performance. audio processing is notoriously intensive, so any remaining performance problems in the functional language implementation could make or break the product. - integration. certainly parts of the core program, and possibly extensions, would want to be written in an imperative style, either for performance, or because there are well-known and already implemented algorithms for certain dsp tasks. the functional language would need to support clean integration with other languages for that reason. - a good i/o model and lazy evaluation. many tasks in these environments consist primarily of consuming on infinite stream of input, performing some transformation, and producing an infinite stream of output. modern functional languages have a very good model for such tasks, and lazy evaluation comes in very handy here, also, allowing the programmer to express things much more closely to the way the algorithm is actually understood. - a good type system. something many of these languages rather lack is a powerful and expressive way of ensuring that connections are "correct". this could neatly solve that problem. in any case, i'd love to see more research in that area... m -- matt hellige matt@immute.net http://matt.immute.net