Controlling Audio From Multiple Scripts

Mon, 04 Nov 2024 00:00:00 +0000

Overview

A hands-on guide to managing one FMOD event from different places in your Unity game. By the end, you’ll be able to start music in one script and safely stop or change it from another, without duplicate sounds or messy references.

Learning goals

Understand when to use instance (non-static) vs class-wide (static) variables
Create and manage a single FMOD EventInstance for music
Trigger fades and parameter changes from other scripts
Avoid common pitfalls like invalid handles and race conditions

What you’ll build

A MusicScript that starts a looping music event
A trigger script that fades the music when the player enters a zone
An optional UI control to change a music parameter (e.g., intensity or low-pass)

Static Vs Non-Static Variables Refresher

Here’s a simple example to clarify the difference between non-static and static data types in C# — especially in a Unity scripting context.

Example: Player Score

using UnityEngine;

public class Player : MonoBehaviour
{
 public int playerScore = 0; // Non-static (instance-based)
 public static int totalScore = 0; // Static (shared across all players)

 void Start()
 {
 playerScore = Random.Range(1, 10);
 totalScore += playerScore;
 }
}

How this works

Non-static (playerScore) Each Player object keeps track of its own score. If you have 3 Player GameObjects, each will have a different playerScore value.
Static (totalScore) This value is shared by all Player objects. Every time a new Player adds its score, totalScore updates globally. You can access it from anywhere with Player.totalScore—no need to reference a specific Player instance.

Why it matters

Use non-static when each instance should have its own data. Example: individual enemies with their own health or position.
Use static when there should be only one value shared across all instances. Example: total score, global music controller, or global game state flag.

Approach 1: Instance-based control (non-static)

Use this when the music belongs to a specific GameObject in the scene and you want to wire references explicitly in the Inspector.

MusicPlayer.cs

using UnityEngine;
using FMODUnity;

public class MusicPlayer : MonoBehaviour
{
 [SerializeField] private EventReference musicEvent;
 public FMOD.Studio.EventInstance MusicInst;

 void Start()
 {
 MusicInst = RuntimeManager.CreateInstance(musicEvent);
 MusicInst.start();
 }

 void OnDestroy()
 {
 MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 MusicInst.release();
 }
}

F_Teleporter.cs (fade music on trigger)

There are two ways to reference our MusicPlayer here. One is to use Unity’s find methods to search for it in the scene; the other is to create a serialized field and drag the reference in the Inspector. The latter is preferred for performance and clarity.

Method 1: Using a find method (not recommended for performance reasons)

// Example only — prefer the serialized field approach below
// var musicPlayer = GameObject.Find("Music Object").GetComponent<MusicPlayer>();
// or
// var musicPlayer = FindObjectOfType<MusicPlayer>();

Method 2: Using a serialized field (preferred)

using UnityEngine;

public class F_Teleporter : MonoBehaviour
{
 [SerializeField] private MusicPlayer musicPlayer; // drag your MusicPlayer object here

 void OnTriggerEnter(Collider other)
 {
 if (!other.CompareTag("Player")) return;

 // Check if the music instance is valid before stopping
 if (musicPlayer != null && musicPlayer.MusicInst.isValid())
 {
 musicPlayer.MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 }
 }
}

Why choose this: it’s explicit and great for scenes with multiple independent music or ambience controllers. You control exactly which instance you’re touching by wiring it in the Inspector.

To finish, select the GameObject with the F_Teleporter component and drag the GameObject with the MusicPlayer script into the Music Player field in the Inspector.

Approach 2: Class-wide control (static)

Use this when there’s exactly one music instance for the whole scene or game and you want to access it from anywhere without passing references.

MusicScript.cs

using UnityEngine;
using FMODUnity;

public class MusicScript : MonoBehaviour
{
 [SerializeField] private EventReference musicEvent;
 public static FMOD.Studio.EventInstance MusicInst;

 void Start()
 {
 if (!MusicInst.isValid())
 {
 MusicInst = RuntimeManager.CreateInstance(musicEvent);
 MusicInst.start();
 }
 }

 void OnDestroy()
 {
 if (MusicInst.isValid())
 {
 MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 MusicInst.release();
 }
 }

 public static void SetMusicParam(string name, float value)
 {
 if (MusicInst.isValid())
 MusicInst.setParameterByName(name, value);
 }
}

F_Teleporter.cs (fade music on trigger)

using UnityEngine;

public class F_Teleporter : MonoBehaviour
{
 void OnTriggerEnter(Collider other)
 {
 if (!other.CompareTag("Player")) return;

 if (MusicScript.MusicInst.isValid())
 {
 MusicScript.MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 }
 }
}

Why choose this: it’s quick and convenient when you truly have a single, global music state. Anywhere in code can reach it via the class name.

When to use which

Use instance-based if:

You have multiple music or ambience controllers
You want explicit Inspector wiring and easy prefab testing

Use static if:

There is only one music instance
Many systems need to access it without passing references
You’re building a lightweight global music controller

Troubleshooting checklist

Does your Player have the Player tag and a collider/rigidbody appropriate for trigger events?
Is the FMOD event assigned in the Inspector and valid in FMOD Studio?
Are you calling stop on a valid instance? Check MusicInst.isValid() before using it.
Are you starting the event before trying to stop it? Initialize in Start and verify logs.
For static mode, do you accidentally create multiple MusicScripts? Guard with isValid().

Clean-up and lifecycle tips

stop ends playback; release frees the handle. After stopping with ALLOWFADEOUT, release the instance when you’re truly done with it.
If music should persist across scenes, mark the music GameObject with DontDestroyOnLoad and manage transitions centrally.
Avoid GameObject.Find. Prefer serialized fields (instance approach) or the class name (static approach) for clarity and performance.

Quick reference

Instance-based access: keep MusicInst non-static and pass references via the Inspector.
Static access: make MusicInst static and reach it from anywhere with MusicScript.MusicInst.
Always check isValid before using an EventInstance.
Stop with ALLOWFADEOUT, then release when finished.

Audio Scripting on DAD 424 Sound Design for Games

Controlling Audio From Multiple Scripts

Overview

Learning goals

What you’ll build

Static Vs Non-Static Variables Refresher

Example: Player Score

How this works

Why it matters

Approach 1: Instance-based control (non-static)

MusicPlayer.cs

F_Teleporter.cs (fade music on trigger)

Approach 2: Class-wide control (static)

MusicScript.cs

F_Teleporter.cs (fade music on trigger)

When to use which

Troubleshooting checklist

Clean-up and lifecycle tips

Quick reference