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

Reply via email to