Re: [fluid-dev] New development

[jimmy]

> Date: Mon, 26 Jan 2009 01:47:12 +0100
> From: Bernat Arlandis i Ma?? 
> <address@hidden>
> 
> Although it's mainly about whatever we can agree that
> is good for the 
> development of the project, I have some generic ideas that
> I think would 
> work. These are modularization, decoupling the API from the
> internals, 
> and also introducing the glib and other dependencies that
> would ease work.
> 
> Specifically, on the modularization aspect I'd like to
> break FS down in 
> several libraries that could build separately if needed.
> This libraries 
> might be, guessing a bit: fluid-synth (the synthesis
> engine), 
> fluid-soundfont (sound font loader), fluid-midi (midi
> playing 
> capabilities incl. midi drivers), fluid-midir (midi
> routing), 
> fluid-audio (audio conversion utilities and output drivers,
> maybe LADSPA 
> too), fluid-ctrl (shell and server).
> 
> Some of these components could grow and become independent
> projects, in 
> particular I think midi routing could become a general
> library being 
> able to read routing rules from a XML file and with a front
> end for 
> editing these files. Some other components might just
> disappear if 
> there's some external one that can do the same.
> 
> Being able to break it down and build it like this would be
> a good 
> modularization test. It would also help 3rd party
> developers taking just 
> what they need and connect all the parts in more flexible
> ways than is 
> possible now.
> 
> In some way, the code has already been developed with this
> goals in 
> mind, so we're not that far. It's really difficult
> to fully reach these 
> goals in one try, or even two, but we're already
> somewhat close.

Bernat,

I think those are good ideas.  Keep in mind I don't do any work for FS at all, 
except running into a few problem here and there.

While people want backward compatibility, I can see that FS code is not that 
easy to change.  So a new version with new API would be just as well. 

Allow me to also suggest that while you do code decoupling, internal variable 
changes should verify that it is valid before allowing the changes.  This is 
best funneling variable changes in a common function and call it from other 
places.

I have seen many places in FS code that assigns variables blindly, i.e. midi 
program change, soundfont bank change that causes invalid instrument selection 
and FS messed up that midi channel, and that channel is silenced.

Jimmy