Miles Sound System is something of a founding father of the concept of middleware. While RenderWare’s 1997 release arguably established the contemporary middleware concept proper, audio tool Miles Sound System has been available in various forms since 1991.
Over the years it’s been used in many thousands of games, straddling several console generations and helping shape the way many of today’s most prolific game audio specialists practice their craft.
Formerly known as Audio Interface Library, and welcomed to the RAD Game Tools stable back in 1995, edition ten has just been released, taking the tool as much into the realm of the sound designer as that of the sound engineer.
As such, the tenth edition is something of a milestone for both Rad and the concept of middleware. So what better technology to place under the watchful eye of Develop’s tools microscope?
We caught up with Dan Thompson, the man at the reigns of this icon of game sound design and engineering.
Firstly could you tell us a little about your role on Miles Sound System today, and your history working on the middleware?
I am the principal developer on the Miles Sound System these days. I was hired to design and develop the high-level toolset that new games and sound designers demand.
Before we get into the finer details, is there a general or broad theme in terms of the direction you’ve taken with Miles Sound System 10? Perhaps there was a specific mantra or ethos to the way you’ve advanced the middleware??
Miles has historically been targeted towards the engineer, and in Miles 10, I wanted to really focus on the sound designer as a valid consumer. To this end I’ve really iterated on the UI, and focused on representing concepts in a manner familiar to people other than programmers.
This is also reflected in somewhat of a shift in philosophy with Miles, as it has historically been very much a middleware where we provide you a set of tools and leave many high-level concepts for you to implement in your own unique way. With a strong, high-level toolset many common concepts are now ready to go ‘out of the box’.?
And how do those changes reflect current trends in game audio? I presume you’ve had to consider future-proofing Miles Sound System 10 with regard to those emerging trends?
The demands on sound designers in games have been increasing and will continue to increase. A strong high-level toolset that puts as much of the power as possible in the designer’s hands will increase efficiency during production, allowing for higher quality soundscapes. In addition, as games become more complex we see more and more entities in the game world vying for parts of the player’s ear, and Miles 10 was designed to provide more tools for controlling what gets heard.?
How did you make sure the changes introduced are what’s needed by today’s game audio professionals? Was it a matter of working with long-standing developer partners, for example?
One of the great things about working with RAD is I do the support as well as the development, so over time I generate a list of features that are desired but not yet implemented. Over the course of developing Miles 9, many features were desired that didn’t ‘slot in’ to the old Miles architecture, so a new version was required.?
Famously, of course, Miles Sound System has been around since 1991; effectively the dawn of middleware. Is any of what defined Miles back then still key to the middleware today??
I would say that RAD’s greatest strength is its support, and no matter what version Miles is on, that will remain a pillar. It’s hard to compare the Miles from pre-Pentium days to the software package it is today. Back then, CPU cycles and memory were both very precious, and sound card compatibility was critical. Nowadays it’s all about streamlining production and ensuring that all production personnel have no problems doing what needs to get done.
Moving into the detail, what are the most significant new features introduced to Miles Sound System 10?
Miles 10 has a huge list of upgrades – too many to list. The most important is a focus on buses, and providing tonnes of controls on routing audio.
In Miles 10, each sample can have multiple outputs or ‘sends’, each of which can have their own sends, with filters allowed everywhere. Each of these buses is also responsible for voice management, providing tonnes of knobs to control how many things are audible at any given moment.
So who is your core market, in terms of the types of studio you supports? Does Miles Sound System 10 offer much to smaller teams, or is it best suited to triple-A teams?
Miles isn’t picky – it can handle any team.
And for a studio embracing Miles Sound System 10 for the first time, how do you think it will impact the working process?
We are expecting it to be a fairly easy transition. Project set-up has been streamlined, and for studios utilising
the high level toolset, the low-level code integration is very straightforward. Getting started is more or less opening Miles Studio and dragging in sound files, and iteration is simple since you can edit while the game is running.
What about old hands who’ve worked with Miles Sound System for years? How have you assured that the migration to the new release 10 will be as painless as possible for them?
It’ll be a bit more work than what they are used to, however the old functions have analogous counterparts in the new API. Since Miles Sound System 10 is such a large upgrade in terms of functionality, we’ve taken the time to clean up the customer-facing functions. I think old hands will love how easy and intuitive the new API is for them.
And what would you say to anybody still unsure about fully embracing Miles Sound System 10?
Miles 10 has a lot of improvements. We encourage anyone who is on the fence about it to get an evaluation from us. Hands-on experience will trump an incomplete list on paper any day. ?