Re: [fluid-dev] New development

[Josh Green]

Hello Bernat,

On Sun, 2009-01-25 at 13:41 +0100, Bernat Arlandis i Mañó wrote:
> This is concerning ticket #11.
> 
> I'm thinking on a lot of changes to take FS forward as I review the 
> source code and fix some things, but most of these changes would break 
> compatibility backwards. Maybe we should think about making a branch for 
> something that could be FS2.0. Fixes that break compatibility could go 
> there, what do you think? Or we could take intermediate steps that would 
> be 1.1, 1.2,... I think it's better working in gradual steps with public 
> releases.

> I'm willing to push development for that branch since I'm getting to 
> know its internals and I like working with it very much, but it wouldn't 
> be good to do it completely on my own without your expertise and the 
> users support. I don't want this to start a fork neither, so there has 
> to be an initial agreement that we all support this branch while it 
> accomplishes some goals or we all forget about it.
> 

I think creating a 2.x branch would be the way to go.  One of the things
that has made FluidSynth so successful, is that the API has been pretty
solid.  It is indeed also one of the reasons why it is difficult to move
forward, as you point out.  I think that the 1.x branch should continue
to be compatible as much as possible, at least at a code API level (just
requires a recompile, but no source changes on the part of other
software using FluidSynth).

Things for the new 2.x branch:
- Move to glib
- 24 bit sample support
- Sample streaming support
- Sub audio buffer MIDI event processing
- Faster than realtime MIDI file to audio rendering
- Overhaul SoundFont loader API (used only by Swami as far as I know)
- Design in a fashion which allows for additional instrument formats to
be supported, if desired (a Fluid instrument format?).
- Leverage off of libInstPatch (optional dependency perhaps, maybe not?)
which would add support for other formats and flexible framework for
managing/manipulating instruments.


I would imagine that as we work on the 2.x branch, the 1.x branch will
become less appealing to work on.  So it is likely that some of the
things which really should be done with 1.x, wont get done.  I think
this is OK though.  Other developers which use FluidSynth in their
applications will likely be more willing to change their own API code to
FluidSynth if it has lots of new features.  Those new features will be
easier for us to add, when the code base is more to our liking, so it is
to the benefit of all, for us to have the flexibility to change the API
as needed.  The 1.x can remain, with bug fixes and minor functionality
improvements, for those applications which don't move to the new version
immediately.

> I know it's a short time since I'm working with the code, but I'm 
> already playing with it and there are simple things that can't be done 
> without breaking backwards compatibility since the code exposes a lot of 
> internals and there's a highly coupling between some components. These 
> are issues that keep FS from evolving.
> 
> Opinions, please.
> 

Its very inspiring to have you so interested in development.  I've been
the maintainer for several years now and haven't been able to quite give
FluidSynth as much attention as it needs, and deserves.  I look forward
to working on a new FluidSynth with you, and whomever else has the will
and enthusiasm to do so :)

One thing I really want to get into, is creating a new instrument
format.  This is slightly off topic, but I think it would be good to
keep in mind this kind of possibility, as we develop FluidSynth 2.0.
I'm thinking something XML based, which uses splines for describing
waveforms, envelopes, oscillators, audio samples, etc.  Kind of a
Structured Vector Audio.  I think Fluid instruments would be a fitting
name for this format.  There is still a bit of work to do, before
exploring this realm.  But I'm really excited about developing such a
format and hearing it synthesized.

Cheers.
        Josh