Hi, I’m Vinny
I’ve noticed that I couldn’t get my sound def to play multiple sounds at the same time, almost like a multi-track mixer would.
Here is an image of what I have currently setup.
My goal is to have randomization of 6 out of those 6 sounds playing at the SAME TIME, literally all starting at the exact same time.
What I’ve found is that when I set the spawn time to [0,0], it only plays ONE of those 6 sounds every instance, instead of what I’m intending which is all 6 at the same time (this is for maximum impact).
When I change the spawn time to [0,1] like in the image, I get all the sounds playing together, almost as intended, BUT it does not play them at the exact same time, it has a slight delay because its playing all of those within a time of 0 to 1ms.
Any help of how I can achieve the playback of multiple sounds in a sound def at the exact same starting time would be greatly appreciated. This will allow for an in-phase, punchy bullet explosion.
- Vunsunta asked 7 years ago
Thank you for a quick reply
I actually tried what you said after I made that post, with the multi-track event. So thank you for confirming for me that that is how you should do something like that. Also thank you for reminding me of the slight latency, because of that I will instead make several mixes of the gunshot for the beginning, since they are guaranteed in-phase samples. I look forward to FMOD studio in the near future, I’m excited for the mixer as well
Hmm, after rereading my earlier post I realise that I could have given a little more detail on how latency affects multi-track events.
To clarify, an event without parameters that contains multiple sound defs will cause all of its sound defs to start playing at the same time and unaffected by latency. Parameters and spawning behaviour will only be affected by latency if they would result in the sounds of an event starting at different times. This means that an event with no parameters and a single, non-spawning sound def on each layer (such as the one I suggested above) will, when triggered, cause all of its sound defs to start playing at the exact same time.
Making a mix of the gunshot event is therefore not necessary to ensure that its component sounds start simultaniously. It is, however, a good way to reduce demand on system resources at run-time.
Vinny, it’s not actually possible to get the behaviour you want out of just a sound def, since sound defs aren’t designed to act like multi-track mixers. In fact, they were originally designed to only play a single sound file at a time. The ‘spawning’ properties were relatively late additions to the property lists. Setting spawn time to [0, 0] turns spawning off, and results in the sound def behaving in the traditional one-file-at-a-time way.
Don’t worry, the behaviour you’re looking for is still possible by using multi-track events, which [i:xqyq57p7]are[/i:xqyq57p7] designed to act a little like multi-track mixers. All you need to do is split your current sound def into a bunch of different ones, each containing a single sound, then create an event that contains each of your sound defs on its own layer. When the event is triggered, all the Sound Defs will be triggered at once.
Alternatively, if system resources are scarce, you may want to consider replacing the audio files in your sound def with a one single sound file containing a mix of the others. This will, however, prevent you from applying any kind of randomization or other variation to the individual sound files, so you should carefully consider the requirements of your project before making your decision.
In any case, you should be aware that no matter how you set things up, FMOD won’t necessarily playback events with millisecond accuracy in-game. There will typically be a slight delay between an event being triggered and it actually playing – and if the event contains sounds that start at different times due to parameters or parameters or spawning behaviour, the individual sounds may be slightly delayed as well. Whether the amount of delay is noticable depends on how often FMOD::System::update() is called, and how large the buffer size is, larger values resulting in greater delays in either case. This is actually a longstanding issue that is unlikely to be fixed in Designer, though we have solved it for FMOD Studio.
Please login first to submit.