[Top][All Lists]

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

Re: [fluid-dev] FS2.0 proposal

From: Josh Green
Subject: Re: [fluid-dev] FS2.0 proposal
Date: Sun, 01 Mar 2009 11:37:17 -0800

Hello Bernat,

On Sun, 2009-03-01 at 01:46 +0100, Bernat Arlandis i Mañó wrote:
> 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.

It would basically mean replacing the existing SoundFont loader API and
would probably be significant changes.  Seems like it might make sense
to keep the libInstPatch integration as a separate phase, since
libInstPatch still needs a little work too.

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

Ok.  I understand better now what your goals are.

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

How did you arrive at the conclusion that we aren't getting on very
well?  I'm really excited that you are interested in working on cleaning
up the FluidSynth API and modularizing it.  From this correspondence I
realize that I have a bit more desire to overhaul things, than simply
clean them up, which might not even be that realistic at this stage.  I
think your ideas and thoughts are well thought out and the last thing I
want to do is get in the way of your efforts.  Everything you mentioned
in your proposal sounded good to me, I was simply trying to add my own
thoughts on FluidSynth 2.0.  In reality, thoughts and ideas are much
easier spoken than coded and you seem to currently have more motivation
to work on FluidSynth than I do (due to my other projects).

So by all means, the forked branch is yours to do with as you will and
as we go along, I can get a better idea of how I can help.

Best regards,

reply via email to

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