We are currently looking into whether or not it is possible to dynamically assign a transceiver channel for transmitter/receiver events to use at runtime upon instantiation. Note that we do not need to automate or change the channel once an event with the transceiver has been created.
We might have a specific enemy type/class with a number of different events (foley, footsteps, VO etc) and so all of these could go on channel 0 for example. But if we then had another enemy of the same type/class we would want to use channel 1, then channel 2 for the next etc.
We are currently on FMOD 2.02.16 but are considering upgrading to 2.03 at some point.
You can assign transceiver channels at runtime, but you cannot automate them using an FMOD Studio parameter- it can only be assigned with code by setting the FMOD_DSP_TRANSCEIVER_CHANNEL on the transceiver dsp.
If you don’t want to delve into the API then you could potentially create multiple transceiver instances, each transmitting on a different channel, and control which one is transmitting by automating the level of each transmitting transceiver, for example:
Is it possible to assign transceiver channels at runtime for ‘embedded events’? We have an event that has just one DSP (fader) but embedded within it is another event that has a transceiver DSP.
I’ve been using getChannelGroup, getNumDSPs, getDSP, getType etc (to find the transceivers) but I’ve not yet come across any way to look at embedded events.
If this is not possible then we can adjust our approach.
Hmm, I don’t think we have a way to access referenced events actually, which seems like a bit of an oversight. I will talk to the Dev team about adding a new FMOD_STUDIO_EVENT_CALLBACK_TYPE to trigger when a nested/referenced event begins playback.
As an alternative, instead of playing back embedded events through a referenced or nested event, if you start the event using a Command Instrument then you can get the event instance via an FMOD_STUDIO_EVENT_CALLBACK_START_EVENT_COMMAND.
Potential issues with this approach would be that the lifetime of the embedded event wouldn’t be tied to the lifetime of the parent event, so you would need to stop the embedded event with a second command instrument if the embedded event doesn’t end on its own.
EDIT: Thinking more about this- you can get the event instance of a newly started nested event using a FMOD_STUDIO_EVENT_CALLBACK_STARTED callback, but you wouldn’t be able to distinguish from nested and non-nested versions of the event. Given your use case I don’t think this would matter, but in any case, this is another approach you could try.
