0
0

Hello,

I’ve hit a few dead ends trying to figure this out, and I was hoping to get some ideas.

In our designer project, we have a standard Event category set-up of music, sfx, and speech, and use them to independently adjust volume, add DSP to a given category’s ChannelGroup, etc.

We’re trying to create an effect that will highlight a given sound based on player actions. The desired outcome is that one or two currently playing events will be played normally, while the rest of the game’s sounds (except maybe the music) are processed with some DSP such as a Lowpass Filter.

For one approach, I set up a Lowpass filter at the head of the Event System ChannelGroups. I created a "bypass" ChannelGroup, with the intent of moving the "focused" event’s Channel to that ChannelGroup during playback.

The problem is, I can’t seem to isolate the "focused" event’s channel from the FMOD end, because my criteria is arbitrary from FMOD’s perspective. I can obtain a playing event’s ChannelGroup, but not its Channel.

This post details a useful way of selectively applying occlusion DSP to Channels using information on their 3-D position:
http://52.88.2.202/forum/viewtopic.php … annelgroup
My problem is that I can’t determine a way to find the Channels that correspond to the event I’m interested in. There is no 3-D position criteria for my events or anything I could see that I could use to link the event to its channel.

The events I wish to "focus" on belong to the sfx and speech EventCategories. Any event could potentially be selected, so I don’t have the luxury of setting up special categories. I’d prefer to avoid having to set up a parameter for every event in the game as well.

Is there any way to obtain a playing event’s channel, determine what event a channel corresponds to, or otherwise bus a playing event to bypass its category’s DSP chain?

Thank you for any ideas!

  • You must to post comments
0
0

Hi,
There are a couple of possibilities here, both using the event’s channelgroup:
[list=1:31kkn32x][:31kkn32x] Use ChannelGroup::getNumChannels and ChannelGroup::getChannel to iterate through the event’s channels. You may need to iterate through sub-groups as well, depending on the complexity of your event (there can be one channelgroup per layer, all going into the event channelgroup). This approach could run into problems if the event starts more channels after you do this.[/:m:31kkn32x]
[:31kkn32x] Just use ChannelGroup::addGroup to add the event’s channelgroup to your bypass group. This is much simpler and less error-prone, so I recommend trying this approach first.[/:m:31kkn32x][/list:o:31kkn32x]
Good luck!

  • You must to post comments
0
0

I’ve been tackling a similar issue, though I’m just working with attenuating volume/pitch of all sounds but the sound in focus (not bothered with DSP filtering at this stage).
Regarding your approach, if you add the focus sounds to a bypass group, how do they inherit the remainder of the games DSP filtering (or do you just assume it doesn’t need to?). For example, say you add a muffle DSP to the dialogue category, then a specific dialogue event becomes the focus sound (because it’s mission critical). If you add the dialogue to the bypass DSP, do you just need to manually make sure the muffle DSP is connected to the bypass DSP as well? I hope that made sense :).

In terms of volume attenuation, I need to have the focus sound inherit all volume attenuation levels all the way down the hierarchy, so I can’t just extract it and place into a separate group. I can’t set the master volume down and then boost the event volume either, because you cannot apply volume boost (volume > 1.0) to a sound. So instead I’ve set the volume of all other (leaf) categories down, except for the focus category (left at 0db), which is a bit long winded.

  • You must to post comments
0
0

Thanks for the replies guys; I’ve been away from this for about a month but have been able to work on it again.

Re: Ben
Thanks for the hint. I set up some tests where I obtain a pointer to the Event’s ChannelGroup (pEventCG,) and call: pBypassGG->addGroup(pEventCG) to add it as a child of the bypass ChannelGroup. Although the results are reported as FMOD_OK, and pEventCG->getParentGroup() confirms that the pBypassCG is the new parent of pEventCG, this change is not reflected in the audio, nor is it displayed in the "Profiler" view of FMod Designer. It depicts the event’s channel group as staying where it was (under its original Category ChannelGroup.) I know I’m getting the correct ChannelGroup for the event because operations like pEventCG->setPaused(true) audibly stop the audio output for the event and visibly gray out the Event’s group members in the Profiler.

Have you guys confirmed that this operation should work on playing events (and I’m missing something) or does it not work due to the Event System design or a bug? I’m still pretty stuck.

Thanks again for any help!

Re: Jade_Lee
To answer your question, I’m not concerned with the bypass group sounds inheriting any of the DSP that they may have been going through via their category ChannelGroups. One approach to do so (for say, a SFX category) might be to create an intermediate Category that is a child of SFX called SFX_LPF. All the category’s events would be under SFX_LPF by default. You could hook up your category DSP to SFX, and have a lopwass filter on SFX_LPF. A bypass ChannelGroup could then be added as a child to the SFX group, and sounds from SFX_LPF could be directed there as required to bypass the LowpassFilter only but retain other category effects. Of course, I haven’t been able to get this kind of Re-bussing of ChannelGroups working in practice yet!

In order to individually "punch" the volume of a single event category, I think your approach sounds correct. We let our users set relative volume levels for a few categories as well as a master volume, so I’d be sure to restore them after the volume punch has ended. If you wanted to do an individual event and not an entire category, you might adopt the Bypass group approach (assuming we get it working 😉 ) and apply any category-inherited volume attenuation directly to the Event’s ChannelGroup after moving it. (e.g. you’d keep track of any volume attenuation assigned to all categories, and multiply the attenuations of the event’s parent groups together to calculate its overall attenuation.) This way, if you moved several events from different categories into the bypass group, they would retain their relative mix. To attenuate all of the other sounds, I’d obtain the parent ChannelGroup of your topmost event categories and lower its volume. (The bypass group would be connected to bypass this group.) I hope this is helpful!

  • You must to post comments
0
0

[quote="Logarhythm":1w9mkdql]Re: Ben
Thanks for the hint. I set up some tests where I obtain a pointer to the Event’s ChannelGroup (pEventCG,) and call: pBypassGG->addGroup(pEventCG) to add it as a child of the bypass ChannelGroup. Although the results are reported as FMOD_OK, and pEventCG->getParentGroup() confirms that the pBypassCG is the new parent of pEventCG, this change is not reflected in the audio, nor is it displayed in the "Profiler" view of FMod Designer. It depicts the event’s channel group as staying where it was (under its original Category ChannelGroup.) I know I’m getting the correct ChannelGroup for the event because operations like pEventCG->setPaused(true) audibly stop the audio output for the event and visibly gray out the Event’s group members in the Profiler.

Have you guys confirmed that this operation should work on playing events (and I’m missing something) or does it not work due to the Event System design or a bug? I’m still pretty stuck.
[/quote:1w9mkdql]

Hi,
I just tested this again, and it works as expected with FMOD 4.22.00, but not with FMOD 4.20.07 – sorry about that! I’m guessing you’re using a 4.20.xx version?

This issue has been fixed for the next release of the 4.20 branch (FMOD 4.20.08), or alternatively you could upgrade to the 4.22 branch.

Thanks,
Ben

  • You must to post comments
0
0

Hi Ben,

That was it all right. I updated to FMOD 4.22.00 and now the code works correctly. I agree that the ChannelGroup::addGroup() approach is the smartest way to do this. It sounds good too.

Before reading your original comment, I wasn’t aware that each event instance was placed under its own ChannelGroup (I mistakenly thought Event::getChannelGroup() returned the category ChannelGroup) so that cleared up quite a bit too!

Thank you very much.

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.