This is actually a pretty complex question, so I’ll need to go over several different concepts in order to cover everything.
To begin with, though: No. Even if two events the same parameter, you can’t update one and expect the other to change. (Usually, anyway. I’ll get to the exception later.) This starts to make sense as soon as you realise that it’s not events that have updatable parameter values, it’s event instances.
When you play an event in your game, you’re actually creating an instance of that event - and theoretically you could have more than one instance of that event playing at the same time. In most cases, this happens because the different sound events represent separate in-game events happening at the same time but in different places. For example, if your game had two different musicians in the same dance hall each playing wicked guitar riffs, each of those guitar riffs could be a different instance of the same guitar riff event.
Now suppose that one of your game’s frequently-instanced events has a parameter. Often, you’ll want to set the values of each event instance independently - perhaps so that our two musicians can have differing levels of fatigue. FMOD Studio supports this by making each event instance have its own independently-set parameter values. (This is especially important for events that use the Timeline. The Timeline is just another parameter, despite having some special behaviour; If event instances couldn’t have different parameter values, all instances of a timeline-using event would have to play in sync.)
That’s the heart of why you can’t set the value of all parameters with a certain name at once: FMOD Studio has no way of knowing which event instances you want to target unless you specify. Thus, if you want to set every event instance’s parameters to the same values, you need set each and every one of them.
Oh, and I mentioned there is an exception that lets one event instance’s parameter update the parameters of other event instances. This is it: If an event contains an event sound module or an event reference sound module, and the referenced event has a parameter with exactly the same name and range as a parameter in the parent event, then any instance of the referenced event triggered from that sound module will automatically update its parameter values to match those of the specific event instance that triggered the sound module. Note that because nested and referenced events share routing and position with their parent events instances, this is only useful for events where positioning and routing doesn’t matter, or where the nested event should always share the same position and routing as the parent.
As for whether you should create your ‘event 2’ audio tracks inside ‘event 1,’ I can’t say for sure whether that’s best for your project without knowing more about what you’re trying to achieve. Still, in general it’s usually easiest and cheapest to keep your events simple; If you don’t need event 1 and event 2 to share a timeline or otherwise behave as a single entity, it’s probably best to keep them as separate events and update their instances’ parameter values independently.
Incidentally, we do intend to create a “global parameters” feature that will allow you to specify certain variables that can be referenced by any event in your project, but we have not yet set a release date.
