I have a project with two different musical sections both of the same tempo, and each section is its own referenced 8-bar event and is comprised of instrumental layers. All layers contain Multi Sound objects, some which are 4-bars long and some 8-bars long. The layers with 4-bar sound objects repeat the sound object at the 5th measure so that all layers occupy the 8-bar section completely.
Each section has a loop region that spans all 8 measures within the referenced event and plays fine as an event. However, each referenced section has an 8-bar loop region over it and when the events are referenced from the master event, they don’t loop smoothly, stuttering before starting the loop again. And for some reason the second section sometimes skips on the percussion track between 1st and 2nd half of the 8 measures (percussion track is two 4-bar multi sound objects). Playing the original referenced event by itself (not within the master event) plays the two sections smoothly (as well as the loop).
When looking for differences between the two referenced events I noticed that the smooth sounding referenced transition has little black-diamond attachments between the two multi sound objects on the same track (see "joined" below) while the objects of the unsmooth sounding transition have no such diamond (see "un-joined" below). What do these marks mean and how do I control them?
- jason kanter asked 4 years ago
Apparently it’s none of the above. I noticed it wasn’t doing this earlier when I was using one single multi sound event per region, that for some reason wouldn’t loop properly within the loop region unless I also had the individual Multi Sound loop button engaged. I tried this for every single Multi Sound object and sure enough, the next time it transitioned to another section it would stop playing.
Is this the way the loop button is supposed to work? I really don’t understand the relationship between the loop region and the loop button. My overlap problems aside, it seemed that when I have two 2-bar sections side by side, the 8 bar region will loop just fine. But if I have an 8-bar section across the 8-bar region, it won’t loop unless the loop button is engaged (i.e., when the cursor loops around the track won’t play anything).
Ah, you’re having trouble with our different looping behaviors. That’s our fault; Our documentation on this topic isn’t yet complete. We’re working on it, but in the meantime here’s a quick rundown of the most important concepts.
Trigger regions have two possible states: "Triggered" and "Untriggered." A trigger region becomes triggered when the game parameter or timeline cursor enters it, and remains triggered until the cursor leaves it. Non-timelocked sound modules effectively function as on/off switches. It doesn’t matter where or how the cursor enters the trigger region of a non-timelocked sound module; It will always start its associated sound from the beginning. Similarly, it doesn’t matter how or when the cursor leaves the module, the same untriggering behavior will occur. (I don’t see any timelocked sound modules in your screenshots, but you can identify them by the waveform displayed on their trigger regions. They always play the part of the waveform that the timeline cursor is over; That’s why we call them "timelocked.")
The "Looping" toggle buttons on sound modules alter the trigger and untrigger behavior of the sounds produced by a sound module. A module set to loop will start playing its associated sound when triggered and will continue to play over and over again indefinitely, and when untriggered will fall silent immediately; A module that does not loop will play once and then fall silent, and when untriggered will wait until the currently playing sound reaches its end before falling silent. (I must admit I’m generalizing a bit; There’s all sorts of things that change this basic behavior, but they’re all exceptions to the general rule.)
Loop regions change the position of the timeline parameter’s cursor in exactly the same way that a destination marker/transition marker pair does. An interesting point is that a loop region or transition doesn’t actually cause the cursor to leave a trigger region (unless one end of the transition or loop region is outside of the trigger region, of course) so jumping around inside a non-timelocked trigger region won’t alter its playback behavior in any way.
Without knowing more about your project, I can’t be sure about the cause of and solution to the problems you’re having, but hopefully that explanation helps.
The black diamond attachments indicate the presence of a crossfade between the two modules; Presumably, a crossfade so short that it can’t be seen at the zoom level at which those screenshots were taken.
Without seeing your project in more detail I can’t be certain, but the presence of crossfades suggests that the trigger regions in this event are nor aligned exactly to the beat and bar, which may account for the strange behavior you’ve been hearing. If so, you may be able to resolve your issue by creating a tempo marker (if the event hasn’t got one already) and clicking and dragging both ends of every trigger region so that they snap to the appropriate points. If you would prefer not to use a tempo marker for some reason, you should also be able to resolve the issue by moving and resizing the modules via the "Move To…" context-sensitive menu item.
Ok, that makes sense and even though I am using tempo markers, indeed when I zoomed in everything was skewed slightly and there were micro transitions where there shouldn’t have been.
There are still some basic and unexplainable issues that I can’t get to the bottom of.
1) When it plays through the referenced event the first time there’s always that stutter between the first and second halves (when it transitions between bar 4 and 5). Then it seems to loop successfully and plays the transition smoothly every time thereafter. It’s as if FMOD is learning the song.
2) When transitioning from one section to another using the "Transition Region To" function it doesn’t behave as expected. Going from Section 1 to Section 2 the cursor disappears for several measures as Section 1 continues to play. Then the cursor suddenly resurfaces at the beginning of Section 2 and plays but the music from 1st Section can still be heard for a couple of measures and is completely out of sync. Going in the opposite direction, Section 2’s music can be heard under Section 1’s but the cursor doesn’t disappear for several measures and the music is in sync.
Does this make any sense to anyone?
[quote="jason kanter":19v69r81]2) When transitioning from one section to another using the "Transition Region To" function it doesn’t behave as expected. Going from Section 1 to Section 2 the cursor disappears for several measures as Section 1 continues to play. Then the cursor suddenly resurfaces at the beginning of Section 2 and plays but the music from 1st Section can still be heard for a couple of measures and is completely out of sync. Going in the opposite direction, Section 2’s music can be heard under Section 1’s but the cursor doesn’t disappear for several measures and the music is in sync.[/quote:19v69r81]
I’m guessing you accidentally added a transition post/pre-roll which they haven’t fully implemented yet. ([url:19v69r81]http://www.fmod.org/forum/viewtopic.php?f=21&t=16034[/url:19v69r81])
[quote="johnnyrk":mo9nzklz]I’m guessing you accidentally added a transition post/pre-roll which they haven’t fully implemented yet.[/quote:mo9nzklz]
Ah, I guess I did. Thanks. How do you undo that (besides deleting the transition region which is what I landed up doing).
Do we have any explanation of why the sequence "skips" the first time through?
It seems that getting rid of the transition post/pre-roll helped to get rid of the disappearing cursor but my severe overlap is still intact. Not sure what to do about this as it’s really problematic. Is there some sort of "play till end" command implemented that I’m not seeing? Whenever transitioning from one section to another it overlaps for roughly one measure. What to do?
Please login first to submit.