@ -4,19 +4,18 @@ This pathway is a collection of readme files from small tools with a focus on op
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.
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.
## (ah ah! less work for us)
## (ah ah! less work for us)
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.
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, this 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.
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.
Possible, contardictory, totally made-up ways to read this interjection
Possible, contardictory, totally made-up ways to read this interjection
- _"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!"_ 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 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"_ 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 C* 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
- _"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
- etc.
- etc.
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?
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?
@ -37,4 +36,26 @@ It is an open-ended tool, that let users upload their own instruments. The readm
[Workbook - Add an instrument](https://git.xpub.nl/supisara/workbook)
[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.
