[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Fluidsynth changes

From: Marcus Planet
Subject: Re: [fluid-dev] Fluidsynth changes
Date: Thu, 19 Apr 2007 23:39:47 -0400

Hello Miguel and thank you for your excellent work with Fluidsynth.

As a novice programmer who is making use of the Fluidsynth libs in a
new program, my reaction is mostly positive to these changes.  The
only concerns I have are 1) to be sure that the move from C to C++ is
entirely worthwhile.  You mention that C++ will promote code reuse and
I'm sure that is true.   I do believe, however, that a C++ Fluidsynth
may not be quite as easy to absorb and apply as a C Fluidsynth. 2) I
hope that if the "Qt way" is embraced by Fluidsynth that there will
always be a great amount of freely available documentation and other
information about things Qt.  In looking at Trolltech's web presence
I'm a bit suspicious of their desire to fully and freely support the
actions of independent and indigent programmers like myself.

Mostly, though, I realize that the Qt approach is superior to
competing approaches.  It seems more powerful and it seems to work


On 4/19/07, Miguel Lobo <address@hidden> wrote:
Hi list,

Since there's been a surge in the activity of this list recently, I thought
I'd let you know about some work I've been doing on Fluidsynth, although it
is by no means finished.

Now, the changes I've done are of the kind that flamewars are sometimes
started over, so let me begin with a little disclaimer.  I've done these
changes because I'm planning to add some features later, and I wanted to
have a code base to work with that is as solid and maintainable as possible.
 Now I realize that "solid" and "maintainable" are often subjective terms,
so it is quite possible that some people will think my changes are a
terrible idea.  I accept that; reasonable people can disagree.  Also, I mean
no disrespect to previous Fluidsynth authors; I've just tried to improve on
their already excellent work.

Well, after the somewhat dramatic preface, I hope the change list itself is
not too underwhelming :)

Translating from C to C++, using classes and templates to increase code
reuse where possible.
 Changing the naming conventions / indentations / so on to follow Qt code
Changing the build infrastructure from autotools to QMake, which is IMO
simpler and provides support for MSVC.
Splitting the Fluidsynth library into several "components" (again, inspired
by Qt4).  At the moment the components I've thought of are:
A simple "core" component, to which "Fluidsynth events" are sent, and from
which audio data can be read.  This component is passive (i.e. it is called
by external code but it does not do callbacks), and has no concept of "real
time"; its only concept of time is provided by the reading of audio data
from the output end.
A "drivers" component, which can act as a gateway between event sources such
as the Alsa Sequencer or WinMidi and the core component, on the one hand,
and between the core component and audio sinks such as Alsa PCM or
Directsound, on the other hand.
Removing the parts of Fluidsynth that don't fit into that vision, such as
much of the user interaction stuff (command handlers and so on), the midi
router, etc.For the moment I've half-jokingly called this project FSNG, for
"FluidSynth New Generation", but this is just a temporary name.  If people
here think my approach is suitable for the future of Fluidsynth we can
rename my project FluidSynth 2.  If, on the other hand, people think that
this is too big a departure from the Fluidsynth roadmap or just undesirable
for other reasons, I'll change the name to something not Fluidsynth related
and I will develop it independently.  Either option is fine with me.

Finally, event though as I said before the code is far from finished, it
actually works currently, albeit with not much functionality.  For the
moment there is a midi player utility that can read SoundFonts and send the
synthesized result to ALSA or DirectSound.  I've tested that the code builds
and works under Linux, under Windows XP using MinGW, and under Windows XP
using MSVC.  If anyone wants to have a look, I've uploaded the code here:


Basic build instructions (you'll need QMake from Qt4)

Under Linux, just run "qmake" and then "make".
Under Windows using MinGW, run "qmake" and then "mingw32-make SHELL=cmd".
You need MSYS installed and in your PATH, and the appropriate DirectSound
SDK directories must be in your INCLUDE and LIB environment variables.
Under Windows using MSVC, the only difference with the above is that you
must run "qmake -spec win32-msvc" and then "nmake".  Your INCLUDE and LIB
environment variables must also be set correctly.
As I said, things are far from polished yet, so if anyone tries these
instructions and finds some problem please let me know.

Looking forward to everybody's comments!


fluid-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]