Re: [fluid-dev] New development

[Bernat Arlandis i Mañó]

Pedro:
> Changes breaking the API compatibility, not only for FluidSynth but for any 
> ELF shared library (i.e., to be deployed in Linux), should require a change 
> in the SONAME internal attribute for the library. This is usually 
> accomplished changing the major version number.
I wasn't sure about this, I thought changing to 1.1.x would be enough. 
Thanks for the insight.
> Why to bore with this? Because libfluidsynth.so is used by many programs, as 
> QSynth (I'm a contributor for it) and the others reported by Julien.
True. I use QSynth myself, great to hear you're there too.
> So, yes. I would open a new FS2 branch for changes breaking API compatibility 
> and architecture changes. Maybe this would be the place to introduce the glib 
> dependency that Josh has in mind. Anyway, I would like to ask that before 
> coding a lot, please (briefly) explain your proposals.
>   
Although it's mainly about whatever we can agree that is good for the 
development of the project, I have some generic ideas that I think would 
work. These are modularization, decoupling the API from the internals, 
and also introducing the glib and other dependencies that would ease work.

Specifically, on the modularization aspect I'd like to break FS down in 
several libraries that could build separately if needed. This libraries 
might be, guessing a bit: fluid-synth (the synthesis engine), 
fluid-soundfont (sound font loader), fluid-midi (midi playing 
capabilities incl. midi drivers), fluid-midir (midi routing), 
fluid-audio (audio conversion utilities and output drivers, maybe LADSPA 
too), fluid-ctrl (shell and server).

Some of these components could grow and become independent projects, in 
particular I think midi routing could become a general library being 
able to read routing rules from a XML file and with a front end for 
editing these files. Some other components might just disappear if 
there's some external one that can do the same.

Being able to break it down and build it like this would be a good 
modularization test. It would also help 3rd party developers taking just 
what they need and connect all the parts in more flexible ways than is 
possible now.

In some way, the code has already been developed with this goals in 
mind, so we're not that far. It's really difficult to fully reach these 
goals in one try, or even two, but we're already somewhat close.

Josh Green:
> 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).
>   
I agree and it's also a requirement like Pedro said, that's why I 
mentioned that change in the ticket, since at the time I didn't now 
whether the trunk was going to always be the 1.0.x stable branch.
> Things for the new 2.x branch:
> - Move to glib
>   
That's high in our list.
> - 24 bit sample support
> - Sample streaming support
>   
24bit support is needed for complete SF2.04 support, and sample 
streaming would be good too, specially with 24bit samples. I thought 
this belonged to libInstPatch but no. These should be post-2.0.
> - Sub audio buffer MIDI event processing
>   
This one would be hard and I think it would hit performance hard. I 
don't think it's important to have such a high MIDI resolution. Talk 
later about this, post-2.0.
> - Faster than realtime MIDI file to audio rendering
>   
When doing modularization, I'd like to implement external timing, that 
is, synthesis and MIDI timing controlled by external functions. That 
would make it really easy to do.
> - Overhaul SoundFont loader API (used only by Swami as far as I know)
>   
This means Swami depends on FS Soundfont API, I thought libInstPatch 
duplicated this functionality. This is in the pack then.
> - Design in a fashion which allows for additional instrument formats to
> be supported, if desired (a Fluid instrument format?).
>   
Not my interest, but modularization would certainly help that, and we 
might reach a point where this is desirable.
> - Leverage off of libInstPatch (optional dependency perhaps, maybe not?)
> which would add support for other formats and flexible framework for
> managing/manipulating instruments.
>   
You could certainly help a lot with this.
> 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.
>
>   
That's the idea, although I wouldn't put the 1.x branch to rest so fast, 
I think it's gonna take some time. Fixes could easily go to both 
branches whenever possible, but new serious development should go to the 
new branch.
> 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.
>   
With better modularization I expect it'll be easier for everyone to 
focus on their preferred component, and each one could grow 
independently of the others. It'd be also easier to implement 
alternatives for components with little effort.

I thank you all for the positive and helpful responses. I need some time 
to gather more information, I will explain better what I would do and 
then exchange points of view with you so we can work together on this 
from the start.

Cheers.

--
Bernat Arlandis i Mañó