Hi everyone, in many conversations with people from multiple nodes in the Toplap community, the Toplap Manifesto is often brought up both in positive and negative terms. As @yaxu pointed out in a discussion a couple of days ago, the Manifesto is supposed to be a draft, but in the last 10 years it has been barely ever modified. Considering how the practice evolved in recent years and how the community has been growing I think it would be great if we could spend some time redrafting and updating this document as a community.
‘Original’ TOPLAP draft manifesto (with focus on music performance)
Give us access to the performer’s mind, to the whole human instrument.
Obscurantism is dangerous. Show us your screens.
Programs are instruments that can change themselves
The program is to be transcended - Artificial language is the way.
Code should be seen as well as heard, underlying algorithms viewed as well as their visual outcome.
Live coding is not about tools. Algorithms are thoughts. Chainsaws are tools. That’s why algorithms are sometimes harder to notice than chainsaws.
We recognise continuums of interaction and profundity, but prefer:
Insight into algorithms
The skillful extemporisation of algorithm as an expressive/impressive display of mental dexterity
No backup (minidisc, DVD, safety net computer)
We acknowledge that:
It is not necessary for a lay audience to understand the code to appreciate it, much as it is not necessary to know how to play guitar in order to appreciate watching a guitar performance.
Live coding may be accompanied by an impressive display of manual dexterity and the glorification of the typing interface.
Performance involves continuums of interaction, covering perhaps the scope of controls with respect to the parameter space of the artwork, or gestural content, particularly directness of expressive detail. Whilst the traditional haptic rate timing deviations of expressivity in instrumental music are not approximated in code, why repeat the past? No doubt the writing of code and expression of thought will develop its own nuances and customs.
Performances and events closely meeting these manifesto conditions may apply for TOPLAP approval and seal.
Hacking Choreography draft manifesto
By Kate Sicchio
The code allows the audience to view the choreographer and the performer’s mind, process and interpretations. Not just their bodies.
Code is visible on stage to the audience, not just performers.
The dancer always has the ability to change the program, ignore the program, or subvert the program.
Choreography transcends dance. Artificial language is one way.
Code is seen as well as the visual outcome of the choreography.
Dance technique is a tool. Choreography is thought and sometimes harder to notice than dance technique.
We recognise continuums of interaction and profundity, but prefer:
Algorithms are insight into the choreography.
The decision making process of the dancer is on display as part of the choreography.
The show must go on. If there is no score the dancer creates the score. But it is still generated in the performance.
We acknowledge that:
It is not necessary to know the choreographic score to appreciate a dance.
The live coding of dance may be accompanied by typing or other forms of gesture to convey the movement choices. This writing of code is not the dance itself but a way of expressing choreographic thought.
Here are a couple of initial thoughts and personal “pain points” of mine:
“Live coding may be accompanied by an impressive display of manual dexterity and the glorification of the typing interface.” → I know there is a may, but way to often I’ve heard people read this as a must and I fell rather conflicted about this whole sentence as it feels kind of like trying to gatekeep people who are either not in possession of “impressive manual dexterity” and/or using interfaces that are not based entirely (or partially) on typing (ex. visual programming languages such as PD or max/msp). Therefore I’d be happy to tone down, rephrase or remove completely this sentence, if possible.
“Performances and events closely meeting these manifesto conditions may apply for TOPLAP approval and seal.” → makes me feel like as if there was some kind of strict hierarchy / application process to organize events, create new nodes or get involved with the community in general. This sentence, like the one before, also feels like to me it is not representative of the status of the community as it is today (very open, flat and self-organized) and would like to tone it down or remove entirely. I would like people to be encouraged to organize more events and create nodes and not be worried about “closely meeting these manifesto conditions” as it is supposed to be a living document and not a law.
As pointed out in the title, the Manifesto originally was mostly focused around music creation and @sicchio later integrated the Hacking Choreography Manifesto within it. Should we maybe try to do the same to include also the visual side of things (either as a separate section or removing/updating music specific references to make it more inclusive)? I’m involved mostly in the music side of things personally, but would like to know the opinion of visualists and beyond regarding this.
I’d love to hear your thoughts about this and see if we can come up with a better Manifesto Draft and hopefully we can make it more representative of our current community, more inclusive and more encouraging for outsiders to get involved.
I always considered the OG Toplap Manifesto as being an humorous imitation of various artistic manifestos from the XXth century written using a somewhat emphatic tone for the sake of the joke. Still, in between the lines, there are some nice statements and ideas worth to be kept: references to the “hacker ethic”, to open-source practices, the idea of code being a language/communication that testify about the musician’s intentions, etc… I find the manifesto quite rich and concise. I agree that it could be updated though. Live coding has changed quite a lot. I think that it is important to keep part of the same spirit in the new one if we should bake a new one!
@Leofltt: there is a pun in the manifesto, that makes the whole thing about virtuosity and the typing interface more interesting than it looks. impressive display of mental dexterity <-> impressive display of manual dexterity. I don’t know if it is intentional, but I always found it fascinating because it implies that typing could be related to the ability of expressing musical thoughts, that thinking and typing are two sides of a same coin. I would be happy to gather your thoughts about it.
Concerning the second point, I thought that it was a joke. People are live coding anyways, they don’t pay attention to the TOPLAP rules that much. The manifesto pretends that there are corporate guidelines of some sort. The whole Sonic Pi community for instance is rather disconnected from the TOPLAP world (imo), and they are live coding happily. I agree that the tone could be updated.
Visualists also have their own tradition of live coding, which is quite rich, with ramifications in the demoscene, etc… I believe that we are all related by something more general that I sometimes coin as a love for “systematic art” (neologism…): art that deals with live systems, with systems that keep running, that can be interacted with through a set of rules, etc…
I wonder how the conversation could take place in order to include everyone ideas. Live coding means so many different things for so many people nowadays. It is a technique, a performance based art practice, a general approach to speaking with your computer, to approach music-making, etc… I love watching all the directions that it is taking. It almost looks like it is slowly engulfing the whole range of digital arts and computer music.
My concerns stemmed from conversations in which people took the manifesto way too seriously and did not see it as a joke, therefore would be nice to be upfront about it to steer clear of possible misunderstandings.
Not sure what’s the best way to include everyone, but I wanted to start a conversation in a place that is as public as possible and am trying to share it in other places where I know there’s a bunch of live coders like discords and telegram channels so that it can have as much visibility as it can. I hope more people will follow and try to include the voices of anyone they know who might not be aware of this already.
I do agree that live coding is slowly getting integrated in many many different aspects of digital arts and that’s why I would love if there could be a simple, streamlined and clear document that can help curious people and newcomers understand a bit about the practice.
Maybe, like Alex suggested, it could be good to make a new one from scratch while also preserving the original spirit behind the OG one (as you also pointed out) and the references to the ethics, intents and processes of the craft. It could be even more coincise and even more rich, while also being more general and inclusive, allowing for room for future evolutions of the practice in any direction it may go.
I think there is a problem with live coding being viewed as a genre of music instead of a way of thinking about programming/performance.
Live coding to me means changing the structure of an algorithm as it runs instead of just changing some parameters of the algorithm. Whether the parameter is changed with a fader or by changing it with a keyboard I don’t think it makes a difference.
To expect a live coding performance to use only this logic and create a system from scratch is counterproductive to me. In a performance there are a thousand factors decided beforehand (samples, effects, the whole environment, ready-made snippets etc etc) and the idea that the technique of live coding coexists with all the artist’s influences adds many layers of meaning making it much more interesting.
“Live coding may be accompanied by an impressive display of manual dexterity and the glorification of the typing interface.” → I totally agree that this point makes no sense. Even if someone thought that to do a live coding performance one needed to have special mental or manual skills, this would be a general consideration for any kind of performance (i.e., one would think that to play the piano in public one would also need to have these skills). In other words, to do live coding you don’t need any special skills, you just need to practice like anything else.
What it’s really interesting here is seeing how “live coding” means something a little bit different to everyone. We know what it is but it means something different to all of us, I guess. I also agree with everything that has been said so far, in one way or another. But I do not think this approach will get us anywhere really…
What @Nesso said is crucial though: it is not a music genre. And I cannot agree more. Two people using the same language will most probably come up with two completely different piece of music/performance. As well as two people using Hydra will come up with extremely different shaders. So, personally I think we should try to determine what live coding “is not” in order to define exactly what it is. If indeed we need to define what it is, obviously!
First the TOPLAP wiki and manifesto draft was down for a while after a server move. It’s back now! ManifestoDraft - Toplap
Even though the possilibity of having a single manifesto we all agree 100% on is kind of impossible, I still thing it would be interesting to try. Maybe we can come up with statements and alternatives that can sit together even though they are contradictory and ambiguous… and together still give an impression about what live coding is, without defining it exactly.