Programmer instrument scalability

Using the Scripting Examples given for the Programmer Sounds as an example: putting the audio files (.wav) into the StreamingAssets folder and calling them by their path in StreamingAssets is not scalable.

https://www.fmod.com/docs/2.02/unity/examples-programmer-sounds.html

For example if the filename changes or if we’re using sub folders it will break the reference.

Is there a better solution, than just using strings that store their path?
Is AssetReference a possible solution for scalability?

Have you considered using AudioTables in FMOD Studio?
https://www.fmod.com/docs/2.03/studio/dialogue-and-localization.html#audio-tables

1 Like

Thanks Andrew - yes we were planning to use these in any case. But as far as i understand, they’re simply a way of locating all the relevant audio files in one place, correct?

My concern is if naming conventions change for the audio files Unity and won’t be able to refresh and auto-locate these in the same way it does with events.

Just thinking ahead in terms of possible issues we might encounter as the project grows

Under the hood, Events have unique IDs (GUIDs) and names, by having these two pieces of data we are able to handle renames automatically. To have the same functionality with loose .wav files, you’d need to give each file a unique name and not change it. If you’re using audio tables you can use keys to separate the name the game uses (the key) from the file path on disk. This gives you a central place to handle the mapping between game and disk. While not foolproof it does give you some reduction in game breakage as long as the keys file is maintained.