I’ve been experimenting with 2.0.0’s new features. Kudos on those by the way, great stuff! One of the features that caught my eye was the Speed built-in parameter, but I cannot seem to be able to make it work, which leads me to believe that I may have misunderstood its functionality.
To test things, I created an event and on its Timeline sheet I placed a temporary, very short sound (just to monitor event output in Unity; let’s call it ‘feedback sound’) and a loop region on the Timeline sheet, so that the event would keep playing once started (since the event would stop immediately otherwise, as I intended to remove the feedback sound later). Then I added the built-in Speed parameter and placed an audio asset on its sheet (let’s call it ‘main sound’) spanning from 0.1 to 10, so that it would only play that sound if the object the event was attached to was moving, even in the slightest. Finally, I put an FMOD spatializer on the event’s master track. In Unity, I attached the event to the Player’s feet, since I intend to use the Speed parameter functionality in a footsteps event for a first-person character (player doesn’t move: no sound, player moves slowly: soft footstep, player moves quickly: hard footstep. Simple, effective, no coding required, less hassle/debugging; it’s ideal!). I then hit Play, started moving around, and I could only hear the feedback sound, and never the main sound. I could see that the event was playing alright, but the Speed value was presumably staying at 0 value. To make sure there was nothing wrong with the main sound itself, I tried dragging its module on the Speed sheet to cover the 0 value as well, and the main sound then played ok.
I was baffled. I took a look at the documentation again.
The new speed built-in parameter is automatically set to the speed of the event instance it’s used in (determined by the velocity of the event instance relative to that of the listener). This can be used to automate properties of an event instance based on how fast it is moving.
The way I had interpreted this the first time around, was that FMOD calculated the speed based on the changes of an event’s/gameObject’s 3D attributes alone, which made perfect sense. But, now, I started wondering whether it was possible that the ‘relative to that of the listener’ part meant that the parameter took the Listener’s 3D attributes under consideration as well, but even though this makes perfect sense in, say, the Distance built-in parameter’s case, I failed to see how the Listener’s position would have anything to do with any other gameObject’s Speed. If that really were the case though, it might mean that the Speed value of my event would always be 0, as the Player’s feet, on which I had attached the event, stayed in the same relative position to its parent gameObject, which in turn contained the Listener. And, if that were the case as I said, though Speed would nevertheless remain an awesome feature, it would be a no-no for my player footsteps scenario. Regardless, I decided to put this to the test. I created a cube in Unity, and added some basic animation to it. Then I removed the event from the Player’s feet, attached it to the cube, and pressed play. The cube was moving (at different speeds and across all three axes), the feedback sound with it. Again, though, the main sound never played. I even tried walking around with my character, and still seemingly no change in Speed. Through code I printed the event’s Distance, Elevation and Speed (final)values (I added Distance and Elevation sheets for that), and could see that, while the cube was moving, the Distance and Elevation values kept changing, but the Speed value was fixed at 0.
Why is this happening? And are the Listener’s 3D attributes indeed needed for the Speed to be computed? If so, would that mean I cannot use the parameter the way I intended?
On a side-note, why is it that built-in parameters cannot be global? That would come in handy if, for instance, other events needed to know the Distance/Elevation/etc of a certain event. And making that information global (without the use of code) cannot even be achieved indirectly, by automating a global parameter based on a built-in parameter, since global parameters “can only be automated by a global parameter”. A very nice case of catch-22.
I am sorry for the excruciating post length, and thank you for your time and for the awesome features!