You have impact variations in a multi instrument.
You want to tightly line up the main impact point.
There is some minor variation within the design of each file (some have a whoosh in, some have small initial click before the main impact, some just bang right at the top.)
In my understanding, to tightly line up the main impact point, the main transient, I need to carefully bake in silence etc to sync different files. The time from head of file to transient point must be the exact same in the file.
However, I wish this could be controlled in the per Sound settings in the Multi-Instrument’s playlist.
Note: This is different from Start Offset as that would bring the transient forward. I want to do the opposite; I want Start Delay.
Is this possible? (If not, feature request! :D)
You could add Event Sounds into the playlist and have one variation in each, shifted on the timeline. But this all seems like a less practical solution than just lining up the timing in the WAV content itself.
As an aside, you could have a bit more variety by breaking the variations into two parts - in-whoosh variations, and impact variations, and randomize them on the timeline to create more combinations.
Thanks. Nesting events to use their timelines for sync seems like the current solution for me.
Baked timing is certainly the way I normally go, but in this case, it would create a production challenge.
I’m making these composite files rather than layering to limit voice count - and reuse some impact sounds.
All said, it would be nice to have Start Delay next to Start Offset.
Thanks again!
Multi instruments are not the tool for what you want to do. The random and shuffle playlist selection modes are designed tfor multi instruments where each of the playlist entries is an equally-viable alternative to each of the others.
If you want to assign different behavior to two different playlist entries, you could potentially use nested events, as Skaven252 suggests; or you could use one of FMOD Studio’s other methods of selecting between different pieces of content, such as logic markers or instrument trigger conditions.
I have a similar “problem”. I have very short snippets of sounds from collisions, like glass breaking, impact hits with various intensity, some with and some without a strong transient.
Now i want to randomize the pitch and time offset when such a sound file should play. This all happens programmatically in Unreal Engine 5 (with the help of a programmer sound). I spawn between 1-11 instances of the same event, set the programmer sound. and then i want to randomize the start time of the sound.
Is this somehow possible with FMOD? I would like to offset the time independent of the framerate of Unreal engine but in ms intervals, between say 1-50ms, in number of samples would also be ok.
Idk wether writing a plugin works that has the functionality of a programmersound + this time offset functionality (eg. filling the dsp buffer only with 0 until a samplecountthreshold is crossed and then the samples of the sound are put into the buffer until the one shot sound is over.
Unfortunately, as of the time of writing (September of 2024), there is no way to set the delay of an instrument programatically. As you’ve discovered, there is no way to automate delay so that you can control it by setting a parameter.
Can i request this as a feature, to automate it in FMOD Studio and set it via parameter? Or access it via code, the whole delay and quantization section.
Sure thing! I’ll add this suggestion to our feature and improvement tracker now.
We will not implement this suggestion, for the same reason that we do not implement the ability to directly edit most instrument properties at run time: Parameters are the tool for defining how your game’s code any interact with an event instance at run time, and allow you to define exactly how your game’s code is permitted influence an event. Allowing a game’s code to bypass them and set an event instance’s properties directly would remove the benefit of using parameters to define how your game’s code may influence an event; would mean there were multiple conflicting methods by which an event instance could be controlled, necessitating conflict resolution code and making controlling event instances more complicated and harder to learn and understand; and would not add any additional functionality.
