After setting the loop count with Channel::setLoopCount, calls to getLoopCount are correct and sounds play as expected. A channel set to 0 plays once, set to -1 loops forever, and if set to n the channel loops the sound exactly that number of times. My problem happens when I set the loop count to 1 or more. Calls to getLoopCount always return what I originally set the loop count to and never decrement. I need to know when a sound starts its final loop.
The documentation says:
This function retrieves the [b:4onrf3vy]current[/b:4onrf3vy] loop countdown value for the channel being played. This means it will decrement until reaching 0, as it plays.
Is there something I need to do to get the channel to update its value, or is this all supposed to happen internally?
- johnny_w asked 8 years ago
Ok I did some digging, it seems getting the current loop count from a create compressed sample sound is not supported. I’m working up some code now to get it supported for our next development branch release, however I won’t be integrating it to stable branches.
If you have source access you can contact me at email@example.com for a source patch.
Firstly 4.26.00 is a pretty old version ~8 months, have you tried updating to the latest version in the 4.26 series? I have just run a quick test here confirming setLoopCount behaves as expected.
Essentially all you need do is set the sound as looping (FMOD_LOOP_NORMAL) either at createSound time or later via setMode, then do setLoopCount once the sound has been played on a channel. Subsequent calls to getLoopCount should decrement each time a loop is played.
If you still have issues after updating can you post the code you are using that reproduces the problem?
I understand that the version is somewhat dated, but we are very stable and updating tends to present new problems.
I did try bumping the version to 4.26.19, but the problem was still there. The sound is set up correctly at creation time because it definitely loops the set number of times and then stops. I have, however, found that creating the sound with FMOD_CREATECOMPRESSEDSAMPLE causes this behavior. If I remove just this flag, everything works as expected. I don’t see anything documented that suggests creating a sound with this flag affects loopcounts.
Please login first to submit.