0
0

Hey guys,

I am coming over from the Ogre forums. I have been using a free OpenAL wrapper (OgreOgg) for ages with my project, but as it gets bigger I decided to switch over to the great FMOD. I found a SoundManager class on the Wiki, but according to responses it is very poorly written and outdated (written in 2006). I am wondering if anyone might take a few minutes to look it over and suggest some updates to bring it up to date. I can’t find too much as far as actually coding for FMOD goes, didn’t see much in the Wiki regarding this. It would be nice to have an updated FMOD class, as I am sure that would attract a lot more Ogre users, which is never a bad thing :)

Header File
http://www.ampaste.net/f376ddccf

Source File
http://www.ampaste.net/f129f4b33

I spent over an hour just cleaning up the crappy formatting the guy had. Any help updating it function/usage wise would be awesome, or even some suggestions for me to look into. Any good up to date learning resources around? I would eventually like to write an Ogre plugin for this to make it easier for the community to use.

  • You must to post comments
0
0

Hi Brutal, welcome to the FMOD forums!

I’ve seen that SoundManager before. It’s a pretty simple wrapper and it exposes the basic functionality you would need and is pretty extensible. There is nothing that I noticed that is obviously wrong with the code from my cursory glance over it.

From what I can see the current feature set is:
-> plays 2d & 3d stream & sample sounds
-> allows attaching 3d sounds to SceneNodes and automatically updates their position/orientation/velocity
-> overrides FMOD file access function with Ogre functions
-> exposes FMOD::System, FMOD::Sound and FMOD::Channel to allow users to implement other features user side.

This is a pretty good feature set, so if you can bring it up to date that would be a good start.

If you’re looking to improve it I would recommend the following:
-> update to the latest development branch. 4.29.xx

There are three angles you can take with this depending on your ability and available time.

  1. I think the biggest bang for buck improvement would be updating it to use FMOD Event System.

  2. Wrap more FMOD functions in the SoundManager for convenience

  3. Improve disk access and memory mangement by allowing users to preload data they’re going to need in the future and allowing async loads.

  • You must to post comments
0
0

Thanks, glad to be here, been having a great time reading over threads. (Think I spent 2 weeks reading threads the first time I found ogre forums)

Yeah, well im glad it isn’t horribly out of date, as we all know code can change considerably in 4 years. The only issues I had getting it to compile were a few Ogre functions that had name changes since then.

[quote:3linfa2c]This is a pretty good feature set, so if you can bring it up to date that would be a good start.[/quote:3linfa2c]

By this you mean just get it working correct? It sounds like from you the FMOD stuff looks correct, and I have corrected the changed Ogre functions so looks like thats good to go ๐Ÿ˜€

[quote:3linfa2c]I think the biggest bang for buck improvement would be updating it to use FMOD Event System.[/quote:3linfa2c]

Yeah I was reading up some on this. I was slightly confused as I only see FMOD Ex and FMOD Designer on the downloads. So the designer is required for the Event system? And to use the Event System I will need to use the Development Branch? Or will the FMOD Ex alone be entirely capable of the Events system?

[quote:3linfa2c]Wrap more FMOD functions in the SoundManager for convenience[/quote:3linfa2c]

For sure, I will try and stuff as much possibly needed functionality in it as possible.

[quote:3linfa2c]Improve disk access and memory mangement by allowing users to preload data they’re going to need in the future and allowing async loads.[/quote:3linfa2c]

Not something I have done much of in the past, might see if someone else from the community wants to give that part a go, or guess I have lots of reading up to do ๐Ÿ˜›

  • You must to post comments
0
0

[quote:pye0whsd]By this you mean just get it working correct? [/quote:pye0whsd]
Correct. I noticed that set3dAttributes only takes two arguments in that code, it now takes three, so there are a few minor changes required.

[quote:pye0whsd]Yeah I was reading up some on this. I was slightly confused as I only see FMOD Ex and FMOD Designer on the downloads. So the designer is required for the Event system? And to use the Event System I will need to use the Development Branch? Or will the FMOD Ex alone be entirely capable of the Events system? [/quote:pye0whsd]
Yeah it’s a little confusing let me break it down:

FMOD Ex
– low level
– programmer API only
– load sound files (wav, mp3, ogg, midi, etc.)

FMOD Event System (a.k.a FMOD Designer API)
– high level
– programmer API used in conjuction with FMOD Designer (our sound design tool)
– data driven (build FEV and FSB files in Designer)

The Event System is built on top of FMOD Ex, so you get all the power of FMOD Ex as well as a high level interface and a design tool. The Event System is very powerful and reduces the amount of user-side code.

As for the downloads, the API download contains both FMOD Ex and the Event System. If you do upgrade to the Event System, you will need to download FMOD Designer to create test data.

[quote:pye0whsd]For sure, I will try and stuff as much possibly needed functionality in it as possible. [/quote:pye0whsd]
I like your enthusiasm, but it’s important to avoid over-complicating the interface. Since what you’re doing is effectively designing an API it might be worthwhile doing a little background reading. There are plenty of good resources out there, here is a good place to start:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf

  • You must to post comments
0
0

I appreciate the information, I have learned a lot about FMOD since posting this, as I have been tinkering with it almost non stop. I do have a few questions that have popped up though. A couple questions isn’t too shabby considering I have almost finished the ogre fmod wrapper, mostly just trying to perfect the logic behind the design.

After studying all of the example projects, I see there are sounds, sound groups, channels, and channel groups. Right now my design is basically this…

A Singleton class of SoundManager
SoundObject class

SoundManager completely manages all the instances of SoundObject, however I am starting to get a bit confused with how to manage the Channels & Groups. When I call createSound (my own implementation of it, same name) I create the SoundObject instance for it, I store all the necessary information, etc. How should I handle the channel though? Automatically assign it one on creation, and just let it keep using that one until it is removed? The problem I am running into "in my head" is that I have done mods for Valve games for years, and I never had to worry about channels, so this is wear my it has become chaotic for me.

Im going to sleep now, starting to ramble. ๐Ÿ˜€

  • You must to post comments
0
0

I’m not entirely clear about what your "SoundObject" contains. It shouldn’t have an FMOD::Sound instance in it because that would lead to loading the same file multiple times, the FMOD::Sound instances should be shared between "SoundObjects" (when the Sound is opened as sample/compressed sample).

There are 3 types of FMOD::Sound objects:
Sample (decompress the entire file into memory) [good for very short sounds played frequently: footsteps, gun shots, …]
Compressed Sample (load the whole file into memory but don’t decompress it until playback)
Stream (only read small amounts of the file as needed during playback) [good for long sounds played one at a time: music, dialog]

[quote:bpnusalo]How should I handle the channel though? Automatically assign it one on creation, and just let it keep using that one until it is removed? [/quote:bpnusalo]
The channel is the actual playing sound, one FMOD::Sound can be played many times, so each sound object should have a Channel. These channels can go invalid so it’s important to hold a pointer to the parent Sound instance so the channel can be recreated if need be.

-Pete

  • You must to post comments
0
0

Ah this makes a lot more sense now, as I really didn’t understand the concept of the channels being used by FMOD.

So basically a good structure would be

SoundManager* singleton
SoundObject* instances (one for every sound)
Sound* instances which would basically be the channel instances of the sounds playing.

I had looked at a few different sound managers using FMOD and they all did things completely differently from one to the next. I wanted to use a more OOP approach to creating the wrapper so that it will be more versatile.

  • You must to post comments
0
0

[quote:3am52ldp]So basically a good structure would be

SoundManager* singleton
SoundObject* instances (one for every sound)
Sound* instances which would basically be the channel instances of the sounds playing. [/quote:3am52ldp]
Yeah, that’s sounds good.

[quote:3am52ldp]I wanted to use a more OOP approach to creating the wrapper so that it will be more versatile.[/quote:3am52ldp]
Yeah, Ogre is very OO, so it’s good to keep inline with that.

  • You must to post comments
0
0

Hi all,

[quote:2n4tzeqy]1. I think the biggest bang for buck improvement would be updating it to use FMOD Event System.[/quote:2n4tzeqy]

I’m also working on an OO FMOD wrapper which needs to support both FMOD Ex and the Event System.

I had no problem implementing the FMOD Ex part, but the classes I wrote to handle the Event System stuff seem now a little too naive.
I’d love to hear from what others have made to solve things such as event instance stealing, event loading, wave bank management, programmer sounds…
For instance, I’m not sure whether it is recommendable to have a CEvent class to control every aspect/lifetime of an FMOD event or to have CEvent working as a CEventInstance container…

I’d be VERY grateful if anyone could point me in the right direction on how to implement such a wrapper over the Event system.

Thanks in advance,

Juan

  • You must to post comments
0
0

Hi Janko,

[quote:3w4n3avw]For instance, I’m not sure whether it is recommendable to have a CEvent class to control every aspect/lifetime of an FMOD event or to have CEvent working as a CEventInstance container… [/quote:3w4n3avw]
I’m not entirely sure what you’re asking here. If you’re asking whether you could have one object per Event or per event instance, I would definately go with per instance because each instance can have different configurations and generally the user would want to deal with instances.

I think with regard to instance stealing, I think the best method is to have a EventInstance object which has a ‘zombie’ state once stolen. This could just fail silently when operations are called on it because whether the instance is valid is not particularly important on the user side. As far as they care have an instance and they want to set some properties on it.

  • You must to post comments
0
0

Hi Peter,

That little tip was really helpful, so thanks a lot.
I wasn’t sure what to do when the instance was stolen. I had a few different ideas, but guess the easiest is to ‘zombify’ :) my EventInstance object and try to reaquire its FMOD event instance when needed (as stated in the Common Usage section in the docs). User will operate on zombie EventInstance objects as if they were alive.

Regarding the programmer sounds… My first approach was to create separate FSB files per language and then load them through instances of my CSoundGroup class. Then, EventInstance would have a couple methods:
void SetSoundBank( CSoundGroup* pSoundBank );
void SetCurrentProgrammerSound( t_int nSound ) { m_nCurrentSoundIndex = nSound; }
So, when I call EventInstance::Start, the selected sound will be used as the source.

Would it be desirable (or is it a common prectice) to parse the fdp file, so I can somehow map the sound indices with file names (instead of just using the index)? Does anyone have any tips on how to use programmer sounds effectively?

Again, thanks for the quick response.

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.