0
0

the lack of this one feature is the only think keeping me from using fmod, forcing me instead to use BASS.

the problem is that my application is entirely synchronous, heavily componentized, and written in C++. without either a user-defined pointer, or the ability to insert synchronous messages into the main thread’s message queue, there is no safe way to associate my wrapper objects with the callback.

and now that I’m moving over to Mac OS X, and possibly Linux, this irritating lack is becoming a serious problem. it would be great to be able to use fmod, and have one branch for all platforms.

however, then I would need either:

a user-defined pointer associated with a FMUSIC handle.
a user-defined pointer associated with a callback.
a specific platform-specific synch message.

the first two are the ones most compatible with the current API.

just my $0.02 :)

  • You must to post comments
0
0

if you just add a mechanism to associate a user-defined pointer with any given handle, you don’t need to change anything in the callback itself.

something along the lines of:

void* FMUSIC_GetUserPtr(FMUSIC_MODULE *mod);
signed char FMUSIC_SetUserPtr(FMUSIC_MODULE *mod, void *ptr);

and the same for the FSOUND API, if needed. this would be sufficient for my purposes, at least. and with some care, no extra code is necessary to protect against race conditions.

of course, I cannot speak for the rest of the FMOD userbase. anyone else have an opinion?

  • You must to post comments
0
0

well, it’s not that bad. more like one more property among others. the whole FMUSIC API is get/set based anyway.

the pointer in callback solution would be best, of course. but only for me… 😉

  • You must to post comments
0
0

oh, I must have missed that. I’ve never used stream synching.

anyway, I’ll just look forward to 3.61 then :)

and thank you!

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.