[Top][All Lists]

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

Re: [fluid-dev] New development

From: Bernat Arlandis i Mañó
Subject: Re: [fluid-dev] New development
Date: Mon, 26 Jan 2009 01:47:12 +0100
User-agent: Mozilla-Thunderbird (X11/20090103)

Changes breaking the API compatibility, not only for FluidSynth but for any ELF shared library (i.e., to be deployed in Linux), should require a change in the SONAME internal attribute for the library. This is usually accomplished changing the major version number.
I wasn't sure about this, I thought changing to 1.1.x would be enough. Thanks for the insight.
Why to bore with this? Because libfluidsynth.so is used by many programs, as QSynth (I'm a contributor for it) and the others reported by Julien.
True. I use QSynth myself, great to hear you're there too.
So, yes. I would open a new FS2 branch for changes breaking API compatibility and architecture changes. Maybe this would be the place to introduce the glib dependency that Josh has in mind. Anyway, I would like to ask that before coding a lot, please (briefly) explain your proposals.
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.

Josh Green:
I think creating a 2.x branch would be the way to go.  One of the things
that has made FluidSynth so successful, is that the API has been pretty
solid.  It is indeed also one of the reasons why it is difficult to move
forward, as you point out.  I think that the 1.x branch should continue
to be compatible as much as possible, at least at a code API level (just
requires a recompile, but no source changes on the part of other
software using FluidSynth).
I agree and it's also a requirement like Pedro said, that's why I mentioned that change in the ticket, since at the time I didn't now whether the trunk was going to always be the 1.0.x stable branch.
Things for the new 2.x branch:
- Move to glib
That's high in our list.
- 24 bit sample support
- Sample streaming support
24bit support is needed for complete SF2.04 support, and sample streaming would be good too, specially with 24bit samples. I thought this belonged to libInstPatch but no. These should be post-2.0.
- Sub audio buffer MIDI event processing
This one would be hard and I think it would hit performance hard. I don't think it's important to have such a high MIDI resolution. Talk later about this, post-2.0.
- Faster than realtime MIDI file to audio rendering
When doing modularization, I'd like to implement external timing, that is, synthesis and MIDI timing controlled by external functions. That would make it really easy to do.
- Overhaul SoundFont loader API (used only by Swami as far as I know)
This means Swami depends on FS Soundfont API, I thought libInstPatch duplicated this functionality. This is in the pack then.
- Design in a fashion which allows for additional instrument formats to
be supported, if desired (a Fluid instrument format?).
Not my interest, but modularization would certainly help that, and we might reach a point where this is desirable.
- Leverage off of libInstPatch (optional dependency perhaps, maybe not?)
which would add support for other formats and flexible framework for
managing/manipulating instruments.
You could certainly help a lot with this.
I would imagine that as we work on the 2.x branch, the 1.x branch will
become less appealing to work on.  So it is likely that some of the
things which really should be done with 1.x, wont get done.  I think
this is OK though.  Other developers which use FluidSynth in their
applications will likely be more willing to change their own API code to
FluidSynth if it has lots of new features.  Those new features will be
easier for us to add, when the code base is more to our liking, so it is
to the benefit of all, for us to have the flexibility to change the API
as needed.  The 1.x can remain, with bug fixes and minor functionality
improvements, for those applications which don't move to the new version

That's the idea, although I wouldn't put the 1.x branch to rest so fast, I think it's gonna take some time. Fixes could easily go to both branches whenever possible, but new serious development should go to the new branch.
One thing I really want to get into, is creating a new instrument
format.  This is slightly off topic, but I think it would be good to
keep in mind this kind of possibility, as we develop FluidSynth 2.0.
I'm thinking something XML based, which uses splines for describing
waveforms, envelopes, oscillators, audio samples, etc.  Kind of a
Structured Vector Audio.  I think Fluid instruments would be a fitting
name for this format.  There is still a bit of work to do, before
exploring this realm.  But I'm really excited about developing such a
format and hearing it synthesized.
With better modularization I expect it'll be easier for everyone to focus on their preferred component, and each one could grow independently of the others. It'd be also easier to implement alternatives for components with little effort.

I thank you all for the positive and helpful responses. I need some time to gather more information, I will explain better what I would do and then exchange points of view with you so we can work together on this from the start.


Bernat Arlandis i Mañó

reply via email to

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