Re: [fluid-dev] Fluidsynth changes

[Josh Green]

Hello Miguel,

On Fri, 2007-04-20 at 00:31 +0200, Miguel Lobo 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 style.
>       * 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. 
> 


It sounds like just the kind of overhaul that FluidSynth needs.  There
are a couple things that I'm unsure of though, including:

There are some programs (such as my own software Swami) which are C
based and use FluidSynth.  I'm not apposed to moving FluidSynth to C++
(the original author Peter Hanappe had also thought about this), but I'd
like to investigate what options are available for keeping some sort of
interface to C based programs.  Swami does all its own instrument
management and loads instruments via the SoundFont loader API, which
makes it flexible enough to load other types of instrument formats as
well (albeit with SoundFont centric parameters).  I've often kicked
around the idea of using libInstPatch directly in FluidSynth for adding
instrument management for other formats, but decided this wasn't
absolutely necessary, since libswami could itself be used for that.  It
might be interesting to revisit this idea though.

I'm not very familiar with QMake myself.  I'd need to do some more
research to get a better idea if it seems to fit well with the project.
What other projects are using QMake, besides QT based applications?  I
hope the install of QMake doesn't necessitate the installation of QT4.

Once again, I do want to express that what you are working on does sound
like a good direction, I just don't want to leave other applications
behind.  The original intent of FluidSynth was and still is to provide a
low level API that doesn't restrict it to only certain languages.  That
doesn't mean the core of it can't be written in something higher level I
suppose though.  I'm no C++ expert, so I imagine there are many others
that are better versed in the answers to this question.

> 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: 
> 
> http://www.4shared.com/dir/2512039/1ed7a045/sharing.html
> 
> 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!
> 
> Regards,
> Miguel
> 

Cheers!
        Josh