Answered
0
0

I demonstrated my problem on youtube: https://youtu.be/IcPg4QLsf6I

when i make a transition timeline and I drag in audio from either the left or the right, these drag ins will not overlap…

is this normal? And if yes, why?

  • You must to post comments
Great Answer
2
0

Tl;dr: As of the time of writing (the 26th of October, 2015), no source region of a transition timeline can overlap with any destination region of the same transition timeline. As you’ve guessed, this is a bug, or at best a missing feature. We do plan to fix it, but it’ll take us a while; I’ll include a possible workaround at the end of this answer.

Some history: Back in the days of yore, FMOD Designer had had no timelines. We counted that as a strength, as it encouraged neophyte users to create resource-efficient atemporal events, instead of DAW-style events that were only efficient when “baked out” instead of processed in real time. It was possible to make a parameter function like a time line, but a user would need to look up how – and in the process, educate themselves enough about Designer that they could use it far more proficiently.

The disadvantage of this approach was that Designer’s interface was less-than-intuitive to new users. Unless you engaged in time-consuming experimentation or carefully read the manual, there was no knowing what each property and widget and context menu item did, much less which one did the thing you wanted. To save time and effort, most sound designers mastered the specific features their projects absolutely needed, then ignored everything else.

When we began to work on FMOD Studio in earnest, we decided that this had to change. To make the interface as intuitive as possible, we made it resemble that of a DAW. Of course, a few of our planned features that didn’t have a DAW equivalent, and there were some DAW features that wouldn’t make sense outside of a linear audio environment – but that was fine; Our goal was to make Studio’s interface resemble that of a DAW in all the places where they were the same, and we managed it.

As part of that, we decided that each event should have exactly one timeline. Timelines are fundamental to DAW-style content creation, after all – and under-the-hood, they were a handy way for us to hook up certain needed functionality. By building them into our event system from the ground up, we were able to optimise for them thoroughly, and because we designed them specifically to support all the features we had planned, we could be sure they were mostly future-proof.

I say “mostly” because Studio was designed and released in stages. Right at the beginning, we’d made an overarching plan that included everything we wanted to add, but we’d left the really fine details blank. This was intentional. In any design process, unexpected complications can require plans to change, and we knew we’d receive a lot of useful feedback once we started releasing public versions; Planning in more-than-necessary detail would have been an obvious waste. Unfortunately, while this policy has saved us a lot of time and effort over the years, it does occasionally lead to old features being less compatible with new ones than we expect.

Remember when I said that events always have exactly one timeline? We made that decision back before we fleshed out the details of the logic system. To be fair, the event system supported most of our logic marker types easily; It wasn’t until we got to transition timelines that we discovered a problem we couldn’t work around.

Under the hood, all transition timelines do is move the timeline cursor around. Conceptually, the cursor’s enters a secondary timeline run in parallel to the normal one, but it’s really just the normal timeline acting a bit differently, some special trigger conditions, and a bit of creative cursor movement. The source and destination regions just determine which part of the timeline the cursor is “really” in, and that’s where the problem arises: The cursor can’t be in two places at once. It’s either in the part of the timeline described by the source regions, or in the part described by the destination regions, and there’s no way to make it acknowledge both at once. To do that, we’d need to either support multiple cursors per timeline, or to support multiple timeline instances per event – and either of those would be so large a change that we can’t do it easily.

The fix: There is no fix for this yet, but there is hope. One of the items on our big list of features to develop is “multiple timelines per event.” We haven’t scheduled it yet, so I can’t say when it will be done. Still, it will be discussed at our next quarterly roadmap meeting, it’s something a lot of users have requested, and it would allow us to support a number of other useful features – Potentially including overlapping a transition timeline’s source and destination regions.

The workaround: For now, while you can’t overlap the source and destination regions of a transition timeline, you can put other sound modules inside a transition timeline, and can cross-fade them with the transition timeline’s source and destination regions. You can use this to disguise the transition between source and destination.

Alternatively, you could copy some of the content from the destination of the transition, put it in a sound module on the transition timeline, and then cross-fade that sound module with the source region – thereby faking an overlap between the source and destination regions.

  • You must to post comments
0
0

Wow, thank you for that extensive answer!

The workaround is a good tip, i’ll manage in the meantime! :)

cheers,

Ruben

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.