This meeting took place during the third week of Jon's residency period. At this point he had already produced some speech recognition experiments, sketching out some parts of the speech recognition and resynthesis system he envisioned originally.

This page reports part of the meeting where the Almat team and Jonathan talked about the role of the 'implementation stage' in the process of creating one's own artistic tools.

{function: contextual}

Tools, Implementation, Feedback

{kind: title}

DP
For me it's not yet clear at which point of your residecny here there will be a sort of feedback between you and the artefacts you are creating. I mean, this doesn't have to be decided now, of course. What I'm asking is at which point you think, or you imagine, the algorithm will feed back into your very own practice. I mean, how could it influence your way of speaking or thinking about live coding. What you did is quite literal feedback, in the sense that you are taking the output of a part of the algorithm (the speech recognition part) and feeding it back into what you are saying (resynthesising the words the algorithms previously recognised). For sure, this makes a little bit more evident the materially of the performativy of the algorithm, or the fallacy of the algorithm or whatever. So, what I'm trying to ask is: at which point that will happen in this project. It will happen, because it happens anyway, but I was just thinking that at the present state we're only at the stage of building a tool. And I'm wonderin whether you will let the tool change your action, or your agency.


JR
I mean, I ran into this problem a lot. Well is it a problem? Whatever you want to call it. This idea of leaving the shore for a very long time, like you have this idea and then you need to implement it. And this implementation process is such a long research part in its own, right? And I think about that a lot. How do you manage this balance between tool making and, kind of, the art making. How much of the tool making can be par of the art itself. Like, for example, this kind of non isomorphism between the abstract mathematics and the actual simulated mathematics. And there's something very poetic about that, right? But how do you take that kind of immanent poetics and express it artistically? You know, that's always a huge question. And for me also, when I'm in this process of building, I'm also sort of looking for things that are like "oh, there's something very beautiful about this" or "there's something very provocative about this". Taking this  kind of metaphor, or taking it as an observation. And then, well, how does that find its way into the artwork? I mean, I think it's a really important question. And also you need to keep in mind that, while you are kind of in this swamp or implementation, as of now I haven't even seen anything. As of now I'm just trying to get audio streaming into Python. Getting something out of the library.


DP
You know, it's not a critique. As you said, when you are in the process of implementing and doing things, then you are into it. Sometimes, for me at least, I lose a little bit the context. So I'm just trying to give this outside view to you, in order to give you the possibility to step a little bit back and then look at it.


HHR
Maybe a simple technique is to say that at a certain point you just say: ok, today I will just create stuff. So, you know, just aesthetic output. Whatever is broken, whatever doesn't work yet, it doesn't matter. Let's see which stuff already works and then just do something with that and no fixing or implementation or something like that might help in a way to not get lost into just implementing the things, hoping that at the very very end you have something that you could use. Just use this path as a possibility to say "look, today I'm gonna try out just to throw that stuff at the thing and record what comes out of it, and that's it".


DP
Also in the same direction, I think that it could be dangerous to think it in terms of a tool that serves you to translate your speech into live coding. Because it will absorb a lot of energy. And, as you said, you will miss the point probably in which you actually can step out and work with the tool in a different way, not just as a purely instrumental thing. And I think that's what you wanted to say, I'm just trying to rephrase it for myself also. This is what I did when we started playing at a certain point. When we started playing together I was continuously refining the instrument, and doing it anew basically, modifying it and changing it every time we were playing because I was never happy with it. And this is a process we know, I mean the intention of having a perfect instrument. At a certain point I said "no, I keep it like this, it doesn't matter" and I played with it. And that changed a lot for me, in the relationship with the the instrument I had. Because it was not perfect, but that was good, because I learned to know where its limits are, or the constraints it poses to me. It was a good moment to leave that circle of continuous perfectioning and refining. Because otherwise you are always refining and not playing, not using it.


 

Experimentalstudio meeting, 18_10_2018

Jonathan Reus, Hanns Holger Rutz, David Pirrò

file: JR/audio/181018/ZOOM0001.wav

---
meta: true
persons: [HHR, DP, JR]
kind: conversation
origin: spoken
place: experimental studio
date: 181018

keywords: [tools, implementation, feedback]

---