Benoît and the Mandelbrots are a four-piece laptop band spanning the live coding, network group and maybe algorave traditions. They’re based in Karlsruhe in Germany, where you can catch them next week on the 16th November 2012 at nil #2, alongside the mythological Sick Lincoln.
TOPLAP members took part in a distributed interview, where everyone edited a (now frozen) networked document at the same time, either asking questions or answering them, depending on whether they were in the band or not. It worked out nicely, the results are below, maybe the first of a series of TOPLAP interviews?
Q1: How did Benoît and the Mandelbrots get started? [alexm]
[juan] Benoît & the Mandelbrots started (for me) from the frustration with our previous project “Grainface” (with Patrick), which was more “Interface driven”. We’ve got induced into live coding by Julian Rohrhuber and Alberto de Campo, and we decided to make this the underlying concept for our future ensemble. Matthias and Holger were good friends and have shown signs of interest for live performing, so we decided to group, rehearse, and pay 12€ for our first performance… Yes, we payed to play our first gig. [/juan]
[patrick] Juan and I also did a duo live coding performance once. As it wasn’t very successful we thought that more people are less prone crash, so we weren’t really interested in a duo at this moment. Some Mandelbrots Trivia: We almost named the band “Katze Katze Katze”, which means “cat cat cat” in english.
Q2: How important is the preservation of notation between performances for the Mandelbrots? For example, do you actively consider making your work easy to study in the future? [samaaron]
[juan] I wouldn’t say it’s not important, we tried to archive code histories and record lots of rehearsals, but… the recordings turned out to be a better method to control ourselves, to hear again what worked well and what not (to never do it again), but we never analyzed any of our performances again from the code point of view. We do share sometimes code when we practice, but we never do it on our performances or rehearsals. I think we really like that the music just happens for the moment, really improvised almost from scratch (every one has it’s own snippets and recipes) and that’s also a reason we haven’t recorded something yet… there are only live recordings of some performances, but we do enjoy and like the people to be part of a new experience every time. So… we haven’t started a code history library or something. Sorry 🙁 [/juan]
[patrick] When I rehearse privately I sometimes make screen recordings, which are quite a good tool for myself to see my mistakes. I uploaded some of them to YouTube, because some might be interesting for people.
[matthias] I sometimes save code after rehearsals or public performances, especially when I created something interesting from my point of .. listening. But actually I almost never use it afterwards also because of our blank slate approach. I like the idea of presenting a more or less unique or at least non-reproducible piece of electronic music, because it emphasizes the live aspect in a time where we got used to conservation and playback of nearly any kind of music.
Q3: How difficult is the fact that there is no repertoire in what you are doing(I mean in the genre of live coding), so when a performance is sufficient aesthetically enough to be delivered ? Isn’t that an issue or nothing to care about anyways ? [Kostas]
[juan] We don’t see it as a problem actually. With our previous ensemble Grainface, we wanted to play composed pieces, maybe even commission some for us. But we didn’t enjoyed very much playing the same piece over and over again and we weren’t exploiting the capabilities as an ensemble. Once you have the sounds and interfaces you are going to use, you might as well record the piece and play it as a tape piece. I’m not saying the live coded music with the mandelbrots sounds ‘more live’ than other, but at least for us, is a reason to give all we can in a performance, and make the best out of it, also (sometimes) listening to people’s wishes and reactions and giving them satisfaction. Like 80’s synth drums… or more beats to dance to (if they are enjoying it). [/juan]
I know what you mean there is no reason to improvise on the same pieces itself, except you are doing it consciously rather limited by imagination, but somehow wouldn’t make live code spread easily in new people the way other genres are growing for instance with the use of a score, so the code itself may be the passing body of knowledge for instance and will act as a score. [Kostas]
[matthias] First, I’m not sure if I understood the whole question… We never missed a repertoire in the genre of live coding, maybe also just because we never expected a repertoire to exist. We also never try to bring our rehearsal results on stage, they are more an introduction for ourselves to the concert situation. So we also don’t create a repertoire for ourselves.
No, I see your point I meant something different, what I meant is a repertoire to compare or relate with what you do, if you find that important anyways.[kostas]
[matthias] Ah ok. We already knew some live coding examples of aa-cell, powerbooks unplugged, also slub, or thor magnusson with ixiLang, etc. So we didn’t start in an evacuated room but had already some inspirations which then led to our own results. I also think that live coding is just a performance practice and that everybody who actually does live coding, has the potential to redefine the possibilites of it.
Q4: How do you deal with all the groupies? [all n4tural]
[juan] That’s easy. There are none. 😉 Except this girl who threw me her bra, but that wasn’t with the mandelbrots and I was playing the guitar… Actually, there is a “Benoît and the Mandelbrots Groupies e.V.” Group in facebook, if you want to join, you can contact the admin. [/juan]
[patrick] No Groupies that Juan knows of at least 😉
[matthias] obvious question. The live coding community prohibited further contact with them because it would harm their image.
Q5: How do you think live-coding will develop in the future? For the band and for the ‘genre’ in general? [shellyk]
[juan] live coding is the present, I don’t know much about the future, but it is for me, my future for researching the processes in music while I’m still thinking them. I like more the idea of being able to code any kind of music (even electro country!) so, I wouldn’t say the ‘genre’ but the means to achieve a kind of music, and I do think there is still lots to explore and lots of music genres to formalize the basic rules of a given kind of music, so it is recognizable and enjoyable by the audience.[/juan]
[patrick] I don’t consider it a genre and I hope the live coding paradigm can and will be used to create all kind of different styles of music. I think languages that are able to couple tightly with the IDE are very important for the future of live coding, especially programming languages where there is a tight coupling of the running process and position in the source code. This way the process might be able to exchange part of his source code (like in ixi-lang) and the IDE can reflect information state of the process into the source code. (Think something like a = 55, which gets changed somewhere in a process and I can hover over my variable to see in a tool tip that a is now in fact 33. Basically stuff that is done in major Java/C Debuggers in IDEs. Maybe it could be done with Overtone? A good shortcut would be the ability to inline the code of a function from a selected function call. I also hope that younger people start live coding: If I was 15/16 again and there were some good tutorials and some role models to admire I would totally do it! Future of Mandelbrots in 40 years: http://www.youtube.com/watch?v=0nyWbn35e7s
Sorry… ‘genre’ was a bad word choice… I guess I meant the technique or the possibilities of things that can be done with Live-Coding- and also how this may effect that music that is created with it.. [shellyk]
[matthias] For the band I just hope for more concerts in interesting places/occasions. The interesting part of our work will always be the challenge of new situations (maybe also because it fits most to our paradigm of blank slate approach).
[juan (again)] I do think live coding is a very useful technique for discovering new stuff, you can apply it on different levels… visuals, light, etc… it does give you a nice insight into what is happening and how to formulate ideas, abstract an idea into code, and execute it, modify it and get inspired again and again. On a performance situation you make mistakes and sometimes you are driven into making stuff you’ve never did before (if you are not playing the stable card), so it’s a trip to know yourself and get out all your ideas[/juan]
Q6: I had this awkward moment with some colleagues believing that if you do live coding then you must not do anything else like not control in the same time with external controllers and vice versa, do you believe is this distinction important ? like keeping distinctions on stage of what you do, either as live coder or controlled performer, and concerning you guys do you consider of embedding or including any hardware gear for the sake of performance ? [kostas]
[patrick] I think it’s the choice of the artist. If you want to explore pure live coding you should try to perform without controllers, it will open new possibilities!
true, from my experience will create a variety of problems as well, cheers.[kostas]
[patrick] Yeah, I agree! But problems are half of the fun 🙂
oh yeah I refer to problems as research questions [kostas]
[patrick] I saw some approaches (and I also used them) where you can easily use MIDI control values as variables in your live coding, which makes things interesting again: You’re not just playing a pre-built instrument – your building it AND the controls.
“building/modifying the instrument “ I couldn’t agree more, in fact I am working on mapping issues towards the performance and the live application of coding/modifying on the fly, a “problem” is that when you control, and you want/have to modify stuff, which admittedly will explode creatively your hybrid instr. you have to compromise and stop the flow and sit down in a way and inject the text-ed element of code, which is similar to a musician’s changing the page of the score me thinks..or I am pushing the boundaries of traditionalities for my own benefit 🙂
:), how would someone deal with this, or you, and would you found it awkward in a performance ? [kostas]
[juan] we tried using some controllers and using those signals live in the code, but I personally didn’t liked it that much. That takes your hands off the keyboard and makes it difficult to go back again… if you start playing with a filter and making things and then you think, you could actually program it (or automate it) then you take your hands off the controller and this is the moment I don’t like… from performing with the controller back again to formulating your code breaks the smoothness of the performance. An alternative would be to code with one hand while performing with the other. Maybe Mr. Nilson has already done this?[/juan]
Or using a glove, I am not sure that using both mixed techniques of improvisation would be such a big loss, but for the performance sake maybe in some extent will distract the performer alongside the audience. [unsigned edit – kostas?]
[matthias] I agree with Patrick, it is mostly the choice of the artist. There are situations where I don’t see a problem to use the Mouse Axis to control some parameters on the fly, and in the majority of cases where I really enjoy working with algorithms to control the sound. Actually I am working on a concept for a duo with one live coder and one performer on a gestural interface where the program of this gestural interface is live coded (For this approach starting with a blank slate might not be the best one). Then this processes of building and modifying the instrument are again divided on different persons, but have now the capability to happen detached physically and coupled musically at the same time.
Q7. Do you make any explicit effort to communicate your individual virtuosity (vs the virtuosity of the machine) to the audience and if so, how? [samaaron]
[juan] not explicit, we actually think that showing our screens is a good effort for the people, they see a lot of typing and expressions that they try to decode, and in the same way they had to be encoded by us. If they see a relationship between the code and the music they might reveal the ‘virtuosity’ of our improvisation… at least the effort we are doing. So, the virtuosity would be encoding music ideas into code and the virtuosity of the machine is just making those calculations. I think that’s the main reason why we like to project our screens. Some code parts are understandable for the people, and the complex mathematical expressions, or ununderstandable is the “that’s something I couldn’t do”-factor or the “ah! cool! so that’s the formula for a beat! clever! (or not)”. [/juan]
[matthias] I personally am not the biggest protectionist of the “show us your screens” mantra. I sometimes got the feedback that people get distracted by the code and that it ended a few times in a negatory attitude because the projected code created a feeling of exclusion towards audience members not familiar to (live) coding. On the other side I also know many people who really like to listen to our recordings just because of the musical qualities. I could imagine a place for a performance where people can walk around, listen to our music, with many projections on different walls, and on some walls you can also watch our code, but the whole setting doesn’t focus too much on the projection of the screens. What I want to achieve is to create an overall musical experience and not a clinical situation where every sound is presented on the dissecting table. Because the quality of live coding doesn’t only appear by the projection, but primarily by the music itself.
[holger] one problem with “show us your screens” in a group is the lack of projectors and projection space most of the time. perhaps the emergence of affordable small projectors could solve this and make it more pleasing and more like matthias describes it, so the audience won’t have to focus on one projection as it tends to do in our current performances.
Q8. How do you see us best helping new live coding bands getting started? [samaaron]
[patrick] I think commentated live coding sessions could be interesting for beginners. There are good introductions and documentation for most live coding environments, but there is much stuff that isn’t really written down elsewhere, I think. For example the art of writing code in a way that you have multiple possibilities to continue from. To give an example in SuperCollider: It’s sometimes smarter to write [1, 1, 1, 1] than 1!4, because you have more possibilities. (An IDE that would expand 1!4 or basically every call to a literal would be a cool idea!)
[juan] a framework or protocol where they are free to improvise free or to synchronize easily and chat… without much effort. After we had the MandelClock a lot of new possibilities opened up, like making beat driven music, and also chatting and making decisions verbally while performing. Having all this things covered, it is easy to start jamming and deciding if you use the clock or not, and reading the chat (or not). Also good experience with the environment to know what you can apport to the band, what can you do, what are your specialities, so you can offer that to the band.
Q9. How do you think of the collective musical rate(s) of change in your music as it unfolds during gigs? How do you judge whether, say, something that you are doing is ‘interestingly slow’ as against simply uninteresting? Are you aware when playing of the audience’s perception of this as potentially separate to your own? [ludions]
[matthias] I was just reminded of a concert we had in a big factory hall, and where the organizers had a really good sound system. We really had fun with our dark drone ambient session, until one of the organizers came and asked if we could stop soon because the people were frightened. So we really failed to perceive the perception of the audience. 😀
Well, we were supposed to be the warm-up act for the DJ party. There had been a miscommunication at the beginning so we weren’t aware of our ‘role’ before the day of the concert, and when we realized it we just couldn’t resist to still do our planned drone session in this great hall with this amazing sound system 🙂 (http://soundcloud.com/rukano/batman-hfg-nadelrauschen)
But in fact it depends: when we play in clubs of course we try to react to the perception of the audience, when everyone just started dancing we will not slow down to an ambient part again.
The changes during performances are nearly always agreements between us via chat or eye contact. Sometimes there arise little discussions but normally we have a common notion about the developement of our music.
[patrick] I think we are aware of the different perception of the audience but I also think this is one of the biggest challenges in live coding performance and it requires a lot of discipline not to play for your own perception of time (which is totally warped, because even boring sounds can be interesting to code, especially if something doesn’t work the way you want) but for the audience. I think it’s easier for a group, because if one think’s it’s enough of this now he just says that in a chat message, or just prepares a transition to something new. I think it’s very important for a live coder to listen to his own sessions after a while, to see if the pace of the performance is good.
Q10. What’s the weirdest place /situation you’ve live-coded in? [shellyk]
[patrick] My Top 3: On top of shelving in a bank foyer (see picture), under a bunk bed at a private art exhibition, as support act for a indie rock/pop band.
[holger] Definitely the bunk bed.
[matthias] The weirdest situation for me I think was 2010 at the SuperCollider Symposium in Berlin. It was the first time we played in front of an audicene who also was able to understand and read what we were doing. Weird places… I found it for example very weird to be on this great little island in Venice, San Giorgio Maggiore, and perform there in the monastery in front of a small audience.
End of interview! Thanks to everyone who took part.
