# Property seek limitations and suggestions

**URL:** <https://qa.fmod.com/t/property-seek-limitations-and-suggestions/22638>\
**Category:** FMOD Studio\
**Created:** [February 26, 2025, 9:17pm UTC](https://qa.fmod.com/t/property-seek-limitations-and-suggestions/22638 "2025-02-26T21:17:37Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\
**Post date:** [March 3, 2025, 11:00am UTC](https://qa.fmod.com/t/property-seek-limitations-and-suggestions/22638/3 "2025-03-03T11:00:36Z")

</div>

> [@FMOD\_Aaron](#):
>
> To dive into this a little deeper, I think a big thing to remember here is that Seek can be applied to any property, not just volume. Seek as a modulator wasn’t intended necessarily as a solution purely for mixing or stems, but as a modulator to be used on any value.

I know, but by seing (and having contributed to) those posts ([1](https://qa.fmod.com/t/crossfading-between-audio-tracks-when-using-a-discrete-parameter/18269), [2](https://qa.fmod.com/t/crossfade-on-labelled-parameter/18189), [3](https://qa.fmod.com/t/transitions-for-labelled-parameters/16828)), I guess people were mainly waiting it for the use on volume for transitions between states.

> [@FMOD\_Aaron](#):
>
> Therefore, having specific curves applied to specific property types would result in unexpected behavior.

I don’t get it. What’s the logic of applying the same curve on volume (dB) and on, for instance, the rate of a chorus effect (Hz) ? It’s already like adding oranges to carrots. Each type of property should have it’s own relevant map.

> [@FMOD\_Aaron](#):
>
> So if we were to apply another curve on top of the existing dB mapping, the values would be remapped essentially twice, which can lead to performance issues.

I can understand that, and keeping things simple is often better… if things are simple and correct in the first place! I think the default volume map is incorrect. Either an equal gain law or an [equal power law](https://www.production-expert.com/production-expert-1/understanding-crossfades-in-pro-tools) give way better crossfading than the volume seek progression. In the following exemple, the equal gain law (1st exemple) is better because of both signals being identical, but the default crossfade curve (2d exemple) should be better in most cases. Note how the volume seek (3d exemple) completely fails compared to both of them.

[![](https://img.youtube.com/vi/2b6c_QuVIlk/maxresdefault.jpg "FMOD seek volume map problem") ](https://www.youtube.com/watch?v=2b6c_QuVIlk)

> [@FMOD\_Aaron](#):
>
> some approaches I found particularly useful were using the Ascending / Descending values when dealing with blending mixes

I already mentioned that in my first post, but that’s a poor workaround. The 4th exemple in the video above uses an upward value of 0.5 and downward value of 0.15 ; it’s better but far from ideal.

> [@FMOD\_Aaron](#):
>
> If you need automation curves, then the original method of using Parameter automation curves, then applying Seek to the Parameter is still a completely viable workflow & a particularly good one for this type of mixing.

No it’s not, because it’s not possible to switch from a value to another without going through intermediate values. That’s precisely to overcome this limitation that the property seek was awaited.

---

_[View the full topic](https://qa.fmod.com/t/property-seek-limitations-and-suggestions/22638)._