fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] FS2.0 proposal


From: Ebrahim Mayat
Subject: Re: [fluid-dev] FS2.0 proposal
Date: Sun, 01 Mar 2009 07:02:16 -0500


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]