Re: [fluid-dev] FS2.0 proposal

[Ebrahim Mayat]

On Feb 28, 2009, at 12:20 PM, 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 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.

Hello Bernat

Your suggestions are stimulating (for want of a better word). The  
diagram does indeed bring many "modules" into perspective. I imagined  
the the soundfont loader to channel into the synth module instead of  
the other way round. Should not wav files be loaded prior to being  
rendered ?
> 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.
>
> 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.
>
> 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.
> - 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.
>
> 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.

Absolutely.
> 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.

Can't disagree with that.

E