First off, I found it fascinating to get different people’s reactions to it during its premiere performances, primarily which parts of the piece that they liked the most. It was spread pretty evenly across all three movements and all for different reasons, and I think that makes the piece a success because different parts can appeal to a wide variety of people.

At this point for me personally, I find that I dislike the second movement the most. Part of that comes from some of the technical difficulties in error-free execution – the primary reason I want to potentially use Antescofo in the first place – but another part is that the metronomic nature of the movement means that it’s structurally the most rigid and inflexible, limiting the performer’s ability to add their own personal musical expression and leaving little margin for mistakes in execution. In the first and last movement, the electronics are the vehicle for the performer being the forefront, whereas in the second movement, the performer ends up being a vehicle of the electronics as a forefront. That feels counter to why the piece is in an interactive form in the first place – if i wanted it to be like that, I would have just created a tape accompaniment for the performer to play to. I’m not sure what to do about that given the nature of the material, but it’s something I’m thinking about as a consideration for use of that mechanic for future works.

The amount of work I put into the Max programming was a significant time chunk, although I would say that the time invested was well worth it – I learned a lot about MSP, a side of Max that I had never really used before, and all of the patches I created that went into this project can be more easily reused and adapted for future works as opposed to having to start from scratch. Even so, it’s worth remembering that creating a work that involves interactive electronics with the kind of attention to detail that I require as a fairly detail-oriented musician and a programmer doubles or more than doubles the amount of time and energy that I would put into any other kind of composition.

That might seem like something that would discourage me, but it actually does quite the opposite. The work I did on this project and the passion I had and still have for its final outcome has helped me realize that I think I have a lot of unique things to say in the interactive electronic medium that could have a lot of legs for my compositional career. I’m hoping that after tweaking the Max programming to make it as error free as possible, I can get this performed in Oregon and Pennsylvania with my alma mater universities, but I also have ambitions to publish this work and have it potentially played by other trumpet performers. If that happens, that could encourage me to devote more energy to the interactive electronic space as well as open up future opportunities and commissions for those that might come across this work and find it valuable.

Where I go from here immediately will take shape in the next few years. I’m close to closing a commission to write a wind ensemble piece for the spring of 2020 here at Tulane, which will be the first time I’ll have written for a large concert ensemble since beauty…beholder back in 2012. I’m also close to closing a commission deal to write a percussion duet for the 2018-2019 school year. That will likely be purely acoustic, as I already have a few conceptual ideas that are best fit in the purely acoustic space.

After that, I have the framework for a piece that I was originally going to be make as a standalone digital audio piece that I’m now inclined to make a work for solo cello and interactive electronics, specifically for my colleague Elise who plays with me as a part of Versipel New Music. I originally wanted to do that next year, but given the scale of the wind ensemble piece, i’m now thinking that I’ll have to put that off until the fall of 2020 or the spring of 2021. I’ve also been having some initial talks with a dancer/choreographer to maybe do some collaborative work with her and interactive video. That has no timeline, but given that I would have to spend time learning how to use Jitter, I imagine that that would have to be 2021 or later.

The other thing that I’m thinking about is taking the concepts that I’ve put into Minkowski and turning it into a series of pieces – using similar interactive and creative concepts and some of the same Max work for other instruments in the same way as Erin Gee’s Mouthpiece series or Berlioz’s Sequenza series. It would be a lot of fun to write a Minkowski for percussion and another one for clarinet. We’ll see what happens as I let this piece germinate and start to market it. If people want to play it and it’s received well, then it will definitely happen.

Some of the Max programming mechanics that I’ve done for this work have been put into my Kaizen YouTube series, and I’ll be posting up at least one more video that talks about it in the near future. For now, below is the most recent that talks about my custom interactive cue engine.

Some background first:

This is my BufferRecord patch:

It’s pretty straightforward – you give a command for what buffer you want to record into, it activates the recording and sets a timer to track the length of time recorded. When you’re done recording, it turns off the Record function and stores the length in ms into a list that it can then use for reference for looped playback (because otherwise it would loop the whole buffer which i’ve set at a default for 20s).

This is my Loop patch:

There’s a lot of small things going on there, but the relevant point to this entry is that the actual engine for playback is going through that [poly~] object. [Poly~] is a way to “clone” a subpatch with multiple instances without actually copy/pasting those individual instances which necessitates routing signals to those individual instances via cumbersome gates and switches. Everything is instead set by a single [poly`] object that has a definable number of “voices” that can be dealt with all at once or individually. In this patch I have 16 different voices. When a loop is activated, a counter iterates to the next [poly~] voice and then all of the loop info is assigned to that voice – it iterates to one voice higher in number to the one that was last used, so if the last voice used was 8, the next loop activation chooses voice 9.

Here’s the patch that exists inside of the [poly~] object: 

The [groove~] object is what actually plays the loop. I send in the buffer name to loop (which replaces the default i created “Buffer1”) as well as all of the variables of loop start/end time and speed.

The problem is: since i’m not personally tracking which [poly~] voice is being used for an individual loop (because i just have the counter iterating to the next available voice), I needed to find an alternate way to find a specific loop within a voice instance so i could end just that specific loop as needed. I decided to use the Buffer name (in this instance “1-01”) as a means of doing that, so if i send the command [LoopEnd 1-01], it would find the [poly~] voice that’s looping 1-01 by name and then turn it off. Except what if I want to run multiple voices with the same buffer simultaneously and I only want to turn off some of those voices later? Sending the command [LoopEnd 1-01] would turn off all voices that hold a buffer named 1-01 at once with no ability to deal with that partially.

There’s a few different ways to address this. The quick and dirty method is to take any instance in which i want the same buffer materials looped and write that material into multiple buffers. That way, voices in the [poly~] will never have duplicate names. It’s sloppy and would require a ton of extra CPU buffer depending on how many copies of a single buffer i would want to create.

A more programmatically clean but inflexible way is to identify the loops by poly voice only with no concern for what’s there. That could create some potential problems down the road if, say, one Record Buffer fails to trigger or the counter iterates wrong or something and now sample 1 is not located in voice 1 where it’s supposed to be and i accidentally activate or cut the wrong loop.

The most airtight but most difficult to program way is to somehow link the name of the sample with either the voice it’s connected to or its simultaneous iteration number and then somehow program LoopEnds to know which voice each simultaneous iteration is connected to even if that voice is different every performance. As i type this out, I may have a strategy to address this, but I still need to work out some of the details in my head to make sure it will work. If it doesn’t, i’ll probably go quick and dirty and hope that my laptop can handle the CPU load that would be necessary. We’ll see what happens.

First, one of my marching band students has asked me to write a piece for his senior trumpet recital. After a brief discussion about ideas, I decided to write it as an interactive piece using Max, which has gotten me down the path of re-learning and doing a lot of Max programming (because apparently I can’t make things easy for myself even if i tried). I’m not as familiar with MSP as I should be, but hopefully this will graduate me from beginner to competent amateur.

Right now I’m conceiving of the piece as being done in four movements, all of which play with a different concept of time. The first movement will be about the trumpet playing some passages that will then get echoed back and potentially manipulated, representing the trumpet playing from the “past” being used with current material. The second movement will be about the trumpet playing passages that has chordal movement in live unison, representing the trumpet playing from the “present” being used with the current material. The third movement will be about the trumpet playing passages that it hears from Max first, representing the idea that those passages are grabbing trumpet playing from “future” passages. The fourth movement will pull from all of those concepts into a single movement that is loosely based on the concept of spacetime.

The beginning stages of this is mostly programming Max patches that can deal with these various mechanics. I’m trying to figure out the best way to get the trumpet signal into Max, easily identify its pitch, account for tuning errors, different input/output gains and levels, and the like. Once I create that groundwork, I’ll deal with tools for the actual music. The patch for Movement 2 is going to be a modified version of an external patch already built by ICST, so that’ll also probably be what I compose first.

Second, I need to write a piece for nienteForte this year, and if all goes according to plan, that will be for the TALEA ensemble. A lot will depend on exactly what members of TALEA will be a part of the festival, but if all goes according to plan, the piece will also include some basic Max programming (but much more simple as it will be MIDI only and I can do that in my sleep). The piece is going to be based on a Dali painting that i love, with the idea that the ensemble is going to be split into two distinct tonal groups – one that uses equal-temperament and another that uses a “parallel” microtonal equal-temperament that phases in and out as controlled by Max and a MIDI piano. The idea I have right now is to put the responsibility of the parallel tuning on string instruments with the idea that it’s easier for them to constantly microtune than it is for wind instruments.

We’ll see how all of this shakes down; the current goal is to get the Max programming structure of the trumpet piece done in the next few weeks so that I can start writing the actual music in July. My progress on that will be somewhat contingent on Life getting in the way, which is going wonderfully ballistic right now with house hunting with the girlfriend, staying on top of TUMB stuff, etc.

There are a couple of small nagging sloppy parts to the piece that frustrate me and I think the middle section before the final climax is something that I would do slightly differently, but there’s more about it that I’m still happy with than unhappy, and that feels pretty good.  The more important thing is that fifteen years later it still feels like me – given the same source material that I had back then (which was probably over two hours worth of material), my approach to the composition might be more polished, but the general structure and idea behind the work would still be the same.

It serves as a good reminder that contemporary electronic art music is something that still holds importance to me in some way, and that, along with some other stuff that i’m almost done creating a different blog entry about, is giving me the drive to kickstart some abandoned projects in that realm to complete for the next couple of years.  There’s two electronic projects in particular that I’m planning on doing – one is a revision and a revamp of an old piece I did during my undergraduate years that then carried through to my masters called Surrounded By Mirrors for clarinet, MIDI keyboard, and interactive electronics.  The other, In a Fast Paced World, is a piece that I was originally conceiving of as an interactive octaphonic piece of music using a LEAP Motion Controller.  I’m not 100% convinced that the LEAP is the right controller for the job anymore, but it’s still worth fiddling with since the software side of the tech has improved greatly since i last experimented with it, and they may have even figured out at this point how to get two LEAPs to connect to a single computer.  We’ll see what happens, or if something else comes along that is a better sort of input for that project.

The concept was to have the piece be a representation of standing in the middle of the road with whizzing traffic happening on either side of you. All of it would be fast traffic, the stereotypical high-speed-loud-engine-doppler-effect that would start as one iteration of it on one side of you, then a pause, then another iteration on the other side, then a pause, then a gradual increase in iteration frequency that would evolve and build to this cacophony of whizzing doppler effect noises.

Two days ago, i was randomly thinking about the piece again and upped the game on the compositional concept and content in two ways. First, i want to add the sound of walking, a loud sort of clack that moves at a very slow pace. The piece itself will be retitled something like slow pace in a fast place except more artistic, the concept being less about the simple experience of how it would sound to be in the middle of the road of fast whizzing traffic and being more about the value of finding times to move slowly in an increasingly fast-paced world.

Second, after establishing the initial expectation and vocabulary of the piece being the walking sound and the whizzing doppler sound, i eventually want to mutate the whizzing to become chords and then start to add my own sort of music to it. This would be in the style of the third movement of Michael Gordon’s Weather, one of the more powerful pieces of music i’ve ever had the pleasure of experiencing. I want to capture that sort of idea in my own way.

I still conceive of it being an octophonic piece, something that could then be mixed down to stereo. The problem is that i don’t have access to an octophonic setup – ideally I think the piece would be primarily designed in Max/MSP with a patch that could route any sound through eight different output channels. I know that I could build this in software with minimal effort, but I don’t know how to truly realize the piece without having the desired octophonic setup, or at least a digital mixer that would not be practical for me to buy.

I’ll probably end up having a conversation with the current Tulane Technology guy Richard Snow about it and see what he thinks. The piece itself isn’t something that I think would take a long time to put together, it may be a quickie summer project after i get done with Cascadia but before stuff at Tulane picks up again, maybe something that I could target for entry into SEAMUS and other electronic music competitions in the 2013-14 academic year. We’ll see how it develops.

I never got much into the co-op mode of guitar freaks/drummania/keyboardmania, but i’ve played Rock Band for a couple of sessions now and while i like it a lot, the nature of that particular game brings out a fundamental flaw in all of them – you’re not actually playing with other people, you just happen to be playing next to them.

As in, when you’re playing the game with someone else, what you do has no impact on how they get judged because everyone is keying off of what the game tells them, so everyone is executing in silos with the blinders on. If i’m the drummer and i start to fall behind the beat, it doesn’t matter to anyone else – they just do their own thing.

But a real band doesn’t operate like that, and marching bands/drum corps in particular can’t operate like that. Musicians have to be able to adjust to each other and listen to each other to be able to execute their best. At the extreme level, high level marching drum lines have to learn to be able to adjust and react to what’s happening around them to the millisecond sort of degree or else they sound dirty.

So i want a music video game to have the option to emulate that – to make it so that the judgement that is received is based on how the players are playing in relation to each other.

With something like Rock Band, simple enough. The drummer or the bass guitar or the rhythm guitar acts as the tempo lead, and the video game adjusts its “judgement window tempo” based on what that lead is doing. So if the drummer is the tempo lead and slows down or speeds up, the tracks slow down and speed up with him and everyone else playing has to slow down and speed up with him. Promote the idea of the ensemble truly being an ensemble.

With something like DDR, i had this idea where two players playing the same chart get judged on how closely they hit the arrows in relation to each other, so as opposed to getting a perfect by hitting your arrow within 20ms of the arrow hitting the casings exactly, you get a perfect by hitting your arrow within 20ms of your partner. Then turn on “autosync” (and furthermore autosync the music as opposed to just the visual arrows) so that if the couple slows down or speeds up, the arrows and music adjust with the couple.

If i had to build a piece of electornic music programming from scratch that could do something like that i bet i could pull at least a basic form of it off with some complex Max/MSP work. In an actual music video game that would be more challenging. If i knew the ins and outs of stepmania programming i could probably change the code to measure the judgements based on each other, but i wouldn’t be able to get the “adjust the BPM of the song based on the player’s performance” part since it’s not fundamentally built into the code (and no, speeding up the song in the extended options screen doesn’t count).

fun to think about.