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.

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. :)

Cheers,
James
_______________________________________________
SDL mailing list

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

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:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks

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


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. ;)

James
_______________________________________________
SDL mailing list

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

Okay, thanks!

On Mon, Mar 21, 2011 at 5:41 PM, James Le Cuirot wrote:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks

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

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

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

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

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


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

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

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


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

Gregory Smith wrote:

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

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