Hi everyone! I would like to know if some of you ever thought about a topic that I found important for preserving and documenting live-coded performances.
I am currently writing an academic paper about the relation between live-coders and their algorithmic texts (the code of the performance or the source code of their musical system basically). I try to understand how live-coders perceive the text as a tool for thinking, sharing, communicating, or as an opening to an original mode of musical expression. I'm also trying to link some of these points to the old-school philosophy of Unix concerning plain-text or to an attitude that is often found in open-source / hacker-maker communities throughout the internet.
Live-coding is most often about manipulating plain-text; different iterative states of the same text buffer that goes through different transformations as long as the musician is performing. That's one of the most intriguing paradoxes about live-coding as a musical notation: it's a notation that does not last and that is often deleted once the performance ends. Of course, that's not entirely true:
one can record stuff (live-coding captation as video archive).
one can save different files at different cues during the performance.
more complex systems? (state system using Git and other tools like Emacs).
What are your strategies for saving text-files or improvisations that are destined to be transformed, altered, blended, and so on ?
EDIT: oh, and what about keeping track of improvisations involving external instruments, complex audio files, dependancies, etc.. ?
For streamed works, I keep (and share both) the video footage and the final state of the .tidal file
This is pretty inconvenient when it comes to reviewing, luckily I don't tend to
For just testing stuff, particularly stuff that is dependent on software or hardware outside of tidal, I keep copious notes in the .tidal file which is usually named in a relevant fashion (midi_input.tidal)
I've thought about using git as a state system, my idle thoughts at this stage have not extended beyond:
When starting tidal, init a git repo if required, and add the blank file as a commit
On evaluate (successful eval ideally ie no syntax errors) automatically make a new commit
allow keyboard shortcuts to navigate backwards and forwards through commits
This could also potentially be used to replay a performance but there are other factors to consider (logging cps, external tools etc) - I think this could make a useful starting point though.
I'm also conscious that there is/should be(?) a transient component due to the "live" and "improvised" nature of the performance/question, which the git idea above kind of nukes
Thanks for sharing your thoughts! I agree that the tricky part in keeping track of the improvisation process is that there are a lot of things that are not described at all or only in an elusive way in the code of the performance (midi connexions, cps, external state, etc..).
I guess that seing people perform solely with code that is an exhaustive description / representation of their setup is pretty rare nowadays. It makes you wonder what people are really notating using text when live-coding? and what do they share/communicate by projecting their screens?
That's not a new topic at all, lots of people wrote about it already in the past decades, but I think that the question is more relevant than ever today. It is easier, nowadays, to setup an hybrid performance setting involving analog/digital instruments, various sound and data sources, etc.. People are doing it, but where does text / code fits in the equation?
I guess that many people would be tempted to answer by saying that code is one of the traditional mediums for expressing things through algorithms and computation, which is what live-coding is mostly about.
Still, how could we share the output of our personal experiments with code and software in a way that makes it easily accessible and open for anyone to try? (sharing the whole setup of one's performance).
I think I've read some comments from @yaxu on this topic which I'll borrow heavily from below.
I guess there are two types of consumers in a Live coding performance (not unlike any other musical performance tbh) - those that understand the code, and those that don't but both are enjoying/consuming the musical output/performance.
In both instances though, projecting the code is a way for the gap between a performer typing on a laptop and crowd to be lessened - the crowd gets to see (some of) what the performer is actually doing, appreciate the craftmanship more and allow them to more closely engage with the electronic performer.
In many cases, the projection is as much (or moreso) an aesthetic component of the performance - I've noticed that kindohm's projections have morphed to a much more visually pleasing style, but are less informational as a result (having said that, he shares/has shared so much information already)
By using accessible tools (open source software, permissively licensed samples etc), and providing a path or instruction set to make the "glueing" of these components together easier.
I do think about this, and attempt to execute on this in my own way:
I've created a bunch of sample sets that are CC0 licensed, and added them to a number of projects (estuary, gibber, tidal clean-samples rework)
I share my performance code as a snapshot on github
I share my performance as a recorded experience on yt/twitch
I build/maintain a tidal configuration manager for allowing easy setup/maintenance of the components required to make tidal go, eg I'm doing a bunch of work at the moment to add support for the mutable-instruments ugens which require a few fiddly setup pieces
when I use softsynths, they are open source/packaged in standard distros
when I use a daw, they are open source/packaged in standard distros (and the plumbing of these pieces happens in my config manager)
I am well aware of your work for packaging and distributing Tidal along with other components and I think that it is really a great idea. It's a nice way to deal with the fact that information about live coding, live coding setups and techniques is a bit scattered over the internet.
One thing that I would really like to see happening is some kind of community-maintained documentation / wiki / personal page for people to share their experiments with Tidal, SC and so on. Something that would look like a crossover between a wiki page and a personal blog for each contributor. Sharing performance patchs, audio samples if there are some, etc.. One could even think about a way to fetch that documentation from the command line or from a GUI window in a similar fashion to the SC Documentation.
But I agree that it's just pure speculation from my part. Setting up something like this would be incredibly difficult and hard to maintain.
Coming back to the main topic: code projection for aesthetic purpose/ communication of an intent or gesture is an important part of the whole thing I agree.
When watching live-coding performances, you often see people preparing lots of materials, patterns, or trying to streamline their improvisation by pre-writing patterns that can act as guides or as a basis for later modification. They are obviously trying to "keep track" of their improvisation, doing something quite but not completely similar to a musical notation. Maybe we could draw an analogy between that and jazz lead sheets. That's the most obvious way to keep track of time / events through textual notation, and it might be useful for pedagogy / conservation of this form of musical improvisation. Sharing these leadsheets with the possibility for anyone to play them (having the right samples and synths) could be immensely fun and rewarding.
I use tidal with vim as an editor, and by default I save the undo files for my .tidal files to disk; then, I can use undotree to navigate the undo history in case I want to go back to something.
When improvising, I usually also save the code whenever I get to a pattern that I want to remember, then (barring executive dysfunction ) save all the .tidal files in a directory and back it up.
For command line editors such as vim, maybe asciinema could be a nice way to "record" live performances.
Jamie Faye Fenton made a Hydra version that can record and play performances, she presented it in the 5th Hydra meetup. I think you can find it in her Hydra fork. I'll see if I can get the video of the presentation uploaded. We should look into it and see how can we implement it in other languages
) save all the .tidal files in a directory and back it up.