Seq24

So, you can get Seq24 for Windows, but without a way to pipe it to PureData it's not much use.  In Linux this seems to basically be done out of the box, although I offer you one warning: disable Jack support for Seq24, as this seems to result in what I'm calling the "Keyboard-Butt of Doom Crash" where Seq24 freezes in a loop and sprays MIDI messages at maximum bitrate until anything looking at the port has a heart attack.  (Or disable ALSA, I think it might be you can have one but not the other...)

BUT, once you get past that, Seq24 is a totally indispensable companion for PureData.  Seq24 will send MIDI messages with channels attached, allowing PureData to peel them apart from each other.

With this setup, I now have all the features I used to get with the ancient Voyetra tracker, except that the MIDI patches are all of my own design.

While PD can definitely do sequencing (and do a ton of tricks Seq24 could only dream of), you have to build your own piano rolls, which is not only tedious but prone to errors, and PD's selection of widgets is pretty limited unless you go out fishing for plugins.  Seq24 fills a gap in the capabilities of the PureData + Ardour juggernaut that kept me from really jamming with loops.  Loops in Seq24 aren't just easy, they're intrinsic to normal operation, IE effortless.

And as always, remember that MIDI messages coming into PureData don't need to be interpreted as simple notes.  You can do anything with them, so your coded sequence in Seq24 might actually be tied to a channel dedicated to tweaking your synth or reverb settings.  One patch and one stored Seq24 MIDI file could be a complete, nondestructive performance, and as I've discovered, you can pipe multiple audio channels to Ardour separately, which means Pure Data can be meticulously peeling each one of the instruments in your ensemble apart and pushing them through their own channels for Ardour to record separately.

Now THAT'S a Digital Audio Workflow.

The following, is freaking sweet:

Both of these are pretty simple bits of code, trivial really, but look at what's happening here.

My Arduino board is talking to Pure Data.  Not only that, but it's doing so in a tidy, scalable way.  Here's how it works:

The Arduino program waits to see a character (any character) appear on the COM port.  When it gets one, it waits 10ms and sends one byte, then another 10ms and sends another one.  I've made them have different behavior so I could tell them apart for debug, but they could be anything.

The Pure Data side sends a random number to the COM port when you click the top bang.  Doing this also resets the packet counter on the right.  Each received byte increments the packet counter, which is then used with my crude routing spigots below, so that each byte is allocated, in sequence, where it belongs.

If I did a long list of sends (say, one for each potentiometer on a nice big loaderboard) from the 'duino, it could sort these too.  I can now build arbitrary input hardware to talk to Pure Data.  How sweet is that.

Get the Pure Data Patch
Get the Arduino Code

Sampling

So far I've been learning synthesizers, directly "inventing" sound from known, easily-made mathematical waveforms.  Today I've got some recipes for sampling with the microphone (or other audio equipment).

First, basic sampling.  With an array called loop01 stuffed into its own patch (better for various performance reasons), I set up a bang to trigger the tabwrite~ function and put half a second of data into the array.

This streams straight in from the ADC and into the array, which I've made 22000 samples long to store half a second of 44000Hz data.  (Working on a more sophisticated version of this patch that'd have adjustable length, but one thing at a time.)

Next, playback.  I had a lot of fun hooking up a phasor~ object to the tabread4~ block and sliding it around, but for simple sampling, just feed it a vline~ that goes to near the end of the array based on an input argument.

My input argument here has been hacked up a little so that middle C on my nanoKey leaves the pitch unaltered.  This creates the (wrong, but useful) impression that the sample is taken at "normal" and the MIDI keyboard slows it down and speeds it up depending on how high or low you go.  I wired the "mod" button on my keyboard to take samples, but the bang is accessible in case you don't have that particular feature.  I also put a slider in so that if you're using this without a keyboard, everything will still work.

Before I go to the more sophisticated sampler with polyphonic MIDI control, I want to thank GuitarExtended for this excellent patch for detecting sounds at the input.  I appropriated this into a patch called threshbang which I used to give the next version of the sampler the ability to detect things like claps or vocalizations and trigger the sampler.  (Its details are currently beyond the scope of the blog, but I've included it so the whole polyphonic sampler patch works.)

Packing the note interpreter, pitch shifting part, line generator and tabread4~ object all into a subpatch and then duplicating it up for polyphony works about the same as for any other sound effect, but now the keyboard can play chords of whatever sound you've put into the half-second memory space of this simple patch.

Sampling and pitch-shifting sounds from around the desk quickly yields a lot of rich sound, and I can't wait to store all the funky audio I'm getting from this!

Today's Files:
Simple Sampler
Polyphonic Sampler
"Bang on Threshold" generator

MIDI Basics

So basic MIDI capability. This is a picture of roughly the simplest polyphonic MIDI patch that will work and play multiple notes, plus a little side demo that shows off how this also can be used with "ordinary" generated notes.

The nice thing about this is that this gives you general polyphony for your projects-- not just if you happen to plug in a MIDI keyboard. (By the way, I'll be using the Korg nanoKey, which for the money is about the best damn keyboard I can imagine getting. It's utterly miniscule but has two octaves worth of velocity sensitive(!) keys and a pair of shifter buttons to allow 10 octaves total from one little keyboard, and that's before you do anything with PD.

So, quick breakdown of functionality.  First we have a notein object, which is how you get MIDI messages into PD.  The 1 in the argument list is a channel select I think-- so far I've just left that filled in.  From there, into the poly object, which does the tricky work of polyphonic splitting.  In Pure Data this is handled in a pretty straightforward manner: the poly object just passes the message along, adding an integer indicating which of the N voices it's directed to, where N is the first argument.  (Here I used 3 to save visual space, but I usually use six so I can play two simultaneous chords.)

Everything up to this point has been ordinary, single-element messages, but as of the pack block, we now have a single wire sending ordered triplets, whose pattern is: [voice, note, velocity].  The route block uses the first element in the message (the "voice" element) to select to which of the three voices the note message will be sent.

In this way, if I hit three notes simultaneously on my keyboard, they'll show up at the notein block in (very) rapid succession, where the poly block assigns them a voice, and then the route block sends each of the three messages to its own unique player below.

The players are identical.  Each consists of an unpack statement to split apart the message back into note and velocity, a square wave generator fed by the note message, and an ead~ envelope generator set to trigger only on non-zero velocities.  (This is because zero velocity is MIDI for "shut off the note" and is triggered by releasing the key.)

The results are summed at the output and you get polyphonic square waves.  This configuration isn't hard to feed with your own data either-- just make sure you provide a nonzero velocity message simultaneously with your note, or as shown earlier, nothing will play.

Download the patch

MIDI: Polyphony Is Hard, Deal With It

This part's just fundamental, if you do polyphonic MIDI in PD, it's gonna look like this:



And that's if you don't have arguments on that oscillator. That's why I'm learning how to use route, select, etc for message handling, and so far, it ain't pretty...