Feature request : Command instrument Tick

[_MaX]

Hi FMOD Team, Hi everyone,

I’ve been improving our dynamic music system recently. And due to our constraints, I had to implement a system inside of our music events to be able to sustain it for a while before stopping it.

You could argue that this is something that has to be done on the code end, but since FMOD gives the tools, I don’t think it’s a bad approach.

Here’s the overall idea : the music system is a mix of horizontal and vertical sequencing.

There are three intensities divided in 4 values : 0 = stopped. 1 > 3, playing at three different intensities.

When the music director (our code) drops below 1 (music expected to be stopped), the music is entering a sustain loop which lowers the soundtrack volume, to give the gameplay a bit of room before stopping it. This allows the music director to go above 1 during that period which will make the sustain section transition, which restores the volume back to normal and re-enter the 1/2/3 intensities loops (and resets the sustain parameter).

The way I did that to have a consistent sustain before stopping. No matter where the playhead enters the sustain loop, is by making a command track updating a parameter called “SustainMusicEnd”.
This track, as shown in the screenshot above, has a command instrument every 8 measures adding a delta value of 0.3 everytime.

As you can see, the command track gets a bit crowded

So my question is, would it be possible to consider this in the command type :

Add :

• “Tick parameter”, which will feature 4 parameters:
  • Target
  • Delta value
  • Quantization (time or tempo)
  • Quantization value ( delay interval or or quantization interval )

Which would allow us to put a single command instrument in a track, and as long as the playhead is on it, the command instrument will tick based on the parameters we defined.

That would ease the implementation process and probably allow all sorts of fun tricks… I suppose? Or maybe I am the only one with a weird brain doing that sort of things?

[joseph]

So, if I understand correctly, you want a command instrument that functions like an increment parameter command instrument, but re-triggers itself at regular intervals as long as it remains triggered?

Have you considered other means of achieving this behavior? Using seventeen near-identical command instruments is obviously sub-optimal, but what about (for example) using a single command instrument, giving it a parameter condition, and attaching an LFO modulator to the relevat parameter’s value such that the parameter’s value meets the command instrument’s trigger condition at regular intervals? You’d get the same behavior using only a single command instrument, instead of needing the seventeen of them that you have in your screenshot.

Another method that would allow you to use a single command instrument is adding a seek modulator to the parameter’s value, so that it ramps to new values gradually rather than jumping instantly.

Another option would be to use automation to control the volume, potentially inside a transition timeline. Automation is the classic way to gradually ramp property values, and can be combined with modulators as well if needed.

Do any of these alternative ways of achieving the same behavior work for your case?

[_MaX]

@joseph

So, if I understand correctly, you want a command instrument that functions like an increment parameter command instrument, but re-triggers itself at regular intervals as long as it remains triggered?

Exactly ! That said, as you’ll see in the rest of the answer, the feature suggestion was based probably on a lack of “smartness” on my end haha.

@joseph

Have you considered other means of achieving this behavior?

Well! I thought about that prior to this implementation and did not had any eureka moment to compensate my hacky approach.

@joseph

Another method that would allow you to use a single command instrument is adding a seek modulator to the parameter’s value, so that it ramps to new values gradually rather than jumping instantly.

Brilliant approach! Tested it and it’s indeed doing the same thing with a better visual clarity. Thank you for that suggestion.

@joseph

Another option would be to use automation to control the volume

Yeap, but Automation (unless I don’t know a way to use it that way) cannot be relative. Since my track behaves based on relative horizontal transitions, I don’t think there’s any way to do automations based on that relative positioning of the play head. Is it?

For the record, I’d be interested to know, this could be handy.

@joseph

Do any of these alternative ways of achieving the same behavior work for your case?

As you’ve read, it does! Thank you for your precious input joseph.

[joseph]

@_MaX

Yeap, but Automation (unless I don’t know a way to use it that way) cannot be relative. Since my track behaves based on relative horizontal transitions, I don’t think there’s any way to do automations based on that relative positioning of the play head. Is it?

It is possible to place automation within a transition timeline. Since a transition timeline on a transition region can be entered at any point along that region’s length, this means that you can reliably have the automation start at the point the transition begins and end at the point where it ends, regardless of where on the main timeline the those points happen to be.

That being said, this solution is only suitable for very specifc use-cases, where a transition timeline is a good fit for the event’s pacing, and the property values do not vary from moment to moment outside the transition timeline. The seek modulator is probably a much better tool for your use-case.

In any case, I’m glad to hear you were able to find a solution that worked for your game.