I’m trying to find a good way to apply the same general rule to a whole bunch of different events. We’re working on a 2D game and want to do some left-right panning of sound effects from enemies as they approach the edge of the screen, while keeping sounds balanced toward the center for most of the screen real-estate.
We’ve got a system that works for this by mapping the X position to a parameter and adding an identical curve for every event we want to have this panning behavior. However that means that if we tweak that panning behavior we then have to copy and paste that curve to every event. This seems super inefficient.
I imagine this must be a common problem so what’s the best practice for applying the same parameter curve(s) to multiple separate events? Should we use sub-events, or is there some way to add parameters to groups in the mixer?
Adding panning to groups in the mixer is possible if you use a snapshot, but I think it wouldn’t help in this particular case; From what I understand, your intention is to give each event a different parameter value, and a snapshot’s parameter values affect all affected properties equally.
Fortunately, there’s a better solution: In recent versions of FMOD Studio, you can multi-select events to edit them in bulk. (Event elements that are bulk editable are highlighted in gold; You’ll know it when you see it.) If you multi-select all the events to which you need to add automation, you should be able to create the same automation curve for all of them at once.
In theory, you should also be able to use bulk editing to copy and paste an automation curve to multiple events at a time, but at the moment this only adds that pasted curve to the active event. This is a bug; We’ll fix it.
Thanks, while it isn’t a super elegant solution to the general problem it’ll definitely make the ugly one we’ve been using a LOT easier to manage!
Is there a reason why making all the sounds sub events and then applying the panning parameter stuff to the parent wouldn’t work, or would it have the same issue that the snapshot does where every the instance of any of the event(s) would get panned when one of them does?
I’ll need several comments to answer that, so here I go: Subevents (as opposed to event sound modules and event reference sound modules) are deprecated, and recent versions of Studio do not allow you to add them to projects. The subevent feature was originally added as a stopgap measure to a temporary problem, and they’re no longer needed. In any case, they wouldn’t help in this case: Subevents do not use the routing of their parent event, so applying automation to the parent would have no effect on any subevents it had.
You might have been thinking of nested events when you said subevents. That’s our fault; We’ve repeatedly failed to explain the distinction in the past.
As I hinted above, nested events are what is created when you add Event Sound Modules and Event References Sound Modules to the tracks of an event, and allow an event instance to trigger instances of other events. These nested event instances route into the parent event instance’s internal buses, and so can be affected by its effects and automation. You could indeed use these to achieve your goal: The parent event would need an extra parameter that determines which nested event is triggered each time the parent is played, but that would be fairly simple to set up. That said, your game would need to spawn a separate instance of the parent even each time you wanted to play one of its nested events, which would mean an effective doubling of the resources required; Depending on the project, that might be too expensive.