On Thu, Feb 5, 2015 at 1:24 PM, Garth Hjelte <ga...@chickensys.com> wrote:
> At 11:37 AM 2/5/2015, you wrote: > > >Hi and thanks for chiming in - as you very likely know, all formats have > >their own quirks and ways of transforming the sample according to > >various rules, so SFZ/DLS/Gigasampler/etc support would require certain > >additions and changes to the playback core. Simply adding a dependency > >to libInstPatch does not seem to be sufficient - as other formats > >wouldn't exactly map 1:1 to SF2, we would be something that plays SF2 > >really well (like today) but other formats slightly wrong. > > Actually (and I have the world expertise on this) most formats are eerily > similar. It's not as different as you might be implying, in fact it's > almost identical. PCM sample, volume, pan, tune, bits, sample rate, > channels, loop on/off, loopstart, loopend, root key, keytrack. MAYBE > amplitude envelope. > > I agree, a lot of these wavetable formats are similar in regards to their synthesis models. As far as libInstPatch is concerned, it keeps files in their native formats and when they get synthesized by FluidSynth they get transformed into a SoundFont centric voice cache, which gets used to instantiate voices in FluidSynth. So yes, it is limited to the SoundFont synthesis model currently. I suppose when I think about it, I've been focusing mainly on getting the majority of features of other similar formats supported and not worrying much about some of the other details which can't be shoehorned into the SoundFont model. I've been told before that this is wrong and that most users would expect full support for whatever format they are using and that partial support just wouldn't cut it. This is probably true. There may even be an argument for just converting other formats to SF2 separately, rather than trying to load them into FluidSynth directly. When it comes down to it, its mostly about getting down and doing some real coding, which is where I have found very little time for, for quite a while now. > The solution is really as simple as taking in the core parameters (see > above) and transferring it in. You don't have to guarantee perfect results; > merely getting it in is much more advantageous. > > My thought is if there is a consideration of putting another instrument > format to be read within the core FluidSynth, I would recommend SFZ only > for the fact that people can write their own SFZ files very simply. FS > would only take a subset of the opcodes as authoritative, which is actually > all FS would ever need. The advantage is making FS a bit more open as far > as input goes. > > Garth Hjelte > Sampler User > > Best regards, Element Green
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
