Pedro Lopez-Cabanillas escrigué:
Bernat Arlandis i Mañó wrote:
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.
Please, can you elaborate what are those problems, and the goals that we can't
fullfill without the big overhaul you are proposing?
My main complain is not being able to fix bugs and implement simple
features without breaking API compatibility. FS is a program that is
build as a library by exposing a lot of internals. Max has also pointed
some of the flaws of FS as a library.
Modularization is also a bit too rough and makes it difficult to work
isolated in a module, or even replace modules. Timing is another thing
that isn't well defined.
[...]
So, this is a list of tasks without strict order:
- Define API for every component.
I think that I agree with Josh here. Can you please explain why the current
API is so badly designed, broken or ugly to require a complete redesign from
scratch?
I think I've been severely misunderstood. I don't plan on rewriting FS,
I don't want to do a new API from scratch, not exactly. I'd like to
review the current API trying to make it simpler.
The main work I'm proposing is improving the interface and
modularization by following the proposed design. The design diagram I'm
proposing isn't original at all, it's taken from the current
implementation. So it's just an improvement over what we have, an
interface cleanup and rearrangement with a clearer (simpler
dependencies) design.
Maybe there's not much to do because everything is pretty good already,
but I dub it since I know there's at least some weird things in the
code, note on processing and timing are two of them.
- Replace code with external libraries where possible.
I can agree with using Glib, instead of borrowing entire components as for
instance fluid_list, but external dependencies should be carefully justified
and limited to the strictly necessary.
Yes, replace "where possible" with "whenever it makes sense".
- 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.
Why not to leave the autohell, and go to something better like CMake? I have
some experience converting projects to CMake.
What do you think about adding CMake to trunk? (without removing the auto.*)
Trunk is Josh's land. I don't have an opinion about that since I know
little about build environments.
- Platform building and testing (including drivers).
I can also offer my help in Linux and Windows, and my little experience in Mac
OSX.
Anyway, I would like to ask what do you think about a new stable release 1.0.9
from trunk, soon. I really like all the new drivers, and also interesting
bugfixes. I would like to be able to fix tickets #22 and #23 first. I think
that #23 would be not exactly the same as #10, but only a limited workaround.
If you're asking me, releasing a new stable build would be good, but not
related to 2.0.
Josh:
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?
I don't want to do a rewrite, I'd like to be conservative about changes
except where absolutely necessary to reach the goals. I would even delay
libInstPatch or any other library integration if that meant a lot of
changes to the code.
My main goals now would be the improvement on modularization and a
simplification and better arrangement of the API. Having this
established should be easier to work separately on modules, or even
replace one module, f.e. replacing the current soundfont loader module
with libInstPatch.
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.
These are details that can be discussed later. Yes, I've used glib a
bit. I wouldn't start using glib data types everywhere, these changes
should be done progressively where we can get some benefit, f.e. we
could replace some arrays with hash tables and lists for better
performance in some places.
Locking is another entirely different problem. I know there are a lot of
important and interesting problems to solve, but I don't want to fix
them all now. I just want to improve the modularization and API.
I hope you're honest and let me know if you think I should forget about
this. Maybe I'm talking bullshit or I'm not the right person or it's not
the right moment or I'm just bad explaining it. Whatever it is I think
we aren't getting on very well and it's making me loose confidence on
what I'm doing.
--
Bernat Arlandis i Mañó
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev