Audiokinetic Wwise Knowledge Base

States Are Global

States are global to a project. The states used in the interactive music hierarchy go through the same mechanism as those of the actor-mixer hierarchy.

A music object that is registered to a state may delay a state change (at the next beat, bar, cue, and so on) if it is playing and it is the active segment when the change occurs (refer to Understanding the Interactive Music Engine for an explanation on active segments and segment chains). In such a case, it is not the application of the state's properties on the object that is delayed, but the state change request itself. The music engine catches state change requests when needed, and releases them later.

Here's how it works:

1. The game calls SetState().
2. Before doing anything, the internal State Manager of the sound engine notifies the music engine that a state change request was received.
3. The music engine checks within its playing segments to determine whether the state change request should be delayed or not (refer to Understanding the Interactive Music Engine for more details on how this is done).
• A) If it should be applied immediately, the music engine yields control to the State Manager, which eventually updates the properties of all registered objects of the actor-mixer, interactive music and master-mixer hierarchies.
• B) If a playing music object requires that it should wait for some time, the music engine stores the state change request in a queue and informs the State Manager that it was dealt with. Later, it calls SetState() internally, but this time the music engine's intervention is skipped.

Sample Accuracy

The low-level layer of the sound engine does not support sample-accurate property changes. Therefore, state properties ramping may start at more or less 20 milliseconds around the desired location.

States and Switch Containers

Switch containers may be registered to states instead of switches. When their state changes, they schedule a music transition according to their transition matrix.

If, for some reason, the state change request is delayed, then the _scheduling_ of the music transition is delayed. Therefore it is generally not a good thing to register a switch container to a state to which one of its children is also registered, with a timing policy (Next XXXX).

Imagine a segment S that is registered to a state with "Next Bar" policy, and its parent, a switch container, is also registered to this state. The switch container uses "Next Bar" transition rules. You might expect that when the state changes, both the segment properties change and the transition will occur at the next bar. Well this is not what happens at all. In fact, when the state change request is posted, the music engine catches it because the segment S is playing, and releases it one bar later. Then the switch container schedules a transition, which will occur at the next bar.

It is always more efficient to use switches with switch containers, because switch change requests do not have to go through the analysis of every music object that plays in order to determine whether it should be delayed or not.