Projektdatei-Austausch bei mehreren Cuttern

[NAB]

Hallo allesamt!
Ich wurde kürzlich gefragt, ob ich für ein Hörspielprojekt cutten möchte. Da es in diesem Fall für eine Person recht viel arbeit ist, habe ich mal vorgeschlagen den Aufwand zu teilen und nun kam die Frage auf, wie man das denn am besten organisiert.
Die Grundgedanken die ich mir dazu gemacht habe waren:

• Möglichst die gleiche Software nutzen (Reaper/Audacitiy denke ich)
• beide haben natürlich exakt die gleichen Takes exakt gleich benannt im exakt gleichen Unterordner lokal damit die Projektdateien drauf zugreifen können
• Einige technische Einigungen im Vorfeld (auf wieviel DB wird normalisiert, welcher Limiter wird benutzt, welcher Faltungshall etc.)

Unter den Bedingungen müsste es doch eigentlich möglich sein, die Projektdateien auszutauschen ohne immer die gesamten Ordner mit allen Abhängigkeiten rumzuschieben!? Mit Sicherheit gibt es hier Leute, die mit so etwas schon Erfahrungen gemacht haben und ich würde mich über eure Meinungen, Tipps, Does & Dont's usw. sehr freuen
Lg,
Nicolas

 

[Mr_Kubi]

Ich würde das Szene für Szene organisieren.
Also z.B. in Reaper jede Szene ist ein Projekt, und dann so abspeichern bzw. das so einstellen das das alle Audiodateien in den Projektordner kopiert werden.
Dann hast Du pro Szene einen Ordner mit allen Takes/Sounds und kannst anderen Cutter den Ordner senden und da ist dann für die Szene alles drin.

Wenn alle Szenen gecuttet sind, ausrendern und in einem neuen Projekt das Mastering über alle Szenen machen.

Soweit meine Meinung.

besten Gruß

 

[craze]

Wenn man auf das hin und herschicken des Ordners verzichten will würde sich die Verwaltung inklusive von Versionen anbieten.
Hier könnte man "git" (https://github.com) als gutes Beispiel nennen.
Wenn jemand fertig ist sendet er die aktuellsten Dateien an den github Server und das Gegenüber zieht sich die neueste Version.
Eine Einstiegshürde gibt es allerdings. Außerdem sollten in diesem Fall nicht zwei cutter gleichzeitig arbeiten, da es sonst zu Konflikten kommt.

github ist kostenlos und die "repositories" lassen sich als privat markieren.
Als Desktop-Applikation eignet sich "github desktop" (GitHub Desktop)

 

[Ellerbrok]

Oder die kompletten Projektdateien in einen geteilten GoogleDrive(*)-Ordner ablegen, so wie ich das schon oft gemacht hab

*) Oder anderen geeigneten Cloud-Service

 

[Heavy]

nter den Bedingungen müsste es doch eigentlich möglich sein, die Projektdateien auszutauschen ohne immer die gesamten Ordner mit allen Abhängigkeiten rumzuschieben!?

@Killip hat mir den Rohschnitt für ein hörspiel in AIFF gegeben. Da ist dann alles drin. Aber da könnte Kilip besser aufklären als ich Laie ^^

 

[Delay]

Einige technische Einigungen im Vorfeld (auf wieviel DB wird normalisiert, welcher Limiter wird benutzt, welcher Faltungshall etc.)

Ich finde es generell eine gute Idee aber auch irgendwo unnötig kompliziert. Welche Vorteile hat man dadurch das mehrere Leute an einem Kapitel arbeiten können? Wieso teilt man nicht einfach auf wer was macht und jeder in seiner Wohlfühl-DAW und fertig.
Schlussendlich sind die Mischmenschen sowieso schon rar gesät und von den ohnehin schon wenigen, noch welche zu finden die mit der gleichen DAW und Plugins arbeiten ist schwierig.
Viele arbeiten mit Reaper, der ein oder andere mit Sony Vegas, da jemand mit Audition und Cubase User gibt es auch noch. Ist echt schwierig. Dann lieber Kapitel unterteilen und jeder arbeitet für sich. Ein Cloud Ordner um alles zu sammeln ist aber eine gute Idee.

 

[Spirit328]

Also, beim Austausch von Daten ist immer ein Punkt ganz wichtig:
Wann ist was aktuell?

Manchmal "entwirft" man eine Szene, ist sich nicht ganz sicher und macht eine weitere. Doch dann ergibt sich während des Arbeitens eine weitere Idee.
Schon nach 20 Minuten haben wir 3 Versionen einer Szene. Gut, speichern wir also "Szene17Take1Version1" ab. Dann die zweite Version als "Szene17Take1Version2" usw.
Das wird dann irgendwann aufwendig und ich kenne nur eine Person, welche die Disziplin aufbringt eine derartige Versionierung von Hand zu machen. Und glaubt einem alten Mann, von diesen Menschen gibt es sehr, sehr, sehr, sehr wenige, die das konsequent und auch noch fehlerfrei (!) beherrschen.

Dann passiert ein kleines Missgeschick, während man an der Version 7 arbeitet, drückt man auf Ctrl-S und wollte doch eigentlich auf "Speichern unter" drücken, aber Oh shit. Version 6 wurde bereits überschrieben.
Nun, nach dem ersten Schreck denkt man sich, ach ich habe doch noch 5 andere. Also egal.

Doch wenig späte möchte der Regisseur die jetzt überschriebene Version haben und daran weiter arbeiten.

Das ist GENAU der Moment, wo Du Dir wünschen wirst eine sichere Versionierung benutzt zu haben.
Aber ... zu spät. Beim nächsten Mal aber bestimmt.


Gut, man kann sich einen Github-account besorgen und das für ümesonst. Aber erstens ist Github der Feind, weil im Besitz von M$ und es gibt das alles in mindestens besser für wenige Euronen.
Außerdem ist nie ganz klar, wann was mit den Daten auf Github passieren kann. ("patriot act")

Dann wäre da eine wirklich gute Alternativ:
GitLab. OpenSource, wirklich leicht zu installieren und sehr leistungsstark.
Zugegeben für Nicht-ITler ist der Einstieg alles andere als leicht, aber er ist es verdammt noch mal wert.

Endlich kann man IMMER und zu jeder Zeit zurück gehen zu jedem Zeitpunkt der Bearbeitung. So lange man immer darauf achtet alles zu sichern und entsprechend markiert. Aber das ist nicht wirklich schwierig.
Einen GitLab Server kann wirklich jeder aufsetzen, der Lesen und Schreiben kann. Hardware Anforderungen .... Nun: Viel Plattenplatz. CPU, RAM ... alles was ein PC bis zu einem Alter von ca. 10 Jahren auch noch kann.
Netzwerk Anschluß sollte mindestens vorhanden sein, aber das war schon damals Standard. Ansonsten hat Ihh-Bäh noch tausende Erweiterungskarten im Angebot.

Dann das Ganze kräftig umrühren und fäddisch.

Wer sich viel und häufig mit anderen Kollgen/innen austauschen möchte|soll|muss, der kann sich auch beim Hoster seines Vertrauens einen kleinen Server mieten, GitLab drauf zimmern und loslegen.
So gibt es z.B.: bei www.hetzner.de/sb viele Server, die für solche Zwecke ideal sind. Natürlich auch bei vielen anderen Hostern. Aber ich habe bisher "nur" mit diesen Servern Erfahrungen und kann nur darüber etwas aussagen.
Der für mich entscheidende Vorteil ist, daß man keine (!) Setup Gebühr bezahlt und man zum Monatsende jederzeit kündigen kann, sprich man geht keine langwierigen Verbindungen ein.
Ein gut ausgestatteter Server kostet rund 25 Euronen im Monat. Und wenn das Projekt fertig ist und alle Daten gesichert wurden, dann kann man den Server sofort (!) löschen und er kostet keinen Cent mehr.

Überschlagen wir mal die Kosten: Ein PC nimmt sich 200 W Leistung (Durchschnitt), mal 24 Stunden sind es schon rund 5 kWh. Also rund 1 Euro Stromkosten pro Tag. 30 Tage mal 1 Euro, also rund 30 € pro Monat für einen ollen PC. Dann rappelt das Ding noch mitten in der Nacht ... neeeeeee.
Also gleich in richtig.

Gut ausgestattet ist ein Server dann, wenn er MINDESTENS zwei Festplatten hat. Besser mehr, aber das wird Budget-technisch immer schwieriger und eher für diejenigen interessant, die damit Geld verdienen. (Die können solche Server-Kosten bestimmt steuerlich geltend machen. Fragen Sie Ihren Steuerberater oder Finanzamt-Mitarbeiterin oder -Mitarbeiter)

• Traffic: unlimited (sehr wichtig, denn wir hantieren schon mal mit größeren Datenmengen)

Informationen

• 2x RAM 8192 MB DDR3 = 16 GB RAM (mehr als genug)
• 2x HDD SATA 3,0 TB (Zwei Festplatten gespiegelt, also gleicher Inhalt auf jeder Platte, ist das mindeste)

Supportleistungen

• Ersatz defekter Hardware (kostet nichts, hatte ich schon zwei Mal)
• kostenloser E-Mail-Support (nun, braucht man nicht und wenn tut es das ganz gut, für die "Profis", sollte es dann schon der "amtliche" Support sein )

Preis

• 25,34 € monatlich inkl. Mehrwertsteuer.
• Keine Setupgebühr.

Für ein paar Euronen mehr gibt es auch mehr:

• Traffic: unlimited

Informationen

• 4x RAM 8192 MB DDR3 ECC
• 4x HDD SATA 2,0 TB Enterprise
• NIC 1 Gbit - Intel 82574L
• RAID Controller 4-Port SATA PCI-E - LSI MegaRAID SAS 9260-4i

Supportleistungen

• Ersatz defekter Hardware
• kostenloser E-Mail-Support

Preis

• 35,09 € monatlich inkl. Mehrwertsteuer.
• Keine Setupgebühr.

32 GB RAM lassen noch genügend Platz für Folding@home als Container in podman (oder ganz kurz: GENÜGEND) und mit 4 Platten kann man ein sog. "RAID 5" aufbauen. Das ist ziemlich sicher gegen Ausfälle von HW gesichert. (Je nachdem wie paranoid man ist.)

Als Regel für den Aufwand, den man treiben möchte sollte folgende Überlegung gelten:
"Wie viel Aufwand bedeutet es die Aufnahmen wieder herzustellen, wenn sie nicht mehr verfügbar wären?"

Als Beispiel eine kleines Hörspiel:
3 w, 2m, 2 Kinder Stimmen, eine Erzähler/Erzählerin und eine weitere Stimme aus dem Off.
Jede Stimme hatte mindestens 3 Takes pro Szene für die Stimme, ... überschlagen wir mal 5 Stunden pro Stimme alles noch einmal neu einzusprechen, bei den Kinderstimmen noch einen kleinen Zuschlag. Rund 47 Stunden, um alles noch einmal aufzunehmen. Von der großen Freude bei allen Beteiligten, das aktuelle Projekt zu unterbrechen und etwas nochmal aufzunehmen, das eigentlich schon durch war.

Nun die Gegenrechnung:
Einen Server zu bestellen dauert 15 Minuten, gaaaaanz großzügig gerechnet.
Dann GitLab einspielen ... sind wir mal großzügig ... noch mal 30 Minuten. Benutzer anlegen und Login Daten verschicken .. noch mal 15 Minuten.
Also, nach rund einer Stunde habt Ihr einen sicheren Server, der für alle Beteiligten JEDERZEIT und von überall erreichbar ist, der nichts "vergisst", wo man nur mit entsprechenden Rechten etwas löschen kann und jeder sich die Aufnahmen der anderen anhören und verwenden kann, um seine Takes noch besser zu machen....
Okay. Ihr seid überzeugt.

Wäre da nicht dieses Monster "GitLab" genannt. Die Lernkurve ist hoch und irgendwie hat da außer ein paar Nerds noch nie jemand mit zu tun gehabt....

Okay, okay. Überredet. Ich werde mir in den nächsten Wochen die Zeit nehmen und einen weitestgehend automatisierten Skript mit Ansible (für die Nerds ) erstellen und einen Beitrag, wie man das "Drumherum" in den Griff bekommt. Dann noch ein Tutorial für GitLab Dummies und schon geht kein Take mehr verloren.

Wäre das von Interesse für Euch?

Übrigens @Jeln Pueskas wäre ich für Deine Unterstützung sehr dankbar im Erklären von GitLab für Einsteiger. Wenn es Deine knappe Zeit erlaubt.
Auf dem IHW 2020 habe ich ein paar Sprecherinnen/Sprecher gesprochen, die mit USB Sticks, externen Festplatten oder mit schlichtem Gott-Vertrauen (oder jede beliebige Kombination daraus) experimentieren. Da wird mir schwummerig.

Klar könntet Ihr alles auf eine virtuelle Festplatte bei einem public cloud Anbieter hochladen. Doch in aller Regel gibt es dort keine "Versions-Verwaltung". Sprich es kann Euch jederzeit (!) passieren, daß Ihr irgendetwas überschreibt und es erst merkt, wenn es viel zu spät ist.

Hiermit die Bitte um Feedback. Gerne an mich.

 

[Jeln Pueskas]

Ich kann da gerne unterstützen. Allerdings habe ich Gitlab auf einem Linux-Host (CentOs7) beim Anbieter Contabo aufgesetzt. Man muss sich ein bisschen mit dem Betriebssystem und der Console auseinander setzen. Das sind im wesentlichen Grundgriffe. Der Rest ist Download und abarbeiten der Installationsanweisung.

Zwei Knackpunkte hat das Ganze aber noch.
1. Solltet ihr einen Server, den ihr im Internet gehostet habt auch absichern. Dazu benötigt ihr ein Zertifikat, mit dem ihr eine sichere Verbindung ala https aufbauen könnt. Ich habe dfür Geld ausgegeben, da ich meinen Server in erster Linie kommerziell nutze. Das muss man aber nicht zwangsläufig OpenSSL tut da auch das Nötige.

2. Bei Hörspielprojekten nehme ich auch die Audiodateien in das Repository mit. Da die Größe damit massiv ansteigt, ist Gitlab nicht mehr mit http nutzbar. Die Übertragung bricht einfach ab. Man sollte sich also einen SSH-Schlüssel generieren Dies ist recht einfach über die gitbash möglich, die man sich allerdings lokal auf dem Rechner installieren muss. Es werden dabei ein privater und ein öffentlicher Key erstellt. Der private verbleibt in einem festen Ordner auf dem eigenen Rechner. Der öffentliche muss ins Gitlab geladen werden. Diesen Schritt müssen alle Beteiligten eines Projektes durchführen.

Wer immer noch Interesse hat, sich das Ganze aus der Nähe anzusehen und sich damit zu beschäftigen, kann mich gerne kontaktieren.

 

[FaderFummler]

und irgendwie hat da außer ein paar Nerds noch nie jemand mit zu tun gehabt....

:flushed: Schuldig :sweatsmile::tearsofjoy:

Falls die Audiodateien nicht mit ins Repository sollen würde ich noch einen Uberspace ins Rennen werfen. (da momentan "nur" max. 10GB, soll aber bald erweiterbar werden. Dafür ein sehr interessantes Preismodell und ein großartiger Support.) Da gibt es auch gleich eine Anleitung, wie man Gitea aufsetzen kann. Let's Encrypt Zertifikate werden automatisch generiert. Ich bin da schon ein paar Jahre Kunde und äußerst zufrieden. Hab Gitea selbst so eingerichtet, aber synchronisiere damit eigentlich eher txt, Python-Gedöns und LaTeX Dateien, für die ich gern eine Versionsgeschichte hätte.
Für das bisschen Push/Pull ist es ja egal, ob nun GitLab oder etwas anderes auf dem Server läuft.

Falls ihr da eine Anleitung schreiben wollt, würde mich vor allem der Part für die Endnutzer-Umsetzung interessieren. Für OSX gibt es z.B. SourceTree (und viele andere, aber das nutze ich) als Frontend für git, was das leidige Konsolengefrickel vereinfacht und Branches und Dateivergleiche vor dem Commit visuell angenehmer darstellt. Für Windows gibt es bestimmt auch etwas entsprechendes...
Ich denke die git-Bedienung und einheitliche Richtlinien (z.B. jeder soll einen eigenen Branch nutzen, Namenskonventionen, ...) sollten da eher im Vordergrund stehen, da wahrscheinlich mehr Leute als Nutzer teilnehmen und nur einige wenige einen Server aufsetzen werden. Und falls man das allein nutzt, braucht es ja im Zweifelsfall nicht mal einen Server, sondern nur das lokale Repository, was man im Rechner-Backup ja (hoffentlich) automatisch mit drin hat.
Und wenn man sie damit geködert hat, kann man sie viel leichter mit "Und wie toll wäre es erst, wenn du das jetzt zwischen deinen Geräten und mit anderen Leuten synchronisieren könntest!" auf die GUI-freie Seite des Internets locken! :smilingimp:


@Jeln Pueskas Spricht eigentlich etwas dagegen, für Shorties (wo ja jeder mit den Daten spielen darf) einen offiziellen hoer-talk.de GitHub Account zu erstellen und (falls die Beteiligten zustimmen) für jeden Shorty ein Repository mit allen Sprechern und Scripten zu erstellen? Als ich durch ein paar Shorty-Threads durch bin, um mir "Übungsmaterial" zu holen, waren da sehr oft nur noch tote Dropbox, GoogleDrive etc. Links, was ja eigentlich recht schade ist.
Auf die Schnelle konnte ich bei GitHub nur ein "per File limit" von 100mb finden, was durch aufsplitten ja kein Problem darstellt.

 

[Gelöschtes Mitglied 5339]

waren da sehr oft nur noch tote Dropbox, GoogleDrive etc. Links, was ja eigentlich recht schade ist.

Wenn dir das passiert, kannst du jederzeit die damaligen Sprecher/innen anschreiben. Viele haben die Dateien noch "irgendwo rumliegen". Oder du suchst dir Leute zur Unterstützung, die die Rollen nochmal einsprechen. Wie sinnvoll GitHub hier ist , weiß ich nicht, weil ich mich damit nicht auskenne.

Liebe Grüße von
Peter

 

[Spirit328]

Hmmmm, wenn ich @Dennis Künstner auf dem IHW richtig verstanden habe, sieht es mit "noch einem zusätzlichen Server" sehr mau aus. Was nicht zuletzt mit der nicht allzu üppigen Spendenfreudigkeit der Mitglieder korreliert.
Also sollten wir uns da mal ein paar grundsätzliche Gedanken machen. Doch das ist nicht Gegenstand dieses Threads.Vielleicht finden wir (also die Hoer-talk-Community) eine Lösung, mit der sich nicht nur das Shorty Problem lösen ließe. Ich hätte da ein paar Ideen, aber das sollten wir mal in einer größeren Runde diskutieren.

Ich denke schon ein paar Wochen darüber nach mir einen GitLab-Server im Internet zuzulegen.
Da ich bei einer Software-Firma arbeitete, die sich auf "Enterprise-Software" versteht, würde ich mal mit den Kollegen aus der Security Abteilung einen Chat halten, wie man denn einen solchen Server absichert, also richtig absichert und dennoch den legitimen Benutzern Zugriff gewährt.
Port-Knocking und SPA sind da die Themen, die mir neben den üblichen Dingen, wie Zertifikaten u.s.w. einfallen. Mal sehen, was die Kollegen noch an Tricks auf Lager haben.

... und ja, Ansible funktioniert auf allen Systemen, die Python ausführen können, also sogar auf Macs und Windoof Büchsen. Aber es gibt auch richtige Betriebssysteme. Doch zurück zum Thema.

Nach meiner Meinung ist es wesentlich für den Erfolg eines derartigen Ansatzes, daß es auch für "Nicht-Nerds" einfach U N D zuverlässig zu bedienen ist. Und da liegt der Hase in der Schoko-Sauce. Source-Tree ist schon okay, aber für "Nicht-Nerds" ein Problem.

Vielleicht ist da ein WebDAV Laufwerk mit eingeschalteter Versionierung eine Alternative?

Oder eine wöchentliche Schulung auf "hoer-talk", wie man Source-Tree und GitLab richtig nutzt? Oder eine kleine Online-Schulung, die man asynchron ausführen kann, um es zu lernen?

Vielleicht sollten wir es wie die Rot-Hüte machen und einfach mal anfangen? Nicht alles schon vorab durchdenken, sondern "nur" Katastrophen weniger schlimm machen und sehen was die Benutzer wirklich brauchen?

Your thoughts?

 

[Delay]

So toll und innovativ das ganze auch klingt und ich weiß wie es ist total begeistert einer Sache zu sein... aber ich habe auch schon die Erfahrung gemacht das es nicht unbedingt ausreicht wenn man nur alleine davon überzeugt ist, sondern die Gruppe oder Gemeinschaft selbst muss den Wert und Sinn dahinter erkennen und damit auch die Bereitschaft damit zu arbeiten.
Ich erinnere mich noch gut daran wie jemand aus einer Gruppe damals mit einer Art Peer2Peer Verteilersystem (auch Open-Source) ankam und das jeder auf seinem Rechner installieren sollte und die Daten untereinander dann jederzeit synchronisiert wurden. Das ist bei mir (war damals noch nicht so affin mit Technik) und anderen auf nicht so viel Gegenliebe gestoßen und wurde dann zeitig wieder eingestampft und wir hatten zu der Zeit schon ein FTP Server im Einsatz. Ziel des ganzen war es das Änderungen sofort übertragen werden. Damit konnte aber immer noch nicht zeitgleich an einer Datei gearbeitet werden.

Ich für meinen Teil denke das die Einführung von GitHub oder GitLab die Allgemeine Situation was Hörspiele produzieren angeht zusätzlich verkompliziert. Jeder kennt DropBox oder GoogleDrive und damit funktioniert es. Nicht umsonst gibt es den Ausspruch: Never change a running system.

Das ist meine Meinung zum Thema.

 

[Spirit328]

Genau das ist ein sehr wichtiger Punkt: Die Akzeptanz der Benutzer. Da stimme ich Dir zu!
Nur scheint mir das Argument "Das hat bisher funktioniert" ein wenig zu kurz gegriffen. Wäre das ein allgemein akzeptierten Ansatz gäbe es weder das Internet noch die sog. Smartphones. Steve Jobs hatte nicht nur Fans, als er das Ei-Phone vorstellte!!!

Ich sehe das vom Standpunkt der technischen Weiterentwicklung.
Niemand muss dabei mitmachen, sondern sie/er KANN dabei mitmachen.
Wem also FTP (wenn schon dann bitte SFTP!!!) genügt und damit weiter arbeiten möchte ... PRIMA! Wenn es für Dich/Euch funktioniert, wäre es Unfug das zu ändern.
Doch wenn jemand mit weiterentwickelten Methoden arbeiten möchte, dann ist sie/er herzlich willkommen.

Deswegen sei mir nicht böse,wenn ich in guter alter "Metocracy-Manier" mit denen zusammenarbeiten werde, die meine Ansichten teilen. Du bist und bleibst jederzeit willkommen, solltest Du Deine Meinung ändern. Das gehört auch dazu.

 

[Jeln Pueskas]

Also ich kann mal ein bisschen aus der Erfahrung mit Lindenblatt plaudern:

Bislang bin ich der einzige, der das Repo pflegt, die Zugänge einrichtet, in Gitlab die Berechtigungen einstellt und ggf. beim Einrichten des Repos unterstützt. Leider kam es bislang nicht zu einer breiten Benutzung, was auch damit zu tun hat, dass alle weiteren Beteiligten auf technischer Ebene nicht damit in Berührung kamen. So bin ich bislang auch der Einzige, der bei Fehlern im Repo unterstützt und das wieder gerade zieht. Leider hatte sich nicht so viel Akzeptanz ergeben, wie gehofft. Aber es wurde zumindest ausprobiert. Ich habe da weniger Berührungsängste, da es mein tägliches Brot ist. Zudem kannte ich git und gitlab auch schon im Vorfeld.

Vielleicht macht es Sinn, wenn man ein Projekt neben "Die Katze" vom hoerspielprojekt zusätzlich anlegt und sich die Macher mit der Technologie auseinandersetzen und sieht, ob das was für einen ist. Generell ist das Versionieren und Sichern der Projektdateien eine Sache, die grundsätzlich gemacht werden sollte. Wie oft ist mal eine Platte kaputtgegangen und dann war es das. Wie gesagt, ist nur ein Vorschlag. Wer Interesse hat, einfach melden...

Im Übrigen arbeitet Spirit328 auf dem gitlab für "Die Katze"

 

[Spirit328]

Kennt Ihr die tiefe Verzweiflung wenn Ihr feststellt , daß an dem alten ITIer Wissen viel Wahres ist:
"Keiner will Backups aber allen wollen Restore,"
Meine Eltern haben mal auf andere Menschen gehört und über 4.000 DM hir die Wiederherstellung von Daten bezahlt, die man für einen Bruchteil der Kosten hätte " backupen" können?

Ein GitLab Repository ist dagegen ein Zustand, der dem Paradis schon recht nahe kommt.
Und wenn man bisher damitt noch nicht gearbeitet hat, dann wollte man es mal versuchen zu lernen. Das haben schon sooo viele Menschen vor Euch getan und verstanden, das ich die Prognose wage : Das könnt Ihr auch !
Außerdem bleibt Ihr Herr (bzw. Herrin) Eurer Daten!

Und ja! ich arbeite mit GitLab und nach einer kurzen Eingewirkungsphase macht es sogar SpaBI

 

[benkuly]

Ich sehe irgendwie nicht den Sinn git zu verwenden, um Binärdateien, also Ton- und Projektdaten zu versionieren. Git ist für Quellcode, also Text geschaffen und nicht wirklich geeignet, um effizient Binärdateien zu versionieren. Außerdem ist es für Nicht-Entwickler nicht wirklich zu verstehen, sobald der erste Merge-Konflikt entsteht. Und mergen von Binärdaten geht eh nicht, also sind viele Vorteile von git eh futsch.

Warum nicht sowas wie Nextcloud mit eingeschalteter Versionsverwaltung (Versionsverwaltung — Nextcloud 15 Benutzerhandbuch 15 documentation). Das ist dann vom Workflow nicht anders als mit den Cloudspeichern der großen IT-Firmen, die hier ja eh schon verwendet werden in Projekten. Einfach Nextcloud-Software auf dem PC installieren und der Ordner wird ständig mit Nextcloud synchronisiert.

 

[Delay]

Dazu fällt mir im übrigen ein: Was soll den versioniert werden?
Die Aufnahmen, einmal im Kasten, sollten sich außer es stehen Retakes an, nicht mehr ändern.
Eine ordentliche DAW bietet es von sich aus an das „Versioniert“ werden kann.

Eine ordentliche DAW arbeitet auch Non-Destruktiv, das einzige was sich als im Laufe des Projektes ändern sollte sind neben Musik und Soundeffekten eigentlich nur noch die Positionen der Audiofiles und die Einstellungen der einzelnen Plugins, oder übersehe ich hier etwas entscheidendes?
Ob man die Versionierung innerhalb der DAW nutzt steht natürlich auf dem anderen Blatt (lässt sich aber bestimmt auch einstellen das automatisch nach Zeit X eine neue Version abgelegt wird... wie sinnvoll das ist muss jeder für sich entscheiden). Macht man dann noch einigermaßen regelmäßig Sicherheitsbackups, geht eigentlich auch nichts verloren. Ich habe so gut wie alle Projekten bei denen ich seit 2015 mitgewirkt habe abgespeichert, das sind allein 1 TB an Projektdaten.

 

[pierre_horn]

Ich habe das Gefühl, die Diskussion ist ein wenig - wie soll ich es ausdrücken - aus dem Ruder gelaufen.

Der Austausch der Daten war ja nur ein Punkt von dreien (Versionierung war da noch nicht mal drin).

Zu Punkt 1: Wenn beide Cutter an der selben Szene basteln wollen, müssen Wohl oder Übel mit der selben DAW arbeiten. Das macht das finden eines weiteren Cutters etwas schwerer. Ich denke aber, es wird im Verlauf des Projektes hilfreich sein, wenn beide Cutter eine Szene bearbeiten können. Allerdings würde ich @Mr_Kubi zustimmen, mich szenenweise zu organisieren.

Zu Punkt 2: Hier könnte allein schon Dropbox ausreichen (sogar Versionswiederherstellungen sind möglich).

Zu Punkt 3: Das Feslegen auf einen gemeinsamen Standard macht das Abmischen des Gesamtwerkes hinterher einfacher.

 

[FaderFummler]

Und mergen von Binärdaten geht eh nicht, also sind viele Vorteile von git eh futsch.

Das Reaper-Format ist XML. Ich habe eben aus Spaß mal zwei Branches erstellt, in jedem eine Audio-Spur in einer gut gefüllten Vorlage hinzugefügt und dann einen Merge-Versuch unternommen. Hat geklappt, es kam eine Datei mit beiden Spuren heraus. Allerdings gab es auch Konflikte, die ich aber einfach ignorieren konnte (war von der SWS Extension, die die Tracks automatisch einfärbt). Ich würde vermuten, dass man bei größeren Änderungen entweder was zerstört oder so viel Zeit für Konflikte Investiert, dass man es auch gleich per Hand einfügen könnte.
Für mich wäre das auch eher ein zusätzliches Backup und eine Hilfe, bei verschiedenen Varianten nicht den Überblick zu verlieren.

 

[Spirit328]

... hmmm, war nur so eine Idee von mir. Wenn Ihr alle ohne Versionierung klar kommt ... mir soll's recht sein.

Ich erachte eine Versionierung via Git auch für Binär-Dateien, wie auch die schnell veränderlichen Schnitt- und sonstigen Informationen, als sehr wesentlich für meine Arbeit.
Wenn das auf wenig Resonanz stößt, dann auch gut. Zumindest für mich.

Ich würde mich dennoch sehr dafür interssieren, wie das die "Kollegen" hier machen.