If I understand this correctly, @Alcibiade… You’re happy with the behavior of seek modulators for most property types and most situations, but have found they’re not suitable for crossfading one signal with another, as a crossfade requires equal-power curves and seek modulators do not use that type of curve to smooth volume properties.
I can certainly see why you’d want that, so I’ve added the suggestion to our feature and improvement tracker. It’s a tricky request to fulfill, though, because it touches on some details of how volume properties work under-the-hood. I’ll try to explain as best I can below.
There’s also a workaround that you should be able to use in the mean time. I’ll describe it at the end of this post.
Taking about the type of curves we use is something of a red herring. It is technically part of the explanation, but on its own isn’t enough to answer the question “why do seek modulators work this way?” To answer that question, I’ll first have to explain a little of the seek modulator’s design, so please bear with me.
As you’ve doubtlessly observed, the behavior of a seek modulator is defined by its “speed” property; or by its “ascending” and “descending” properties if it’s set to asymmetrical mode. All three of those properties function in essentially the same way: They define a “speed limit” for the property, putting an upper limit on how quickly it changes.
The values of all these properties represent the fraction of the property’s range that the property’s value may change by in one second. That’s important, because it means that the rate of change defined by a seek modulator is inextricably tied to the scale used by that property outside the context of seek modulators. If a modulator’s speed is 0.1 and a user reduces that property’s value by exactly 1/10th of its range, the property’s value must take exactly one second to reach the new value.
The equal-power curves required for a smooth crossfade have a specific shape: They’re shallow at high volumes, and steep at lower volumes. If we were to implement such curves for seek modulators on volume properties, it would mean that the “speed” properties of those seek modulators would no longer be accurate: The time required to traverse 1/10th of a volume property’s range would need to be longer at high volumes where the curve is shallower, and shorter at low volumes where the curve is steep - and that would mean that the values displayed for the seek modulator’s speed properties would no longer be accurate.
As I mentioned, this is a tricky problem to solve. We can’t simply change the mapping curve that the modulator uses for volume properties, because that would make the values displayed for the modulator’s speed properties inaccurate. We can’t make the value displayed for a seek modulator’s speed properties change depending on the current value of the property, because that would make the displayed value of the property almost meaningless and difficult to interpret, and therefore practically useless. We can’t change the scale used by volume properties under-the-hood to make them naturally result in equal power curves for seek modulators, because doing so would break how volume properties work in every other context in the FMOD Engine… And there aren’t many other options.
Which isn’t to say that the problem is unsolvable, of course; just that a solution would necessarily involve a substantial redesign of how seek modulators work when applied to volume properties, and a new way of describing the maximum rate at which the property’s value can change that doesn’t involve the property’s range in units per second.
So, while I can see why you’d want to use seek modulators for crossfades, and I’d added your suggestion that we improve crossfade support to our feature and improvement tracker, I can’t predict when a solution might become available. We’ll have to discuss this feature internally and do some design work before we know.
I suspect Aaron was actually alluding to a different workaround to the one you’re thinking of. Specifically, I believe he meant to suggest that, rather than automating your volume properties directly on the controlling parameter, you should create one new parameter for each volume property you want to automate, automate each of those volume properties on one of those new parameters, then automate those parameters on the controlling parameter. Then, place the seek modulators on the new parameters, rather than on the controlling parameter or the volume properties.
This method avoids the “going through intermediate values” problem that you describe, because the controlling parameter lacks seek speed and so is able to change instantly from any value to any other value; and because the parameters used to automate the volume properties sit between the controlling parameter and the volume properties, you can use their automation curves to define exactly how those volume properties change over time when the intermediary parameters’ values are set by the controlling parameter, giving you absolute control over how sounds fade in and out.
It’s a little more work to set up, but you should be able to use this workaround to create the perfect crossfades you desire.
