It’s not the usual attenuation question (I’m amazed how few people seem to read that documentation). In fact, let’s just ignore the max value and only focus on the min, which is what I’m playing with. Max is sufficiently large.
When I call the FMOD::Sound version of set3DMinMaxDistance, only the first call has any effect; subsequent calls with different values do nothing. Example: call it once with a min of 100, then again with a min of 10, and the latter call is apparently ignored. The sound plays with a mindistance of 100. If I switch the order, the sound plays with a mindistance of 10. If I add even more calls after those two nothing changes. The effective value is always whatever is passed to the function the first time after that particular FMOD::Sound is created.
I never use the FMOD::Channel version of the function, but I tried it just now to test, and found that it worked as expected: if I call it twice in a row, the value passed to the last call is always the one reflected in the actual playback.
Am I missing something? I would expect to be able to call set3DMinMaxDistance as many times as I feel like on a Sound, not just once. Is this an FMOD bug?
FWIW, I’m using version 4.28.07. I don’t plan to update right now unless there’s a fix for this particular issue.
- Surge asked 7 years ago
[quote="mathew":3to6esto]Setting the 3D min max on a sound should not affect channels already playing, even the first time. I’m not sure how you are reproducing that behavior, perhaps not calling System::update?
Can you reproduce this behavior with one of the examples?[/quote:3to6esto]
FMOD does not allow us to change the 3DMinMaxDistance while the channel is playing?
So what should I do, if while a sound is playing, I want to change the 3DMinMaxDistance settings and we can hear the changes?
FMOD does not support this? Is there any way to make it work?
Sorry for this message. We do can change the 3DMinMaxDistance setting even while a channel is playing.
- farhanRIT answered 7 years ago
When you use set3DMinMaxDistance on a sound you are essentially setting a template for any channels created after that point. So if you change the minMax for the sound, already created channels will not be affected.
Is this perhaps what you are experiencing?
I didn’t realize it worked that way. That certainly sounds like it would explain the behavior I’m seeing, except for one thing: if the very first call happens after the sound is already playing (so after a channel is created), it does produce the desired result on the existing channel.
Can you explain that? Is it possible that FMOD applies the settings to existing channels if and only if it’s the first time the function has been called on a particular sound?
Setting the 3D min max on a sound should not affect channels already playing, even the first time. I’m not sure how you are reproducing that behavior, perhaps not calling System::update?
Can you reproduce this behavior with one of the examples?
I thought I had been careful enough about reproducing that behavior to feel certain about it, but since then the code changes made to reflect the proper use pattern (Channel vs. Sound) are significant enough that it isn’t convenient for me to try again. I agree the natural place to resolve it would be a sample app. I’ll try getting around to that, but if you don’t hear back from me it’s probably safe not to worry about it.
Incidentally, I should have known better about calling the Channel version of the function, but this was a very old area of my code that hasn’t really been exercised (beyond setting initial defaults) until now. Since it had always seemed to work properly, I didn’t question the way it was written. Thanks for the help!
Please login first to submit.