Quantized async instruments strange behavior

I wasn’t aware until now that quantized async instruments had a so strange behavior. If the event timeline playhead passes through the instrument (and its trigger conditions are met), if the quantization doesn’t allow an immediate play, it “programs” itself to play at the next quantized location, even if the instrument is untriggered!!
I hardly understand the benefit of this behavior, but I fully understand the drawbacks! I recently had to redesign a music event, because of this.

To summarize, it means that both cases bellow, starting the playback from the actuel playhead location, will play exactly the same, triggering the instrument at Marker A…

Futhermore, I realize that the answer we both gave, @joseph and I, in this post, was false!

Is there a reason for that behavior? Is it a bug?

Alcibiade, thank you for your feedback on my initial thread.

You’re right, when the async event is planned, there is nothing to prevent it from happening in my different test cases (like the one you’ve shown).

In my case here’s what I tested :

The yellow container is triggered at intensity 2 and the purple one at intensity 3.

"The not so bad case" : if the game changes state from intensity 1 to intensity 2 at the red spot (1), and changes back to intensity 1 at the blue spot (2), the yellow container will play anyway. In this situation, this is not really critical, you will eventually have 4 measures of intensity 2 playing then going back immediately to intensity 1.

The bad case : if the game changes state from intensity 2 to intensity 3 at the red spot (1), and changes back to intensity 2 at the blue spot (2), the yellow container AND the purple container will play together, which is not good at all ( in my implementation, it’s one or another, not both ).

I’m was changing the structure of the project (before you answered in my initial thread), because having all intensities on the same section has some drawbacks for what I have in mind. Which will solve the bad case scenario.

That said, the not so bad case still stands. I’m pretty sure that the game will not send an intensity change that fast, but if you kinda have OCDs like me, wanting everything to be perfect… you know that in some instances, you could have the music glitching because of this behavior.

So yeah, I’d be curious if this is something we could prevent (or not).

EDIT : I forgot to mention that the containers are conditionals. When the intensity changes, they are enabled or disabled with the trigger behavior setup.

So, eventually, is this a bug, or not?..

1 Like

This behavior is, indeed, a bug. I’ve added it to our bug tracker, so it should be fixed in an upcoming release of FMOD Studio.

I think I’m having the same problem as @Alcibiade above but need confirmation, sorry to open an old thread.

I am using a parameter called FirstBlood with a veolcity set at 0.35/s. You can see its parameter sheet above which i use to transition to a new area of my arrangemetnt. There are 3 states 0,1 and Q. My understanding on how this should work is the paramemter remains on 0 until the parameter is called (when any ship takes damage) and will then set to 1, and again automatically move to Q after X seconds once my score is quantized.

However the parameter is moving between states before any such call at the start of each battle. Is this the correct behaviour? Should it not stay on 0?

For completeness: i use the Q state to disable my magnet region (highlighted above) after quantization. If you know of another way to do this, i’m all ears! Thanks

Velocity will apply at the beginning of the event, no matter what you do. Why don’t you just start with the Q value? That way, it will be caped until you change the value.
By the way, I don’t get how your problem is related to the original post.

Yes, this is the correct behavior.

The parameter’s velocity is 0.35. This means that it continually increases at a rate of 0.35 units per second, starting when the event starts. In your event, this means that if the parameter starts at 0, it will gradually progress to 1, and then to Q.

Is there some part of our documentation that gives the impression a parameter with velocity won’t change until its value is set by something? If so, please let us know, so that we can correct it.

By the way, I’m a bit surprised the bug I mentioned at the beginning of that thread still isn’t fixed in 2.02.06. Has this behavior eventually be converted to “feature”?

According to our records, a fix for this bug is currently in development. Once the fix is complete, it will be included in subsequently-released versions of FMOD Studio.

No, it’s still a bug. The current behavior is limiting and counter-intuitive.

1 Like