The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
[PATCH] FluidSynth backend for SDL_mixer
James Le Cuirot
Guest

Hello everyone,

Attached is a patch to add a FluidSynth backend to SDL_mixer. This
patch has been some time in the making but I now believe it is finally
ready.

If you want to try it, it requires the latest FluidSynth from
Subversion. The patch was created against the latest SDL_mixer from
Mercurial but you can apply it against 1.2.11 while safely ignoring the
Makefile.in conflict. Don't forget to run ./autogen.sh. I have tested
that it works under 64-bit Linux and have tested that it builds under
32-bit MSVC 2010. I wasn't able to actually run it under Windows due to
audio issues I'm having with QEMU at the moment but I'm confident that
it'll work.

Unlike Timidity, FluidSynth isn't usually distributed with any sounds
so you either have to set the SDL_SOUNDFONTS environment variable to
some path or the game can call Mix_SetSoundFonts. The latter takes
priority but if you want to override it, set SDL_FORCE_SOUNDFONTS to 1.

You probably won't need to but you can specify more than one SoundFont
file at a time, concatenating them with ; on Windows or : on Linux. To
prevent confusion, ; will also work on Linux but it needs to be quoted
on the command line, which is why : is preferred.

Since FluidSynth requires some conditions to be met while Timidity
doesn't, FluidSynth is attempted first. It will fall back to Timidity
if no SoundFonts are requested by either method or if the requested
SoundFont files are not accessible.

Because the backend is determined when Mix_OpenAudio is called,
Mix_SetSoundFonts needs to be called before this. You can call it again
to change the SoundFonts later but by this time, it's too late to fall
back to Timidity so if the given SoundFonts don't work for any reason,
you'll just get silence! I have considered whether it would be better
to determine the backend on each song load instead but there doesn't
seem to be a strong need for it.

Mix_SetSoundFonts (as well as Mix_GetSoundFonts and Mix_EachSoundFont)
are intended to be generic functions in case the other MIDI backends
ever add support for SoundFonts. You can therefore use them without
worrying whether the user has enabled FluidSynth support or not.

Like the other external dependencies, I have made it possible to load
FluidSynth dynamically. I was able to use a macro to greatly shorten
the code needed to do this. It works really well and could be applied
to the other dependencies so take a look.

I have included the necessary changes to the project files in the
VisualC directory but I decided not to pollute the patch with the
FluidSynth DLL and headers so these will need to be added in the same
manner as the other dependencies.

Even though the required FluidSynth code hasn't yet been put into a
release, it should be safe to merge this patch now because configure
specifically checks for the new function (fluid_player_add_mem) that
makes this work.

I think that covers everything. Feedback and suggestions welcome. Smile

Cheers,
James
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
I'm looking at the possibility of bundling SDL_mixer with the commercial
license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!

On Sun, Mar 20, 2011 at 9:55 AM, James Le Cuirot wrote:
Quote:
Hello everyone,

Attached is a patch to add a FluidSynth backend to SDL_mixer. This
patch has been some time in the making but I now believe it is finally
ready.

If you want to try it, it requires the latest FluidSynth from
Subversion. The patch was created against the latest SDL_mixer from
Mercurial but you can apply it against 1.2.11 while safely ignoring the
Makefile.in conflict. Don't forget to run ./autogen.sh. I have tested
that it works under 64-bit Linux and have tested that it builds under
32-bit MSVC 2010. I wasn't able to actually run it under Windows due to
audio issues I'm having with QEMU at the moment but I'm confident that
it'll work.

Unlike Timidity, FluidSynth isn't usually distributed with any sounds
so you either have to set the SDL_SOUNDFONTS environment variable to
some path or the game can call Mix_SetSoundFonts. The latter takes
priority but if you want to override it, set SDL_FORCE_SOUNDFONTS to 1.

You probably won't need to but you can specify more than one SoundFont
file at a time, concatenating them with ; on Windows or : on Linux. To
prevent confusion, ; will also work on Linux but it needs to be quoted
on the command line, which is why : is preferred.

Since FluidSynth requires some conditions to be met while Timidity
doesn't, FluidSynth is attempted first. It will fall back to Timidity
if no SoundFonts are requested by either method or if the requested
SoundFont files are not accessible.

Because the backend is determined when Mix_OpenAudio is called,
Mix_SetSoundFonts needs to be called before this. You can call it again
to change the SoundFonts later but by this time, it's too late to fall
back to Timidity so if the given SoundFonts don't work for any reason,
you'll just get silence! I have considered whether it would be better
to determine the backend on each song load instead but there doesn't
seem to be a strong need for it.

Mix_SetSoundFonts (as well as Mix_GetSoundFonts and Mix_EachSoundFont)
are intended to be generic functions in case the other MIDI backends
ever add support for SoundFonts. You can therefore use them without
worrying whether the user has enabled FluidSynth support or not.

Like the other external dependencies, I have made it possible to load
FluidSynth dynamically. I was able to use a macro to greatly shorten
the code needed to do this. It works really well and could be applied
to the other dependencies so take a look.

I have included the necessary changes to the project files in the
VisualC directory but I decided not to pollute the patch with the
FluidSynth DLL and headers so these will need to be added in the same
manner as the other dependencies.

Even though the required FluidSynth code hasn't yet been put into a
release, it should be safe to merge this patch now because configure
specifically checks for the new function (fluid_player_add_mem) that
makes this work.

I think that covers everything. Feedback and suggestions welcome. Smile

Cheers,
James
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
[PATCH] FluidSynth backend for SDL_mixer
James Le Cuirot
Guest

On Mon, 21 Mar 2011 16:56:18 -0700
Sam Lantinga wrote:

Quote:
I'm looking at the possibility of bundling SDL_mixer with the
commercial license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!

I'm not a huge fan of such licenses since the LGPL seems like a fair
compromise to me but I'm guessing that not giving you permission would
make things awkward. Then again, some of the native MIDI code is
GPL-only so this wouldn't be the only exception. Even though this is
probably my most significant open source contribution to date, I
suppose it's not that big in the grand scheme of things. Thinking of
the bigger picture, I would like to see SDL more widely adopted.
Chances are that a big commercial project wouldn't even use MIDI
anyway. Soooo... yeah, alright. Sorry for the brain dump. Wink

James
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
Okay, thanks!

On Mon, Mar 21, 2011 at 5:41 PM, James Le Cuirot wrote:
Quote:
On Mon, 21 Mar 2011 16:56:18 -0700
Sam Lantinga wrote:

Quote:
I'm looking at the possibility of bundling SDL_mixer with the
commercial license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!


I'm not a huge fan of such licenses since the LGPL seems like a fair
compromise to me but I'm guessing that not giving you permission would
make things awkward. Then again, some of the native MIDI code is
GPL-only so this wouldn't be the only exception. Even though this is
probably my most significant open source contribution to date, I
suppose it's not that big in the grand scheme of things. Thinking of
the bigger picture, I would like to see SDL more widely adopted.
Chances are that a big commercial project wouldn't even use MIDI
anyway. Soooo... yeah, alright. Sorry for the brain dump. Wink


James
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
[PATCH] FluidSynth backend for SDL_mixer
Mason Wheeler
Guest

Quote:
----- Original Message ----

Quote:
From: James Le Cuirot
Subject: Re: [SDL] [PATCH] FluidSynth backend for SDL_mixer

On Mon, 21 Mar 2011 16:56:18 -0700
Sam Lantinga wrote:

Quote:
I'm looking at the possibility of bundling SDL_mixer with the
commercial license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_mixer
under both the LGPL and a closed-source commercial license?

Thanks!

I'm not a huge fan of such licenses since the LGPL seems like a fair
compromise to me but I'm guessing that not giving you permission would
make things awkward. Then again, some of the native MIDI code is
GPL-only so this wouldn't be the only exception. Even though this is
probably my most significant open source contribution to date, I
suppose it's not that big in the grand scheme of things. Thinking of
the bigger picture, I would like to see SDL more widely adopted.
Chances are that a big commercial project wouldn't even use MIDI
anyway. Soooo... yeah, alright. Sorry for the brain dump. Wink

It's for the iPhone devs. Apple doesn't let you use dynamically-linked
libraries for iOS, and statically linking a LGPL library can be done but
it's more trouble than it's worth, so another solution is required.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
Vittorio G.
Guest

On Tue, Mar 22, 2011 at 3:08 AM, Mason Wheeler wrote:
Quote:

It's for the iPhone devs.  Apple doesn't let you use dynamically-linked
libraries for iOS, and statically linking a LGPL library can be done but
it's more trouble than it's worth, so another solution is required.

trouble as in releasing the source code you are linking to? i see only
benefits from that Smile
Vittorio
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
James Le Cuirot
Guest

On Mon, 21 Mar 2011 19:08:48 -0700 (PDT)
Mason Wheeler wrote:

Quote:
It's for the iPhone devs. Apple doesn't let you use
dynamically-linked libraries for iOS, and statically linking a LGPL
library can be done but it's more trouble than it's worth, so another
solution is required.

Fair enough. At least I know who to blame now. Wink
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
Gregory Smith
Guest

On Tue, 22 Mar 2011, Vittorio G. wrote:

Quote:
On Tue, Mar 22, 2011 at 3:08 AM, Mason Wheeler wrote:
Quote:

It's for the iPhone devs.  Apple doesn't let you use dynamically-linked
libraries for iOS, and statically linking a LGPL library can be done but
it's more trouble than it's worth, so another solution is required.

trouble as in releasing the source code you are linking to? i see only
benefits from that Smile

Ordinarily, you don't even need to do that with LGPL--a linkable object
file is enough. Unfortunately, none of the LGPL solutions work in this
case, since the app store imposes restrictions on redistribution which are
incompatible with the LGPL.

That said, it's certainly possible to conceive of an LGPL-like license
with a specific exception for app store distribution. A closed-source
license is not the only solution.

I say this for the benefit of other future library authors, of course--Sam
has already chosen the license for SDL 1.3 and the only decision
contributors have to make is whether they're comfortable with it.

Gregory
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
Bill Kelly
Guest

Gregory Smith wrote:
Quote:

That said, it's certainly possible to conceive of an LGPL-like license
with a specific exception for app store distribution. A closed-source
license is not the only solution.

If I recall correctly, the MPL is similar to the LGPL in that
one must share one's modifications to the source code, but
without the LGPL's constraints on mixing closed source and
static linking.

( http://www.mozilla.org/MPL/mpl-faq.html )


Regards,

Bill

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[PATCH] FluidSynth backend for SDL_mixer
Mason Wheeler
Guest

Quote:
----- Original Message ----

Quote:
From: Bill Kelly
Subject: Re: [SDL] [PATCH] FluidSynth backend for SDL_mixer


Gregory Smith wrote:
Quote:

That said, it's certainly possible to conceive of an LGPL-like license
with a specific exception for app store distribution. A closed-source
license is not the only solution.

If I recall correctly, the MPL is similar to the LGPL in that
one must share one's modifications to the source code, but
without the LGPL's constraints on mixing closed source and
static linking.

( http://www.mozilla.org/MPL/mpl-faq.html )

Yep. I personally consider the MPL a much more useful license for
open-source projects than the GPL.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org