0
0

Hi all,

I’ve got a legit question this time ๐Ÿ˜› I was playing with creating parameterized events in Designer and playing them back in Ex, but I’ve got a weird bug in which the parameter with a velocity will jump to its max value at the first playback.

Subsequent calls to FMOD::Event->start() work fine. But, if I retrieve the event again with FMOD::EventGroup->getEvent() it gets reset again so when I call FMOD::Event->start() that parameter jumps to its max value again.

The desired effect is a crossfade between two sound defs over time. This will happen if you hit ‘r’ to repeat the previously triggered event, but all you hear after playing it back the for the first time is the second sound def. I also tried manually setting the parameter to 0 or 0.0001 before first calling start(), but no dice. I’m also calling FMOD::EventGroup->loadEventData() just in case. Is there another initialization step or something I’m missing to get this working properly?

I’ve also used two approaches in the Designer tool, two sound defs in the same layer overlapping so an automatic crossfade is created, and adding a second layer and manually drawing in the crossfade with the volume effect on both layers, same thing happens with both approaches.

Here’s a zip with the FDP, the WAVs, precompiled FSB and FEV, a VS 08 project, and crappy little scripts to compile and run on Mac (I apologize for the clunkiness for anybody trying it on Mac, conio.h was easier to toss in than ncurses/pdcurses):
[url:5vu3wz1d]http://dump.bartnett.com/files/FMODeventTest.zip[/url:5vu3wz1d]

Here was the code I had temporarily stuck in the triggerEvent() function just before fmod_event->start() was called (this isn’t in the zip file):

[code:5vu3wz1d]if (paramCount > 0)
{
FMOD::EventParameter *param;
fmod_event->getParameter(0, &param);
param->setValue(0.0001);
}[/code:5vu3wz1d]

[EDIT] Just noticed if you run on Mac you won’t see the input once you hit ‘e’ to trigger a new event . . . oh well, this is just a quick test. If you carefully type "deathspawn" it will still work.

Thanks!

Michael

  • You must to post comments
0
0

Has anyone had a chance to try out the code I posted? Different permutations of cacheEvents set to true or false and loading a group versus loading individual events and manually setting the parameter, or triggering and immediately stopping the event are proving unsuccessful.

I’m also realizing that the FMOD Designer forum seems to have some programming stuff on it. I initially thought it was exclusively for the designer application. Would this thread be better suited on that board?

  • You must to post comments
0
0

Hi BearCDP, you problem is occurring because of the blocking nature of the console IO. You are dillegently calling EventSystem::update in your main loop, but there is no way to call EventSystem::update while waiting for std::cin. The problem is that the EventSystem calculates the time delta based on when it was last called so this is basically what is happening:

eventSystem->update() (record time)
std::cin (2 seconds or more)
event->start()
eventSystem->update() (calculate time delta (2 seconds or more) and update velocity parameter)

Adding an EventSystem::update before calling Event::start() seems to fix this specific problem but this is not recommended. You [i:19h2wbvh]should[/i:19h2wbvh] be calling EventSystem::update regularly and not blocking the FMOD thread for IO.
[code:19h2wbvh]void triggerEvent(const char *eventName)
{
fmod_result = eventGroup->getEvent(eventName, FMOD_EVENT_DEFAULT, &fmod_event);
CheckErr_FMOD(fmod_result);
int paramCount = 0;
fmod_event->getNumParameters(&paramCount);
cout << "Event has " << paramCount << " parameters." << endl;
eventSystem->update();
fmod_event->start();
}[/code:19h2wbvh]

  • You must to post comments
0
0

That was it! If I’m gonna test like this, I suppose I’d better write my own asynchronous input function.

Thanks so much for your help, Pete. Your explanation of how EventSystem::update() works really helps. And, this was my first time mixing terminal output with a library that operates in realtime (Forms and XNA really keep your butt covered), so it could’ve been ages before I realized that.

Cheers! ๐Ÿ˜€

  • You must to post comments
0
0

Glad to have helped. :) I think asynchornous input would be a good solution.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.