The Compatibility Game - ProSoundNetwork.com

The Compatibility Game

The “big features” that live within a DAW—digital audio, MIDI, automation, video integration, etc.—are already in place, but once you go outside the DAW, matters become less certain.
Author:
Publish date:

Craig Anderton The “big features” that live within a DAW—digital audio, MIDI, automation, video integration, etc.—are already in place, but once you go outside the DAW, matters become less certain. Compatibility is crucial because no product supports everything, so we have to be really careful to set priorities and make buying choices that accommodate those priorities.

Image placeholder title

There are two main compatibility issues, starting with platforms. When Microsoft and Apple change their operating system, the ripple effect not only impacts DAWs, but also may affect the drivers and peripherals DAWs need to connect with video and audio. After an OS update, some users are essentially dead in the water until new drivers arrive for their audio interfaces. Nor are optimum hardware choices always obvious. A “high-performance” video card may be gaming-centric, so a driver “update” that delivers better game performance may do so at the expense of audio streaming.

Developers have also complained about Apple modifying hardware specs, like changing the PCIe bus and thereby rendering some previously PCIe-compliant products obsolete. Or consider Microsoft’s “audio driver model du jour” approach—no wonder companies stick with ASIO. Another problem is the ever-changing mobile world. Many programs require tweaks for iOS updates, but the situation is even more chaotic with Android’s diverse operating systems and standards.

Companies can’t do much about these issues except grin and bear it. But with limited resources, creating new features or debugging old ones often cedes priority to maintaining compatibility.

The second compatibility issue exists within the DAW: Which of the many protocols will it support? For example, VST3 is a comprehensive specification that, like MIDI, does not require a manufacturer to implement all elements. As a result, one DAW may be able to take advantage of certain features that other DAWs do not, but this also depends on whether the plugin can support a particular feature. And what about video format compatibility, especially when Windows doesn’t have a 64-bit video or audio codec for QuickTime?

ARA (Audio Random Access) is another protocol some DAWs support and some don’t. Originated by Celemony working in conjunction with PreSonus to support Melodyne pitch correction, it has since been adopted by Cakewalk and has other potential applications. But this brings up another point about compatibility: If a program already offers its own pitch correction internal to the DAW, should compatibility with a different pitch correction plug-in be a priority if it requires an underlying change in the DAW itself?

Or take controllers. Should a DAW support the EUCON protocol for Ethernet connection of control surfaces? How extensively should it support the aging Mackie Control protocol? Is it important to support touch, given its current Windows-centric orientation?

There are three main ways companies determine which compatibilities are important. First is whether compatibility will fill a product’s “hole.” Perhaps one reason why PreSonus and Cakewalk were quick to embrace ARA is because Studio One didn’t have internal pitch correction, and Sonar’s V-Vocal was getting pretty long in the tooth. They needed modern pitch correction to remain competitive, so ARA provided a solution.

Second is whether the compatibility will be perceived as a benefit by the user base, and encourage it to either stick with the program or upgrade to a new version. Avid’s EUCON is a good example, as it’s supported by production-oriented DAWs whose users often need a general-purpose, high-quality control surface. But Ableton Live doesn’t support EUCON, presumably because its paradigm is somewhat different and perhaps more importantly, controllers exist that are Live-specific and fit the program like a glove.

Third is basically about bragging rights—the belief that something will become sufficiently important that not having it will be perceived as the company lagging behind. There was a time when DAWs didn’t support 192 or 384 kHz sampling rates; now most do, although few people record at those rates. Expect to see more inclusion of DSD as well, even though it’s unclear about what to expect in terms of future demand. Users often want features not necessarily for an immediate need, but because they don’t want to be caught unprepared—like if a client asks for a 192 kHz or DSD two-track mix.

What this means to us is choosing a host isn’t just about what features it has, but what other features it can accommodate. Now, if only there was a soothsayer feature that could tell us exactly what we’ll need in 2015....

Author/musician Craig Anderton has presented seminars on technology and the arts in 38 states, 10 countries, and in three languages. Check out his music at youtube.com/thecraiganderton