Happy birthday, aRts!

Stefan Westerfeld

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. For those of you who don't know anything about aRts: aRts stands for analog realtime synthesizer. It runs (mainly) under linux and is available under GPL, which makes it free software that comes with full source. More info is at http://linux.twc.de/arts.

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.

Stefan Westerfeld