Say I have Parameter A that is currently 20, I’d like to make Parameter B affect A such that it adds its value to it, e.g. setting Parameter B to 5 would then make A = 25
This is how modulating parameters works so I assumed that automating A with B would give the same result, however as soon as I add B as an automation curve to A it makes A read-only, and the values of B now map directly onto A. Probably a lack of imagination on my part but I can’t see a use for this? Is there a solution for what I’m trying to do?
EDIT: I’ve thought of one hacky solution which is to use a command instrument to increment Parameter A, and then automate the increment amount with B. The only thing is I then want A to return to its original value using the velocity of B, which I don’t think I can do with this method?
Automation allows you to draw a graph that defines the value of a property for every possible value of a parameter. This has a wide variety of uses.
The case of automating a parameter on another parameter is mostly useful when you are using a single parameter to automate multiple other parameters or properties using non-linear curves.
Automation is not the appropriate tool for what you are trying to do. Automation does not apply an adjustment to the base value of a property without changing that base value; rather, it sets that parameter’s base value in a way that’s similar to setting it with in your game’s code.
What behavior are you trying to create? FMOD Studio has a variety of tools for designing complex audio behavior, but without knowing what you’re trying to achieve, we cannot advise you which tools would let you achieve it.
Could that be a feature at some point? So using automation as an adjustment value instead of being intrinsically tied to the base value? Or is that too far outside its scope?
So let’s say parameter A is engine power and parameter B is ‘boost’. I want to be able to set B to an arbitrary value, and have that added to parameter A (engine + boost), but with a negative velocity so the amount of ‘boost’ decreases over time down to 0 again. I can code this behaviour in Unity instead, but if it’s possible to achieve something like this in FMOD that’d be super useful and way more convenient.
The closest I got was controlling A with a sawtooth LFO, with B controlling depth, but I couldn’t guarantee it’d be at the correct spot in the LFO when B was ‘boosted’ so it didn’t sound consistent enough.
That would be a very substantial change to how parameters work, both conceptually and under-the-hood. Given that the behavior you want is achievable by other means, we’re unlikely to implement the change you suggest.
This is possible to achieve in FMOD Studio. Instead of automating parameter A on parameter B, add an AHDSR modulator to parameter A, then set the modulator’s attack, hold, decay and release properties to 0.00 ms. Then, automate the modulator’s Sustain property on parameter B.
Brilliant! Thanks Joseph that’s perfect, and being aware of that potential interaction will be very useful for other things in future.
If I can just pick your brain on something else as well - since I first asked the question this boost behaviour has been extended, and now multiple boosts can stack up (so A + B, and then +B again a little later). So my idea for implementing this to have an event with a command instrument that increments B by the correct amount. Is that the easiest solution or is there something obvious I’ve overlooked?
I’m not sure I understand how this solution would be easier than setting the parameter from your game’s code. Command instruments set the value of the parameter via an API command; which means that, like automation, they set the base value of the parameter rather than applying an adjustment on top of that base value. To make this solution work, therefore, your game’s code will need to keep careful track of how much adjustment has been applied by each command instrument - and at that point, you might as well have your game’s code the the parameter directly, instead of using a command instrument as an intermediary.
The ‘GlideSpeedBoost’ parameter can be set to -100 to 100, and when the event is triggered this param will increment both GlideBoostInc & GlideBoostDec - however their curves are set up such that values of -100 to 0 will only affect GlideBoostDec, and 0 - 100 only GlideBoostInc. Both these params have velocity set to bring them back to 0 over time. This has the behaviour I intended: repeated triggers of this event will increment/decrement by further amounts.
I’m glad to hear you were able to get the behavour you want, though less glad to hear about the crashes.
Given that this event just increments the value of the parameters, would it not be simpler to “cut out the middleman” so to speak, and just set those parameter’s values using your game’s code?
Well I was tweening these values in code, but it’s actually far easier to do it in FMOD because parameter velocity does the tweening for you - and I’ve always assumed that keeping code out of Update() wherever possible is good practice. Using the increment means successive boosts can add up, and I don’t need to track the current boost amount (which is always tending towards 0) in code as FMOD is doing it for me. You’re absolutely right that I could do all this logic in code, but I find doing things in FMOD (where possible) far more intuitive. Just a shame that automating the parameter envelope (which is key to the whole thing) crashes Unity all the time!
