invite people in
parent
ce1ef55162
commit
d3d9eedaba
@ -1,15 +1,40 @@
|
||||
# How to invite other developers (tmp)
|
||||
|
||||
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 users to expand and re-elaborate what is framed as a starting point, more then a finalized instrument.
|
||||
|
||||
Read these readme as invitation, as provocation, as a way to lure developers in with the promise of full automation, as a way to delegate hard work to other developers, as a way to delegate the creative parts to other artists, as a way to delegate the demanding aspect of writing even more documentation to possibly future coders.
|
||||
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 delegate the creative parts to other artists, as a way to delegate 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)
|
||||
|
||||
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.
|
||||
|
||||
Possible, contardictory, totally made-up ways to read this interjection
|
||||
|
||||
Drw is an app to gather drawings for live visuals. It is organized as a decoupled network of sources and destinations, where different drawing apps and output surfaces can coexhist at the same time. It is simple to plug-in different sources and destinations, 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.
|
||||
- _"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 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
|
||||
- etc.
|
||||
|
||||
[Drw - Setup](https://git.xpub.nl/kamo/drw#setup)
|
||||
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?
|
||||
|
||||
|
||||
|
||||
Seq is a csv sequencer that delegates logic to the user from the very beginning. As the [workbook](https://git.xpub.nl/supisara/workbook) and [drw](https://git.xpub.nl/kamo/drw) can be seen more as a platform than a tool itself. Or maybe a device to stimulate tool-thinking and prototyping. Its readme is not an exaustive explanation of the code, but rather a list of implementation examples, each a way to attune and think to the sequencer in a different way.
|
||||
[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.
|
||||
|
||||
[Seq - an open-end csv sequencer](https://git.xpub.nl/kamo/seq)
|
||||
|
||||
|
||||
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)
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue