Re: [fluid-dev] FS2.0 proposal

[Josh Green]

Hello,

On Sat, 2009-02-28 at 18:20 +0100, Bernat Arlandis i Mañó wrote:
> Hi.
> 
> Sorry for the long wait but I'm a bit busy lately. This is how it's 
> gonna be since this is something I have to do on my spare time so there 
> will be ups and lows inevitably, but I'm firmly decide to get there with 
> your help.
> 


I've also been very busy and have a lot of projects too and so I'm in as
similar situation.  But I do enjoy working on FluidSynth when I get
inspired.


> I've been thinking a bit on what I'd like to do for FS2.0 and would be 
> interesting to do. My goal is having a better code base to work on 
> building new features and improving performance and compatibility 
> without the problems we have right now.
> 
> My first priority is designing a simple API that hides the internals and 
> provides just what is needed and expected from FS. I think this is also 
> the first thing that should get done since it's fundamental to other 
> decisions, the new API will guide the refactoring of the code.
> 
> I've made a simple design diagram for FS components (image attached), 
> dependencies have been minimized and there's no loops. Based on this 
> diagram we should be able to define what every component should provide 
> and what not. Every component should be seen as a library even though 
> we're not planning on distributing them separated, thus every component 
> will have its own API and the sum of them will be the FS API.
> 
> We must follow some guidelines to library implementation as suggested by 
> Max Kellermann. All API functions should check their parameters and 
> report their condition by returning result codes. Abnormal conditions in 
> internal functions can be taken care by asserts and should be treated as 
> programming errors.
> 


glib has some useful macros in this regard.  g_return_if_fail and
g_return_val_if_fail, for functions which don't return a value and ones
which do, respectively.  I use them extensively in Swami and
libInstPatch.


> We should also remove code from FS that can be used from external 
> libraries. We talked about using glib and the swami sounfont library, 
> maybe using gobject too. I took a look at gobject and I think it might 
> be overkill for this project right now.
> 


I think the properties system would be a nice replacement for the
FluidSynth settings system that exists now.  And it would pave the way
for Python and C++ bindings (leveraging off of the work of PyGObject and
GTK--).  The reference counting and consistent object
creation/destruction is also useful.  We could always do that as a
separate branch though.  Perhaps I've just gotten too used to using it
in my projects :)


> We'll be breaking compatibility in a major way, so another important 
> task is helping applications become compatible with the new API by 
> providing patches and support. We could try providing a compatibility 
> layer for the old API but it might take too much effort.
> 
> So, this is a list of tasks without strict order:
> 
>  - Define API for every component.


I'm not convinced this is entirely necessary from the get go.  We could
work on this in stages (described below).


>  - Replace code with external libraries where possible.
>  - Refactor code.
>  - Implement missing API functions.
>  - Implement checks and result codes on every API function.
>  - Document the new API.
>  - Helping applications developers upgrade to the new API.
> 

That all sounds good.

For documentation, we could use GTK doc.  The resulting HTML
documentation looks nice and I have come to really like the syntax.  You
can document pretty much everything in the code, which is where it
belongs.  Getting into the habit of documenting while coding, is the
right way to do things, rather than having to come back and document it
later.


> This is much work, and we're a just few developers with not much time. I 
> won't mind working alone, but there's some subjects where I'd truly need 
> your help:
> 
>  - Autotools/automake/libtool maintenance and support.
>  - Platform building and testing (including drivers).
> 
> Also, I'd like to avoid regressions, so everyone willing to test every 
> new commit and report feedback is very welcome. Providing patches for 
> maintaining compatibility with other applications (like QSynth) would 
> help doing better testing too.
> 
> There's some places where collaboration will be necessary (API design), 
> but sometimes it'll be troublesome (refactoring), communication will be 
> really important. I'd like this to be a collaborative effort and get you 
> all involved in some way, but coordination and direction is very 
> important to succeed so I should take the lead in this branch.
> 


Sounds good.


> As can be seen, implementing new features is not the main goal right 
> now, but if we get the new modular design right then some wanted 
> features will get done without effort. Besides, anyone can start a new 
> branch if they feel like implementing any experimental feature, if it's 
> good it can be merged later.
> 
> I'd start by posting a simplified draft of the current API so we can 
> start discussing, but I'd like to read first your comments about this. 
> How do you think you could get involved... what's wrong... whatever you 
> think is important.
> 
> Regards.
> 


I'm currently working on getting libInstPatch back in a state of full
operation.  I've been re-doing some of the sample API stuff, in
particular adding support for surround sound (up to 8 channels, I really
like the idea of surround sound instruments) in the lowlevel sample
routines and cleaning up some redundant sample object dependencies.
Once I get these changes out of the way, I'll turn to adding support for
it in the new FluidSynth branch (or make another branch if desirable).

We might want to look at FluidSynth 2.0 as being more of a re-write,
than trying to muck with every part of the existing code base.  I think
this would likely be more productive.  If we decide to use libInstPatch
from the beginning, then we can ditch all the SoundFont loader code,
which is where a lot of the redundant glib borrowed code is.

Rather than define the API from the get go, for every part of
FluidSynth, it might make more sense to re-write particular subsystems
first and allow some of the other API to evolve as the core components
are completed.  This would lead to something that works sooner.  How
does this sound as far as a priorities list of things to re-write:

1 FluidSynth core with libInstPatch support
2 New driver API with a couple drivers using new API
3 MIDI event and timing system
4 MIDI file player
5 Remaining drivers


The new FluidSynth could begin to be used in a minimalistic fashion
after stage 2.

How does this sound?

How familiar are you with glib?  A discussion that is probably worth
having from the beginning, is just some overview of features and data
types in glib that will be useful to us.  We should also decide on how
FluidSynth is going to handle locking of its internal data and
minimizing locking in the synthesis thread.  glib has cross platform
thread functions and primitives for this, but having a better idea of
what needs to be locked and when would be a good start.

Cheers!
        Josh