Visual Haskell [and visual music langages]

[matt hellige]

[Jerzy Karczmarczuk <karczma@info.unicaen.fr>]
> (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