Jahrelang war ich treuer Anhänger von freier Software und habe diese konsequent eingesetzt und mich geduldig mit allen Macken auseinandergesetzt. Letztes Jahr kaufte ich mir dann einen kleinen aber feinen Mac mini und begann, nach und nach kommerzielle Software einzusetzen. Und das Ergebnis war ernüchternd: In allen Bereichen der klassischen Anwendungsfelder hinkt die freie Software (im Sinne von “Anwendung”) den kommerziellen Äquivalenten um Jahre hinterher! Wo und woran das liegt versuche ich mal zu erklären.

Print- und Webdesign

Für die Pixelschubserei gibt es GIMP, für alles Vektorbasierte Inkscape, Scribus maßt sich an für das Layouten geeignet zu sein.

Wer mal schnell einen Flyer mit GIMP machen will, kann schonmal folgenden Satz üben: “Ja liebe Druckerei, es ist Absicht, dass die Datei in RGB ist. Ich kann kein CMYK und nehme zur Kenntnis, dass Sie keine Farbechtheit garantieren können.” Nach 10 Jahren ist es immer noch nicht möglich, in GIMP nativ mit CMYK umzugehen. Das ist dringend nötig, da die Räume RGB und CMYK nicht deckungsgleich (der Mathematiker weiß: homomorph) sind. Es gibt also praktisch keine Möglichkeit, einen sinnvollen Konverter zu programmieren, insbesondere beim stets kritischen Umgang mit der Farbe Schwarz. Schon mehrmals musste ich böse Überraschungen erleben, wie Flyer “made with GIMP” von der Druckerei kommen: Grau statt Schwarz, kantige Verläufe ins Schwarz, Firmenlogos nicht farbecht. Alleine die fehlende Unterstützung für CMYK macht GIMP also unbrauchbar für das Printdesign.

Inkscape kann ebenfalls kein CMYK. Und wenn man eine Pixelgrafik exportiert darf man sich auf hässliche Alias-Effekte und sehr harte Pixelübergänge beim Umgang mit Transparenz einstellen. Das ist für hochauflösenden Print nicht schlimm, für das Web aber schon. Schon mehrmals musste ich komplexe Vektorelemente in GIMP komplett überarbeiten, weil der PNG-Export von Inkscape selbst niedrigsten Anforderungen nicht genügt. Der PDF-Export ist nicht Adobe-kompatibel und ganz sicher wird es zu Fehlern kommen wenn man die Datei zur Druckerei gibt. Und: GIMP und Inkscape arbeiten nicht gut zusammen. Beim Austausch gehen auf jeden Fall alle Layer verloren und was mit der Transparanz passiert ist reine Glückssache.

Und was kann die kommerzielle Software, im Speziellen Adobe CS 4? Alles perfekt! CMYK geht nativ, über Pantone kann man jedes Corporate Design einfach spezifizieren, der Austausch zwischen den Anwendungen geht mit direkter Verknüpfung. Zudem ist Illustrator wesentlich mächtiger als Inkscape, alleine die Erosionswerkzeuge lassen Inkscape erblassen. Von den mächtigen Undo-Funktionen und der guten Performance (Inkscape startet bei mir 55 Sekunden lang wegen rund 200 installierten OTFs) ganz abgesehen.

Schon mal ein Magazin oder eine Broschüre mit Open Source gemacht? Alles, was nicht mit LaTeX geht, sollte man gar nicht erst anfangen. Etwas, das man eine Alternative zu InDesign nennen könnte, gibt es nicht. Scribus halte ich für unbenutzbar, wenn man auch nur ganz kleine Ansprüche stellt.

Ergo: Nie wieder Grafik mit Open Source! Meine Zeit ist mir zu schade.

Textverarbeitung

Warum startet OpenOffice 3 40 Sekunden lang? Um die hässliche Oberfläche aufzubauen? OpenOffice ist seit 5 Jahren ein fetter Dinosaurier mit einem fetten Relikt von StarOffice als Backend. Unbrauchbar wird OpenOffice, wenn man mehr als 3 Bilder im Dokument hat. Selbst das Scrollen wird dann zu träge, das Layouten gar unmöglich. Einzig die Tabellenkalkulation ist halbwegs brauchbar. “Impress” wiederum nicht, weil der essentielle Umgang mit Boxen, Pfeilen und sonstigen Grafiken zu einem sich indeterministisch verhaltenden Geduldsspiel wird.

Microsoft Office kenne ich nicht, iWorks von Apple kann aber in der erst dritten Generation deutlich mehr. Vor allem schaut es besser aus — sowohl in der Oberfläche als auch im Ergebnis. Alleine schon ein paar wenige sehr gute Vorlagen beschleunigen die Arbeit ungemein. Zudem ist die Software bei gleicher Rechenleistung performanter und wesentlich einfacher zu bedienen.

Musik

Ardour ist ein sehr gutes Beispiel, wie gut freie Software sein kann. Es konkurriert direkt mit ProTools und ist eine ernste Gefahr für kommerzielle Software. Aber: Ardour kann kein MIDI. 90% aller Anwender machen Musik mit dem Computer und verwenden die Kiste nicht nur zum Schnippeln und Mischen. Jeder Popsong, jeder Rocksong und jede noch so billige Produktion braucht virtuelle Instrumente. Die gibt es unter Linux zwar, aber nicht in Ardour. Es gibt praktisch keinen brauchbaren Host für all die Synths, die als LV2 angeboten werden. Rosegarden wiederum kann viel zu wenig. Und: Kein einziger Sampleplayer ist verfügbar. “Das läuft doch alles mit Wine” ist der Tenor. Richtig. Schlecht und träge läuft es mit Wine. Warum sollte man kommerzielle VSTs unter Linux hinfrickeln und in einen schlechten Host stecken, wenn Cubase alles besser und schneller kann?

Möchte man in der Konsole mal schnell einen Codeschnipsel oder eine Textdatei anschauen, ist more oder less die erste Wahl. Die beiden kleinen Werkzeuge können im Wesentlichen nur eines: Zeichen darstellen und eine Schnittstelle mit Scrollbalken hinbasteln. Wegen diesem Minimalismus sind sie auch recht populär.

Beim Anschauen von Code ist Syntax-Highlighting jedoch ein recht praktisches Mittel, um den Durchblick zu bekommen oder zu behalten. Less und more können Derartiges nur mit wildem Gepachte und Umkonfigurieren. Warum also nicht gleich vim als Ersatz für less verwenden? Dazu muss man die Killer-Anwendung vim jedoch erst einmal umfangreich kastrieren.
Seit Vim in der Version 6 liefert der Editor gleich ein dafür passendes Bash-Script mit, welches Vim als reinen Textbetrachter startet. Sogar die wenigen Shortcuts von less sind liebevoll umgesetzt. (So beendet etwa q anstatt :q[Enter] das Programm). Das Script befindet sich unter

/usr/share/vim/vim??/macros/less.sh

Nun muss nur noch ein Alias auf less oder more erzeugt werden und man freut sich beim Anzeigen von beliebigen Text an vielen bunten Farben.

Linux war lange Zeit nicht besonders bekannt für tolle Programme im kreativen Bereich. Erst allmählich konnten Projekte wie Gimp und Inkscape auch im professionellen Bereich Fuß fassen. Der gesamte Audio-Sektor war in besonderem Maße böse vernachlässigt. Das war nicht immer so: Schon ganz früh hatten die ersten Unix-Enthusiasten mit cSound (übrigens am renommierten MIT entwickelt) gebastelt. Und knapp 20 Jahre war dieses avagardistische „Programmieren“ von Musik das einzige, was einen dazu treib unter einem Unix-System Musik zu machen.

Die Ansprüche änderten sich aber. Das hat die Gemeinschaft der freien Software aber zu spät gemerkt. Viel zu zäh war die Entwicklung von ALSA, der endgültige Abschied von OSS und das Entwickeln freier modularer Systeme wie Jack, DSSI, LADSPA und insbesondere LV2. Der Musiker von heute braucht flexible und skalierbare Systeme für das Harddisk-Recording, einen flexiblen Plugin-Standard und ein hohes Qualitätsniveau.

Ardour2 wurde dank GTK zwar schöner, jedoch nicht zwangsläufig übersichtlicher

Und das alles soll er seit vorgestern nun in Ardour2 bekommen. Ardour ist ein Harddisk-Recorder für den gehobenen Anspruch. Mit dem Soundserver Jack kann er sich an die Hardware und an andere Software anschließen. Mit den Plugin-Standards LADSPA/LV2 und – neu in Version 2 – VST kann man auf eine Vielzahl freier, kostenloser und proprietärer Effekte zurückgreifen. Automation aller Parameter, einfaches Bearbeiten, Envelopes und flexibles Routing machen Ardour im Prinzip fit für eine professionelle CD-Produktion.

Einzig am MIDI-Sequenzing fehlt es noch. Will man MIDI-Daten verarbeiten, egal ob zur Klangsynthese oder zur Steuerung, ist man weiterhin auf Rosegarden angewiesen. Zwei Sequencer simultan laufen zu lassen ist zwar dank der globalen Transportfunktion von Jack nicht unmöglich, jedoch recht unkomfortabel. Schon seit Jahren steht dieser Punkt auf der Roadmap, auch der Google „Summer of Code“ 2006 konnte das Ziel nicht verwirklichen. Dieses Jahr haben sich aber zwei Bewerber gefunden. Der eine wird MIDI implementieren. Und der andere bastelt an einem weiteren wichtigen Feature: Raumklangmodellierung über Multispeaker Panning, samt GUI zum Konfigurieren (und hoffentlich automatisieren).

Was beim neuen Ardour aber deutlich ins Auge sticht ist die neue Bedienoberfläche. Die GUI in GTK2 ist zwar nicht wirklich übersichtlicher, aber ziemlich „fancy“. So „fancy“, dass ich die gtkrc von Ardour zu meinem globalen Theme gemacht habe. Und weil Ardour unter der GPL steht, darf ich diese Datei hier anbieten. In einer normalen Linux-Installation muss sie einfach in den Ordner /usr/share/themes/Ardour/gtk-2.0/ kopiert werden:

»Download der Ardour Theme Datei

Yamaha offers a wide variety of different products for musicians. And the most tricky part in programming them is to handle the menus, the sub-menus and the sub-sub-menus which are accessible through different modes, sub-modes and sub-sub-modes. To make the programming even more interesting for the musician, the only output that the machine gives is found on a minimal, 3×6 cm monochrome display. (Maybe you know now, why I spent 3000€ on my Clavia „Nord Stage“.)

But Yamaha knows about the problems of their costumers(?), so they offer proprietary software to program their products on a PC trough a highly developed GUI with multiple colors and readable text! This works surprisingly well - but only on Windows and Mac OS. Although the hardware is completely compatible with the “snd-usb-audio” kernel module, they did not take the effort to port their software to Linux.

I’ve figured out how to run a Yamaha Motif Rack on Linux using the built-in MIDI-to-USB device and the proprietary “Studio Manager 2.x” and the corresponding plugin for the Motif. Plugins for all digital Yamaha products and the “Studio Manager” itself can be found on Yamahasynth.com.

The first step is the setup of the hardware. Configure the synth to use MIDI-to-USB instead of the DIN connectors. Then connect the synth via USB to your PC. Make shure that the kernel module “snd-usb-audio” is loaded (take a look at lsmod) or compiled into the kernel.

Now the synth should be recognized by the system. Of course, bus and device may vary:

# lsusb | grep Yamaha
Bus 002 Device 002: ID 0499:1015 Yamaha Corp.

Now make sure that ALSA finds the MIDI ports. The port numbers may vary depending on your other MIDI devices. The port name depends on your synth:

#aplaymidi -l
Port Client name Port name
72:0 MOTIF-R MOTIF-R MIDI 1
72:1 MOTIF-R MOTIF-R MIDI 2
72:2 MOTIF-R MOTIF-R MIDI 3
72:3 MOTIF-R MOTIF-R MIDI 4
72:4 MOTIF-R MOTIF-R MIDI 5
72:5 MOTIF-R MOTIF-R MIDI 6
72:6 MOTIF-R MOTIF-R MIDI 7
72:7 MOTIF-R MOTIF-R MIDI 8

Perfect! All MIDI ports are available without configuration.

Now the tricky part: The setup.exe both of the “Studio Manager” and the plugin for the synth will fail due to some “fixme”-bugs in Wine. The bugs are related to some MSI issues and are currently unresolved. You have to install both setup.exe on a Windows machine. Then copy the whole folder “C:\Program Files\YAMAHA” from the Windows system to “~/.wine/drive_c/Program Files/” on your Linux system. This should copy both the “Studio Manager” and the plugins. Copy the following DLLs from “C:\Windows\system32″ on Windows to “~/.wine/drive_c/Program Files/YAMAHA/Studio Manager”:

• SM2DLL.dll
• msvcp60.dll
• smh-qt-mt333.dll
• smh-qtoptserver.dll
• smlogcfg.dll

Now there is one big problem: The plugin is registered to the “Studio Manager” through the installation process. So all entries in the registry are not set in Wine. So run “regedit” on Windows and export every registry node that carries a value with the path to your plugin. They can be found with the search string “YAMAHA\Studio Manager\$your_plugin_name”. There are about 7 entries just in [HKEY_CLASSES_ROOT\CLSID\] - you have to export each individal node. Don’t forget the node [HKEY_LOCAL_MACHINE\Software\Yamaha\].

Copy all exported nodes on Linux. Open each of them in notepad and save it once again (just type notepad in a shell). This is a workaround for a bug in Wine’s version of “regedit”. Now import all exported patches to the registry on the Linux machine. Regedit is also available on Wine.

After that, the “Studio Manager” will run and it will find your plugin. Now enjoy making music!

Wer braucht schon eine hässliche GUI um Musik abzuspielen? Ich nicht. Darum läuft meine Musik in aller Regel mit mplayer - und zwar in der Kommandozeile. Einzig die Steuerung gestaltet sich manchmal etwas umständlich. Während sich Amarok und Co. gerne in Form kleiner Symbole auf allen Arbeitsplätzen schnell bedienen lassen, muss man zur Interaktion mit Mplayer stets in das passende Shell-Fenster wechseln. Doch Linux wäre nicht Linux, wenn sich dieses Problem nicht elegant hacken ließe.

Das Ziel: Mplayer soll, wenn einmal in irgendeiner Shell gestartet, über meine Multimediatasten an der Tastatur bedient werden können. Egal, welches Fenster gerade den Fokus hat.

Der modulare (und chaotische) Aufbau Mplayers erlaubt da eine Lösung: Zuerst muss man eine Schnittstelle schaffen, die die Befehle an Mplayer weitergibt. Ein FIFO bietet sich dafür an:

mkfifo ~/.mplayer/mplinput

Danach sollte man Mplayer sagen, dass es als zusätzlichen Eingabekanal diesen FIFO verwenden soll. Das geht sehr gut mit einem Eintrag in ‚/etc/mplayer‘ oder besser in ‚~/.mplayer/conf‘:

input=file=/home/benutzername/mplayer/mplinput

Die Variable ~ kann von Mplayer wohl nicht aufgelöst werden, darum muss der Pfad hart kodiert sein. Ab dem nächsten Start lauscht Mplayer also an der FIFO auf neue Befehle. Die werden elegant mit einem echo-Befehl dort hineingeschrieben:

echo "pause" > ~/.mplayer/mplinput
echo "pt_step 1" > ~/.mplayer/mplinput
echo "pt_step -1" > ~/.mplayer/mplinput

Der erste Eintrag pausiert die Musikausgabe, die beiden anderen springen ein Musikstück weiter oder zurück. Weitere Funktionen lassen sich durch intensive Lektüre der Man-Page mehr oder weniger schnell erraten.

Nun müssen diese Befehle noch auf Tastendruck ausgeführt werden. Wer wie ich spezielle Multimediatasten hat, wird vielleicht mit diesen Zeilen für ‚~/.Xmodmap‘ etwas anfangen können. Eigentlich sollte der Keycode standardisiert sein. Sowohl mein IBM Notebook als auch meine Cherry Tastatur bedienen sich jenen Zahlen für Sondertasten:

keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext
keycode 160 = XF86AudioMute
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume

Das binden der Tasten an die Befehle sollte am besten dem Windowmanager übertragen werden. Bei Fluxbox etwa müssen folgende Zeilen in ‚~/.fluxbox/keys‘ hinzugefügt werden:

None XF86AudioPlay :ExecCommand echo "pause" > ~/.mplayer/mplinput
None XF86AudioNext :ExecCommand echo "pt_step 1" > ~/.mplayer/mplinput
None XF86AudioPrev :ExecCommand echo "pt_step -1" > ~/.mplayer/mplinput

Wer zudem noch die globale Lautstärke von ALSA kontrollieren möchte, sollte sich ‚amixer‘ (nicht ‚alsamixer‘) anschauen. Die Bedienung gestaltet sich recht einfach.

Professionelle Software braucht manchmal unprofessionelle Betriebssysteme. Um meine Ideen, die sich in Form von mit Bleistift geschriebenen Noten auf Papier schon zu lange stapeln, in ein akustisches Kleid zu betten, kaufte(!) ich mir mein eigenes privates Sinfonieorchester in Form von Motu Symphonic Instruments. Mein Notebook, das ausschließlich für die mobile Klangerzeugung und -verarbeitung ausgelegt ist, beherbergt sowohl Windows XP als auch ein Gentoo Linux mit den RT-Kernelquellen des „pro-audio“ Overlays. Dort läuft die Software unter Windows eher schlecht als recht. Die Latenz ist zwar im Bereich des Erträglichen, mit mehr als drei Kanälen gleichzeitig hält das System aber nicht mit. Zum live spielen mit maximal zwei Händen à fünf Finger also ausreichend, für ein Arrangement mit Sequenzer aber nicht. Darum muss nun Windows auf meinen PC, der in Personalunion auch gleichzeitig mein Heimstudio ist und bisher ausschließlich mit Gentoo Linux läuft.
Also legte ich die Windows-XP-CD ein, wartete recht lange auf das Erkennen der Hardware, akzeptierte widerwillig die EULA und widmete mich dann der Formatierung meiner Platte. Das ging aber nicht. Windows XP kann wohl keine ext2-Partition in NTFS umwandeln. Es kann sie nicht einmal löschen. Genaugenommen kann der Setup gar nichts außer eine leere Partition mit NFTS verseuchen.

Nun galt es also das Setup abzubrechen, um mit geeignetem Programm den Ansprüche von Microsoft genüge zu werden. Wäre recht einfach gewesen, hätte der Setup nicht zu diesem Zeitpunkt schon den MBR überschrieben. Dieses Konzept erschließt sich mir leider nicht ganz: Warum wird der MBR überschrieben, bevor überhaupt nur ein einziges Byte auf die Platte kopiert wurde? Baut Microsoft zuerst den Wegweiser und dann die Stadt?

Wie dem auch sei: Reparieren war angesagt. Im Ermangeln einer Boot-Diskette oder Boot-CD musste ich wohl einen chroot ausführen. Hier nun eine kleine Liste für alle, die einmal Ähnliches tun müssen:

1. LiveCD booten
2. die Root-Partition der Festplatte mounten, etwa nach /mnt/root
3. die Boot-Partition, sofern vorhanden, mounten; nach Konvention nach /mnt/root/boot
4. das Proc-System mounten bzw. erstellen; das geht mit mount -t proc none /mnt/root/proc
5. das Dev-System mounten bzw. verbinden; das geht mit mount -o bind /dev /mnt/gentoo/dev
6. mit chroot /mnt/root die neue Umgebung betreten
7. so ziemlich alles an Umgebungsvariablen aktualisieren; Gentoo macht da etc-update und source /etc/profile
8. Dem neuen System sagen, was alles gemountet ist. Das geht mit /proc/mounts > /etc/mtab. Nachträglich alle Mountpoints der Live-CD aus /etc/mtab löschen
9. grub-install /dev/hdx installiert Grub wieder dorthin wo es hingehört.
   

Ich hätte meine kostenlose Support-Anfrage, die ich vor Jahren zusammen mit der schicken Windows-XP-CD erworben habe, nutzen sollen. Alleine schon die 20 Minuten vergeudete Arbeitszeit eines Support-Sklaven hätte ich Microsoft gegönnt.

Seit nunmehr fast 4 Monaten verwende ich Beryl/Emerald auf meinem mobilen Rechner. Jenseits von technischen Problemen (die leider immer noch recht dominant sind) möchte ich mich aber hier mit der generellen Idee eines 3D-Schreibtisch befassen. Bringt das Konzept wirkliche Vorteile? Erhöht es die Produktivität oder ist es nichts weiter als Süßigkeiten fürs Auge (konsequent Anglizismen zu vermeiden ist verdammt schwierig).

Brauchbare Ansätze

Mehrere Arbeitsoberflächen sind ein wesentlicher Vorteil der Linux-Desktops. Allerdings ist die Identifikation über Zahlen oder durch ein „endloses“ Band ein recht un-intuitives Konzept. Darum neigt der Benutzer dazu, immer gleiche Applikationen auf der immer gleichen Arbeitsoberfläche zu laden. Dank dieser Strategie findet man seine Anwendungen zwar recht schnell, man beschneidet sich aber in der Freiheit. Mit den 4 Seiten eines 3D-Würfels ist dies unnötig geworden. Dank der geometrischen, wenig abstrakten Anordnung im dreidimensionalen Raum findet man sich besser zurecht als im Zahlen-Wirrwarr von Fluxbox und Co. Die Drehbewegung ist geschmeidig und in der Geschwindigkeit variabel. Damit ist der Nervfaktor bedeutend reduziert.

Ein weiteres Plus ist das angeblich von Mac OS X geklaute „Exposé“. Diese Funktion verkleinert bei Tastendruck alle Fenster, um sie dann übersichtlich und geordnet auf einer Oberfläche zu präsentieren. Ein Klick auf eines der Fenster aktiviert dieses und holt es in den Vordergrund. Auch wenn es kompliziert und umständlich klingt - dieses Konzept ist deutlich schneller und besser als die antiquierte Taskleiste. Während bei einer Taskleiste die Identifikation über das Icon oder gar nur über den Fensternamen erfolgen muss, kann die Exposé-Funktion das Fenster so darstellen, wie es ist. Besonders bei Anwendungen wie GIMP oder Ardour, die schon beim Starten zig Fenster öffnen, stellt diese Funktion eine unglaubliche Steigerung der Produktivtät dar. Während man sonst verloren und hilflos die Fenster durchklickt, findet man dank dem Exposé-Klon alles innerhalb von Millisekunden. Zudem bietet Beryl die Profifunktion, nur Fenster der aktiven Anwendung, der aktiven Oberfläche oder aller Oberflächen in die Exposé-Darstellung einzubeziehen. Mac OS X kann das nicht.

Sinnlos, unbrauchbar, fehlerhaft

Doch bei Weitem nicht alles hat seine Daseinsberechtigung im Umfeld produktiver Arbeit. Wer braucht eine dreisekündige Animation beim Minimieren eines Fensters? Ein Flirren und Zappeln beim Vergrößern eines Fensters? Oder brennende Fenster beim Schließen? Wassertropfen auf dem Bildschirm? Manchmal würde man sich wünschen, es wären weniger Spielkinder und mehr Ergonomie-Experten unter den Linux-Entwicklern. Oder wenigstens solche, die gute Dokus schreiben. Denn angesichts der Modularität von Beryl sollte es wohl nicht allzu schwer sein, sich selbst kleine Module zu schreiben - wenn denn nur die Doku vorhanden wäre. Und über deren Sinnhaftigkeit kann man dann selbst bestimmen.