|
From: Peter H. <pe...@ha...> - 2003-03-18 23:11:58
|
Josh Green wrote: > On Tue, 2003-03-18 at 01:12, Steve Harris wrote: > >>Givent that one of the main goals of linuxsampler was to have disk >>streamed sample playback, how much effort is required to add this, and >>would it fit with the currect architecture - I guess it would go into fluid? >> >>- Steve >> > > > I have suggested streamed sample playback on the FluidSynth list a few > times. It sounds like it is on the todo list for next major release (who > knows when that will be). <chop> > The current view of some of > the FluidSynth developers is that it isn't really necessary. Streamed sample playback is on my todo list for quite a while now. However, the first goal was to develop a synthesizer that is MIDI and SoundFont compatible. Version 1.0 pretty much satisfies that goal. As soon as we split of the development branch (version 1.1.x) we can start adding sample streaming. Maybe the better thing to do is to improve the current sfloader and sample API and add the intelligence of the sample streaming (i.e. caching, preloading) in libInstPatch rather than in FluidSynth. >>From what I currently know of FluidSynth goals, it currently falls short > of the linuxsampler goal of multi patch format support. FluidSynth is > likely to remain SoundFont based, but its sfloader API that I use to > interface Swami's instruments to it is generic enough to allow any > format to be synthesized (within the constraints of SoundFont > synthesis). I'm of the opinion that it's better that FluidSynth implements the SoundFont synthesis model as efficiently as possible instead of trying to become a swiss army knife for wavetable synthesis. I think the users benefit more from having the choice between several small but optimized synthesizers rather than one big, buggy synthesizer. As you said, additional patch types can be supported through libInstPatch, if they map reasonably well to the SoundFont synthesis model. Peter > Josh > |