Re: [iiwusynth-devel] FluidSynth roadmap

[Peter Hanappe]

Hi,


I quickly reply to an earlier mail in this thread.

Antoine Schmitt wrote:
> :::::::::6/11/02::::0:37 -0800::::Josh Green:::::::::
>
> > - New FluidSynth name. Should the API be changed to reflect this? This
> > is obviously going to completely blow up backwards compatibility.
>
>
> That would be a good moment to make a stable release.

Agree.


> > - Improved sfloader sample data handling
>
>
> - I think that the sfloader API is really heavy, especially knowing that 
> only one sfloader exists : the default one. Is it really necessary ?

I agree that it's heavy. C simply doesn't handle subclassing very
well ;)

I've been thinking about something that maybe controversial: start
a parallel development branch to rewrite Fluid in C++. Initially, the
synth was going to be very simple and it's "class" structure as good
as flat. Now we have drivers, plugins, soundfont loaders to handle.
If we want to stream large samples, it might be nice to have a
Sample class as well. Just some thoughts. Hardcore-C-coders, don't
shoot me, yet.

> Some other topics I'd like to submit to your sagacity:
> - have FluidSynth automatically take advantage of hardware devices if 
> available

Yup, that was one of the initial goals of the projects: if there's a
SoundFont hardware synth, use it, if not, use the software synth.


> - architecture FluidSynth so that the output stream(s) may be inputted 
> into some other APIs, like DirectSound3D, or some équivalent 3D sound 
> spatialization engine).

> -- Ability to set the number of channels at startup

See my next mail.

> -- Manage other sampling frequency than 44100

The synth can output at a different sampling rate. I guess what you mean
is handle samples at a different sampling rate. The sampling rate is
fixed by the SoundFont specifications and there's nowhere in the SF2
file where you can set the sampling rate. The only solution is to load
the sample as if it were at 44100 Hz and change the root key according
to the real sampling frequency.


> [I cut the rest because they have been discussed later in the thread]


> The only thing that is quite complex I think, and which is not caused by 
> iiwu but by the opensource process, is that it is very difficult to rely 
> on a stable version, as it changes all the time with bug fixes and new 
> features. So for the production of a client of iiwu, one has to have the 
> full development environment available, CVS, as well as all the other 
> free software libraries (portaudio, MidiShare, now linsndfile for the 
> Xtra...) + update regularely and recompile everything. I dont know how 
> things are done usually with OpenSource software (I come more from the 
> industry - NeXT, etc..), and I know that all this is done gracefully by 
> all of us, but I think that it would be good to have stable releases 
> from time to time, fully built and available in binary format, with 
> documentation.

You're right, it's time that we release a stable, binary, reference
release. Hopefully soon, with the namechange.

The "problem" with opensource projects is that the process is completely
transparent and all intermediate (unstable) versions are visible and
public. The latest version is rarely the best version. But, yes, it's to
release a stable, binary version for Fluid.

Cheers,
P

> Enough for today :-)
>
>
>
> ++ as
>
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/iiwusynth-devel