Grant Muller

I’ve had several chances to play my new setup now, including the Mandala. I played a live gig (recording to come) on Friday of last week, and learned a few lessons. Now that I’ve got things under control, I started to create some basic kits in Battery for my Mandala.

The Mandala is capable of subdividing into 7 zones. For a 10 inch surface that’s a lot. It’s really great for emulating snare sounds, and extremely realistic percussion (you can effectively assign any number of samples to these zones, velocity map them, and have a “real” drum). But I don’t need that. I have plenty of drums.

My first little attempt at a custom kit for the Mandala is a riff off of the tabla kit released a while ago. I found that 3 zones per pad is my ideal number, so this little snippet features about 30 samples mapped over 3 zones. Each zone is actually only one “instrument” of course, but velocity mapping dictates that I have more than one sample per zone for a more realistic implementation. Here’s a little sample of my drums and the Mandala working together.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

When we bought our house a few years back, I finally had enough space to consolidate all my music gear into one space. I had big plans for my basement studio. Mix desk over on one side. Wall-mounted monitors. Jute coffee sack sound baffles and just the right location for recording the drums. Later I found a place for my pump organ, and of course a myriad of other instruments strewn here and there. Over a year or so, I managed to make all that happen. The result has been rather…terrible.

After I spread everything out, it became clear that recording with just little-old-me was slow if not impossible. If I wanted to record drums, I had to press record, and walk over to my drums to do it. Not a big deal if I’m just going to cut it all in post, but what about punch-ins? I’m also lazy. If it takes me more than 2-3 minutes to setup and tear down to make some sound happen, I just won’t do it. I’m not into setting up, tuning and perfecting the timbre for an hour dammit, I’ve got a melody in my head now.

I thought about my past work, stuff I’d done for an EP and a full-length a few years back and realized everything I have ever recorded I’ve done in a tight space, with just a few things, without a big setup. As a lone wolf in the studio, I don’t have a team to put things together for me, press record and punch when I need, and patch up my instruments. If I was going to continue doing it myself, I was going to have to make some changes. So I did.

I started by ditching my Digi001. This was an old recording platform released by Digidesign about a decade ago. I loved this thing, but it was really starting to age, not to mention it only had 2 mic preamps. I traded it for my Presonus FP-10…which I’m so far very impressed with. 8 Mic preamps, and I can use it with any software I want (previously I was tied to Pro Tools). All in one rack unit. Done.

Next was the mixer and cabinet. With 8 Mic preamps in the FP-10, why do I need a mixer? I ditched it (eBay style), and the rack I had it mounted in (which I had built many years ago…it’s ok to destroy the things you create). This freed up a lot of space, and of course, freed up my hands.

After that it was bye-bye desktop. It required a monitor, keyboard, mouse, blah blah blah. Gone. As of now I’m doing everything with a laptop. Yeah, I know Kid606 and other people cooler than me have been doing this for years. I don’t care. I’m old school or something.

So, down to a laptop, FP-10, mics, drums, a controller keyboard, and a bunch of random instruments. Now what? Round ‘em up:

I set up in the round so that everything would be right at arms length. I’m primarily a drummer, anything else I do is purely piddling around, so I made the drums the focus by setting up the mics (Recorderman Style) specifically for recording them and my Mandala. Couple overheads (Samson C02’s), Kick, 2 on the snare (Shure SM57), and some crappy tom mics. To my left I threw together a keyboard stand with the FP-10 and a place for the laptop. Right behind me is a controller keyboard, so if I want to throw together a cheesy bassline for the rad beat in 25/8 time I just wrote, I can do it immediately. I just spin around to make music. Mostly.

So the idea is that I’ll write here, and when I feel pretty comfortable everything is ready, I’ll take it to the mix desk, where those coffee sack baffles will really help out.

What’s next? I just got word that a friend is selling an old electronic kit. Since I’m basically a drum machine, I’ll pick that up and include it in my little round here…maybe right in with my current drum kit. We’ll see if this works…I played this silly little drum lick to test the mics:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

It’s been a while but I finally found some extra time to slap a clear coat on my Schwinn redux. I saw “I”, but really my father-in-law took care of this one. Its delicate work, and I’m just not in to that. Maybe next time.

Clearcoating is really to hide and protect. It masks any blemishes that might be left on the bike, and protects the coats of paint you slapped on previously from rust, nicks, and other marring. It serves a third purpose of course; it makes everything “pop”. The red on against cream look was already a nice contrast, but with the clearcoat applied the red really went from bright to ostentatious…in a good way.

I don’t have any pictures of it to describe it, but the chemicals involved in this process are a bit more noxious than anything else we’ve used in this project. Respirators were a must, and the manual was consulted to get the exact chemical composition nailed down. Rick was extra-extra careful on this one:

The clearcoating itself went on in 3 stages, all applied with the same airbrushes we’ve been using thus far. First a “dust coat” was applied, to fill any gaps and lay down a rough surface for the rest of the coats to stick to. Next a thick layer of clear was laid on. Finally, we wrapped it all up with some touch-ups and gap filling to complete the job

The results are excellent. I don’t think I expected the bike to transition from nice to sexy quite as much as it did. You heard me. Sexy. See the photos.

Next up, we’ll re-cable and rebuild the components on the bike. It’s going to be ready to ride very soon…

I 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:

1. Intercept pulses
2. Subtract the space between two pulses(in milliseconds)
3. Divide this value by the quotient of your conversion divided by 24 (to get n milliseconds)
4. Start a thread and send out a pulse to your sequencer every n milliseconds

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

For all those paying attention, you may notice that I’m posting with less frequency. This is normal. The fact is, its getting warm again. When that happens, I spend more time outdoors, getting my triathlon on, reading in a hammock, or making my yard happen than hanging out on my computer. When the cold happens again, I’ll be back in front of my computer writing code, or making electronics happen, and other indoor projects. Expect fewer posts for the next few months.

With all the painting done its time to move on to puttin’ fancy stickers on the bike. It occurs to me that I didn’t post a picture of the bike with the paint all finished, so here is a shot:

Looking pretty slick. I ordered two sets of decals for the bike from eBay. If you do a search for whatever bike brand and decals you’ll come up with hundreds. In retrospect I should have looked for Roll-Royce decals, hindsight is often hilarious. I kept it real though, and ordered a set of Schwinn feathers and a set of Schwinn Black Phantoms. The Prelude (what the bike formerly was) came with some pretty 80’s decals, replete with scan lines and big bold beautiful Helvetica, so even if I could find some of replicas of them, I would have gone another direction. I ended up not liking the Phantoms. They were a little big and not as elegant as the the feathers. But, the Phantoms did come with a nice red and gold Schwinn badge, which I ended up using.

Putting decals on is pretty easy. Cut them up into sizes that are manageable, soak in lukewarm water for about 30 seconds or so, then set them into the area you want them on the surface. Oh yeah, clean the surface first. Once you get them where you want them, peel back the backing layer while holding the clear decal layer, making sure that the decal stays where you want it. This being detail work (which I’m miserable at) I just let Rick take care of the three decals

It looks a bit, or exactly, like this with all the decals on:

Next, slap a clear coat or two for protection (and of course to cover up some blemishes), then put it all back together and get it on the street.

Its been a few weeks, but I finally moved on to the last of the painting over the weekend. In the previous post we painted the frame in its entirety with a primer and the cream colored base coat. We did a test with the red paint for the lugs and details on the fork, and it looked excellent, so we continued using the same process on the rest of the frame.

Cary spent a week’s worth of evening taping off the frame, afterwards I realized that selecting cream instead of “blue-painters tape” for the base coat was a good idea. We hung the frame up in the paint room and went to work on it with the small Iwata airbrush. Maneuvering around the fork was a bit easier than the whole frame, but overall things went smoothly.

I’m not fantastic with the airbrush yet, so Rick had to clean-up for me from time to time:

Some of the details work was delicate, but with Cary’s knock up job taping everything off, I could pretty much apply my usual brand of recklessness without being too worried I’d screw it up. Here’s how it looked all taped up with paint attached:

Cary is currently referring to it as the Superman bike until the tape comes off (Rick took the tape off a day ago and as I understand it, it looks incredible, I’ll get a picture posted soon).

Next post is decals and clear coating, which should wrap up the decorative portion of the redux. After that will be the bike reassembly, recabling, etc.

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:

• Chord Mode – Chord mode allows the user to hold down a key on the keyboard and play a chord when a note is clicked. The chord map is on the release page.
• Chord Lock – By default when playing a chord by pressing a key, the chord only sounds while the key is held down. In chord lock mode you need only press the key of the chord you want to play, and any note you click after that will play that chord
• Various Performance Fixes – Nothing special here, moved some stuff around and improved map loops to speed the whole thing up a bit

That should cover it, you can download it here.

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

• UI Overhaul – Rather than trying to stuff all the sequencers into 1 window, I gave them each their own tab. So now you have 6 tabs across the top with an independent screen for each sequencer. This allowed me to create a 32 x 32 grid rather than just a 16 x 16.
• Internal Sync – Previously it was necessary to sync the sequencer to another device to get it to play, I implemented an internal metronome thread instead. The sequencer now works independently if you like.
• Update Time – Added this option to increase the interval that the game updates, rather than just waiting for the sequence to end.
• Kill Notes – Its working now. If you activate this option only one note at a time will play from the sequencer. Not effective in ORIGINAL mode.
• Various and sundry additions – A few more modes added to the scale option, triplets added to the timing sections.

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.

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