That draft of the simple spec for tape.deck that 6.1 Sol generated is “pretty good.” Not perfect, but pretty good. Some things I would have excluded for initial tighter focus, but also, whatever. Some of it represents a sort intellectual archaeology of how the idea and the process have evolved too, so don’t want to cut too much of that out. But neither do I want to overwhelm potential readers with TMI, which is incredibly easy to do when your workstream involves generative AI as an essential part of your tooling and ideation.

So, I thought a next useful step would be expose another side of those explorations that I’ve done to show some of the ground that has been covered, and what the findings were, so as to bring it all back to the main branch eventually to continue composing pieces of the amalgamated toolbox that tape.deck represents.

Anyway, what follows are simplified wireframes I had ChatGPT do of different key screens within what I imagine one implementation of tape.deck could look or function like:

Story Space view

So this screen visualizes a theoretical corpus – in my case it is EPUB files from a linked narrative multiverse project. And this would be generated after subjecting those files to conversion to plain text formats, and then running my SYMBOL SCAN skill over them to pull out the most important-seeming entities (“symbols”) and associations between them for review and promotion.

This story space view then lets you visualize those various symbols and their connections as linked clusters, which can then be expanded or recombined in other ways in other views.

Registry view

For each symbol node that appears in the story space, there is a corresponding registry entry. This is a record of all known information about a given symbol, including its “attestations” – which books it appears in, what quotes reference it – key links to other symbols, usage rules or restrictions for that symbol.

[Apparently Lucasfilm has a FileMaker database they use for a similar purpose for Star Wars in-universe continuity, which is called The Holocron.]

As the composition process progresses through the workspace, one of the things that gets included in the capsules for any finished “cassette” (to be sent out to renderers or playback environments) is registry slices. That is, one of the key capsules that gets transmitted with cassettes is enough information from the included symbols’ registry entries to allow renderers to faithfully reproduce the underlying cassette’s contents.

Builder view

These next few screens feel a bit jumbled to me, and they have some different tab or section labeling that is inconsistent with each other. But the point this is trying to make is that cassettes can be composed out of nested units: capsules (and sub-capsules), blocks, frames. These can be chained together as sequences, or linked via decision-points for branching narrative outcomes. The above screenshot is intending (I think) to show the ability to arrange and edit capsules, chains, and blocks together in a Builder interface.

Anyway, these are all just initial visualizations and the specifics are not all completely nailed down yet.

Cassette view & preview

Two different views into the same finished cassette, the first showing more the complete package (capsule flow, registry, etc), and the second a more focused view into the specific linear content elements in their arranged final forder:

Focused version:

Rendered outputs view

From the finished cassette, various types of rendered outputs could be produced, either by the creator of the cassette directly themselves, or by third party renderers or playback environments which might read from the cassettes down the road. The most obvious modalities that come to mind for rendered outputs would be text, audio (narration, music, sound effects), video, VR artifacts or scenes, etc.

As I wrote about in my original post about a workflow for using AI in video, each of the generated outputs is pegged to the frame, block, or capsule which it depicts or renders through available media formats. Conceivably, the creator of a cassette (or a cassette’s own automated evidence gate checks) could go through a review queue of generated outputs and approve or reject items which do or do not match the ideal vision represented by the cassette. And then, in those cases, approved artifacts could be included with the cassette as it travels onwards to other generation or playback environments.

Or presumably, from there, the cassette creator could simply output various different complete renders: a finished ebook (or series), a dramatised audio book, a complete video, etc. And then the selected artifacts made available are the only authorized ones by the cassette’s creator, and the underlying cassette does not travel. And they could always come back in a few years and use new technologies to re-render the underlying story structure without having to re-write it.

Anyway, hopefully the visualizations help ground it more!