One of my early requests for Computational Design Workbench had very little to do with drawing software. I wanted the work we had done in conversation to exist somewhere outside ChatGPT.
There were already questions about marks, tone, composition, and the judgment involved in making a drawing. There were also practical decisions about the application we were beginning to build. I asked whether that material could become a project folder, perhaps as Markdown files: something tangible that we could keep working with.
Alongside the software, we needed a record of the thinking behind it.
An experiment I can return to
For the drawing application, the early requirements were concrete: generate vector geometry, work in physical dimensions, save a project, reopen it, and export something the AxiDraw could draw.
Repeatability mattered. If I found an interesting arrangement, saving and reopening the project should preserve it. A random seed could give me variation while allowing me to return to a particular result.
By the first working Square Truchet version, the development reports included checks that saving and reopening preserved the SVG output. That gave us a useful basis for comparison. We could change something deliberately without wondering whether the underlying arrangement had changed on its own.
The foundation documents carry that thinking further. They describe explicit rules, reproducibility, and the ability to inspect how a drawing is constructed. They also make room for restraint, cultural context, and the artist’s judgment.
A reproducible drawing can still leave plenty to decide.
Keeping the questions
The Design Notebook exists as written Markdown entries in the project repository. It holds questions that deserve more attention than a passing mention in a chat.
The first entry, Finished Is Unfinished, asks when additional marks begin to take away more than they contribute. That grew out of our discussion about stopping before a drawing becomes overworked.
The second, Recursive Hatch, considers the spaces between marks as regions where further marks might be placed. That connects directly to my interest in building tone through layers of hatching, while leaving questions about how the process should work.
Neither entry settles the subject. They preserve something we can return to, test, and revise.
The vocabulary document is useful for the same reason. It separates intent from observation and perception: what I want a drawing to do, what can be described about it, and how I interpret what I see. It also gives us language for deliberate changes, white space, and stopping.
Those distinctions help when discussing an experiment. A measurable increase in line density tells us something about the drawing. Whether that change makes it more interesting still requires judgment.
Research that comes back to a mark
The project also has a reading map. Books such as Daniel Shiffman’s The Nature of Code and Carl Lostritto’s Computational Drawing sit within a wider field of artists, tools, and approaches to computational drawing.
The questions I bring to that material are often specific. How does changing the spacing between lines change tone? What happens when another set of marks occupies the spaces? How much information does a drawing need before the eye begins to read form?
A reference might lead to a small experiment, a comparison, or a note to revisit. It does not automatically become another control in the application.
ChatGPT has helped me develop and examine these ideas, while Codex has helped implement and test the software. Written handoffs carry decisions between those conversations and the project files. I bring my drawing experience, the questions I want to explore, and my judgment about the results.
Recording what happened
The project’s physical plotting records include an intentional two-color offset and an example of paper movement during plotting. They offer a useful comparison: a displaced line can be a deliberate choice or an interruption in the process.
The accompanying notes preserve that distinction. These examples document observations; they do not, by themselves, validate an entire generator or prove that a registration workflow is reliable.
The same care belongs in future plans. The written Design Notebook is already part of the project. A larger in-application Research Mode remains a future concept in its handoff document, explicitly outside the original Studio v0.1 scope. Having a document about a possibility does not make it a working feature.
As this journal develops, I want to make room for these questions and tests alongside the drawings. The next post begins with a small set of Truchet tiles and follows what happened when they reached paper.
