I’m hoping to make one group bus duck another but allow certain frequencies pass through without being effected. Ideally this would be as simple as a dynamic EQ being triggered by an source other than bus it’s placed on, but I don’t think that’s possible correct? Is there any way to approximate the results of something like this?
If more context helps, this is for a game that will have an extremely dense mix. I’m hoping to thin out the mix by having various group buses duck specific frequencies of other, less important group buses.
In any recent version of FMOD Studio, you can attach a sidechain modulator to a property of a multiband EQ effect, and link that sidechain modulator to a sidechain effect elsewhere in your project.
In FMOD Studio 2.03.00, you might prefer to use the new multiband dynamics effect, which can compress or expand a specific frequency range of a signal, and can be linked to a sidechain effect elsewhere in your project.
Hi Joseph! Thanks so much for the reply This is great to hear!
A couple quick follow up questions:
“you can attach a sidechain modulator to a property of a multiband EQ effect, and link that sidechain modulator to a sidechain effect elsewhere in your project.” -
– Super cool, I’m curious how the EQ reacts in this case. Does the sidechain trigger the EQ instantly? Is it possible to control the attack and release time? Say I want one high priority gunshot sound type to duck another (lower priority) one below 500hz by 15db. Will the triggering of the EQ occur gradually? Will it release gradually? Or is it more akin to a light switch like 0.0 to -15db and back up instantly? Will the EQ react proportionately to the sidechain? If not, is it possible to attach an ADSR to this behavior? Hope this question makes sense!
On FMOD Studio 2.03 - The multiband dynamic effect looks great and would be a huge help for this project! Do you think 2.03 (vs 2.02) is stable enough for me to safely recommend to the developer I’m working with? That might be difficult to answer but any insight would be very appreciated!
As you can see, the attack and release properties allow you to control the attack and release time of the modulator.
For technical reasons, you can’t attach a modulator directly to another modulator, so it’s not possible to attach an AHDSR modulator to a property of a sidechain modulator. Even if you could, it wouldn’t do what you want, because AHDSR modulators’ attack and release behaviors are begun by the triggering and untriggering of the instrument to which they are attached or the event instance in which they are present, not by arbitrary adjustments to the properties of effects that could occur at any time while an event or instrument is playing. (Of course, since you can just use the attack and release properties of the sidechain modulator, this question is moot.)
FMOD version numbers are split into three parts, in the format: productVersion.majorVersion.minorVersion . Major versions contain significant changes and add new features, and may affect bank compatibility and playback behavior in some cases. Minor versions, also known as patch versions, contain only bug fixes and smaller workflow improvements. Because major versions feature major changes, major versions are much more likely than minor versions to introduce significant bugs. We thoroughly test everything we release, of course; as quality assurance manager, I try and make our testing as thorough as I feasibly can. Even so, no amount of testing is guaranteed to catch everything, so there’s always a chance that a new major version will have a few bugs that slip through the net and affect early adopters. In acknowledgement of that possibility, we mark the first few releases of each new major version as “early access” on our downloads page, so that people who download it know that it hasn’t yet been “used in anger” in many real game projects, and so might have significant undiscovered issues.
As the first release of a new major version, FMOD Studio version 2.03.00 is an early access version. The next few patch versions of 2.03 will probably be early access versions as well. Eventually, once enough people have started using version 2.03 in actual games, we’ll feel confident that there are no serious bugs, and start releasing versions that aren’t tagged “early access.”
So, to answer your question of whether version 2.03.00 is stable enough to safely recommend to the developer you’re working with…
Maybe? It depends on what stage of development your game project is at.
If your game is only just starting development and won’t be finished for a long time, switching to FMOD Studio version 2.03.00 is a good idea. Yes, it being an early access version means it might have undiscovered bugs - but we’ll fix those bugs in patches as we find them, and updating to a new patch version within a major version is pretty safe. Switching to version 2.03.00 early in a game project means you’ll be able to use all of the new features, and you should be able to update to new patch versions that fix the bugs long before you release.
On the other hand, if your game is getting close to release, upgrading to 2.03.00 is a bad idea. If the new version turns out to contain bugs that impact your project, there’s no guarantee that we’ll finish fixing them before your game needs to be released, and even if we do release all the fixes you need, you’ll have relatively little time to test all your game’s audio afterwards.
So, as I said, it depends on what stage of development your game project is at.
Pardon the slow reply, the week got away from me! Thank you for this very informative reply! We’re a ways out from release so sounds like 2.03 will be great for this project.
This forum is the place! Any new thread is automatically ticketed in our support system, meaning it’ll be triaged and assigned to one of our staff for investigation in short order.
We’ll try and provide you with a workaround for any bug you report - and if there is no workaround, we’ll at least advise you on how to avoid the bug until a fix can be released.
This is great to hear!