fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] Soundfont banks


From: jimmy
Subject: Re: [fluid-dev] Soundfont banks
Date: Tue, 10 Jul 2012 13:26:35 -0700 (PDT)

Oops, I hit "reply" instead of "reply all".  Trying again to post to the 
mailing list.


--- On Tue, 7/10/12, David Henningsson <address@hidden> wrote:

> In your emails, I sometimes have a hard time separating the
> facts you provide from the opinions you also provide. This
> might be part of why you feel you don't get an answer for
> some of the stuff you say. Another is lack of time on my
> part.

My opinions are my interpretation of the MIDI specs.  XG-mode does not break 
the MIDI specs in any way.  In fact, I think of it as one decent interpretation 
of the MIDI Specs, which handles 128x128 soundbanks.  Just that the XG-specs is 
hard to obtain, and is obsoleted by MIDI-2.  If there's any movement toward 
MIDI-2 in FluidSynth, I wouldn't care much at all with XG stuff.

You and Pedro seem to stick with only what you prefer with the Soundfont specs 
and GS-specs, both of which only deal with 128 soundbanks.

Of course, I don't expect you to waste your time on XG-stuff if that's not your 
area of interest, or expertise.  I have done some homework with regarding to XG 
stuff and provided my patch(es) for my "observation" of the vairous XG 
implementations (via Yamaha hardware instrument tables). 

No, I don't speak with any authority on XG, no I don't even have the official 
XG specs.  Does that make me "wrong"?  I doubt it.  People can look up the 
hardware manuals for Yamaha keyboards and find out if my "observation" and 
"interpretation" is way off-base, or not.  I also had references to some of 
those manual when I brought up the point in supporting my patch(es).


>
> I don't mind figuring out a system for mapping several
> soundfont files to different MSB's and LSB's, through some
> kind for soundfont bank offset functionality. It is not
> clear to me how that will work out in the different modes,
> especially not in combination with drum channels, drum
> presets and drum banks.

Which is why my patches only touch the XG-mode, it won't break GM, GS or any 
other modes.  It should work the same way MIDI and MIDI-2 allow hardwares to 
do, too.  But I'm not risking breaking MIDI and MIDI-2 stuff at the moment.  If 
other people have other ideas, or want to adopt the functions I use in XG mode 
for other modes, it's up to them.

It took me several years to read up and understand bit by bit the XG stuff, 
just because I deal with some Yamaha keyboard stuff, and want to work with 
XG-MIDI messages and XG-MIDI files.  It's also painful, because I can't find 
much info on XG-specs.  I can only peek at the various implementations via 
their numerous specific keyboard manuals.

In fact, again my own opinion, I think that the MIDI-2 specs adopts the multi 
drum channels feature from the various XG implementations.  This particular 
feature doesn't clash with the original full MIDI specs at all, just brought 
forward a specific recommendation for implementing it.


>
> But before we actually have that system figured out, patches
> written and committed for how to do this, it does not make
> sense to me to commit an XG bank selection patch that just
> causes the total value (MSB*128 + LSB) to go out of range.
> Especially when we have an mma mode that already does just
> that, and is perfectly possible to use, if you desperately
> want values that point nowhere.

With existing code, the MMA mode in the MSB handling completely ignored 
drum-channels.  I'm not well versed in the MMA arena, so I won't speak on that. 
 But for XG to piggy-back that specific code, it is broken for XG-drum 
channels.  That's what my patch in the MSB function tries to fix.

In other words, the MMA style is only partially working with regards to 
XG-mode, and currently that's short-circuited in the logical flow of the code 
so it doesn't handle it properly in XG-mode.


>
> The General Midi (GM1) spec does not include bank selection
> messages at all. Therefore all bank changes are ignored in
> GM mode. That method is compliant with the General Midi
> (GM1) spec, but maybe not "how you think things should
> work".

Here you are either confused between GM and full MIDI specs, or you are 
bastardize the MIDI specs again.  I'm talking full MIDI specs which include CC0 
and CC32.  You are refering to the GM-mode, which is even tinier subset of the 
Soundfont specs, or GS specs.  GM-mode has something like one soundbank, and 
one drumbank, right?


> As previously stated, the GM bank selection mode (i e,
> ignore all bank selection messages) is compliant with the
> GM1 spec. Please stop saying that it isn't.

I'm not talking about GM-mode, I'm talking full MIDI specs with CC0 and CC32 
support.  I'm not work talking about one soundbank, one drumset that GM-mode 
provides.


> Patches are more likely to be accepted if we first agree on
> what should be implemented.

Only if you realize GM-mode and full MIDI are like a drop of water compare to a 
cup of water.


>
> As for your other email about what you think is wrong with
> the current patch, let's get back to that when we have the
> soundfont bank offset functionality in place.

Sure, do what you want.  I'm pointing out that the current code is wrong.  I 
also know that my patch is logically sound, but won't fix anything functionally 
at the moment.  But I'd rather having the correct code in place, instead of 
saying "we know the current code is wrong, but it doesn't make any difference, 
so we won't change the code".

Hey, if I won't be around, at least the correct code is in there, saving 
someone else the trouble of understanding the XG stuff and code it years down 
the road.  Heck it's been almost 1.5 years since I submitted that patch and 
nothing has been mentioned.  I might see Harley's Comet swing by before I see 
anything new in FluidSynth at this pace.

Jimmy




reply via email to

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