Happy birthday, aRts!
Well, since aRts has been available to the public for one year, I
thought it would be a good idea to look whether it has developed well in
that time, and what remains to be done. Let me introduce myself for a
second: I am Stefan
Westerfeld, the one who had the crazy idea of starting the
project.
The beginnings
First of all, it hasn't been only a year. The first line of code was
written in late 1997. Back then, aRts was developed under Aix/4.2
running on a PowerPC machine. The idea was to do modular sound synthesis,
realtimeness wasn't possible back then, since Aix had no way to do so.
Even CORBA was not an issue. I remember having a small C++ Program, which
would parse some text files containing descriptions of the synthesis model.
To get some useful data in there, there was even a Synth_STDIN module,
which could read from stdin, so you could write something like
# mpeg3play nice_music.mp3 | synthesizer bandpassmodel.syn | play 44100
to get the nice_music.mp3 filtered though a bandpassmodel. Well, I had even
a flanger and some echo structures back then, and I remember a friend of
mine telling me "wow, that flanger sounds better than that we've got in
our studio", which was pretty motivating. :)
So aRts started with a powerful and fully featured flow system from the
first day. It could do recursive calculations soon after it started running
at all. But it was not satisfying. After all, I started aRts not only to
be modular, but to be easy to use. I could have been using CSound and be
happy if I only wanted a program which I give some text files and which
spits out a sound file after parsing them.
Making it easy to use and powerful was the goal one year ago, and still
is.
GUI issues
So aRts needed a GUI. It should allow confortable and easy to learn editing
of the synthesis files that were created with text files before. Even at that
time, there were ongoing GUI wars between KDE and Gnome people.
But what had synthesis to do with the GUI, after all? Why should it be a
Gnome/KDE only app, if only one small part of it, the Builder itself, would
even need to talk to the GUI?
It should not. Gimp had the right to be tied to Gtk+ as they
built their own toolkit anyway, when neither Gnome nor KDE existed. Gimp
even had the right to be closely tied to the GUI, so that it could not
easily ported away. But a new application like aRts, whose main purpose
was sound/signal processing and not drawing, and which was written in
awareness that there are two toolkits/desktops/camps out there, had not,
IMHO!!
Silly to produce two apps of any kind and then start holy wars, just because
people who like this or that desktop better.
Besides other reasons, that was the motive why CORBA came into aRts. It
would allow the synthesizer to simply do its work, alone, independant from
the toolkit. Anyone who liked to do something with the synthesizer then
could write a GUI, a scripting system or whatever else in their favourite
programming language.
I had to decide anyway which toolkit to use for the first builder, and I had
made very good experiences with KDE (I ran it from the first betas, even
on Motorola Risc 88100 systems, and Aix boxes, when Gnome didn't exist).
Besides, my C++ knowledge was okay, and finally the thought that it wouldn't
be TIED to KDE since CORBA abstraction lead to the conclusion that this
decision couldn't be really wrong, as the amount to change it would be very
limited.
And others could develop a Gnome frontend parallely - until now there just
never happened to be someone who did that...
Midi & Realtime
Well, the KDE GUI started to work, and the CORBA stuff (aRts is using mico
as ORB) proved to be really stable and really helpful.
Soon after that I was able to switch development over to a linux box, which
made me able to work on realtime features. Arts became realtime aware
relatively fast, and the idea to process midi data was born. Since aRts
should never become a sequencer and a synthesizer, but remain a synthesizer,
communication to sequencing programs was needed.
The invention of the Midibus standard (a CORBA pased protocol to transfer
midi events between applications) was the aRts way to solve that problem.
What happened until today
As you see, most core concepts of aRts were there in the first versions
that were released officially (aRts was called KSynth in the first versions,
but that name was dropped since aRts never intended to be a KDE only thing),
and they are still there now.
But what was vaguely known to be a good idea back then is proven to work
now. Example: the midibus thing I talked of. Back then, it was just an idea
that could be done. Today, the binding to Cantor (a linux sequencer) works
quite fine, you can use the midi keyboard to improvise live on aRts. I have
an experimental version of kooBase running on the midibus standard as well,
and talked to Antonio Larossa about integration into his player classes,
which are used in KDE apps such as kmid.
The flow system is another example. In the first versions of aRts it was
really slow, but worked. Now it supports much more features, like using
structures again as modules, dynamic connections between modules AKA busses.
Adding blockwise calculation for instance, combined with module optimization
made aRts five times as fast in some structures, but of course added a lot
of complexity to the recursive scheduling algorithms.
Finally, releases have been announced, documentation has been written, the
web site and mailing list are there now, and the code is more useful than
ever.
On the other hand, the people (and their machines out there) have changed.
When CORBA was something unknown to most in 1997, the KDE and Gnome projects
have made it something for everybody. Distributions like SuSE ship CORBA
ORBs with their CDs, and more and more people know KOffice.
And of course, the sequencer software, that is the condition under which
a software synthesizer can be used to do real work, are now better than
ever. KooBase is one of the newer ones, that looks really useful, on the
other hand Cantor has appeared since a long time.
There are talks about integration/code sharing/... going on all the time
now between aRts/kooBase/Cantor. There will be some good solution, I am
sure.
Other sound processing programs of course could also benefit from aRts,
well, let's see.
The future
Arts is a pretty nice piece of software already. But what is to do now?
Well, to look back to the beginnings: making it easy to use and powerful
was the goal one year ago, and still is.
There are some new points in the "easy to use" goal now. One is the GUI
Builder. As you see in the latest screenshots, aRts should provide sliders,
buttons and control panels for the future. Of course they create new needs
for ArtsBuilder, and require new features from the flow system. Also, their
clean integration into the midi processing scheme seems important. When
having a slider that controls for instance the cutoff of some filter
in some midi instrument structure, one would like to have
- only one slider on the screen
- always that slider on the screen, even if no midi note is being played
right now
- hear the effect of turning this one slider in every note that is being
played right now
Well, aRts can't do that now, since this requires some new dynamic
connection strategies between the GUI elements and the instruments.
Of course, if that parameter is also controllable via midi, one
would like to have the slider move when midi events appear, and perhaps
also the other way round.
You see - more work on "powerful" requires more work on "easy to use" and
vice versa. Overall, the flexibility of the modelling that aRts supports
has to grow further. In the first versions, one was only modelling one
structure, and then executed it. Then, it became evident that it would be
great to execute more than one structure at once (on the same server at
the same time). Busses then appeared to make structures communicate, and
connect/disconnect themselves dynamically. So you can send signals generated
inside one structure to another.
Later, with midi routers, the functionality appeared to let modules create
structures on demand. So when someone presses a key on the midi keyboard,
aRts can generate just the modules it needs to generate that sound, and when
the key is released again, the structure can be removed again.
Structures inside structures appeared now, to allow a kind of "code reuse"
inside structures. Since a user probably doesn't like to build the same
effect from scratch every time he needs it, he can now make it a module and
reuse it every time he needs it.
But here is probably not the end of the development. As always, the task
will be that a user needs to build models of his ideas of signal
processing in aRts. But both, the modelling and the execution techniques
need more refinement to provide concepts that allow intuitive usage and
high flexibility.
After all, the modelling challange is to model real studio technology in
aRts, which just happens to be very different in purpose, interface and
usage. A mixer is different from an instrument, and this differs from an
effect. The structural modelling of aRts needs to be powerful enough to
allow modelling them all in a reusable manner. The description of a mixer
for instance should not contain a fixed number of mixing channels or a
fixed equalizer style which is tied to the mixer. Instead, these should
be parameters which at least should be changeable when the user starts
the mixer, better even at runtime.
Everything then needs to be integrated in a control model that allows either
direct control from the user (via GUI interface), or via midi.
Finally the claim aRts makes is to have a virtual studio of your own. You
should enter your studio when starting aRts and loading something, and
leave your studio when closing aRts. And you should be able to take your
whole studio and put it on a floppy and go to some friend, and work with
it there.
From the simplest effect to complex interacting systems, everything should
consist of interacting small components. The idea of having a new filter
scheme or a modification to an existing effect implemented in just a few
minutes, without writing a line of code, is what aRts wants to be. Still
the efficiency should be high, so that effects implemented as aRts
structures are usable in daily work. Of course if something is great and
used every day, someone can still handoptimize it in some C++ code fragment,
which can then be used.
Certainly this is also something where work needs to be done: aRts currently
requires every module that it uses to be compiled in. Better would be of
course to have them seperately, so that people can write and install new
modules without needing to recompile aRts. A good API of course must be
based on a flow system which is finished. The need for new control
models and new flow system (execution & modelling) features is something
that needs to be coordinated with the externalization of the aRts
modules.
Anyway, it would be a good idea to aim at having a lot of free high quality
digital filters available in the future. Perhaps not even only for aRts,
but also for wave editors, or other programs which may need something like
that.
But to find some conclusion words, as I am seeing how many motivated people
are working on such things right now, things should improve a lot in the
next time. Right now, there are many ideas like aRts and ATech,
kooBase and Cantor, MMM and Sonic Flow, PSL and ESD, KAudioServer and
libmediatool, and many others I have forgotten... most of them will
mature, and the need to make things work that is very strong in the free
software world will make those work together where it makes sense. The
winners will be the end users, which will not only get a nice desktop
environment like KDE/Gnome, nice free office tools like
KOffice/Gnumeric, but also professional music software.
I think with Gimp, KDE and Gnome, the people who do free software have
accepted the idea that the power of programs expresses itself not only
in inner beauty, but also in efficient user interfaces. Well, free
software isn't only for programmers anymore, ... and perhaps soon even
musicians will like it.
If you like, go to
http://linux.twc.de/arts
now, and get the source, and play with aRts. Subscribe the mailinglist.
Join the team. Build the future.