Subject: Re: [linux-audio-dev] acid, linux
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: to joulu 02 1999 - 18:54:45 EST
Hi!
On Wed, Dec 01, 1999 at 10:57:11PM -0500, Paul Barton-Davis wrote:
> >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 ...
I'll read it as constructive criticism ;) Perhaps I can also make the
direction a bit more clear, since aRts seems to be one of the projects
nobody really knows what exactly it is ... I should really document
the aRts/MCOP plans/internals/visions somewhere.
> 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. [...]
> 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".
What I did just show you in the last mail is about the "raw internals"
of aRts. How it looks inside.
On the surface, it will be still UG model, so every normal user can draw
flow graphs, using simple modules "real programmers" wrote. So you write
a sine oscillator, add module, multiply module, triangle oscillator and
some filters. People can then build their synthstrings themselves, without
knowing anything about how these modules actually work (let alone IDLs).
When the UG model was developed, the normal "academic way" to make music
was to write a piece of music in your text editor, describe the instruments
also in a text editor (using these nice opcodes). Then you would put your
computer to work, and after 20 hours of calculation, you would hear the
result. Compiler like music creation. Like LaTeX for writing books.
But today, people want something that is interactive at every point, greatly
integrated with the GUI, easy to understand (at least first steps) even if
you have no clue about anything, visually attractive, etc.
When people are using AudioLogic or CuBase and these various Plugins,
Softsynths and whatever, they get a lot more of what they expect than
if they are using CSound and Emacs.
> [...]
>
> 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.
There are some modules which deal with MIDI, and to those the thing is
fairly important. However, midi instruments currently are somewhat tied
to midi, and kludgy implemented in the arts core. For instance, you can't
use a midi instrument for something else than for midi. I suppose to be able
to get around all this by looking at these instruments again as objects.
So that goal for the next year we share between aRts and Quasimodo. ;)
> 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.
Let's say: it's not proven that it's really a great thing to do it like
aRts does, but I suppose it is (though certainity only comes if you go
that way quite a while and see if it proves successful - somebody's got
to try it).
Note however the relationship between the modules (or if you like) opcodes
needs to be formally defined in any case for useful editing, and using the
same formal definitions for "opcodes" and "widgets" - which happen to be
something similar in aRts - seemed to be a good idea.
> 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.
Well, what I observed is: whatever datatypes you want for "opcodes",
you will also want to edit them in the GUI. Whatever data you communicate
between "opcodes", some day, you will have the need to visualize them.
When you are constructing flow graphs, they shall be tightly coupled to
corresponding GUI elements (or at least that should be possible). When
building larger plugins, they should have larger GUIs.
For instance if you have an opcode (to use the UG related terminilogy)
which takes filter coefficients or which produces FFT packets, the day will
come where anybody wants to modify the filter coefficients and the FFT
packets manually.
Of course, you can include FFT packets, and filter coefficients, and Midi
Events, and whatever in the aRts core API. But I want people to be able
to extend things even when they are not in the core API. Instead, the core
API should only contain some essential things.
I am not sure about possible other approaches, but having real objects,
real communication between objects, and for instance "real saving" of
GUI objects seems the easiest way to achieve in aRts what I stated above
as goals: consistent GUI integration throughout the system, interactivity
at any point, ...
> but to reiterate - i think that aRts is a very interesting and
> valuable program, and i hope that it continues to grow and succeed.
Thanks! ;) We could also try hard to reach interoperability between
aRts and Quasimodo (that could be an even more valuable goal for the
new year than throwing out midi of the respective core's ;), as we'll
probably both continue to go our own way in the next time.
Cu... Stefan
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST