1) Random stereo/surround pan
2) Random spatial offset
3) Automated repeat times
4) Automated deviations for random pitch/volume
5) Global envelopes. Instead of adding the same envelope to all layers it could be added globally for the event.
6) Minimize/Restore/Maximize layers in event view
- Frohagen asked 12 years ago
[quote="andrew":11221oax]We would still need to add a nonblocking flag for EventSystem::load on our end in order to have nonblocking project loads.[/quote:11221oax]
Is this going to happen? Since FMOD is not threadsafe, loading FEV files must be done from the main thread which can cause hangs when an FEV is loaded during game-play.
- droberts answered 11 years ago
We solve this by loading all .fevs at startup. I know it’s not the best of solutions but it works for us, at least so far.
I have been working quite alot with FMOD and its resource management and even though it might have its points internally its one of the hardest and most complicated systems I have tried to integrate with an existing resource system. As one big wish right now I would like to see some enhancements here like for instance options for loading everything from memory and non-blocking. I know this isn’t the case right now for .fevs.
- Frohagen answered 11 years ago
Great. As a programmer I would like to add one thing to the list which actually is of very great importance to us and that is a way of controlling data loading. I know that you have massive support in our classic API for this where it’s even possible to handle streaming of audio data. Now, the later isn’t really top priority but to be able to controll loading of data definatelly is in order to achieve optimal disc performance, mostly with respect to seeks. When it comes to streaming it would be nice if we could control when FMOD is allowed to access disc so we can sync with our data streamer.
You can already use EventSystem::getSystemObject() and then System::setFileSystem() to make the eventsystem use your file routines. We’ll also be adding a "load fsb" callback very soon which gives the programmer control of loading the fsb’s that the eventsystem requests. This way you can load the fsb’s however you like, precache them, load them from memory etc.
That’s pretty much what I wanted to hear I guess this means that for instance loading a project which today is blocking could be made non-blocking in our code provided that the filesystem we use will do the magic and that we add some wrapper code that handle that the project can’t be used before loading is complete.
So if I call EventGroup::loadEventData I will only get a callback for readnig fsb’s, right? Would it be possible in the future to get callbacks for all data loading? What about controlling streaming? Can disc access be switched thru some callback or how do we do that?
[quote:2el9mwhm]So if I call EventGroup::loadEventData I will only get a callback for readnig fsb’s, right?[/quote:2el9mwhm]
Yes, when we implement that callback.
[quote:2el9mwhm]Would it be possible in the future to get callbacks for all data loading?[/quote:2el9mwhm]
If you mean a callback for .fev as well as .fsb the answer is maybe. We’d have to implement a nonblocking flag for EventSystem::load in order to make this possible.
[quote:2el9mwhm]What about controlling streaming? Can disc access be switched thru some callback or how do we do that?[/quote:2el9mwhm]
You can already use EventSystem::getSystemObject() and then System::setFileSystem() to make the eventsystem use your file routines.
So, right now if I use System::setFileSystem() to route all data loading to our routines then in the case of FMOD designer I won’t get any callbacks at all (apart from data streaming) until you have implemented support for this, right? When do you plan on implementing this?
No, System::setFileSystem() will catch all FMOD Ex and FMOD EventSystem disk accesses. This is implemented in the current version.
The fsb callback that I mentioned previously is something completely different than just overriding the filesystem using System::setFileSystem() and it is not implemented yet. We’re planning to have it implemented in the next couple of weeks.
To clarify, System::setFileSystem() is a low-level function that overrides ALL file operations. The "load fsb" callback will be a high-level callback that the user can register with the EventSystem. The EventSystem will call the callback with an fsb filename when it wants to load that fsb – the user can load that fsb however he likes – and then the user passes a pointer to the loaded fsb back to the EventSystem.
Sorry if I haven’t been clearer previously.
Thanks for clarifying the file i/o matters. I think I know what you mean now. When you add that loading-fsbs-seperatly function please make sure that it notifies the events that uses the sampledata so they can release their resources. In previous API’s I have worked with this hasn’t been very stable and has always caused crashes and I just don’t see why it has to be that way.
Please login first to submit.