Re: [fluid-dev] Fluidsynth changes

[Josh Green]

On Fri, 2007-04-20 at 21:22 +0200, Miguel Lobo wrote:

> Ok, thanks.  I don't know to which degree libInstPatch makes other
> instrument formats look like SoundFonts, but if the "abstract"
> libInstPatch instrument looks very different from a SoundFont's, kaing
> FluidSynth use it will be a big job IMO. 
> 

Well the thing is, that FluidSynth is already using libInstPatch in
Swami (through the SoundFont loader API in FluidSynth).  The instrument
management is already handled by libInstPatch and instruments are
rendered into static SF2 voice structures at Preset selection time,
which means note-on events can be processed very quickly.  So basic
GigaSampler and DLS support already exists in Swami, using FluidSynth.
The effect parameters are not yet used, so it is at this point a rather
basic conversion, but the framework is there to add this, just takes the
effort of adding IpatchSF2VoiceCache conversion functions for the other
instrument object types.  So it would be fairly trivial to switch
FluidSynth to using libInstPatch, since the code is mostly all there.
Its really just a question of where the code resides.  In some ways I
think it makes a lot of sense to add libInstPatch support to FluidSynth,
since the host of other applications would also then benefit from
additional formats and it could at this point be optional.

The synthesis model of SoundFont files is fixed of course (2 envelopes,
2 oscillators, low pass filter, reverb/chorus etc), but a lot of other
formats can be modeled fairly well using the SoundFont model (DLS for
example).  GigaSampler can also be of course converted to the SoundFont
model, although there are certain specialized features that can't
currently be done with FluidSynth (other types of filters, random sample
selection, etc).  A lot of this can be emulated with modulators I
imagine though (cross fading for example) and I think it would be a good
idea to look into adding some of these additional features to
FluidSynth.

> 
> Anyway, no hard feelings, at least on my part.  Obviously I would have
> preferred that the solution was to go with a C++ Fluidsynth, but I
> knew it wasn't likely.
> 
> Best of luck to you guys and hopefully our projects can benefit from
> each other in the future. 
> 

Well, I would say that the decision has not yet been made.  I am leaning
towards continuing to use C, but I don't feel that it has really been
very well weighed out yet.  The biggest issue is once again, who is
willing to program on FluidSynth.  I'm not completely convinced that C++
is necessarily a good idea to improve the code base, but if it means
more developers being interested, then why not?

Your priorities seem to be in using C++ and QMake.  I think the
FluidSynth project needs to make it a priority to continue providing a
simple API and other interfaces to other applications.  By forking the
project, you'll end up needing to merge any improvements that are made
to FluidSynth and vice versa and it may in fact be much more complicated
to have contributions be mutually beneficial.  If the effort was instead
put toward making a strong C based FluidSynth core and providing a C++
binding, it might provide for the functionality you are looking for and
provide for more cooperation together.  If you have any ideas/points to
offer about how FluidSynth will be improved by moving to C++, I'd love
to hear it.  Because as I have said, it may indeed be a good idea for a
C++ FluidSynth with a C API, it just takes a little convincing..

> Regards,
> Miguel
> 

Best regards,
        Josh