0
0

Our sound designer wants to be able to create an Event in Designer and have access to its properties in our tools so he can add several copies of the Event in the world that perhaps have different rolloffs, cone angles etc. but only have to create one Event in Designer. He doesn’t want to duplicate the Event in Designer or use the Template feature because that still requires creating lots of Events. In order to do this I need access to those properties but Event does not expose them. If they are specified on a per Event basis in the fdp and fev files there must be some way for me to do this. Can these accessors be added to Event? I do not think this breaks the data-driven design of the event system; it’s just shifting the burden from FMOD to us and it would still just be an option. I suppose I could call Event::getChannelGroup and iterate over all of the Channels setting the values but this seems tedious. Or is my thinking all wrong and do you intend for Channles to be the API for the properties listed in the Events tab. If so, would it make sense to add such accessors to the ChannelGroup interface? Please advise.
Thanks.

  • You must to post comments
0
0

This problem is something I’d just noticed too, for the same reasons as the guys above i.e. I want (generally) to have a single event created by the sound designer for a specific purpose, but when placing it in a level using the editor, I want the level designer to be able to tweak specific properties (within defined limits) so that they’re fundamentally using the same event, but with slight variations in their instances so that they fit where theyr’e being place in the level better e.g. changing the min/max distance or the 3D cone.

This matches the Channel structure really, and I can see how there might be problems in applying it to multi-layer multi-sound events, but the only alternative I see is to create individual events for the different settings I’d need and expect the level designer to pick the right one in the tool – something that would balloon out of control and become prone to errors. If I had to do that, then I’d think it was probably easier ditching the Event system for those types of sounds, but that something I’d be loathe to do. The need and interface to change these kind of properties (min/max distance and cone) doesn’t really seem that different from setting the 3D position for 2 instances of the same event using Event::set3DAttributes.

  • You must to post comments
0
0

You can’t just iterate through channels in an event channelgroup because they have none. An event channelgroup is the parent channelgroup of nested layer channelgroups and sounddef overlap groups. You could recursively iterate through subchannelgroups to burrow all the way down to channels but it wouldn’t be very efficient.

The only reason we actually let people get access to the channelgroup of an event is so they can do ChannelGroup::addDSP because there isnt a good concept of adding effects to whole events or groups of events yet (that is coming very soon with the new ‘effect event’ feature)

It does break the data driven philosophy, because nothing is data driven at all if you’re tweaking all this stuff in code. It is the opposite of data driven, and you’d never be able to do things like use fmod’s live network auditioning/mixing/tweaking feature which is supposed to be in the sound designers domain. That issue is what we are trying to avoid with this interface.

The idea is, if something is inneficient to do in fmod designer, then ask us what feature you would like that would make the sound designer’s life easier, not how to hack into the low level stuff.

  • You must to post comments
0
0

crouton: I’m not sure if you were adding anything there or reinforcing what has already been said, but thats already what has been discussed and addressed here with the addition of the setProperty function.

lljudas: We do have network tweaking and adjusting already. Just use fmod_event_net. You can type in the IP address of the game, and adjust all your event properties while the game is running, using fmod designer.

We have a ‘dsp monitor’ program that we use internally, you can connect to an app via tcpip and watch the dsp tree graphically updating in realtime, but its mainly for our debugging purposes, and while interesting to end users isnt really needed I think.

  • You must to post comments
0
0

[quote="brett":1o0ufnon]It does break the data driven philosophy, because nothing is data driven at all if you’re tweaking all this stuff in code. It is the opposite of data driven, and you’d never be able to do things like use fmod’s live network auditioning/mixing/tweaking feature which is supposed to be in the sound designers domain. That issue is what we are trying to avoid with this interface.[/quote:1o0ufnon]

Hey Brett –

I’m going to disagree with this statement and I’ll give some specific reasons why. What we are trying to do is use the designer tool in conjunction with our own inhouse toolsuite. In this particular example I’m talking about ambient sounds.

When placing positional ambient sounds in a level, the speaker-entity count can easily reach to the multiple hundreds. Within these multiple hundreds of speakers, the sound designer (me) will recycle sounds (events) multiple times but with varying min/max falloffs, etc., depending on the level structure that the game is providing.

Having the ability to do this while I work instead of having to make a separate event in designer, rebuild, and test, only to see that I need to make additional changes is very inefficient. I’m wanting a way to use the designer settings as a "default" but be able to adjust the min/max distances, etc. within our own toolsuite and not have to make hundreds of events in designer that I would have to constantly recompile to make sure work.

So, this kind of ability would remain in my hands in terms of creative control. I just need the ability exposed through the API. This is a common thing in AAA games and something that I’ve been working with for a number of years now.

Thanks a lot and great work on Fmod, I’m having fun! :)

  • You must to post comments
0
0

I’ll definatelly look into the network thingie since that sounds really usefull. Debugging DSP’s might not be very usefull in an every-day scenario but I bet there are times when the end user would like any kind of debugging tool to help explain weird behaviours. I’ve been there before both with my own code and other middlewares.

  • You must to post comments
0
0

This is a really good point and I think that we would be interested in such functionallity as well in the future. Still, I don’t think the solution is to open up the data-driven interface but rather to provide a seperate SDK to the designer tool that lets the programmer implement the fmod designer authoring in any tool. I know that gameCODA used to have this for working against their authoring tool in 3dstudio and maya and I don’t think it would be that hard to make something similar with FMOD designer. It would take time to develop yes but it would be really usefull. To begin with it could be very restricted to like tweaking spatial properties. It could be a project that grows with time but quite soon is usable. What do you think?

  • You must to post comments
0
0

Brett, do you know what the time frame might be for adding the Event::setProperty function? Next update maybe? A setPropertyByIndex would be great as well since it would be slightly faster.
Thanks.

  • You must to post comments
0
0

[quote="Ljudas":1mju59zq]Still, I don’t think the solution is to open up the data-driven interface but rather to provide a seperate SDK to the designer tool that lets the programmer implement the fmod designer authoring in any tool.[/quote:1mju59zq]

I like this but I think the problem remains that you will be creating new Events templated off of a single Event that will need to be managed. Or am I misunderstanding you? Suppose you edit the FDP file in your in-house tool. Whether in Designer or in an in-house tool, editing the FDP file to vary an Event will still create new Events, which will be in your project and present in Designer the next time you open it. This would pollute the project file with many many duplicate Events varied only by settings such as min/max distance, fall-off type, etc. I suppose with proper organization a sound designer could manage this. After all, this is the intent of the template option in Designer.

Some important items for this to work immediately come to mind:

1) Real-time auditioning of properties so that you do not have to rebuild your FEV every time you change something. I know this works for some things but you can not test 3D parameters in Designer which you would need for an in-house tool.
2) The ability to prepopulate the sound definitions/EventParameters of a "new" event templated off of another with those of the template. Most of the trouble in creating Events is getting the sound definitions and the EventParameters right, so templating this would be important.
3) The ability to manage the EventGroup hierarchy to keep things organized.

There may be more but these are the most obvious ones that come to mind. Also, I believe none of these issues need be dealt with if the properties were exposed in the Event. However, I agree that creating a new API would be the correct way to handle it.

Please respond with thoughts or criticism because I think this is an important feature.

Many thanks.

  • You must to post comments
0
0

We will probably put it in for tommorow’s release but you will have to use the experimental/dev branch as it is a new feature and we’re not adding features to the stable branch.

  • You must to post comments
0
0

Is it even possible in Fmod to have multiple instances of an event, each playing with different 3D properties (other than location/orientation)?

Which event properties support unique values per event instance and which properties are shared for all instances of the event?

For example, multiple event instances can all have unique user property parameter values, but are ALL event properties changeable on a per-instance basis?

I too would like our game tools to allow each instance of a 3D event to have different sound cone angles, distance min/max, and outside volume, edited by a slick 3d widget in the game editor view.

The game’s sound emitter objects would store these per instance values for 3D properties and apply them to each instance of an Fmod event upon creation in the game.

Is support for this already in the Fmod API or is that what this thread is asking for?

cheers
-jason

  • You must to post comments
0
0

I’ve just added Event::setProperty and Event::setPropertyByIndex for our next release.

  • You must to post comments
0
0

[quote="jcobb":if0ahmb4]I too would like our game tools to allow each instance of a 3D event to have different sound cone angles, distance min/max, and outside volume, edited by a slick 3d widget in the game editor view.[/quote:if0ahmb4]
Brett, a widget can wait as far as I am concerned. I am just asking for an interface to be exposed. I can implement the widget for our sound designer for now.

[quote:if0ahmb4]
Is support for this already in the Fmod API or is that what this thread is asking for?[/quote:if0ahmb4]
No, it’s not. That’s what this thread is asking for. I am glad to see there is so much interest and that we’re not crazy (or at least we’re not alone in our craziness). :)

  • You must to post comments
0
0

I see what you mean now, as using a tool the level designer wants to be able to place a sound and specify its audible sphere graphically. We were just playing with the torque editor and realized that.

I think we can just add a set function to compiment the get function for now, so that if you spawn multiple instances inside your editor (you will have to do this, you cant have multiple different settings for the main event), so as in the editor, if the game spawns an object, it would simply call EventGroup::getEvent to get an instance and Event::setProperty anyway, so it would work fine.

The other option is to integrate fmod into the various editors, but then we’d be supporting a lot of different engines, and can’t account for in house engines/editors.

  • You must to post comments
0
0

[quote="droberts":2beur6sy]
Brett, a widget can wait as far as I am concerned. I am just asking for an interface to be exposed. I can implement the widget for our sound designer for now.
[/quote:2beur6sy]

To clairify, I was not asking for a 3D widget in fmod, I want the ability to make one in our game tools, ergo the need for the api.

  • You must to post comments
0
0

[quote="brett":11f9bmrb]I see what you mean now, as using a tool the level designer wants to be able to place a sound and specify its audible sphere graphically.[/quote:11f9bmrb]
That is one example. Cone angle would be another.

[quote="brett":11f9bmrb](you will have to do this, you cant have multiple different settings for the main event)[/quote:11f9bmrb]
This is exactly what we want. We can set the appropriate instance number simply with max playbacks in the settings of the original event.

[quote="brett":11f9bmrb]so as in the editor, if the game spawns an object, it would simply call EventGroup::getEvent to get an instance and Event::setProperty anyway, so it would work fine.[/quote:11f9bmrb]
Sweet!

[quote="brett":11f9bmrb]
The other option is to integrate fmod into the various editors, but then we’d be supporting a lot of different engines, and can’t account for in house engines/editors.[/quote:11f9bmrb]
I’m a little confused by what you’re saying here because effectively what we will be doing IS integrating FMOD into our editor by basically wrapping Event::setProperty calls. Certainly it’s up to us to do this; all we need from FMOD is the interface. Or did you mean something else?

This is great. I will eagerly await this ability.
Thanks!

  • You must to post comments
0
0

Havoc has a tool that you can hook up with your game/editor and monitor all kinds of things. A really, really, cool thing would be if something similar could be done with FMOD. That, is FMOD will check for a connecting app no matter if you are running the game in debug, release or on a console. When you hook up your tool you suddenly are able to monitor/edit all FMOD sounds in realtime. Another similar app would be microsofts PIX. I do think that the sdk thingie is eaiser to accomplish and to start with more usefull but in the end an app such as this would be really nice as well. You need to hire more people :)

  • You must to post comments
Showing 16 results
Your Answer

Please first to submit.