Emmanuel Jourdan

Converting a "pluggo ready patch" into a "poly~ abstraction"

A common concern for many advanced Max users is the ability to load new sound modules into a running MSP patch without causing discontinuities in the sound. Many people worked around this by creating Pluggo plug-ins of their sound modules that could be loaded dynamically inside the vst~ object without breaking up the signal in the main patch. Another feature of the Pluggo engine was that it automatically generated the handy "egg-slider" GUI from the parameters specified in the patch. As exporting plug-ins is not currently available for Max 5, we will look at another alternative in this article based on a new feature of the poly~ object, which allows you to dynamically load new abstractions without recompiling the DSP. To help users explore this new alternative, we will demonstrate different ways to convert a Pluggo-ready patch made with MaxMSP 4.6 into a patch that you can load as a poly~ abstraction. Using the scripting capabilities of MaxMSP, we will also see how to automatically generate a Graphical User Interface for the newly converted poly~ abstraction. As this is a fairly advanced tutorial, you may need to consult the documentation browser for more details about the concepts and techniques involved.

Click here to download the patches used in this tutorial.

Before starting, it's important to have an idea of how a Pluggo-ready patch (henceforth referred to as PRP) typically looks. It usually looks like a more or less normal MSP patch with three special elements:

plugin~/plugout~ objects represent inputs/outputs of the plug-in (instead of adc~ and dac~ objects for a normal patch)

pp objects declare names and characteristics of the parameters that user can manipulate

plugconfig object stores information about the plug-in, such as the parameter programs (presets)

Click here for a large image of the patch.

The original purpose of poly~ was to load a patcher multiple times to create polyphonic synthesisers and effects. However, there are many features of poly~ that are useful for other purposes as well, especially since Max 5 was released. We will use poly~ in a special way here, to load a single instance of a patcher, taking advantage of the fact that poly~ uses a different DSP chain than the main patch. This means that it is possible to load a different patcher inside poly~ while the DSP is running in the main patch, without causing any interruption in the other processes. A typical abstraction designed to work with poly~ includes special numbered input and output objects (in~/out~ for signal, in/out for max messages).

In order to be use our PRP in poly~, a few changes need to be made. To facilitate this work, and to make the process reusable, I've included some abstractions to replace objects like plugin~, plugout~ and pp,which are typically found in a PRP. The pp objects declare parameters of our plugin for the host application. The arguments of pp give the name of the parameter, the range, the unit... With this information Pluggo would automatically create an "egg-slider" GUI for the user to manipulate the parameters. In order to automatically generate our own GUI for our poly~ abstraction, we also need to have access to these parameters. This will be done using the pp2pattr abstraction, which includes three pattr objects, one for saving the parameter (in order to make presets), two others (which use the invisible attribute) to store the arguments of the abstraction and the hidden state (in order to be able to access them from the parent patcher). Using the pattr system will give us a great deal of flexibility of control and allow us to access the parameters in a programmatic way later on.

The first step is to import our PRP and clean it a little bit (using the Edit->Scale feature). Newly imported patches from Max 4 may need a little sprucing up to take advantage of the new look of Max 5. See the video below for a demonstration.

Next, we will need to replace the plugin~ and plugout~ objects with in~ and out~ objects to expose the inputs and outputs to the poly~ object. You can replace them manually, but a much more convenient way will be to replace the plugin~ and plugout~ with plugin2poly~ and plugout2poly~ abstractions, and then using the De-Encapsulate function from the Edit menu. This will paste the contents of the abstractions into the main patcher while keeping the connection in place, which will save us some time.

Next, we'll need to replace our pp objects with the pp2pattr abstraction. To do this by hand is fairly straightforward, but can be quite tedious if there are a number of parameters to deal with. To do this simply retype the object boxes with "pp2pattr", leaving the arguments intact.

#3b: Replacing pp (regular expression is fun)

Replacing pp by pp2pattr by hand is not super fun, especially if there are a lot of pp objects. One way around this is to use a Regular Expression (aka Find and Replace) in your favorite text editor. One benefit of the new text-based file format in Max 5 is that it's easy to use intelligent text search/replace to alter patches. Let's have a look at what we will need to change first. A pp object looks like this in the Max File Format (it's an extract of the patch):

"box" :             {
"maxclass" : "newobj",
"text" : "pp 1 Gain -1. 1.",
"patching_rect" : [ 478.881042, 294.241638, 86.892197, 19.0 ],
"id" : "obj-34",
"fontname" : "Arial",
"numinlets" : 1,
"numoutlets" : 3,
"fontsize" : 10.623105,
"outlettype" : [ "", "float", "" ],
"save" : [ "#N", "pp", 1, "Gain", -1.0, 1.0, ";", "#PP", "text", "The level of the input signal", ";" ]
}What we want is the following:

"box" :             {
"maxclass" : "newobj",
"text" : "pp2pattr 1 Gain -1. 1.",
"patching_rect" : [ 478.881042, 294.241638, 86.892197, 19.0 ],
"id" : "obj-34",
"fontname" : "Arial",
"numinlets" : 1,
"numoutlets" : 3,
"fontsize" : 10.623105,
"outlettype" : [ "", "float", "" ]
}In the second example, the name of the object has been changed and the last line has been removed (which also means that the comma at the end of the "outlettype" line has been removed too - otherwise the file would be corrupted). We will now use a text editor that supports Regular Expressions (TextWrangler in this case) to make the replacements. Before continuing, you might want to backup your patch just in case something goes wrong or a mistake is made. Open the "Generic Effect.maxpat" patch with TextWrangler, and choose Find in the Search menu. Here's one magical expression to do the search:

"text" : "pp([^}]+),[^}]+"save".+$
This expression means that we will search literally for "text" : "pp followed by as many characters as possible which are not a } followed by a comma, and a certain number of characters which are not }, followed by the literal string "save" and everything else up to the end of that line (.+$). The replacement string is a bit simpler:

"text" : "pp2pattr1
where 1 is the only special pattern, which means replace with the first back reference (the part of the searched text in parentheses).

After hitting Replace All, and saving the file, you can now reopen the patch in Max5 to see the result of this process.

In order to construct our graphical user interface, we will need to get the arguments of the pp2pattr abstractions, which define the parameter index, name, range, etc. To see how we accomplish this, have a look at the AutoGeneration and AutoGenerationJS patches for two different methods (see below). In both methods, we will use the getclientlist message of pattrstorage to get the name of all the visible pattr objects in our patch (one per pp2pattr abstraction). From there, we can extract the name of the pattr object which stores the arguments in each pp2pattr abstraction using a regexp object. For instance, the name of the pattr in the abstraction which controls the Gain parameter has a name like: pp2pattr[8]::Gain (the number might be different). From this, it is easy to generate the name of an invisible pattr object which is located in the same abstraction (pp2pattr[8]::args).  Then we can query the current state of that particular pattr via the getpp2pattr[8]::args message to pattrstorage. The values received from the argspattr are then saved in a coll object to be used in different places in the patch. In order to manipulate pattrstorage easily, aliases of the pattr object in pp2pattr are automatically created.  It is then possible to set the value of pp2pattr[8]::Gain directly using the message Gain. A separate coll object which stores the hidden state of a pp2pattr is created based on the same technique. The regexp object is used to separate messages coming from the outlet of pattrstorage. In order to have a clean interface, we create the objects so they appear automatically in presentation mode.

In order to create the UI objects, we can send messages to the thispatcher object to create new patcher elements programmatically. We use the script newobject command to create the objects that we need. To integrate the UI scripting into our PRP, paste the contents of the AutoGeneration.maxpat file, as demonstrated on the movie below.

We can also send messages to this.patcher within JavaScript in order to create the objects. One advantage of using JavaScript here is to be able to quickly create and customize the UI. Tasks like generating many objects programmatically are often much simpler to represent using a text-based scripting language than the equivalent patch. The included js code (GUIgenerate.js) has an internal representation of each of the pp2pattr objects, and is able to automatically create UI objects that bind to the appropriate parameter in each case, setting all the necessary attributes as it goes. To integrate the UI scripting into our PRP, paste the contents of the AutoGenerationJS.maxpat file, as demonstrated on the movie below.

In a PRP, the presets are stored in the plugconfig object. When you double click this object you can see its script.  A program (aka a preset) is indicated with the setprogram keyword, followed by the program number, the program index, the program name, the parameter offset and finally the values of each parameter. For simplification reasons, the parameter offset will be ignored. The parameter values are always expressed as a floating point value between 0 and 1:

#C setprogram 4 "White Chorus" 0 0.855 1. 0.855 0.1 0.0282 0.0111 0.1 0. 0.;
The conversion we use consists in a few steps:

pasting it in a text object, so we can dump it.

extracting only the lines which contains the setprogram keyword, using regexp again ;-)

scaling the parameters to fit the real range of each one (we use the coll which stores the range of each parameter for that)

and save each preset with the appropriate name coming from the plugconfig script.

The patch Preset-conversion.maxpat contains all the items to be pasted in the patch.

In order to communicate from the outside of the "poly~ abstraction", we need to create a new input (in 3) and output (out 1). The getSet.maxpat abstraction also contains a subpatcher which communicates with pattrstorage, in order to set / get parameters. This patch is designed to be compatible with the vst~ syntax: get followed by an index returns the value of the parameter, a list of index and value, or a symbol followed by a float value sets the value of the parameter.

In order to make the patcher look nicer after resizing the window, we will change a few options in the patcher inspector:

check "Save Default-Valued Object Attributes" (this is only if you want to make sure that the patch will always look the same, no matter what the default color scheme is).

Finally, we need to check "Define Fixed Initial Window Location" in the view menu, to save the default position of the patcher window.

#7: Dynamically Loading Our poly~ Abstraction

pluggo2poly_main.maxpat shows how to load your "poly~ abstractions" dynamically using the patchername attribute. We use matrix~ in order to change the amplitude of the effect smoothly: we fade out, load a new abstraction in the poly~ object, and then fade back in. This patch also demonstrates a way of controlling the parameters from the outside of the poly~ object, in the same way as with vst~ object (with get messages, and list of {parameter, value}).

Here are a few suggestions to go further:

use a more sophisticated regexp in 3b, and you could get the text associated to the pp to display the hint of your sliders.

add randomize and evolve capabilities (would be relatively easy from JavaScript)

add a more vst~ -friendly message to get the parameters and programs name (this would require querying pattrstorage)

add a default value attribute to pp2pattr

Now that we have the tools to convert Pluggo-ready patches into poly~ abstractions, it will be pretty simple to start converting your Pluggo patches for use with poly~. Also, now that you have played around a little bit with programmatic patch creation, you can begin to put these tools to other uses with a little development. Have fun!

As exporting plug-ins is not currently available for Max 5, we will look at another alternative in this article based on a new feature of the poly~ object, which allows you to dynamically load new abstractions without recompiling the DSP. To help users explore this new alternative, we will demonstrate different ways to convert a Pluggo-ready patch made with MaxMSP 4.6 into a patch that you can load as a poly~ abstraction.

re-purposing-plug-ins-in-max-5

Re-purposing Plug-ins in Max 5

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. (This work was developed in Max 4.6, an older version.)

The series covers the basics of synthesizer creation using Max and MSP. While these tools are incredibly powerful, they can also be overwhelming to the new user. I attempt to plow through the hundreds of objects to put together an efficient and straight-forward mechanism for synth creation.

In addition to using the standard Max and MSP objects, I will provide custom externals and sub-patchers that can help anyone create complex software synthesizer.

The series includes the following articles: Creating the Simple Synth (part 1), Output manipulation using Envelopes (part 2), Basic Filtering (part 3), Turning It Polyphonic #1 (part 4), Turning It Polyphonic #2 (part 5), A User-modable Oscillator (part 6), Making a plug-in (part 7), Plug-in Tweaks (part 8)

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-introduction

Synth-Building with Max/MSP (Introduction)

Gregory Taylor

I tend to look at larger bodies of work -- novels, recordings - even things like software, I suppose -- and wonder if there's a single point at which everything began. Where did Hipno "come from?"

Hipno actually started out life as a really unfocused effort to leverage a bunch of 3rd-party Max work (Tap.Tools, GTK, etc.) into plug-ins. After an initial surge, the artist in me couldn't handle the diffuseness of this as a vision, so in going back to square one I started pulling things apart and reflecting on a vision for the package. Once I sat back, it didn't take long to define the problems I wanted to tackle in Hipno, namely how plug-ins are controlled in realtime -- from within the plug-ins themselves.

I have an obsession with how things are controlled and structured, so I had a fair number of resources to pull from. This included my own work with video as a control source, developing the Teabox sensor interface with Jesse Allison, as well as some work I had done with implementing Jitter-based preset interpolation from a paper by Ali Momeni presented at the 2003 NIME in Montreal. Once the concept and structure of the Hipnoscope was in place, I felt like I had something around which to anchor the entire package.

The Hipnoscope was really the Idée Fixe for the whole plug-in collection -- and it represents my neurosis in a way, because in my mind it is like the embodiment of every plug-in within that one element which is shared by the various plug-ins. The "scope" become the Magic 8 Ball that determined what each plug-in would be.

What was the "first" Hipno plug-in you (guys) did?

Though others had been started earlier, Spuntorrt was finished first. It was actually done a couple of years before the whole package shipped. It was a good plug-in to do first because at the time it only had 4 parameters at the time, and none of them operated in a linear or logical manner. This was the test to see if the Hipnoscope could actually make such a plug-in usable.

If the plug-in collection was a collaborative activity, did its development kind of reflect your own interests as composers/performers, or was it a question of extending ideas that appeared as you worked?

It definitely grew out of our areas of interest. Nathan's plug-ins all grew out of his research and development on granular synthesis for the GTK. Jesse's plug-ins largely grew out of his interest trying to mangle FFT processing in unusual ways. Many of my plug-ins are based on the Tap.Tools or grew out of my preoccupation with how to control parameters in a plug-in host in realtime.

For me, one of the interesting things about working on things in series is the idea of "emergence" -- ideas or whole themes that more or less pop-up unexpectedly in the course of working that you might not have had in mind at the start. Did you find that happening?

There is one case in particular where it happened. You might recall when it came time to flesh out and make presets for the plug-ins?

There just seemed to be no easy way to make presets in our hosts of choice and then get them to the plug-in developer. To remedy this, we tried a series of strategies which ultimately ended up being Hipno's XML import/export feature.

One of the obvious things that makes the Hipno collection different from other plug-ins is the Hipnoscope. Where did that idea come from, initially?

The Hipnoscope does something that I'm quite proud of, which is that it allows you to quickly audition a plug-in and some of its possibilities. But at the same time it really rewards those who are patient explorers that spend time really focusing on subtleties offers. I still find myself surprised at the results I get sometimes - the Hipnoscope creates this palette where there is an almost infinite range of subtlety with some of the plug-ins.

Many plug-ins would not exist without the scope, because without it they really aren't anything new. For example, the CrackVerb plug-in is basically a reverb. No one needs another reverb.

Though most reverbs don't contain sample-rate reduction or other distortion controls as a feature, it really isn't the reverb algorithm that makes it interesting to me as an artist. It's the morphing and exploration of a terrain that bring a kind of special life to sound produced by the plug-in.

Was it a visual idea first, or was the visual part of the scope the *solution* to a problem?

I don't know, to be honest. It was a solution to a technical problem, yes, but it was also a solution to an artistic problem -- how to make 40 something plug-ins seem to be a cohesive whole. So the visual aspect is at least part of the problem with which I was struggling.

One interesting feature of our life with pluggo has been that no one seems to use *all* the plug-ins in a given collection, but rather gravitate toward individual ones. It's as if everyone only uses something like 7 (plus or minus 2?) plug-ins. Is that the case with you?

I think I use most of them occasionally. There are only a handful that I use consistently. There are too many plug-ins to really dig deep into them all on a regular basis. I think this makes the Hipnoscope all the more important, because it enables you to audition the plug-ins more rapidly to determine which handful you are going to use on a given project.

Do you think that's different from people who *use* rather than *create* the plug-ins?

Probably not.  Most people are crunched for time and probably gravitate toward a few choice effects or instruments.

Just out of curiosity, which Hipno plug-ins can you not live without? How about your collaborators?

I typically use the plug-in in combinations. One of my favorite combinations is Greequaincer feeding a Sphylterbank. I also like combining Spuntorrt, Morphulescence, and DrunkenSailor in various ways quite a lot.

(Note: We also put this question to Nathan Wolek, one of the other members of the shadowy Hipno cabal. Here’s what he said:)

Greequaincer. My personal style is heavily dependent on textures and pulses. This plug-in delivers both. Granular textures typically oscillate between a single pulse and totally randomized. By giving the grains a pattern to follow, you can give some subtle organization. Add in the echo generators and this plug-in can produce some really beautiful textures.

When you make things and send them into the world, you can't always judge what people will find interesting. Do you think that there are "secrets" about Hipno that people you meet don't seem to have figured out?

People seem to have grasped onto most of it pretty well -- even the XML import and export.

The one trick that is a favorite of mine, and possibly for you too, is exporting an XML preset from one plug-in and then loading it into a completely different plug-in. This is a bit nerdy, but if you edit the XML manually then you can do some neat stuff like load the Hipnoscope color arrangements from plug-in into another plug-in. I think you have used this approach with the Hipno presets, yes?

Do you think that there are "secret" Hipno plug-ins that are relatively unknown but really interesting?

Because I am so close to the plug-ins, I have a hard time gauging what would be unknown.

Perhaps I didn’t phrase the question that well... Uh, do you have the sense that there are "undiscovered" or "less well-known" plug-ins in the Hipno collection?

It's like I said about the Hipnoscope -- it rewards the patient listener who spends time focusing on subtleties. It's not so much that there are "secret" plug-ins as it is that each plug-in has secrets of its own.

In this interview, Tim Place speaks about his work as a developer and artist, charting the numerous development projects which pooled together to create Hipno.

an-interview-with-tim-place

An Interview With Tim Place

Andrew Benson

Even before the Max for Live beta was opened up to the public, a community of testers was hard at work putting Max for Live through its paces.  The integration of Max into the Ableton Live environment opened up a whole spectrum of possibilities that many users hadn't even considered until now, and it didn't take long before our beta testers were begging to show off their new projects to the larger community.

Once the veil of secrecy had been lifted, we saw an unprecedented flurry of blog posts, screencasts, Twitter updates and even whole websites devoted to the software and what people are doing with it. There was already a vibrant and engaged community of users developing around Max for Live before the product was even released.

One of the areas where there seems to be an explosion of development is the integration of various alternative controllers into Live sets.  A lot has been said about the new Akai APC40 and Novation Launchpad, but Max for Live can benefit a variety of controllers.  Ableton Live has a fairly friendly interface for mapping MIDI controllers, but users have increasingly desired interfaces for things like Open Sound Control , serial data, HID devices, and other non-MIDI protocols.  With mature devices like the Monome, JazzMutant's Lemur, and others using OSC as their native communication protocol, Max for Live presents a welcome set of tools for use with Live.  Monome users can expect to see many of their favorite patches ported to Max for Live in the near future, if they aren't already.

Now, Monome and Lemur aren't the only controllers that will benefit from Max for Live.  Here is a screenshot of a patch being developed by Vlad Spears for the Snyderphonics Manta controller:

"Honeycomb maps incoming pad presses from the Snyderphonics Manta to a latticed tonal system of midi notes.  This lattice turns the Manta into an isomorphic keyboard, allowing consistent chordal shapes to be played anywhere on its surface.  A minor chord is always created with an inverted triangle having its root note in the upper left corner, while a major chord is always a triangle with its root at the top of the shape.  This isomorphism makes it easy to play the Manta and produces surprising melodies."

Vlad is also busy working on devices for Monome control, porting his popular Daevl.Plugs, and all sorts of wonderful sounding experiments for Max for Live.

Recently, Create Digital Music ran a story about Scott Wardle's Ms. Pinky digital vinyl system being ported to work with Max for Live:

Livid Instruments has also been working on integrating their new controllers Block and Ohm64 with Max for Live devices.

For those individuals who like to create their own unique experimental controllers, here is a video from "Liubo" showing an Arduino connected to Max for Live:

Of course any device communication that natively works inside of Max should work the same inside of Max for Live, so gaming controllers, multitouch clients, serial boards and custom MIDI controllers of all varieties should work just fine.  Combine this with the Live API  objects and hardware controllers for Live are about to become way more interesting.

Included with Max for Live are 40 of the most popular Pluggo plugins ported as editable Max devices.  This is the result of a labor of love to clean up the old patches, add comments where needed, and generally spruce up the user interfaces.  Admittedly, even after years of Pluggo updates, the plugins themselves were looking pretty dated.  Max for Live provided an excuse to weed out the best plugins and modernize them a bit, taking advantage of some of the features that are specific to the Live integration.  Also, since all Max for Live devices are editable, users are welcome to take them apart, reuse bits of the patches, or look at them as some really quirky examples of patching.

Peculiar Instruments, Custom Effects, and Email

It is tempting to focus all of our attention on the grand productions that people will build in Max for Live, the fully realized synths and complex sequencers. As Robert Henke noted in a recent interview on this site, “MaxForLive allows people to solve their very individual problems with a high degree of elegance.” A lot of the devices produced in Max for Live are likely to be very simple solutions to very unique problems. To help you on your way, there is an impressive set of Max building blocks and tutorial devices developed by Manuel Poletti included with the Max for Live content.  The building block devices show just how effective simple Max patches can be, and also offer less experienced users a set of well-designed demonstrations of common audio and MIDI processing approaches. Also included are the Big 3 devices developed by Darwin Grosse - Buffer Shuffler, Step Sequencer, and Loop Shifter - more complex devices that you can play with right out of the box.  There will certainly be plenty of new toys to keep you busy.

During the beta process, long-time Max user Nick Rothwell decided to take off in a completely different direction and came up with some really clever devices.  Since Max provides access to all sorts of programming and scripting languages, there is a potential to integrate any sort of scripting API into a Max project.  Eager to test this idea, Nick decided to be the first user to create an email-reading device:

He then followed up with a Twitter client as well, using Java and python libraries:

As Nick's experiments suggest, we are bound to see all sorts of strange pairings once people start using Max for Live and exploring all of the options.  As Robert says, “People will come up with ideas which totally exceed what any one of us would imagine people would do.” So, what will you build?

the-edit-button-has-been-pressed

The Edit Button Has Been Pressed

oli larkin

project1

pMix / int.lib

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. 

special note: As of Max 5, Cycling '74 no longer supports Pluggo plug-in building.  You may be interested in Max For Live, which allows you to build devices for Ableton Live.  You could apply many of the techniques mentioned below to build such a device.

Well, in honor of Pluggo 3's brand new release, this tutorial will focus on turning our existing software synth into a full-blown VSTi plug-in. Well, full-blown might be a bit strong - rather, we are going to get it to the point that Cubase, Logic or Digital Performer can host it...

Output manipulation using Envelopes (part 2)

The power of Pluggo is quite amazing. I've had to write VST plug-ins in the past - alas, it was so long ago that I've forgotten everything but the pain. While it's a fairly full-featured development SDK, it also demands a high level of programming competency from it's developers. In addition, getting a plug-in to work reliably in Cubase, Logic, Ableton Live (for effects), Digital Performer and RTAS requires a level of commitment that most beginners don't really want to (or can't) take on.

Pluggo opens the door nicely for non-programming-gurus to get into the plug-in game. And, best of all, you can parlay your MSP programming into the VST environment pretty easily. To start with, let's take a look at the new version of our plug-in:

While it looks remarkably similar to the synth from the last article, there are three differences:

The midi input section has changed, with the addition of the plugmidiin.

The audio output section has changed, from an ezdac~ to a plugout~/dac~ combo.

There is an additional plugconfig object just floating there.

The plugmidiin addition is really quite simple - we've just paralleled the midiin object with a plugmidiin. What plugmidiin does is get midi information from the VST (or MAS or RTAS) environment and translate it to look just like data from a midiin object. So, for our purposes, we just have to feed the output of plugmidiin into the midiformat object and we have MIDI input.

The change to the output section is a bit more complex. First, we traded in the ezdac~ object for a dac~ - this is a bit of a convenience, since we don't want our users poking at a useless button when they are running out VST instrument. "startwindow" and "stop" messages have been added so we can start and stop the audio when we are running this in Max. Next, we've inserted a plugout~ object between the clip~ object and the dac~ output. What does it do? Well, it just acts like a dac~ when we are running the patch as a plug-in.

Finally, that plugconfig object. Believe it or not, this is where all the action lies. If you place a new plugconfig file on a patcher and double-click on it, you will get the following text edit window:

These are your commands for telling Pluggo how to host your patch. While an exhaustive explanation of these messages would be beyond the scope of this article (plus the manual and tutorials do a great job already), we will just look at our "altered" version to see what matters:

We've changed two lines, and added a third. The first line changes the number of "presets" available from 64 to 16. Why? Because any presets that you list, but don't define, will just be named "Program 1", "Program 2"...          When I was beta testing the first version of Pluggo (waaay back when), I was notorious for calling these names "Crap Presets", and that's how most of my C74 friends best remember me. Since we won't be defining presets until the next tutorial, I want to at least limit the number of "Crap Presets" to 16.

Next, we've changed the autosize message to windowsize, so that our definition of the window in Max will be honored by Pluggo. There are other sizing options, but for now we will just use the Max window size.

Finally, we added a "#C synth;" message to the list. This is the key for Pluggo to see this patch as an instrument (meaning that it will see MIDI input) rather than an effect (which will receive audio input). By adding this one line, we are defining our plugin as an instrument, and it will automatically show up in Cubase's instrument panel.

Once we've added the appropriate objects, and edited our plugconfig settings, we need to begin the "Pluggo-izing" of the patch. The first step is to save the patch as a "Collective". Not familiar with them? I wasn't either until I started working on Pluggo patches. Never fear - they are nothing to be afraid of. Just select the "Save As Collective..." menu option and hit the "Make" button. You will get a standard "Save As" dialog, where you name your plug-in.

One very critical point here - the name of the collective will be the name that the host application (Cubase, Logic, DP or Pro Tools) will assign to your plug-in. By default, the "Save As Collective..." option appends a ".clct" extension to your patcher name. This wouldn't be good, since a plug-in named "cs_06.pat.clct" would look pretty silly in the Cubase or Logic plug-in menu. So, as I've done above, take off all the extensions so the plug-in will be named simple "cs_06".

Hit the save button, and Max will grind for a minute. When it is done, you will have a Collective file wherever you chose to save it. The next step is to run it through Plugmaker.Plugmaker is a magical program - it does stuff that nobody will discuss, but it does it consistently and well. To make a plug-in, you need to drag your new collective onto Plugmaker. In about a second, a file "cs_06.pi" will be created - a valid Pluggo plug-in! Just wait, though - no celebrating. One of the tricks with Plugmaker is that it is a two-step process. You need to take your new ".pi" file and drag it onto Plugmaker again. This does additional voodoo, and completes the plug-in making process.

The result of these few steps is a completed Pluggo plug-in. Drop the result of this exercise (currently named cs_06.pi) and drop it in the "VstPlugins" folder of your host application; run the app, and cs_06 will appear in          your list of available instruments.If you are reading this at work, and don't believe it could be that simple, just take a look:

There you go - a 16-voice polysynth with simple waveshaping controls, runnable within Cubase, Logic, Digital Performer or Pro Tools. Believe me, if you tried to do that with a bit of C++ code, you'd wouldn't be done for several weeks (if ever).

Next time, we will be going over the creation of presets and setting up storable parameters. In the meantime - keep that Plugmaker hopping!

The files for this tutorial are available from the following link: cs.06.zip

synth-building-with-maxmsp-7

Synth-Building with Max/MSP #7

Several years ago, I wrote a rather lighthearted piece for the old Pluggo website about how I wrote my very first pluggo plug-in using MSP. That article turned out to have a life of its own I didn't really expect...

People actually read it and liked it, and (unaccountably) found it even easier to make sense of than the Pluggo Developer's Guide that I learned from. People still mention it when I meet them. In the intervening time, my little plug-in was promoted from "Pluggo the Month" to a part of the standard Pluggo distribution, Max/MSP went dual-platform, and Pluggo itself was improved and updated. Time flies when you're having fun.

Recently, I'd be reminded of my ancient article when I got email from a perplexed reader who was trying to make sense of the procedures with a current version of MSP. Since we've changed the way that plug-ins are built, I realized that perhaps it'd be a good idea to find my humble little article and update it for use in the Current Dispensation.

You can click here to download a zipped and updated version of the Plug-In Confidential that contains the complete source to the KnaveStories plug-in that comes with Pluggo, the necessary objects you'll need to make it, and a step-by-step description of how I turned an idea into a plug-in.

I thought a bit about perhaps adding a way to set the rate of calculation to match tempo from a host application, but decided to leave that as an exercise to the perspicacious reader. While I was up in Minneapolis recently performing at a festival, someone asked me if I could maybe write another Confidential that describes how to make a simple plug-in that includes host-sync capability, and I said I'd work on it. So watch this space, okay?

Since we've changed the way that plug-ins are built, I realized that perhaps it'd be a good idea to find my humble little article and update it for use in the Current Dispensation.

plug-in-confidential-redux

Plug-In Confidential, Redux

Marsha Vdovin

Audio Wizard Tom Erbe is a generous guy.  His SoundHack program is a legendary and beloved tool for mangling sound and he gives it away for free.  Now he has made VST plug-ins so I called him up to see what the man behind this benevolent act was like. I found a funny and wise educator and musician who loves what he does.

I grew up in the Midwest, in Milwaukee and Chicago, and went to school at the University of Illinois Urbana-Champaign. I got involved with music technology pretty early on. My great uncle was a radio engineer at WCFL, and my grandpa was a police radio operator, back in the ‘30s. My great uncle gave me an oscilloscope and microphone when I was about ten or so.

So I ended up at a high school in Illinois, which happened to have a radio station, and as soon as my friends found out that I soldered, and knew about microphones, I became the technical director there when I was 15.

I had a nice crowd of friends in high school that were very into music. We all had our own radio shows, and we all were always competing to find the more obscure music. The weekly trip to the record store was the basis of high-school social life for me.

Not really. I really got into things from being a DJ. Also, being the guy who could fix all the gear, as well. We used to do a little outdoor fair that the community put on, and our radio station would go there and put on the music. I would be the one climbing the telephone pole to hang the speakers. It was all fun, and it was just getting together with friends who were really interested in music.

It’s seems so unusual for a high school to have a radio station.

Yeah. This was back in the ‘70s, and back then there was a provision by the FCC for a Class D radio station license. It allowed small organizations to have low powered radio stations, under 10 watts.

So there used to be a lot of high-school radio stations in the ‘70s. I was lucky, because I could get into music technology very early.

Then, when I was finishing high school, I found a recording studio that I was able to intern at for a bit. I learned quite a bit there as well. They let me play with the mixing board, and some of the equipment.

When I got into college, I went into computer science and music. At the same time, I worked at a record store, DJ’ed at a couple radio stations, interned at Faithful Sound Studio, which was where Mark Rubel worked. He runs Pogo Records now, a recording studio in Champaign.

I learned quite a bit then. I also played synthesizer in a band. I just got really, really interested in electronic music. Of course, as my tastes got more adventurous, I got into weirder, as well as more serious, electronic music.

So yeah, after I got out of college, I found a job—I found that there was an opening at the Computer Audio Research Lab at UCSD, and took it. It was just perfect for someone with a degree in computer science and music minor.

That must have been quite a culture shock, coming from the Midwest.

Yeah, I guess so. [Laughs.] The options in the Midwest for jobs at the time were very conservative, or at least that’s what it seemed like. Someone with an engineering background was going to work for an industrial company. I wanted to get into something more related to music. So it really seemed like quite the right thing to come out to California.

It must have been amazing. There were a lot of really interesting composers that came through back then.

Oh, yeah. A lot of people were visiting. Gordon Mumma was here for a good long time. That was very fun. John Cage visited. Of course, Roger Reynolds was here—and still is. This was also the time when the Computer Audio Research Lab [CARL] was here, at the Center for Music Experiment. We were developing a lot of software tools for signal processing that all ran on the mainframe computer. The music software all ran in non-real time.

Mark Dolson was at CARL. He developed sound file convolution and phase vocoder software—a lot of cool stuff. And Dick Moore, who developed C Music, which was one of the more interesting Music 5 languages in C.

So there was a lot of good software development going on, and I just spent all my time trying to figure out how all of it worked. [Laughs.] I worked on a project developing a real-time pitch detector for electronic violin. Also more basic things like a MIDI interface for a Sun workstation. Which, at that point, we thought was sort of a nice, small, compact computer. [Laughs.]

We were trying to get things working in real time, but at the same time, there was a lot of interest in research with signal processing. I worked there for about three years, but I was itching for a place that was even more creatively active. In ’87, a position opened up at Mills College for the technical director, so I went for that position.

That was such an exciting time in the Bay Area.

It really was. I was at CCM [Center for Contemporary Music at Mills College]. Anthony Braxton was there, David Rosenboom, and Larry Polansky; Chris Brown had just started working. The Hub was there. Bob Ashley came by for a couple of years and I recorded and played synthesizer on his album, Improvement.

So that’s where I started developing the software that became SoundHack, back in ’89.

What was your philosophy behind it? Or did it just evolve organically?

Well, a lot of the fascinating things at UCSD, it seemed to me, were unavailable to people who couldn’t have a mainframe. So for a couple years, I really tried hard to get a mainframe-type computer at Mills and only got so far. I ended up with sort of a cast-off Hewlett Packard Bobcat computer, and I got a lot of things working on it.

Then suddenly the Mac II came out, which had a floating-point processor, and it was the first computer that could actually run serious signal processing, because it did have floating point built in. The earlier Macs didn’t, so it was completely impractical to do anything on them.

So at that point, I thought, “Well, maybe I should learn how to program the Mac, and bring some of these interesting things to the Macintosh.” And that’s what I went ahead and did. I really love the sounds that you can get out of convolution, and out of the phase vocoder.

It took a couple years. I think the first version of SoundHack came out in ’91. And then I spent maybe five years just continually developing and updating it and adding new processes, always as a standalone application.

I didn’t think anyone would want to pay for something that took a whole day to process three minutes of sound. I was excited about the software, and wasn’t really thinking about marketing.

This was before there was any sort of notion of open source software—at least it hadn’t hit me yet. I just wanted to get something out there that would be helpful to experimental musicians, and would help people make a lot of different sounds.

I’m a teacher, computer music developer, recording engineer and occasional musician. I use Max/MSP and PD [Pure Data] in all of those roles.

At UCSD, I teach the fundamentals of music synthesis. It’s extremely helpful to have a program that is modular, that allows me to show the architecture of an oscillator, or a filter, for instance, and show students how to build these things up from small components and into a hierarchy.

My other relationship with Max/MSP is that I am a plug-in developer. The reason I use Max/MSP is to prototype all my software. For example, three years ago, I designed a bunch of delay effects for VST/RTAS/AU, one of which was just called +delay, but it’s really based on the old multi-head, rotating delay lines that were out in the early ‘60s. I prototyped everything in Max, and I wanted to give this delay analog-like behavior, so I needed to do some sub-sample interpolation. I wanted to put some sort of tape saturation as well as some nice filtering in the feedback path, so I could emulate the high-frequency loss in tape. But also allow people to go farther than that.

So I built this all up as a huge patch, before I ever went to the C compiler. Then after I built the patch, I was able to quickly go into C and build a plug-in out of it. Using that process, I built a pitch-shifting delay, which uses the classic, multi-head technique for pitch shifting. I also built a granular delay, where the delay line is being sampled with a grain stream.

So it’s become my process, now, I guess for the past three or four years, just to build everything, in either Max or PD first. Once I’m convinced I have something that sounds good, then I implement it in C, and maybe do some refinements.

You came out with some plug-ins for Max for Live?

I did. I’ve programmed about 15 plug-ins now. I’ve been doing them since, oh, I guess since about ’99, 2000. I found a lot of people were using my plug-ins within Max, using the VST~ object. So they were using my Decimate plug-in, or my Binaural plug-in, and I thought that was possibly a little inefficient for them, because the GUI does take up some CPU.

Also, within Max, you can get to parameters much quicker than you can through the VST~ object—at least more direct access.

So this last year, me and a couple grad students and undergrads ported all of my plug-ins to Max/MSP as externals. So now those are all running under Max/MSP and Max for Live.

I don’t know. [Laughs.] It’s really hard to say. I never look at how many people download it. I see a lot of people talking about it, and a lot of people saying, “Hurray!” when it got announced. That’s one thing about developing software, when you give your software away for free, you don’t really get a lot of feedback. So I think they’re popular. I should check how many downloads there are.

But people were definitely asking about them a lot before they came out. Then, when they came out, the announcement got retweeted quite a bit. [Laughs.]

There ya go. It seemed to go up on every blog. But I don’t know if that indicates popularity. I do hear from time to time that, oh, I use SoundHack’s externals for doing this or that. So I get feedback here and there, but I don’t spend all of my time looking at other people’s blogs or press releases.

Good for you. But that can be a hard thing to resist.

[Laughs.] I’m usually focused on the new software. So I’ll assume that people like it. If they do send me some notes back, it’ll be encouragement for me to do more. So I guess I actually would like to hear whether people are using them or not.

They are sort of different than other externals for Max in that they’re very complete processes. They’re more like stand-alone effects, studio effects, than they are externals. So I’m really not sure how that would gel to a typical Max user.

At first, I thought there was no reason to turn my VST plug-ins into externals. I thought, well, a Max user could just build them themselves, so I don’t need to do that for them. But then when I found enough people using the plug-ins, I figured, well, maybe it would be nice for them to have some convenience.

Especially the ‘Max for Live’ people. They just want to get going—fast.

Yeah, definitely. As Max gets more popular, and Max for Live gets more popular, there’s a wider variety of users, and some who don’t want to sit there twiddling so much, or programming so much. So I imagine there’s a need, but I haven’t had a lot of feedback yet.

Right now I’m working on a set of plug-ins that are based on the classic phase vocoder algorithm, which I feel has really not been explored enough in commercial plug-ins. I’m working on a real-time time stretcher, which takes a real-time stream of sound and captures multiple windows from the incoming stream, and layers a time-stretched output. I’m still developing it, but it looks like it’s going to be a really nice way to develop a big, ambient, stretched sound out of any incoming sound.

I’m also working on some stuff with pitch. Pitch shifting out to the ridiculous. I always like taking algorithms beyond the beautiful, to the point where it gets noisy—from sublime to ridiculous. I’ve also done a pitch-shifting vocoder with it, which is sounding really nice.

Then there is also a phase-vocoder looper that I’m developing. It’s sort of like a conventional looper, but it will be using phase-vocoder style pitch shifting and time stretching on all of the loops.

I’m at the difficult part, to make this thing fun to play with, interactive, able to lock it to beat, and all those kind of good things. That’s what I’m doing right now.

I expect to be finished with these, hopefully some time in the next couple of months.

That’s really exciting. Those should get a lot of attention.

Especially with experimental and fringe electronic music getting bigger and bigger.

Search Results