Quantization delay applying on loop restart

FMOD Studio
1

Using version 2.02.13.

I have two projects I’m working on at the moment - one of them is having this issue, but the other project isn’t. I’ve compared the parameters and settings for each project, and they appear to my eyes to all match, so I’m not sure what I’ve done wrong with the project that’s not working.

In each project, I have several stem layers in my music tracks, and each stem is triggered by the player’s level progress or other in-game events. On the project that isn’t working correctly, what’s happening is that when the loop restarts, any of the currently active stems have the quantization delay applied, as if the trigger was just set, even though the trigger was already activated at the end of the loop.

For example, one of the stems has a 1 bar quantization delay set - if that stem is playing when the end of the loop is reached, at the start of the loop it turns off for 1 bar, and then picks up again. It’s doing this to all of the stems in this project (aside from the base stem, which I have the quantization delay turned), regardless of the quantization interval (so bars, beats, etc.)

On the other project, it works as you would expect - when the parameter is first triggered, it waits until the quantization delay setting has reached, the stem starts, and it continues through the loop. I had done the setup of this project a while ago, so I’m assuming there’s something fundamental I’ve forgotten to do in the intervening time, but after comparing all the settings between the two, I can’t figure out what it is I’ve skipped.

Here are screenshots of the project that isn’t working:

Maize1
Maize11920×1170 147 KB

Maize2
Maize21920×1171 105 KB

And here’s the project that is working:

Strings1
Strings11920×1180 180 KB

Strings2
Strings21920×1120 119 KB

Any ideas would be greatly appreciated!

2

Update: I figured out part of the problem. As you can see in the first screenshot from my first post, for the project that isn’t working, I have the first iteration of the base stem play un-looped, and then the looped version starts at bar 21. (The only difference between the 1st iteration and the looped version is that the looped version has the tail cut-off mixed into the first measure to make the loop more seamless). I didn’t do that with the other project, because in that mix the tail wasn’t as apparent at the start of the loop, so I didn’t need to have two iterations.

Apparently, since there is music playing before the start of the loop, when the loop restarts for some reason it’s reading that as a the parameter being reset, even though it hasn’t changed.

Temporary fix for now, I’m just taking out the first iteration - as it’s not TOO apparent in this mix either, but I’m sure there’s gotta be a way around this, so if anyone knows how to get around that, please let me know!

3

The key difference between your two projects is the tempo markers. In your working project, you have placed a tempo marker at the start of each loop region. Tempo markers reset the bar/beat count for the purposes of quantization, ensuring that the start of the bar falls exactly at the start of the loop region.

This is important because synchronous instruments are untriggered and retriggered by loop regions, even if those instruments’ trigger regions overlap both the source and destination of the loop region. You have set your quantization interval to one bar, meaning that if the left edge of a loop region does not align exactly with the start of the bar, the instrument will not trigger and begin playing immediately upon the loop region is triggered, but will instead wait until the playback position reaches the start of the next bar. I can’t be sure without being able to examine your project, but I suspect that your loop regions’ start points are not aligned perfectly with the start of the bar, thus explaining the behavior you’re seeing.

4

Thank you! I zoomed in and adjusted loop edges, and also added a tempo marker to the start of the loop region, and that did the trick.

Related question: Is there a way to make the AHDSR fade in only when the track is started by a parameter trigger, and not at the start of every loop?

EG: Using the first example (the one that wasn’t working), I’ve placed a .25 second AHDSR fade in at the start of the stems that are attached to parameters, to make their entrance more smooth, but when the loop restarts FMOD is applying that fade in, even though that stem has already been triggered. It’s relatively minor, but it does make the loop stand out if you’re listening for it, so hoping there’s a trick around that.

5

Yes, but only if you set the insturment to be synchronous. If a transition (including a loop) moves the playback position on a synchronous instrument, that instrument is untriggered and retriggered, and so starts playing the attack of its AHDSR modulator.

There are a number of ways to work around this behavior without making the instrument asynchronous, however. Here’s a couple of examples:

  • Putting the AHDSR modulator on the track’s volume instead of that of the instrument will work in cases where you want the attack of the AHDSR to play when the event starts rather than every time the instrument is triggered.
  • Automating the “initial” property of the AHDSR modulator such that it’s -oo dB at timeline values where you want a fade-in, but 0 dB at positions where you do not, will ensure that the attack only results in a ramping of volume at certain timeline positions.