Tools & Systeme: Wie aus Werkzeugen ein Workflow wird

Zwischen kreativer Entscheidung, KI-Unterstützung und technischer Organisation

Katsubō Stories entsteht nicht in einem einzelnen Programm. Hinter einer veröffentlichten Story arbeiten unterschiedliche Werkzeuge und Plattformen zusammen. Einige helfen dabei, Gedanken und Geschichten zu entwickeln und zu strukturieren. Andere unterstützen die Musik- oder Bildentwicklung, die Erstellung von Podcast-Inhalten, Distribution, Veröffentlichung oder technische Abläufe. Entscheidend ist deshalb nicht nur, welches Werkzeug verwendet wird. Entscheidend ist, welche Aufgabe es innerhalb des gesamten Prozesses übernimmt.

Ein Werkzeug kann Vorschläge machen, Varianten erzeugen, Informationen strukturieren oder wiederkehrende Arbeit vereinfachen. Es entscheidet jedoch nicht allein, welche Geschichte Katsubō Stories erzählt, welche Variante zur jeweiligen Story passt oder welches Ergebnis schließlich veröffentlicht wird. Der grundlegende Ablauf bleibt deshalb:

Idee → Werkzeug → Varianten → Vergleich → Prüfung → Entscheidung → nächster Arbeitsschritt

Aus einzelnen Programmen entsteht erst dann ein System, wenn ihre Aufgaben klar voneinander getrennt und ihre Ergebnisse bewusst miteinander verbunden werden.

 

Nicht jedes Werkzeug hat dieselbe Aufgabe

Ein Werkzeug für Storyentwicklung erfüllt eine andere Funktion als ein Musikgenerator. Ein Bildwerkzeug löst andere Aufgaben als eine Distributionsplattform. Ein Artist-Portal übernimmt eine andere Rolle als eine Webseite. Und ein technisches Werkzeug für Workflows und Automatisierung soll nicht plötzlich kreative Entscheidungen übernehmen. Deshalb betrachte ich die eingesetzten Werkzeuge nicht danach, wie viel sie theoretisch können, sondern danach, welche konkrete Aufgabe sie innerhalb von Katsubō Stories erfüllen. Ein Werkzeug kann sehr leistungsfähig sein und trotzdem nur einen einzelnen Teil des Gesamtprozesses übernehmen. Das sichtbare Ergebnis entsteht erst durch das Zusammenspiel dieser unterschiedlichen Aufgaben. Das Werkzeug kann wechseln. Die Aufgabe innerhalb des Systems bleibt. 

 

Denken, Schreiben & Strukturieren · ChatGPT

ChatGPT bildet einen zentralen Arbeitsraum innerhalb von Katsubō Stories. Hier entwickle und prüfe ich Ideen, strukturiere Geschichten, arbeite Figuren und Situationen aus, entwickle Lyrics und musikalische Richtungen, vergleiche Varianten und dokumentiere Entscheidungen. Auch viele Verbindungen zwischen einzelnen Bereichen entstehen zunächst hier: Eine Story kann zur Grundlage eines Songs werden, ein musikalischer Moment zu einer visuellen Idee führen oder eine Beobachtung aus einem bestehenden Kapitel neue Fragen für spätere Geschichten auslösen. ChatGPT übernimmt dabei nicht die kreative Verantwortung für das Projekt. Ich gebe Ausgangspunkt, Richtung und Anforderungen vor, vergleiche Ergebnisse, korrigiere Widersprüche und entscheide, welche Vorschläge tatsächlich zu Katsubō Stories gehören. Damit ist ChatGPT nicht einfach ein Werkzeug zum Erzeugen von Text. Es dient gleichzeitig als Denkraum, Strukturierungswerkzeug, Entwicklungsumgebung und Unterstützung bei der Qualitätskontrolle. Von hier aus werden Ergebnisse anschließend an andere Teile des Workflows weitergegeben – beispielsweise an die Musikentwicklung, visuelle Umsetzung, Veröffentlichung oder technische Organisation.

 

Musikentwicklung · Suno

Suno übernimmt innerhalb von Katsubō Stories die musikalische Generierung auf Grundlage der zuvor entwickelten Story, Lyrics und musikalischen Richtung. Bevor ein Song in Suno entsteht, sind zentrale Entscheidungen bereits vorbereitet. Dazu gehören beispielsweise Perspektive und Funktion des Songs innerhalb der Geschichte, Lyrics, emotionale Richtung, gewünschte Atmosphäre, Instrumentierung, Energie, Stimmcharakter und weitere musikalische Vorgaben. Suno setzt diese Vorgaben in unterschiedliche musikalische Varianten um. Dabei betrachte ich die erste Generierung nicht automatisch als fertigen Song. Je nach Titel können zahlreiche Versionen entstehen. Diese werden angehört, miteinander verglichen und schrittweise eingegrenzt. Entscheidend ist dabei nicht nur, welche Version musikalisch zunächst am besten klingt. Ich prüfe unter anderem:

Aussprache · Texttreue · fehlende oder zusätzliche Wörter · Übergänge · Beginn und Ende · Stimme · Atmosphäre · emotionale Wirkung · Zusammenhang mit der Story und dem Album

Gerade bei mehrsprachigen oder koreanischen Textpassagen spielt die Aussprache eine wichtige Rolle. Eine musikalisch starke Version kann deshalb trotzdem ausscheiden, wenn Wörter unverständlich ausgesprochen werden oder die phonetische Wirkung nicht zu dem zuvor entwickelten Text passt. Wenn eine Variante in einem wichtigen Punkt nicht funktioniert, kann der Prozess zurückgehen: Lyrics oder musikalische Beschreibung werden angepasst, neue Varianten erzeugt und anschließend erneut verglichen.

Dadurch entsteht kein linearer Ablauf von Prompt → Song, sondern ein wiederkehrender Auswahlprozess: 

Story + Lyrics + musikalische Richtung → Suno → Varianten → Vergleich → Prüfung → Anpassung → neue Varianten → finale Auswahl

Suno erzeugt damit musikalische Möglichkeiten. Welche Version zur Geschichte gehört, welche Fehler eine neue Generierung notwendig machen und welche Aufnahme schließlich veröffentlicht wird, bleibt eine bewusste Auswahl innerhalb des Gesamtprozesses. Nach der finalen Entscheidung werden die benötigten Audiodateien gesichert und für die nächsten Arbeitsschritte vorbereitet. Von dort führt der Workflow weiter zur visuellen Umsetzung, Release-Vorbereitung und späteren Distribution.

Kurz gesagt: Suno erzeugt nicht die Geschichte. Es gibt einer bereits entwickelten Geschichte musikalische Möglichkeiten.

 

Visuelle Entwicklung · ChatGPT · Leonardo.Ai

Die visuelle Entwicklung beginnt bei Katsubō Stories nicht erst mit der Bilderzeugung. Zuerst wird aus Story, Musik, Figuren, Orten und wiederkehrenden Motiven eine visuelle Richtung entwickelt. Dabei geht es um Fragen wie: Welche Atmosphäre soll sichtbar werden? Welche Szene trägt den entscheidenden Moment? Wie viel Nähe oder Distanz brauchen die Figuren? Welche Rolle spielen Licht, Blickrichtung, Umgebung oder Bewegung? Und welche Elemente dürfen sichtbar sein, ohne die Geschichte bereits vollständig zu erklären? ChatGPT steht in diesem Prozess meist am Anfang. Hier entwickle ich Bildideen, Szenenbeschreibungen, Kompositionen und visuelle Varianten aus dem bereits vorhandenen Story-Material. Dabei kann ChatGPT sowohl bei der konzeptionellen Vorbereitung als auch bei der direkten Bildentwicklung eingesetzt werden. Das Bild entsteht dadurch nicht unabhängig von der Geschichte, sondern aus ihr heraus. Ein möglicher Ablauf ist:

Story + Musik + Figuren + Motive → visuelle Richtung → Bildbeschreibung → Varianten → Vergleich → Anpassung

Dabei wird die erste Version nicht automatisch übernommen. Ich prüfe unter anderem:

Komposition · Figurenposition · Gesichtsausdruck · Blickrichtung · Umgebung · Licht · Atmosphäre · Storybezug · visuelle Fehler · technische Eignung für das spätere Format

Gerade bei wiederkehrenden Figuren ist wichtig, dass ein Bild nicht nur für sich funktioniert. Es muss auch innerhalb der bereits entwickelten Welt glaubwürdig bleiben. Leonardo.Ai ergänzt diesen Prozess als weiteres visuelles Werkzeug. Dort können zusätzliche Bildvarianten, Cover, vertikale Formate oder kurze visuelle Sequenzen entwickelt werden. Diese können beispielsweise für Social Media, Reels, Shorts oder Spotify Canvas verwendet werden. Auch hier gilt: Eine technisch oder optisch beeindruckende Variante ist nicht automatisch die richtige. Ein Bild kann schön sein und trotzdem die falsche Situation erzählen. Eine Figur kann gut dargestellt sein und trotzdem nicht zur Szene passen. Eine Komposition kann spektakulär wirken und gleichzeitig zu viel über eine Geschichte vorwegnehmen. Deshalb gehört auch bei visueller Arbeit die Auswahl selbst zum kreativen Prozess.

beschreiben → erzeugen → betrachten → vergleichen → anpassen → erneut erzeugen

Die verfügbaren Werkzeuge verändern sich schnell. Auch ihre Möglichkeiten entwickeln sich weiter. Deshalb können ältere und neuere Visuals innerhalb von Katsubō Stories unterschiedlich aussehen. Diese Unterschiede werden nicht automatisch nachträglich korrigiert oder ältere Veröffentlichungen vollständig neu gestaltet. Sie dokumentieren auch, welche Werkzeuge, Möglichkeiten und Entscheidungen zu einem bestimmten Zeitpunkt vorhanden waren.

Die visuelle Entwicklung soll die Geschichte unterstützen – nicht sie ersetzen.

ChatGPT und Leonardo.Ai erzeugen visuelle Möglichkeiten. Welche Darstellung zur Geschichte gehört, welche Fehler korrigiert werden müssen und welches Ergebnis schließlich als Cover, Standbild oder kurze Sequenz verwendet wird, entsteht durch Vergleich, Prüfung und bewusste Auswahl. Von dort führt der Workflow weiter zur Veröffentlichung, Distribution und späteren Verwendung auf Webseite und Social Media.

 

Quellenarbeit & Podcast-Erstellung · Gemini Notebook (ehemals NotebookLM)

Für die Podcast-Inhalte von Katsubō Stories nutze ich Gemini Notebook. Viele der bereits veröffentlichten Podcast-Folgen entstanden noch unter dem früheren Produktnamen NotebookLM. Die Grundlage für einen Podcast entsteht jedoch nicht erst in diesem Werkzeug. Zuvor liegen bereits Storytexte, Hintergrundinformationen, Figuren, Orte, Zusammenhänge oder andere vorbereitete Quellen vor. Diese Materialien bilden den Rahmen, innerhalb dessen der Podcast entwickelt werden kann. Gemini Notebook arbeitet damit nicht unabhängig von Katsubō Stories, sondern auf Grundlage des Materials, das für das jeweilige Thema bereitgestellt wird.

Der Ablauf beginnt deshalb nicht mit:

KI → Podcast

sondern mit:

vorbereitete Quellen → Gemini Notebook → gesprochene Aufbereitung → Prüfung → Veröffentlichung

Ein wichtiger Vorteil besteht darin, dass bereits vorhandenes Material in eine andere Form übersetzt werden kann. Eine Geschichte kann gelesen werden. Ein Song kann sie musikalisch interpretieren. Ein Bild kann einen Moment sichtbar machen. Und ein Podcast kann zusätzliche Zusammenhänge, Hintergründe oder Perspektiven hörbar machen. Dabei ersetzt der Podcast weder die ursprüngliche Story noch die Musik. Er eröffnet einen weiteren Zugang zu demselben Projekt.

Auch gesprochene Inhalte werden vor der Veröffentlichung geprüft.

Ich kontrolliere, ob zentrale Zusammenhänge korrekt wiedergegeben werden, ob Aussagen zum zugrunde liegenden Material passen und ob die entstandene Folge innerhalb von Katsubō Stories sinnvoll eingesetzt werden kann. Nicht jede erzeugte Aussage muss automatisch Teil des veröffentlichten Projekts werden. Gerade bei längeren oder komplexeren Story-Zusammenhängen ist deshalb wichtig, zwischen dem vorhandenen Quellenmaterial und einer möglichen Interpretation daraus zu unterscheiden. Gemini Notebook übernimmt damit vor allem die quellenbasierte Aufbereitung und die Erstellung gesprochener Inhalte. Die Auswahl der Quellen, ihre Einordnung, die Prüfung des Ergebnisses und die Entscheidung über die Veröffentlichung bleiben Teil meines Workflows.

Aus vorhandenem Material entsteht dadurch kein zweites Projekt, sondern ein weiterer Zugang zu derselben Welt.

Nach der Prüfung wird die fertige Podcast-Folge anschließend über die dafür vorgesehene Veröffentlichungs- und Verwaltungsplattform weitergeführt.

 

Podcast-Veröffentlichung & Verwaltung · Spotify for Creators

Nach der Erstellung und Prüfung wird die fertige Podcast-Folge über Spotify for Creators veröffentlicht und verwaltet. Während Gemini Notebook für die quellenbasierte Entwicklung und gesprochene Aufbereitung eingesetzt wird, beginnt mit Spotify for Creators ein anderer Teil des Prozesses: die eigentliche Veröffentlichung. Hier werden Podcast-Folgen angelegt, Titel und Beschreibungen ergänzt und die veröffentlichten Inhalte innerhalb des Podcast-Bestands organisiert. Damit entsteht erneut eine klare Trennung zwischen:

Inhalt entwickeln → Inhalt prüfen → Inhalt veröffentlichen → Veröffentlichung verwalten

Spotify for Creators entscheidet dabei nicht darüber, welche Geschichte erzählt werden soll. Die Plattform übernimmt die technische und organisatorische Ebene nach der inhaltlichen Entwicklung. Ich prüfe unter anderem: 

Titel · Beschreibung · Zuordnung zur richtigen Folge oder Staffel · Veröffentlichungsstatus · Darstellung · verfügbare Links · veröffentlichte Reihenfolge

Gerade bei einem Podcast, der mit einer größeren Storywelt verbunden ist, reicht es nicht aus, dass eine Folge technisch online ist. Sie muss auch innerhalb des gesamten Projekts richtig eingeordnet sein. Eine Folge kann beispielsweise zu einer bestimmten Story, einem Hintergrundthema oder einer größeren Staffel gehören. Diese Verbindung muss für mich weiterhin nachvollziehbar bleiben.

Veröffentlichung bedeutet deshalb auch hier nicht automatisch Abschluss.

Nach dem Erscheinen kontrolliere ich, ob die Folge korrekt dargestellt wird und ob die vorgesehenen Verbindungen zu Webseite oder weiteren Inhalten funktionieren. Der Podcast wird damit zu einem weiteren veröffentlichten Bestandteil des Systems – neben Musik, Stories und visuellen Inhalten. Ein möglicher Ablauf ist:

Quellenmaterial → Gemini Notebook → Podcast-Inhalt → Prüfung → Spotify for Creators → Veröffentlichung → Kontrolle → Verbindung mit Webseite und weiteren Inhalten

Auch die Podcast-Veröffentlichung ist damit kein isolierter Vorgang. Sie wird Teil des größeren Katsubō-Stories-Workflows. 

Gemini Notebook entwickelt aus vorbereitetem Material einen möglichen gesprochenen Zugang. Spotify for Creators macht daraus einen verwalteten und veröffentlichten Podcast-Inhalt.

 

Distribution · DistroKid

Nach der kreativen Entwicklung, Auswahl und Vorbereitung beginnt mit DistroKid die technische Distribution der Musik. Hier werden die finalen Audiodateien, Cover, Titel, Credits, Sprachen, Veröffentlichungsdaten und weitere Metadaten zu einem Release zusammengeführt und an die vorgesehenen Streamingplattformen und Stores übermittelt. DistroKid übernimmt damit nicht die kreative Entwicklung des Songs. Die Plattform übernimmt die Verteilung. Der Ablauf beginnt deshalb nicht erst beim Upload, sondern mit einer vorbereiteten Veröffentlichung:

finale Audiodatei + Cover + Metadaten → Prüfung → DistroKid → Validierung → Distribution → Plattformkontrolle

Vor dem Upload prüfe ich, ob die benötigten Angaben vollständig und konsistent sind. Dazu gehören je nach Release unter anderem:

Artist · Song- oder Albumtitel · Audiodateien · Cover · Songreihenfolge · Credits · Sprache · Veröffentlichungsdatum · weitere Metadaten

Gerade bei mehrsprachigen Titeln oder unterschiedlichen Schriftsystemen wird die Metadatenpflege zu einem eigenen Teil der Qualitätskontrolle. Ein Fehler in einer Audiodatei betrifft zunächst den Song. Ein Fehler in den Metadaten kann dagegen gleichzeitig auf mehreren Plattformen sichtbar werden. Deshalb kontrolliere ich die eingegebenen Daten noch einmal gegen die vorbereiteten Informationen, bevor ein Release abgeschickt wird.

Auch der Upload selbst ist nicht automatisch das Ende.

DistroKid oder einzelne Plattformen können Hinweise, Validierungen oder Rückfragen zurückgeben. Dann muss geprüft werden, worauf sich die Meldung bezieht und ob Metadaten, Dateien oder andere Angaben angepasst werden müssen. Je nach Fall kann dabei auch ein Supportprozess notwendig werden. Erst wenn der Release den Auslieferungsprozess erfolgreich durchlaufen hat, beginnt die nächste Kontrollstufe.

Distribution bedeutet Reichweite – nicht automatisch aktive Profilpflege.

Über DistroKid können Veröffentlichungen an deutlich mehr Streamingplattformen und Stores ausgeliefert werden, als ich selbst aktiv verwalte. Ein konkreter Katsubō-Stories-Release wurde beispielsweise an 25 Streamingplattformen und Stores übermittelt. Dazu können große internationale Musikdienste ebenso gehören wie Plattformen, die für bestimmte Regionen oder Märkte relevanter sind. Nicht jede dieser Plattformen bietet für mich einen sinnvollen oder zugänglichen Artist-Bereich. Und nicht jede Plattform muss zusätzlich mit Bild, Biografie, Profiltexten oder weiteren Inhalten aktiv gepflegt werden. Deshalb unterscheide ich zwischen zwei Ebenen:

Distribution → der Release wird an die Plattform ausgeliefert · Artist-Pflege → ausgewählte Plattformen werden anschließend aktiv verwaltet

Diese Trennung ist wichtig. Ein Release kann korrekt auf einer Plattform verfügbar sein, ohne dass dort zusätzlich ein individuell gepflegtes Artist-Profil geführt wird. Nach der Distribution wird kontrolliert. Ich prüfe – soweit es auf der jeweiligen Plattform möglich ist – unter anderem: 

richtige Artist-Zuordnung · Titel · Cover · Release-Darstellung · verfügbare Links · erkennbare Abweichungen zu den vorbereiteten Daten

Nicht alle Stores stellen über DistroKid anschließend einen direkten Link bereit. In solchen Fällen kann eine zusätzliche Suche auf der jeweiligen Plattform notwendig sein. Damit wird die Distribution nicht als Blackbox behandelt. Das ausgelieferte Ergebnis wird wieder mit dem ursprünglich vorbereiteten Release verglichen. Wenn eine Abweichung auftritt, beginnt erneut ein Prüfprozess:

Problem erkennen → Ursache eingrenzen → Korrektur oder Support → erneut kontrollieren

DistroKid bildet damit die Verbindung zwischen dem intern vorbereiteten Release und seiner öffentlichen Verfügbarkeit auf zahlreichen Musikplattformen. DistroKid verteilt den Release. Welche Daten veröffentlicht werden, welche Version dafür verwendet wird und ob das ausgelieferte Ergebnis korrekt ist, bleibt Teil meiner eigenen Prüfung und Verwaltung.

 

Artist-Profile, Statistiken & Release-Pflege

Nach der Distribution beginnt auf ausgewählten Plattformen die aktive Pflege der Künstlerprofile. Dabei ist wichtig, zwischen zwei Dingen zu unterscheiden:

Ein Release kann auf einer Plattform verfügbar sein, ohne dass dort zusätzlich ein individuell gepflegtes Artist-Profil geführt wird.

Über DistroKid werden Veröffentlichungen an zahlreiche Streamingplattformen und Stores ausgeliefert. Aktiv verwalte ich jedoch nur die Plattformen, bei denen ein entsprechender Künstlerzugang sinnvoll verfügbar ist und die für Katsubō Stories praktisch relevant sind. Dazu gehören beispielsweise:

Spotify for Artists · Apple Music for Artists · Amazon Music for Artists · TIDAL Artist Home · Deezer for Creators · YouTube Studio mit Official Artist Channel

Diese Portale erfüllen nicht alle dieselbe Aufgabe. Über Spotify for Artists können beispielsweise Künstlerprofil, Veröffentlichungen, Analytics und zusätzliche Inhalte wie Canvas verwaltet beziehungsweise kontrolliert werden. Spotify beschreibt das Portal selbst als zentrale Umgebung für Profilpflege, Veröffentlichungen und Performance-Daten. (Spotify for Artists)

Apple Music for Artists dient unter anderem dazu, das Künstlerprofil zu verwalten, Veröffentlichungen zu beobachten und Einblicke in die Performance auf Apple Music, iTunes und Shazam zu erhalten. (Apple Music for Artists)

Über Amazon Music for Artists können Künstlerprofile, Publikumsdaten und weitere Funktionen rund um die eigene Präsenz auf Amazon Music verwaltet werden. (Amazon Music for Artists (EN))

Mit TIDAL Artist Home lassen sich TIDAL-Künstlerprofile verwalten. (High Fidelity Music Streaming)

Deezer for Creators bietet Künstlern Zugriff auf Profilpflege und Analytics. Unter anderem können Profilbild, Biografie und Social-Media-Verbindungen verwaltet werden. (DistroKid Hilfezentrum)

Bei YouTube erfolgt die Künstlerverwaltung über YouTube Studio und – sofern eingerichtet – den Official Artist Channel. Dort können unter anderem Veröffentlichungen, Kanalinhalte und Analytics for Artists zusammengeführt werden. (Google Hilfe)

Für meinen Workflow bedeutet das:

Distribution → Release erscheint auf Plattformen → ausgewählte Artist-Portale kontrollieren → Profil und Darstellung pflegen → Statistiken beobachten → bei Bedarf korrigieren

Ich prüfe dabei beispielsweise:

Artist-Zuordnung · Profilbild · Biografie · Release-Darstellung · Diskografie · Links · verfügbare Zusatzfunktionen · Statistiken und erkennbare Abweichungen

Nicht jede Plattform erlaubt dieselben Änderungen. Manche Bereiche können direkt über das Artist-Portal gepflegt werden. Andere Informationen stammen aus der Distribution oder müssen über einen Supportprozess korrigiert werden. Auch deshalb behandle ich die Plattformen nicht als identische Kopien voneinander. Jede Plattform hat ihre eigene Logik. Gleichzeitig wäre es weder sinnvoll noch realistisch, jede belieferte Plattform aktiv im selben Umfang zu pflegen. Einige Musikdienste sind in bestimmten Regionen deutlich relevanter als im DACH-Raum. Andere bieten keinen für meinen Workflow sinnvollen oder zugänglichen Künstlerbereich. Wieder andere erhalten den Release korrekt über die Distribution, ohne dass zusätzliche Profilpflege notwendig ist. Deshalb konzentriere ich die aktive Verwaltung auf eine ausgewählte Gruppe von Plattformen. Die anderen bleiben trotzdem Teil der Distribution.

Reichweite und aktive Pflege sind damit zwei unterschiedliche Ebenen.

Die Artist-Portale liefern außerdem Informationen zurück in den Workflow. Streams, Aufrufe, Publikum, Regionen oder andere verfügbare Kennzahlen können Hinweise darauf geben, wie Veröffentlichungen nach ihrem Erscheinen tatsächlich genutzt werden. Diese Daten bestimmen jedoch nicht automatisch die kreative Richtung. Sie sind eine zusätzliche Beobachtungsebene.

veröffentlichen → beobachten → einordnen → Erkenntnisse für spätere Entscheidungen mitnehmen

Die Plattformpflege endet deshalb nicht bei der Einrichtung eines Künstlerprofils. Mit jeder Veröffentlichung wächst die Diskografie weiter. Neue Releases müssen kontrolliert, bestehende Profile aktuell gehalten und Änderungen oder Probleme gegebenenfalls nachverfolgt werden. Die Distribution bringt die Musik auf die Plattformen. Die Artist-Portale helfen mir anschließend dabei, ausgewählte Teile dieser öffentlichen Präsenz zu kontrollieren, zu pflegen und besser zu verstehen.

 

Webseite & Veröffentlichung · Bandzoogle · katsubostories.com

Die Webseite übernimmt innerhalb von Katsubō Stories eine andere Funktion als Streamingplattformen, Artist-Portale oder Social Media. Auf einer Musikplattform steht zunächst der Release im Mittelpunkt. Auf katsubostories.com können dagegen unterschiedliche Ebenen zusammengeführt werden:

Stories · Musik · Figuren · Veröffentlichungen · Podcast · Hintergrundinformationen · Insights · externe Plattformen

Dadurch wird die Webseite zu einem zentralen Ort innerhalb des Projekts. Bandzoogle dient dabei als technische Grundlage für die aktuelle Website. Über Bandzoogle werden Seiten angelegt, Inhalte strukturiert, Navigation gepflegt, Links gesetzt und unterschiedliche Bereiche von Katsubō Stories miteinander verbunden. Die Plattform gibt dabei einen bestimmten technischen Rahmen vor. Einzelne Inhalte werden über vorhandene Bausteine aufgebaut. Diese Bausteine bestimmen teilweise, wie Texte, Buttons, Abstände oder Seitenstrukturen dargestellt werden können. Deshalb entsteht die Webseite immer aus zwei Ebenen:

inhaltliche Struktur → technische Möglichkeiten des Website-Systems

Nicht jede gewünschte Gestaltung lässt sich innerhalb eines Baukastens exakt so umsetzen, wie sie ursprünglich gedacht war. Dann muss entschieden werden, welche Lösung innerhalb des vorhandenen Systems sinnvoll funktioniert, ohne die inhaltliche Struktur unnötig zu verändern. Die Webseite verbindet Inhalte, die an anderen Stellen getrennt erscheinen. Ein Song kann auf einer Streamingplattform für sich stehen. Auf katsubostories.com kann derselbe Release wieder mit seiner Story, weiteren Kapiteln, Podcast-Inhalten oder zusätzlichen Hintergrundinformationen verbunden werden. Dadurch entsteht ein anderer Kontext. Die Webseite beantwortet nicht nur die Frage: Was wurde veröffentlicht? Sondern zunehmend auch: Wie gehört dieser Inhalt zum größeren Projekt? Ein möglicher Ablauf ist:

Story oder Release vorbereiten → passende Webseite oder Unterseite auswählen → Inhalt einordnen → Links und Verbindungen ergänzen → veröffentlichen → Darstellung kontrollieren

Auch veröffentlichte Webseiteninhalte brauchen Pflege. Links können sich ändern. Neue Releases müssen ergänzt werden. Navigationen entwickeln sich weiter. Bestehende Inhalte können neue Verbindungen erhalten. Und manche Bereiche müssen angepasst werden, wenn sich das Projekt selbst weiterentwickelt. Deshalb ist die Webseite kein einmal fertiggestelltes Archiv. Sie wächst mit Katsubō Stories. Ein Beispiel dafür ist der Bereich Insights. Dort richtet sich der Blick bewusst hinter das sichtbare Ergebnis. Der Bereich macht Teile des Entwicklungsprozesses sichtbar – beispielsweise durch die Creative Engine, Reflexionen, Kritik sowie Tools und Systeme. Damit bekommt die Webseite neben ihrer Funktion als Projektpräsentation eine zweite Aufgabe: Sie dokumentiert, wie Katsubō Stories entwickelt, hinterfragt und weitergeführt wird.

Gerade dadurch unterscheidet sich katsubostories.com von einem reinen Musikprofil. Ein Streamingdienst zeigt vor allem das fertige Ergebnis. Die Webseite kann zusätzlich zeigen, wie Storytelling, Musik, Visuals, Distribution, technische Arbeit und Weiterentwicklung zusammengehören. Bandzoogle ist dabei das aktuelle Werkzeug – die Webseite selbst ist das eigentliche System. Das ist eine wichtige Unterscheidung. Wenn sich das technische Werkzeug später verändert, sollen die grundlegende Struktur, Inhalte und Beziehungen des Projekts trotzdem erhalten bleiben können. Die Aufgabe lautet deshalb nicht: eine Bandzoogle-Seite bauen. Sondern: eine digitale Struktur für Katsubō Stories aufbauen, die derzeit mit Bandzoogle umgesetzt wird. So bleibt auch dieser Teil des Workflows unabhängig vom einzelnen Werkzeug gedacht. Die Webseite ist damit der Ort, an dem viele getrennte Ergebnisse wieder zu einem zusammenhängenden Projekt werden.

 

Social Media · Instagram · Facebook · TikTok · YouTube

Social Media übernimmt innerhalb von Katsubō Stories vor allem die Aufgabe, bereits entwickelte Inhalte in kürzere und plattformgerechte Formen zu übersetzen. Die Grundlage entsteht normalerweise vorher:

Story → Musik → Visuals → Release → daraus abgeleitete Social-Media-Inhalte

Dadurch beginnt die Arbeit nicht für jeden Post wieder bei null. Ein Cover kann als Standbild verwendet werden. Eine kurze visuelle Sequenz kann mit Musik verbunden werden. Ein Moment aus einer Story kann als Einstieg dienen. Ein veröffentlichter Song kann über einen kurzen Ausschnitt erneut sichtbar oder hörbar werden. Je nach Plattform entstehen daraus beispielsweise:

Reels · Stories · Shorts · kurze Videos · Standbilder · Textbeiträge · Links zu Musik, Podcast oder Webseite

Dabei erfüllen Instagram, Facebook, TikTok und YouTube nicht automatisch dieselbe Aufgabe. Auch wenn derselbe inhaltliche Kern verwendet wird, können Format, Länge, Bildausschnitt, Textmenge oder Art der Präsentation unterschiedlich sein. Ein vertikales Kurzvideo funktioniert anders als ein Standbild. Eine Story erfüllt eine andere Funktion als ein dauerhaft sichtbarer Beitrag. Ein YouTube Short kann anders eingesetzt werden als ein Facebook-Post.

Der Ablauf lautet nicht: einen Inhalt erstellen → überall identisch veröffentlichen

Sondern: bestehenden Projektinhalt auswählen → Plattform und Format bestimmen → anpassen → veröffentlichen → Darstellung kontrollieren

Der Projektkern bleibt gleich. Die Form verändert sich. Das ist für Katsubō Stories besonders wichtig. Ein kurzer Social-Media-Inhalt muss nicht versuchen, die vollständige Story zu erzählen. Oft reicht ein einzelner Moment: ein Blick, eine Zeile, ein Bild, ein kurzer Ausschnitt aus der Musik, eine Bewegung, eine Frage. Social Media kann dadurch zum Einstiegspunkt werden. Wer über einen kurzen Clip oder ein Bild auf Katsubō Stories stößt, kann von dort weiter zur Musik, Webseite, Story oder zum Podcast gelangen. Damit soll Social Media nicht die vollständige Projektwelt ersetzen. Es öffnet eine Tür zu ihr. Auch nach der Veröffentlichung gehört Kontrolle zum Workflow. Ich prüfe unter anderem:

Darstellung · Format · Bildausschnitt · Ton · Text · Link · Zuordnung · Erreichbarkeit des vorgesehenen Ziels

Ein Beitrag kann technisch veröffentlicht sein und trotzdem nicht richtig funktionieren – beispielsweise wenn ein Link fehlt, ein Format ungünstig dargestellt wird oder die Verbindung zum eigentlichen Inhalt nicht erkennbar ist. Deshalb bleibt auch hier die bekannte Rückkopplung bestehen:

vorbereiten → anpassen → veröffentlichen → kontrollieren → gegebenenfalls korrigieren

Nicht jede Plattform muss dabei identisch oder mit derselben Intensität gepflegt werden. Reichweite, verfügbare Funktionen und tatsächliche Nutzung können sich verändern. Deshalb kann sich auch die Gewichtung einzelner Kanäle im Laufe des Projekts verschieben. Entscheidend bleibt nicht, überall möglichst viel zu veröffentlichen. Entscheidend ist, dass die verwendeten Kanäle sinnvoll mit dem restlichen Katsubō-Stories-System verbunden sind. Social Media erzeugt damit nicht die Geschichte. Es übersetzt bereits entwickelte Teile der Geschichte in kurze Zugänge, über die Menschen das größere Projekt entdecken können.

 

Technische Entwicklung & Workflows · Codex (OpenAI)

Codex übernimmt innerhalb von Katsubō Stories eine andere Rolle als die Werkzeuge für Story, Musik oder visuelle Gestaltung. Hier geht es stärker um technische Strukturen, Dateien, Webseiten, wiederkehrende Abläufe und die Frage, wie aus einzelnen manuellen Arbeitsschritten ein nachvollziehbarer Workflow entstehen kann. Codex wird von OpenAI als agentisches Werkzeug für Softwareentwicklung und zunehmend auch für weitergehende Arbeitsabläufe angeboten. Es kann unter anderem mit Code, Dateien, Entwicklungsumgebungen und länger laufenden Aufgaben arbeiten und ist in ChatGPT sowie in weiteren Entwicklungsumgebungen verfügbar. (OpenAI) Für Katsubō Stories nutze ich diese Möglichkeiten vor allem dort, wo kreative Inhalte bereits existieren und anschließend technisch organisiert, verbunden oder weiterentwickelt werden müssen. Dazu können beispielsweise gehören:

Webseitenstruktur · Dateien und Ordner · technische Dokumentation · wiederkehrende Arbeitsschritte · Datenverarbeitung · Prüfungen · kleinere Werkzeuge · Automatisierungen · Entwicklung einer eigenen Webseite

Der Unterschied zu einem rein kreativen Werkzeug ist dabei wichtig. Codex soll nicht entscheiden, welche Story erzählt wird oder welche emotionale Richtung ein Kapitel bekommt. Es arbeitet auf einer anderen Ebene:

vorhandene Entscheidung → technische Aufgabe → Umsetzung → Prüfung → gegebenenfalls Korrektur

Ein Beispiel ist die Webseite. Aktuell wird katsubostories.com mit Bandzoogle umgesetzt. Gleichzeitig kann langfristig der Wunsch entstehen, bestimmte Strukturen unabhängiger von einem Baukastensystem zu entwickeln. Dann kann Codex dabei helfen, technische Konzepte zu entwickeln, Seitenstrukturen aufzubauen, Code zu erstellen, bestehende Dateien zu prüfen und Veränderungen schrittweise umzusetzen. Damit entsteht eine Verbindung zwischen:

kreativer Projektstruktur → technischer Architektur → funktionierender Umsetzung

Auch Organisation kann Teil der technischen Entwicklung werden. Mit jeder Story entstehen Texte, Musikdateien, Bilder, Metadaten, Veröffentlichungsinformationen und weitere Projektstände. Wenn solche Informationen nur manuell an vielen unterschiedlichen Stellen gepflegt werden, wächst mit dem Projekt auch die Wahrscheinlichkeit von Fehlern, Doppelarbeit oder verlorenen Zusammenhängen. 

Deshalb interessiert mich nicht nur die Frage: Was kann automatisiert werden? Sondern zuerst: Was sollte überhaupt standardisiert werden?

Nicht jede Aufgabe eignet sich dafür. Eine emotionale Entscheidung über eine Story sollte nicht einfach automatisiert werden. Eine wiederkehrende Dateistruktur, eine Prüfung von Metadaten, eine Statusübersicht oder ein klar definierter technischer Ablauf dagegen kann stärker systematisiert werden. Dadurch entsteht eine wichtige Trennung:

kreative Entscheidung → individuell · wiederkehrender Prozess → strukturierbar · technische Routine → teilweise automatisierbar · Ergebnis → erneut prüfen

Codex kann solche Prozesse unterstützen, aber auch hier bleibt Kontrolle notwendig. Eine technisch funktionierende Lösung ist nicht automatisch die richtige Lösung für das Projekt. Code kann funktionieren und trotzdem eine falsche Struktur erzeugen. Eine Automation kann Zeit sparen und gleichzeitig einen Fehler hundertfach wiederholen. Deshalb gehört auch hier die Rückkopplung zum Workflow:

Aufgabe definieren → Codex einsetzen → Ergebnis prüfen → testen → korrigieren → erst danach übernehmen

OpenAI beschreibt Codex inzwischen ausdrücklich auch für länger laufende Aufgaben, parallele Agenten und wiederkehrende Arbeitsabläufe. Gerade deshalb wird die menschliche Kontrolle nicht weniger wichtig, sondern verändert ihre Form: weniger jeden einzelnen technischen Schritt selbst ausführen, dafür stärker Anforderungen definieren, Ergebnisse prüfen und Entscheidungen freigeben. (OpenAI)

Automatisierung bedeutet deshalb für Katsubō Stories nicht, den kreativen Prozess abzugeben.

Sie bedeutet, wiederkehrende technische Arbeit dort zu vereinfachen, wo dadurch mehr Zeit für Story, Musik, visuelle Entwicklung und Entscheidungen entsteht. Das langfristige Ziel ist kein vollständig automatisiertes Projekt. Das Ziel ist ein System, in dem klar erkennbar bleibt: Was muss ein Mensch entscheiden? Was kann ein Werkzeug vorbereiten? Was kann ein technischer Workflow wiederholen? Und an welcher Stelle muss das Ergebnis erneut kontrolliert werden?

Codex verbindet damit die Creative Engine mit ihrer technischen Weiterentwicklung. Es hilft dabei, aus einzelnen Arbeitsabläufen Strukturen zu entwickeln, die später erneut verwendet, erweitert oder teilweise automatisiert werden können. Das Werkzeug kann dabei wechseln. Die grundlegende Aufgabe bleibt: Technik soll den kreativen Prozess tragen – nicht bestimmen.

 

Wie die Werkzeuge zusammenarbeiten

Die einzelnen Werkzeuge erfüllen unterschiedliche Aufgaben. Erst im Zusammenspiel entsteht daraus ein vollständiger Workflow. Ein möglicher Weg durch Katsubō Stories kann beispielsweise so aussehen:

Idee → ChatGPT → Story & Struktur → Suno → Musikvarianten → ChatGPT / Leonardo.Ai → visuelle Umsetzung → Gemini Notebook → Podcast-Aufbereitung → Spotify for Creators → Podcast-Veröffentlichung → DistroKid → Musikdistribution → Artist-Portale → Profilpflege & Kontrolle → Bandzoogle / katsubostories.com → Projektverknüpfung → Social Media → weitere Zugänge → Codex → technische Weiterentwicklung & Automatisierung

Dieser Ablauf ist jedoch keine starre Kette. Nicht jede Story benötigt jeden Schritt in derselben Reihenfolge. Manche Bereiche laufen parallel. Andere führen zurück zu einer früheren Entscheidung. Ein visuelles Ergebnis kann beispielsweise eine neue Storyfrage auslösen. Eine Plattformmeldung kann eine Korrektur der Metadaten notwendig machen. Eine Podcast-Ausarbeitung kann zeigen, dass ein Zusammenhang in der Story noch nicht klar genug formuliert wurde. Eine technische Verbesserung kann wiederum beeinflussen, wie Inhalte später organisiert oder veröffentlicht werden. Dadurch entsteht kein einfacher Produktionsweg. Es entsteht ein System aus Rückkopplungen.

 

Werkzeuge erzeugen Ergebnisse – Entscheidungen verbinden sie

Der wichtigste Teil des Systems liegt deshalb nicht in der Anzahl der verwendeten Programme. Er liegt in den Übergängen zwischen ihnen. Eine Storybeschreibung muss so vorbereitet sein, dass daraus eine musikalische Richtung entstehen kann. Eine finale Audiodatei muss eindeutig einem Release zugeordnet werden. Ein Cover muss zur richtigen Story und zum richtigen Titel gehören. Eine Podcast-Folge muss auf dem richtigen Quellenmaterial basieren. Eine Veröffentlichung muss nach der Distribution wieder kontrolliert werden. Ein Social-Media-Inhalt muss zu dem Ziel führen, das vorgesehen war. Und eine technische Automation muss genau wissen, welche Aufgabe sie wiederholen darf – und welche Entscheidung bewusst offen bleiben muss. Gerade diese Übergänge sind häufig die Stellen, an denen Fehler entstehen können. Deshalb gehört ihre Kontrolle zum Workflow.

 

Human-led · AI-supported

Katsubō Stories ist ein KI-unterstütztes Kreativprojekt. Das bedeutet jedoch nicht, dass KI den gesamten Prozess übernimmt. Die Werkzeuge helfen beim Strukturieren, Entwickeln, Erzeugen von Varianten, technischen Umsetzen und Organisieren. Die kreative Richtung, Auswahl und Verantwortung bleiben beim Menschen. Ich entscheide: welche Idee weiterentwickelt wird, welche Geschichte erzählt wird, welcher Text zur Figur passt, welche musikalische Variante die richtige Wirkung trägt, welches Bild zur Szene gehört, welche Veröffentlichung freigegeben wird, welcher Fehler korrigiert werden muss, welcher Prozess automatisiert werden darf

Damit entsteht eine klare Rollenverteilung:

Mensch → Richtung · Bedeutung · Auswahl · Verantwortung · KI → Unterstützung · Varianten · Strukturierung · Umsetzungsmöglichkeiten · Plattformen → Veröffentlichung · Distribution · Verwaltung · Automatisierung → wiederkehrende technische Abläufe

 

Automatisieren, ohne den Kern zu verlieren

Mit zunehmender Größe des Projekts wird Automatisierung wichtiger. Nicht deshalb, weil möglichst viel ohne menschliche Beteiligung passieren soll. Sondern weil wiederkehrende technische Aufgaben Zeit benötigen, die an anderer Stelle für kreative Arbeit gebraucht wird. Mögliche Bereiche dafür sind beispielsweise:

Dateiorganisation · Statusübersichten · Metadatenvorbereitung · wiederkehrende Prüfungen · Veröffentlichungsvorbereitung · Linkkontrollen · technische Dokumentation · strukturierte Datenübertragung

Andere Bereiche bleiben bewusst individuell:

Storyidee · emotionale Richtung · Figurenentwicklung · Interpretation · Auswahl einer finalen Musikversion · visuelle Entscheidung · Veröffentlichung

Die Grenze zwischen beiden Bereichen ist nicht unveränderlich. Mit jedem neuen Workflow kann geprüft werden: Was wiederholt sich? Was verursacht unnötige Arbeit? Wo entstehen Fehler? Was lässt sich standardisieren? Und wo würde Automatisierung mehr verlieren als gewinnen?

 

Das System entwickelt sich weiter

Die heute verwendeten Werkzeuge werden nicht zwangsläufig dieselben bleiben. Produkte verändern sich. Funktionen werden erweitert. Plattformen verschwinden oder entstehen neu. Neue technische Möglichkeiten kommen hinzu. Deshalb ist das Ziel nicht, Katsubō Stories dauerhaft an eine bestimmte Software zu binden. Wichtiger ist, die Aufgaben hinter den Werkzeugen zu verstehen. Wenn ein Tool später ersetzt wird, sollte klar bleiben: Welche Aufgabe hatte es? Welche Daten oder Inhalte hat es übernommen? Was kam vorher? Was muss danach passieren? Damit bleibt der Workflow auch dann nachvollziehbar, wenn sich einzelne Werkzeuge verändern. Das Werkzeug kann wechseln. Der Prozess bleibt verständlich.

 

Ergebnis

Tools & Systeme zeigt deshalb nicht einfach eine Liste der Programme, die bei Katsubō Stories verwendet werden. Der Bereich dokumentiert, wie unterschiedliche Werkzeuge miteinander verbunden werden, welche Aufgaben sie übernehmen und an welchen Stellen menschliche Entscheidungen notwendig bleiben.

ChatGPT · Suno · Leonardo.Ai · Gemini Notebook · Spotify for Creators · DistroKid · Artist-Portale · Bandzoogle · Social Media · Codex ergeben allein noch kein System.

Erst durch: Aufgabe → Übergabe → Prüfung → Entscheidung → nächster Schritt entsteht ein reproduzierbarer Workflow. Und genau dort schließt sich die Verbindung zur Creative Engine.

Die Creative Engine zeigt, wie Katsubō Stories entsteht.

Tools & Systeme zeigt, womit dieser Prozess umgesetzt, verbunden und weiterentwickelt wird. Beides gehört zusammen. Technik schafft Möglichkeiten. Struktur macht sie nutzbar. Die kreative Entscheidung gibt ihnen Richtung.