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
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
