This pathway is a collection of readme files from small tools with a focus on open-endedness: where code asks for more code, and invite developers to expand and re-elaborate what is framed as a starting point, more then a finalized outcomes.
Read these readme as an invitation, as a provocation, as a plea to grow multiple stems from the same concept, as generous offering, as a way to share ideas other than code, as a way to lure developers in with the promise of full automation, as a way to delegate hard work to other programmers, as a way to hand over the creative parts to other artists, as a way to pass on the demanding aspect of writing even more documentation to possibly future mantainers, as a way to get people close to code.
Drw is an app to gather drawings for live visuals. During a concert or a performance, the public can draw from their smartphone in realtime. On the other end of the drw server a destination receives the drawings encoded as SVG graphics, and can use them as source material for generating visuals. It is organized as a decoupled network of sources and destinations, where different drawing surfaces and output displays can coexhist at the same time. It is simple to plug-in different ins and outs, and from a wide variety of platforms. The only requirements is websocket communication. One can draw from a web app on their smartphone and send it to a projection, or from different motion sensors to a pen plotter. It's programmed to be a simple and extensible tool, welcoming modifications and interventions from others, as well as hosting others applications sharing the same infrastructure.
In the [Setup](https://git.xpub.nl/kamo/drw#setup) section, a goofy remark introduces some possible platforms to plug into drw. Offering just a barebone (and pretty boring) working example, the readme plays lazy and leave to other developers the implemention of more than half of the codebase.
- _"Ah ah!"_ this was a mere operation of open-end-washing, we had fun developing the concept but for everything else you are on your own _"less work for us"_
- _"Ah ah!"_ ok ok we know that eventually external contribuitions means even more work, that's why we would prefer _"less work for us"_
- _"Ah"_ actually i just realized that an open ended tool without proper support is actually invisible. _"ah!"_ wait, this could probably mean that a really serious and demanding work of documentation regarding the API will be necessary, and here i was going like _"less work for us"_
- _"Ah ah"_ here I am, just pushed yet another commit to a repo that no one will ever open _"!"_ a message from my friend Chae saying: ok i just read the documentation but im stuck at NPM ??? this means there are at least 2 users for this project!! "less work for us" if we join forces
Another detail where to zoom-in is the use of _us_. Why did I wrote like that, even though working on the development on my own? Who are those _us_? An invocation for future maintainers? Displacement of personalities through future timelines? Me and my future selves are a nice and supportive team? Or it's just a cry asking for someone to program with?
[Drw - small app for collaborative drawing](https://git.xpub.nl/kamo/drw)
Seq is a csv sequencer that delegates logic to the user from the very beginning. In the documentation, no distinction is made between user and developer: the user is asked to provide for some runtime logic for the sequencer, implying some necessary coding in order to get something out of the instrument.
As the [workbook](https://git.xpub.nl/supisara/workbook) and [drw](https://git.xpub.nl/kamo/drw), Seq can be seen more as a platform than a tool itself. Or maybe a device to stimulate tool-thinking and prototyping. Or a writing machine for trying out sequencing ideas. The readme is not an exaustive explanation of the code, but rather a list of implementation examples, each a way to attune and think with the sequencer differently. A list that asks for more entries.
The Workbook is a tool to keep track and annotate configurations for synthetizers and other instruments. It was developed together with [Supi](https://supisara.info/) as a surface to facilitate the learning process of sound synthesis. With digital instruments one can easily save presets and load them as necessary, but with analog and modular ones things are more messy than that. Often a sound is the ephemeral combination of knobs turned to a certain degrees and cables connecting sources and destinations together. The programmer familiar with the horrors of spaghetti code will recognize the same irresistible danger in spaghetti patching. Messing with all these handles makes for sure the joy of playing with such instruments, but to remember which configuration generated that specific sound can be tough. The Workbook offers a way to store configuration snapshots by turning knobs and drawing cables.
It is an open-ended tool, that let users upload their own instruments. The readme is far from complete, but a lot of efforts were put to highlight this extensibility. Core of the writing was the workbook as a starting point, and not as a finished product. An invitation for users to get hands-on and fiddle with code with a non-standard and non-perfect attitude to prepare their own SVG instrument panels. A statement that acknowledges the necessity of trial and error in the process of generating a compatible vector file.
[Workbook - Add an instrument](https://git.xpub.nl/supisara/workbook)
How do you invite people to participate in your coding practice? Which kind of doors do you leave ajar for others to sneak in? Feel free to contribute to this pathway by sending a pull request to the [project repo](need to make a repo on gitlab or sourcehut bc on the xpub git external ppl cannot collaborate)!
## Colophon
This pubblication is part of Readme Readers, a network of republished readme files and other pathways through diverse code documentation practices.
This initial snapshot has been curated by [Kamo](https://hub.xpub.nl/soupboat/~kamo/), but is really meant to be an organic process open to modification, branching and other contributions.
Does the existence of headless cms imply the existence of a bodyless cms? Nobody knows. What we do know is that:
- the Workbook has been developed with shared efforts by Supisara Burapachaisri and km0. It takes some inspiration from VCV rack for the way in which interactive panels are generated.
- drw has been developed by km0.
- seq has been developed by km0 in concert with Erica Gargaglione. See [spreadsqueet](https://git.xpub.nl/grgr/spreadsqueet)
- Font
- paper
- repo
- website
## Licence
This work exists because of various degrees of collaborative efforts within the context of XPUB, 2023. Copyleft with a difference: This is a collective work, you are invited to copy, distribute, and modify it under the terms of the CC4r.
