Dedizierter Launcher für Ultraschall

Ultraschall
1

Wie komme ich darauf?

Wie ich im Vorstellungsthread geschrieben habe, habe ich ursprünglich GarageBand zum Podcasten verwendet. Das tat soweit, aber irgendwann fehlen einfach die Features (MIDI, Automation, Routing etc.). Daher kommen mir REAPER und Ultraschall gerade recht, weil ich dann nicht nur eine großartige Podcast-DAW, sondern auch gleich eine allgemein großartige DAW auf einmal habe. Ich muss also weder zwei DAWs kaufen, noch mich in zwei DAWs auskennen.

Momentan kann ich damit aber nicht viel anfangen: Ultraschall ersetzt meine anderen Themes, fügt eigene Extensions hinzu etc. Das ist natürlich notwendig, damit Ultraschall läuft, aber es macht leider meine “REAPER auch für andere Recording- und Schnitttasks nutzen”-Pläne zunichte. Da ist Ultraschall eher im Weg, weil sich diese Tasks nicht im Podcaster-Workflow abbilden lassen.

Worum geht’s?

Deshalb hier meine Feature-Idee: Ein Launcher (also praktisch Ultraschall.app), der ein komplett eigenes REAPER-Profil verwendet und somit komplett separat verwendbar ist.

Wie implementieren?

Jetzt ist natürlich die große Frage, wie man das umsetzt.
Dafür habe ich spontan zwei Ideen:

  1. Der “So-sollte-es-eigentlich-sein”-Plan

    Angenommen, man könnte Man kann REAPER beim Start eine Kommandozeilenoption mitgeben, die ihm sagt, welchen Ordner er verwenden soll (also praktisch ~/Library/Application Support/Ultraschall statt ~/Library/Application Support/REAPER.
    Edit: Diese Kommandozeilenoption heißt -cfgfile, was aber momentan nicht ganz mit Ultraschall (oder überhaupt) funktioniert. Sollte jemand eine andere Option kennen, die genau das macht, was wir hier wollen, immer her damit!

    Der Launcher würde dann REAPER mit genau dieser Option starten und sich selbst beenden. Done.

    Der Installationsprozess würde sich dabei radikal vereinfachen: Einfach den Profilordner mit allem drin (alle Extensions, Theme-Dateien etc.) nach ~/Library/Application Support/Ultraschall werfen, einen Launcher nach /Applications/Ultraschall.app schreiben und die Kernel-Extension Ultraschall-Hub und das Soundboard installieren. That’s about it. Man müsste weder entscheiden, welche Extensions man überhaupt haben will (da das ja dann alles im Profil gekapselt ist und man die eigentlich gar nicht mehr abwählen können will), noch müsste man das ConfigZip auf REAPER ziehen. Das wäre ja alles schon im Profil drin.

  2. Die “Holzhammer-Hauptsache-es-geht”-Methode

    Da ich nicht weiß, ob es diese Option tatsächlich gibt, hier noch die Alternative, die auf jeden Fall klappt, aber nicht genauso schön ist.

    Gleiches Prinzip: Der Installer erstellt ~/Library/Application Support/Ultraschall, allerdings macht er außerdem folgendes: Er benennt den vorhandenen REAPER-Ordner in REAPER.plain um und erstellt einen Symlink von REAPER nach REAPER.plain. REAPER stört das (so weit ich es getestet habe) nicht. Der Launcher würde dann beim Start den Symlink auf Ultraschall umbiegen und REAPER starten. Nachdem REAPER beendet wird, würde er den Symlink wieder zurückbiegen, damit man dann wieder REAPER normal nutzen kann.

    Funktioniert, ist aber nicht effizient und man weiß nicht so recht, ob ganz REAPER das verträgt und mit diesem Symlink wirklich problemlos umgehen kann.

Tatsächliche Implementierung

Siehe den ersten Entwurf von mir.

Vorteile

  • Man hätte dann Ultraschall.app. Wie cool ist das denn?
  • Der Launcher könnte nebenbei auch nach Updates suchen und eventuell direkt anbieten, sie beim Programmstart zu installieren. Ist ja dann alles automatisch, da das Profil komplett Ultraschall gehört und kein manuelles Setup mehr nötig ist.
  • Ultraschall wäre (bis auf die Kernel-Extension und das Soundboard, das ja auch in anderen Anwendungen genutzt werden kann) komplett gekapselt und man müsste sich nicht mehr fragen, wo denn überhaupt überall was hininstalliert wird.
  • Wie oben erwähnt: Der Installer wäre um einiges simpler. Es gäbe nur noch “Ultraschall-Profil für REAPER”, “Ultraschall-Launcher”, “Soundflower entfernen”, den Ultraschall-Hub und das VST-Plugin vom Soundboard. Die Interna (also bspw. SWS) wären dann komplett ausgeblendet, da die einfach dazugehören und den User nicht zu interessieren brauchen. Damit bleiben nur noch Komponenten übrig, deren Zweck man auf Anhieb verstehen kann und die auch einzeln jeweils Sinn ergeben (also die “Features” von Ultraschall).
  • Da Ultraschall das Profil komplett besitzt, kann man nach einem Update auch wirklich sicher sein, dass nicht irgendeine manuelle Einstellung mit der neuen Ultraschall-Version kollidiert. Natürlich würden die dann im Gegenzug komplett verloren gehen, aber das will man ja im Zweifel auch. Lieber “alles weg” als “nur manches weg und man weiß nicht was”. :wink:
  • Und, zu guter Letzt, das Argument, das mich auf die Idee brachte: Man kann REAPER auch vanilla nutzen, ohne Ultraschall aktiviert zu haben.

Eventuelle Schwierigkeiten

Momentan werden die ganzen REAPER-Extensions und -Plugins ja in die globale Library (also /Library) geworfen. Ich weiß jetzt nicht, wieso ihr das so macht. Wenn das nur so ist, damit ihr nichts im User-Profil von REAPER kaputt macht, wäre das alles kein Problem (dann könnte man das spätestens jetzt so machen). Sollte es einen speziellen Grund dafür geben, ginge die ganze Idee mit dem Launcher natürlich nicht.
Edit: Siehe Erklärung von Heiko, somit wäre das kein Problem mehr.

So, langer Text und hoffentlich genug Info, damit ihr versteht, worum es bei der Sache überhaupt geht. Ich hoffe, ich habe euch mit der Idee auch angesteckt. :wink:

2 „Gefällt mir“
2

Das kann ich schonmal ohne weiteres beantworten: Die Ultraschall-Komponenten könnte man ohne Probleme in der User-Verzeichnis installieren. Mit Ausnahme der Kernel Extension. Und da der OSX-Installer nicht ins System- und in des User-Verzeichnis installieren kann, ist halt alles im System-Verzeichnis gelandet.

1 „Gefällt mir“
3

Klar, der Ultraschall-Hub (und wahrscheinlich auch das VST-Plugin) sind da natürlich Ausnahmen. Die sollen und dürfen aber auch außerhalb davon sein, da die ja erst einmal gar nichts mit REAPER zu tun haben.

Die Alternative hier wäre also, dass der durch den Installer nach /Applications installierte Launcher beim ersten Start das Ultraschall-Profil in die User-Library installieren würde, wenn es noch nicht vorhanden ist. Das wäre sehr robust und würde sich so verhalten, wie das andere Apps auch machen.

In dem Fall könnte man den Launcher sogar auch komplett separat vom Installer anbieten (also als “nach Applications ziehen”-App). Dann könnte man Ultraschall an sich auch so verwenden, wenn man das Soundboard und den Ultraschall-Hub nicht braucht (bspw. wenn man da sowieso andere Lösungen hat).

4

Du willst also auf einen Profil-Manager für REAPER raus, oder? Das würde in der Tat einige Probleme im Installer lösen.

5

Na ja, nee. Das ist meiner Meinung nach Overkill. Ein einfacher Launcher mit genau einem Profil für Ultraschall reicht da völlig. Ultraschall muss ja nicht alle Probleme lösen, es ist ja ein Podcasting-Tool, kein DAW-Management-Tool. #singleResponsibilityPrinciple

6

Den Code, der die Profile verwaltet, muss man doch sowieso schreiben.

7

Ja, das stimmt schon. Dann sollte der Profil-Manager aber wiederum nicht in den Launcher eingebaut, sondern eine weitere Anwendung sein, sonst wirft man am Ende alles unnötig zusammen (meine Meinung).

Der Code, der dafür nötig ist, sind irgendwie 5 Zeilen Shell-Script oder entsprechend ähnlich viel in Objective-C. Den kann man auch erst einmal nur für Ultraschall verwenden, sonst muss man den UI-Code zum Profil-Auswählen auch gleich schreiben. Der wäre dann der größte Anteil am Profil-Manager.

Mir ist noch was zum Update-Prozess eingefallen: Eventuell sollte man die Project Templates außerhalb vom Profil speichern und dann mit einem Symlink reinlinken (also vom Profil aus referenzieren). Dann bleiben die auch bei Updates erhalten. Ähnliches gilt auch für einzelne weitere Einstellungen, sollte das möglich sein.

8

Sicher? Na, dann zeig mal. :wink:

9

Um mal den Raum für Spekulationen etwas einzugrenzen: Wir planen im Zusammenhang mit dem neuen Ultraschall-Hub eine Applikation zum Verwalten des neuen Core Audio-Drivers. Es ist also nicht so, dass wir von Grund auf eine neue App schreiben müssten.

10

Aber gerne doch. Hier jeweils für meine beiden Implementierungsideen:

Der “So-sollte-es-eigentlich-sein”-Plan

open /Applications/REAPER64.app --args -cfgfile ~/Library/Application\ Support/Ultraschall/reaper.ini

Funktioniert momentan nicht ganz, vermutlich liegt das an den absoluten Pfaden in der reaper.ini, die nur auf Ralfs Mac Sinn geben. Mit “rohen” REAPER-Profilen mit jeweils verschiedenen Einstellungen klappt das aber.

Aber: #eineZeileCode

Die “Holzhammer-Hauptsache-es-geht”-Methode

ln -s ~/Library/Application\ Support/Ultraschall ~/Library/Application\ Support/REAPER
open /Applications/REAPER64.app -W
ln -s ~/Library/Application\ Support/REAPER.plain ~/Library/Application\ Support/REAPER

Und hier sind es auch sogar nur 3 Zeilen Code. Dafür funktioniert es super (bis jetzt keine Probleme feststellen können).

11

Na ja, aber diese Anwendung/PrefPane ist dann ja für den Ultraschall-Hub. Ich denke nicht, dass es Sinn gibt, dieses Feature da einzubauen.

12

Cool! Wie machst du das mit dem Lizenzfile?

13

Dann halt nicht mehr.

Und ich denke nicht, dass wir für jeden Use Case eine eigene App bauen sollten. Das treibt ja den Aufwand für den Installer wieder in die Höhe.

2 „Gefällt mir“
14

Hm, das ist eine gute Frage. Ich habe selbst noch keine Lizenz gekauft, deshalb weiß ich jetzt nicht, wie REAPER das genau handhabt. Ist es möglich, die Lizenzdatei wiederum systemweit in /Library zu hinterlegen? Ansonsten müsste man sie halt in beide Profile installieren.

1 „Gefällt mir“
15

Da sind wir dann unterschiedlicher Meinung. Aber das müssen wir ja jetzt nicht entscheiden.

Das ist schon richtig, aber sollte der Ultraschall-Hub wirklich zum „neuen“ Soundflower werden und es komplett ersetzen, werden auch andere Audiomenschen, die nicht mit Ultraschall arbeiten, den Ultraschall-Hub installieren wollen. Für die sind sämtliche weitere Funktionen dann völlig unsinnig.

1 „Gefällt mir“
16

Als Software-Hersteller würde ich sagen: Nein.

17

Ich hab’ das mal gegoogled: http://forum.cockos.com/showthread.php?t=153068
Dort geht es eigentlich um was völlig anderes, aber nebenbei wird erwähnt, dass die Lizenzdatei auch dort erkannt wird. Das müsste man wohl einfach mal ausprobieren.

1 „Gefällt mir“
18

Das zu bewerten, steht mir nicht zu. Aber: Ziel des Ultraschall-Projekts ist es, Podcastern die Arbeit zu erleichtern. Deshalb finde ich, dass wir mit einer zentralen App besser beraten sind.

Vielleicht an dieser Stelle zwei grundsätzliche Überlegungen:

  1. Ich trenne bewusst ‚ich‘ und ‚wir‘ und ich kann mir vorstellen, dass es Team-Mitgleider gibt, die die Dinge anders sehen als ich.

  2. Deine Idee gefällt mir sehr gut und ich finde, dass wir sie in der einen oder anderen Form umsetzen sollten. Und mit ‚wir‘ meine ich auch dich. Und natürlich alle anderen.

  3. Allerdings erreicht die Ultraschall-Software - wie jede andere nicht-triviale Software auch - mit der Zeit eine Komplexität, die es erfordert, dass man sich neue Features und Änderungen sehr gut überlegt. Nicht jede Idee muss sich als Ultraschall-Feature manifestieren. Wenn das mal der Fall ist, hat ja jeder die Möglichkeit selbst Anpassungen zu machen.

2 „Gefällt mir“
19

Das es technisch geht, heißt nicht, dass es rechtlich OK ist.

1 „Gefällt mir“
20

Ich hab’ mal in die Lizenz geschaut:

1.5  Subject to the terms and conditions of this Agreement, you are granted a limited non-exclusive license to use the Software on one (1) computer any given time.

Demnach ist das auch rechtlich in Ordnung. Im Endeffekt geht es ja darum, dass man die Lizenz nicht mit anderen Leuten teilt, aber auf einem System kann das ja auch nur einer gleichzeitig verwenden. Die Lizenz erlaubt damit sogar, die Lizenzdatei auf mehreren Rechnern zu installieren, solange man sie nur auf einem gleichzeitig nutzt.

Ich bin jetzt kein Jurist, aber so verstehe ich das persönlich und meiner Meinung nach ist das auf jeden Fall so interpretiert, wie es gedacht war.