The playlist in a multi sound object appears to play in a shuffled order when shuffle is enabled but it seems to always play the SAME shuffled order every time I restart my application.
This is obviously not desired behaviour - why does the shuffle function not have a random seed set each time the bank is loaded?
Is there any way to actually randomize the play list of a multi sound object properly?
EDIT: Just want to note that this behaviour is not evident INSIDE Studio as it plays randomly all the time, it only happens when I’m using the events from within my app.
EDIT 2: Using the following code - still no change in behaviour. Tried setAdvancedSettings both before and after system->initialize, with no change. Not seeing any errors. cbSize is 108, and random seed (as expected) is always different and greater than 2. Any idea what I’m doing wrong?
Randomisation in Multi Sounds is based on the random seed provided by your FMOD initialization settings. By default, the random seed will default to 0, meaning that you will get the same shuffled order deterministically, each time you start up your game.
You can read more about Random Seeds here:
Our Unreal Engine 4 and Unity integrations both set the random seed to the system time, so you should get a quasi-random behaviour in game.
You need to make sure that you are setting these settings before FMOD Studio is initialised. Could you let me know how you are building your game (Unity, UE4, custom?)?
Your code looks correct and should work, which leads me to believe there might be an issue elsewhere in your game code. Unfortunately without seeing the source code we can’t really offer further advice.
Are you able to reproduce this in a separate project (eg. press a button to play the multi sound)?
FMOD_ADVANCEDSETTINGS needs to have all of its values zeroed out before being passed to FMOD_System_SetAdvancedSettings in order to ensure they’re all at their default values. You can do this like so:
This should ensure that the system accepts your provided advanced settings struct. You should be able to verify whether the values are set as expected by using the logging versions of the libs (L suffix) and setting your logging level to FMOD_DEBUG_LEVEL_LOG before system creation, like so:
If you check the return value of the FMOD_System_GetAdvancedSettings call, I expect you’ll find it’s returning an invalid parameter error (value 31). This is because even when retrieving the existing value, the system expects the struct to be zeroed out so that rogue/uninitialized values or pointers aren’t passed out of the FMOD system.
This isn’t explicitly noted in our documentation, so I’ve flagged the relevant API pages for improvements.