Timothy Place

In this 12-minute video, I give you a tour of some advanced Max filtering tools and filter design options that go above and beyond the biquad~ object. With the filterdesign, filterdetail and plot~ objects, you can take filtering to the next level.

Watch other filter design videos: Demystifying Filters and Crossover Filter Design.

A tour of some advanced Max filtering tools and filter design options that go above and beyond the biquad~ object. With the filterdesign, filterdetail and plot~ objects, you can take filtering to the next level.

More information: https://cycling74.com/products/max/

Explore Filtering Tools in Max

a-tour-of-filtering-tools-in-max

A Tour of Filtering Tools in Max

Darwin Grosse

This series of tutorials first appeared on my CreativeSynth.com website between 2001 and 2002. Due to their popularity (especially amongst new Max users), I have moved them to the Cycling74.com website. Read the introduction. 

As promised, we are going to clean up our previous synth-building patch, create some presets and, well, clean it up some more.

Output manipulation using Envelopes (part 2)

While having a Pluggo-based VST plugin is cool, it isn't quite as cool as having one that can store and recall its settings.  For most occasions, the MSP object that you will use for parameter handling is the "pp" object. (No snickering - I'm sure it stands for Pluggo Parameter.)

One thing that is a misconception is that pp's parameters have to exist in the 0.0-1.0 range.  Not true - you can tell pp what the range and type of your settings are, and pp will handle all of the translation for you.

So, to use pp, we need to lay them into the patch, connect them to our UI objects, and loop the output back to the input.  This seems to violate Max's "don't make loopbacks" rule, but pp is smart enough to stop any unwarranted looping.

All of our onscreen controls are pretty straightforward except that pesky filtergraph~.  What to you connect to what?  The best bet is to use the freq/gain/resonance outputs as separate parameters, and loop them back to their appropriate values.  Also - don't forget to set the "filter type" menu, otherwise you'll get unexpected results when you restore a patch.

Below is a snapshot of our "pp'd" patch, with the appropriate ranges entered into the pp objects.  Note that the filtergraph~ ranges are pretty obscure - you will want to copy these settings for your future use...

Now that we have a prepared patch, we need to save some preset.  But, um, how do we do that?

I've created a standard construct that I use in every single Pluggo patch that I create:

This little setup allows me to call up any preset I save, and also lets me save a patch with a single click.  This is another one of those "save-it" bits - you will find it in all of my patches, and I'll bet I find it in all of yours!

So, we need to go about creating and saving presets.  Not a problem - with the above construct, we make patches, hit the button and we are set.  Well, not quite.  While this will allow us to save the settings, it does nothing to save a patch name.  You can actually jam a name into the plugconfig, but there is no way to access and edit it.

There are two ways to name patches.  First, you can double-click on plugconfig and hand-enter the names into the patches.  This is most convenient.  However, there is one downside.  If you are using int parameters (which are converted into floats by pp), opening and editing the plugconfig file can change your settings by 1.  Why?             This has to do with rounding in Max, and also with display precision in the editor.

It's not worth much more talking about - just be aware that extremely fiddly controls (like anything that stores text characters or menu settings) might suffer from plugconfig editing.

The other option requires a) a copy of Cubase, b) a valid Pluggo license and c) the willingness to get it "right".  If you save a Pluggo patch with the default names, then open the patch in Cubase, you can edit the names of each of the patches.  You can then save the patch bank from Cubase and load it into plugconfig when you reedit the patch.  A hassle, but this is the way you have to do it when the settings really matter.

In our current case, we don't have to be that worried about it.  So - double-click the plugconfig object and edit away!  Make sure that, after editing, you double check all of your patches to make sure that nothing went awry.

Well, before we call this complete, there are a few bits and pieces to clean up.  First, since they don't really work in Pluggo world, we should hide some of the objects in the patcher and make the whole thing more compact.  In this case, I've moved the volume slider next to the envelopes and hid all of the "details" below.  I've also reduced the size of the patcher, so that we'll only see as much as we need...

Also, I've added a switch to the midiin object.  It turns out that some sequencers (Digital Performer in particular) will pass MIDI from both midiin and plugmidiin - so if both are active in a patch, you will get doubled notes.  The Gswitch will allow you to turn on midiin when you are playing with the patch (or if you decide you like doubled notes in DP).

Once these final details are complete, we are ready to fly.  Create a collective (again), run it (twice!) through plugmaker and we have a spanking new Pluggo, complete with cool patches.

Hopefully, this helps you tweak your own creations into shape.  If you make a cool Pluggo, make sure you let me know (and send me a copy)!

The files for this week's tutorial are available at this link: cs.08.zip

This series of tutorials first appeared on my CreativeSynth.com website between 2001 and 2002. Due to their popularity (especially amongst new Max users), I have moved them to the Cycling74.com website.

synth-building-with-maxmsp-8

Synth-Building with Max/MSP #8

Max and Max For Live were used to build the device.

m4l-morph-filter

M4L Morph Filter

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.

Download the patch used in this tutorial.

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.

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!

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!


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. 

max-5-guitar-processor-part-5

Max 5 Guitar Processor, Part 5

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.

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 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. About all that I added to the patch is some scaling of the inputs to help keep the control ranges sensible.

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 Hand 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 you need to 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 or program 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 full “rack space” in Presentation Mode, we also want to put another level meter at the end 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!


max-5-guitar-processor-part-3

Max 5 Guitar Processor, Part 3

OK - we've built the voice patch for a poly~ object, now we have to turn it into a legitimate polyphonic synth. Here is our "master patch" (as found in the last tutorial, which you can download from this link):

While it doesn't much look like the tutorial 3 patch, it maintains all of the functionality of that machine - but is now a 16-voice version. Let's look at each section of the synth...

In our earlier patch, we used notein and ddg.mono to simplify midi handling. While we could still use notein, I've decided to use midiin instead (you'll see why in the next tutorial). I also append the "a" identifier to midiin - this allows me to automatically use whatever MIDI device I've got assigns as the "a" device without the hassle of selecting an OMS input.

Using midiparse, we can get the note-on and note-off events that are coming in from the midiin object. In order for poly~ to understand the meaning of these note events, we need to prepend the symbol "midinote" to the note number and velocity. This combo gets sent to the left input of the poly~ object.

Next, all of the user interface objects get sent to the poly~ object:

One point about user interface elements - they actually have to get sent to all instances of the voice patch. To do this, we have to send the message "target 0" to poly~ - this is a signal that all voice patches get the message, as opposed to the current voice. This is done by using the trigger (abbreviated as "t") to first bang the "target          0" message, then send the remainder of the UI values to poly~.

The poly~ object is instantiated with the name of the voice patch ("cs_04_voice", which is what we called the patch), and the number of voices to create. One other detail: we need to tell poly~ to implement voice stealing. This is done with a loadbang object hitting the "steal 1" message. This tells poly~ that voice stealing should be used...

Finally, the output of poly~ (from the out~ object in our voice patch) is sent to a signal fader, the clip~ object and ezdac~, just as with our original patch. One nice feature of poly~ is that it outputs a mixed signal of all 16 voices - no further mixing is required by our patch.

So, there we have it. A 16-voice polysynth out of the dregs of a monosynth. Hopefully, this helps you see the power of poly~, the ease of creating a polysynth and gets you excited about making your own poly-monsters.

synth-building-with-maxmsp-5

Synth-Building with Max/MSP #5

Sorry for the long delay - the real world has a way of getting out-of-hand. Nevertheless, we shall continue...

In our last article, we beefed up our basic synth by adding volume control using an A/R envelope. Now that we have some control over the basic amplitude, it's time to move onto filtering.

Filtering is almost the most important timbral control of a synth. You can take almost any reasonably complex sound and tone it down to be useful in the appropriate context. Filtering is part of Subtractive Synthesis - the process of starting with complex sound, and subtracting harmonic information until you achieve a useful sound.

In order to make our synth more useful, we are going to make a slight change to the basic synth we created in article #2. Instead of using the cycle~ oscillator, we will use the phasor~ - which gives us the harmonically more complex sawtooth waveform. This will give us more material to filter, and is better for this type of exercise. Just change the "cycle~ 440." to "phasor~ 440.", and you now have a sawtooth oscillator. Next, we will build up a filter section. There are many ways to do filtering within MSP. You can use the lp~ or hp~ filters, which are simple and "low cost". lores~ gives you a resonant lowpass filter, and reson~ can provide a similar bandpass option. You can also use the biquad~, which can give you a wide range of filter options - but is probably the most complex filter to properly set up.

Well, Cycling '74 developer jhno came to the rescue in MSP2, with the filtergraph~ object. This beauty takes all of the work out of creating a usable biquad~ filter setup, and gives extensive real-time control as well. We will use filtergraph~, along with biquad~, to create a flexible and good sounding filter system for our synth.

To set up a biquad~/filtergraph~ filter subsystem, you will need one of each of the objects, as well as a umenu. The biquad~ filter takes the input signal in the first inlet, and a number of coefficients in the remaining inlets.          The first outlet of the filtergraph~ filter will provide a list of coefficients that are usable by the biquad~ inlets 2-6. Since it is a list of five numbers, you can send the list to inlet #2, and the individual values will be automatically routed to the five right inlets.

We still have a umenu to deal with - which sets up the filter to conform to a specified type. If you open the umenu Info screen (Command-I), you can enter the menu text in a textedit area. The available settings for filtergraph~ are as follow:

display: only display the result of coefficient settings (not all that useful in this context).

lowpass: typical lowpass filter operation.

highpass: typical highpass filter operation.

bandpass: typical bandpass filter operation.

bandstop: The reverse of bandpass filtering - in essence, a controllable notch filter.

peaknotch: A notch filter with user-editable peak level adjustment.

lowshelf: A shelving highpass filter - in essence, a "bass tone control".

highshelf: A shelving lowpass filter - in essence, a "treble tone control".

These settings are transmitted as text to the biquad~ object, so spelling is critical. Since text is used, however, it is completely acceptable to have only a subset of the available filter types. For example, for an analog emulator,          you could provide lowpass, highpass and bandpass - and the others could be safely ignored. In our example, we will add them all (just to prove we can). Whenever the umenu is changed, the filter functions will change to match.

Now, you connect the right outlet (which outputs the selected menu text) to the left input of filtergraph~, and you are set to connect the audio. In our example, we will connect the output of the phasor~ object to the biquad~ inlet #1, and the biquad~ outlet to the velocity input. This will give us a complete audio chain, and allow us to filter to taste.

The final patcher (with filtering) can be downloaded from this link. The image below shows how the filtering system fits into our growing synth:

Take the example patcher and play with the filter. Select every type of filter, and start clicking around the filtergraph~. You will be amazed at the wide range of effects that can be created with this simple set of objects.

synth-building-with-maxmsp-3

Synth-Building with Max/MSP #3

samplehold

A audio application I built for live improvisation with multiple sound files. It has a handy multi channel file recorder for recording your performance or sketches as stems.

Max 8 was used to build this. Click here to download.

A audio application I built for live improvisation with multiple sound files. It has a handy multi channel file recorder for recording your 

sketchasound

SketchASound

Joe Malloch

This “toolbox” is a collection of Max/MSP abstraction that we have found useful in the IDMIL for creating gesture processing patches for digital musical instruments. Each abstraction is accompanied by a help patch to demonstrate its use. Authors: Joseph Malloch, Stephen Sinclair, and Marlon Schumacher @ the Input Devices and Music Interaction Lab, McGill University.

Download the details for this tool (PDF).


digital-orchestra-toolbox

Digital Orchestra Toolbox

Peter McCulloch

PM.Chamberlin~ is a Chamberlin state-variable filter.  It contains two extra modes (peak and notch), and is over-sampled so it supports cutoff frequencies over up to roughly 80% of the Nyquist frequency.

The cutoff can be specified in MIDI or frequency values, and the filter can self-oscillate.  The filter has a built-in saturation.  The volume of the self-oscillation is fixed, so pre-and-post gain can be used to adjust the mix of the resonant peak.

This release is only for Mac, and the SDK was for 10.5, so it may not work on 10.4 machines.  I don't have Windows, but if anyone is interested in using this on Windows please contact me and we'll see what we can do.


Search Results