BUG 1:
When first trying to set a command instrument (to set a parameter) before a standard instrument in an action sheet, I found out the command instrument was playing in parallel of the next action (despite the “Consecutive” setting). So I had the idea to add a short silence instrument between both, to be sure the command instrument is triggered before the next action. What it does is really weird! Firstly, the silence instrument doesn’t play at all (it behaves as it was before, actions A and C playing simultaneously). After saving/closing/restarting, the silence instrument does play, but incorrectly: it keeps a global value and doesn’t restart when the event is restarted! Set something like 10s to see what I mean.
BUG 2:
It seems impossible to randomize across all values of a discrete parameter. In the case bellow (possible values: 0, 1, 2), it only randomizes across {0, 1}, despite the blue line across {0-2}. I guess it’s the same for continuous parameters, but it’s much less annoying, since there’s an infinite possible values.
Thanks for the bug report! This is definitely behaving incorrectly. I’ll add this issue to our bug tracker.
There is a bug here - and it’s slightly more complex than it might appear to be.
Discrete and labelled parameters aren’t integer variables. Like all parameters in FMOD Studio, they’re actually floating point variables, and as such support fractional values. (You can see this if you create a parameter sheet for the parameter you’ve used in your screenshot, then watch it while you repeatedly restart the event: You’ll see the parameter’s current value indicator jump to a variety of positions, not just the three values the parameter purports to have.) As such, each of the values in a discrete parameter is actually a range of values. In the case of the parameter in your screenshot, the displayed value 0 actually represents a range from 0 to slightly less than 1, the displayed value 1 actually represents a range from 1 to slightly less than 2, and the displayed value 2 actually represents a range from 2 to slightly less than 3.
When a randomization modulator adjusts a property’s value, it generates a random adjustment between -(half the percentage of the property’s full range specified by the random modulator) and +(half the percentage of the property’s full range specified by the random modulator). This means that if a discrete parameter ranges from 0-2, and its randomization modulator is set to 100%, it’ll generate an adjustment between -1 and +1. If the parameter’s base value is 1, this means it’ll be assigned a value anywhere between 0 and 2, and there are an extremely large number of fractional values inside that range.
I’m sure you see the issue: The parameter’s actual range is 0-4, and the highest discrete value is actually the range 2-3. This means that for the random modulator to select a value within the 0 or 1 ranges, it can generate any adjustment between 0 and 2 - but any number between 0 and slightly-less-than-two will fall into the 0-to-slightly-less-than-1 or 1-to-slightly-less-than-2 ranges rather than into the 2-to-slightly-less-than-3 range. It is therefore technically possible for it to be randomly set to exactly 2, but the odds of it happening are as close to 0 as a floating point variable can get.
This is, as I said, a bug. Our random modulator should include special case code to ensure that the kind of randomization you’re attempting works as expected, but it looks like it stopped working a few versions ago. I’ll add this issue to our bug tracker; we’ll fix it in an upcoming release.
