VST3-Plug-ins nun endlich auch für Linux
Steinberg VST SDK 3.6.7
Linux und Audioproduktion war bisher nur etwas für ganz Hartgesottene. Doch das Open-Source Betriebssystem gewinnt langsam an Fahrt. Es gibt ja auch schon gute DAWs für diese Plattform, wie z.B. Harrison MixBus, ReNoise, Bitwig und Tracktion/Waveform oder LMMS, doch woran es bisher wirklich mangelte, waren gute Audiotreiber und hilfreiche Plug-ins.
Das Problem, dass es bisher fast nur Audiotreiber von ehrenamtlichen Drittanbietern für eine sehr kleine Anzahl von Audiointerfaces gibt, wird sich wohl nicht so schnell auflösen.
Bei den Plug-ins gab es bisher Ansätze mit LADSPA und LV2 (LADSPA V.2) oder über wackelige Brücken einige Windows-VSTs.
Zumindest das Problem mit den Steinberg VST wird sich wohl in naher Zukunft auflösen. Denn mit Version 3.6.7 des neuen Software-Entwicklungskits für VST3-Plug-ins bringt Steinberg eine umfassende Software-Unterstützung für Windows, macOS, iOS und auch für Linux.
Einer der wichtigsten Faktoren bei der Öffnung zu Linux war dabei bisher nicht technisch verhindert, sondern wie leider zu oft rechtlich. Denn die VST-Schnittstelle ist immer das geistige Eigentum von Steinberg im Gegensatz zu Linux, das unter der GPL Lizenz vertrieben wird.
GPL heißt General Public License und bedeutet soviel, dass der Endnutzer eine Software studieren (dekompilieren), verändern und vervielfätigen darf, meisten mit dem Zusatz „unter den gleichen Bedingungen‟, also z.B. kostenlos erhaltene Software darf nicht weiterverkauft werden.
Mit dem SDK 3.6.7 fügt Steinberg der Proprietären Lizenz nun eine GPL 3.0 Standardlizenz hinzu. Damit ist die rechtliche Grundlage zur Entwicklung von VST3-Plug-ins gegeben.
VST ist ja quasi der Gewinner der Plug-in-Formate. Selbst AudioUnits auf macOS sind inzwischen meistens nichts anderes als verkleidete VSTs. Der entsprechende Format-Wrapper ist im VST-SDK schon eingebaut. Native AUs auf macOS sind ehr selten geworden. Selbst auf iOS halten VSTs als AUv3s „getarnt“ Einzug.
Wer sich jetzt allerdings schon die Hände reibt und sich auf all die „großen‟ Plug-ins für sein Linuxchen freut, muss sich aber dennoch auf eine Enttäuschungen gefasst machen. Das größte Problemn das VST3 auf Linux haben wird, wird die rechtliche Lage der Plug-ins sein, hauptsächlich Kopierschutzmechanismen und die Rechte der Endnutzer unter GPL und auch solange Pace iLok nicht auf den Zug aufspringt, werden viele namhaften Hersteller Linux weiterhin meiden.
Es ist also eher als eine Chance für all die Klein- und Heimentwickler zu sehen. Auf jeden Fall aber ein Schritt in die richtige Richtung, der vielleicht genügend Wellen schlägt.
Da wurden vom Autor ein paar Dinge zusammen geworfen, die so nicht ganz stimmen.
1. Die duale Lizenz von Steinberg bedeutet das sowohl Closed-Source-Projekte (VST License) als auch Open-Source-Projekte (mit GPL License) dieses SDK nutzen können. Das hat aber keinen Einfluss, ob es sich dabei um kommerzielle oder nicht-kommerzielle Projekte handelt. Kommerzielle Geschäftsmodelle können auch mit der GPL verwirklicht werden, siehe z.B. Ardour als DAW. Die GPL verbietet nicht das Verkaufen von Software, es muss allerdings immer auch der Source-Code veröffentlicht werden.
@hztirf 2. Ad „Einer der wichtigsten Faktoren bei der Öffnung zu Linux war dabei bisher nicht technisch verhindert, sondern wie leider zu oft rechtlich. Denn die VST-Schnittstelle ist immer das geistige Eigentum von Steinberg im Gegensatz zu Linux, das unter der GPL Lizenz vertrieben wird.“: Das stimmt auch so nicht ganz. VST ist (war?) eine proprietäre Entwicklung von Steinberg und somit die Unterstützung und Akzeptanz der Open-Source-Gemeinde immer gespalten, aber nicht unmöglich.
3. Ad „Das größte Problemn das VST3 auf Linux haben wird, wird die rechtliche Lage der Plug-ins sein, hauptsächlich Kopierschutzmechanismen und die Rechte der Endnutzer unter GPL und auch solange Pace iLok nicht auf den Zug aufspringt, werden viele namhaften Hersteller Linux weiterhin meiden.“: Die GPL bringt hier keine Probleme. Als Endanwender kann ich jederzeit auch nicht GPL-konforme, Closed-Source-Applikationen nutzen. Wo der Autor allerdings Recht behält, ist der Punkt, wie es sich mit Kopierschutzmechanismen verhalten wird und ob auch diese Lösungen mittelfristig auf Linux portiert werden.
@hztirf Last, but not least, ad „Das Problem, dass es bisher fast nur Audiotreiber von ehrenamtlichen Drittanbietern für eine sehr kleine Anzahl von Audiointerfaces gibt, wird sich wohl nicht so schnell auflösen.“:
Sofern die Interfaces USB-Class-Compliant sind, laufen sie meist komplett reibungslos auch unter Linux. Hier braucht es genau wie unter macOS/iOS keinen eigenständigen Treiber für den Betrieb. D.h., wo iOS draufsteht, funktioniert es mit sehr hoher Wahrscheinlichkeit genauso gut mit einem aktuellen Linux.
Das mit Linux wird erst loslegen, wenn die großen Pluginanbieter ihre Plugins auch für Linux anbieten.
Bei manchen VSTs wird der Port schnell gehen, aber ob sich zum Beispiel NI die Mühe machen wird, Komplete zu portieren?
@Tobias Schmidt Das ist ja schon längst geschehen.
Man erinnere sich and Komplete 5 für Receptor
von Museresearch.
Das Betriebssystem läuft ja unter Linux…..was nicht heißt das diese Produkte zu empfehlen wären.
So wie sich das bei Receptor liest, läuft das über eine Windows-Simulation (vermutlich WINE).
Im Idealfall kann man damit beliebige Windows-Anwendungen unter Linux ausführen. Da hat NI also vermutlich keinen Finger für gekrümmt.
@Tobias Schmidt Hallo Tobias,
beliebige mit Wine kompatible Anwendungen ist richtig. Die Muse Receptor Kisten stellen Kompatibilität auch nur über einen Hardware Plug-in Player sicher. Was ein customized WINE ist. Muse schreibt ja selber in der FAQ ob VST Windows Plugins out of the box laufen, it depends. Damit die Plugins laufen, müssen bestimmte Bedingungen erfüllt sein. Immerhin läuft hier ein Linux unattended. Demzufolge benötigt das VST „keine“ GUI, aber alle Elemente müssen per MIDI und/oder Console erreichbar sein. Sobald aber in dem VST auf eine Befehlsbibliothek verwiesen wird, die nicht WINE kompatibel oder nicht referenziert ist, funktioniert das natürlich nicht. Da die die NI Produkte teilweise direkt auf der Muse laufen, wird NI hier keine Sonderlocken programmiert haben. Wobei ich persönlich einen Reaktor auf der Muse als sinnfrei empfinde(^^).
Danke für die Klärung :-)