I have non-looped long sound. It is for cutscene player, so I want sometimes play from specific time. When I use instance->setTimelinePosition it will always succeed, but sometimes in a moment I’m getting callback to create programmer sound again. So I’ve tried to set initialseekposition when creating sound in callback, sometimes I get “Loading delay exceeded, sound may play at incorrect time” and sound plays from the beginning.
Also instance->getTimelinePosition sometimes returns time greater than actual sound length.
What version of FMOD are you using?
Are you able to share your callback code at all?
2.0.14
Callback is basically the same as UFMODAudioComponent::EventCallbackCreateProgrammerSound.
I’ve only tried to add just before creating sound:
SoundInfo.exinfo.initialseekpostype = FMOD_TIMEUNIT_MS;
SoundInfo.exinfo.initialseekposition = RequestedTime;
but sound always play from start
When I use StudioInstance->setTimelinePosition, it will usually restart programmer sound. But sometimes it doesn’t, but still it will not work (but now getTimelinePosition will now report different position like it was changed correctly - thats why can report time longer than actual sound).
When I’ve removed NON_BLOCKING, I’m no longer getting warnings about “sound may play at incorrect time”.
The “sound may play at incorrect time” warning should be able to be removed by preloading the sounds before the event needs to play them. We are looking into possible ways we can improve this experience.
exinfo.initialseekposition only works for streams and only the first time the stream is played.
setTimelinePosition does not currently work with programmer sounds, even if the instrument is synchronous, which is something that requires investigation because you would expect it to. I have created a task to investigate a fix for an upcoming release.
Thanks for looking into this!
Hello!
I’m quite interested in this issue given that I need to play/pause/seek in a programmer sound. This message being more than a year old, has the setTimelinePosition issue with programmer sounds have been fixed?
If not, I had a working implementation using directly the Core API (through FMOD::Sound and FMOD::Channel), but I wanted to have better control over the global sound mix and started using Studio API instead. Can I mix Studio and Core APIs, using the Studio API to create the programmer sound event that’s correctly routed and mixed via Studio, and then manipulate the FMOD::Sound for pause/seek?
Additional question: if I’m supposed to use FMOD::Channel API for playback control, how can I get the proper Channel to use ?
I have a bus setup in FMOD studio called “Track”. I tried to call getBus("bus:/Track", &myBus) and then trackBus->GetChannelGroup(&myChannelGroup) but:
- calling it before I start playing the Event fails (which is normal from what I understand, as it’s the only Event on the bus and channels are created only when needed)
- calling it in the Event callback when the programmer sound is created works, but checking
myChannelGroup->getName()returns “Master”, which is odd, and also I don’t know how to get the proper Channel from the ChannelGroup - using
EventInstance->getChannelGroup()from the callback also works, but the ChannelGroup name is also “Master” (and same question about how to get the Channel from the group)
The less you can do this the better, as reaching into the Core API through the Studio API and modifying things can cause unintended issues if you are not careful, although there are some occasions when you just don’t have a choice.
setTimelinePosition still doesn’t work with programmer instruments. A workaround for this could be to automate the start offset of the programmer instrument with a parameter.
Although this only works before the programmer sound is played.
The name ‘Master’ in this context is the Master track of an event in FMOD Studio:
@cameron-fmod Hi, is there a fix for this already? Cheers!
There are no plans to make setTimelinePosition work with async instruments, since they are are not time-locked they are not effected by the timeline position, but synchronous programmer instruments should be working with it.