Audioprobleme und Sehnsüchte ...

... nach den alten Zeiten<br /> <br /> Es war einmal ein großes 19" Rack - vollgestopft mit Soundmodulen, Effektgeräten und einem Mische ...

Schlagworte:

... nach den alten Zeiten

Es war einmal ein großes 19" Rack - vollgestopft mit Soundmodulen, Effektgeräten und einem Mischer. Das ganze Zeug hatte ziemlich viele Höheneinheiten, staubte schnell ein (es war schwarz) und jeder der dort eingesetzten Tonerzeuger hatte einen eigenständigen Sound mit echtem Wiedererkennungswert. Das war vor vielen, vielen Jahren, da war ich stolzer Besitzer einer ganzen Armada von Hardwaretonerzeugern und EFX-Equipment.


Vorweg eine Warnung. Aufgezeigt wird hier unsere ganz persönliche Sichtweise und Entwicklung in Sachen Musiker-Hard- und -software. Unser Standpunkt soll eine Diskussion anstoßen - mehr nicht.

Geschichte

Mit dem Aufkommen der ersten virtuellen Instrumente schien mir meine ganze Synthesizer-Hardware hoffnungslos veraltet und ich habe zugesehen, den ganzen Krempel so schnell wie möglich zu verkaufen. Bei meinem damaligen S 2000 hatte ich damit allerdings schon zu lange gezögert. Hardwaresampler gaben sich als erste den Software-Instrumenten geschlagen und so habe ich für meinen alten Akai kaum noch Geld bekommen. Das machte aber nichts! Es galt die neuen VSTis und eine riesengroße Auswahl von Plug-ins zu entdecken. Ganz neue Welten taten sich auf und das Potenzial von Software war (und ist) schier unbegrenzt. Inzwischen aber macht sich bei mir zunehmend eine gewisse Ernüchterung breit ...

Das Problem

Die Einfachheit, mit der man damals neues Equipment in Betrieb nehmen konnte, war schon bestechend. Produkt aus der Verpackung schälen, ins Rack schrauben, verkabeln, fertig! Macht man das heute mit einem Softwareprodukt, sieht die Sache schnell anders aus. Während z.B. Native Instruments bei der Installation und Autorisation hervorragend abschneidet, ist die Installation und anschließende Autorisation bei Waves im Vergleich extrem aufwändig.

Aber die Installations- und Autorisationsprozeduren mancher Software-Hersteller sind nicht das einzige Problem, mit dem man sich als Digitalmusiker in heutigen Zeiten herumschlagen muss. Installierte man sich am 26. Oktober 2007 ungefragt Apples neues Betriebssystem Leopard auf seinem Computer (oder kaufte sich einen, auf dem dieses System vorinstalliert war), hatte man plötzlich ganz schlechte Karten. Trotz langer Betaphase und trotz der Tatsache, dass inzwischen über 3 Monate vergangen sind, gibt es für diverse Audiointerfaces noch keine angepassten Treiber. Steinberg kann (konnte?) für Cubase nur einen Betainstaller liefern, der Cubase auf ein frisches Leopard bringt. Will man dann auf 4.1 updaten, wird man vom Betriebssystem gewarnt, dass das Update das System beschädigen kann. Auch Waves ist immer noch nicht Leopard-Ready (Not Yet Supported).

Ich frage mich, warum es z.B. Ableton schafft, Live 7 fit für Leopard zu machen und Digidesign oder Steinberg dies nicht pünktlich hinbekommen. Weiter frage ich mich, ob vielleicht der eine oder andere Hersteller zu viele Audiointerfaces im Programm hat und womöglich deshalb nicht mehr in der Lage ist, zeitnah funktionierende Treiber zu liefern.

Ich hab das alles so dermaßen satt, dass ich - so verrückt es klingen mag - schon wieder von Hardware träume. Bei virtuellen Instrumenten habe ich in Sachen Qualität zwar das geringste Bedürfnis, die gegen Hardware einzutauschen, aber es hat auch was, wenn man Zugriff auf einen Synthie oder eine Workstation hat, den / die man auch ohne Computer spielen kann. Besonders interessant finde ich derzeit Korg M3, Roland Juno-G, Juno-D und SH-201 - oder doch lieber ein Yamaha Motif XS 8? Da passen ja diese sehr schönen Erweiterungsmodule herein - allen voran die AN1X-Tonerzeugung! Ich hatte das AN1X-Keyboard mal und fand es obergenial!

Welche Lösungen bieten sich nun für Digitalmusiker an, zukünftig Softwareproblemen so weit wie möglich aus dem Weg zu gehen und Betriebssystemupdates und einen komfortablen Audiosequenzer unter einen Hut zu bringen?

Als Apple-User liegt die Lösung nahe und hört auf den Namen Logic. Auch wenn es nicht hundertprozentig sicher ist - die Wahrscheinlichkeit, dass Apple OS X so updatet, dass Logic nicht mehr läuft, ist vergleichsweise gering - geringer jedenfalls, als bei einem Mitbewerberprodukt. Auch Ableton kommt hier in Frage, hat die Berliner Softwareschmiede doch bewiesen, dass sie mit Live 7 aus dem Stand Leopard-ready ist.

Welche Möglichkeiten Treiberprobleme zu umgehen bieten sich bei Audiointerfaces?

Wer als Apple-User über einen Mac mit Digitalanschlüssen verfügt und nicht auf eine große Zahl von Audioein- und -ausgängen angewiesen ist, sollte zu einem Interface mit S/PDIF-Schnittstelle greifen. Hier werden keine externen Treiber benötigt, weil die Ein- und Ausgabe über CoreAudio abgewickelt wird.

Jörn Daberkow



Heiko Wallauer: Wie Jörn kenne auch ich sie noch, die "gute alte Zeit", als Racks noch mannshoch und voll mit Equipment und Mischpulte raumfüllend waren. Und auch ich komme jetzt bestimmt vom Hundersten ins Tausendste, und bestimmt sind meinen Ansichten rein subjektiv, man möge es mir aber nachsehen.

Ähnlich wie Jörn macht mich die aktuelle Entwicklung auf dem Software-Markt nachdenklich. Sei es nun Apples Leopard oder Micorsofts Vista, auf beiden Seiten zeichnet sich eine fast analoge Entwicklung ab: die nämlich, dass es Anbieter im Musik- und Audiobereich anscheinend nicht mehr schaffen, zeitnah Treiber bereitzustellen oder aktuelle Betriebssysteme zu unterstützen. Inwiefern Apple im Falle Leopard oder Microsoft im Falle Vista Informationen nicht an Drittanbieter weiterkommunizieren, entzieht sich natürlich unserer Kenntnis, trotzdem finde ich es im Falle Leopard mehr als peinlich, dass es selbst über zwei Monate nach dem Release für bestimmte Produkte keine Updates oder neue Treiber gibt. Statt Lösungen zu haben, bietet man dem User, der immerhin mal Geld in ein Produkt und dessen Zukunftssicherheit investiert hat, auf breiter Fläche vollmundige Erklärungen, weshalb man noch keinen Support für Apples aktuelles Betriebssystem liefern kann. Das Liest sich auch alles ganz nett, aber wenn ich zu Weihnachten meinen neuen iMac mit vorinstalliertem Leopard auspacke, nützt mir das relativ wenig, auch nicht der Hinweis, dann neben Leopard ein bootfähiges Tiger-System zu installieren. Wo soll man das denn hernehmen?

Natürlich könnte man mutmaßen, dass sich Apple für Logic oder Final Cut einen strategischen Vorteil verschaffen möchte, dagegen spricht jedoch, dass zum Beispiel Ableton schon in der ersten Version von Live 7 volle Leopard-Funktionalität bieten konnte (ausgenommen Cocoa).

Neben Ableton sind auch viele kleinere Anbieter von Plug-ins gleich vorne mit dabei, wenn es um aktuelle Versionen geht. So war ich erstaunt, wie viele von meinen Plug-ins nach dem Wechsel auf Leopard ohne zusätzliche Updates lauffähig waren.

Was ich die Tage gar nicht mehr hören kann, ist "Beta". Ich meine: Hey, was soll das? Da werden halbgare Treiber und Programmversionen angeboten, nur um dem User eine Entwicklung vorzugaukeln. Viel eher dürfte es doch Frustrationen zur Folge haben, wenn das gewohnte Maß an Betriebssicherheit und Funktionsumfang nicht gegeben ist.

Natürlich könnte die Lösung so einfach sein: man aktualisiert sein System einfach nicht und bleibt auf einer funktionierenden Versionsnummer. Das mag ja auch im Einzelfall praktikabel sein, lässt aber völlig außer Acht, dass die wenigsten von uns "nur" Audio machen. Egal ob Homerecorder, Ton-Ingenieur oder Musiker, eigentlich kommt heute keiner mehr damit aus, sich den Computer exklusiv für eine Anwendung zu reservieren.

Der Musiker auf Tour führt auch noch seine Korrespondenz und Buchhaltung über sein Notebook, der Homerecorder möchte seine eigene Homepage mit Content füllen und das Profi-Studio hat auch noch Videoschnitt mit Final Cut im Angebot.

Plug and Play, so wie ursprünglich mal mit der digitalen Revolution gedacht, ist das schon lange nicht mehr.

Plug and Play war früher: man kommt ins Studio, legt den Stromschalter um, das Pult fährt hoch, man legt das Band in die Maschine und kann loslegen.

Natürlich entwickelte jedes Studio mit der Zeit auch ein (mitunter kurioses) Eigenleben, welches fernab der eigentlich geplanten Funktionen lag, aber das kannte man, weil es vorhersehbar war. Man wusste einfach: Immer wenn ich am Steckfeld in einer bestimmten Reihenfolge Geräte zusammenschalte, tritt eine Anomalie auf. Also macht man das einfach nicht mehr, oder fand eine Lösung - schließlich hatte man Messgeräte und einen Lötkolben. Wie sähe das heute aus? Im Source-Code selbst editieren?

Auch wenn ich auf bestimmte Errungenschaften nur noch ungern verzichten möchte, so vermisse ich sie doch manchmal, die Zeit als ich anfing, mich mit Recording zu beschäftigen. Denn statt ständig den neuesten Programmversionen hinterher zu jagen, Treiber zu aktualisieren und im Anschluss mit Konflikten zu kämpfen, konnte man produktiv und kreativ sein. Ja, man musste dies sogar sein, Studiozeit war teuer und kostspielig.

Im Gegenzug musste man als Studiobetreiber sicherstellen, dass die volle Funktion des Equipments gegeben war, ein Anspruch der aktuell nur noch schwerlich zu erfüllen ist.

Eigentlich sollte ja heute alles viel besser sein: den teuersten Faltungshall hat man sich in den Rechner gepackt, sämtliche Amps für Bass und Gitarre hat man virtuell in einem Plug-in, dazu noch die Hammond B3, das Rhodes und den Steinway-Flügel. Und trotzdem: Immer öfter sieht man sich damit konfrontiert, all die schönen Sachen gar nicht mehr benutzen zu können, weil man mal wieder eine Komponente im System mit einem Update versehen hat, das den Sequenzer-Host nicht mehr starten lässt. Und alles nur, weil man in Quicktime Videos im Vollbild anschauen wollte ...

Heiko Wallauer



Sascha Sachs: Ich war eigentlich nie ein echter Hardware-Fetischist. Irgendwann in den 90ern fing es an, Roland entwickelte die erste Groovebox, die MC 303 und in meiner Funktion als DJ musste ich sie einfach haben. Das kleine Gerät hat verdammt viel Spaß gemacht, doch irgendwann wurden die Computer leistungsfähiger und so plumpste ich in die IT-Welt. Ein bärenstarker PC mit einer gigantischen 200MHz-CPU zog ein. Natürlich war auch der Rest nur vom Feinsten. Eine 4,3GB große SCSI-Festplatte wartete darauf gefüllt zu werden und eine der besten Soundkarten jener Zeit schickte sich an, große Töne zu spucken - die TerraTec EWS 64XL. Für den Preis dieser Karte bekommt man beim Lebensmitteldiscounter heute ein ziemlich fesches Notebook, selbst wenn man nicht von DMark auf Euro umrechnet.

Die Software der Soundkarte war nicht komplett. "ED!SON", der Wave-Editor, wurde in zahlreichen Beta-Versionen nachgeliefert. Wir bekamen noch die guten alten 3,5"-Disketten per SnailMal zugeschickt, denn ein Internetanschluss war damals noch keine Selbstverständlichkeit. Nach rund 2 Jahren war das Ding dann komplett. Dokumentationen dieser wilden Zeit findet der geneigte Historiker noch heute im Netz.

Die Jahre gingen ins Land und mit ihnen die Rechner. Die aktuellen Maschinen hatten erst 600, dann 1200MHz und irgendwann entdeckte ich Reason. Sowas hatte ich immer gesucht, eine einfach zu bedienende Software. Reason war zu jener Zeit spektakulär, es hatte alles was man brauchte, mehr nicht. Aber es war rock stable. Anschalten, loslegen. Das Dumme war, dass diese Soft den Wunsch nach mehr auf geradezu bestialische Weise forcierte und so dauerte es nicht allzulange und der MicroKorg zog bei mir ein.

Der kleine Synthesizer brauchte einen Eingang in den PC und so schaute ich mich nach einer neuen Soundkarte um, denn die Terratec hatte längst den Besitzer gewechselt, nachdem sie durch 3 Eigenbau-PCs gezogen war. Zwar nicht mehr ganz N00b, aber auch nicht wirklich fortgeschritten, lies ich mir eine Creative Audigy Platinum andrehen. Ganz tolles Ding! Bestand aus zwei Teilen, unterstützte alle möglichen Surround-Formate, sogar THX-zertifiziert war sie. Dummerweise unterstützte sie meine Audiosoft nur mit einer Samplingrate von 48kHz, was immer wieder zu extrem nervtötenden Problemen führte. Dass Reason keine Audiospuren hat, wurde langsam aber sicher auch zum Ärgernis. Und so häufte ich Hardware an, mit dem Ziel, irgendwann autark ohne Rechner musizieren zu können. Zum kleinen Korg gesellte sich eine Electribe aus demselben Hause. Und dann noch eine und noch eine. Später kamen ein Yamaha DX7 und ein Korg Z1 dazu. Die gebrauchten Synths kostet fast weniger als Software. Natürlich musste ein Mischpult her. Ich kaufte einem Kollegen sein Behringer ab und erfreute mich am Rauschen. Manche Fehler muss man einfach selber machen.

Während dieser Zeit häuften sich die Hiobsbotschaften über Microsofts kommendes Betriebssystem - Longhorn. Das OS wurde mehrfach umbenannt, so schlecht war sein Ruf schon Jahre vorm Release. Später sollte es Vista heißen. All die Horrorstories über die totale Entmündigung des Users lösten einen nicht zu unterdrückenden Fluchtinstinkt aus. Einerseits mit Hardware auf der sicheren Seite, andererseits die Bude voll mit teilweise uraltem Gerümpel und einer 500km langen Kabelsalatbar haderte ich eine gewisse Zeit. Dann trennte ich mich von Synths und Grooveboxen und stiegt auf den Mac um. Ein G5 kam ins Haus, nach und nach neue Soft. Alles war gut, alles funktionierte und die Frickelei machte Spaß wie lange nicht mehr. Irgendwann wurde ich übermütig und missachtete die goldene Regel, die da lautet: "Never touch a running system".

Ich hatte ein kleines MIDI.Keyboard von Evolution und beim Allmächtigen, ich hätte es behalten sollen! Aber irgendwann brachte Novation diese Remote-Serie auf den Markt. "Automap" hieß das Zauberwort. Diese MIDI-Hupe sollte alle möglichen Soft-Synthesizer erkennen und automatisch die wichtigsten Parameter belegen und in hübschen kleinen Displays anzeigen. Wooow! Ich ging in einen Laden und kaufte das Ding. Und natürlich funktionierte gar nichts. Die Tasten klapperten wie ein Güterzug, aber von Automapping keine Spur. Im Gegenteil, viele meiner Softies wurden erst gar nicht erkannt und so blieb meist das Klappern der Tasten das dominierende Geräusch. Und das war kein Einzelfall, die einschlägigen Foren waren bereits mit Beschwerden gefüllt. Also packte ich das Gerät wieder ein und marschierte zum Händler, um es gegen mein Geld einzutauschen. 2 Tage waren vergangen, das sollte kein Problem sein. Doch der kleine Shop sträubte sich mit Vehemenz, Kulanz walten zu lassen. Nach einer großen Überredungsoffensive tauschten sie das Novation gegen ein Ozonic von M-Audio. Ich habe seitdem nie wieder etwas im Fachhandel gekauft. Warum kostenpflichtig Betatester spielen, wenn man beim Onlinehandel des Fernabgabegesetz wahrnehmen kann!?

Das Ozonic war nicht die schlechteste Wahl, es ist ein Audio/MIDI-Interface, also eine externe Soundkarte mit einer MIDI-Hupe drumherum. Es kommuniziert via Firewire und es funktionierte. Es übernahm fortan den Job des kleinen Edirol-Mischers. Der M-100FX war eine externe Soundkarte mit einem 10-Kanal-Mixer drumherum. Der hatte putzige Effekte, kommunizierte via USB und er funktionierte. Als das Ozonic ihm den Job weg nahm, wechselte er für einen Schleuderpreis den Besitzer. Das war der nächste grobe Fehler, aber das durfte ich erst viel später erfahren. Nach Jahren Spaß mit Software pur, zog kürzlich ein kleines Spielzeug bei mir ein, der Korg Kaossilator. Per Klinke ins Notebook gesteckt, kann man mit seiner präferierten Audiosoftware Phrasen aufzeichnen und layern und so ganze Songs mit dem kleinen Synth basteln, ein Heidenspaß. Heute versuchte ich, den kleinen Korg ins "Analog In" des Ozonic zu stöpseln und auf diese Weise aufzuzeichnen. Aber ich habe die Rechnung ohne die Wirte gemacht, Apple und M-Audio.

Apples Katastrophen-Update - "OS X 10.4.10" - hatte der Audioklientel viel Ärger bereitet. Zahlreiche Firewire-Devices hatten den Dienst quittiert oder liefen nur noch mit Störungen, besonders die Intelmaschinen waren betroffen. Apple legte irgendwann Patches nach, 10.4.11 kam und hier und da wurde wieder stressfrei Musik gemacht, heißt es. An mir war der Kelch bis dato vorübergegangen.

Die Aufnahme über die Analog-In des Ozonic erfordern im Audiosequencer einige Umstellungen. Das ist schnell erledigt. Aufnahme läuft, klingt klasse. Dummerweise bleibt alles stumm, will man das aufgenommene Material hernach anhören. Also wieder umschalten. "Ui, jetzt kommt was! Hm.. klingt aber sau mies. Warum knistert das so?" Alle möglichen (und unmöglichen) Einstellungen führen zu einem der beiden Ergebnisse: Stille oder Knistern. Ein beherzter Klick auf den UPDATE-Button der Ozonic-Software zeigt, dass der aktuellste Treiber bereits installiert ist. Die letzte Version von OS X Tiger ist auch vorhanden: 10.4.11. Ein Blick auf das Treiberangebot auf M-Audios Seite verrät, dass die letzte Treiberversion für 10.4.10 geschrieben wurde. Die haben es bis heute nicht geschafft, dem Treiber ein Update zuteil werden zu lassen. Von Leopard ist erst recht keine Rede. "Na gut", denk ich mir, "das ist sicher dieses Intel-Mac-Problem. Probier ich's halt an meinem guten alten G5!" Also das ganze Geranze umgestöpselt. Ergebnis: beim G5 knistert es immer. Beim Recorden, beim Abspielen, beim Verzweifeln. Auch der G5 arbeitet mit der letzten mir bekannten Version von OS X Tiger. Neugierig geworden, teste ich den exotischen Arbeitsablauf - das Recorden eines Audiosignals über den analogen Eingang eines Audio-Interfaces - mit Garageband. Dasselbe Ergebnis, auf beiden Macs: Sauberes Signal beim Aufzeichnen, Knistern beim Abspielen. Auf Wiedersehen, M-Audio! Hallo eBay!

PS: ja, ich werde in der Auktion natürlich deutlich darauf hinweisen, dass das Ozonic am Mac Probleme bereitet und dass genau den Verkaufsgrund darstellt. Auch wenn das meinen Verlust maximieren wird.

Sascha Sachs



Da unser Artikel einige Fragen aufgeworfen hat, haben wir den Entwickler Stephan M. Bernsee (www.dspdimension.com) gebeten, uns die Zusammenhänge zu erklären und auf den Punkt zu bringen.

Stephan, hat sich in Leopard sehr viel verändert, oder warum laufen einige der aktuellen Software-Produkte noch nicht auf Leopard?

Verändert hat sich in Leopard hinsichtlich Audio eigentlich nicht sehr viel. Die meisten der Funktionen von Tiger sind auch weiterhin unter Leopard nutzbar, allerdings gibt es wie bei jedem größeren Update drei Punkte, die zu beachten sind:
  1. obsolete Funktionen. Einige der Funktionen, die in Tiger zur Verfügung standen, wurden aus Leopard entfernt oder durch andere ersetzt. Das ist ein normaler Prozess, der dazu dient, das Betriebssystem und seine Funktionen übersichtlich und konsistent zu halten. In der Regel wurde man unter Tiger bereits vorgewarnt, hatte also theoretisch Zeit, seinen Code entsprechend umzustellen. Natürlich sind dies aber auch die Dinge, die man als Entwickler gerne ein bischen vor sich her schiebt, da der Code ja zunächst einmal funktioniert.
  2. Strengere Kontrolle der Argumente. Speziell im Audio-Sektor geht Leopard etwas strenger mit den Argumenten von Funktionen um, die z.B. auf die CoreAudio Schnittstelle zugreifen. Dinge, die unter Tiger noch akzeptiert wurden, aber eigentlich schon damals nicht okay waren werden unter Leopard jetzt z.B. mit der Weigerung, etwas abzuspielen quittiert.
  3. Bugs. Natürlich gibt es auch in Leopard echte Bugs, die dazu führen, dass manche Dinge nicht mehr oder nicht richtig funktionieren. Allerdings sind diese in der Regel seltener anzutreffen, als einen die Entwickler glauben lassen wollen. Aber es ist (zumindest in Deutschland) auch teil der Entwicklerkultur, mit dem Finger auf andere zu zeigen, wenn etwas nicht geht. Das darf man in der Regel aber nicht so ernst und schon gar nicht persönlich nehmen, denn es hängt meistens mit unterschiedlichen Denkweisen und Lösungswegen der Beteiligten zusammen.

Darüber hinaus gibt es natürlich noch die erweiterten 64bit-Fähigkeiten von Leopard sowie die neue Cocoa Speicherverwaltung, die aber nicht zwingend von der Software auch unterstützt werden müssen. Man muss also die Umstellung nicht gleich mitmachen. In vielen Fällen kann man sie auch gar nicht machen, da manche Funktionen sie (noch) nicht unterstützen, oder will sie nicht machen, weil sich der benötigte Speicherplatz eventuell erhöht.

Wie sieht das mit den Treibern von Audiointerfaces aus? Unterscheidet sich die Programmierung sehr von VSTis, Plug-ins oder Sequenzern, oder warum scheint es so schwer zu sein, sofort funktionierende Treiber bereit zu stellen?

Der Grad der Schwierigkeit hängt hauptsächlich davon ab, wie man die Hardware auf der einen Seite mit der vorgegebenen Treiberarchitektur der Zielplattform zusammenbringt. Das ist aber eine prinzipielle Sache, die erst einmal nichts mit dem Umstieg auf Leopard zu tun hat, sondern bei der man evtl. von vornherein schon Kompromisse eingehen muss - zum Beispiel aus Kostengründen. Ansonsten gelten die eingangs erwähnten Dinge natürlich auch für Treiber. Es wäre dabei zu erwähnen, dass Apple bereits vorab Versionen von Leopard zur Verfügung gestellt hat, mit der man schon erste Tests fahren konnte um zu sehen, ob die eigenen Treiber und Produkte auch funktionieren. Dies sollte dann natürlich auch gemacht werden. Wenn man wartet, bis die offizielle Version in den Läden steht, wird das natürlich etwas hektisch.

Den Anwendern ist aber andererseits auch nahezulegen, sich zunächst einmal zu erkundigen, ob man überhaupt schon Treiber-Unterstützung für ein neu veröffentlichtes Betriebssystem erwarten kann, bevor man es installiert. Wenn man immer das Neueste auf seinem System haben will dann wird man selten ein wirklich lauffähiges System hinbekommen. Problematisch wird dies natürlich dann, wenn man einen neuen Mac kauft, der nur mit der aktuellen Betriebssystemversion ausgeliefert wird. Dann kann man nur hoffen, daß man Produkte von Firmen benutzt, die auch schnell Aktualisierungen zur Verfügung stellen.

Generell ist dies aber auch ein ziemlich Mac-spezifisches Problem - PC User sind normalerweise misstrauischer und installieren nicht sofort jedes neue Systemupdate und erwarten meistens auch nicht, daß das dann direkt und ohne Unterbrechung funktioniert.

Wie sieht die Zusammenarbeit mit Apple aus? Bekommt man als Entwickler ausreichend Hilfe aus Cupertino, oder hast du den Eindruck, dass man von Apple hängen gelassen wird? Wie ist überhaupt die Prozedur, wenn man als Entwickler Fragen hat?

Ich selbst empfinde die Zusammenarbeit als gut. Im Gegensatz zu anderen Firmen am Markt hört man von Apple selten die typischen Support-Antworten "das Problem ist uns nicht bekannt" oder "Du bist der Einzige". Es gibt beispielsweise in Leopard 10.5 und 10.5.1 einen Bug, der dazu führt, dass beim direkten Lesen von MP3 Dateien das Apple MP3 Codec abstürzt. Ich hatte auf meine Anfrage hin innerhalb von 2 Tagen eine sehr nette Email von zwei Apple-Entwicklern (direkt aus dem CoreAudio Team) in meiner Mailbox die besagte - "hey, wir kennen das Problem und werden im nächsten Update eine Lösung bieten".

Oft wird hier auch angeführt, dass der Entwicklersupport von Apple Geld kostet und man sich das in der MI-Branche nicht leisten kann oder will. Das ist auch nicht ganz richtig - natürlich gibt es ein Support-Level, das Geld kostet, schließlich setzt sich dann dort ein Entwickler an das Problem und kümmert sich darum. Apple stellt aber auch kostenlose Mailing-Listen zur Verfügung, auf welchen auch direkt Hilfestellung von den Entwicklern geleistet wird. Das ist nicht so schnell wie der bezahlte Support, aber dennoch bisweilen sehr nützlich, wenn man mal nicht mehr weiterkommt. Obendrein gibt es auch noch den Bugreporter, über welchen man vermeintliche Fehler in den Applikationen oder dem Betriebssystem direkt an Apple melden kann - auch als Endkunde.

Wird bei der Programmierung von Software viel improvisiert, oder achten alle darauf, die Programmierichtlinien von Apple einzuhalten?

Das kann Apple sicher besser beurteilen als ich, ich sehe aber zwei potentielle Probleme - die Bequemlichkeit der Entwickler und die teilweise stark verbesserungsfähige Dokumentation von Apple, zumindest was die Audio-Seite des Betriebssystems angeht. Ersteres ist leicht erklärt - ich muss allerdings gleich dazu sagen, dass Bequemlichkeit bei Software-Entwicklern eigentlich eine positive Eigenschaft ist. Nur wer grundsätzlich bequem ist (und zwar bequem und nicht faul!), findet auch einfache Lösungen für komplexe Fragestellungen. Allerdings führt das dann auch dazu, dass man lieber "denkt" anstelle die Dokumentation zu lesen, weil das manchmal eben erst einmal der bequemere Weg ist. Jeder, der mal wegen einer Frage in ein Handbuch schauen musste weiß das. Oft verbringt man mehr Zeit mit dem Versuch, es selbst herauszufinden, anstelle 5 Minuten Zeit in das Lesen des Handbuches zu investieren. Dann kommt eine Lösung dabei heraus, die zwar für den Moment funktioniert, aber beim nächsten Update des OS nicht mehr, weil zum Beispiel (wie in Leopard) die Funktionen etwas störrischer auf falsche Argumente reagieren.

Andererseits ist die Apple Dokumentation stellenweise auch so dürftig, dass man manche Dinge einfach selber herausfinden muss. Es gibt zum Beispiel eine sehr nützliche Klasse, genannt CAClock, mit der man im eigenen Programm Dinge wie MIDI Time Code und SMPTE Synchronisation realisieren kann. Also durchaus etwas, das man in unserer Praxis braucht. Leider gibt es in der Apple Dokumentation nicht ein einziges Beispiel dafür, und auch aus der Dokumentation selbst ist nicht zu erkennen, wie man diese Funktionen in einem eigenen Programm richtig einsetzt. Erst auf Anfrage bei Apple bekamen wir dann nach längerem Hin und Her ein Beispiel-Projekt, das uns weiter brachte. Hier besteht natürlich deutlicher Nachholbedarf.

Stichwort Ableton und Cocoa: Warum ist es wichtig, dass Plug-ins in Cocoa geschrieben werden?

Cocoa ist die Technologie, die mit Mac OS X bei Apple neu eingeführt wurde und die es ermöglicht, innerhalb kurzer Zeit und mit minimalem Aufwand elegante Benutzeroberflächen zu entwickeln. Sie wird im Mac OS X selbst und auch in den iApps von Apple verwendet und ist wirklich nützlich. Man kann mit 5 Zeilen Objective-C Code in Cocoa Dinge erreichen, wofür man ansonsten noch seitenweise C++ Carbon-Code schreiben mußte. Viele Programme, die ursprünglich unter Mac OS 9 entwickelt wurden benutzen aber heute noch die Carbon-Technologie, die auch unter Mac OS X noch weiterhin unterstützt wird. Allerdings ist vor allem hinsichtlich der 64bit Unterstützung schon abzusehen, dass das wohl nicht für immer so bleiben wird - insofern wird sich ein Umstieg auf Cocoa langfristig nicht vermeiden lassen.

Momentan ist eine Cocoa-Oberflächen Unterstützung bei AudioUnit PlugIns in Live, Digital Performer oder Kore2 (alle anderen unterstützen sie m.W. bereits) hauptsächlich für die Plug-in Entwickler wünschenswert, die Cocoa Plug-ins anbieten, und natürlich für Kunden, die diese ohne Einschränkung benutzen wollen. Da es noch nicht allzu viele Plug-in-Hersteller sind kann man sie als Sequenzer-Entwickler sicher noch für eine Weile ignorieren, bis sich die Kundenbeschwerden häufen und man gezwungen sein wird, etwas zu tun. Natürlich ist so eine Umstellung grundsätzlich unbequem, schließlich hat man viel Zeit in eine Klassenbibliothek investiert, die sowohl unter Windows als auch auf dem Mac funktionieren soll.

Letzten Endes ist man als Entwickler von Anwendungen aber doch immer dem ausgeliefert, was der Hersteller des Betriebssystems sich ausdenkt und tut auch gut daran, sich an seine Empfehlungen zu halten. Apple empfiehlt Cocoa für Benutzeroberflächen und zwingt einen auch dazu, bei 64bit Applikationen Cocoa zu benutzen. Ich rechne also damit, daß die oben genannten Hersteller auch früher oder später Unterstützung für Cocoa AudioUnit Plug-ins anbieten werden. Es gibt ja eine große Zahl alternativer Programme, die Cocoa AUs bereits unterstützen - und kein Plug-in-Entwickler wird mehr auf eine aussterbende Technologie setzen, wenn er heute neue Produkte entwickelt.

Danke für das Gespräch

Jörn Daberkow