To What Extent Should the Sound Implementation be Done Programmatically?

In ADX, there are features that can be implemented only in code, both in code and in the tool, or only in the tool. Classifying the Frequently Used Features

craftv2_tips_program_doing00.png

Things That can be Done Only in Code

Initialization, termination, loading and unloading files (ACF, ACB, and AWB), creating Players, setting Cues, starting, stopping, pausing, creating game objects, setting selectors, specifying blocks, seeking playback, attaching faders, seamless concatenation playback, updating the position of 3D sound, named file playback, setting Bus, setting snapshots

The program mainly manages the data in memory and change the sounds parameters dynamically if needed.

Things That can be Done in Code And in the Tool

Almost everything can be done in code. However, some tasks can be implemented more easily by using the authoring tool and overwriting the settings of the code.

Before the process to be modified by the program, it can be indirectly operated by the Player parameter or category.

Since the code cannot add new data, it simply overwrites the initial value. You can change the parameters with AISAC or directly modify the pitch, volume, or pan.

Things That can be Done Only in the Tool

Adding, removing, moving, and editing the data, configuring REACT and AISAC curves, and setting the Cues (e.g. a complex Cue, a multi-track or highly hierarchical Cue etc...).

The things that can only be done in the tool are either not accessible from the code, or would require a complex manipulation of the data.

For example, you can implement the random playback by authoring the data and simply playing back the Cue by the program. This allows for simple handling of the data, with minimum code.