A Grab Bag of Pluggo Dev Tricks
An informal guide to some bonus externs and some patching and building techniques.
./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.
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/.
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.
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.
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.