Die Arbeit an der Anwendung Premiere Remote, mit der Adobe Premiere über eine offene Schnittstelle ferngesteuert werden kann, wurde fortgesetzt. Die Demo des aktuellen Standes zeigte die Funktionen. Anschließend wurden mehrere Verbesserungen vorgenommen: Die Konfiguration der Überwachung wurde korrigiert, die Synchronisation zwischen WSL- und Windows-Umgebung eingerichtet und ein Problem beim Neustart der Verbindung gelöst. Darüber hinaus wurden gesellschaftliche Auswirkungen von Social Media und künstlicher Intelligenz diskutiert. Die Entwicklung wurde als gemeinsame Arbeit mit einer KI wahrgenommen.

Software and Game Development
00:00:00

Software and Game Development

Einstieg und Diskussion über Social Media

00:11:47

Zu Beginn des Streams wird die Technik überprüft und über die morgendliche Musik gescherzt. Nach der Begrüßung dreht sich das Gespräch bald um einen neuen Gesetzesentwurf zur Regulierung von Online-Inhalten. Der Gesprächspartner zeigt sich gelassen, da er solche Kontrolle für ineffektiv hält, und vergleicht die Diskussion mit einer Schlammschlacht. Er äußert sich kritisch über Social-Media-Plattformen wie Twitter und TikTok, die durch algorithmische Kuratierung nur noch schlechte Inhalte liefern würden. Auch die Entwicklung von KI-generierten Shorts wird thematisiert, wobei er diese als Verlust für kreatives Kurzformat betrachtet. Diese Reflexionen über die Medienlandschaft prägen die erste halbe Stunde des Streams.

Kritik an Kurzvideos und KI-generierten Inhalten

00:17:29

Im weiteren Verlauf wird das Thema Kurzvideos vertieft. Die Kritik richtet sich gegen die mangelnde Aufmerksamkeitsspanne und den fehlenden Erinnerungswert solcher Inhalte. Die Person lobt dagegen die frühen Tage von 7-Sekunden-Videos, die kreativer waren. Sie beobachtet, dass YouTube und andere Plattformen zunehmend von KI-generierten Streams oder Avataren durchsetzt werden. Diese Entwicklung wird als natürlicher Fortschritt gesehen, allerdings mit einer gewissen Skepsis gegenüber der Qualität. Die Diskussion mündet in die Überlegung, dass die Menschheit sich vielleicht wieder mehr auf reale Gespräche besinnen wird, wenn virtuelle Kontakte ununterscheidbar werden. So wird die Hoffnung geäußert, dass die technische Entwicklung zu mehr bewussten zwischenmenschlichen Begegnungen führt.

Zukunftsgedanken über KI und menschliche Interaktion

00:20:43

Die Zukunftsvisionen werden konkreter. Es wird über implantierbare Technologien wie Neuralink spekuliert, die eines Tages Informationen direkt ins Gehirn liefern könnten. Die Sorge besteht, dass Menschen dann nicht mehr in der Lage sind, echte von künstlichen Interaktionen zu unterscheiden. Als Gegenbewegung werden abgeschottete Räume mit Handyverbot genannt, die bereits in manchen Clubs existieren. Diese Idee findet Anklang, weil sie einen geschützten Raum für ungestörte Kommunikation schafft. Gleichzeitig wird eingeräumt, dass das menschliche Gehirn nicht für die moderne Technik gemacht ist und wir uns an die neuen Herausforderungen anpassen müssen, auch wenn dies nicht immer gelingt. Die Stimmung bleibt jedoch pragmatisch, denn man könne die Entwicklung nicht aufhalten, sondern nur reagieren.

Ankündigung des Codestreams und Einführung in Premiere Remote

00:25:53

Nach dieser philosophischen Runde kündigt sich der Programmierteil an. Es wird ein neues Video für das nächste Wochenende angekündigt, und dann geht es an das Projekt Premiere Remote. Dieses Tool ermöglicht die Fernsteuerung von Adobe Premiere über eine OpenAPI-Schnittstelle. Der aktuelle Stand zeigt bereits eine funktionierende Demo, bei der der Sequenzname ausgelesen wird. Die nächsten Schritte sind ein minimales Aktionsset für den produktiven Einsatz. Dafür werden zunächst die Entwicklungsumgebung und der Dev-Container vorbereitet, um eine saubere Basis für die weiteren Arbeiten zu schaffen. Die angenehme Arbeitsweise mit dem Playground wird hervorgehoben, da man dort schnelle Änderungen testen kann.

Demonstration des Tools und Entwicklungsablaufs

00:30:00

Die Demo des Tools läuft reibungslos. Über den Playground wird eine Funktion ausgeführt, die den Namen der aktiven Sequenz zurückgibt. Anschließend wird der Entwicklungsprozess gezeigt: Der Client baut automatisch neu, und der Server kommuniziert über Websockets. Dabei fällt auf, dass Änderungen an der Funktion sofort im Client erkannt werden, wenn der Server neu geladen wird. Es wird erklärt, dass dies die Grundlage für eine spätere Automatisierung von Schnittabläufen ist. Das Vorgehen ist klar strukturiert: erst die Umgebung zum Laufen bringen, dann den Code schreiben. Auch das Problem der fehlenden Belichtung der Kamera wird kurz erwähnt, aber nicht weiter verfolgt.

Bugfix für Notemon und Watch-Konfiguration

00:35:00

Ein Bug im Überwachungsmechanismus von Notemon wird entdeckt und behoben. Der Server startet nicht neu, wenn neue Funktionen im OpenAPI-Contract hinzukommen. Nach einigem Herumprobieren zeigt sich, dass die Lösung darin besteht, zwei Watch-Einträge in der Konfiguration zu hinterlegen: einmal für den Quellcode und einmal für die JSON-Datei. Diese Änderung wird direkt umgesetzt und getestet, sodass die Funktion korrekt umbenannt und ausgeführt werden kann. Die Genugtuung über den schnellen Fix ist deutlich, da dieses Problem schon länger bestand. Die Beobachtung des Fehlers wird akribisch dokumentiert, um ähnliche Fälle in Zukunft zu vermeiden.

Synchronisation zwischen WSL und Windows

00:43:20

Nun widmet sich das Gespräch der Synchronisation zwischen Linux- und Windows-Umgebungen. Da Premiere nur unter Windows läuft, der Code aber in WSL entwickelt wird, muss das Build-Ergebnis in ein für Premiere sichtbares Verzeichnis kopiert werden. Es werden verschiedene Ansätze diskutiert, von Umgebungsvariablen bis zu fest eingebundenen Ordnern. Der favorisierte Vorschlag ist eine env-Variable, die optional gesetzt werden kann. Falls sie nicht gesetzt ist, soll ein Fallback in ein temporäres Verzeichnis genutzt werden. Diese Lösung wird als einfach und robust angesehen, da sie keine komplexen Mount-Konfigurationen erfordert. Gleichzeitig wird die Notwendigkeit betont, alle Entwickler-Szenarien zu unterstützen, von WSL bis Docker.

Implementierung der env-Variablen und erste Hürden

00:58:20

Die Implementierung der env-Variablen wird in Angriff genommen. Ein Skript soll den Build-Ordner nach dem Bauen in das angegebene Windows-Verzeichnis kopieren. Dazu wird eine .env-Datei mit einem Beispiel angelegt, die der Nutzer ausfüllen kann. Der Dev-Container muss so konfiguriert werden, dass er diese Variable beim Start liest und den Zielordner als Mount bereitstellt. Nach dem Rebuild des Containers wird getestet, ob die Variable ankommt. Zwar funktioniert der Mechanismus, aber die Variable wird nicht automatisch aus der .env-Datei geladen, was zu ersten Problemen führt. Stattdessen fällt der Fallback auf das temporäre Verzeichnis, was den Test aber erlaubt.

Fehlersuche bei Umgebungsvariablen und Container-Mount

01:23:20

Die Fehlersuche geht weiter, denn die Umgebungsvariable wird nicht korrekt in den Container übernommen. Es wird geprüft, ob eine manuelle Konfiguration in der Shell notwendig ist. Schließlich stellt sich heraus, dass der Zugriff auf die Variable von der Art des Starts abhängt. Der Vorschlag, eine .env-Datei zu verwenden, wird verworfen, da sie beim Containerstart nicht berücksichtigt wird. Stattdessen wird auf eine Symlink-Lösung umgeschwenkt: Ein Docker-Command erstellt einen Link vom Zielverzeichnis zu einem internen Pfad, sodass Premiere die Dateien erkennen kann. Nach dem Rebuild wird der Link erfolgreich gesetzt, und der Build wird in das Windows-Verzeichnis kopiert.

Erfolgreiche Einrichtung mit Symlink und funktionierender Watch

01:48:20

Der Symlink-Ansatz funktioniert endlich einwandfrei. Der Dev-Container erstellt beim Start einen symbolischen Link vom workspace zum angegebenen Zielordner auf dem Windows-System. Dadurch werden Änderungen an Build-Dateien sofort in Premiere sichtbar, ohne dass manuelles Kopieren nötig ist. Ein Test mit dem Watch-Button zeigt, dass der Client nach kleinen Änderungen sofort neu lädt. Auch größere Änderungen wie das Umbenennen von Funktionen werden zuverlässig erkannt. Damit ist ein wichtiger Schritt erreicht, um die Entwicklungserfahrung zu verbessern, insbesondere für die spätere Integration von KI-Agenten, die den Code automatisch schreiben sollen.

Letztes Problem mit Reload und dessen Lösung

02:05:00

Es bleibt noch ein Fehler beim Reload des Plugins. Nach einem Neustart des Servers dauert es manchmal fast zehn Sekunden, bis sich das Plugin wieder verbindet. Durch gezieltes Experimentieren wird herausgefunden, dass der Reconnect-Layer die alte Verbindung nicht sofort schließt. Die Lösung besteht darin, die Wartezeit für den Reconnect zu verkürzen und die Verbindung beim Start sauber zu trennen. Nach dem Fix laufen die Tests durch: Der Server startet neu, und das Plugin verbindet sich sofort wieder. Die Änderungen sind minimal, aber effektiv. Damit sind die anfangs identifizierten Probleme gelöst, und der Stand kann committet werden.

Fazit zur AI-Zusammenarbeit und Ausblick

02:21:40

Zum Abschluss wird ein Fazit gezogen. Die Zusammenarbeit mit der KI war produktiv, obwohl es einige Fehlentscheidungen gab. Das Gefühl des gemeinsamen Voranschreitens erinnert an traditionelle Coding-Streams, nur dass die KI als gleichberechtigter Partner agiert. Die Entwicklung von Premiere Remote ist deutlich vorangekommen, und ein Release im nächsten Jahr scheint möglich. Die Diskussion über die Zukunft des Codings und die Rolle von KI wird angeregt, aber ohne endgültige Antworten. Zum Ende wird sich für die Zuschauer bedankt und auf den nächsten Stream verwiesen, bei dem das minimal Action-Set implementiert werden soll.