Jeln Pueskas

Michael Gerdes
Teammitglied
Sprechprobe
Link
Hallo miteinander,

aus der Informatik kommend hat man ja oft mit dem heißen Scheiß zu tun. Ein schon etwas älterer dafür aber nicht weniger interessanter Ansatz ist es, seine Arbeit über ein Versionierungstool zu speichern. Von diesen gibt einige im Netz. Die bekanntesten sind subversion und git. Letzteres kann über eine Web IDE namens gitlab auch genutzt werden, um Daten an einem fernen Server zu speichern, zu versionieren, Inhalte zusammen zu führen (mergen) und diese einem Team zur Verfügung zu stellen. Nun mal meine Fragen an Euch:

  • Hat schon mal jemand in der Runde gitLab oder ähnliches auf einem Webspace eingesetzt, um seine Audodateien zu versionieren und mit anderen zu teilen.
  • Nutzt jemand Webhosts, die eine Grundlage liefern, um solche Tools dort zu installieren und genügend Platz für einen akzeptablen Preis anbieten. Zum Beispiel für eine linuxbasierten Host unbegrenzt Speicherplatz mit Datenbank, git, Webservices etc für unter 10€ den Monat anbietet
  • Wer hat generell Interesse an einem solchen Thema?

Viele Grüße, Michael
 

benkuly

<nobody></nobody>
Sprechprobe
Link
Ich hätte dazu mal eine Frage: Wieso sollte man Audio-Dateien versionieren? Oder meinst du eher Audio-Projekte á la Cubase, Samplitude, etc.
Git ist wohlbemerkt nicht wirklich für große Binärdateien geeignet.
 
Zuletzt bearbeitet:

Ellerbrok

Sprecher, Cutter & Fledermaus
Teammitglied
Sprechprobe
Link
Git ist wohlbemerkt nicht wirklich für große Binärdateien geeignet.
Dem kann ich nur zustimmen. Die gängigen Versionierungstools, hier bei uns in der Firma nutzen wir Mercurial, sind klassischerweise für Programmierer und deren Quellcode-Dateien in (ASCII-)Textform gedacht. Viele der Mechanismen funktionieren nur für Textdateien. Zum Beispiel nur die Änderungen (Delta) speichern und nicht jedes Mal die komplette Datei. Bei Audiodateien (=Binär) würde jedes mal eine neue Kopie der kompletten Datei in der Versionskontrolle abgelegt und der Speicherbedarf somit explodieren.
 

SeGreeeen

Kaaaaarakaluuuuuuuhhhh!!!!
Teammitglied
Du könntest aber die Projektdateien versionieren, da die meist ein xml file o.ä. sind. Man macht es ja auch in der Softwareentwicklung so, dass Binärdateien nicht auf das repo gepusht werden, sondern nur der code inkl. (zumindest in Java) maven oder gradle projekt.

Wenn du alleine daran arbeitest, könntest du die audiodateien in einer (privaten) cloud speichern und die Projektdateien in git versionieren. Dann kannst du auf jeden gerät auf alles zugreifen... Zumindest in der theorie. Wie das in der Praxis aussähe weiß ich nicht... Vermutlich einfach das gesamte projekt im cloud folder machen und hoffen, dass die DAW relative und nicht absolute pfade verwendet...

ps: wenn es absolute pfade sind müsste man ein shellscript schreiben, das für pushen und pullen verantwortlich ist und nach dem pullen die pfade anpassen und vor dem pushen wieder zurückändert... o.ä... klingt nach einigem aufwand. da wäre es evtl. besser einfach nur auf einer Maschine daran zu arbeiten und nur die Projektdateien zu versionieren...
 
Zuletzt bearbeitet:

Jeln Pueskas

Michael Gerdes
Teammitglied
Sprechprobe
Link
Hiho

Das Ganze geht in folgende Richtungen:

Zum einen natürlich ja, die Projektdateien ließen sich mergen und natürlich auch abrufen. Mir geht es aber über das Mergen hinaus. Git bietet beispielsweise das Plugfin LFS für das Verwalten übergroßér Dateien. Damit rückt auch das Mergen in den Hintergrund.
Das Versionieren ist dann von Belang, wenn man im Team arbeitet, dabei aber verschiedene DWAs benutzt. In der Regel werden dann die Szenen als einzelne Wave-Datei pro Spur ausgetauscht. Ebenso kann man auch ganze Szenen dort ablegen und sie dem Mastering-Team oder Musikern bereitlegen. Sollte es es dann eine Änderung geben, kann über die feste Struktur die Datei nachgeladen werden (per git eben).

Der noch wichtigere Aspekt ist, dass alle Teammitglieder auf die gleiche Verzeichnisstruktur zuweisen. Das bedeutet auch, dass wenn einer diese Struktur ändert, alle anderen diese ebenfalls mit der Aktualisierung bekommen. Das bietet den Vorteil, dass man ohne suchen zu müssen, alles an seinem Platz findet. Im Vergleich dazu bietet weder dropbox, noch Google Drive oder sogar dieses Forum ein solches Feature an. Gerade im Bereich der teamgebundenen Projekte würde ich wirklich überlegen, ob man über so eine Möglichkeit nicht ernsthaft nachdenken sollte. Natürlich mit dem Hintergrund, dass man hier eben keine Software baut, keine Build-Pipeline daran hängt und keine Deployments automatisch generiert. Aber es ist mit Sicherheit ein wesentlich effektiverer Weg, sein Projekt zu verwalten und zu steuern, als wenn jeder auf seiner Platte nach eigenen Gutdünken mit einem Shared Link verteilt.

Weitere Vorteile sehe ich hier:
  • Es wird nur das hochgeladen oder heruntergeladen, was sich geändert hat.
  • Man kann auch bei Totalverlust des Rechners innerhalb kürzerster Zeit seinen letzten Stand auf einem anderen Rechner wiederherstellen
  • Ein Team, wie beispielsweise SHU oder Zukunftschroniken kann somit auch zusätzlich ihre Skripte verwalten und versionieren, den aktuellen Produktionsstand einsehen
  • Jede Änderung ist protokolliert und kann wiederhergestellt werden.
Noch als Ergänzung zum Host Server: Ich bin davon ausgegangen, dass ein Webhost vermutlich reichen würde. Da hat mich Dennis eines besseren belehrt und von einem Root-Server gesprochen, der in erster Linie virtuell aufgesetzt wird. Damit hat man auch alle Rechte, um alles zu installieren, was man braucht. Ein Beispiel wäre webtropia die Root-Server zu einem relativ günstigen Preis und inkusive der Möglichkeit alles nachzukonfigurieren.
 

Jeln Pueskas

Michael Gerdes
Teammitglied
Sprechprobe
Link
Hallo miteinander,

Hast du das noch weiter verfolgt?
@Jeln Pueskas

ja habe ich. Das komplette Projekt vom Hexer Episode 2 mit Ausnahme des Bouncen für das Mastering wurde in einem eigenen Git-Repository versioniert. Auch das Projekt "Die Katze" liegt im git und kann vom Cutter dort abgegriffen werden. Bei Lindenblatt haben wir entschieden, das auszuweiten und die Geräusche, wie auch die Musikproduktion in ein extra Repo abzulegen. Somit haben alle Projektbeteiligten den Zugriff auf alle Geräusche, müssen aber nicht zwangsläufig alles sehen, was andere in ihrem Repo so treiben.

Es hat sich gezeigt, dass die Ladezeiten natürlich recht lang sind und das ein Repo auch nur über eine SSH-Einrichtung noch funktioniert (Das HTTP bricht nach einer gewissen Zeit den Ladevorgang ab). Allerdings hatten wir beim Austausch so gut wie keine Probleme. Wenn diese allerdings auftraten, benöntigt man einen git-Fachkundigen, der per git bash das Repo wieder gerade schüttelt. Zum Einsatz kam als Client-Software Source Tree von Atlassian, dass kostenlos heruntergeladen werden kann. Man muss allerdings auch ein Atlassian-Konto erstellen, damit die Software überghaupt gestartet werden kann.

Viele Grüße, Michael
 

Searge

Space-Opera ist ein musss!
Sprechprobe
Link
Das macht aber wirklich auch nur Sinn wenn man mit mehreren Leuten an einem großen Projekt arbeitet, oder? Ansonsten habe ich das "Gefühl" für "kleine" Sachen wäre es überdimensioniert.

Gruß »Searge«
 
Oben