Vorgeschichte: warum ich oft auf Audacity herumgehackt habe
Vielleicht hat es schon jemand gemerkt: Ich war bisher kein sehr großer Fan von Audacity. Das Programm ist Crossplatform hat aber oft den Eindruck gemacht, dass es dabei eine spürbare Neigung in Richtung MS Windows verspürt. So benutzt es das vergleichsweise krude PortAudio statt unter Linux direkt auf Jack zu setzen.
Audio-Software unter Linux, die Jack vollständig benutzt, kann meistens auch Effekte in Echtzeit rendern. Das bedeutet, man kann genau hören, was der Effekt bewirkt während man seine Parameter einstellt. In Audacity ging das nicht, man musste die Parameter im Blindflug einstellen und konnte sich nur eine kurze Vorschau vorspielen lassen. Während die läuft, lassen sich die Parameter aber nicht einstellen.
Nun haben die Leute von Audacity auf Google+ einen Beitrag gepostet, nachdem sie gerade daran arbeiten, diesen anachronistischen Rückstand ihres Programms zu beseitigen. Dazu hatten sie einen Screenshot gestellt, auf dem man die native grafische Oberfläche eines VST-Effekts sehen konnte(Audacity hatte zur Bedienung von Effekten immer nur eigene, generische Oberflächen angezeigt…).
Der Linux-VST Equalizer Luftikus zeigt in Audacity nicht nur seine hübsche Oberfläche, er lässt sich auch bedienen, während der Sound zu hören ist.
Interessant. Die neuen Wunder der Technik wurden für die kommende Version 2.1 angekündigt, die Nachricht ließ allerdings erkennen, dass die Entwickler bereits damit experimentieren. Also habe ich mir die aktuellen Quellcodes via svn heruntergeladen:
svn checkout http://audacity.googlecode.com/svn/audacity-src/trunk/ audacity-read-only
Das Programm lässt sich auf einem aktuellen Kubuntu 14.04 LTS ohne große Probleme übersetzen, für seine Oberfläche braucht es die Entwickler-Pakete von WX-Windows und GTK, für Effekte und Audioschnittstellen benötigt man etwa 20 weitere dev-Pakete und deren Abhängigkeiten. Da ich auf dem Rechner schon Ardour3, Carla und andere große Audiosysteme gebaut hatte, musste ich nur WX-Windows nachinstallieren.
Der Build lief problemlos durch und Audacity 2.1 startet ganz normal. Es zeigt ein paar Warnungen beim ersten Einlesen einiger experimenteller LV2-Plugins aber ansonsten ist diese Entwickler-Beta nach ca. 3 Sekunden mit Jack verbunden betriebsbereit.
Warum wir von Software oft enttäuscht werden, obwohl das gar nicht nötig wäre.
Und? Gehts?
Geht so, natürlich probiere ich in Audacity das, was in Ardour oder Qtractor auch geht: ich bearbeite was mit einem vielfach bewährten LV2-Plugin. Die von mir bevorzugten CALF-Module tauchen auch tatsächlich in den endlos langen Effektlisten von Audacity auf. Allerdings lauert beim Aufruf eine herbe Entäuschung: der Effekt lässt sich zwar durchaus einstellen und auch anwenden aber statt seiner grafische Oberfläche gibt es nur die simplen Schieberegler von Audacity und abspielen lässt sich das Meterial während des Einstellens der Parameter auch nicht.
Wie die schlaueren unter uns vielleicht schon vermuten, unterstützt Audacity Echtzeiteinstellungen nicht für LV2. Ich selber habe mich fleißig dumm gestellt und traurige Anfragen an die Audacity Leute geschickt, ob denn die neuen Funktionen überhaupt schon im öffentlichen SVN sind und was ich denn falsch mache etc.
Natürlich liegt es an LV2. Echtzeit geht nur mit LADSPA und VST, native grafische Oberflächen nur mit VST.
UPDATE: Da fällt mir ein, dass Carla Patchbay ja auch als VST verfügbar ist. Ein schneller Test sieht schon mal prima aus: die Patchbay lässt sich in Audacity starten und zeigt auch die grafischen Oberflächen von LV2-Modulen perfekt an. Alles lässt sich wie gewünscht einstellen und es sieht so aus, als ob man damit auch in Audacity das ganze Brett der modernen Plugins für Linux zeitgemäß benutzen kann. Nur beim Anwenden stürzt Audacity ab und Carla läuft Amok. Da sowohl Audacity als auch Carla hier als exxperimentelle Betas laufen, ist das keine Katastrophe, man darf wohl hoffen, dass das noch besser wird….
Schade aber OK, die LV2 API soll wohl auch nichts für Leute mit schwachen Nerven sein. Ihre Grafikschnittstelle unterstützt sowohl GTK als auch QT und auch noch Juce und der Umgang mit Presets etc ist wohl auch nicht die simpelste Idee, die Frameworkentwickler in letzter Zeit hatten.
Allerdings funktionieren die Echtzeiteinstellungen auch nicht für die internen Effekte von Audacity, deren API die Audacity Entwickler wohl schon unter Kontrolle haben dürften.
Hier schlagen wohl einige problematische Designentscheidungen aus der frühen Zeit von Audacity zu. Audacity ist von vornherein nicht für Echtzeit gebaut und dieses Problem zu lösen, stellt eine entsprechend komplexe Aufgabe dar.
Das richtig zu programmieren ist kompliziert und langwierig, viel Arbeit und Dank und Anerkennung gibt es zu wenig dafür. Überhaupt nicht kompliziert wäre es allerdings, den Stand des Arbeitsfortschritts so zu dokumentieren, dass es beim Nutzer ankommt.
Warum bei der Axt versagen fleißige, herausragend intelligente Menschen, die sehr komplizierte technische Probleme lösen können, dabei? Es würde genügen, wenn sie statt:
Echtzeiteffekte funktionieren. Hier eine grafische Oberfläche eines beliebten VST-Effekts.
das hier schreiben würden:
Echtzeiteffekte funktionieren aktuell für LADSPA und VST, grafische Oberflächen zeigen wir für VST an(wie im Bild zu sehen).
Warum tun sie das nicht?
Der erste Gedanke wäre: weil sie sich nicht in ihre Leser hineinversetzen können. Sie sind nicht fähig, sich vorzustellen, wie ein Endnutzer da draußen ihre Nachrichten interpretiert. Das, zusammen mit der Tatsache, dass es für sie selbst, so, wie sie es benutzen, offensichtlich funktioniert, verursacht das Kommunikationsproblem.
Liegt nahe … aber lasst uns noch ein bisschen Paranoia über das Offensichtliche kippen.
Haben wir in der freien Szene nicht seit 10-15 Jahren immer und immer wieder erzählt bekommen, dass die Endnutzer doof sind? Ist es nicht das, was uns “UX”-Experten tagein tagaus gepredigt haben? Diese armen kleinen Wiesel hatten beim Erstkontakt mit freien Programmierern und deren Nutzern einen Kulturschock: da sind Leute, die wissen wollen, wie ihre Software funktioniert und die das auch herausbekommen.
Ahhhh deswegen hat Linux also nur einen Marktanteil von 1-2%! Weil es nur ein paar Halbirre in karierten 80er-Hemden mit Kompottschalenbrille benutzen können! Gestörte, arrogante Freaks, denen es nichts auszumachen scheint, als Endnutzer eines Computers ein Kommandozeilenterminal zu öffnen und dort diabolische Geheimsprache einzutippen.
So so. Und tausende haben den Quark geglaubt und glauben ihn noch. Das liegt nicht unwesentlich daran, dass viele Linux-Nutzer tatsächlich gerne den allwissenden Supernerd heraushängen lassen, der mit wissendem Schmunzeln auf die Klickibunti Mausschubser herabzublicken sich nicht enthalten kann. Es gibt aber einen Unterschied zwischen leichter Bedienbarkeit dank intuitiver Oberflächen mit präziser, vollständiger Dokumentation und idiotisch heruntergeblödeten “klicken Sie hier, dann geschieht, was Sie wollen sollten”-Produkten.
Gerade das letztere scheint aber der heilige Gral der Usability-Prediger zu sein.
Euer Gral ist eine rostige Konservendose mit scharfkantigem Rand, Freunde.
Lasst Euch nicht einreden, dass Eure Nutzer blöde sind. Sie können lesen und sie können auch Passagen überspringen, die sie wirklich nicht interessieren. Präzise und vollständige Informationen haben noch niemandem geschadet und wer sich dann doch beschwert, dass da “so unverständliches Zeugs steht”, wird Ruhe geben, wenn alles funktioniert und vielleicht noch mal das unverständliche Zeug lesen, wenn etwas nur dann funktionieren kann, wenn man die Beschreibung verstanden hat.
