In this, the final episode of our guitar processing extravaganza, we are going to step away from making effects and focus on performance support. For a system as complicated as this, performance support means two things: patch storage and realtime control. Thus, we will learn to create a preset system and manipulate the various on-screen controls with an inexpensive MIDI footpedal system.
The “pattr” objects manage the basics of preset handling for complex patches. This subsystem revolves around an object called pattr, which maintains the state of a control and allows it to be saved or remotely controlled. In our patch, we won’t use the pattr object directly; rather, we will use the autopattr object (which creates a virtual pattr for all named objects) and the pattrstorage object (which provides for preset storage and remote dispatching).
In order to make autopattr work, we need to name all of the controls that we want maintained by the pattr system and we also must make sure that controls we want left “untouched” are unnamed. If you select a control and bring up the Object Inspector, you will see that I’ve named all of the appropriate controls, using a naming convention that identifies the module and control function for each UI element.
In addition to naming all of the controls (so they can be seen by autopattr), I’ve also added a textedit object that will be used as a preset name. This “no-nothing” field isn’t connected to anything, but it is named – therefore acting as a place to put our patch name. Gotta have a patch name…
Once the autopattr object is in place, we also need to handle the selection and storage of preset data. That is what the pattrstorage object does. We can use a number box (in this case, with an up/down control) to select patch slots, and create messages that will store the current settings as a preset. We also need to add controls for saving and restoring the contents to a file. With remarkably little patching, we’ve created a complete device preset system.
MIDI Control
Another important aspect to a usable live guitar rig is MIDI control – specifically, control from a MIDI pedal board. I happen to have a Behringer FCB1010 MIDI Foot Controller, and I’ve integrated its use into this custom patch. I’ve created a simple set of functions to create a list of MIDI inputs and to select a set of control functions, then manage the MIDI input within the subpatcher called midi_handler.
Incoming MIDI information is parsed (using the midiparse object), with program changes used to set the current preset slot. In addition, I use the program change command to act as a tap tempo button, since I have set the FCB1010 to produce the appropriate messages.
The most important section of this patch, however, is the routing of MIDI control messages. I have a subpatch that compares incoming MIDI CC messages with our selected controller numbers, and only outputs valid control messages. This is then sent to a gate object, which routes the value to the correct message box (and, in some cases, a scale object that scales the values). These message boxes prepend the pattr name of a control to the value, then send this set back to pattrstorage.
The result is an automatic update to the control, based on pattrstorage’s message handling! This is a little known way of controlling pattr’d controls; we use pattrstorage as a “dispatcher” of messages, and let it update the control (and the current patch setting).
One thing to watch out for, though, is that these changes overwrite the current setting in the pattrstorage preset slot. So, if you load a preset file, change a setting with the foot pedal, then save the preset file, your changes will become the new setting for that control. It’s a good idea to always review your current patch when working with pattrstorage, and to separate preset creation from live performance!
Conclusion
I hope that this series have been inspirational to you. The design and execution of the final patch is particular to my performance needs, but should be easy enough to modify into a system that will work for you. I’ve included a file (mypresets.xml) with a few of the preset I use with this rig – you may want to start your customization by making presets of your own. But best result would be for you to take this patch, rip it apart, and create your dream guitar processor!
Thanks for following the series, and feel free to email me with any questions or comments: ddg@cycling74.com. Hope to hear from you soon!
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 processor is exactly why many people first get into Max/MSP. Even if you aren’t into guitar processing per se, you may find this looping delay system can jump-start your Max experiments.
Reverb
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 consistant 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 gverb~. I happen to like the sound of it well enough, and 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 fact, I don’t; but I can use them as equal power mixers as well. By using only one output of the panner, and reverse panning the live sound, I can get a decent mixing function will little effort. This may not be the most efficient processing stream, but it sure was easy to implement!
And a Limiter at the end…
Finally, to make sure everything stays under control, I’ve added a limiter to the end of the processing chain. I’m using the omx.peaklim~ object, which implements a good quality limiter. The parameters for this object are a little weird, so after some experimenting, I found a set that worked for me. These are loadbang’d into the object during startup, and never change. 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.
Conclusion
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 article, where we will cover preset management (‘cuz I don’t want to be mousing too much on-stage) and MIDI parameter controls (using my FCB-1010 foot controller). Get familiar with our new modules, and prepare for a big finale with our next Guitar Processing entry!
I recently attended Winter NAMM 2009 in Anaheim,CA, where Cycling ’74 was sharing booth space with our friends at Ableton. I arrived on Friday afternoon, well after we had released our product announcement for Max for Live, and was impressed by the volume of booth traffic we were getting. Ableton had, of course, also announced their new Akai controller and Live 8 in addition to Max for Live, so there was a great deal of buzz surrounding our area of the show.
This article provides a brief tour of the features we’ve added to Max for creating Live devices. If you’re familiar with our old plug-in development objects, we hope you’ll notice the major improvements we’ve made. If you’re new to creating Max content for audio and MIDI processing, we hope this tour will give you a flavor of the tools that will be at your disposal when Max for Live is released later this year.
Please note, the information presented here is preliminary and subject to change.
Nine years ago, Robert Henke told me about the edit button.
Robert was in Anaheim, giving amazing Live 1.0 demos non-stop at Ableton’s first NAMM booth, and before the last day of the show, we were chatting in the topiary-enhanced parking lot of Stovall’s Inn. Having used Max to prototype some of the first effects included with Live, Robert told me he wanted to be able to reprogram his effects on the fly, without stopping the music, just the way everything else worked in Live. At that time, the reality for Robert would have involved translating his revised patch into a C program and rebuilding a new version of Live. This was not exactly the real-time development cycle he was used to as a Max user.
NAMM • Anaheim, CA • January 15, 2009–Cycling ’74 and Ableton today announced Max for Live, the integration of Cycling ’74′s Max/MSP environment into Ableton Live. Available as an add-on product to Ableton’s newly announced Live 8, Max for Live permits users to create devices that extend and customize Live by creating instruments, controllers, audio effects, and MIDI processors.
