Update DaVinci Resolve 14.2.1 - hauptsächlich Bugfixing

[slashCAM]

Das aktuelle Update enthält viele Stabilitätsverbesserungen und Bugfixes. Einzelheiten? Bitteschön:

Addressed an issue where playing frame-based clips in the Media page would not play the synced audio
Addressed an issue where Resolve would sometimes not output audio on certain pages in macOS
Addressed an issue where audio formats for stereo, 5.1 and 7.1 were not set correctly when rendering WAV files
Addressed an issue where rendered adaptive tracks were incorrectly tagged as stereo, 5.1 or 7.1 formats
Addressed an issue where changing clip audio properties in the Inspector would not work correctly when multiple clips were selected
Addressed an issue where deleting a volume keyframe and performing an undo would not restore the smoothening applied
Addressed an issue where the source meters would sometimes not reflect the correct number of channels for clips with audio
Addressed an issue where the Fairlight viewers would show a still image during playback when monitoring with a Blackmagic Design capture and playback device
Addressed an issue where render jobs could not be added for audio only timelines
Addressed an issue where rendered media files would sometimes have blank audio on the first video frame
Addressed an issue with marking render ranges when rendering an audio-only timeline on the Delivery page
Addressed a crash when adding a marker to a clip with cross-fades
Addressed an issue where moving an audio clip on the Fairlight page would sometimes result in a crash
Addressed an issue where the metadata widget would remain blank when clips were selected on the Fairlight page
Addressed an issue where audio FX applied on clips inside a nested timeline would sometimes not get saved
Addressed an issue where deleting an audio clip in a layered track and performing an undo would restore it in an incorrect layer
Addressed an issue where resetting audio properties in the Inspector would not fully reset the clip equalizer
Clips dragged on to the timeline no longer update the position of the playhead
Addressed an issue where viewers would become blank when Video Scopes were enabled in Edit page
Addressed a crash when decomposing compound clips from certain timelines imported using XML or AAF
Addressed an issue where reimporting EDLs exported from Resolve would cause a crash
Addressed an issue where performing an undo on a take selector action would sometimes result in a failure to save the project
Clip names stored in EDL comments are also available as a render tag
Power Windows with tracking now also have an indicator on the viewer overlay to show when they are in frame mode
Addressed an issue where reconforming to a clip at a different source resolution would result in misaligned power windows in some cases
Addressed support for DCDM ACES Output Transform with gamut clipped to P3 per SMPTE spec
Addressed an issue where stills grabbed on a project migrated from Resolve 12.5 project would not be saved
Addressed an issue where loading gallery stills would sometimes take a long time
Addressed an issue where some stills would show a black frame when wiping
Addressed an issue where node cache would sometimes incorrectly be invalidated when rippling color parameters
Addressed an issue where the Dolby Vision CMU would be in pass-through mode until the trim metadata was modified
Addressed an issue where qualifier controls remained editable when disabled
Addressed an issue where Intel graphics hardware would not be recognized as OpenCL compatible with the latest drivers on Windows
Addressed an issue where the Generate Optimized Media progress dialog would sometimes disappear before the operation completed
Addressed an issue where performing a Save As after a failure to save a project would sometimes result in the original project disappearing
Addressed an issue where selecting multiple titles in certain timelines would result in a crash
Addressed an issue where deleting timelines in some projects would result in a crash
Addressed an issue where Blackmagic Design Capture and Playback devices would not be detected on older drivers on Windows
Addressed a crash when enabling 4:4:4 SDI monitoring with certain Blackmagic Design capture and playback devices
Addressed an issue where viewers would become blank when enabling Data Burn Ins and monitoring with a Blackmagic Design capture and playback device
Addressed an issue with network connectivity on the JLCooper Eclipse panel
Addressed an issue where changing the source folder or relinking clips in the Media Pool would not affect the associated matte clips unless they were explicitly selected
Addressed a crash when rendering to Cineform at certain resolutions such as 2K DCI Flat
Addressed a crash when decoding some H.264 clips
Addressed an issue where colorspace metadata was exported incorrectly when rendering MXF clips
Addressed an issue with default brightness levels when decoding RAW formats from some still cameras
Addressed a crash with decoding some high resolution XAVC clips on certain system configurations
Addressed inability to render multiple mono audio tracks to the MXF OpAtom container
Improved encoding speeds when rendering to Apple QuickTime ProRes
Improved decoding speeds with XAVC-I media
Addressed performance degradation when using CUDA compatible OpenFX plugins
Addressed an issue where Edit page playback response would be delayed during thumbnail generation
Addressed an issue with viewer performance on multicam clips on certain system configurations
General performance and stability improvements



Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Update DaVinci Resolve 14.2.1 - hauptsächlich Bugfixing

[Peppermintpost]

wir haben in der Firma gerade von 12 auf 14 upgedated und mal das colaberative processing mit nem Davinci Server ans laufen gebracht und es ist geeeeiiiiiilllll. Also alle die die Notwendigkeit sehen mit mehreren Personen an einem Projekt rum zu fukkeln kann ich das nur ans Herz legen, funktioniert super!

[CameraRick]

Also alle die die Notwendigkeit sehen mit mehreren Personen an einem Projekt rum zu fukkeln kann ich das nur ans Herz legen, funktioniert super!

Das ist wirklich eins der einzigen Features, die mich so richtig an der 14 interessieren. Weitere AAFs/EDLs/XMLs einladen können, während schon gearbeitet wird.
Gut zu hören, dass es bei euch gut funktioniert... vielleicht kriege ich uns auch mal dahin, sobald es mehr positives Feedback der Coloristen gibt :)

Hast Du auch Erfahrung mit der Funktion, wo man eine bestehende Timeline anhand einer neuen AAF/EDL/XML modifizieren kann, sodass alles übernommen wird etc? Das klang auch sehr vielversprechend.

[Peppermintpost]

Hey Rick,

genau aus dem Grund (Conform während des Gradings ) haben wir es eingerichtet.
Du kannst die Timeline editiren während jemand anders Graded, das geht. Die Freigaben gehen so, jeder kann immer lesen, aber der der zuerst irgend etwas öffnet hat schreibrechte. Das gilt für Bins, Timelines und Clips. Aber was super cool ist, wenn du eine Timeline öffnest und dann ins grading gehst, dann gibst du die Timeline wieder frei und hast nur noch Schreibrechte auf den angewählten Clip im Grading, und zwar nur auf den einen Clip. Wenn jetzt ein zweiter während du im Grading bist in der Timeline herum macht, dann bleibt dein Grading dennoch auf jedem Clip erhalten. Wenn du die Clips dann natürlich in der Timeline verlängerst und der Colorist hatte auf dem Clip ein Tracking, dann geht das natürlich nur bis dahin wo der Clip vorher war, die geänderte Überlange muste dann noch anpassen. Das war aber ja auch schon so wenn du ein Grading von einer Timeline auf eine zweite angewendet hast.

Raus rendern kannst du dann natürlich mit jedem Rechner einzeln weil das die Setups ja nur liest. Also wenn du ein ProRes und ein H264 haben willst oder so.

Was das Grading selbst angeht, wird wohl nicht so oft vorkommen aber dennoch ist die Funktion cool, du kannst auch mit 2 oder mehr Leuten an einem Film rum graden weil wie gesagt im Grading nur ein einzelner Clip gesperrt ist.

Ich hoffe das hilft dir weiter

[CameraRick]

Auf jeden Fall, Danke für die Ausführung! Das klingt wirklich toll.
Wir würden in jedem Fall immer vorher eine Kopie der Timeline machen bevor wir was ändern, aber dennoch ist das sehr angenehm.

Aber gehen die Timeline-Änderungen dann nur manuell?

[Peppermintpost]

Aber gehen die Timeline-Änderungen dann nur manuell?

Da ist mir nicht 100% klar was du meinst. Wenn du die Timeline aufmachst, dann kann ich sie mir nur noch ansehen, bzw ich kann dann ins Grading und daran rum wiggeln.
Wenn du jetzt irgend was in der Timeline änderst bekomme ich das in Grading nicht mit, solage bis ich zurück zu editing Tab schalte und dann sehe ich ein kleines Update Zeichen in der Ecke vom Viewer, wenn ich darauf drücke sehe ich die Änderungen die du gemacht hast.
Während ich im Grading bin kannst du im Editing machen was du willst, du hast volle Zugriffsrechte.
Während du im Editing bist ist auch der Bin geschützt in dem du bist.

Was die Timelines angeht machen wir jetzt 3 Ordner. Timeline_Grading, Timeline_Conform, Timeline_Import, damit jeder seinen eigenen Bin hat und man einen "austausch" Bin hat. Also ich importiere mir meine aaf und fang mit den Conform an, ist das geschehen ziehe ich ihn in Timeline_Conform, weil darin ja keiner arbeitet. Ist der Colorist jetzt mit seiner Timeline durch nimmt er sich eine neue aus dem Conform Bin.

Würde natürlich auch mit 2 Bins gehen weil der Colorist ja sowieso 99% der Zeit im Grading ist, aber wenn man genau im gleichen Moment einen Bin blockiert und man hat Kunden hinter sich sitzen dann nerft es hat, deswegen einfach 3 Bins und gut ist.

[CameraRick]

Mit manuell meinte ich die Änderungen :)
Kennst ja selbst - Film ist abgenommen, ab ins Grading. Jetzt gefällt Schnitt doch nicht, Grading und Colorist sind aber schon gebucht, und während des Gradings wird eben noch weiter geschnitten.

Nun wurde für die 14 das Feature angekündigt, dass eine Timeline auch "aktualisieren" kann. Sprich keine neue Timeline, sondern die alte wird anhand einer neuen Schnittliste aktualisiert. Eben Auto-Conform statt manuellem Eingriff anhand der neuen AAF. Spart einem das Colour-Tracing (was ja auch gerne mal Probleme macht).

Hab mich wohl blöd ausgedrückt - jetzt klarer?

[Peppermintpost]

ah verstehe was du meinst. Ne das hab ich noch nicht ausprobiert. Da würde ich mich freuen wenn du Feedback geben kannst wie das funktioniert.
Wenn wir diesen unsäglichen Fall haben und du kannst dir vorstellen das wir mit Händen und Füssen versuchen das zu vermeiden, dann sind wir bis jetzt halt den weg des Colour-Tracings gegangen (mehr oder weniger erfolgreich).

Die Sache ist die wir haben 2 Arten von Projekten, die einen sind Projekte die ganz normal mit irgend einer anständigen Kamera gedreht worden sind (meistens Alexa, manchmal Red), da ist die ganze Angelegenheit in der Regel null Problemo, wenn man mal von 1 bis 2 Frames shift absieht die wir dann händisch gerade rücken, ich hoffe das Problem ist inzwischen Vergangenheit.
Das sind auch genau die Kunden die gerne den Schnitt noch ändern während man schon die Sendekopien raus rechnet.

Dann haben wir eine zweite Art von Projekten, und evtl hast du da einen Tip wie man damit am besten umgeht, da ist ein grosser Teil des Footage von diversen Stock Anbietern. Einige von denen halten ihre Timecodes in Ordnung, andere haben aber unterschiedliche Timecodes in den Preview Files und den FullRes Files und genau da wird es dann natürlich zur mega Katastrophe weil dann ein automatisiertes conform schon nicht im ansatz funktioniert. Das ist natürlich kein Resolve Problem, aber halt ein Problem das man lösen muss wenn man vor dem Resolve sitzt. Einnen besseren Weg als die Stills zu speichern und neu drauf zu kopieren hab ich da noch nicht gefunden, natürlich mit dem ganzen daraus resultierendem Krampf die Masken alle neu zu machen etc.
Falls du da eine Idee hast, auch wenn es weitere Software mit einbezieht wäre ich sehr glücklich.

Aber sag auch mal wie du mit der neuen Funktionalität der unterschiedlichen aafs mit gleichem CC zurande kommst. Wenn ich damit Erfahrungen habe schreib ich auch gerne nochmal was dazu.

[CameraRick]

Hier in der Firma kann ich das nicht testen, weil wir noch nicht auf die 14 gehen, wobei, ich hab sie zur Zeit ja drauf... Wie viele Computer brauche ich denn für ein Setup, reichen zwei oder brauche ich einen separaten Server? Würde das ganze Setup gerne mal daheim testen.
Für die Aktualisierung von Timelines brauche ich ja keinen zweiten Resolve :)
Diesen unsäglichen Fall haben wir halt oft, wird fast schon zum Trend. Letztes Jahr um diese Zeit haben wir sogar eine schon verschickte Sendekopie zurück ziehen müssen, inkl. neuem Grading und neuer Online (durchs Grading konnte vieles nicht ganz so übernommen werden). Good times :)

Wie dem auch sei, diese Funktion hatten sie so beworben; Color-Tracing geht ja meist ganz gut, manchmal aber unerklärlich nicht. Da man Gradings nur so richtig übertragen kann (Stills speichern ja keine Trackings etc) wäre das eben schon der Knaller, sonst mussten wir immer die Clips manuell rüber holen und umschneiden.
Wir haben ja zum Glück idR nur kurze Sequenzen, aber muss dann ja auch immer alles schnell gehen... kennst die Kunden ja :)

Puh, das Szenario was Du da schilderst ist natürlich ein Alptraum :( Color-Tracing kann ja auch manuell betrieben werden, da sollte zumindest Grading (ohne Trackings) trotz TC-mismatch klappen. Dazu muss man dann das Fenster auf "Manual" (ganz oben) stellen, matchende Bilder auswählen und unten rechts "Paste" anklicken. Wenn man sich etwas konzentriert ist das zumindest viel schneller als Stills einzufügen :o
Ansonsten könnte man den TC auch anpassen; im besten Fall haben die Previews einfach keinen Timecode (also 00:00:00:00), im Resolve kannst das für die Source-Files in den Clip Attributes ändern. Natürlich geht jeder TC, nur wenn er bei 0 steht geht es eben schneller... :) Problem dabei: man kann es nicht im Batch machen, nur jeden Clip einzeln. Falls die AAF/XML/EDL dann dennoch nicht verknüpft kann man in den Conform Options noch ein wenig was probieren, oft ists nur ein falsches Setting dort was es blockiert.
Ansonsten, puh, da fällt mir jetzt ohne weiteres auch nichts ein. Auf den Praktikanten zu verweisen ist nun auch sehr elitär, huh? :)

[Peppermintpost]

... im Resolve kannst das für die Source-Files in den Clip Attributes ändern. Natürlich geht jeder TC, nur wenn er bei 0 steht geht es eben schneller... :)

ah, das schaue ich mir mal an, ist schon mal ein super tip, thx. In den meisten Fällen ist der TC bei uns um 1 Stunde verschoben, das lässt sich dann also recht schnell ändern. Das schaue ich mir auf jeden Fall an.

Was den Datenbank Server angeht, ne dazu must du nicht zwingend einen Server einrichten, den Job kann auch eine einzelne Workstation übernehmen, die muss dann natürlich auch immer laufen. Wir haben es halt auf dem Server als zusätzliche VM weil der sowieso immer durchläuft und weil die VM auf nem raid5 liegt und weil sie täglich ein Backup sieht.
Du must nur schauen das die SQL Datenbank so konfiguriert ist das von extern darauf zugegriffen werden kann, dann ist alles easy. Die ist ja als Standart 127.0.0.1 also local host only.

[CameraRick]

Ah, das läuft dann über den Postgre, verstehe.
Hier in der Firma wäre das auf dem Grading an sich kein Problem, da das ja auch der primäre Arbeitsplatz dafür ist. Wenn niemand graded kann ich da ja auch rein, wenn jemand graded mache ich das eben von meiner Workstation aus - das klappt schon.

... davon unabhängig ist es natürlich sexy, die Datenbank auf einem anderen Rechner laufen zu haben der regelmäßiger Backups zieht bzw ziehen kann. Bzw generell sie extern zu haben - ein weiteres Ärgernis ist ja oft ein Grading für morgen vorzubereiten, wenn die heute mit einem anderen Projekt bis 22h in der Suite sitzen. Dafür brauchts vermutlich eine weitere Lizenz; wir haben zwar zwei Dongle, aber ein dritter dafür wäre ja auch spott billig. Hm. Damit krieg ich die Entscheider sicher rum ... :)

[Peppermintpost]

wenn du es nicht simmultan brauchst kannste ja inzwischen auch einen Netzwerkordner anlegen (ohne Datenbank) und das geht dann auch mit der kostenlos Version.

Also Colorist arbeitet and Projekt A und du conformst Projekt B, am nächsten Tag arbeitet der Colorist an Projekt B und du an Projekt C. Das geht mit jeder Resolve 14 Version und der Ordner kann liegen wo er will solange er im Netzwerk freigegeben ist.

In dem Zusammenhang haben wir getestet wie es mit Farb shifts aussieht, weil wir den Effekt hatten das wenn wir ein Projekt exportieren und dann wieder importieren sich ein sehr leichter Farbshift eingestellt hat. Der Bug scheint raus zu sein, wir haben das auf allen möglichen Rechnern mit allen möglichen Grafikkarten getestet und die Farben waren jetzt alle gleich. Ich sag das nur weil das Netzwerkordner Setup ja genau diese Projekt Export Daten benutzt wie es scheint.

[CameraRick]

Hi Peppermint,

ah verstehe, das ist natürlich auch ganz gut. Aber wie gesagt, zwei Dongles haben wir (und zur Not hab ich einen privaten, den ich mitnehmen kann). Bislang haben wir es immer etwas "dirty" gemacht, das Material lag idR schon am Grading ab (wird vorher, im Zweifel über Nacht, kopiert), dann wird übers Netzwerk woanders conformed und am nächsten Tag früh morgens das exportierte Projekt eingeladen. Toll ist das natürlich nicht; so ein Server ist halt schon auf viele Weisen recht sexy, zumal wie eigentlich alles haben bis auf eine weitere Lizenz. Setzt man das in Kosten/Nutzen sind die 300€ aber bis zur Mittagspause schon wieder eingespielt.
Ich bin die Woche leider sehr eingebunden und am WE muss ich für einen Freund schufften, ab nächste Woche stürze ich mich da mal drauf! :)

Veränderungen beim Import hatten wir bisher nur Versionsübergreifend, sprich wenn Du zB was aus der 11 in der 12 öffnest; ging meistens mit dem Qualifier zusammmen, der ja einige Änderungen in der Anpassung des Keys mitbrachte. Und das ist wirklich eine Sauerei bei BMD, dass sich von Version zu Version so viel ändert und man mitunter keine alten Projekte gescheit einladen kann. Wäre nur halb so schlimm wenn man zwei Versionen parallel installieren könnte, aber das geht ja auch nicht - da könnten sie sich beim Fusion eine Scheibe abschneiden.
Ist gar nicht mal so selten dass ich noch einmal in ein 9er Projekt muss, sicher so ein- oder zweimal im Jahr

[Peppermintpost]

ja klar, das mit den Versionen finde ich auch kotzig, aber es ist halt der Datenbank geschuldet. Bis jetzt hat das null Sinn gemacht, aber jetzt mit dem Colaberative Workflow ist die Datenbank schon echt geil, wenn du dir die Möglichkeiten von Resolve mit z.B. Avids Netzwerk Colaborative Workflow vergleichst dann ist Resolve halt schon ein Quantensprung.
Also ich rede jetzt nicht über den Schnitt sondern nur wie das System mit Multi Usern umgeht.

Und klar 300€ für das Feature ist geschenkt, das sehe ich genau so.

[CameraRick]

Vom Avid kannte ich das gar nicht. Zugegeben, ich kann den Avid auch nicht bedienen, aber habe ihn gern im Haus. Läuft idR einfach besser. Wie ich das mitbekomme ist es beim Avid aber generell alles viel einfacher, weil man einfach einen Bin aus den Projektdateien irgendwo importiert und alles ist schon fertig (zumindest sieht das immer sehr einfach aus, was der Kollege hier so macht).
Die Datenbank ist halt eher so eine Altlast (weswegen ich es auch für den Schnitt immer etwas zu klobig finde), eine Datenbank pro Version sollte ja aber auch drin sein (mit der Option, alte zu importieren).

Bin ich mal gespannt wieder das alles klappt. Heute Abend ist ja ein Mocha Webinar, das wollte ich schauen um vielleicht mal Gründe zu finden auf den 5er zu updaten (sind noch auf der 3). Dann versuche ich nächste Woche mal die 14 zu pitchen... aiaiai, hoffentlich sehen sie das Geld da so gut investiert wie ich :D

[Peppermintpost]

wie gesagt ich wollte mich nicht auf den Avid im allgemeinen beziehen sondern tatsächlich nur auf den collaborative workflow. Wenn du beim Avid eine Timeline aufmachst, dann ist im Netzwerk halt der ganze Bin gelocked. Und egal was du in der Timeline anstellst bleibt das auch so.
Du kannst also nicht in der Timeline eine Farbkorrektur machen oder Effekte einstellen oder was auch immer und ein anderer macht in der gleichen Timeline was anderes. Das geht einfach nicht, weil einfach das ganze File so wie Timeline abgespeichert ist, also der Bin auf dem Server geblockt wird.
In einer Datenbank kannst du sozusagen (ist jetzt vermutlich der falsche Begriff) Objektorientiert arbeiten also verweist die Timeline nur auf die Objekte (Clips) die dann wieder gesondert (von jemand anderem) bearbeitet werden können.
Beim Avid geht das nicht.

Resolve schleppt da also keine Altlasten mit sich herum sondern die haben schon in der Vergangenheit sehr vorausschauend ihre Software konzipiert und heute zahlt es sich halt aus.

Ist zumindest mein Eindruck

[CameraRick]

Achso, verstehe. Ja Collabo ist das bei uns in dem Fall natürlich nur so halb, wenn der Assistent was vorbereitet und der Editor hinzufügt. Zusammen arbeitet da im selben Projekt keiner, ist aber auch derzeit kein Need für uns.

Na ja, ich würde jetzt mal behaupten dass BMD zu Zeiten von Resolve 9, 10 oder vielleicht sogar noch 11 nicht über die Art von Collabo nachgedacht hat, zumindest dahingehend war es (in meinen Augen) eine Altlast aus der Workstation-Zeit. Dass die SQL-basierte Datenbank natürlich gerade für große Häuser auch da schon Vorteile bot ist mir natürlich bewusst, die Datenbank-Kritik kommt eher aus dem Blickpunkt des Privatanwenders/kleinem Haus :)
Immerhin das User-Choosing haben sie ja dann irgendwann verloren (wobei man ja auch nur automatisch eingelogged wird, User gibt es nach wie vor). Jetzt spielt es einem natürlich alles in die Hände :)

[mash_gh4]

ich finde eure diskussion über die kollaborationsfeatures im resolve ausgesprochen spannend und wichtig!

ich selbst bin zwar in puncto videobarbeitung weniger darauf angewiesen meine daten im team mit anderen auszutauschen und gleichzeitig zu bearbeiten, aber dafür ist es mir umso wichtiger, dass der austausch zwischen verschiedenen anwendungen und werkzeugen, die ich gerne nebeneinander benutze, möglichst reibungslos und fehlerfrei funktioniert. das mag zwar auf den erten blick eine völlig anderes geartetes kriterium sein, scheint mir auf technischer ebene aber sehr viele berührungspunkte mit den von euch debattierten aspekten zu haben.

ob nun datenbankschnittstellen oder serialisierte information im filessystem als mittel der austauschs verwendung finden, ist dabei wohl eher zweitrangig. gut funktionierende locking-mechanismen lassen sich vermutlich in beiden varianten realisieren. wenn es einen grund gibt, der SQL-variante den vorrang einzuräumen, dürfte es eher performance-vorteile sein.

ich persönlich habe trotzdem die XML-basierenden persistenz der projektverwaltung, wie sie bis version 14 im resolve genutzt werden konnte, favorisiert, weil ich solche verhältnismäßig einfach durchschaubaren und überprüfbaren datenstrukturen generell bevorzuge, und sie sich auch gegenüber irgendwelche komplexen datenbanken und bessere in meine verhältnismäßig einfachen gestalteten backup- bzw. rollbacklösungen fügen. ich kann aber natürlich durchaus damit leben, dass die resolve entwickler nun beschlossen haben, diese trennung in zwei äste der datenverwaltung aufzugeben und ihre kräfte nur mehr auf die SQL-repräsentation in postgesql und sqlite datenbanken zu konzentrieren.

das wirkliche problem, dass ich aber tatsächlich kritisieren möchte, ist er umstand, dass die strukturen der entsprechende datenbanken in keiner weise dokumentiert oder für die programmierer von externen tools zugänglich ist! das halte ich für ausgesprochen unangenehme einschränkung, die letztlich auch sehr viele unsicherheiten bzw. ohnmacht und ausweglosigkeit im falle von unvorhergesehnen problemen mit sich bringt.

es ist zwar natürlich aussgesprochen erfreulich, wenn die anwendung selbst immer besser wird und neue features und gestaltungsmöglichkeiten für den endanwender hinzukommen, aber damit werden die entsprechenden internen datenstrukturen nur immer komplizierter und der austausch mit anderen programmen zusehend schwieriger und fehleranfälliger.

das ist leider nicht nur eine völlig spekulative behauptung, sondern man stößt auch auch immer wider auf ganz gravierende praktische probleme, die das wunderbar belegen.

in den changelogs zur aktullen ausgabe findet sich u.a. ein punkt:

"Addressed an issue where reimporting EDLs exported from Resolve would cause a crash"

der mir ziemlich symptomatisch für dieses problem zu stehen scheint.
je komplizierter und verwegener die internen möglichkeiten solcher programme heranwachsen, umso schwerer wird es round trips und kompatibilität mit etablierten anderen austauschformaten in befriedigender und fehlerfreier weise aufrechtzuerhalten. das führt dazu, dass dann über kurz oder lang ursprünglich nur intern genutzte projektdatenrepräsentationsformate plötzlich auch von anderen anwendungen übernommen oder für den austausch nachgeahmt werden, weil das mehr sinn als eine übersetzung macht. EDL, FCP- und FCPX-XML aber auch AAF sind ganz typische verteter einer solchen entwicklung.
ich bin gespannt, ob wir so etwas irgendwann auch einem aus dem hause BMD zu gesicht bekommen. bisher schaut's jedefalls eher so aus, als würde man sich dort noch radikaler als bei den meisten anderen konkurrenten um ein möglichst rücksichtsloses etablieren von monopolien bemühen und auf derartige bedürfnise des austauschs und der zusammenarbeit mit anderen produkten immer weniger rücksicht nehmen.

das ist ein aspekt, der mich an BMD prosdukten wirklich ganz schrecklich stört!

als positives gegenbeispiel, das mir in dieser hinsicht ziemlich vorbildlich und von den möglichkeiten selbstgestalteter technischer eingriffe ideal erscheint, würde ich hier viel eher nuke-studio bzw. hiero hervorheben. dort gibt's wirklich schnittstellen für programmierer und dokumentation für entwickler, von denen resolve anwender nur träume können!

ich glaube auch, dass es kein zu zufall ist, dass diese angesprochnen alternativen auch in puncto kollaboration -- speziell wo es um den austausch von anmerkungen und versionen zwischen gleichzeitig arbeiteten teammitgliedern geht -- dem resolve noch immer weit voraus sein dürfte.

wenn ich drüber so nachdenke, würde ich hier aber fasst gerne noch weiter ausholen, und die sache mit bezugnahme auf analogien in anderen arbeitsfeldern verdeutlichen:

ich quäle in letzter zeit immer wieder diverse arbeitskollegen damit, dass wir bei gemeinsam zu schreibenden projektansuchen, -dokumenationen u.ä. ganz bewusst mit gitlab bzw. auch gitlab pages und mittel der statischen webseitengenerierung zurückgreifen, also auf werkzeuge, die ursprünglich eher ersonnen wurden, um die arbeitsabläufe unter programmieren zu erleichtern. das hat viel damit zu tun, dass ich im lauf der jahre die erfahrung machen musste, welchen aufwand es erfordert datenbankbasiernde CMS-systeme und typische office-anwendungen über einen längeren zeitraum zu warten und darüber tatsächlich als verteiltest team mit ganz hetrogenen arbeitsmitteln (unterschiedlichen betriebssystemen etc.) zu kollaborieren. die erfahrrungen, die wir in letzter zeit mit dieser etwas geänderten herangehensweise sammeln konnten, sind ziemlich ermutigend. es ist zwar vielleicht auch nur wieder eine zeiterscheinung, die irgendwann wieder von geeigenetern mitteln abgelöst werden wird, aber zumindest zum gegenwärtigen zeitpunkt scheint es einigermaßen konstruktiv auf umstände eine antwort zu geben, die man nicht einfach weiterschleppen oder ungelöst stehen lassen will. natürlich ist das nicht so einfach auf die anforderungen der videoproduktion umlegbar, wo ja auch ich hauptsächlichr mit ziemlich komplexen geschlossenen anwendungslösungen arbeite. trotzdem nimmt man auch dahin eine bisserl was von diesem nachdenken über reduzierter formen der austauschs, der versionsverwaltung bzw. projketdokumentation und kollaboration mit, wenn man sich damit einmal in anderen kontexten anzufreunden gelernt hat.

[Frank Glencairn]

Ich versteh immer noch nicht wo dein Problem mit der Datenbank in der Praxis ist.

Von welchem konkretem Anwendungsfall sprechen wir hier?

[mash_gh4]

Ich versteh immer noch nicht wo dein Problem mit der Datenbank in der Praxis ist.

datenbanken per se zu verdammen und abzulehnen macht sicher keinen sinn. ich kann gut verstehen, dass sie im resolve genutzt werden, und man mittlerweile eben auch dazu übergegangen ist, sie als einziges mittel der längerfristigen datenverwaltung einzusetzten bzw. die parallele möglichkeit serialisierte XML-projektverwaltungsfiles im dateisystem abzulegen neuerdings nicht mehr zur verfügung steht.

auch die konkret verwendeten datenbanken -- postgresql in den größern setups, wo auch kollaborationsfähigkeiten geboten werden, und sqlite als einfache lösung, die ohne großen aufwand als eingebette datenbank lokal genutzt werden kann -- finde ich beide gut und ausgereift. es handelt sich dabei ja auch in beiden fällen um sehr bekannte open source projekte, die lange jahre der entwicklung und der laufenden verbesserung hinter sich haben.

wenn man das ganze also wirklich ernsthaft hinterfragen will, kann es dabei nur um die frage gehen, wie weit die datenstrukturen in diesen zusammenhang auch jenseits des genutzten anwendungsprogramms eingesehen, genutzt und ggf. überprüft, modifiziert und von außen repartiert werden können -- evtl. aber auch um die frage, welche probleme sich vor allem im zusammenhang mit schleichenden fehlern bzw. sehr schwer und oft viel zu spät entdeckten inkonsistenzen in datenbanken ergeben können?

dieses problem mit den schleichenden fehlern mag zwar auf den ersten blick völlig an den haaren herbeigezogen erscheinen, tritt aber bei sehr komplexen datenstrukturen bzw. relation zwischen ihnen in der praxis leider doch immer wieder in erscheinung. auch wenn die programmierer und natürlich ihr bestes tun, um derartiges zu vermeiden, gibt's manchmal doch situationen, wo einem nichts anders über bleibt, als in der zeit zurückzugehen und auf eine ältere form des projekt zurückzugreifen. das geht im einfachsten fall mit sicherheitskopien des speicherabbilds bzw. datenbank-dumps aber z.t. auch mit rollback-befehlen direkt auf datenbankebene, mit denen man frühere zustände in einer weise wiederherstellen kann, die einen konsistenten zustand repräsentieren -- was ja nicht unbedingt der fall sein muss, wenn z.b. alleine mit apples time machine od. ähnlichen filesystem-snapshot-mechanismen nur jene files, die die datenbanken nutzen im laufenden betrieb sichert.

mir persönlich ist dies problem vor allem deshalb so vertraut, weil ich lange jahre große internet server strukturen betreut habe, wo ja fast regelmäßig irgendwelche schwachstellen in veralteten wordpress-plugins u.ä. von außen ausgenutzt werden, um maschinen bzw. einzelne anwendungsinstanzen zu 'kompromitieren' -- also irgendwelche ganz unscheinbare änderungen vorzunehmen, die auf den ersten blick kaum erkennbar sind --, die dann meistens auch eine weile nicht benutzt werden, um dann plötzlich für irgendwelche wirklich problematischen angriffe genutzt werden. derartige schleichende bedrohungen sind ganz schwer in den griff zu bekommen, weil es eben so schwierig ist, den kompromitierungszeitpunkt nachträglich herauszufinden und mit backups od. rollback-mechnaismen wenigstens wieder zum damaligen zustand zurückzukehren bzw. betroffen daten zu retten.

aber dieses szenario ist natürlich nicht so ohne weiteres auf resolve anzuwenden, weil man dort ja kaum derartige angriffsflächen für bösartige störungen von außen bietet. aber trotzdem: auf den ersten blick unerkennbare fehler, die erst später ganz fatale folgen nach sich ziehen, stellen sich einfach auch in gut funktionierenden systemen mmer wieder ein, wenn sie nur ausreichend komplex sind.

eine anders beispiel, das man hier vielleicht einbringen könnte, um möglichst konstruktive lösungen im umgang mit solchen fragen zu veranschaulichen, sind große softwareentwicklungsprojekte, wo sich ja auch regelmäßig das problem stellt, dass irgendwelche winzigen änderungen, die irgendwann einmal von einem mitarbeiter in den sourcecode eingepflegt wurden, sich nachträglich als fehlerhaft herausstellen bzw. im ersten schritt einmal einfach nur störungen (regressions) auftreten, deren ursache nicht wirklich klar erkennbar ist. das passiert ausgesprochen oft, auch wenn sich alle entwickler noch so sehr bemühen, fehler zu vermeiden und neu hinzukommenden code vor dem einpflegen gegenseitig zu überprüfen. in diesen fällen arbeitete man dann oft mit speziellen techniken, die an hand eines kleinen testprogramms den versionsverlauf des progrogrammcodes zeitlich zurückgehen, um schritt für schritt jenen änderung zu finden, wo sich das problem zum ersten mal zeigt.

sorry, wenn ich hier so weit aushole, und vielleicht für dich gar nicht mehr erkennbar ist, wie derartiges auf schnitt- od. color grading programme vernünftig umgelegt werden könnte?

was ich damit herauszuheben versuche, ist die wichtigkeit, den zeitlichen änderungsverlauf sinnvoll zu erfassen und nachträglich greifbar zu machen. genau das also, was versionsverwaltungssysteme, aber z.t. durchaus auch div. datenbanklösungen, wunderbar erlauben, was auch in viele kollaborativen arbeitszusammenhängen mittlerweile geradezu unverzichtbar geworden ist.

ich würde in der frage so weit gehen, dass ich sogar eine schnitt- od. gradinglösung, die hier weniger auf möglichst schnelle zugriffe setzt, sondern statt dessen z.b. git für eine vernünftige versionsverwaltung, verteilte zusammenarbeit im team und begleitende dokumentation der projektdaten nutzt, bevorzugen würde.

realistischer weise ist man hier ohnehin nur mit derart kleinen anfallenden datenmengen konfrontiert, dass entsprechende serialisierte XML u. YAML-repräsentation im filesystem durchaus genügen, um eine vernünftige verarbeitungsgeschwindigkeit zu gewährleisten. die meisten derartigen lösungen -- auch richtig große -- nutzten ja auch in wahrheit nichts anderes, während jene lösungen, die schon lange um datenbanken herum zentriert sind (ich denke z.b. an lightworks), doch immer wieder von diesen schwer aufzulösenden inkonsistenzen in der datenbank bzw. korrupter projektverwaltung geplagt sind.

trotzdem -- diese bedenken richten sich nicht so sehr alleine gegen die verwendung von datenbanken, sondern vielmehr ganz allgemein gegen intransparente und nach außen hin undokumentierte projektverwaltungen.

ich kann mir gut vorstellen, dass solche bedenken für viele endanwender völlig unverständlich sind bzw. die meisten damit zufrieden sind, wenn sich alleine die entwickler der entsprechenden software um solche dinge kümmern. dem kann man nur entgegenhalten, wie viel nutzen und möglichkeiten sich daraus ergeben, wenn derartige dinge offener und mit nicht monopolistisch orientierten proprietären ansätzen bewerkstelligt werden.

natürlich bin ich mit dieser sichtweise und entsprechender neugierde nicht ganz allein. immer wieder stößt man auf andere kollegen, die zumindest ihr bestes tun, im sich auch im falle vom resolve auf umwegen bzw. über mühsames reverse engineering einblick in die entsprechenden verwaltungsstrukturen zu verschaffen (siehe z.b. http://www.liftgammagain.com/forum/inde ... rams.8740/).

BMDs politik in dieser frage ist trotzdem erschreckend stur und kompromisslos. sinnvolle werkzeuge von drittanbieter, wie z.b. plurar eyes, aber auch einfachere praktische scripts, wie man sie im konforming-umfeld gelegentlich benötigt, können unter diesen einschränkungen einfach nicht vernünftig umgesetzt werden. das schafft unbefriedigende abhängigkeiten von einer einzigen paternalistischen instanz, von der man sich ohne wenn und aber abhängig macht. ich persönlich ziehe es einfach vor, über diese dinge auch unabhängig von irgendwelchen groben störungen und problemen, wo man dann wirklich ansteht und in seiner praktischen arbeit behindert wird, kritisch nachzudenken und für verbesserungen des gegebenen einzutreten.

[-paleface-]

Ich habe das Gefühl das Davinci nach dem Update die "GRAB STILL" Funktion verändert hat.
Wenn ich ein Still mache und das über mein Grade lege sehe ich eindeutig eine andere Kompression, Bildschärfe und leichten Helligkeits Unterschied.

Gibt es da irgendwo Einstellungen wie ich das beeinflussen kann?

[Frank Glencairn]

sorry, wenn ich hier so weit aushole, und vielleicht für dich gar nicht mehr erkennbar ist, wie derartiges auf schnitt- od. color grading programme vernünftig umgelegt werden könnte?

Danke für die ausführliche Antwort.

Ich versteh schon was du meinst, aber in der Praxis kannst du zu jedem beliebigen Zeitpunkt einfach ne aktuelle Kopie deiner Datenbank oder des Projekts auf nen beliebigen Datenträger zur Sicherheit ziehen, was wahrscheinlich über 90% der von dir angesprochenen Szenarien entschärft.

Ich exportiere z.B. täglich ne Version von Laufenden Projekten und einmal die Woche, die Komplette Datenbank zur Sicherheit. Gebraucht hab ich das in all den Jahren trotzdem nie, und ich bin Betatester, d.H. ich arbeite oft mit halbgaren Versionen. Selbst wenn alles aus irgend einem Grund über den Jordan geht, kann ich also in Minutenschnelle alles wieder 1:1 herstellen.

Ich kenn Leute, die für größere Projekte jeweils ne eigene Datenbank anlegen - man kann ja zwischen beliebig vielen Versionen switchen, halte ich aber für einen Overkill.

[Peppermintpost]

ich verstehe die Kritik an der Datenkank nur bedingt.
Klar wenn die Datenbank aus irgend welchen Gründen abraucht ist halt alles in der Datenbank futsch. Das ist unschön.
Das würde auch zum Problem werden wäre die Davinci Datenbank buggy, ist sie aber nicht.
Was mich in vergangenen Versionen (pre 14) ätzend fand war das die Export/Import Funktion nicht zu identischen Resultaten geführt hat, das bedeutet ein Projekt von einem Rechner zum nächsten umziehen zu lassen hat zu u.U. zu Problemen geführt.
Aber das ist wie ich ja hier schon beschrieben habe offensichtlich verschwunden, zumindest konnte ich diesen Fehler jetzt in v14 nicht mehr erzeugen. Wie geschrieben hab ich das auf unterschiedlichen Rechnern mit unterschiedlichen OSX Systemen und underschiedlicher Grafik (Nvidia und AMD) getestet und es war einwandfrei.

Dann ist da der Kritikpunkt das Davinci irgendwie da ihr eigenes Ding mit den Setups macht. Ja klar, aber das macht ja jeder andere Hersteller auch. Natürlich gibt es Hersteller Formate die so verbreitet sind das auch andere Software Hersteller eine Funktion einbauen diese Formate zu lesen .psd ist wohl eins der besten Beispiele, aber ein FCPX oder Avid MC Projekt bekomme ich ja auch auf keiner anderen Software auf. Genau dafür gibts ja die Austauschformate wie xml oder aaf. Resolve kann beide einwandfrei. Das es dabei hier und da mal einen Bug gibt ist natürlich ärgerlich weils halt eine sehr wichtige Funktion ist, aber auch das kommt in den besten (Software) Familien vor. The Foundry doktort auch ständig daran herum und auch in der Flame geht nicht immer alles einwandfrei, das liegt halt in der Natur der Dinge wenn es Updates gibt.

Jetzt für den Collaboration Workflow funktioniert die Datenbank super gut und hat massive Vorteile gegenüber anderen Systemen, aber für alle für die Datenbank ein Ärgerniss ist und bleibt hat Resolve ja nun die Option irgend einen Ordner zu wählen in den dann die Projekt Dateien genau so geschrieben werden wie bei jeder anderen Software auch.

[cantsin]

Es ist schon einmal positiv, dass Blackmagic auf eine robuste, seit Jahrzehnten entwickelte und auf der ganzen Welt im kritischen Produktionseinsatz bewährte Open Source-Datenbank (PostgreSQL) setzt, als irgendetwas eigenes zusammenzuflicken. Und bei komplexen Kollaborationsfeatures - bzw. Lockingmechanismen - führt wohl kein Weg an einer Datenbank vorbei.

Es stimmt aber auch, dass es wünschenswert wäre, wenn sich Projekte zur Archivierung in einem transparenten (XML-) Format abspeichern liessen, und zwar eben mit allen Parametern und Attributen, nicht nur als Schnittdatei.

[Frank Glencairn]

Und welchen Vorteil hätte das, gegenüber der normalen Projekt Datei, die genau das macht?

[cantsin]

Und welchen Vorteil hätte das, gegenüber der normalen Projekt Datei, die genau das macht?

- Dass Du eine beschädigte Projektdatei notfalls im Texteditor reparieren kannst.
- Dass man einfache Austauschoperationen für Parameter ggfs. schnell durch Suchen-und-Ersetzen im Texteditor erledigen kann (z.B. das Austauschen aller "Screen"- durch "Overlay"-Überblendungen)
- Dass Du von der Projektdatei einfach inkrementelle Backups machen kannst, in denen nur die in der neuen Version veränderten Textteile gespeichert werden.
- Dass Du dadurch die Projektdatei in externe Versionsverwaltungen wie Git/Github einbinden kannst.
- Dass man sehr einfach Programme schreiben kann, die mit der Projektdatei arbeiten, z.B. eine Export-/Import-Schnittstelle zwischen einem Textverarbeitungsprogramm und Resolves Text-Overlays oder das Extrahieren von .srt-Untertiteln aus Resolve-Textfeldern mit 10 Zeilen Python-Script, undundund...

[mash_gh4]

ja -- im wesentlichen würde ich all diesen wirklich erstebenswerten punkten zustimmen, die catsin hier aufzählt.

der gerechtikeit halber muss man aber auch auch sagen, dass sich sehr sql-datenbanken sehr einfach und in klar spezifizierter weise dumpen lassen -- womit man dann ja auch wieder ein text-file in händen hält, dass ich nur in seinem sytax von der linearisierung in XML, JSON od. YAML unterscheidet.

das wirklich hacken an dieser sache ist aber der umstand, dass in diesen files nicht einfach nur ganz elementare key-value parre und datenbanktypische relationen zu finden sind, sondern leider fast jede wirklich relevante information in völlig kryptischen und nicht weiter dokumentierten binary blobs verpackt ist. das war leider im falle von resolve auch schon in den früheren versionen mit ihren lokal gespeicherten XML files nicht anders. deshalb waren auch schon dort sehr viele von den angesprochnen vorteilen in der praxis auch dort nicht wirklich zugänglich.

dieses problem mit den bionary blobs ist übrigens auch im AAF in ganz ähnlicher weise anzutreffen. dort werden zur codierung auch noch techniken verwendet, die extrem windows spezisch sind, und das ganze auf anderen plattformen denkbar kompliziert und fremd wirken lassen.

das wirkliche heraushebenswerte gegenbeispiel sind die FCP und FCPX XML files. die sind nicht nur vernünftig strukturiert bzw. dem genutzten format gerecht werdend, sondern auch wirklich vorbildlich dokumentiert!

heute versteht man diese FCP XML files hauptsächlich als austauschformat, aber das wird der sache nicht ganz gerecht. in wahrheit wurden diese beiden formate ursprünglich ersonnen, um den komplete projektverwaltung der betreffenden programme abbilden und in persistenter weise speichern zu können. das ist wirklich ganz etwas anderes, als nur eine teilmenge des entsprechenden informationsumfangs als kleinsten gemeinsamen nenner für den austausch zwischen verschiedenen programmen zu nutzten. es ist allerdings wirklich nur den vorzügen, wie sie sich aus dieser relativ einfachen technischen form ergeben, und der wunderbaren dokumenation zu danken, dass diese XML files sich als ersatz für die längst völlig unzureichenden EDL files weitestgehend durchgesetzt haben.

aber, wie gesagt, es spricht nichts dagegen, das BMD im zuge des wirklich beeindrucken ausbaus seiner werkzeuge neue standards etabliert, die den gegenwärtigen anforderungen besser gerecht werden (natron hat z.b. vor einiger zeit die projketrepräsentation auf YAML umgestellt, weil das deutlich kleiner files mit sich bingt, die sich auch noch wesentlich schneller und problemloser verarbeiten lassen). entscheidend beleibt das kriterum, dass die betreffenden formate und internen repräsentationsformate vernünftig dokumentiert sind, damit sie auch von anderen genutzt werden können. das ist allerdings ein punkt, auf den ich wirklich nicht verzichten möchte. so gesehen ist mir der austausch und die zusammenarbeit zw. verschiedenen programmen und arbeitsmitteln einfach deutlich wichtiger als ein turmbau zu babel der sich alleine auf den ausbau der features inner halb eines einzigen programms bzw. einer geschlossen softwareumgebung bezieht.

ganz kurz aber nocheinmal zu den datenbank-typischen problemen und unterschieden in der pratischen nutztung:

ich stimme frank und Peppermintpost natürlich zu, dass man ja auch weiterhin jederzeit aus der betreffeden anwendung heraus projektfiles als sicherheitskopie exportieren kann. trotzdem sollte man einfach sehen, dass eine solche vorgehensweise sich nicht wirklich in entsprechende strukturen fügt. einen zentralen fileserver wird man ja im normalfall auch nicht händisch von den angeschlossen clients aus mühsam backupen. das macht man vielemehr besser direkt am fileserver bzw. mit automatisierten lösungen, die dem umfang der dort befindlichen oder verränderten daten viel besser gerecht werden. und das geleiche gilt natürlich auch für zentrale datenbankserver in einem professionellen arbeitsumfeld, die gewöhnlich 24stunden durchlaufen und mit speziellen, dafür vorgesehenen mitteln, gesichert werden.

in größeren betrieben, wo sich entsprechende fachkräfdte um solche notwendigen wartungsarbeiten und netzwerkinfrastruktur kümmern, ist das ohnehin eine selbstverständlichkeit, über die man nicht viele worte verlieren muss. problematischer wird es, dort wo derartige professionelle lösungen von weniger spezialisierten endanwendern genutzt oder betreut werden. da stellen sich dann schon sehr oft probleme ein, an die keiner gedacht hat od. die im routinierteren umgang mit datenbanken normalerweise von vornherein ausgeschlossen sind.

spätestens als ich unlängst die schwärmerischen ausführungen eines kollegen in einer ganz ähnlich betitelten diskussion auf LGG zu den vorzügen datenbankbasierter projektverwaltung gelesen habe, wurde mir das wieder einmal ziemlich deutlich vor augen geführt:

http://liftgammagain.com/forum/index.ph ... ost-101513

im lightworks ist das nämlich tatsäch so radikal gelöst, dass alle operationen unmittelbar in die datenbank geschieben werden, und gar kein "save"-menüpunkt od. keyboard shortcut mehr zur verfügung steht. ich bin mir nicht sicher, ob ich mir derartiges wirklich immer wünsche, weil ja auch die undo-funktionalität, die in solchen fällen oft den einzigen weg zurück bildet, nicht immer ganz genau das tut, was man sich wünscht bzw. entsprechende kontrolle oft ziemlich beschwert. im übrigen habe ich gerade an hand der nutztung dieses des betreffenden programms und dem mitverfolgen der probleme anderer benutzer im entsprechenden anwenderforum erleben dürfen, wie problematisch sich datenbankprobleme in der praxis erweisen können. noch schlimmere und häufiger auftretende probleme mit korrupten projekten habe ich ehrlich gestanden bisher überhaupt noch nie erlebt.

wie gesagt -- ich galube, dass das BMD ohehein ein bisserl besser macht bzw. vernünftigere datenbankbackends nutzt, aber trotzdem sollten einem derartige ganz praktische anhaltspunkte ein wenig zu denken geben.

natürlich spricht im sinne der von cantsin bereits ausgeführten punkte einiges für eine traditionellere und einfachere lösung. wenn beim offnen des projekts die daten deserialisiert und in die interne repräsentation des programms zuückverwandelt werden müssen, ist ja damit auch bereits ein ganz wichtiger praktischer test durchlaufen, der einen auf grobe fehler und inkonsistenzen aufmerksam machen kann. aber trotzdem kann das natürlich auch mit datenbanken ganz gut funktionieren, wenn alles gut geht.

ich würde sogar auch manche vorteile darin entdecken können, weil auf diesem weg veränderungungen am projekt auch für plugins oder hilfsprogramme von drittanbietern möglich wären, ohne das das das programm neu gestartet werden muss od. irgendeine projketdatei neu eingelesen werden muss. so etwas kann schon sinn machen -- nur müsste es halt zumindest offen gelegt werden, damit wir uns alle darüber freuen können. ;)

und dann noch zu einem punkt, den Peppermintpost vertreten hat:

Was mich in vergangenen Versionen (pre 14) ätzend fand war das die Export/Import Funktion nicht zu identischen Resultaten geführt hat, das bedeutet ein Projekt von einem Rechner zum nächsten umziehen zu lassen hat zu u.U. zu Problemen geführt.
Aber das ist wie ich ja hier schon beschrieben habe offensichtlich verschwunden, zumindest konnte ich diesen Fehler jetzt in v14 nicht mehr erzeugen. Wie geschrieben hab ich das auf unterschiedlichen Rechnern mit unterschiedlichen OSX Systemen und underschiedlicher Grafik (Nvidia und AMD) getestet und es war einwandfrei.

diese einschätzung teile ich leider definitiv nicht. meiner wahrnehmung nach gibt es in den letzten versionen zunehmend probleme, die sich aus den immer größeren abweichungen zw. der freien und der studio version bzw. den jeweils unterschiedlichen genutzten codecs ergeben.

ich zwar damit kein großes problem damit, wenn div. anspruchsvollere features nur in der ohnehin recht erschwinglichen kaufversion zur verfügubng stehen, aber gerade diese wirklich nervigen codec-bezogenen inkompatibilitäten finde ich ausgesprochen störend und ärgerlich. das scheint mir mir wirklich ein punkt zu sein, wo ich recht überzeugt ein genau gegenteiliges urteil fällen würde.

und was die kompatibilität bzw. auch nur annähernd gleichwertige funktionalität od. praktische nutzbarkeit unter linux betrifft, schweigt man hier wohl besser. es ist einfach nur traurig, wie stiefmütterlich diese ausgabe regelmäßig wieder behandelt wird bzw. wie wenige verbesserungen hier seit dem erscheinen eingeflossen sind. das ganze ist jenseits der werbeträchtigen bzw. ausschreibungspolitischen relvanz in praxis für linux-endanwender weiterhin beinahe unbenutzbar.

[CameraRick]

Aiaiaiai, da ist man ein paar Tage nicht da, und schon geht man sich nach einer friedlichen Unterhaltung an die Gurgeln... :)

Ich glaube ich habe meine Meinung zu Datenbanken in diesem und anderen Threads ausführlich erklärt, fürs Grading halte ich das in den meisten für sinnvoll, zum Schneiden finde ich es ziemlich suboptimal. Zumindest in Szenarien wie dem, in welchem ich mich bewege.

Kollaborationsfeatures konnte ich leider immernoch nicht erörtern, haben leider zu viel zu tun :(