In the API I found DynamicSoundGroupCreator.GroupsToCreate returns an empty list unless DynamicSoundGroupCreator.CreateItems() is called first. Is this expected behaviour?
I was hoping to change some DynamicSoundGroup fields/properties before instantiating the MasterAudioGroup objects with CreateItems(). I can work around it OK, just wondering if I misunderstood the purpose of DynamicSoundGroupCreator.GroupsToCreate or if its a bug.
Post by DarkTonic Dev on Jan 15, 2021 16:36:00 GMT
That's not a method you should be calling, yes it is populated later at runtime. Some methods have to be public so Inspectors and other scripts can use them. It doesn't mean you should. I can change the comment for that method so it's more clear, or you can call PopulateGroupData first and see if that works. Let me know.
Thanks, good to know. It was in the API doc so I jumped on it:)
I want to get the list of DynamicSoundGroups in the DynamicSoundGroupCreator (hence calling GroupsToCreate) or at least the MasterAudioGroups created after they are instantiated as I need that reference to the MasterAudioGroups to insert the variations at runtime. I'm Ok with calling GroupsToCreate after they are created but if I shouldn't use it I could use GetChild(i).GetComponent<DynamicSoundGroup>() on the DynamicSoundGroupCreator parent object.
As you said previously I'm pushing the API beyond what was intended but by gameplay is based around user selected audio clips hence my runtime API needs. I'm keen on using MasterAudio as I really like how the package simplifies controlling the audio mixergroups/soundgroups/variations/playlists/buses/etc once the audio assets are created.
On a side note, I want to set the variation sequence at runtime too...is this OK? - _masterAudioGroup.curVariationSequence = MasterAudioGroup.VariationSequence.Randomized // or TopToBottom And using _soundGroupVariation.clipAlias as I use that to trigger specific variations on events. Both of these are public fields so ideally I should not be touching them. Do you recommend I avoid this? To better protect myself with future upgrades where such fields could change I plan on writing MasterAudioGroup and SoundGroupVariation extension methods so I at least have a single point of change.