If you are interested in my process, please feel free to read my final report below, or email me.

Original Objective

To write a bass guitar composition and design algorithmically determined accompaniments, all based on the Fibonacci sequence.

Process

My process in developing this project was very linear due to my limited time frame. In the beginning of the semester, I set up a list of goals to accomplish, and mapped them evenly across the remainder of the semester. Initially all of my goals were technical, proof of concept pieces, which became the individual components that I would later combine into a larger signal-flow. Some of these components took more time to implement than I had anticipated and some took much less, so I was able to complete them all on time. After completing any one of these smaller components, I hardly ever went back to revise or rewrite it. For example, I spent approximately an hour choosing the percussive sounds that I used in the piece, and never looked back after that. I feel that my ability to perform the piece successfully is partly due to this lack of perfection, as I would have never had enough time to finish writing the composition, let alone practice playing it, if I had attempted to make every aspect perfect.

As far as the composition itself, I did not spend that much time on the general structure, nor on any other aspect of it. For the central melody, I arbitrarily chose a center (pitch), and used successive Fibonacci numbers to determine how many semitones will be between the current note, and the next note. I alternate the direction of the pitch, i.e. up 1 semitone, down 1 semitone, up 2, down 3, up 5, down 8, etc. The amount of quarter-note rests between each note is also based on this “global” Fibonacci number. This ended up not sounding too bad at all.

To integrate this in to Max/MSP, I basically just fed the MIDI into Max, and devised algorithms to keep track of this global Fibonacci number based on the notes that I am playing. All percussion is generated based on this number, and other randomly generated numbers. The number sometimes denotes how many percussive notes to play, how long to wait between them, etc.

Final Result

Although I didn’t get to accomplish some of my original goals, I am satisfied with the way this project turned out after a semester’s work. My plan was to get my hands dirty with this concept, and to see what I could make of it. The result is a fairly polished, proof of concept, of what I hope to become a much bigger composition next semester.

This semester allowed me to work out many of the technical issues that I had considered while planning this project such as exactly how the signal flow would occur during the performance. I was also able to experiment briefly with many of the aspects that I hope to exploit further next semester, including audio effects, and melody generation within Max/MSP. Because of my limited amount of time and the vast amount of elements involved in this project, I was only able to spend a short amount of time on each element. In the future, I would like to spend much more time choosing and manipulating the elements of this project, to make sure that every aspect is intentional.

The hardest part for me, due to my lack of formal music training, is the actual composition. I have been discussing with many classically trained musicians and music professors (Prof. Curtis Bahn, Prof. Scott McCoy, Garrett Smelcer, Garrett Sullivan) over the past semester various techniques and concepts relating to this project, and am looking forward to my elaboration of these ideas in the future.

Now that I have a general concept, and ideas of how to implement various techniques, next semester I plan on taking this project further, and hopefully expanding it into what I originally hoped it would be.

Concert solves not only this problem of choosing the good from the bad, but also solves the problem of organization of the various audio “segments”. Concert will allow all the members of a group, say Tim, Garrett and myself, to collaboratively listen to each of the audio recordings that we have piled up on our own time. A user of Concert can then highlight a segment of one of these audio recordings and “tag” it, effectively organizing parts of the audio recordings. Other users in the same group will be able to see these changes, and add/remove audio segments from these tags.

On the technical side, we have a few challenges to face. One challenge is on the backend, with the audio manipulation. We are hoping to provide the functionality for a user to download an “audio segment”, that is, a segment of an audio file that they have previously uploaded. Another set of challenges, which are the ones I am trying to deal with, are on the client-side. We are hoping to use HTML5 instead of flash for the audio playback. I have already solved a few quirky issues that I’ve found with this new technology, and overall it seems fairly solid.

Overall, we hope to have a small working prototype of Concert by the end of the semester. We’ll see where this takes us.

Objective

My objective is to write a bass guitar composition and design algorithmically determined accompaniments, all based on the Fibonacci sequence.

Goals

• Finish writing a composition that I once started on my bass revolving around the Fibonacci numbers
• Design various accompaniments to this bass line also revolving around the Fibonacci sequence
• Experiment with digital audio effects, the parameters of which are manipulated based on Fibonacci sequence
• Experiment with manual manipulation of different parameters of the auto-accompaniments
• Experiment with multi-channel audio
• Use a MIDI foot pedal, or other sensors (accelerometer), to manipulate these parameters during performance of the piece

Implementation

I am hoping to achieve these goals by creating a few smaller projects to tackle each of them, and then bringing all of the techniques together in the end.

In the end I hope to have flushed out this composition I have in mind, and to have some natural sounding, algorithmically determined accompaniments in the piece. My goal is not to merely generate these accompaniments in an arbitrary way, but to ensure that the piece is still pleasing to listen to. I do not want knowledge of my development process to be a prerequisite for listening to the piece. It should stand on its own.

Features

• Entire e-commerce solution, so Kenyon can sell their products directly to customers.
• Dealer login, enabling dealers to select which products they carry
• Google Maps “Dealer Locator” which can be specific to items carried by dealer
• Administrative users can receive notification of low stock and product invoices
• Unlimited number of static pages, all editable through administrative interface
• All products & product categories handled through admin interface

Implementation

• PHP Symfony web framework
• Symfony plugins
• Javascript
  • Google Maps API
  • jQuery/Ajax
• MySQL

Unlike our shows at Mohegan Sun, where my boss (Phil Gauvin) writes the scripts in our native scripting program, I was handed a script that a different coworker had written in Excel, which was in a format that made sense to him as he was planning the event.

When I first looked at this script, I was a bit taken back.  942 cues, approximately 650 of which detonate in 60 seconds, between 11:59:00 and 12:00:00.  This was a huge script, and it was not in the format that I needed it to be in for the Nighthawk.

Ruby to the rescue.

I had been working with Ruby for a good amount of last semester, so about a week before the show, I went to town.  After a bit of trouble with converting the time on the original script (5:59:45 PM) to my relative time from the start of the script (0.00 seconds), I had the script ready.  Since there was about a minute of pyro every hour until midnight, I decided to just make the entire night a single script, and to avoid overflowing any number representations in the system, just added about 100 seconds between these discrete events.  This allowed me to simply stop the panel after each event, forward to the next cue, and I was good to go.  Dave Levoy from Pyromate, Inc. was with us all night as a consultant in case we had any problems with his system, and to make sure we didn’t run into any quirks or small issues.  He helped me figure out how to run such a long show on his panel, and pointed out the number overflow problem.

Setup went pretty flawlessly, as it usually does with the Pyromate system.  We used all wired mods, to eliminate the possibility of wireless interference, although I’m sure they would have worked just fine.

As far as the actual execution of the show, it was a bit chaotic in the beginning, but everything ended up working out in the end.  I enjoyed the time between firings, as I only had to check continuity and keep track of a small number of events at once, and it gave us ample time to fix any problems that may have occurred during firings.  All in all it was a very successful event, and thanks to those 5 hour energy shots, I was alert the entire time

I’ve decided to implement this using a programming language called ChucK, which so far has been working out extremely well. ChucK is a relatively new multimedia programming language which allows you to accomplish some complicated tasks in very little time. Since I have not really done any DSP Programming before, it is extremely gratifying to be able to hear results immediately.

The way Independent Study works at RPI, is you make proposals, set goals, and complete them. Here is my proposal for my end-of-semester project: Project Proposal

Curtis Bahn is my advising professor for this project, and he has been more than helpful.

Here is an audio sample of the effect in action. There are no other alterations to the bass signal besides mixing in a bit of clean as well. The affected signal was recorded through my stack (GK-700RBII, Ampeg SVT410HLF) using my Zoom H4n. The distortion increases as I play my bass louder, as you can hear towards the end of the clip.

ChucK ended up working very well. I think the effect sounds pretty good. As you can see below, there are infinitely many options available for the coefficients of the wavetable function (Gen17 object in ChucK). I can spend hours tweaking them, but the ones I settled on are uncommented below.

Click to show code.

/**
*  Overdrive/Distortion effect (meant for bass guitar)
*
*  Copyright (c) 2009 Colin Sullivan
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  The above copyright notice and this permission notice shall be included in
*  all copies or substantial portions of the Software.
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
**/

// patch
//envelope follower
adc => Gain g => OnePole p => blackhole;
//clean lows
adc => LPF lowpass => Gain lowClean => Gain mix;
//overdrive on lows
lowpass => Gen17 lowOD => mix;
//clean highs
adc => BPF highpass => Gain highClean => mix;
//overdrive on highs
adc => highpass => Gen17 highOD => mix;
//mix them together
mix => dac;

//master Levels
mix.gain(0);
1  => float masterVolumeLimit;

//low levels
lowClean.gain(1); //1
lowOD.gain(0); //0.3

//high levels
highClean.gain(1); //0.3
highOD.gain(0); //1

//frequency of pass filters
lowpass.freq(1000);
highpass.set(1000, 1000/(1200-800) );

//square input
adc => g;
//multiply
3 => g.op;
// set pole position
0.9999 => p.pole;

// load up the coeffs; amplitudes for successive partials
lowOD.coefs( [ 1., 0.5, 0, 0.5, 1. ] ); //Nice fat fuzz
//lowOD.coefs( [1., 0.5, 0, -0.5, -1.] );  //thrashy, but buzz
//lowOD.coefs( [.99, .88, 0, .88, -.99] );	//loud and farty fuzz
// load up the coeffs; amplitudes for successive partials
//highOD.coefs( [ 1., 0.5, 0, 0.5, 1. ] );
//highOD.coefs( [1., 0.5, 0, -0.5, -1.] );
//highOD.coefs( [.99, .88, 0, .88, -.99] );
//highOD.coefs( [0.5, 0, -0.5] );
highOD.coefs( [.256, -.576, .432, -.120, .9] ); //not grungy enough

//master volume
0 => float masterVolume;
0 => float i;

// will hold last value of filter
0 => float pLast;
// full overdrive flag
0 => int fullOD;

// Allows output to chuck~ object outlet in Max/MSP
MaxMessage m;

while (true) {
  while(masterVolume < masterVolumeLimit) {
    mix.gain(masterVolume);
    0.001 +=> masterVolume;
    1::ms => now;
  }

  // Get last value of filter
  p.last()*50 => pLast;

  // Debug to max
  //pLast => m.floatout;

  // Set high overdrive gain based on dynamics of playing
  if(pLast < 1 && fullOD == 0)
  {
    highOD.gain(pLast);
    lowOD.gain(0.3*pLast);
  }
  else if(pLast >= 1)
  {
    highOD.gain(1);
    lowOD.gain(0.3);
    1 => fullOD;
  }
  else if(pLast < 0.5 && fullOD == 1)
  {
    // turn fullOD flag off if done lowering
    if(highOD.gain() - pLast < 0.001)
    {
      0 => fullOD;
    }
    else
    {
      // Lower gain
      highOD.gain(highOD.gain() - 0.001);
    }
  }
  0.01 +=> i;
  1::ms => now;
}

We use jQuery for all manipulations and Ajax calls, and PHP/MySQL for the back-end.

For more information about the project, http://www.rpinventory.com/.