DP3 & Multiple Audio Interfaces; Waveform Editor

DP3's revised Configure Hardware Driver window, with facilities for selecting multiple interfaces.p class="introtext">This month we take a look at using multiple audio interfaces with DP3, the new OS X patchlist format, and practical uses for the Waveform Editor for all DP users.

One of the big advantages of running DP under OS X is its ability to use multiple audio interfaces simultaneously, such as a MOTU Firewire 896 with a PCI324-based 2408MkII. To accommodate this new flexibility, DP4's Configure Hardware Driver window has been changed, and some new options have been added. Since virtually all interfaces designed to work with OS X have Core Audio drivers, the window's uppermost popup menu nearly always stays set on 'Core Audio'. Instead, interfaces available to DP4 show up in the text field beneath, and selecting them for use is as easy as clicking on their names. If you're using more than one interface you need to specify a Master Device — the interface which DP4 will use to determine the audio clock for the system. You can then configure clock options for each interface using the 'Clock Modes' menus.

What isn't quite so obvious about this new arrangement — and you'd be quite forgiven for not twigging this immediately — is that DP4 cannot by itself synchronise interfaces attached to it. To take the example above of an 896 and a 2408MkII, each has its own timing clock (although the 2408's is actually on the PCI324 card). DP4 can address them simultaneously, but it has no facility for synchronising their two clocks, so left to its own devices a system like this would probably be plagued with clicks, pops and audio-timing problems, especially if you tried to route an input of one interface to an output of the other. Consequently you still need to synchronise the two interfaces manually, as it were, by taking a word clock output from the 896 to the word clock input of the 2408, for instance. You'd then need to designate the 896 as the Master Device in DP4's Configure Hardware Driver window, and configure clock modes for each interface appropriately.

You also need to remember that some interfaces, including the Mac's own 'Built-in audio controller', have no facilities at all to send or receive clock, so any attempt to use them in conjunction with another interface is likely to be problematic, and could result in drifting timing or worse. So the moral of the story is that if you intend using more than one interface, make sure that the ones you choose for use with DP4 can synchronise with each other — this is often not the case with cheaper USB units, for example.

Using multiple interfaces can sometimes scupper attempts to keep a DP4 system running with low latency, as according to MOTU the number of interfaces (and hence drivers) you're using has to be reflected in the value of the Host Buffer Multiplier setting. So if you were using three interfaces and a Buffer Size of 256, you'd end up with the equivalent of a 768-sample buffer, and a tripling of the system latency. However, some interface combinations seem to work fine when the Host Buffer Multiplier is left on 1, so if you have multiple MOTU Firewire or PCI-based interfaces it's worth trying this out first, and raising it only if you suffer any audio problems. It's very much a case of 'suck it and see'.

OS X Patchlists

Now that FreeMIDI has been replaced by Core MIDI under OS X, the long-familiar FreeMIDI patchlists and ageing Patchlist Manager application have been consigned to history. It's to MOTU's credit that they released DP4 together with virtually all their existing FreeMIDI patchlists converted into a format that would work with OS X, but as this new patchlist format is so different to the old one, and MOTU have so far not issued a replacement Patchlist Manager, it's not surprising that some users feel as if they've taken a step backwards. However, although a few things are still up in the air, getting to grips with the new arrangements is not all that difficult, and in the long run it should turn out to be an improvement.

A little bit of an OS X patchlist in XML, showing how some of the basic properties of the synth are defined.You'll find the OS X patchlists that come as part of a full DP4 installation in ~/Library/Audio /MIDI Devices/MOTU. In this folder can be found two types of file you may not be familiar with, '.middev' and '.midnam', along with folders named after manufacturers, containing more '.middev' and '.midnam' files. Despite the slightly scary extensions, these files are nothing more than plain text, so you can open them in something like BBEdit, and I'd urge everybody who makes use of patchlists to do this straight away. What you'll find is an XML (Extensible Markup Language) document which is a structured system of tags and text not dissimilar to HTML. In this case, though, the document describes various attributes and characteristics relating to MIDI (see screenshot, above right). An interesting requirement of XML is that it should be easy to read and understand, so ploughing through a '.midnam' or '.middev' file is not at all difficult, even if you're not quite sure what each bit of it does. It doesn't take very long to realise that '.midnam' files are patchlists — they contain long lists of patch names (and sometimes note names for drum kits) together with basic MIDI information about a single synth or other device. Their counterparts, '.middev' files, are not patchlists but provide information about types of MIDI device made by a particular manufacturer. Consequently there's a '.middev' file for individual companies, containing information about the MIDI gear they make, and '.midnam' files for MIDI devices that need them. So although Akai get a '.middev', it doesn't get any '.midnam' files, reflecting the fact that there's no real point having pre-configured patchlists for samplers.

The '.middev' and '.midnam' formats aren't MOTU's invention, and so are not in a proprietary format like the old FreeMIDI patchlist. To find out more about who is responsible for them you need to follow the link at the top of all MOTU's .middev and '.midnam' files, and visit www.sonosphere.com, the web site of Doug Wyatt, who, as many will already know, was one of the main people behind OMS. You might also like to drop by the MIDI Manufacturer's Association at www.midi.org, as they're responsible for ratifying the new file types. What you soon learn is that the specification for XML-based MIDI files hasn't been finalised, so it turns out that MOTU really stuck their necks out by converting all their old patchlists. It also means, of course, that what we're using now could change at some point in the future, although if it does (and it looks like it might) the change should be only relatively slight.

CherryPicker is Rob Martin's little freeware application for painlessly manipulating FreeMIDI and XML patchlists in OS X.There are various reasons why you might want to modify a '.midnam' file, such as altering patch names to reflect new sounds that you've programmed, or to add an entire bank to accommodate a synth expansion card, so how do you go about doing this? The most direct approach is editing the file manually in a text editor. This is nowhere near as worrying as it might sound. To give you an example, when I recently bought a Waldorf Micro Q, I instantly set about making some sounds, and saved one of them over a particularly boring factory preset in patch location C006, calling it 'Evil Noise rb' (well, it did sound evil!). To get that change to show up in the Micro Q's patchlist in DP4, I opened the Waldorf folder inside Library/Audio/MIDI Devices/MOTU, opened the 'microQ.midnam' file in my text editor of choice, BBEdit Lite, scrolled down to the line <PatchBank Name="Bank C">, located <Patch Number="6"....> just beneath, then changed "Up and Down Lead..." to "Evil Noise rb". After saving, the modified patch name then became visible in DP next time I started it up. Adding an entire bank is not much more difficult, though it might feel a bit nerdy if you've never written anything in XML or HTML before. Basically you need to insert a new bank tag such as <PatchBank Name="My New Bank"> between or at the end of the existing banks, follow it with information about the controller 0 and 32 numbers needed to select the bank, in the following format:

<MIDICommands>

<ControlChange Control="0" Value="x"/>

<ControlChange Control="32" Value="y"/>

</MIDICommands>

and then set about entering patch names in the following format:

<PatchNameList>

<Patch Number="001" Name="My First Patch" ProgramChange="0"/>

...

<Patch Number="128" Name="My Last Patch" ProgramChange="127"/>

</PatchNameList>

before adding a final

</PatchBank>

to round things off nicely.

What the more experienced patchlist tweakers amongst you may have realised already is that the XML patchlists MOTU have employed have a quite fundamental weakness — they can't describe, in a single bank, 'collections' of sounds drawn from several banks on the synth itself. That's because the bank change MIDI controllers 0 and 32 can only be specified once per list of 128 patches. Whilst only a slight change in the '.midnam' format is necessary to remedy this, we can only keep our fingers crossed that it occurs soon!

In the meantime, you might like to check out a great little freeware application, CherryPicker, that was written quite recently by Robert Martin, ex-bassist in the prog rock band Curved Air. CherryPicker can make the renaming of patches and the writing of new OS X patchlist banks almost painless, and (with the bank-select proviso above) convert OS 9 patchlists into OS X XML format and vice versa. You can download it from www.savagetranscendental.com /cherrypicker right now, and there'll be more about it (and the importance of '.middev' files) in next month's Performer Notes.

One final thought — it's probably worth making a safety copy of any '.midnam' files you intend to modify before letting loose with your text editor — that way normal service can be restored if the XML sprawl gets the better of you.