Pedro:
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
immediately.
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.
Cheers.
--
Bernat Arlandis i Mañó
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev