Integra Contemporary & Electroacoustics

Integra Contemporary & Electroacoustics (ICE) is a student ensemble that focuses on the interpretation of contemporary art music with and without electronic music components, creating new performance practices and exploring a potential for increased musical expressivity through technology.

Students integrate regular musical instruments (saxophones, pianos, didgeridoo, accordions, voices, percussion instruments, etc.), electronic instruments (guitars, microphones, MOOG Voyager, etc.) and digital instruments (turntables, DTX Drums, wii remotes, tablets, and more…) while practicing group performance, composition and free improv.

In ICE, we engage in experimental approaches that include live electronics, developing new digital instruments, sound design, creative sound production techniques, live coding, live gameplay, experimental video, and software synthesis (Logic Pro, Ableton Suite, Max, among others).


Group Collaboration, Improvisation and Life, while Live Coding

By Jordan Berg

Last semester was my first experience with live coding and one of my most profound conclusions at the time was that ‘going with the flow’ when live coding produced music that I felt was more successful than when I had tried to strictly compose material beforehand. This semester I found the same approach created more successful collaborations when improvising with the group. If I let my feelings, ideas and previously chosen sounds dominate my thinking, I ended up fighting with the unpredictability of the other sounds and choices that were made by the other performers. If I held nothing sacred in my choices and ideas I had made beforehand, remained very open minded with the direction and sounds made by the other players, I found that the overall experience was more enjoyable and always resulted in music that was original and interesting.

Timbre or sound choice is one of the biggest potential issues when improvising with others in a live coding environment. When improvising with non-electronic instrumentalists it is easier to know in advance how the sound from your colleagues will blend with your own instrument/sound. When live coding, the sounds that other members of your group make can be totally unpredictable. It could be the sound of an acoustic instrument, a voice, an electronic noise, animal sound or really anything else one can think of (and beyond). When you are accustomed to traditional composition or improvisation this can be frustrating at first because your ideas for the piece and what you have composed in advance might not pair successfully with the vision and sounds of the other members. Another potentially frustrating part of live coding with a group is that you might completely disagree initially that the sounds that your colleagues make are suitable for the particular performance. One player might be taking a more serious approach, for example playing a percussive rhythm, a melody with a recognizable instrument, or a subtle sonic atmosphere, while another player might take a comedic approach (this often happens). What I found to be a surprising result of having an open mind is that when the group engaged in a discussion about our choices, sometimes it seemed that everyone else unanimously enjoyed something I thought wasn’t working. I was happy that I had kept an open mind because it made me realize that maybe the only reason that I felt that something didn’t fit was perhaps that it simply didn’t work with my idea. Maybe my idea didn’t really work in the first place. It also made me think that when I sometimes felt displeased with an abrasive sound played loudly and/or repetitively maybe others sometimes felt that same way about a sound that I was proud of. I discovered that I should definitely communicate my opinions, but that I should remain very open minded, play my sounds in a way that blend in with the others and not carry overtop all the time, and then change things up from time to time because no matter how much I loved what I had done, it would become tiring to others inevitably. Even with the seriousness vs. comedic dichotomy and the fact that there might be sounds in the mix you don’t fully appreciate, I find that live coding is very forgiving if you let it be. If you hold things you’ve come up with as too precious and you allow your idea for the piece to dominate your thinking, you will end up conflicting with other performers’ elements and feeling frustrated. If you communicate with others in a constructive and positive way and you let things fall as they may without getting precious about anything in particular and allowing for strangeness that you may not love initially, the music that results ends up sounding good even if it does have strange, surreal, or out of place sounds. I feel that communication is very necessary because you can discuss the vision for the piece and talk about strategies. It is also necessary to openly discuss relative volumes/levels because often a player doesn’t realize how their sound or performance is dominating due to their focus on it. I found the experience overall to be rewarding and will be of value every time I perform with another musician whether live coding or otherwise.

Finding a Place in an Ensemble: A Reflection on the First Live Coding Experience

By Carter Potts

In an ensemble, each individual often has their own role in performance. For example, in a pop band, there is often a vocalist, guitarist, bassist, and drummer. In this type of ensemble, the most common roles, respectively, are to carry the melody, provide harmonic support, drive the rhythm, and hold the ensemble together and on time. However, in less traditional ensembles these roles aren’t as clearly defined. I have come to learn this as a member of the ICE Ensemble.

My first semester as a member of the ensemble was also the first semester that the ensemble partook in live coding. At first, I was skeptical of the ability for live coding to be recognized as a legitimate means of musical expression. As I continued with the ensemble, however, I recognized that live coding couldn’t necessarily be performed like traditional music. By that I mean that there are limits to live coding, and that these limits are integral to the live coding experience.

Live coding often limits itself to just a few short musical ideas, with these motifs being looped infinitely until terminated by the performer. The interest in live coding thus derives from the performer’s ability to manipulate the repeating musical material in new ways. It also allows the performer the ability to layer new ideas on top of old ones, while also transitioning this old and new material seamlessly. This may sound like a lot to focus on at one time, and it is. This is where the ensemble becomes an invaluable tool in live coding performance.

As already stated, ICE Ensemble’s live coding era was only a semester young at this point, so there was much development for the group to undergo. Every ensemble member started with no experience in live coding and no knowledge of the coding language that we used. As a result, everyone entered the ensemble at the same level. As the group grew in experience, and therefore knowledge, each individual began to recognize their own strengths, and discover their favourite sounds and preferred coding functions. This improved the group’s improv performance, as everyone fell into a role where they were most comfortable.

These roles became most evident in the improv game the ensemble played, called “On the Clock”. In this game, the entire ensemble takes turns editing the same

block of code. Each individual is given 30 seconds to listen to the current state of the piece, and then edit the code before the timer goes off. This quick thinking game compels each performer to play to their strongest qualities. For example, some performers choose to implement an additional voice to the code in order to richen the texture. Other performers may choose to make quick, yet impactful changes to pre-existing code that may, for instance, increase the rhythmic motion by adding more samples to the loop, or change the texture by changing the sound bank used for a voice. These different styles of performance allow for the piece to remain interesting by constantly altering all of the different musical qualities that are present in the performance.

The ICE ensemble has shown substantial growth through its first semester of live coding by displaying the different roles ensemble members have taken within the group. Each member limited themselves within the group in an effort to produce a cohesive performance. As a result, the ensemble members independently found their own roles within live coding performance, much like a more traditional ensemble would already have in place.

Live Sampling While Live Coding

By Matthew B. Pohl

The concept of live coding is foreign to many people, making it a difficult draw for even small-scale performances outside of a very niche community. Except for the curious musician or coding enthusiast, a live coding environment does not have the same appeal as a rock group, string ensemble, or jazz band would in the confines of the music community. With this knowledge in mind, I proposed the following idea to David Hume and Martin Suarez-Tamayo, two of the Fall 2018 Ensemble’s members: investigate the integration of live musical performance and a live instrument within a live coding environment, namely the TidalCycles live music coding language and a compatible IDE in Atom. In this way, there could be a functional bridge between the audience interpretation of traditional gestural means and the commonly sedentary presentation of live coding.

While it is entirely possible to have any acoustic instrument perform alongside the sound processes executed via Atom (or David Ogborn’s extramuros software when in a group setting), the goal was to integrate a live performance into the code to manipulate it live. The TydalCycles programming language is heavily reliant on the SuperDirt synth, which is activated through the SuperCollider IDE, and on the pre-programmed samples of the SuperDirt synth. We discovered that the SuperDirt samples are located in a user-accessible folder called “Dirt-Samples,” the contents of which could be modified freely without causing errors to that end. Therefore, one could effectively sample a live instrument into any DAW, export the bounced file into a user-created folder within “Dirt-Samples,” and call upon the sample in Atom. This is the process which we followed.

Any instrument can be recorded and sampled, whether mic’d or recorded acoustically in the case of a violin or saxophone, or as recorded from a digital instrument such as a keyboard or electronic drum kit. To avoid having to deal with the problems acoustic instruments face in a live sound environment (levels, compression, and EQ to name a few) as the performance was ongoing, and due to potential space constraints, we optioned to use a digital piano (Roland FA-08) as the performance instrument. The output was sent from the keyboard to a MOTU audio interface, in which the sound from the piano was mixed with the sounds produced from the USB-connected computer and sent to the main mixing board for distribution out to the eight loudspeakers.

The actual performance, without going into significant detail, was comprised of the first two measures of Erik Satie’s 1¬¬ere Gymnopédie which we sampled into Ableton Live at 72 bpm, coinciding with the metrical value in Atom, cps (72/60/6). As the sample was being bounced, exported, and relocated to a user file in our local copy of “Dirt-Sounds,” I continued to play through the piece by improvising on a central theme of the work. The fact that the audience had a (partial) view of a performer improvising on a relatively well-known piece of music while the sample was being created functioned as a discreet separation from the awkward first moments of silence live coding often entails by providing for them a motive to follow throughout the performance.

This is a vital distinction between what live coding itself is perceived as versus what it can result in as part of a collaborative environment. I feel that, as live coding integration matures into a distinct musical art form as opposed to the more-or-less novelty that it presently is, it should be the responsibility of the performer and the orchestrator to find ways that live coding can be intertwined with common musical practice. While this is not a new idea, perhaps this is one step towards performing coders being able to create saw-wave melodies live for an eighties tribute band or live drum loop patterns for a modern pop-rock group, coming soon to a bar or club near you.

Ensemble Performance and Teamwork While Live Coding

By Travis Lee

For this write-up I decided to take a closer look at my group performance with Cameron at this semester’s concert for the Integra Contemporary and Electroacoustics Ensemble. I will first talk about our ideas and the decisions we made regarding our piece leading up to the date of the concert. After that I will discuss the thoughts and reflections I have about the piece and the performance we gave. Through this review I hope to pinpoint the strengths and weaknesses of our performance so that I may take that information and apply it to any future performances.

For our group performance piece, Cameron and I decided to repurpose our midterm performance, but not without a bit of retooling. Our changes and additions to the piece were largely based on the feedback we received from the class after our midterm, the main points being to use explore more diverse sample libraries and to incorporate a bass voice into the piece. In an effort to act upon those recommendations, we replaced the “bd” sample with a one from the “hardkick” library and added a line that played samples from “jungbass”. These changes also ended up giving the piece a slightly more electronic texture than before. We also wanted to change the format from ABA, as we felt we needed more breathing room. The original intention was to play the first two sections and end it there, however in the rehearsal we found that there still wasn’t enough time to end the piece comfortably. So, we decided to just use the A section and then supplement it by adding additional effects to shape the sound. This in of itself provided us with a pseudo AB format, one where the musical material is added in the A section and the texture/rhythmic structure is varied in the B section.

After both the rehearsal and the concert performance, one major problem with our method became clear. As with our midterm performance, we used only one channel in our piece and used the stack function to layer multiple voices over top of each other within that channel. There were certain advantages to this format that proved useful to us, chief among them was the fact that it allowed us to add effects to individual voices as well as globally. However, using this format required us to effectively work in stages, since having one channel meant that we could only execute through one of the boxes. To expedite the process and to help prevent us from executing unfinished code, one person would write his code into another box and then copy and paste the code from that box to the primary one. Unfortunately, this was not enough of a fix to counteract the regression in productivity that this problem caused, and in retrospect it was the primary reason why we had to scale down the piece. For subsequent group performances of this nature I plan on returning to the multi-channel method that was used by the rest of the performances, though I would still consider using this format for solo performances if I were to do such a performance.

Live Coding Etiquette in Small and Large Ensembles

By Kierian Turner

When you are in any type of ensemble, the focus is on the collective and the sounds that are collectively being created. With that being said, the focus is not and should not be on the individual, unless it is in a solo section or performance piece. When it comes to a live coding ensemble, these principles remain the same.

When live coding in a large ensemble, you as the individual want to make sure that you are adding to the overall texture of the piece. You do not want your ideas to shine through extensively and mask other ensemble members’ ideas, so you need to make sure that you are thinking about your ‘gain’ values, your ‘pan’ values and the overall busyness of your coding. If you are coding the bass or rhythmic line of the piece, you want to make sure that it fits well within the piece and sits properly in the mix. If you are layering harmonic and melodic lines, you want to make sure that it does not conflict with the existing lines of code.

In general, you want to create different sections throughout the piece, so each ensemble member has to be thinking about the scope of it. You want transitions from section to section to be smooth so that the piece has a general flow, unless you intend to have a very choppy piece. Therefore, each member must think about how they are going to transition from idea A to idea B. Each ensemble member must also exercise the ‘power of limits’ since with a large ensemble, if you have everyone in it consistently jumping from idea to idea and using a wide variety of sounds and parameters, the piece will become very chaotic very quickly. If everyone has a designated role or at the very least limits themselves to a few sounds and effects, this will add to the structure and the cohesiveness of the piece.

When coding in a small ensemble of two or three, the majority of the above information is relevant but there are some additional parameters, restrictions and limitations that one must consider. In a large ensemble, the music will automatically continue to drive forward, since there will be many moving parts in the piece with lines constantly changing. When there are only two or three members, one of the challenges they will face is how to keep the audience engaged. To achieve this, the members must stagger their parts and really focus on the timing of adding new lines of code. You want to write short lines of code and be able to manipulate them quickly so that the audience does not get bored listening to the same repeated lines for one minute. If you stagger your manipulated short lines of code, then each member has a bit longer to work with their code before having to implement their next line, freeing them from a large time constraint. Another challenge that one has to keep in mind is that you don’t have let’s say ten others coding, therefore you have to be able to layer your material creatively and add multiple parts to the piece. Where you could focus on one instrument or sound in a large ensemble, you have to be able to contribute melodic, harmonic and rhythmic elements to truly reinforce the piece in a small ensemble. This means you have to be coding multiple lines continuously or coding lines that contain multiple elements in order to fulfil this.