Gents, my personal observations and thoughts without being a programmer:
I can second that since FS release 1.1.1 patches of bank 0 [bank 1 after Chris' definition] using CC00 are *not* called correctly, until we introduce to re-route bank 0 patch calling using CC32. In jOrgan we can do so, but indeed it would be preferable to have bank 0[1] patch calling working with CC00 for default. There was already a bank 0 patch calling issue in FS 1.0.9 release, resulting a voice substitution. I was informed by FS error messages, that FS didn't found patches which were correctly set up in the soundfonts, and had replaced them by bank 0 patch 0. Strange though, the sounds themselves weren't replaced in fact, as they were set up correctly in the soundfonts. In FS 1.1.1 those error messages correctly appear only when patches in the soundfonts are missing in fact, but bank 0 patch calling using CC00 remains not to work correctly. I've never tested if FS 1.0.9 did work correctly with CC32. Another thought: I understood a bank change has *always* to be followed by a program change, else it's not performed at all, by definition. So may be both MSB and LSB have to be followed by a program change? Regards Bernd. ----- Folgende Nachricht wurde empfangen ----- Absender: Elimar Green Empfänger: S. Christian Collins Zeit: 2010-08-02, 04:00:28 Betreff: Re: [fluid-dev] Re: Son of ticket #65 Its been a while since the topic of MIDI bank selection was discussed, so I'm frustratingly in the dark again about it. From what I read a bank/program change is sent as such: Bank MSB (CC #0) Bank LSB (CC #32) Program change So in that case if 1 was sent for MSB and 0 was sent for LSB it would mean bank #128. If only a MSB is sent though, as in the cited example case, I'm suspecting that should be interpreted instead as an LSB value? Not sure exactly what standard defines such behavior though. Does this sound like what the issue is related to? Elimar On Sun, Aug 1, 2010 at 12:53 PM, S. Christian Collins <s.chriscoll...@gmail.com> wrote: > Well if a default behavior has to be honored, wouldn't supporting the GS > standard of bank switching be preferable to the current implementation? > From what I've read, instead of selecting a patch from bank 1, FluidSynth is > selecting from the percussion banks instead. Isn't this what channel 10 is > for? I would expect there to be far more MIDI files using the bank select > to select GS (or similar) instruments rather than trying to select a drum > set on one of the melodic channels (1-9, 11-16). > > Perhaps I'm misunderstanding the problem, but when this was changed > (sometime after 1.0.9), it seems to have been to a far inferior solution. > As the composer of the March mentioned in the discussion, I expect those > bank 1 patch change commands to select a specific strings preset when used > with GeneralUser GS, and if a patch isn't available on that bank, then it > falls back to the corresponding preset on bank 0 (in this case 48:Fast > Strings). Every synth I've played this March on has behaved in this way. I > would never expect those instruments to become drum sets. > > -~Chris > > On 08/01/2010 01:08 PM, David Henningsson wrote: > > 2010-08-01 19:33, Pedro Lopez-Cabanillas skrev: > > > I assume that this issue is irrelevant for the people that manages this > project. So probably fluidsynth 1.1.2 is going to be released with this bug? > > > If that was a question to me, I would say you are welcome to commit a > change assuming it fixes more songs that it messes up, basically. > > What's not likely to happen in 1.1.2 is behavior being dynamic, i e > changed based on GM/GM2/GS/XG sysex'es in MIDI files. > > // David > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > http://lists.nongnu.org/mailman/listinfo/fluid-dev > > > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > http://lists.nongnu.org/mailman/listinfo/fluid-dev > > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
