Re: [fluid-dev] same-named samples in soundfonts in 1.1.3

[Bernd Casper]

Gents,

 

it would be great if this could be researched for the official release.

 

I can second the effect Krzysztof describes, with soundfonts constructed in Vienna 2.3 and 2.4, and Viena. The issue also appears *sometimes* when original 2channel stereo samples are used (both the channels are re-named samplename(L) and samplename(R) in Vienna then, but even the own import functionality of Vienna has strong problems with names).

 

In some cases only one channel of the stereo sample was loaded by FS.

 

Actually, the only way to avoid this seems to divide the stereo sample into two mono samples manually, and name them unique. I observed that since FS 1.0.9.

 

Some moments the behaviour let me suspect a memory pointer issue.

 

Regards

Bernd.

----- Folgende Nachricht wurde empfangen -----

Absender: Krzysztof Foltman

Empfänger: fluid-dev

Zeit: 2011-02-23, 23:01:52

Betreff: [fluid-dev] same-named samples in soundfonts in 1.1.3

Hey all,

I've found an odd property of Fluidsynth's soundfont loader. It wouldn't
be a big deal, but it gives some trouble when using soundfonts created
using some tools (like Lear Jeff's Nerd Soundfont Tools), and may be
hard to diagnose at first.

The problem occurs when the soundfont file has more than one sample with
the same name. In such cases, it seems to ignore the distinction between
those samples. In case of soundfonts created using jsftools, the samples
for the left channel and the right channel have the same name.

SWAMI and other tools seem to deal with it just fine - but when I try to
use Fluidsynth directly, using its own SF2 loader(?) instead of SWAMI's,
I get mono sound, because a single sample (left channel, for instance)
is used for both sample references in an instrument.

Just for a test, I've created a soundfont with all samples having the
same name - loads and plays fine in SWAMI, but not using command-line
Fluidsynth program, where again only one sample is used instead of many
different samples.

I haven't been trying too hard to find where the problem actually is,
but at least in one place the sample to use in the zone is resolved via
name (fluid_defsfont.c line 1411). If that's where the problem is, I may
try to fix it myself, but maybe someone's been thinking about the best
way to do it before?

(Of course, the simplest workaround for new soundfonts is to guarantee
that sample names are unique, and that's what I'm doing now - but it
doesn't help when using other people's unmodified soundfonts)

Cheers,
Krzysztof


_______________________________________________
fluid-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fluid-dev