Re: [fluid-dev] Fluidsynth changes

[Josh Green]

Good suggestions, I generally agree with all of it :)  I'm planning on
doing a GObject code up, just to see if it makes sense.  It may indeed
be more complex than need be, but a lot of the work is already done, and
it would add things like properties and signals which would make
FluidSynth more usable in other apps I would think.  Also a Python
binding would be really easy then.

Being simple and lightweight seems to be one of FluidSynth's strong
points.  I would like to continue in that tradition.

Cheers.
        Josh


On Thu, 2007-04-26 at 23:09 -0700, Ken Restivo wrote:
> On Sat, Apr 21, 2007 at 04:45:48PM +0200, Josh Green wrote:
> > On Sat, 2007-04-21 at 12:29 +0300, Mihail Zenkov wrote:
> > > Why we hear it only in 16 bits?
> > > 
> > 
> > FluidSynth currently only has support for 16 bit samples.  Swami uses
> > the SoundFont loader API, which just currently doesn't have support for
> > other formats other than 16 bit.  It would take some changes to
> > FluidSynth.
> > 
> > > > As for the question of platform.  We have:
> > > > 
> > > > A. Continue using C without any support libraries
> > > > B. Use a portability/utility library such a glib but remain C
> > > > C. Use GObject which is also part of glib to be a little more OO but
> > > > also remain C (would get Python bindings rather easy too, in that case)
> > > > D. Move to C++ and look into writing a C binding
> > > 
> > > IMHO B or C should be good.
> > > 
> > 
> > At this point I tend to agree.  I'm curious if the route of GObject was
> > taken, what that would look like.  There are some object building tools
> > which assist with the process, and you end up with something that is
> > rather language binding friendly in a semi automated fashion (Python and
> > C++).
> >     Josh
> > 
> > 
> 
> I like the wiki page, but that'll probably get to be a very long list.
> 
> For me, as a pretty heavy user of fluidsynth (it's my main instrument), the 
> top things I'd request are:
> 
> 1) Streaming to use less memory.
> 
> 2) Enhance realtime performance with JACK. It's already pretty tight AFAICT. 
> But I'd hope you were able to stay focussed on realtime and JACK. 
> Particularly with heavily-multilayered soundfonts.
> 
> 3) Support 24-bit soundfonts.
> 
> 4) Multi-core CPU support! Soon almost every machine shipped will be dual 
> core or quad core. jackmp has some excellent capabilities for efficiently 
> using those multiple cores, but the applications have to take advantage of 
> it. There wassome recent discussion on the jack list regarding this.
> 
> 5) Some way to do the MIDI routing through a conf file instead of having to 
> telnet into the thing (if you use glib, you get its built-in API for conf 
> file reading/parsing, IIRC).
> 
> 6) Please keep it lightweight and command-line/daemon oriented, and resist 
> the GUI temptation.
> 
> So just my humble requests. Fluidsynth is a great synth and again, it's my 
> main instrument.
> 
> - -ken
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFGMZOne8HF+6xeOIcRAhfgAKDVj9ThLNUc7s/W0WODAA3gEsIoZQCgiT1O
> B4E4xpCkezx+G5SEs+F4uJQ=
> =DHDI
> -----END PGP SIGNATURE-----
>