[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Supported Wave/Flac format other than SF2

From: David Henningsson
Subject: Re: [fluid-dev] Supported Wave/Flac format other than SF2
Date: Thu, 05 Feb 2015 22:21:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015-02-05 21:24, Garth Hjelte 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.

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.

I guess this depends on your level of ambition. I believe - correct me if I'm wrong - that for the (open source) sf2 playback engines out there, FluidSynth is the top notch one, in terms of following the specification.

Sure, we could "just transfer it in", but then again, the results would be slightly wrong. Just as an example, sfz seems to have a three band EQ built into every voice [1], which SF2 voices do not. This is stuff we would have to add into the playback engine.

If we should bring SFZ into the engine, then my wish would be that the goal should be to play it as perfect as SF2 files are played today. (Sure, we can have a few releases along the way where we're open with that SFZ is not perfect yet, and that we plan to improve the support later.)

// David

[1] Source: http://sfzformat.com/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]