Last month, I explained how DP's Consoles could be used both for remapping MIDI data and as a source of data in themselves, as well as some of the ins and outs of buttons, sliders and knobs. This month, it's time to round things off, beginning with Consoles' Groups function.
Guess what? Console Groups let you group Control Items together so that they can be governed simultaneously by a Master Item. For example, you could assign three sliders to transmit controller messages to change filter cutoff on different channels of a multitimbral synth module. After grouping them and, optionally, creating one master slider for the group, all three sliders could be made to move simultaneously whilst dragging just one.
The way 'slave' Items react to a master is pretty flexible too — they can track a master Item's values absolutely, matching them exactly, or instead offset or scale the values, and even work with negative polarity, so that as the master's value increases, the slave's decreases. As is the way with DP's Consoles generally, the sky's the limit as regards complexity, and dedicated tweakers should be able to dream up some wild and wacky setups that have all kinds of MIDI controllers, note events, plug-in operations and external data sources linked to each other.
Adding a Control Item to a group is simple: select it, choose Group from the mini-menu and type a group letter (A to Z) into the dialogue box that appears. It's here that you set positive or negative polarity and decide whether to match, offset or scale the master value. In the latter two cases you also get to set the 'strength' of the relationship, as a percentage. All these settings can be made in the standard Control Assignment dialogue box, too, which always appears when you first create a Control Item.
Setting an Item to be a master is also simple. Select it, choose Control Assignment from the Console's mini-menu, assign a group letter, then click the Master radio button. There's one important consideration for master Control Items when they're sliders: the so-called 'null point'. You can think of this as a kind of reference point, and it basically allows relative values of masters and slaves to be set up. For example, if you set a master Item's null to a value of 100, and then set one of its slaves (in 'offset' mode) to a value of 20, moving the master to a value of 127 would result in the slave moving to a value of 47. Nulls make master items send 'changes' in value, relative to the null, rather than absolute values, as measured across the entire range of the slider. Tricky stuff, maybe, but important for many Group setups.
Incidentally, nulls can be set either by option-clicking the slider at the desired point or by typing a numerical value into the Control Assignment dialogue box.
It's in the nature of some Consoles to just sit there, being used occasionally to send or re-route a particular type of data, while you get on with the serious business of putting together a track. Consoles don't have to be so passive, though — they can be integrated right into the heart of your sequence, interacting with it as a means to record data into tracks, or modifying data already present in tracks as they play back. It's important to note, though, that while Consoles aren't tied to individual tracks, their Control Items often are, acting as a source of data for tracks, and also following (and perhaps modifying or re-routing) the data during playback.
There are two ways to initiate data recording from a Console. The first is to record-enable any tracks assigned to your Control Item(s), put DP into overdub record mode, then hit Record. The second is to leave all tracks un-enabled but make the Console the uppermost window before hitting Record. In either case the outcome is the same — new data is recorded into appropriate tracks from any Control Item whose output is a track itself, or a MIDI target that is also, somewhere amongst your tracks, a track output. This sounds more complicated than it is. Just assume that the Console automatically 'connects' itself to tracks associated with any of its Control Items and you won't go too far wrong.
When you're playing back a sequence, any Console Control Items associated with data types in play-enabled tracks will animate to reflect the current values of those data types. This not only gives excellent visual feedback of what's going on, especially with controllers, but allows sliders (or other Control Items) to be 'grabbed', at which point data in the track is ignored and the new 'live' values generated in its place. Let go of a Control Item and DP immediately starts dishing out the track's data once more.
Compared to many of DP's other windows, a hastily constructed Console can look pretty awful, making even a Pluggo plug-in interface seem stylish! However, Consoles can be made to look half-decent by using their built-in layout tools, accessible from the mini-menu. Certainly, a little effort spent on ergonomics and aesthetics should be worth it for Consoles you'll end up using a lot.
When you set up button Control Items in a Console, you may notice the little 'M' (mute) option next to some of the value fields. This makes a button behave more like a mixer's mute button in that when it's released it doesn't send an absolute value but instead allows the data to return to the current value of its target controller type. This can work well during playback, when the button is set to control volume, filter cutoff, or some other fairly 'noticeable' aspect of a synth's sound (for example), allowing for momentary interruptions to the sound, very typical of many modern fragmented or glitch-oriented styles.
Having spent time honing your perfect Console, how do you save it? And how do you call it up in another sequence? Well, Console windows themselves don't have Load and Save functions, and there's no such thing as a DP 'Console file' that you'd ever come across in the Finder. Instead, Consoles are actually saved as part of a normal DP file — 'embedded' in it, if you like. This has some important consequences for how you can re-use Consoles that you've designed in different projects, and also how you can best create a 'library' of Consoles accessible at all times.
Loading a Console from another project is done via the File menu's Load command. You navigate to the DP file that contains the Console you wish to open, click Open (or double-click the filename) and then choose 'Consoles' in the Load dialogue box that appears, before finally clicking OK. The Console is loaded into your current project, but may need some tweaking, depending on the degree of similarity of track names, MIDI destinations and so on, between the two projects.
While this is perfectly straightforward, remember that to Load a Console the 'donor' Project must always be available. If you compress, archive or delete it, you'll lose access to any Consoles it contained. For this reason, it's worth thinking about building up a library of Consoles, and this can easily be done by creating a Project that you might call 'Consoles Project' (for example), and that you never use for anything other than Console 'storage'. Every time you created a Console in another Project you could then open 'Consoles Project', load into it the newly-created Console, then hit Save. A slightly irksome solution, maybe, but one that should help to ensure that your favourite Console creations are always available in one place when you need them.
Applications such as DP, which use host-based processing to do their stuff, give to home- and commercial-studio owners alike a level of performance, flexibility and value for money that was unimaginable only a decade ago. What they don't provide, though, is either totally reliable, crash-proof operation, or very much guarantee of backwards (or, for that matter, forwards) compatibility. We run the gauntlet not only of operating-system conflicts, but of relentless upgrades and third-party software development efforts, and as a result life can sometimes get tricky, especially when all you want to do is make music. I doubt there are many Performer Notes readers who haven't at one time or another opened a lovingly-created DP Project (even one they've recently worked on!) only to find that, well, it won't open, or comes up with plug-ins and sound files missing or wrongly set up. As we all know, this is a thoroughly depressing experience, so how do you avoid it, or at least get going again more quickly if it does occur?
There are a range of strategies you can employ — depending on how 'bomb-proof' you'd like your Project-recall chances to be — ranging from the sensible to the neurotic. It probably goes without saying, for example, that freeware and some shareware plug-ins are amongst the most disruptive and least reliable bits of computer code that swim into our lives, however good they sound. You perhaps shouldn't expect to always be able to open a Project and find your 'little' plug-ins in the same state as they were last time you saved — although it's certainly nice when they are!
Consider trying to get to grips with plug-ins' own patch Save and Load facilities, and be prepared to use them, both before closing projects, and after re-opening them. You might also want to consider using OS X's screen- and window-grabbing facilities to take snapshots of plug-in user interfaces, which could then be saved in the Project folder along with the Project file itself, and used as a reference if a plug-in fails to initiate correctly. Shift-Command-3 takes a picture of the whole screen, while Shift-Command -4 gives you a crosshair that you can drag over a smaller area, or, after hitting the space bar, a dedicated window-grabbing tool that snaps individual windows. Grabs are saved to the desktop as a default, and can then be dragged to a folder of your choice.
Another option for storing plug-in information, and also track-output assignments, patch information and locations and so on, is the Tracks window's Comments column. You can store a surprising amount of text here, and the odd annotation made whilst developing a Project could potentially save hours in the long run. Of course, all sorts of data can be referenced by DP's Clippings windows — pictures, photos, lyric sheets, you name it. See Performer Notes from way back in August 2001 for more on this superb DP feature.
A more belt-and-braces solution, especially useful if you intend to put away a DP Project for a year or two, is to to try to render as many elements of your Project as possible into future-proof formats. Plug-in-laden tracks can be turned into 'straight' audio in DP in a number of ways, including via Freeze Tracks (see July 2003's Performer Notes), Bounce to Disk, or even a manual, real-time bounce to a new track. If, at some later point, you needed to load these audio tracks into another sequencer, you could either rely on the audio's time stamps to put them in the right place, or for even greater security make sure that individual track bounces always take place from the start of the sequence, so that manually lining up multiple tracks becomes easy. Finally, consider saving MIDI tracks as a MIDI file too, as they will then be much more widely compatible than if they were in DP's own file format.