0
0

Hi,

Our sound designers have placed a number of closely-related sound definitions within a single event, with the idea being that the primary parameter is set accordingly to control which sound to play.

This looks similar to the "SeekParameter" event in the examples.

However, in our event, each sound starts on a whole-number boundary and has a length of 1. So the first sound goes from 0->1, the second from 1->2, the third from 2->3 and so on. So if for example I want to play the 7th sound in the event, I create an instance of the event, set the parameter to ‘6.0’ and start the event.

Now for some events this works just fine. However, for others I get one of the following occuring:
– The wrong sound plays.
– Two sounds play at the same time (one correct, the other incorrect)
– The event finishes immediately (the finished callback is actually called from within the Event::start function). This last one causes us all sorts of nasty problems! :)

I have just discovered that if I add a small offset to the parameter position, e.g. set it to 6.0005 instead of 6.0, then it all works as expected.

As a programmer, I can imagine how these problems might occur in this situation. However, from a sound designer perspective this doesn’t seem like a totally unreasonable thing to do. Especially considering that’s exactly what the "Lay out sounds evenly" option seems to do. 😉

So what would be the recommended course of action? I don’t particularly like my "epsilon" fix, not as a permanent solution anyway, because it’s a bit hacky. On the other hand, I don’t really want to have to get our audio designers to go through changing all the sound lengths / start positions (there are quite a lot of them).

Is there perhaps any room for improvement in how FMOD handles this case, where one sound ends and another starts on the same parameter value? I’m slightly hesitant to label it as a bug, because I can sort of see how technically they could be interpreted as overlapping. However considering the "Lay out sounds evenly" option in the designer tool will result in this situation, I would expect it to "do the right thing". :)

Many thanks,

Dave

  • You must to post comments
0
0

[quote="dlomas":2nxp5e3y]
I have just discovered that if I add a small offset to the parameter position, e.g. set it to 6.0005 instead of 6.0, then it all works as expected.
[/quote:2nxp5e3y]

Just to be clear, I’m talking about adding the small offset to the value in the EventParameter::setValue call, not to the values in the designer tool event editor.

  • You must to post comments
0
0

Use your epsilon value for now. We’ve logged the issue and will address it for a future release.

Cheers,

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.