Darwin Grosse

One of our most popular article series was the Max 5 Guitar Processor, which built a guitar processing rig by creating a number of connected components. Since the original was published, there have been a number of changes to Max - from the look of patches, to patching 'standards', and even to the available components. We felt like it was time for an update to this series.

In an earlier article, Andrew Benson and Ben Bracken went through the process of connecting a guitar to a Max-based processing system, and creating a few guitar-oriented effects patches. In this series of articles, I will be building a Max-based guitar processing "rig" and will give you the opportunity to look over my shoulder as I design and implement this system. 

The first thing I did was to plan the processing chain that I would create. I wanted a rather typical guitar rig, with the addition of a looping delay line. I decided on the following functional graph:


I also made a few decisions about general program functionality. Since this will be a stand-alone program/patch, I wouldn't worry about limiting system resource usage; therefore I wouldn't wrap subpatches inside of poly~ objects (which could reduce their CPU load when unused). Also, I decided to take full advantage of Presentation Mode, allowing me to code in a convenient way and worry about the performance layout in a separate step.

Since I am a dyed-in-the-wool tweaker, I wanted to structure the code in such a way that I could manipulate it easily - even during live performance. This means that I needed to create an easily-to-follow patch that was well-labeled, and I needed to encapsulate at a level appropriate for on-the-fly changes. Finally, in order to build this quickly, I will beg, borrow or steal as much of the programming as possible without resorting to the use of VST plug-ins (which would reduce tweak-ability). Throughout these articles, you will see me reuse older code, appropriate from other applications and use third-party objects whenever necessary. I also take full advantage of some design patterns I've developed that allow for quick coding of more complex patch routings.

Since this is a stand-alone patch, we need to control our own input and output. Let's start by creating an input section. If you open the patch Max8-GtrProc-1.maxpat (link?), you will see that I have used panel objects to split the patch into segments that correspond to the functions described in my processing graph. Place the patch into Presentation Mode, and you will see that these segments jump into a "rack style" package that is easy to follow during performance.


Move back into Patching Mode, and look at the top-left section of the patch. It is labeled "Input", and includes several controls connected to an abstraction named "input_handler". Double-click on the input_handler subpatcher to see its contents.

This subpatch is pretty simple: it contains a number of adstatus objects that allow my controls to display and alter the audio settings used at runtime. The function is similar to using the DSP Status window, but exposes only those items I considered important for realtime performance. Since I don't use the adstatus object very often, I don't know the functional arguments by heart. While I could have used the documentation to learn about the object, I decided to steal the functions from the help patch instead! 

By viewing the help patch, I can learn about the function of an object. However, all help patches are also functional Max patches. In this case, I was able to unlock the adstatus.maxhelp patch, copy the functional objects that I needed, then paste them into my subpatcher. By connecting a few inlets and outlets, I'd created the small and efficient input setup handler that I needed. In addition to setting the DSP Settings, I also want to control gain at this point. This is especially important with an instrument-driven patch, since different input hardware will provide vastly different levels. In my case, I will sometimes be using an IK Multimedia Stomp I/O, sometimes a mixer with an audio interface, and sometimes a direct connection into my Mac's audio input - so I want good control of my front-end gain. I did this by adding a *~ object to the input section, then routed the input into this control. By using a scale control, I'm able to change the normal range of the gain knob (0-127) into a range that goes from 0.0 (silent) to 4.0 (quadruple-volume).

The next stage of the patch is a compressor. Since compression can have a very significant effect on the sound of the instrument, I wanted detailed control over its parameters. Therefore, I am using number boxes (rather than knobs) to control the values; this gives me precise control over the compressor's operation without having to guess at a knob's output value.

Again, this section is mostly a set of controls connected to an abstraction named "comp_handler". Double-click on this subpatcher to view its contents. This is a very simple subpatch; I've just borrowed the komp subpatcher (found in examples/effects/kompressor/lib of the Max folder) without change. I set one parameter (lookahead) directly with a loadbang, but mostly expose the functions directly to the main patcher. Since this subpatcher is so simple, why didn't I just use komp directly in my main patch?

In the future, I may want to develop my own compressor system, or I may choose to implement code from someone else. I may even break down and use a VST compressor. In any of these cases, I would want to change the compressor "engine" without having to disturb my main patcher. By placing the compressor in a subpatch, I can change the underlying compression engine without ever having to change the top-level patch or the user interface. This is a "high detail" compressor, giving me the kind of control I want for a flexible rig. If you aren't that familiar with compression, though, it may seem a little intimidating. Here are a few settings that I've found useful with this processor:

Note: In each of the processing areas of the patch, you will see a small grey panel - it doesn't seem to do anything. However, when you switch into Presentation Mode, you should see these panels expand to become the background of the individual processing sections. This is an example of using the Presentation Mode's ability to change an object's geometry to keep my patching view clean, but give me an attractive user interface.

The final processing section for this tutorial controls the output. This section will be familiar to any Max/MSP programmer - it's the basis for audio output in almost any audio patch. The output of the compressor is sent to the two faders, which provide left/right volume control. The signal is then routed to an ezdac~, which is also our DSP on/off control. If you have your guitar (or other instrument) plugged into the computer, you can check the settings on the input module, turn on the DSP, turn up the volume and hear your instrument through the patch.


However, it's not always convenient to test with an actual instrument. For example, some of this patch was done while I was waiting in an airport. The last thing the airport security wants to see is for me to pull out a guitar and start wailing. What I've done is to include a "test fixture" that I can use to test the patch as it is being built. You will notice that this section (labeled "test fixture") gives me the opportunity to load and play a file, play an oscillator tone, or generate noise. This is a subpatcher, called "demosound", that is integral to many MSP help files, and has replaced a lot of different test systems I've used in the past. 

For this patch, I grabbed demosound from a help file (in my case, from the comb~ help file), and copied it into my patch. The output of demosound is routed to a send~ object labeled "test". This audio is received into the audio input (that's the extra 'stuff' in the input section), inserting the audio at the same point that my patch would see an instrument. This way, I can test patches without having an instrument plugged in, helping me to be productive when my guitar isn't easily accessible.

We've created the basic I/O blocks for our performance patch. In the next article, we will expand it by adding a good-sounding distortion/overdrive system and a highly controllable filter/EQ. In the meantime, work with this basic patch, learn to understand the routing between the objects and explore the use of the compressor. Until next time - have fun!

Learn More: See all the articles in this series 

Darwin_block.jpg

One of our most popular article series was the Max 5 Guitar Processor. There have been a number of changes to Max, and we felt like it was time for an update to this series. Over the course of the expanded and updated series, I will be building a Max-based guitar processing "rig", and will give you the opportunity to look over my shoulder as I design and implement this system.

max-8-guitar-processor-part-1

Max 8 Guitar Processor, Part 1

In the last article, we did a lot of setup - we got input/output handling in place and added a compressor to the processing chain as an example of an “effects module.” In this article, we will continue adding effects, including a dual overdrive module and a three-stage EQ/Filter module. With these additions we will further explore Max 8’s user interface options, as well as taking a look at some of the “tweaks” that make Max/MSP functions a little more guitar-faithful. 

First up is an overdrive processor.  I’ve found that the way to get the most variety with this sort of processor is to have two overdrive~ objects in series with a lowpass filter between them; the result is a controllable distortion/overdrive capable of some crazy variations. I have, again, encapsulated the overdrive functions in a subpatcher (in this case, called od_handler), which implements the dual overdrive~ setup, as well as a selector~ that provides the bypass functionality.

I’ve also added a level adjustment that allows us to tame the output levels post-overdrive~. This can be very handy since some of the more extreme overdrive settings can cause high levels (both real and perceived). I’ve also connected a meter~ object to the output of the subpatcher, giving me a way to eyeball the output of the compressor-overdrive pairing.

Next up is the creation of a EQ/Filter modules.  This is going to use a cascade~ filter, which is a version of a biquad filter that takes lists of coefficients and creates a complex filter curve. In order to manage it using simplified controls, we will use a function of the filtergraph~ object that converts frequency/level combinations into biquad-type coefficients. By now, you should be able to see the design pattern in use: I create a subpatcher with the “guts” of the effect module, then attach controls for all of the variable parameters. Open the “filter_handler” subpatcher to examine the DSP functions used. Most of this subpatcher converts the incoming values into useful frequency and level values, then sends them into filtergraph~ objects. I could have just as easily used filtercoeff~ objects, but using the filtergraph~ lets me see the individual filter settings, helping me verify that the individual filter parameters are being set correctly. The coefficient outputs of the filtergraph~ objects are “pak’d” into a list of 15 floating point values (five for each filter), then prepended with the cascade message. This informs connected filter objects that more than one coefficient set will be used to create a complex filter.

This list is now sent to a cascade~ object, which implements the equivalent of serial biquad filters that implement the cascaded filter settings. This could just as easily be implemented as several biquad~ objects, but using the single cascade~ object allows us to keep the signal count down. An important addition to this subpatcher is filter clearing. Biquad filters are based on delay lines that can occasionally get overloaded. In these cases, the filter is “blown”, and will not produce any output. The easiest way to fix a blown filter is to send it a clear message, but the downside is that it resets all of the filter coefficients, but doesn’t update any of the user interface elements that control the filter. So, in this case, when we receive a message in the “clear filters” inlet, it not only sends a clear message to the cascade object, but also sends a bang to receivers of the “fil_clear” send object. There is only one receiver of fil_clear: a receive object embedded in the subpatcher called “filter_clearer”. This simply resets all of the user interface elements to default values, providing visual feedback of the filter’s newly cleared state. It is important to implement a function like this whenever you are working with MSP filters, since blowing a filter is a common problem as you experiment with extreme filter settings.

One last, little change: I created a simple subpatcher, which I called "io", that is going to be the last stage before output. I use it to split the single signal into two channels' worth of data, but I also slipped in a limi~ object in there as a way to prevent a complete explosion. 

For the moment, I'm using whatever the default values there are for the object, but we'll probably beef this up in a future article.

Put the patch into Presentation Mode, and you will see that I’ve reordered the modules to maintain the row-column orientation of the signal flow. I’ve also added level meters at the end of each row. This is something that I’ve learned to do for performance patches - to place meters in strategic places, helping me to see “where” something is wrong when something goes wrong. As this patch develops, we will place a meter at the end of each row, combining useful debugging information with a cool, flashy display.

I also decided to make the visual EQ/Filter display very large in Performance Mode. This helps me see the result of subtle changes and gives a better visual indication in the heat of battle. If you want to create and add modules of your own, you might want to make this part of the patch a little smaller — but be careful, since the EQ module can have a pretty drastic effect on your sound and you will want as much control as possible. With the addition of the overdrive and EQ/Filter units, we have created tools to sculpt the sound of the guitar. Next, we will add a few more “effect-y” modules, including a smooth phaser and a modulating delay line. Until then, have fun with our new modules, and try to make some of your own using some of the techniques we’ve developed.

guitar_2.png

In this installment of our series on Max-based guitar processing, I’m going to add a dual overdrive module and a three-stage EQ/Filter module. With these additions we will further explore Max 8’s user interface options, as well as taking a look at some of the “tweaks” that make Max/MSP functions a little more guitar-faithful. 

max-8-guitar-processor-part-2

Max 8 Guitar Processor, Part 2

In the last article, we added some basic tonal effects: distortion/overdrive and EQ/filtering. This time, we will expand our virtual effects rack to include both a phase shifter and a full-featured modulating digital delay. As we add these effects, you will begin to see why a DIY effects system can trump any commercial product. 

In the new version of the patch, the first module I’ve added is a phase shifter. It’s a full-featured implementation, featuring a variable number of phase shift stages and a frequency spread to provide a more complicated sound. Since this is obviously a well-considered piece of work, I surely had to steal from someplace, right? Of course! Luckily, I have access to some of the old Pluggo source patches, and I’ve always liked this particular phase shifter’s sound. So I opened up the patch and copied the whole thing! By placing it in a subpatcher (phasor_handler), I keep it out of my hair at the top level. The only thing that I added to the patch is some scaling of the inputs to help keep the control ranges sensible.

At this point, it might be useful to open up the patch and open the phasor_handler subpatcher. One of the interesting aspects of this patch is the use of the phaseshift~ object to provide the effect. Normally, a phase shift is almost imperceptible, but when the frequency is moving a classic phase shift sound is created. Stacking a few of these on top of each other (with the serial application of the onestage subpatcher) allows us to vary the depth of the effect by adding (or subtracting) phase shifting stages.

The next module is a digital delay, complete with modulation, feedback (with filtering), and stereo enhancement. This is also the place where we go from mono processing to stereo, allowing each output to have a different (but related) delay time. The key to this is the “RHS Factor” which determines the right side’s delay time relative to the left side. Modest difference (like .98) will provide subtle depth while more radical settings (like .5 or 1.5) will give rhythmic ping-pong echoes. If we switch to the Patching Mode and open the delay_handler subpatcher, we see that most of the work is being done by a pair of tapin~/tapout~ objects and some scaling functions. Creating the modulation — which allows this module to perform flanging, chorusing and vibrato effects — is accomplished by varying the delay time. We use a cycle~ object to drive the change — but note that the delay time is consistently maintained as a signal routing rather than an event routing. This causes the delay time to change without interruption, giving us smooth delay time transitions that can be used to our advantage.

As you can see in the patching view, we’ve continued our patching patterns by creating a master patch for each effect module with controls maintained at the top-level patch. If you switch to the Presentation Mode, you will see that we’ve also maintained another pattern: using knobs (the dial object) for controls that are best set by ear and number boxes for controls that may need precise settings. For most people, a screen full of number boxes is confusing and intimidating — and this becomes worse when you are using a patch onstage. By limiting the use of number boxes to those controls that will specifically need them you can reduce the amount of stress experienced when working with a patch.

Since the phase shifter and delay modules take up one half “rack space” in Presentation Mode, we also want to put another level meter at the end of that segment of the rack. However, since we now have split the sound into stereo, we need to use two meters instead. This gives us a quick visual to make sure that neither the phase shifter nor the delay unit settings are causing output distortion.

At this point, we’ve created a credible guitar processor with the most common effects in place. In our next article, we will dive into less familiar territory by taking on looping and reverb. See you then!

m8gp3-d.png

Our guitar processor series swings into high gear in our third installment — I’m going to add a phase shifter with a variable number of phase shift stages and frequency spread and a full-featured modulating digital delay. With these effects on board, you can begin to see why a DIY effects system can trump any commercial product.

max-8-guitar-processor-part-3

Max 8 Guitar Processor, Part 3

At this point, we have a pretty useful guitar processing "rack", but it could use a little spice. This spice will come from two additional processors: a looping delay unit, and a basic reverb system. Also, to help keep the output useful, we will drop a limiter on the back end of the entire rig. 

The first processor we will add is an alternative version of the delay line – one that provides tap tempo, looping and sound-on-sound functionality. Unlike our previous delay module, this one will not provide modulation (for flanging and pitch shifting effects); rather it will be focused on capturing a loop, and allowing overdubs of additional sounds.

As with any delay line, the most important setting is the delay time. We use a standard floating-point number box for entry, but it is probably most convenient to use the "tap tempo" function that is implemented. By clicking on the tap tempo button four times, you generate a delay time that will match your taps. 

The tap tempo function is provided by the taptempo abstraction at the top level of the patch. It counts four incoming bang messages, determines the three intervals between the taps, takes the average and uses that for the tempo calculation. Since it is assumed that we are tapping quarter notes, but want to use a four bar measure, the result is multiplied by four to give us a delay time value. This is an area where you might want to modify the function to meet your needs – if you really want to have the delay run at the rate you tapped, you can remove the [* 4] object at the end of the processing chain.

The basic delay design, as found in the loop_handler subpatcher, is very similar to the layout of the modulating delay. The few tweaks provided are there to support the looping functions. First, when the "Freeze" button is on, the feedback is switched to 100% feedback. This gives us a standard looping function. The feedback loop has a lowpass filter in it, which will change the audio in the loop if it is not fully open. The "Input Active" button is very important – it determines if the input signal is sent into the delay path. If it is off, the only output of the delay line is whatever is currently playing – if the delay is "frozen", you will hear the loop, while with freeze off you will only hear the remaining contents of the loop line feedback. What is cool about this is that, when you freeze the delay line, you can still overlay audio parts onto the loop – giving you sound-on-sound overdubbing. I've also implemented a click track that cycles at the same speed as the delay time. This way, if you want to work up some one-bar loops, you can hear the timing (in quarter note click) even before you begin recording. Most of these concepts are classic delay techniques, but this sort of looping function is why many people get into Max/MSP in the first place. Even if you aren't into guitar processing per se, you may find this looping delay system can jump-start your Max experiments.

What would an effects processing rig be without a reverb? As is typical for any processing rack, I've installed a reverb as the last effect in the system – this way, we will get consistent reverb from both our looped and our live guitar lines. To provide reverb, I've gone to a third-party external object: Nathan Wolek's nw.gverb~. You can find this object in a the LowkeyNW package in the Max Package Manager:

I happen to like the sound of nw.gverb~ well enough, but I've wrapped it up in another abstraction so I can replace it in the future (if I decide to do that).

If you look into the subpatcher reverb_handler, you'll see that I expose the reverb time control to the top-level patch, but I also provide a reverb mix control that uses the pan2 abstraction found in Max's examples folder. This gives me a decent equal power pan – but why would I need to pan? In reality, I don't; but I can use them as equal power channel mixers as well. By using only one output of the panner, and reverse panning the live sound, I can get a decent mixing function with very little effort. This may not be the most efficient processing stream, but it sure was easy to implement!

Finally, to make sure everything stays under control, I've added a limiter to the end of the processing chain.  I've improved the use of the limi~ object in the io subpatcher, setting up a few parameters to make it work as expected. I also reconfigured the output section of the Presentation Mode to make everything fit a little better, but the functionality should all be familiar from previous weeks' articles.

This is the conclusion of new module additions, but far from the conclusion of this series. For my money, some of the most important information will be found in our next two articles, where we will cover preset management ('cuz I don't want to be mousing too much on-stage) and MIDI controls (using a MIDI foot controller). Get familiar with our new modules, and prepare for more fun with our next Guitar Processing entry!

image3.jpg

The guitar processor series just keeps adding the awesome. This time out, I'm adding looping and reverb to the mix. Don’t be surprised if the amount of time you’re spending playing through this patch has been going up with each new installment - that’ll certainly be the case this time. 

max-8-guitar-processor-part-4

Max 8 Guitar Processor, Part 4

In this tutorial, we are going to step away from making new effects for our processor and focus on another important part of a guitar-oriented system: device presets. 

In earlier versions of this article, I used the pattr preset system to store and recall presets for our patch. This time around, I’m going to use the new-ish Max snapshot system for preset save and recall. To begin this process, we need to run through our patch and change each user interface element that we want stored in the preset. So get your mouse hand warmed up, and let’s get started!

For each user element to be saved, we need to turn on the “Parameter Mode Enabled” switch in the object’s inspector. This basically ‘opens the doors’ to the embedded values of the knobs, sliders and menus to be easily saved. You might think that every item should be changed – but that’s not necessarily true: for example, you wouldn’t want the audio input selector to be a part of a preset, nor would you want a preset to change the output on/off state unnecessarily.

I’ve created the following image to show all of the user interface elements that I chose for saving:

For each of these, I select the object, then open the item inspector and scroll down to the Parameter area. The only thing I have to do is to turn on the Parameter Mode Enabled switch, and the item is ready to be saved in a snapshot.

Here's a little hint: You can shift-click select a number of user interface elements (knobs, sliders, toggles) and open the inspector; you will see all of the parameters that are common to all of the selected items. In this way, you can set the "Parameter Mode Enable" option for multiple controls at once!

Also, note that we don't enable parameter mode on the output level; this is a live.gain~ object, which is Parameter Mode-aware automatically. So it will be part of the preset, but we don't have to manually set anything.

Now, all I have to do to save a setup for my patch is to dial things in, open the Snapshot sidebar (that’s the little camera icon on the right hand side…), and then either click on the New… label or select the “+” icon at the bottom of the snapshot sidebar. This will create a new preset that will recall every setting that I set up.

There are a few details that are worth noting here. First, it makes sense to name your presets, which you do by clicking on the name of the preset and typing in a name. Secondly, and kind of subtly, you will probably want to click on that little dot next to the name. 

What does that dot do? That tells the system to save the preset values inside your patch rather than in an external file. And why is that important? It so that your presets will follow along with you if you move your patch to another computer.

At this point, spend some time making some nice presets. You will have access to them in the sidebar - and you select them by clicking on the arrow in front of the name. 

If you want to learn more about the snapshot system, you can check out the documentation and this previous article. 

Having the ability to create presets is great, but the having a bit list that you select from doesn't seem, well, very pedal like. Most guitar rigs have a numeric patch selector with up/down entry for simple patch selection. Max doesn't have any object that do this, but a forum post by Andrew Pask revealed a cool little JavaScript-based patch for snapshot selection called snapshotAPI-example.maxpat, which can be found in the Max file browser.

The nice thing about this is that it has a very steal-able js object that does everything we could need (and, quite frankly, more) - so a simple copy and paste gets it into our patch. With the addition of a little messaging and the clever use of a comment object (to display the patch name), we have a numeric patch selector!

Now you should have a number of snapshots, and the ability to switch between them - either using the sidebar, or with our numeric selector.  We put this interface on the 'front panel' of our patch to make it a little cleaner, and we are set.

In the next (and final) article, we will cover using a MIDI guitar pedal/interface to help make snapshot selection hands-free - as well as getting a little MIDI control action. In the meantime - have fun!

ddg_preset.png

The guitar processor we’ve been building during this tutorial series now boasts an impressive set of effects. For this tutorial, I am going to step away from making new effects to focus on another important part of a guitar-oriented system: device presets.

max-8-guitar-processor-part-5

Max 8 Guitar Processor, Part 5

To wrap things up, I want to make a connection to the real world - to hardware. In previous iterations of this series, we created a complicated pattr-based preset system, then coupled it with an equally complex routing system. When using the system, I seldom found this useful - rather, what I really wanted was hands-off preset selection, and simple volume control from a foot pedal. So we again diverge from earlier versions and create a simple - but effective - MIDI pedal connection. 

There are a few different guitar-oriented MIDI rigs out there, and some have been around for a long time. However, a relatively new (but still affordable) option has arrived: the IK Multimedia iRig Stomp I/O. This shortboard-styled system combines a guitar-oriented audio interface with a set of pushbuttons and a foot-potentiometer, which is exactly the kind of system that can activate our guitar rig.

With a little investigation, we find out that there are several ways of using this as a stock MIDI pedal interface. We are going to choose the easiest one - the default mode, which causes the buttons to transmit MIDI Program Change messages, and the pedal providing a straight MIDI CC. Since this is the device's default mode, we don't have to do much other than connect it right up to the computer with a USB cable, connect our guitar and an amp (or headphones) and dig in!

There isn't anything too special about the MIDI produced by the iRig Stomp I/O, other than the fact that no notes are generated; rather, everything is Program Changes or Continuous Controllers. But we do have to select the device as our MIDI input - and parse out the MIDI stream for useful information. 

To get this functionality, we are going to steal directly from one of the help files: specifically, the midiin help file. This gem provides us with the information necessary to select from the available MIDI input devices (of which the iRig is most interesting). Pairing that with a midiparse object allows us to get the Program Change and Continuous Controller messages.

To make things easy for ourselves, we'll route the Program Change messages to a send named pgm, and MIDI CC #11 messages (what the foot pedal produces) to a send named pedal.

What should we do with the data? Well, the Program Change messages are pretty easy: we'll just route them directly to the Preset Selector for direct snapshot selection.

For the CC we need be a little thoughtful - and our Overdrive/Gain system is a good place to route this data. By altering the volume before it gets to the delay systems, we'll be able to create interesting swells that get carried forward by the delay (and looper). It's a simple effect that is incredibly musical.

And with that, we hit the end of this series. The final result, with all effects, preset/snapshot management and MIDI interface, end up being a tight little system with a lot of flexibility.

How is this different/preferable to something like IK Multimedia's iRig software, or Guitar Rig, or any of the other virtual guitar rigs out there? It's because you have the ability to extend and improve this setup in ways that only you can imagine. Think about adding VST's, Max for Live devices, or Gen processors to expand your effects system - it's truly an endless playground.

Thanks for following along, and if you have any questions - just drop a comment. Happy patching!

MIDI_pedal.png

Here we are at the close of our series on creating a guitar processor in MSP. To wrap things up, I want to make a connection to the real world - to hardware. In previous iterations of this series, we created a complicated pattr-based preset system, then coupled it with an equally complex routing system. When using the system, I found that what I really wanted was hands-off preset selection, and simple volume control from a foot pedal. So we’re ending this series by adding a simple - but effective - MIDI pedal connection. 

Search Results