0
0

Hi,

I’ve been trying to get the designer API integrated into our sound engine, and I’ve got a whole bunch of issues and questions and feature requests, so I hope you’ll excuse me if this seems somewhat rambling and disjointed.

Lots of little things have been tripping me up, but one thing that I can’t seem to get around is the following:

I set the EventSystem media path to, for example:
c:\game\sounds

Now I want to load a .fev in
c:\game\sounds\DesignerTool

In that directory is the .fev and the .fsb. The .fev loads returning FMOD_OK, and I can then get an EventGroup from there. Then, as soon as I try to either do loadEventData() or getEvent() on that EventGroup, it returns either a FILE_NOT_FOUND, or a FILE_BAD. If I set the media path to c:\game\sounds\Designertool, then it seems to work properly. But I don’t want to do that, because there may be several different directories that contain .fevs that I want to load in addition to that one.

Which brings up another question: if I load two different .fev files with the same Group name (an abberation, but something that might happen nevertheless by accident), what happens when I try to get that group?

Another question: What’s the lifetime of an Event, if it’s never played? During load I cache the indices of the Events so that when it’s time to play them I can call EventGroup::getEventByIndex(). The way that I do that is I call EventGroup::getEvent(), and then Event::getInfo(), and store the resulting index. But now I’ve gotten an Event, is there some cost associated with that?

Feature request: Is it possible to import a .fev and .fsb into a .fdp? Right now our sound designer has gone home and turned off his computer, and he didn’t check in his .fdp or other source files, and I need to fiddle with some settings in the files, which I can’t do without the original source. There’s not even a way to import an existing .fsb or .fev into a new .fdp.

Another feature request: I haven’t checked if the filesystem callbacks work, but would it be possible to have an option to load a .fev/.fsb from memory? Currently our Pak file system only allows me to load an entire file. For regular samples and streams I just give that value with an FMOD_OPEN_MEMORY, then free it for samples, but I see no way to do that with the designer tool stuff.

Another feature request: Can we get an Event::setMute()?

Also, what are these EventCategories? There’s no documentation on them.

I think that’s all of the questions I have for right now. Thanks!

  • Guy
  • You must to post comments
0
0

[quote:20cbny2t]
Quote:
[quote:20cbny2t]
Which brings up another question: if I load two different .fev files with the same Group name (an abberation, but something that might happen nevertheless by accident), what happens when I try to get that group?
[/quote:20cbny2t]

From what i know you can’t load 2 fevs at once yet. It is supposed to be the whole game’s project.
[/quote:20cbny2t]

From what I know we already work with several active projects at the same time and it works fine. ๐Ÿ˜€ I havent tried to use same group names in different projects yet.

  • You must to post comments
0
0

[quote:2dowwg5c]
From what i know you can’t load 2 fevs at once yet. It is supposed to be the whole game’s project.
[/quote:2dowwg5c]
Oh. See, I think that Dave would go insane if he was forced to manage the entire game’s sounds in one file. There’s so many ways he’s going to want to break it up into multiple files: one project per piece of music, one project per monster, one project per level’s ambient sounds, one project for UI sounds, one project per weapon… Being able to load multiple projects would be a great boon to us.

[quote:2dowwg5c]
Thats right. You don’t expect to be able to re-create the .C and .H files from a .exe either, FSB and FEV are the compressed, compiled data.
In fact a lot of stuff that is tool specific is discarded for the fev, because it is supposed to be the stripped down game version of the compiled project. That information can’t be re-created from nothing.
[/quote:2dowwg5c]
That makes sense. I guess I wasn’t thinking of it like that before, but I can see why there’s no import option. ๐Ÿ˜ณ

[quote:2dowwg5c]
You can override the filesystem using EventSystem::getSystemObject and go from there.
[/quote:2dowwg5c]
The problem is exactly that I don’t have any way (currently) of implementing those filesystem callbacks that will work with our filesystem. The way it works right now is that I have to load an entire file into RAM – with regular sounds I just use the FMOD_OPENMEMORY flag, but there’s no such flag for .fev/.fsb files. Is it possible to load these files from memory?

[quote:2dowwg5c]
[quote:2dowwg5c]
Another feature request: Can we get an Event::setMute()?
[/quote:2dowwg5c]
What about setVolume(0.0 or 1.0)? It is the same thing.
[/quote:2dowwg5c]
Well, it’s almost the same thing. It does mean that if any volume changes happen while an event is muted that I’ll have to keep track of them. Still, that’s no so bad, I suppose.

I’ll keep plugging at it. We’re really looking forward to your upcoming music support features. ๐Ÿ˜€

Thanks, Brett!

  • Guy
  • You must to post comments
0
0

[quote:c672m67y]
Brett:
ack no thats totally against the way it is supposed to work.
The whole point is that you are supposed to have 1 project and use -groups- to organize your data. I don’t see how maintaining a whole heap of projects is supposed to be easier than 1 simple project ๐Ÿ˜ฎ
[/quote:c672m67y]

If you want to have several sound designers working at the same time, there needs to be a way to support multiple project file, that are checked in/out from a source control system. We already do it that way, loading severeal project files at a time works fine. Doing it with a global project file would cut productivity down to one per time.

Upcoming categories needs to be project independent, so that the user can create their own categories and tell any event/group from any project file to which categories they belong. It needs to be a m -> n association.

  • You must to post comments
0
0

[quote="MVD":2i4b45o2][quote:2i4b45o2]
Brett:
ack no thats totally against the way it is supposed to work.
The whole point is that you are supposed to have 1 project and use -groups- to organize your data. I don’t see how maintaining a whole heap of projects is supposed to be easier than 1 simple project ๐Ÿ˜ฎ
[/quote:2i4b45o2]

If you want to have several sound designers working at the same time, there needs to be a way to support multiple project file, that are checked in/out from a source control system. We already do it that way, loading severeal project files at a time works fine. Doing it with a global project file would cut productivity down to one per time.

Upcoming categories needs to be project independent, so that the user can create their own categories and tell any event/group from any project file to which categories they belong. It needs to be a m -> n association.[/quote:2i4b45o2]Gotta agree here – revision control support is pretty important. Would it be possible to get some sort of a Visual Studio style layout, so that individual groups are represented by a single file? (Solution -> Project -> Individual File) You could still always have a ‘compiled’ version of the whole thing that’s just one optimized file, but having it split up into pieces would definitely make it easier to manage.

  • You must to post comments
0
0

[quote:13dwkt7t]
Brett:
By the user do you mean the programmer? That is again, against the data driven approach if it is what you mean. The programmer is not supposed to do the work here, only the sound designer is.
[/quote:13dwkt7t]

I ment the user of the tool, so yes the sound designer.
They should be able to create categories, and the game code can query them and use it for internal mixing.

Again, having one [b:13dwkt7t]huge[/b:13dwkt7t] file for all sounds is inefficient and introduces lots of problems when it comes to production. Not only some source-safe system (those designers work with) do not support merging in a good way because their focus is on binary files. Also coding systems do make errors on merging 3 ways especially on xml code.

We strongly suggest that you keep the way it is now, that several files that can be used (and manipulated) independently. If you introduce a higher level of some kind of frame work, its up to you.
Like I said, we do work with different project files already, about 5 right now, growing quickly.

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.