Working in technical support for KMI, I am often confronted with requests for functionality from some of our devices that we didn’t include for one reason or another. There’s a variety of tools that you can use for this task, such as Max, Bome’s MIDI translator or Pure Data. All of these software environments can do wonderful creative things with MIDI information, but one of them has a defining characteristic; Pure Data is free, open-source, cross platform software. This means that you can make a solution by yourself, today, for free, that can run on Mac, Windows, Linux and even on a Raspberry Pi. In this article (and maybe more) we’ll look at the basics of manipulating MIDI in Pure Data to give the SoftStep2 four triggers on each pad.
First things first, you should download Pure Data and install it. You can find information and downloads at puredata.info. It comes in two flavors, vanilla and extended. I will be using a few objects from libraries that are not included in the vanilla release, so I recommend that you download and install pd-extended. After that, let’s grab our SoftStep, plug it in and quickly setup a preset that gives us position data for both the X and Y axis. This can be done in either the Basic Editor by assigning X/Y to a key, or the Advanced Editor by using two modlines, one with X Live as its source, and the other with Y Live. Set the X CC to 0, and the Y CC to 1 to follow along.
Once you’ve gotten through that process, let’s open up Pure Data and create a new patch by hitting cmd + n or selecting New from the file menu. If this is your first time using pd, you might be a little intimidated by a completely blank slate that is presented to you. It’s a little scary if you’ve never built a tool before, but it should also be exciting. We are in control of exactly what this piece of software will do. And what we want to do first is get some MIDI data going on. First, navigate to the MIDI preferences and select SSCOM 1 as your input, and whatever virtual MIDI port you will be using for your output and hit Apply (MacOs has a built in solution for this, Windows users may have to use something like MIDIOX). A new patch defaults into edit mode (you’ll see a cool little hand icon) and we can immediately start adding objects. Press cmd + 1 to create a new objet (or navigate to the ‘Put’ menu) and type in ‘midiin’ this will receive the MIDI from SSCOM port 1. If you create a ‘print’ object and connect the left outlet of midiin to the inlet of print, you’ll be able to see the MIDI data in the console.
As you can see this is raw MIDI data, so we need to translate it to something that’s easier to read and work with. We could make out own data parsing system to, but that would be a lot of work. So let
‘s just use pd’s built in solution, and create a new object with the name ‘midiparse’. This objet parses the raw data into categories we are all familiar with, like CCs, notes, and Program Change messages. Currently, we have no idea which outlet does what, to find out how an object works, right click and object and open the help patch. You can see in the help patch that the third outlet sends out CC data as a value/controller number pair. In order to process each CC independently, we will want to test for which CC we receive, either 0, or 1. Let’s create a route object, and give it arguments of 0 or 1. If we match either 0, or 1, it will pass the rest of the message out of the corresponding outlet. Before connecting the outlet of midiparse to our route object we will need to switch the order of the list. There are a host of list processing objects included in pd-extended, and we will be using the list-rot object with an argument of 1. Now let’s connect midiparse to the list-rot object, and then connect that to our route object. If you connect number boxes (cmd +2) to the outlets of route and manipulate your ss key, you should see the values in the number boxes.
Now that we have our CCs, it’s not much work to get four triggers from it. The way that the X/Y data sources work on the SS is pretty simple, for the X axis, 64 is dead center, less then 64is moving to the left, and more than 64 is moving to the right. So if we wanted to detect when the left or right side of the key is pressed we could simply check if the CC is less than or greater than 64.
This does work, but is a little too touchy, it might be wise to implement some sort of threshold control, to wait until the data is a certain distance away from center. This can easily be done with a few math objects as seen here:
Now we just have to add the sel object to test for a 1, duplicate that whole construction for the other CC value and we should have 4 triggers for each corner of our key! Let’s just make them shoot out a number from 0 to 3, create a MIDI note from that number using the makenote object, send it to our MIDI output, and we successfully create four separate triggers with an adjustable threshold.
Of course if we wanted to setup multiple keys we would have to duplicate all of this and manually change all of the route objects and the messages that are spitting out our notes. This can be tedious, and makes your patching more prone to human error and bugs. That’s where abstractions come in. We can bundle all of the data processing into an abstraction that we can then create like any other pd object. We can give it arguments so we can define which CCs. Lets create a new patch and copy all of our code from the previous patch, except for the objects above the route, and the two objects that are creating and sending our MIDI notes.
To get data into our abstraction, let’s create two inlet objects: one going to the route object and one going into threshold math objects. Now replace the arguments in the route object with $1 and $2. Those are variables, and can be defined by arguments we will use when creating this abstraction in the main patch. Then add an addition object with an argument of $3 (this will define where our four MIDI notes will start). Finally you can add a loadbang object going to a message to initialize the threshold value to 1. Save this patch with a descriptive name in the same directory as the main patch (I named it FourCorners).
Now, back in our main patch, create a FourCorners object with arguments of 0, 1, and 0. Connect the output of the list-rot to the first inlet, and the outlet of our threshold control to the second inlet. This object looks for CC values of 1, and 0, and will spit out four MIDI notes starting at note 0 . This allows us to quickly setup four triggers for all ten pads if we wish, all with a threshold control that is easily adjustable from the top level. Our finished patch looks nice and tidy, with comments making everything clear
This is just one of many feature requests that almost anyone can accomplish with a little time and some willingness to learn pd. You could easily incorporate more complex behaviors such as conditionals, inc/dec schemes with speed mapped to pressure, keys influencing that states of other keys etc. There are a lot of possibilities. If anyone has any requests for features they’d like to see implemented in pd, drop me a line at evanbeta@keithmcmillen.com