First the tempo and named marker are displayed at beat 3 after the transition timeline, which I can understand because otherwise they’d be inside the transition timeline, but it’s still a bit misleading.
A bit more importantly, the second transition marker after the transition timeline is displayed at beat 11 instead of 9 (and also the wavelengths preview doesn’t go “inside” the transition timeline, the visuals show the first beat at beat 3 - sorry I’m not sure I’m being super clear).
I also encountered an inconvenient issue (although not game breaking) in my Unity project, which may or may not be related to this: when playing an event with a transition like this (and a transition timeline, although I haven’t tested without), for 2-3 frames each loop when reaching the end of the transition timeline, getTimelinePosition somehow returns a wrong number which corresponds to beat 4. After a few frames, it just starts giving the correct timeline position again. It seems to be very consistent in my project, but I haven’t tried to repro this on a simple setup.
Edit: Realized I should provide a numerical example.
On an event with a total duration of 54857 (24 * 4 beats at tempo 105) before the transition timeline starts, and a transition timeline with a duration of 4571 (2 * 4 beats at tempo 105), first loop plays correctly, then during the start of the second loop, I get those values for theorical time / getTimelinePosition (small gaps but that’s because I’m using Unity’s time):
1396 / 1388
3294 / 3265 (those two are just periodic checks as long as the time diff is smaller than 30ms) 4538 / 9096 4557 / 9117 4576 / 9138
5205 / 5185 (back to periodic check since after previous line the gap got smaller than 30ms)
I’m currently using FMOD 2.01.09 (Studio & Unity Integration).
Let me know if it has to be related to Unity integration only, then I’ll post that second issue in Unity’s section instead.
I think, like your previous point, it’s that way for the markers (tempo, transitions, etc…) to be in line with the waveform, which is still visually starting at bar 3, though in reality will be heard at bar 1 of the transition timeline). The transition timeline offsets everything.
I’ve noticed something similar and very simple to test: make an event with a transition timeline and nest it in another event. Play the parent event and observe the little inner cursor inside the nested event, when the transition comes in: there’s a wierd jump.
But I admit that’s really confusing. In fact, the only thing that moves when draging the destination inside the transition timeline is the timeline right OUTSIDE the transition timeline, though the content doesn’t move, which doesn’t make really sense. It took me some time to really catch the behavior or all this.
Suggestion:
It would be less confusing if, for a transition to bar n (n = 1 in the upper exemple), the part right outside the transition timeline would start at bar n (instead of n + [transition timeline destination lenght]), and inside the transition timeline, the destination would be always set to n on the inner timeline (bars before being negative if necessary). We would then have the n displayed inside the timeline at the beginning of the destination and outside the timeline at the transition destination, which would make it easy to understand those 2 points will be at the same time.
The destination marker appearing at the end of the transition timeline is intentional.
The tempo marker and transition markers appearing in incorrect positions is not intentional. I have added this issue to our bug tracker.
You’re right that it doesn’t make sense. As I mentioned, it’s actually a bug. When the timeline to the right of a transition timeline moves because the destination region is dragged, content on the timeline is supposed to move as well.
Edit: Regarding the few frames where getTimelinePosition returns a nonsensical result, do you have any idea if it’s Unity specific and I should post about that on the correct subsection?
This isn’t Unity-specific. Rather, it’s a natural byproduct of the way transition timelines work under-the-hood. Each transition timeline actually requires three timelines to exist simultaneously, each with a different timeline position; which of these timelines is referenced by getTimelinePosition depends on which part of the transition timeline is being executed.
In any case, the value reported by getTimelinePosition at the end of a transition timeline has no impact on in-game behavior, and so can be safely ignored.
