Support>Tutorials>Modeling
About Audio Control Files
Audio control files (extension.proxyxml) are where the actual characteristics of sounds are specified. There are several distinct sections in an audio control file that interact with each other and these are described in the following paragraphs. For a more complete discussion of audio in RailWorks, it is recommended that you read Rail Simulator DevDoc 8.01 or Section 8 of the RailWorks Wiki (once it's completed). Yes, it's lengthy and technical, but after you've been through the audio-creation procedure a few times it will make more sense. The discussion that follows is limited to steam locomotive audio; however, it is hoped that coming at the subject of audio from a different perspective will further clarify it.
Before getting to the specifics, understand that what you see in the Blueprint Editor is sometimes different from what is actually recorded in the XML file. For example, suppose you have a sound file that represents a brake release. In addition to providing a path to the WAV file, you are asked to give it a friendly name. (A "friendly name," in computerese, is simply a name you provide that has an obvious meaning to you) You might choose the name “Brake Release.” Further down in the blueprint, in another section, you are asked to input this friendly name. However, instead of having to remember what you called the sound, you are offered a dropdown list in which your previously named sound appears. You make the selection from this dropdown list rather than looking up the sound's name and typing it in. When you save the audio control file, the Asset Editor replaces all your friendly names with 8-digit ID codes. The ID code appears in the beginning of each sound specification, and is used by reference in subsequent sections. Entries in some of the other sections of the audio control file are set up this way, too.
By the way, never Export an audio control file—Save it only! You should have a corresponding sound blueprint XML file that references the your proxyxml file. Proxyxml source files are converted to proxybin asset files when you export the sound XML file.
Sound Section
You must provide a separate specification for each of your sound files. Each specification consists of a friendly name, the path to the sound's WAV file, the type of sound (looped or not, random or single sample), and data that controls the sound's basic volume and pitch, and the variability of the volume and pitch. A sound specification may have more than one sound file associated with it, in which case you must specify the probability with which each sound file is played.
Friendly Sound names are stored in the blueprint for reference in other sections.
Curve Section
Each curve consists of a friendly name and two or more X/Y pairs. The curves are used to modify a sound according to current conditions in the sim. At this point in the blueprint, X and Y are not defined. But be advised that the X coordinate represents the value or state of the controller and the Y coordinate represents the corresponding value of the controlled variable.
Friendly Curve names are stored in the blueprint for reference in other sections.
ModifierChain Section
This is where the curve variables are defined. You provide a friendly name and follow it with one or more modifiers. Each modifier consists of a controller, a controlled variable, and a curve ID. When more than one modifier is specified, they are evidently combined by simple multiplication. The term “controller” above refers to something that influences how and when a sound is played. Controllers are specified using a ControlName. ControlNames are taken from a list of reserved words that RailWorks has defined to identify specific cab controls and external controls. Examples include Regulator, LiveInjectorWater, and AbsoluteSpeed. A list of ControlNames appears Here.
The term “controlled variable” refers to properties of the sound, specifically volume and pitch.
Friendly ModifierChain names are stored in the blueprint for reference in other sections.
InstanceGroup Section
This section is used to place limits on when a sound can be played. For example if the possibility exists that a second instance of a currently playing sound could be played before the current instance of the sound has finished playing, you can prevent the second instance from playing.
Loop Section
The Loop section and the Oneshot section that follows it are where information from all the previous sections is brought together. Inputs include the sound, its modifier chain, a controller and a set of conditions.
The controller is the same ControlName variable that was previously defined in the ModifierChain section. Why does it appear again here? Let's look at an example from the Black 5, the firebox door. When we open the door we want to hear the sound of burning coal. The sound is named Fireloop, its modifier chain is named FireBoxDoor, and it's controlled by the status of the firebox door, which RailWorks has assigned the ControllerName FireboxDoor. Whenever the virtual fireman opens the door, we hear the sound Fireloop, as modified by FireBoxDoor. The sound is looped continuously until the fireman closes the door. Actually, the sound Fireloop is always being played. The modifier chain FireBoxDoor simply triples the volume of Fireloop when the door (controller: FireboxDoor) is open.
Using the conditional statements for each loop, you can further influence when a sound is or is not played. You can also specify whether a sound is heard inside the cab, outside the engine, or both, using the PlayState variable.
Oneshot Section
This section follows the same format as the Loop section but, like its name, it's reserved for oneshot sounds. The conditional statements, which are not recorded in this document, determine things like playing a oneshot just as you begin to open or close a control lever.
Additional Sections
There are four types of audio control files: Generic, Ambient, Steam, and UI. The preceding sections appear in all four types. Generic control files contain only the sections listed above. A steam whistle file is an example of a generic audio control file. Ambient and UI control files are beyond the scope of this tutorial. Steam control files have one additional section which is now described.
Exhaust Section
This section is used to control the playing of the steam chuff sound files. The steam chuff audio control file is assembled separately from the locomotive audio control file. However, the locomotive audio control file of a steam engine also contains an Exhaust section which controls the noises associated with movement of the locomotive.
The exhaust section consists of several similar blocks of information that are tied to the locomotive's speed using the AbsoluteSpeed controller. Each block is associated with a certain speed range. The numbers specified for the range are in units of meters per second.
The blocks contain four elements, each of which is made up of a sound and a modifier chain. You'll notice that the fourth element in each of the Black 5's Exhaust blocks is a dummy (all variables set to 0). A chuff audio control uses all four elements. One can only speculate as to why this is the case.