[fluid-dev] Re : Re: FluidSynth and glib

Hello everyone,

I'm the creator of a game engine project which too relies on fluidsynth
for handling midi sound rendering. From what I have gathered, my use of

the library is similar in nature to that of ScummVM, because I only feed

already parsed events into a synth object, and call synth_write to fetch

the rendered samples into my buffer, which are then fed into the common

audio pipeline (ie. fluidsynth interaction ends at this point). On the side

of fluidsynth, there is theoretically no threading needed for just this rendering.

From what I can tell, all the threading related glib usage of fluidsynth exists

due to the code for running an actual "midi server", which continually accepts

and renders events, and then feeds them into self-written audio backends

in a threaded fashion. Only data structures like hashes are used for actual
rendering purposes.

I'm not super familiar with the codebase of fluidsynth, but would it perhaps

be feasible to separate the sample rendering code out into it's own,

almost glib-free sublibrary, which the rest of the codebase then uses?

I think this way, both my engine and ScummVM could use only this

sublibrary, and getting around the use of glib data structures should be

a lot easier since they aren't platform-dependent.

Currently, I always end up using an old fluidsynth version which predates

the introduction of the glib dependency precisely because it's such a
headache to build on eg. Win32 platforms.

Thanks,

Jonas

2016-01-14 0:32 GMT+01:00 Element Green <address@hidden>:

Indeed. Probably the easiest would be to just lift the related bits from glib itself.

Best regards,

Element

On Wed, Jan 13, 2016 at 4:29 PM, Ryan Gonzalez <address@hidden> wrote:
May I try? :D

Pretty much everything outside of threading is really trivial. The wiki says the supported platforms are Windows, OSX, and Linux, and that it runs under Solaris and OS/2 but they aren't officially supported.

For atomics, glib seems to use GCC's C++11-style atomics. when it can, then it falls back to either GCC/Clang's built-in __sync atomic operations or Windows's atomic API.

For normal threads, glib uses pthreads on Posix and Windows threads on...Windows.

Maybe I'm just super nerdy, but this seems totally doable. ;)

On Wed, Jan 13, 2016 at 5:06 PM, Element Green <address@hidden> wrote:
I think the ticket system on SourceForge would be the best way to submit this:
https://sourceforge.net/p/fluidsynth/tickets/

Indeed, there isn't a lot of stuff that needs to be implemented to remove glib as a dependency, for a single platform/architecture. Doing this in a clean and portable fashion however, leads one back to glib. So the way I could see this working would be to have native support for certain key architectures which gets optionally selected at compile time which causes a platform specific header and C file to be built (the stuff in fluid_sys.[ch]) which supplies the needed macros and functions. In order to do things properly, threading APIs like pthreads or Windows related thread functions would need to be used (depending on the platform). Some of the atomic operations may require assembler (a lot of this can probably get lifted from glib), which ends up being compiler specific. It may simplify things to only have libfluidsynth get built in these cases and leave out the fluidsynth executable. That may cut down on some of the platform support that needs to be implemented.

I'm not really available at this time to assist with any of this, so hopefully some other developer will step up and help integrate such patches.

Best regards,

Element

On Wed, Jan 13, 2016 at 2:06 PM, Ryan Gonzalez <address@hidden> wrote:
Well, the majority of g_* are wrapped with macros anyway, so it wouldn't be a major issue.

Would the developers of Fluidsynth be OK if I sent a series of patches to this list that slowly eliminated the need for glib? Unless you have another way of handling contributions or something....

On Wed, Jan 13, 2016 at 2:33 PM, Kjetil Matheussen <address@hidden> wrote:

On Wed, Jan 13, 2016 at 9:28 PM, Ryan Gonzalez <address@hidden> wrote:

Similar things for the rest of them. This doesn't seem TOO bad...

Maybe it would be a good idea to just implement the necessary
"g_"* functions for the needed platforms instead of creating a new API
doing all of these things?

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.
http://kirbyfan64.github.io/

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.
http://kirbyfan64.github.io/

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

From:	CERESA Jean-Jacques ENAC/ENAC
Subject:	[fluid-dev] Re : Re: FluidSynth and glib
Date:	Thu, 21 Jan 2016 13:54:42 +0100