Archive for September, 2011

Replace Apple MainStage with a Custom Max/MSP Implementation (Part 3)

September 24th, 2011 2 comments

The earlier articles are

Part 1

Part 2



I know I was supposed to write about the front panel user interface in part 3 but I got very distracted after deciding it was time to add VST support to my implementation. Up until now, Max has only been involved in MIDI routing to external synths and I was really keen to be able to leverage all the soft synths that I had acquired over time to use with MainStage.

MainStage only supports AudioUnits and Logic Studio proprietary synths and max officially only supports VSTs (although a beta au~ Max object is available here) but the good news is that pretty much all third party softsynths are provided in both AU and VST formats.

Max has an object called [vst~] but it’s quite complicated to configure. For example, take a look at the example from the Max documentation.

I’m not going to explain this here as the point of the article is to encapsulate all that stuff into a more usable form. If you want to know more about the underlying operation, see this documentation. The only thing important to note here is that all (and I mean all) control messages are sent through the first inlet.

My goal was to make it really easy to create “instruments” and use them in song patchers the same way as external MIDI synths are already supported (see my original article).


The key object I created is called GenericVST and it takes one argument, the name of the VST that you want to use. Here’s one that loads the free Crystal VST. By the way, if your VST has spaces in the name, then the entire name should be enclosed in quotes.

This object has 9 inlets and 2 outlets. The two outlets are Audio L and Audio R respectively and can be connected directly to the system audio output (see below) or can be connected to the audio inputs (the last two inlets of the object) of another GenericVST object for effects processing.

Inlets (from left to right)

  1. Patchname
  2. Notes
  3. Aftertouch
  4. Pitchbend
  5. MIDI Channel (defaults to 1)
  6. VST Param (see below)
  7. Quickedit the VST GUI (send a Bang in here)
  8. Audio L in
  9. Audio L out

Here’s an example patcher that uses the above object.

When this patcher loads, the following steps occur:

  1. The VST called Crystal is loaded
  2. A previously stored synth patch (SadStrings) is loaded into the VST

Four inlets are exposed, used to send MIDI notes (note number/velocity pairs), aftertouch, pitchbend, and MIDI expression (CC 1) values into the VST. Understand that these inlets represent how the VST will respond to incoming values. For example, you don’t actually have to send the aftertouch value from your keyboard into this inlet. If you connect a slider on your control surface into the aftertouch inlet, then the slider will cause the VST to respond to whatever effect is associated with aftertouch.

Now, why does the fourth inlet have the extra object (dhj.vst.midi.CC) in the path? Well, remember I mentioned earlier that all messages to a VST are sent in through a single inlet of the [vst~] object. Among other things, that means you can’t just send raw MIDI data into a [vst~] the way you can send them into an object representing an external MIDI synth.

They have to be wrapped into a special message that consists of the symbol midievent followed by the appropriate number of bytes for the desired MIDI event. For MIDI notes, aftertouch, and pitchbend, this has been done inside the GenericVST (as we will see in a future article). However, because there can be many different CC numbers (128 in fact), it’s not practical to create an inlet for each one, particularly since only a couple are ever likely to be used in practice. We will come back to this object later.

GenericVST Presentation Mode

Let’s first look at what happens if you double-click on the GenericVST in a live patch.

We will examine parts of the internals of this object later. The buttons let you quickly edit the VST, save the (possibly edited) settings and reload settings. By default, the textfield containing the patch name is whatever was initially loaded but you can change the name to something else before you save. If you are actually creating a derivative sound as opposed to just modifing the sound for the main patcher, then you will want to copy the instrument patcher to a new file and then change the patchname message inside it to match your new name.

The parameter fields show you what changes when you adjust parameters in the VST editor. This information is used in conjunction with another object called [VSTParam] so that you can easily associate any slider, knob or button on your control surface with any parameter in the VST. We will examine the [VSTParam] object shortly.

If we click the button “Edit the GUI”, the VST’s GUI editor is displayed.

Now, here’s the key concept to understand. Every parameter in a VST is represented by a unique integer value and the value of each parameter ranges from 0.0 to 1.0 and that’s all. This is true whether you are changing the position of a slider, selecting a different value from a drop-down combo box, or adjusting one of the points in a graphic envelope. Anything that changes the actual state of the VST behaves this way. Buttons and menus that just show you a different view or page of the VST have no effect.

As you change parameters, you can see the index and new value in the Max window. Here are some examples.

Moved Voice 1 all the way to the left

Moved Voice 2 all the way to the right

Moved the yellow point to the right

Mapping MIDI CC data to VST values.

MIDI control change values consist of a controller number between 0 and 127 and a value for that controller, also between 0 and 127. A VST with 1800 parameters (say) will have parameter indices from 0 to 1799 and values between 0 and 1. How then do we arrange for a slider on your control surface to control the Voice 1 parameter in the Crystal VST?

The VSTParam object

Lets look at the purpose one one specific inlet for the GenericVST object by hovering the mouse cursor over it.

As you can see, the inlet expects a MIDIEvent or a VSTParam. OK, so now, here’s a patch that lets you control the Voice 1 parameter from the first slider of an Akai surface.


The AkaiSurface object encapulates a collection of sliders, knobs and button controls and each outlet sends out a single value between 0 and 127 representing the position of the corresponding control. Note that this is NOT a full MIDI message, just a single value. So how does a single value between 0 and 128 get converted into the desired parameter index and value between 0.0 and 1.0 that is required?

First of all, note that the VSTParam object takes a single argument that will represent the parameter index, which for the Voice 1 parameter is 55. Let’s look inside the instanced VSTParam by double-clicking on it.

The first two parameters of the [scale] object represent the minimum and maximum values of incoming data. The second two parameters represent the minimum and maximum values of outgoing data and actual incoming values get mapped linerarly into the required output value. For example, an incoming value of 64 representing the half-way position of a slider would come out as 0.5 which is half way between 0 and 1. The [sprintf] object then formats the parameter and value into a new message which is sent out (and therefore sent into the VST. Note that the [sprintf] object already has 55 in it. That shows up because of how we created the [VSTParam] in the first place with 55 as its sole argument.

So if you want to control the filter cutoff frequency, resonance, LFO frequency and perhaps the filter decay from an ADSR, then all you need to do is “wiggle” those parameters on the VST, watch what value is displayed in the parameter index, then create a few [VSTParam] objects with the associated parameter indices and connect them up. For example:

To encapsulate this into a standalone synth that exposes just these parameters but can be controlled from different surfaces (say), just replace the inputs to those VSTParams (and the other inputs of the GenericVST itself) with inlets as follows.

I saved this patcher with the name LeadSaw and now I can create a new patcher that just uses this one.

This new instrument can now be used just like any external MIDI instrument by connecting keyboards and surfaces as desired. For example, here is a complete patch that uses my Yamaha AN1x to control this synth where the the modwheel is used to control the envelope decay and my expression pedal controls the filter cutoff frequency, which is the essence of a wah-wah pedal. The first three ports (outlets to inlets) are notes, aftertouch and pitchwheel, which is my standard for all objects representing keyboards.

In part 4, we will disect the GenericVST object itself.


The earlier articles are

Part 1

Part 2

Categories: Music Technology Tags:

Why we created Scorecerer – a brief history of our local universe

September 21st, 2011 No comments

While there have been a few devices around to display music notation, the problem was that it took far too long for me to actually get my sheet music into those devices. As a technologist and a serious amateur musician, I always wanted to use one of those devices and so many years ago with great excitement I bought a MusicPad tablet. However, I found that the process of pulling in my sheet music was painfully slow and I had to use external image processing software such as Photoshop to clean up the scanned images and so forth. Consequently, it took about 5-10 minutes to import each page of sheet music. No way could I afford to spend that amount of time.

So I ended up not really using the tablet for anything serious.

Years later, along came the Kindle DX from Amazon. This thing had the ability to display images and PDF files and I thought, if only I had an easy way to get my sheet music into it efficiently, this could be really cool. So along with my partners, we created Deskew Technologies, LLC. By the way, the word “deskew” (pronounced dee-skew) means to straighten. Amazingly, the domain was not taken so we grabbed it.

We build the first version of the desktop application, which allowed you to just drag scanned images into it. It didn’t care too much about the resolution, gray-scale, color or other “stuff” that one normally worries about with scanners. Nor did you have to worry too much about getting the paper perfectly aligned or straight. Just thow the page on the scanner and save it on your computer. It also understands most popular image file formats so you can just use whatever format for which your scanner is currently configured. No need to make sure it’s suitable for Scorecerer. Scorecerer would then straighten the music automatically as well as remove empty borders so as to maximize the available screen space. It could then “publish” the music directly to the Kindle DX optimized to display nicely and as fast as possible. All of these operations were designed so that you didn’t have to spend any time “futzing” to get it right. So with Scorecerer, the 5-10 minutes became 5-10 seconds, or at worst just slightly longer than your scanning speed (because it takes a second or two of your time to actually drag the scanned images into Scorecerer Desktop!)

It worked very well but the speed at which the Kindle DX could turn the page was not-so-great so although it was usable, it wasn’t wonderful.

We also built Scorecerer Player, an application designed just for displaying Scorecerer processed sheet music on a laptop. We figured that Windows-based tablets would arrive and perhaps even a Mac OS-X based tablet was on the cards. Scorecerer Player is still included as part of the Scorecerer package and it also supports remote MIDI so you can turn the page by pressing a button or a pedal on your MIDI rig.

Then we heard that the iPad was coming. We signed on to the Apple Developer Program, got the iPad SDK and built a “Player” for it. Scorecerer Desktop could now publish in a format optimized for the iPad and boy, were we happy with the page turning speed. We submitted Scorecerer Ipad to the app store in time for the launch.

We added wifi-based publishing recently so you don’t have to depend on iTunes to transfer sheet music. This is particularly worthwhile for those people who have hundreds or thousands of songs. There’s a quick search built into Scorecerer iPad so you can quickly find the song you need.

We’re still adding new features, based on feedback we’re getting from users. Feel free to contact us through our support center with your own requests.

Categories: Musings Tags: