Subject: Re: [linux-audio-dev] acid, linux
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke joulu 01 1999 - 22:57:11 EST
>PS: Please - everybody who is now writing something similar - step back a
>second and think of you couldn't join aRts. What is missing?
i don't want this to be read as an "aRts-bashing" letter. i think
there are lots of things to like about aRts. however, stefan did ask,
so ...
what i *think* is missing is an easy way to access the power of the
Music V/unit generator (UG) model that emerged out of academic
computer music over the course of 30 years or so.
aRts is a very nice system, but its fundamentally based around the
idea of having to be a "real programmer" to be able to provide new
functionality for it. the UG model sidesteps this issue by allowing
people who are not "real programmers" but can handle an interpreted
environment like the one offered by UG langauges to create interesting
things. you just provide a language that includes basic arithmetic,
logical and relational operators, some level of flow control, and a
rich set of functions/opcodes/procedures/objects/whatever-you-call-them;
individual users who understand very little of the workings of the
engine or programming languages (let alone IDL's) can develop very
interesting new "instruments".
there are a *relatively* large number of people who are
writing/extending/fixing opcodes for Csound and SAOL, and these don't
really lend themselves to use in aRts without a complete rewrite
(well, often). consider things like the granular synthesis opcodes for
Csound: these are complex algorithms that undergo subtle extensions
from time to time, and it seems to me that there is (currently) no
developer base out there to implement such things as aRts modules.
there are lots more examples like this. the use of SAOL for MP4 is
only going to increase the popularity of a UG model.
another criticism i would make of aRts is the centrality of MIDI. most
people familiar with MIDI know that its representation of pitch leaves
a great deal to be desired, yet the notion of MIDI interconnections
between aRts structures seems fairly fundamental to the whole
program. removing MIDI from the core of Quasimodo is one of my
projects for the new year.
finally, its not clear to me the formalization of an object
relationship between the synthesis engine and a user interface needs
or even should be taken to the extreme that aRts does. i think one can
follow Michael Gogins' lead with his proposal for a Csound engine API
- i don't think that one needs a model that looks anything like CORBA
(or the new MCOP). As long as some entity within a program exists that
supports the function calls and data present in the API, then the
program will get what it requests. It seems to me that placing the
emphasis on inter-object communication instead of object API's leads
one down a strange path for a real-time low latency application.
i may be wrong about a lot of this - i have not tried aRts in at least
a year, and i don't claim to understand much about the program. i have
read the manual from cover to cover, however :)
but to reiterate - i think that aRts is a very interesting and
valuable program, and i hope that it continues to grow and succeed.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST