Visual Haskell [and visual music langages]
Tue, 3 Apr 2001 16:18:15 -0500
[Jerzy Karczmarczuk <email@example.com>]
> (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.
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
- 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
- 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...
matt hellige firstname.lastname@example.org