We are using FMOD with UE for a new project we are making and got a component that sets some rendered audio (using elias for that) into the callback that is set at pcmreadcallback on FMOD_CREATESOUNDEXINFO.
So far it seems to work…the rendered audio will be modified if we add some DSP effects so we assume it’s actually working, however this is where we are lost. We expected that we could somehow see this input on FMOD Studio ( and tweak it with Live Update ) or even add it to some group on the mixer and allow our Audio Engineers to apply group parameters.
The documentation about DSP plugins makes it look very low level. Is there any way to expose this to our audio engineers? Is there any way the audio is added to a group in the mixer?
We would greatly appreciate some help here.
To do this you would need to make a DSP plugin as a stand alone dynamic library: FMOD - White Papers | DSP Plugin API.
Thanks for the help (and answering the other topic, sadly programmer instrument didn’t help me). Before making our own dsp plugin we were wondering…will this allow our audio engineers to tweak the values using Live Update? because we do know that adding the DSP effect with c++ works (as stated on your documentation) but that’s exactly what we want to avoid, since it won’t be as friendly as we need.
Apologies, I should have also linked the Studio docs: FMOD - Plug-in Reference.
You can create plugins, and a custom UI, for your audio engineers to use in Studio. You can then tweak the values using Live Update as you would with any other effect.
One last question. We were used to have our music affected by global variables depending on the situation we are currently. If we create a DSP plugin it means that the only effect that will affect this stream will be from the DSP? or we still can have one single variable to change “something” as if it were a regular event?
(sorry if this doesn’t makes too much sense, streaming and dsp plugins are new waters for us)
PS: we managed to do the following:
-Create a programmer sound using an event with a progammer sound (with 1second duration, need some info about why it has to be 1 second long)
-On the FMOD_STUDIO_EVENT_CALLBACK_CREATE_PROGRAMMER_SOUND we created the stream
-On the FMOD_STUDIO_EVENT_CALLBACK_DESTROY_PROGRAMMER_SOUND we kept the code from the sample (release the sound)
-Live update now allows us to modify this event. giving us the result we wanted.
Would it work fine? it’s kind of weird to have to create the stream each second, will it affect the performance? is there any way to have the duration to infinite and only create the stream once?
When you use programmer sounds on an event made in Studio, it will work as a regular event. Any other DSP/effects added down the line will still affect it. You can even expose properties from your DSP as parameters on the even rather than trying to set the values through the DSP API.
This may be to do with your event, if you were to add a loop region to the instrument or make the instrument ‘async’ then it shouldn’t cut off your programmer sound. (If this does not help then I will need some more information on the issue.)
It did have a loop region but found that it seems to be depending on the length of the event (both fmod event and the event paremeters created in code). We found that matching the length on the FMOD_CREATESOUNDEXINFO and the length of the fmod event seems to work but were expecting to set the length in FMOD_CREATESOUNDEXINFO to infinite (not sure uint_max would do the trick) and hoped fmod studio would assume that an event with loop should be treated as infinite too.
Matching the values work, i could put something like…1min and the callback will be called every minute, but my question remains as…how expensive is it to be creating this stream sound every, let’s say, 1min? (it seems like it could be 10min or even 1 hour but we are curious now as if it’s actually that expensive performance-wise)
Thanks for the help so far.
The loop region will need to be inside the length of the programmer instrument, otherwise the programmer sound will keep starting and stopping.
Making the instrument async is a nicer way to do a similar thing, it will just keep the event alive as long as the instrument is playing.
Streams are not something you want to be stopping and starting for short sounds. Depending on what you are playing and how many effects it is using will determine how expensive it is, but over a minute playing 60 streams will be a lot more expensive than playing just one.
No matter what i do it seems like it keeps following the length specified on FMOD_CREATESOUNDEXINFO, after that time is done the callback is triggered for FMOD_STUDIO_EVENT_CALLBACK_DESTROY_PROGRAMMER_SOUND and then it doesn’t triggers again (unless i match the length of the info and the event).
Even with the loop region or the Async option it doesn’t seems to be working as described. (Using 2.01.08)
But i think we can work with what we got so far. We will probably just go with the option of making it replay every minute (or 10) which seems to work (we are playing a background music in loop). Thanks again for all the help
You should not need to specify a length in FMOD_CREATESOUNDEXINFO, every property except cbsize is optional. FMOD - Core API Reference | System (fmod createsoundexinfo)
I did try without setting the length but then it doesn’t even play (i just tried right now not setting anything other than the pcmreadcallback), the pcmreadcallback from the Stream that is created for the programmer instrument gets called once and then never again. Then the ProgrammerSoundCallback get’s called after the loop region restarts on the fmod studio event.
Are you checking the result returned from the createSound/Stream function? If there is a problem it will give you details on the issue.
Checking on your examples i see that there is one that does almost the same as what we do for creating the stream (user_created_sound.cpp). If i pass an info without any params it will return FMOD_ERR_INVALID_PARAM.
Seeing that example it’s starting to make sense, the length is the duration that we are expecting for our user created sound, which should be the same as the event. Once the event loops it should match the length that we were expecting when creating the sound, even if it’s not really looping for us, which is why i mentioned about the infinite duration. It makes sense that the info for user created sounds has a duration (if you created it thinking on a single sound) but it doesn’t if what we are playing is background music (stream)
Assuming that we got that right, it doesn’t really matter if we set the length to 1min or 1hour, as long as both event and info are synced.
