Hello, Although I do plan to add libInstPatch support to FluidSynth, I think it likely makes sense to leave the old loader as well, for a standalone option.
As per the SoundFont spec, samples should not have identical names, but FluidSynth's handling of this definitely seems wrong. Line 1411 in fluid_defsfont.c does look like the offending code. The original SoundFont loader was taken from my ancient Smurf SoundFont Editor code base. The part where things are going wrong in this regard is the routine that imports those structures into the FluidSynth specific ones. I've committed a fix for this to SVN (rev 409). It seems that the defsfont loader isn't directly exposed to the public API, so I took the liberty of adding a fluid_sample field to SFSample for doing a proper fixup of samples when doing the import and removed the no longer used fluid_defsfont_get_sample() function. Please let me know if this fixes your problem or not. Best regards, Element On Sun, Feb 27, 2011 at 1:25 AM, David Henningsson <[email protected]> wrote: > On 2011-02-23 23:01, Krzysztof Foltman wrote: > >> 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) >> > > Thanks for your bug report. I believe Josh/Element Green had some thoughts > of FluidSynth actually using the libInstPatch loader (used in SWAMI) instead > of FluidSynth's current loader. > > I don't know if that will happen in the near future though, so I'm happy to > accept patches that fixes the current issues. > > // David > >
_______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
