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 [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
