Re: [fluid-dev] FS2.0 proposal

[Bernat Arlandis i Mañó]

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ñó