Difference between revisions of "Jouska"

Revision as of 14:55, 19 June 2017

[project page for 220C course with Chris Chafe, Spring 2017]

Overview and Setup

Title: Jouska

Composer: Chris Lortie

Duration: 9'

Instrumentation: Violin and live electronics (including µgic glove sensor)

Premiere Performance: Mari Kimura at the 2017 SPLICE Institute on Wednesday, June 14th at 7:30pm in the Dalton Center Recital Hall, Western Michigan University.

Setup: Violin >> DPA clip-on mic >> Max/MSP on a laptop >> stereo output. During the piece, both fixed sound files and live processing of the violin input occur. Data from the violinist's glove sensor alter these effects and occasionally advance cues in the Max/MSP patch. There is no foot pedal involved in the piece.

Program Notes

The word Jouska comes from the Dictionary of Obscure Sorrows, a compendium of invented words written by John Koenig that try to “give a name to emotions we all might experience but don’t yet have a word for.” Koenig defines Jouska as “a hypothetical conversation that you compulsively play out in your head…which serves as a kind of psychological batting cage where you can connect more deeply with people than in the small ball of everyday life, which is a frustratingly cautious game of change-up pitches, sacrifice bunts, and intentional walks.”

Circumstance

Jouska was written for the violinist Mari Kimura as part of a commissioned collaboration for the 2017 SPLICE Institute at Western Michigan University. The criteria for this commission only dictated that the piece should be around 7-9 minutes in length. After being introduced to my collaborator, Mari, I asked about the potential to make use of her µgic sensor, a glove sensor prototype she developed with Liubo Borissov at IRCAM. She was more than happy to accommodate this request and sent instructions through email about the nature of the data the sensor would provide. In early May, I coded for her a "precomposition patch," which included most of the live processing used in the piece; these effects were split into 11 different "presets," each of which utilized her sensor data in a specific way. This patch later influenced how I coded the final performance patch, and allowed me to better understand the results of the data-audio interaction. Mari and I finally met in person on June 11th at the SPLICE Institute; here, we tweaked the patch with some final adjustments for the data streams and addressed some balance issues with the live processing.

µgic sensor

The Data

Mari's µgic sensor was utilized as a major component in the piece, primarily to act as a bridge between the performative gestures inherent to her playing and the resulting processing of her sound. In this way, the data from the sensor was used to drive different parameter values in the live processing. The µgic sensor is built to track the following performative motions using a 9-axis accelerometer:

1) bow stroke duration - tracks the length of a bow stroke in 10s of milliseconds

2) pizzicato - a sforzando pizzicato motion can be reasonably traced

3) bow energy - the aggregate energy value for the entire sensor (on a scale from 0. to 1.)

Pitch tracking and amplitude/note-onset tracking were available as parameters to work with, although they do not require the use of the sensor glove. For pitch tracking, I used the IRCAM external, yin~.

Here is a video of Mari explaining sensor interactions in her piece "Eigenspace."

Sensor Brainstorming

Before beginning the piece, I thought about what might be the most potent way to utilize the sensor data as an organic element in the piece. I wanted to use the sensor as a way to make the live electronics more congruent with the performative action. Certain movements cannot easily be tracked with amplitude or spectral algorithms alone. Mari is well known in the electroacoustic community to avoid the use of a foot pedal to trigger cues, particularly because they 1) destroy the illusion of interactivity, snapping the frame of reference towards the foot pedal itself for a brief moment, and 2) because the foot pedal does not hold an organic performative role that is embedded in how the performer plays their instrument. With the above arguments in mind, I brainstormed what sorts of interactive relations might fall under the criteria of:

1) events that would be difficult to align if there were structured as performer and fixed media playback (for example, a pizzicato motion could start or stop a sound file)

2) ways in which I could combine multiple elements together (such as pitch detection and bow duration) to create more interesting processing that does not become stale over time

3) evolutions of effects that would seem "inorganic" if they were triggered only with a foot pedal

--A list of brainstormed ideas sensor-processing interaction can be found here. This document includes Mari's correspondence as well.

Final Results

Each of the three available data streams from the sensor were ultimately used in the piece. These uses included:

- using bow energy to crossfade between distortion and octave doubling

- using bow energy to control the amplitude of the harmonizer

- using bow duration to pitchshift notes for their individual durations

- using pizzicato motion to advance cues

- using pizzicato motion to start or end sound files

- using pizzicato motion to "capture" a pizzicato note and send it through a different effect than everything else

A snapshot of the data router in my Max patch can be viewed here. This router was created simply using [gate] objects, each of which was turned on and off over the course of the piece by the [pattr] object. I originally used the [router] object in combination with [matrixctrl] to control these data, but ran into several issues that were embedded in the [router] object itself; namely, the object was sending out both a control message as well as the data itself. Parsing this control message out of the stream seemed to be fruitless, since it was not consistent over time.

In retrospect, I would have had more success in using the bow duration data instead of the bow energy data in many places. The bow energy values were not scaled in a way that matched well with Mari's gestures, but instead gave a more-or-less logarithmic curve of energy; because of this, the energy data was useful in detecting the onset of fast tremolo notes, but not the steady increase and decrease in bowing speed that I was looking for. In future iterations of the patch, I will recode the bow energy correlations to be bow duration correlations instead.

The Max Patch

Interface and Cue System

The Max/MSP patch for the piece was constructed as a 16-cue system that either automatically or intuitively advances over the duration of the piece. I used the [pattr] object to store all sensor data and audio routing settings, and the [qlist] object to control all ramps, effects parameters, and triggered sound files. I ran into issues when using these in combination due to some simple order-of-operations flaws in my logic. Additionally, [qlist] is not ideal as a means of triggering ramps and soundfiles, since skipping to cues in rehearsal will play all previous cues. I managed to compensate for these issues with a few simple workarounds -- in future iterations of the patch, I will need to structure this logic a bit differently so that the cue system still complements my workflow but doesn't introduce these issues.

A few screenshots of the patch can be viewed here:

Main GUI: Features the current cue number, a means of skipping to a new cue number for rehearsal, the data coming from the sensor, a record button for recording audio during performances, a description of each cue, level adjustments for the main outs/mic/sound files that can be saved, and a large slider which helps to coordinate timings within the piece.

Effects GUI: Provides an interface to set individual levels for each of the effects and save them. Two effects are not show here because their levels need not be adjusted from the GUI (these being the crossfader and the sidechain compressor).

Audio Router: I can route audio signals to and from whichever effects I like for a particular cue.

Data Router: I can route sensor data to an effects parameter only when I need it.

Live Processing Effects

There are only six different effects used in the piece to process the violin:

Multi-tap Exponential Delay -- This is an effect I created (started in October 2015) initially for use in my acousmatic compositions. The effect is essentially a multi-tap delay with the option to provide an exponential curve to the delay times. The delay time and amplitude of each tap can be configured by the user on the main GUI. In the piece, I used this effect exclusively to process pizzicato notes (and ONLY pizzicato notes, not what surrounds them). I built an algorithm that allowed the effect to compensate for the sensor's latency, so that I could capture the pizzicato notes by themselves and send them through the delay lines.

Distortion --

Convolution --

Harmonizer --