Parameter automation in mixer and nested parameter acces

FMOD Studio
1

Hi all,
I have some doubts about Fmod Studio capabilities\implementation tricks:

1)How is it possible to activate parameter based automation when using effects in the mixer?

For example, in a racing game, I create several engine events, each one corresponding to a different car (Ferrari, Porsche)…
Then all these channels are routed to a to a “Vehicles” group in the mixer, to easy mix and logically group them.

I would like to activate a Lowpass effect on this vehicle group (and not on every different engine event) when helmet cam is activated, so I would need a “isInHelemet” bool parameter to control this effect, for example setting cutoff frequency to 22Khz when helmet cam is off and to 5 kHz when is on…but I can’t add automation on the effects while they are applied in the mixer (and not in the events themselves). Right click on the effect parameter does not show “add automation”

Another example could be the need of a lowpass filter bound to the distance parameter for hf attenuation, for all the 3D events…it would be much easier to apply it on a mixer group in which all these 3d events are routed in, than apply it to every single event.

2) Is it possible to handle smooth transition between mixer snapshot?

We could call mixer snapshot as function of a parameter, creating an event and dragging the different snapshot in its master track. This could be another way to handle mixer automation.
But is it possible to pass smoothly between one snapshot and the other (for example, one having a lowpass set to 20 Khz and the other to 1 khZ)?
I tried to crossfade the snapshot in the master track as we do we the samples, but with no success…

3)Is it possible to directly access nested elements?

I try to explain myself: let’s suppose we have a racing game. We have to implement skid sounds. These sounds depend on the material of the terrain, on the status of the terrain (dry\wet), on the speed of the vehicle, on the level of “friction” produced. Moreover, we need to check if the wheels are against the terrain, and a different sample has to be triggered for every different wheel to avoid phasing artifacts.

So I create the following structure:

At the top level event I have a generic “skid” event with a material_type parameter that controls the selection of different nested sound events, such as “tarmac”, “gravel”, “grass”…
I also have all the other parameters needed such as WheelNumber,StatusDry\Wet,Level of friction,speed of the vehicle, wheel contact status.

For Every material (let’s consider Tarmac), I have other 2/4 nested sound events (Wheel0, Wheel1,…), corresponding to the wheels of the vehicle. Every wheel sound event has finally one or more samples associated and managed in funciont of the “Wheel0_Tarmac_friction” parameter (example for Wheel0).

The so nested friction parameter “Wheel_0_Tarmac_Friction” can’t be accessed directly by the programmer to be set: so this parameter is accessed by using an automation from the its parent event by usign the “Tarmac_Friction” parameter, that is copied exactly to “Wheel_0_Tarmac_Friction” parameter.
But also “Tarmac Friction” can’t be accessed directly by the programmer because it’s in the nested event “Tarmac”, so again this parameter has to be automated to be controlled by the top event “skid”. Here the friction parameter can be easily accessible by the programmer.

The need to create dummy variables and to control the nested parameters just via automation of the parent make things more complicated and less intuitive.

Would it be possible instead of the chain

programmer -> event "skid" friction parameter -> nested event "Tarmac" Tarmac_friction parameter -> nested event Wheel 0 "Wheel0_Tarmac_Friction"

to access directly the parameter of the nested event like

programmer-> skid.tarmac.wheel0->Wheel0_tarmac_friction ??

One could simply activate a “access from parents” option on the desired parameter and get there directly from the top level, because no further mappings are needed in some cases.

4)What’s the level of logic complexity do you suggest to implement?

This leads to the third question: If the direct access to nested elements is not possible, maybe it’s better to leave the material\wheels logic hardcoded by the programmer to avoid making the project too heavy and full of “fake” automations. Do you suggest any particular approach to handle logic between the programmer and the designer?

Thank you for your help,
best regards

Luca

2

You can do this with a snapshot, and snapshots can be triggered by an event. Then the Snapshot Intensity can be automated for a gradual change, either with an envelope or an AHDSR modulator.

If you’ve added a lowpass filter to the vehicle sounds mixer group (aka channel), simply create a blank snapshot, name it “helmet cam”, then right click → Scope In on the lowpass cutoff knob and slide it to your preferred value.

The snapshot in the list can be dragged to a new empty event. It should have an “intensity” parameter exposed for automation.

3

Thank you a lot Peter,
I didn’t notice the parameter “Intensity”! I modulated it with an ADSR and it works perfectly…you solved my points 1 and 2!

Thanks again, all the best!

Luca

4

This should work, so it looks like you’ve found a bug. Thanks for pointing this out - we’ll look into it.

5

Just to clarify, would you play one copy of this event for each wheel, or one copy for all four wheels?

The problem with accessing specific components of the event like this is that it makes the game’s parameter setting logic much more complicated and increases the likelihood of the game code getting out of sync with the event setup. It’s much more robust for the game to just access a set of generic top-level parameters (like “surface”, “friction”, “speed” etc.) that are hooked up to specific properties in FMOD Studio.

We have discussed various ways to make it more convenient to connect nested event parameters to parent parameters, but we haven’t settled on anything yet. Rest assured we are aware of the issue though.

The approach you describe above is probably the way to go.

6

Hi Ben,
thank you for your reply.

I’ll have one generic skid event, that will play different material\wheelNumber nested events that trigger different sounds. For example in a car game I’ll have:

Wheel0,wheel1,wheel2,wheel3 nested events for tarmac, each triggering different tarmac samples, each with its own friction parameter
Wheel0,wheel1,wheel2,wheel3 nested events for gravel… and so on.

I agree it is a bit messy, maybe it’s not the best way to do it.

I see now!

Ok, thanks! So I’ll wait the next releases, I’m sure you’ll find an excellent solution to this issue.

I’m not sure if you referred to the first methodology (a lot of logic in Fmod + fake automation\variables) or to the second (hardcode logic + simple parent events in Fmod), but I guess the second. I think that trying to keep things easier is the best thing to do, even if I’d like to have a lot of “power” without referring to the programmer.

Thanks again, best regards

Luca

7

There’s two options you can do:

  • Use an instance of the same event 4 times (one istance in each wheel), but use a multi-sound to randomize between 4 samples. There’s a chance it won’t repeat.
  • If it’s a loop, you can try containing it into an Event Sound inside the event, and use Start Offset on the loop, tie that to a parameter, then in the parent that contains this loop event sound, apply a Random modulator to the exposed time offset parameter. The loop will start from a random position within the sample, which should greatly reduce the chance of phasing.
8

Hi Peter,

thanks! The solutions you pointed out are smarter than mine, I’ll try both for sure! I especially like the second one, I’m going to try it now :slight_smile:

Thanks again, best regards

Luca

9

Snapshot crossfading is fixed in the 1.1.3 release, which is available now.