Grant Muller

GOLSequencer, HarmonicTable, and MidiReference on GitHub

With just a little trepidation I have checked in the code for all of my free software goodies into GitHub. I was getting several requests to provide access to the source for several of my old projects, so rather than emailing code around on a case by case basis, I have simply checked everything in to GitHub for posterity. Who knows, maybe someone will jump in there and fix all the bugs.

I have written some other tools for my personal use that I will likely check in there as well, so check back if you’re interested in that kind of thing.




RWMidi and Pitch Bend: Another Adventure in Social Coding

In my previous post, I discovered that the RWMidi library was available via GitHub, leaving it open to the possibility of forking and making my sync and pulse resolution changes public. Proving that Jung and Sting were on to something, while making these changes I received an e-mail from a user struggling with RWMidi:

I’m trying to send a simple Pitch Bend message and it’s proving impossible!

I was already in the code, so I poked around. The problem was simple.

You can’t.

There are no exposed methods to send pitch bend in RWMidi. So, newly empowered with forked code from GitHub, I created a method in the MidiOutput class that would allow a user to do this. I did a little research on the format for pitch bend method and came up with this:

Pitch Bend
The pitch bend wheel is also a continuous controller on many MIDI keyboards. Possibly, the Pitch Bend message is in its own category because it is something likely to be done frequently. The two bytes of the pitch bend message form a 14 bit number, 0 to 16383. The value 8192 (sent, LSB first, as 0x00 0x40), is centered, or “no pitch bend.” The value 0 (0x00 0x00) means, “bend as low as possible,” and, similarly, 16383 (0x7F 0x7F) is to “bend as high as possible.” The exact range of the pitch bend is specific to the synthesizer.

Crudely translated this simply means that pitch bends are in the range of 0 to 16383, with 8192 meaning “don’t bend”. Bending up means sending a value higher than 8192, bending lower means sending a value lower.

The format is a little funky and deserves some explanation. Essentially rather than sending two 8-bit bytes to represent the 16-bit value, I have to send two 8-bit bytes representing a 14-bit value, which will be interpreted as a number between 0 and 16383. So, in order to send the correct bytes I have to take my original value and rescale the size of each byte from 8 to 7 bits.

For the plain-jane 16-bit number 4000, the two 8-bit bytes would look like:

8 7 6 5 4 3 2 1
LSB 1 0 1 0 0 0 0 0
MSB 0 0 0 0 1 1 1 1

The 14-bit value that I need to send would be:
8 7 6 5 4 3 2 1
LSB 0 0 1 0 0 0 0 0
MSB 0 0 0 1 1 1 1 1

When visualized like this, it becomes clear that what we need to do is shift the last bit in the least significant byte into the first bit of the most significant byte, thus shifting the entire MSB over a place to the left. The way I have to think about this is to consider the two 8-bit bytes as zero-padded 7-bit bytes, and understand that when the receiving device gets the message, it will trim the last bit of each byte and put the registers together to form one 14-bit value.

Doing this is somewhat straightforward. I take the modulo of the pitch bend value and the greatest possible value I can represent with a 7-bit byte, which is 128, to get the LSB. From there I can simply divide the pitch bend value by 128 to get the binary value of the MSB. To send a pitch bend of 4000, I would send the numerical value 32 for the LSB, and 31 for the MSB. When you strip the first zero of each of these bytes, then string the registers together into one 14-bit number, you get 111110100000. This isn’t the most efficient way of doing this of course, I could shift some bits around, masking off values, etc. But I didn’t. The method I created is pretty straightforward:

public int sendPitchBend(int channel, int value) {
		if (value > MAXPITCHBEND) value = MAXPITCHBEND;
		if (value < MINPITCHBEND) value = MINPITCHBEND;
		byte lsb = (byte) (value % 128);
		byte msb = (byte) (value/128);
		ShortMessage msg = new ShortMessage();
		try {
			msg.setMessage(MidiEvent.PITCH_BEND, channel, lsb, msb);
			receiver.send(msg, -1);
			return 1;
		} catch (InvalidMidiDataException e) {
			// TODO Auto-generated catch block
			return 0;

There is some error checking here to make sure we don’t try to send a stupid value. Obviously if the max is 16383, there is no reason to allow 16384, not to mention a negative number. To test this I created a little sketch that looks a heck of a lot like a pitch bend slider, using the mouse’s X-position to control the amount of bend. I mapped the value of the 800 pixel width box to match our minimum and maximum pitch bend values, 0 and 16383 respectively:

public void setup ()
	    size(800, 200);
	    midiOutput = RWMidi.getOutputDevices()[2].createOutput();
	public void draw ()
	    line(mouseX, 0, mouseX, height);
	public void mouseMoved ()
	    midiOutput.sendPitchBend(1, (int) map(mouseX, 0, 800, 0, 16382));

And there you have it. The code is checked in to my fork of the RWMidi library and a pull request has been issued. I checked in a pre-compiled library with this functionality added as well.

Creating a pitch bend slider on the screen is small potatoes with functionality like this. My sketch should only serve to get you started. You should think about mapping other more exotic pitch bend controls to this method. Perhaps a sine wave generator, allowing you to change the pitch somewhat like an LFO would. Perhaps you can make the pitch “wobble” when the mouse tracks over some position on the screen? That old MIDI keyboard on your desk can already bend the pitch with a slider, how can you take this functionality and make something unique?

RWMidi, GMS, and GOL Sequencer: Adventures in Social Coding

Many moons ago, I created a little tool called the GOL Sequencer Bank. You can read more about it here, and here. In order to create the tool, I used RWMidi, a Java/Processing library created by Manuel Odendahl of Ruin&Wesen. While creating the sequencer bank, I discovered that the RWMidi library had no support for MIDI Sync messages, preventing me from syncing the sequencer with a master, like Ableton Live. This simply would not do.

In the past, I would have looked for another library, but given that I had the source readily available, and had already written a ton of code interfacing to RWMidi, I decided it would be a better use of my time to modify the RWMidi library to support sync messages. You can read more about that here. The changes were minimal, and I learned a lot in the process about MIDI, Java, and the art of modifying open source.

Not too long after that word got out that I had made this change to the RWMidi library, and I started getting one-off requests to send my modified library to folks for their own use. For instance, John Keston over at AudioCookbook built his GMS synth using my modified library.

A short time after that, Mr. Keston approached me with what I thought at the time was a strange requirement: modify the library to support greater than 24PPQ for recognizing 64th and 128th note resolutions. In plain English, John wanted the GMS to support 64 and 128 notes using plain-jane MIDI clock. I thought it couldn’t be done, but loved the challenge, and modified the RWMidi library accordingly. It was a doozy.

These modifications to the RWMidi library have only been available as a custom change to the GMS and the GOL Sequencer Bank, but now, through the power of GitHub and social coding, I can make these changes available to anyone who wants them. I have forked the RWMidi library on Github, incorporated the changes there, and issued a pull request to Manuel to include them in the main source.

You can check out the source here.

I have also built a jar file and included it as a download on GitHub. You can get it here.

Having finally discovered the beauty of social coding, I plan on eventually uploading the source of both the HarmonicTable and the GOL Seqeuencer. I’ve had requests in the past to make changes to the synth that I just don’t have time for, this way people in the know can simply fork the source, make their own changes, and ask me to pull them into the main body of work.

As more and more regular Janes and Joes become savvy programmers (i.e. our children), I expect we’ll see the power of social coding change the way we think about how software is made in general…

Harmonic Table 0.5: Midi Input & Lit Keys

While I thought the GOL Sequencer Bank would get the bulk of my attention this Winter, it turns out I’m getting far more requests to update to the Harmonic Table controller. Among them were Midi Input capabilities, buttons lighting up, and some bug fixes here and there. All that completed, I give you Harmonic Table 0.5. Here is the breakdown:

Midi Input – This feature allows you to accept midi note on and off events and display them as key presses on the main screen. I see this as a learning tool that allows a user to easily see the relationships between notes. Note: At this time it is difficult to keep up with a rapid number of midi input messages. If you’re using this as a learning tool, it is recommended that you reduce the tempo of your sequencer so you can see these relationships without missing any notes.

Midi Thru – This is just another aspect of midi input. When this is turned on any messages appearing on the midi input will be mirrored to the midi output you have selected

You can download it here: HarmonicTable 0.5

Lighting up buttons and accepting midi input introduced a few performance related bugs, but nothing that should keep anyone from using the tool. I’ll have this cleaned up in a future release.

The main target in the next release is touch screen support. I’m getting a lot of great info offline from a few people who are interested in testing this for me, so look for that very soon.

Converting 24PPQ Midi Sync in Java/Processing

midi_logoI would be the first person to say that for the most part, MIDI is perfectly acceptable as an interface between musical devices, and has survived for as long as it has because of how dead simple it is. MIDI is still plenty fast, and in terms of interoperability, has yet to be bested. However MIDI does have its shortcomings, and while helping John Keston over at AudioCookbook with his Gestural Music Sequencer, I ran in to a big one.

Way back in the day, I can only assume before Mu-ziq and BT, MIDI clock was implemented at a rate of 24 pulses per quarter note. This means that when you press play on your sequencer, the devices that are synced via this clock hear 24 pulses for ever quarter note, and as a result can playback in time along with these pulses. After 12 pulses pass, you would move by an eighth note, 6 pulses a sixteenth notes and 3 pulses a 32nd note. You should see that as soon as I try to drop to a 64th note resolution, I’m in trouble. How do I wait a pulse and a half if all that I’m relying on is the pulse to tell me when to move forward? I’m sure that while scoring the soundtrack for Legend, Tangerine Dream were perfectly happy being able to sequence 32nd notes, but how am I supposed to start an Aphex Twin cover band without 128th note stuttering beats and retrigger effects?

There are ways around this of course, you can use the native time code in your sequencer or application and just use SMPTE frame based timing to keep it all in sync, but if you’re writing a simple step sequencer to interface with some master sequencer, this is a huge hassle. Whats a guy to do? Convert it!

Conceptually, the steps to do this are simple:

So, if I want to convert 24 ppq to 96 ppq, I divide 96/24 to get 4. This means that for every pulse I get from the master sequencer, I should generate 4 pulses for my local sequencer. Now, look at the time of the first pulse, and subtract it from the time of the second pulse. Lets pretend I get something like 100 milliseconds. So at this point while the master sequencer will be sending me pulses every 100 milliseconds, I should generate pulses every 25 milliseconds. Then just do this for every pulse I receive (in the case that the time changes and I need to reduce or increase the amount of time between pulses, in the case of a ritardando or accelerando. Seems easy enough, but how to put it in practice.

I worked on a standalone project in java first. Wired through RWMidi, I passed the pulses from the event handler in my main java class to the Sync Converter, then using reflection mapping passed the newly generated pulses back into another even handler in my main class. I decided that this approach sucked for a few reasons. For one, the performance hit I took doing the reflection mapping twice (Once in RWMidi, then again in my sync converter. Also, this required me to have two event handlers to catch the pulses in my main class, one for the originating pulses, and another for the newly generated pulses. Thinking in terms of an end-user, who would likely not want to go through all of this trouble just to convert some pulses, I decided it would be better to jam the sync converter right in line with the MidiInput class of RWMidi. Since I’m no stranger to modifying that library (I enabled sync in it a few months ago), I figured Wesen wouldn’t mind some additional modifications to his work to create this sync converter.

At first, I assumed the best approach would be to create separate thread that handles the entire timing routine, a thread that would just stay in sync with the incoming pulses from the external sequencer. This approach turned out to be silly after 5 minutes. When do the math, at 120 BPM the MIDI timing pulses are roughly 21 Milliseconds apart. Asking a thread to perform even a simple algorithm like the one proposed above while making sure to send a sync pulse on the arrival from the external reference along with a calibrated “in-between” pulse (every 5 milliseconds, in this case), was asking too much. I tried it anyway, even though the math wasn’t working out, and sure enough, a significant amount of drift was occurring between the external and internal sequencers.

So no dice on a replacement time reference. Perhaps I could let the original pulse fall through to keep my internal sequencer in sync, and create a timer/thread to handle the “in-between” pulses? This approach was on the right course, but failed for a few reasons. I couldn’t the separate thread to wake up quickly enough to send the pulse (or pulses), so would fall behin the external sync every 8 to nine pulses. The result was drift. The timer was closer, but the overhead of creating a new thread per timer every 21 milliseconds (at 120 BPM), was just not cutting it, the result was still a bit of drift.

Frustrated, I did what I always do in these situations and went to sleep. It was clear that I was losing track of the number one priority of the clock, keeping that internal device in lock step with the external device. These in-between pulses are technically superfluous, and won’t even be accounted for unless you drop below a note resolution of 32nd note triplets. I started doing the math in my head. If a 1/4 note occurs every 504 milliseconds (120 BPM), than a 64th note only occurs arrives every 31 milliseconds. Would a listener be able to distinguish if a 64th note were off by a few milliseconds one way or the other at this speed? What is the threshold where individual notes just sound like pulses in an oscillation? I speculated that that threshold is the minimum amount of space I would need between pulses, after that it would just be a matter of sending the in-between pulses as quickly as possible.

In order to find out exactly what that threshold was, I ran a sleep test directly on the MidiInput class. I determined what my sleep time was using the same formula from above, and slept the entire midiInput thread for the determined amount. My assumption regarding this was that my sleep times would be less than the speed that any quantized midi message could possibly arrive, so sleeping would be safe, especially if the midiInput would only be used for sync messages. As I increased the tempo, I found that the threshold was around 5 milliseconds, after that you couldn’t sleep the thread for a short enough period of time to meet the 64th note requirement. Once this 5 millisecond threshold is surpassed, the thread doesn’t bother sleeping before sending the extra pulses, it just blasts them on to the receiver of the messages. I also discovered that this method of sleeping the thread was working just fine, and there was no reason to implement another method.

A few tests and mistakes on my part later and Keston was up and running with synced 64th notes on the GMS. Keep an eye on his space to watch his progress. The next release of GOL Sequencer will also include 64th (and possibly 128th note) capability

HarmonicTable 0.3

Bit slow these days with work and other stuff to get around to some of the changes I’m been meaning to make to these projects, but here is a quick 0.3 stab. I had more changes planned for this release, along with some stuff for playing back patterns and keyboard playback support, but for now I only had time to make a few changes:

That should cover it, you can download it here.

Game of Life Sequencer Bank Beta

I finished up a bunch of changes to the Game of Life Sequencer Bank. Here is a brief overview:

You can download it here

Thats about it. Using the right set of drum patches and timing intervals, this thing generates some mean drum sounds.

Java MidiReference 1.0

Several months ago I started working on a series of classes to make my life easier when programming for music. I’d started several projects and realized that trying to refer back and forth between MIDI Numbers and Notation by hand was tedious, so I created a library of functions to do it all for me.

I finally got around to formalizing this into one library, and released it here. I’ve put this into action already with the Game Of Life Sequencer Bank and HarmonicTable projects, and its really made it easy to pull scales, chords, drum maps, you name it quickly from a preset library

If this kind of thing is useful for anyone other than me, feel free to use it

Game of Life Sequencer Bank Alpha

I wrapped up the Game of Life Sequencer Bank Alpha release (which I’ll probably start calling GOL SeqBank because it’s easier to type). Documentation, downloads, etc can all be found here:

Hopefully it doesn’t break on anyone. I’ve been using it to generate all kinds of random noise successfully for at least a few days now.

Game of Life Sequencer Bank Demo

Some time ago, Wesen of Ruin&Wesen created a screencast of a sequencer based on the game of life concept. I followed the screencast, and thought there was a lot you could do with something like this. I thought of several features, making it a step sequencer, a drum sequencer, perhaps enabling multiple scales. I had some free time (we took a vacation), so I worked on it on the plane and early in the morning while my wife slept in, and came up with the Game of Life Sequencer Bank, a bank of 6 GOL sequencers each capable of individual operation and synced via MIDI. The application uses a modified RWMidi library (to handle sync events) and controlP5. Here is a video that demonstrates it:

Game of Life Sequencer Bank: Demo from Grant Muller on Vimeo.

Here is an audio example:


I’ll spend a few days working out any last kinks and putting together something like documentation, and set it free so to speak. For this project I will likely NOT release the source code just yet, mostly because it needs to be cleaned up (I’d be embarrassed).