Hey, I have some new features to suggest for future FMOD releases. I hope other users can benefit from these additions, too. It would be nice to have:
The ability to draw specific panning paths that can be randomly applied to each scatterer instance (similarly to what you can do in Wwise - Wwise-101 - Lesson 4 - Understanding 3D Position Automation - YouTube@2:35), rather than having “fixed” instances that can only be modulated with LFOs or other modulators
The ability to save and load effect presets and chains into the mixer’s buses, much like you can do in the event editor
A motion plugin to implement force/haptic feedback for various types of game controllers directly within FMOD
A low-pass filter and spread control in the spatializer plugin to simulate high-frequency roll off and stereo width reduction with distance. (I know you could simply bind an EQ to the built-in distance parameter to achieve the same effect but that would require adding an EQ to the insert chain just for an LPF.)
For number 1 / you can achieve similar results creating each instances in separate events. Then you can create your spatial automation in it (even with randomness). Then you drag each “children events” as nested inside a “parent event” containing your scatterer instrument.
This is already on our feature/improvement tracker. I’ll add you to the list of people interested in it.
We already support controller vibration for platforms that feature it, via port buses. Is that what you mean?
Is there some reason why you’re reluctant to add additional effects to your signal chain?
I ask because we’re generally reluctant to load too many additional features into the spatializer effect. Doing so worsens its resource cost for all users and makes it more complicated to use, while providing benefit only to the subset of users who understand and deliberately make use of the new feature.
As you mentioned, it is already possible to get the behavior you want by adding a lowpass or equalizer effect to the signal chain. This method has the same resource cost for your game as building the feature into the spatializer effect would have, helps keep the different effects’ behaviors compartmentalized and thus easier for our users to comprehend, and also has the advantage of making it explicit that you’re adding an extra effect to the signal chain and incurring an commesurate resource cost.
From what I read in the manual (chapter 9.4 - port buses), FMOD currently supports vibration for PS5 controllers only - is that correct?
What I’d personally love to have, instead, is the possibility to test vibration on various types of controllers (Xbox, PS4, PS5, etc.) and create motion feedback from scratch using a plugin like Wwise’s Motion Plugin (see Plug-ins | Audiokinetic).
Because we could basically have a single plugin to handle all the things related to distance attenuation (i.e., volume, hi-freq roll off, spread, etc.), instead of having to tweak two or more plugins in the chain for the same purpose.
Also, suppose you have a separate LPF and automate its cutoff frequency using the built-in distance parameter. In that case, every time you change the min and max distance override values in the spatializer plugin or the min and max distance values in the event macros editor, the volume attenuation would be scaled relative to those new min and max values while the LPF properties wouldn’t. And the same would be true for other automated plugin properties, resulting in a time-consuming and error-prone process to deal with.
Having a single plugin would obviate this problem and let you automatically scale all the automation values according to the newly set distance values, while still giving the user full control over the object’s attenuation behavior.
Lastly, to overcome the additional CPU cost, perhaps you could implement a toggle to enable/disable the additional modules in the spatializer (e.g., LPF, HPF, spread, etc.), or even provide a secondary, more advanced spatialization plugin that features all these controls to let the user decide whether they want to use a heavier or more CPU-friendly plugin. (But I would personally prefer the first option.)
Not exactly. The “vibration” port type does only work for PS5, but that’s because only the PS5’s controller vibration accepts pcm data (which is to say, sound) as input. Other platforms control vibration intensity by other means; for example, on PS4 you call scePadSetVibration and pass in a value between 0 and 255 for the intensity of the vibration whenever you want the intensity of the vibration to change.
If you want to use the signal passing through an FMOD bus to control vibration on another platform, you could; I imagine you’d do so by using DSP::getMeteringInfo to get the levels of a channel, then convert the result into whatever level of vibration intensity makes sense for the platform you’re targeting, and pass it to that platform’s usual method of controlling controller vibration.
Have you considered using effect chains? They allow you to treat two or more effects as a single effect for most purposes.
This is what the distance (normalized) parameter type is for. It functions just like the distance built-in parameter type, but its minimum and maximum distance values are based on the min and max distance specified in the event’s macro controls, just like the spatializer effect’s min and max distance are - which means that if the min or max distance changes, you just have to change it in one place, and all effects and built-in parameters will use the new values automatically.
The benefits you’re trying to achieve with this more complex spatializer - including both the ease of workflow and the in-game behavior - can already be obtained by using our existing features.
I think that having a plugin to handle controller vibration directly in FMOD Studio would be a game changer. Is there any chance that the FMOD team will develop such a plugin?
Yes, this is what I currently do in my projects. But if I had to create a custom chain for each event instance, I would end up with hundreds - if not thousands - of effect chain presets. Mainly because I often find myself making small changes to the spatializer effect depending on the size of the emitter, and in those cases I need to detach the chain from its preset and create a new one, which is quite unhandy.
I hadn’t thought of using the distance (normalized) parameter type. Thank you very much for the tip!
I can see how it might be useful, so I’ll add your request to our feature/improvement tracker.
However, I should warn you that because it is already possible to achieve the benefit of this feature by the means I described earlier, it’s likely to be given a lower priority for development than new features that make formerly-impossible things possible. Accordingly, we probably won’t develop it in the immediate future, unless there’s an unexpected outpouring of requests for it.
If that’s the case, I’m afraid I don’t see how having all the properties and behaviours in a single effect would simplify your workflow; you would still need hundreds, if not thousands, of unique variants of that effect.