{persons: [JR, HHR, DP], date: 25_09_2018}
DP
I would like to talk about the interconnection between live coding and language. I have seen a lot of live coding performances, but I don’t do live coding myself. I often find this kind of performance challenging for the audience, because many times the software that is used - be it SuperCollider, Pure Data, or whatever sound language - steals the scene, or the focus of attention. Despite that the sound is nice, and everything is working, in the end this kind of performance is too little idiosyncratic, it’s too little personal for me. The specific language that is projected on the screen is one that is not necessarily the language of the person that uses it.
HHR
Although often people do use their own little languages in live coding.
DP
Yeah, but that’s a completely different thing. Almost all the people do not. Of course it’s a huge effort to write one's own language but I think, when you do it, that marks an important change. There's a big difference between being used by a language and creating a new language. Either you speak a language or you are spoken by a language, that’s what Agostino said at some point ↗ . And I think this is relevant also with respect to the fact that for you flow, movement and simplicity are important in live coding. In this residence, it could be interesting to see how you could develop a live coding language that reflects these ideas. Because I can share the importance of these ideas, but obviously my understanding of these concepts is very personal, as it is your understading. And that's the interesting part. I think that one needs to develop one's own language for expressing these ideas.
JR
I mean, you have basically very nicely summarized what are the things that I want to do. I’m using SC to write micro-languages right now. Because sc has a very nice pre-processor that you can use, but of course it’s stacked on a class systems and so on. However, between the pre-processor and the class system you can do quite a lot ↗ . But this is happening sort of in tandem with the development of a sonic toolkit as well: building my synthesis libraries, my own GUIs etc. And I want to develop a language that makes sense. The big question is what kind of language can encapsulate these sort of temporal gestures. That’s a big question for me. How can flow transitions be expressed? I keep coming back to story telling: you have these folk story tellers and actually there’s a number of small stories, almost like story cells, and what makes these story tellers so masterful is that they can kind of freely weave these cells together ↗ . So there’s this transitional flow to the story telling as a kind of performance. I’m really curious how language can capture that. Because if you see live coding performances, this is always the hardest thing to do. You go to a live coding performance and that guy spends a lot of time building up a sonic texture or something like that. And then, building a transition is very difficult. Even if you see somebody super virtuosic, like Alex McLean performing with Tidal, still transitions feel like they’re chopped. For me and my music this kind of flow is really important, I’m curious about exploring what kind of notation systems or language, linguistic constructs make sense for creating these transitions and flows.
HHR
I’m almost thinking that you need different kind of language layers, in a way. One for building up textures, another one for creating transitions. Perhaps part of problem is that these languages (SC, Pure Dat) are made for building up structures like textures, but they cannot really express transitions. Maybe to create transitions you need an entirely different way of writing. Maybe really a separate language set, that it's specifically made for moving from one situation to other situations, or something like that.
JR
Yeah. Well, an example is Ron and the pattern library. You have seen how that evolved. It’s great for creating textures, it’s great for creating rhythmic gestures and things like that. But the transitioning between patterns is really difficult.
HHR
Although he has a very interesting technique. He uses all these Pdefs and so on, where patterns are running and he can simoultaneously exchange an entire sub-portion of the system. It is quite interesting. He does the same with some more hybrid structures, like routines. When he was here, I had the impression that ‘live coding’ was there, in a sense. That’s why I wanted to talk about live coding, I was questioning what live coding is. Live coding is not only happening in front of an audience, when people see the screen and you type. Liive coding is also a way to develop pieces in your studio. I thought that's how he composes sounds: he works on a process that is always running. For me, that's really interesting also from a compositional perspective. Not necessarily on stage, or in a performative situation. Maybe you work on a installation or something that doesn’t include code in the end. But you are in the piece while the piece moves you. In a way, you are trying to repair your car while the motor is running. That’s just a side note that comes again from my perspective that relates with the question: how do I actually create a piece? Do I go to the general IDE, and write and compile and run again, and then it creates the piece? Or does this create the structure? Or can I create partial structures and then kind of, while they are there, exchange parts? That has some elements of live coding to it, even though I wouldn’t say that I’m a live coder, because I don’t do that in a performance. But it has this question of the two time layers: of the time in which you create and manipulate things, and the time in which things are made perceivable.
JR
Yeah. I mean, maybe there are two layers there in terms of terminology. We were talking about what live coding is. I think there is a layer of live coding as a genre, and a layer of live coding as a practice. And I think the practice is sort of lateral between all these things. And then the genre precisely that you go to a performance and you expect to see the inside of the thinking of the performer. You see the process. To me, that’s kind of what live coding as a genre is: the process is completely composed. I’ve always thought of live coding performances as a sort of reaction against the ‘laptop music’ tradition, where everything is super opaque, and you have these kind of acousmatic walls. And people always joke: “oh, they are just checking their email”.
HHR
It is partially a reaction, but then my criticism would be that it only works for people who can understand how the code works. If you pick somebody who is used to all kinds of art music, but that has no knowledge of these programming languages, maybe they could say ‘ok, this is kind of interesting, but I also don’t really know what’s happening’. There’s also this kind of question: if live coding achieves a real transparency, or whether there’s another layer of opacity in the end ↗ .
JR
I agree, and it’s even interesting to try to solve that problem. I sometimes doubt it, because I’ve seen performances where languages were created that were specifically meant to be audience readable. And I found them really uninteresting performances, like it becomes almost pedagogical. However I think there is an artistic potential in creating languages which are audience-readable. But I don’t think it has to happen necessarily in this kind of pedagogical way. maybe more in like a theatrical, thinking more about like story telling. I saw a wonderful performance by Justin Bennett, a few years ago. He’s an artist based here in The Hague, who does a lot with field recording. Once he did this wonderful performance where he was literally playing field recordings from his library and he had a text editor open. And he was annotating the field recordings while they were playing. Essentially, like telling an incredibly personal story about his relationships to these sounds, while you would listen to them. It was so beautiful, it was so poetic and I’m just imagining how could live coding may be used in this kind of way. Like to make it very personal, as you were saying, but also to have this sort of.. to tell a story rather than teaching what the processes are.
HHR
So the audience would see him annotating the sounds basically? That’s a beautiful idea. I have not seen something like that, that sounds really beautiful.
JR
Yeah, so simple, beautiful. And it felt like he was typing in a terminal. That was the aesthetic of it. It felt like he was typing in a terminal, but you were kind at the other side of the terminal. So maybe there was a bit of nostalgic chatroom vibe. But it was really nice and I was just thinking how text became that theatrical in the performance. I think that might be something interesting to explore with live coding also: how a text be functional but also narrative, or theatrical. Can it express personal thoughts at the same time of expressing functional operations?
It’s a funny coincidence that in the last couple of weeks I’m also having fun messing around with the pre-processor in SC. I’m using it in tandem with the Document class, that allows you to automate deletion, rewriting and evaluation of pieces of code in the IDE. The idea is to basically build a sort of dictionary that responds to the events passing through the pre-processor, having multiple ‘adaptive’ Ndefs that automatically rewrite or modify themselves according to the code which is evaluated. Originally, it was not meant for live coding but after hearing your discussion, I’m now thinking it could be quite funny to develop it in a sort of performance where I ‘co-write’ with the computer: basically it would mean I would code at the same time with SC itself, and it could happen that while I’m trying to edit a part of code he deletes the whole Ndef I’m working on, or we could find ourself working on the same line of code, or similar stuff. The automatic editing is visually quite captivating to watch, so maybe it could really become a sort of ‘broken live coding’ performance. Maybe also introducing crazy recursions could make the IDE explode at some point :)
{function: comment}
Recently I was reading some Herbert Brün’s writings and I encountered many interesting insights on the topic of language within his theory of ‘anticommunication’.
One of the primary functions of Brün’s compositional praxis was to uncover possibilities for new significance, while opposing the reification of meaning inherent in the acts of recognition and appropriation. He relates this to the relations with musical languages, and he makes a very similar point to Di Scipio when he affirms that ‘language has the tendency to preempt thought’, that is almost the same as to ‘be spoken by a language’. According to this, he affirms that in musical expression a composer can choose to ‘communicate’ by adapting his personal expressions to a pre-existing language. In this case language preempts thought, for one will tend to think within the boundaries of that specific language. The alternative is then to ‘anticommunicate’, that he defines as ‘an attempt at respectfully teaching language to say something’, or to express something through a channel of communication which is not yet available, ‘inventing’ a language for which procedures of encoding and decoding are not yet established. In this case, the communication is thus not direct and the reception of the information contained is delayed. From this presumptions, he derives many interesting thoughts, but what mainly grabbed my attention was which kind of assumptions could we derive if we shift this conception from the domain of musical language to the one of computer music language. I was lately thinking that a computer music language embeds two levels of ‘semiotics’, one which is purely acoustic and concerns the sound production aspects. The other, more intriguing one, is at the level of the interaction between artist and machine: a cml prescribes a well defined way of communicating with the computer. I wonder if it is possible to try to ‘anticommunicate’ at this level of communication, kind of ‘hacking’ the language from within its own structure, to anticommunicate without inventing a new language. I have the feeling this would potentially lead to a sort of ‘broken’ algorithmic relation, which I find really fascinating. With respect to this idea, Brün’s says that “anticommunication is most easily observed, and often can have an almost entertaining quality, if well-known fragments of a linguistic system are composed into a contextual environment in which they try but fail to mean what they always had meant”. I wonder if it’s possible to apply this thought to a computer music language like SC, what would that signify and what the consequences would be?
{function: comment}
Talking about flow and movement, I think a nice way of thinking about transitions is indeed that of exchanging parts, kind of ‘reformulating a running process’. You have multiple cells, or ‘sonic building blocks’, and then you have some procedures to recombine them. It’s quite related to Ron’s approach with patterns, but he was doing permutations in time, while I would be interested in finding ways of doing that at the level of timbre, permutating the structure of a synthesis process so to say. Ndefs are a nice tool to experiment with this, because they assure continuity even when changing part of the synth structure.
{function: comment}
{POZ, 27_09_18}
I don’t know if in the case of live coding it’s really fundamental to understand the code. I mean, for me, the question is more whether performes are able to communicate their act of writing, the interaction with the running machine, the “repairing the motor while the car is running”. If they finds a way of communicating such impression, the actual code and its significance doesn’t really matter. Paradoxically, the most convincing live coding performances I’ve seen are those in which the code wasn’t projected. So from my perspective the question of opacity is more about whether the performer is able or not of transmitting this relation with the machine, rather than making the code understandable ↗ .
Indeed, something I find also interesting is when the code isn’t treated as a language, as something to be “understood”, but rather as a pure visual aesthetic element.
{function: comment}
---
meta: true
persons: [HHR, POZ, DP, JR]
kind: conversation
origin: video call
keywords: [live coding, language, pattern, storytelling, SuperCollider]
---
{hhr, 08-Oct-2018}
It just occurred to me, perhaps it's a bit far fetched, but Édouard Glissant is talking both about (natural) languages and concepts of transparency/opacity in "Poetics of Relation". There are some related thoughts in there, I think, like the question of the malleability of language, that could be relevant to our discussion. I have only skimmed through the book so far, so I shall try to investigate that text for a better understanding.
{function: comment}