I am encountering a problem with music transition timelines being undeterministic. Sometimes a transition (with a timeline duration and a cross fade, as seen in example below) will be skipped.
I have checked several times that the event is not already inside another transition when entering a new one.
I have checked that the transition does not have a condition which might cause a logical problem
None of the transitions have probability on
The issue is only reproduceable in build, not inside of the studio event editor itself. It can also be reproduced using a recorded profiler session. The gaps will occur at different transitions using the same profiler session recording.
When recording with profiler while reproducing the issue, there is also a discrepancy between the recorded audio, and the simulated result. Using the profiler session and running it in sumaltion mode several times will lead to the same sort of gaps, at different locations.
The same issue is also present in other tracks making use of transition timelines, occuring since we switched to this version of fmod. We can not roll back due to platform requirements. Please respond.
This is an unusual issue, and I’m afraid I haven’t yet been able to reproduce it while testing here.
That being said, I do notice that you have two other transition markers at the same timeline position as the “To 7” marker, and they’re all higher in priority than the “To 7” marker. When multiple transition markers are at the same timeline position, the highest priority (i.e.: topmost) marker whose trigger conditions are met is the one whose transition timeline the playback position will enter, even if there are other transition markers whose trigger conditions are already met. Is it possible that that’s what’s happening here, and the “To 6 Slow A” or “To 9” transition markers are active when the “To 7” marker is supposed to activate?
FMOD Studio uses an instance of the FMOD Engine for auditioning, so it uses the exact same API calls and functions that your game has access to. Thus, if your game is creating behavior you don’t expect, but that behavior can’t be reproduced while auditioning the same events in FMOD Studio, it’s very likely that your game is issuing commands that differ from what you’re doing while auditioning in FMOD Studio. Have you tried looking at the API calls view of the profiler, and seeing if the API calls being made are what you expect?
Simulate mode only repeats the API calls that were made in-game. Thus, if your project contains variable elements that aren’t controlled by the API (such as random modulators or multi instruments), it’s entirely expected that a profiler session produce different behavior each time you play it. It’s therefore hard to say whether this is significant or relevant to the behavior you’re seeing.
We do try to respond to all queries and support requests.
However, the practical constraints of limited resources and time means that we are not always able to respond to all support requests immediately. For example, in the lead-up to releasing a new version, we often have to depriotize forum support so that our development and QA staff have time to finish developing and testing all the features and changes included in the new version.
If you want more immediate replies to your support requests, you can purchase a support contract, or a Basic or Premium FMOD licence. As described on our licencing page, these agreements include at least a year of e-mail support, which is assigned a higher priority than forum support, and so is not deprioritized when we get busy.
Hey Joseph, thank you so much for looking into this.
Super valid question. I assumed that it must be a logical problem with our transitions structures too. But i made sure the transitions are prioritized correctly and I am seeing the same behaviour at transitions where there is no other transitions present, and that don’t have any conditions or probabilities attached to them.
Also, audibly what you can hear in the example in the folder is the isolated tail end of a music snippet (marked with a yellow line in the fifth image from top), meaning, the timeline didn’t transition to any other marker either, but just continues as if no transition is there at all. Which should never be the case when the lowest placed transition has no conditions or probabilities set.
I also checked whether maybe, any of the transition timelines affected had no fade in of the destination, which would explain why the tail of the source was audible, but the destination is not. Unfortunately that’s not the problem either. That also wouldn’t explain irregular behaviour. I can gladly provide you the fmod events if you would like to take a closer look to check for user error.
I haven’t looked at the API call viewer. I will do so and let you know if I find anything there. What I did do though is checking the parameters of the instance in the profiler and they were as expected. Also; the issue is observable on transitions with no conditions or probabilities.
Next Steps:
I will analyse the api calls of the profiler to make sure I am not seeing any unintended behaviour there.
I will create a event with strictly linear transitions, no probabilities and no parameters and report here whether I was able to reproduce the issue.
That definitely does sound strange. Normally, the fact that the issue only occurs intermittently would suggest it might be a scheduling issue, i.e.: that the conditions of the transition marker are sometimes being met so short an interval before playback position reaches the marker that there’s not enough time to schedule the transition before it’s supposed to happen. (The reason why this can result in inconsistent behavior, when the period between the command being issued and the time when the transition is consistent, is that the changes are only processed when update() is called, which typically happens every 20 ms.) However, if there’s no trigger conditions on the transition marker, there’s no obvious reason why that should happen - unless the playback position is being jumped to just before the transition marker by some means, but that seems unlikely.
I’ll look forward to hearing whether your attempts to reproduce the issue succeed.
I tried yesterday to create a very linear version of the track above with only non conditonal transitions and was not able to reproduce the issue. Even after looking at the api calls in profiler I still have no clue why I see different behaviours in windows build than in unity editor and fmod studio. I have to assume the issue is on our end.
I will keep you posted either way, but this is going to take a while.
Heyo! It’s me, the guy with the weird transition issue again. I was actually able to figure out what the problem is.
The issue occurs(still only in build) when the event with the transition timeline has multiple tracks.
I created a simple linear version of the track I initally posted to reduce complexity and verify that in fact, the logic of the transitions is not faulty.
I can reproduce the same behaviour in other events too. How can I best help you to verify that on your end? I can gladly provide you with builds and the fmod project, but I would rather not upload them visible to the public.
So I created a new project with some basic ui and the relevant tracks and obviously wasn’t able to reproduce the issue with transitions there…
I profiled the game again and realized, that despite the settings being 128 real channels and 512 virtuals ones, the game was running on 32 real channel in build.
The channels where overwritten by the advanced codec settings which are set to 32 real channels for build, but 256 for the unity editor. Which explains why the transitions behaved differently in editor than in build. So I was able to solve my issue by overriding the codec default and setting it to 64 channels.
My music track is set to highest prio, and the combined highest prio event instances don’t add up to 32 real channels during runtime from what I see. So the fact the duplicate instance created by the transition timeline is virtualized is super super odd, but that too might just be user error.
