I’m having an issue where my transition doesn’t happen immidiately when the parameter is changed, as you can see in the screen recording here. in happens around 100-200 ms later, which is quite annoying. This is also the case when using the event in Unity.
I’m not aware of any issue that would cause a scheduling delay when triggering a transition region, and I can’t see anything in that video that would suggest a cause. Are all the transition regions create affected in this way, or just some of them? If only some transition regions exhibit this behavior, are you able to send us a copy of an affected project so that we can examine the affected events in detail?
Also, does the issue occur on all machines, or only some?
We’ve identified the cause of this issue, and are currently working on a fix, which will be included in an upcoming release of FMOD Studio. Given that we’ve identified the cause of the bug, it’s no longer necessary for you to send us a copy of your project. Thank you for helping us out.
We’ve also discovered this issue does not affect transition timelines with source regions, so you may be able to work around the issue in some cases by adding a short source region to the transition timeline, then removing the resulting fade-in curves from the instrument(s) inside the transition timeline and maximizing the fade-out curves on the transition timeline’s source region.
If that workaround doesn’t work for you, and you’re not able to wait for a new FMOD Studio version that includes the fix, you should be able to avoid the bug by using FMOD Studio versions 1.10.09 and earlier. The bug was introduced in version 1.10.10, so earlier versions are not affected.
That sounds good. I’m not sure I understand the workaround, and do not know what “lead-in regions” are - I couldn’t find much info. on thay Could you explain it or maybe send a screen shot Thank you
I’m not sure I understand the workaround, and do not know what “lead-in regions” are - I couldn’t find much info.
Whoops! I wrote “lead-in regions” when I meant “source regions.” I’ve corrected my post.
If you look at a transition timeline when it is expanded, you’ll see a dashed grey line at the left edge of the transition timeline. If you click and drag this dashed line to the right, you’ll add a “source region” to the transition timeline. When the playback position enters the transition timeline, it will continue playing content from the main timeline until the playback position leaves the source region. Of course, this behavior may not be desirable in all transition timelines, so this workaround may not work in all situations.
Great to hear it’s a bug and you guys a working on a fix. I discovered the exact same problem and couldn’t make sense out of it, as everything was working fine before. Even when loading older projects I now get a small delay. When working with music and quantization intervals I’ve got the feeling, that the delay is somewhat based on the chosen time signature. But I can also be mistaken.
I will just sit tight and wait for the next release. Any idea about when this version will be available?
I’m also getting a latency when pressing play on certain events. I cannot figure out why. It’s not very long, but still noticeable in a gamplay situation. Here’s a video showing it. Notice that the sound does not play immidiately after the play button is pressed: https://youtu.be/9KtKCHo4zns
I’m also getting a latency when pressing play on certain events… Notice that the sound does not play immidiately after the play button is pressed: https://youtu.be/9KtKCHo4zns
What compression format are your audio files in? If they’re anything other than uncompressed .wav files, FMOD Studio has to decompress them prior to playing an event, and so will delay the start of the event until they’re ready. If it didn’t do this, instruments at and near the start of the event would be silent until a short few moments after the timeline started advancing.
I’ve checked with our API development team, and they’ve informed me that this isn’t a bug.
FMOD Studio schedules instruments to start playing a little ahead of when they actually play. This behavior is necessary for content to be scheduled with to-the-sample accuracy. The playback position’s location, on the other hand, indicates the content that is actually currently playing.
This can be seen in your video: If you look closely, you’ll see that the multi instrument at the destination marker lights up a moment before the playback position arrives. This lighting up indicates that it has been scheduled to start playback. The instrument doesn’t actually start producing output until a few moments later, when the playback position arrives at the destination marker.
There will always be some latency between calling setParameter and the instrument starting to play, as it is physically impossible for a consequence and its cause to be simultaneous. Usually this delay isn’t significant enough to cause problems, as it’s small enough that an end user won’t notice it.
That said, if it’s important to your project to reduce this delay, there are ways to do so, but each way has its own limitations. What behavior are you trying to achieve in-game, and why is having low latency on a parameter value change important for that behavior? If you give us more information about what you want, we’ll be better positioned to suggest solutions.
Here’s an example of when I get a problem with the latency:
I’m working on a soccer game, where my music event starts playing a looping drone when the level starts. I have a parameter called “FirestBallTouch” that is set to 1.0 when a player touches the ball.
This parameter starts a drum loop, but that does not feel very good, when there’s a latency.
Another example is my “KickBall” event. The event starts playing a charge sound. I have a parameter called “KickBallAfterCharge” and one called “LostBallDuringCharge”. The first one play a kick sound and the second one play a silly “swuup sound”. Again these does not feel good with latency.
In both scenarios I’m using a transition region to move the playhead whenever the parameter is set to one. Of course I could play new events from my code instead, but that seems much more messy, as I would then have to stop one event and start another one. And using one event also makes it possible to use transition timelines