A Grab Bag of Pluggo Dev Tricks

An informal guide to some bonus externs and some patching and building techniques.

For Mac users, the bonus-externs folder is located at:

./Library/Application Support/C74 Plug-in Support/Pluggo Support/bonus-externs/

For Windows users, the bonus-externs folder is located at:

c:Program FilesCommon FilesC74 Plug-in SupportPluggo Supportbonus-externs

It is put there by the various Pluggo installers.

This folder contains a number of extra externals which we use in the various Pluggo based plug-in packages. These externals are unsupported, contain features which may change at any point, and may not be maintained with regard to backwards compatibility. However, plug-in developers may find some of them useful, and you are free to include and distribute them with your plugs. In this article, I'd like to introduce a few of them, explain a little about how they work, and also demonstrate a couple of the tools we use to make our lives easier managing all of our plug-in packages. This article assumes that you are an experienced MaxMSP user and Pluggo plug-in developer, and that you have a basic knowledge of javascript.

First, download this article's source package (developed in Max 4.6). If you don't have them already, add the bonus externs in the downloaded archive to your bonus externs folder and add that folder to MaxMSP's search path. The download contains all of the externals we talk about in this article, as some of them are not included in the Pluggo RT download. Please note that you need to be running MaxMSP 4.6.x and Pluggo RT 3.6.x. for these examples to work correctly.

Plug-in building without tears.

I manually built all of the Pluggo plug-ins once. After that, there had to be a better way. And there is! If you are trying to develop a set of plug-ins, the following will save you hours. This trick is especially good if you are developing a plug and need to rebuild it over and over again. It cuts out the entire collective dialog step-through.

First - a note about versioning systems. Some people find it useful to save their patches and source code in version control systems such as CVS or SVN. Cycling '74 uses CVS for all of its source code, including plug-ins and other MaxMSP patcher source. When saving plug-in patches in CVS, we have found that the text format for patches is the most convenient. While it does not make any sense to diff a max patch as a text file, certain things, such as multi file search and replace become possible. This is the reason why all of the patches in this article are saved as text files with the .mxt extension. For more information about version control, please check out the SVN site at http://subversion.tigris.org/.

Open the patch called plugbuilder.mxt in the plugbuilder folder. This patch should set up the source and target folders for plug building. By clicking on the various message boxes you should be able to get the js "plugbuilder" object to send the correct messages to Max to build the plug with the same name. Check that it's working correctly by loading up the plugs which are built into _buildfolder into your favourite host. If you like, you can modify the javascript object to build directly to your VST folder by changing the value of the vstfolder variable.

A quick look at the source of plugbuilder.js will give you an idea of how this actually works. Have look in the build() function. Here are the crucial lines.

Almost all of the rest of this very small js script is stuff for parsing folder and file names on both platforms.

Ok, so far so good. But there is one problem. There is no way, using this technique, to specify a collective build script for any plug-in. This means that we need to find a way to include any file that we need in our plug-in which is not normally included by MaxMSP. Typically I prefer to leave the plug-in source folders out of the Max search path, and have all of a plug's resources present in the root of the plug's source folder. That way I know when I'm missing something. Sometimes it may be necessary to include files which are not automatically added to collectives. An obvious use for this is when you might have custom externals in your plug-in but you do not want to have to put your users through the hassle of loading things into bonus-externs, or you just want to "hide" them in the plug-in collective, or maybe you want to specify some audio files as wavetables. This is where the buildassist object comes in handy.

Buildassist

Open the plug-in source called buildassist_plug.mxt. You'll notice that it contains a non standard object I wrote called "loser~". This extern takes an audio input and multiplies it by a gain amount, and is entirely less useful than gain~.

The buildassist object looks for its argument and includes this file in the collective when the plug is built. This plug should work fine in hosts even though the loser~ object is not in bonus externs. You can even go one step further and get the buildassist object to include itself.

Buildassist has a couple of attributes. @path is required, the path to the file to be included. "@extension external" is required when adding an external to the collective, this takes care of getting the correct external for the platform the plug is being built on. You may also include folders of files if you set the path the the folder and use the "@type folder" attribute.

Right - that gets plugbuilding out of the way - now let's have a look at some plug-in patching techniques.

A better bang - ddg.beatsync

Have you ever stared at the pptime and pptempo help patches and felt an overwhelming sense of despair? The following is for you. Darwin Grosse wrote the ddg.beatsync object when he was working on the first version of Mode, and it offers a nicely cleaned up way of getting timed bangs, ideal for use in step sequencers or arpeggiators. Check it out in the ddg.beatsync_plug-source folder.

The arguments for ddg.beatsync are number of steps, bar length (in steps) , and the initial step number. The inlets are well described by their assistance strings.

ddg.exclusive - a super radiogroup!

This trick is for all of you who have been frustrated by the lack of customization possibilities in the radiogroup object. The patch is called ddg.exclusive_plug.mxt. Here's what it looks like.

Have a play with the patch for this one. ddg.exclusive is a really great and simple solution for a really nagging little problem.

In a similar vein as ddg.exclusive comes this next object by Tim Place. It is designed to get around the problem of connecting more than one UI object to the same pp object.

Gang.

You'll find it in the gang_plug-source folder.

Patching multiple UI views of the same parameter can be pretty tricky, but the gang object makes light work of it. Notice how both UI objects can safely be used to modify the parameter value. Windows users need not be worried about the build error for js32mt.dll. This file is included in all Windows Pluggo installs.

This next plug demonstrates a way for a vst plug-in to save a filepath as parameter data. This trick was invented around the time the Essential Instruments first appeared. The objects presented here were written by Darwin Grosse, and the patching technique is similar to the one we use in "easy sampler". The only restriction of this technique is that the total file path must be 255 characters or less. The patch is in the saving_filepaths_plug-source folder.

That wraps it up for this set. Please feel free to use any of this in your own work. There is only one caveat - all of this stuff is unsupported and may change at any time. If you have any questions please feel free to ask them on the Pluggo forum. I'd be happy to try and explain myself further. Credit for the objects and techniques described in this article should go in the first place to Darwin Grosse and Tim Place.