Re: [fluid-dev] Soundfont banks
--- On Mon, 7/16/12, David Henningsson di...@ubuntu.com wrote: Just a question here: What soundfont do you run these files with? Is there an XG soundfont out there (or maybe even lots of them?), and if so - how is that soundfont constructed? How does it squeeze XG's drum banks and melody banks into the 128+1 bank numbers that the soundfont specification offers? You can use any standard GM soundfont to try it. Running FluidSynth in XG-mode already has the soundbank/drumbank fallback scheme in place. So any soundbank/drumset that isn't found, it reverts to using the GM soundbank/drumset. Poor-man's XG, or at least a simplest starting point. Of course, different drumbanks will have different instrument-note mapping. Similarly, in hardware, same instrument in different soundbanks will sound differently because they would use different special effects parameters on the same sound samples. Some funky drumset mapping may sound wierd because the same note in that drumset may be mapped to a whistle in default GM standard drumset, for example. To get that in FluidSynth, custom soundfonts would be needed. Note that it does print out a warning/info on the Fluidsynth console (commandline output) when it could not locate a soundbank number (in decimal). This way, folks can see what particular soundbank is expected by that specific XG-MIDI file (or XG hardware), should they want to do some custom soundfont mapping. Again, the number being used and printed out right now is truncated to 7-bit (CC32 only). Fluidsynth needs my rejected patch to properly print the full 14-bit (CC0/CC32) number (used by the XG-MIDI file, or XG-harware) correctly. Using the basic GM soundfont for XG-mode is similar to my other patch in GM-mode when an instrument is not found in some soundbank, it reverts to using the same instrument number in the default soundbank (bank=0). Prior to that patch, Fluidsynth simply ignored that instrument, no sound would be heard at all for that channel until an exact instrument requested was found (some sound banks only have a few instruments mapped). A live reset command (while continue playing) would of course set that instrument to piano, should one tries to at least hear something is playing on that channel (or determine if some MIDI events even get to that channel at all). The fallback scheme, I believe is vailable in both XG and GS in some way. I also believe that is what all GM hardwares do, too. This is the rationals around the original request for my patch in GM-mode fallback instrument lookup. Try any hardware keyboard, or hardware sound module, connect to it via MIDI cable and request an invalid CC0/CC32 and progChange request, it would never silence that channel (as FluidSynth did at that time). It most likely will keep the current instrument, or use some fallback mapping of sort. Those patches I wrote for XG-mode already in FluidSynth simply uses the particular resources if they are available, if not it would try to do a reasonable cascading substitution to some equivalence instruments/drumsets within that GM/XG mode. I had previously explained these instrument mapping (in GM-mode) back when Josh/Element Green was applying such patches, as well as CC0/CC32 mapping when I submitted the XG-related patches. In XG-mode for XG-hardwares, if I remember correctly, they use CC0=121/CC32=0 as their default/fallback soundbank (don't remember if this is written to use that before using the GM-default in FluidSynth XG-mode). Such soundbank sounds much better than the GM-mode default soundbank in those hardwares. So they can claim that XG harwares/softwares sounds much better than GM sounds. Pure marketing B.S, it's their mapping that make GM-mode sound bad in those hardwares/softwares. GS-hardwares do similar things, I believe. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
2012-07-10 22:26, jimmy skrev: Oops, I hit reply instead of reply all. Trying again to post to the mailing list. --- On Tue, 7/10/12, David Henningssondi...@ubuntu.com 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. The XG spec is the easy one to find: http://web.archive.org/web/20060926124939/http://www.yamaha.co.uk/xg/reading/pdf/xg_spec.pdf The GM1 and GM2 specs are AFAIK not available for free online, but can be bought from MMA: http://www.midi.org/techspecs/gm.php I have not bought these specs, and nobody in this community has either, which might also be part of the problem here. Maybe I should buy them - it might save us some discussions... I don't know if GS specs are available at all, and if so, where you can find them. Apart from GM1, GM2, XG and GS, I don't know of any other specification or standard, so I'm not sure exactly what you mean with MIDI-1, MIDI-2, or Full MIDI specs which you talk about below. Could you explain these three terms, where you find specifications for them, and so on? 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. Again, I'm open to extending FluidSynth to load several soundfont files and place them at different places in the MSB/LSB address space, if we figure out a good scheme for how that would work. Let's start there. I'm also open to extending the XG mode to make use of that feature, once that feature is complete. 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. Hopefully the above link to the XG specification will be helpful for you. It does contain some interesting information on bank selection and how to fall back if a current preset/bank is not available. 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. Ok, fair point. That's what my patch in the MSB function tries to fix. In other words, the MMA style is
Re: [fluid-dev] Soundfont banks
I really don't want to fuel the fire here, but I'd just like to speak with some experience on both sides of the patch/pull game. 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. I've been observing this conversation, and while I do think the reaction to the original mail (on a completely different topic by a different contributor) was overly negative, there also has to be room in a software project to say no. My understanding of the project is that there aren't a lot of people contributing, nor do the people at the top have much time to give. Therefore, proposing drastic changes is probably not going to be feasible, even if it's theoretically a good idea. 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). It's more complicated than saying to the project leads I don't expect you to deal with this, I'll do the research and the work. The problem is that ultimately, someone who owns the project will need to understand this stuff in order to accept it. They will need to review your patch and understand how it fits in with the overall system and the interests of many users. For example, whether including this patch will break other users in some obscure case, or whether it will pull in too many dependencies. If you are proposing a non-trivial amount of work for yourself to do, it *will*ultimately end up becoming a non-trivial amount of work for someone else as well. There's also the fact that if you submit it, you may not be around to maintain it, and then people like David will have to understand it even better to fix it when it breaks. I'm not trying to be a nay-sayer and block progress. I just want to make the point that sometimes, as a project lead, it isn't a good idea to embark on a large new feature with a contributor you don't know well, especially if you don't have much time to give to the project yourself. In any case, getting angry doesn't help. It can be frustrating when nobody is accepting your patch. You should assume they have forgotten, as opposed to deliberately ignored you. It never hurts to wait a week and then post a follow-up: Just checking if anybody has gotten around to looking at my patch yet? Matt ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
On Jul 11, 2012, at 08:41 AM, Matt Giuca matt.gi...@gmail.com wrote:I really don't want to fuel the fire here, but I'd just like to speak with some experience on both sides of the patch/pull game.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.I've been observing this conversation, and while I do think the reaction to the original mail (on a completely different topic by a different contributor) was overly negative, there also has to be room in a software project to say "no." My understanding of the project is that there aren't a lot of people contributing, nor do the people at the top have much time to give. Therefore, proposing drastic changes is probably not going to be feasible, even if it's theoretically a good idea.Hello MattThe OP for the previous thread was clearly willing to work in a step-by-step manner so the problem was not really a question of patching drastic changes.It's more complicated than saying to the project leads "I don't expect you to deal with this, I'll do the research and the work." The problem is that ultimately, someone who "owns" the project will need to understand this stuff in order to accept it. They will need to review your patch and understand how it fits in with the overall system and the interests of many users. For example, whether including this patch will break other users in some obscure case, or whether it will pull in too many dependencies. If you are proposing a non-trivial amount of work for yourself to do, it will ultimately end up becoming a non-trivial amount of work for someone else as well. There's also the fact that if you submit it, you may not be around to maintain it, and then people like David will have to understand it even better to fix it when it breaks.I'm not trying to be a nay-sayer and block progress. I just want to make the point that sometimes, as a project lead, it isn't a good idea to embark on a large new feature with a contributor you don't know well, especially if you don't have much time to give to the project yourself.The sad thing is that the project may have lost an extremely talented potential contributor all because of resolute resistance not consistent with fact.E___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
--- On Mon, 7/9/12, David Henningsson di...@ubuntu.com wrote: Sadly, my patch never made it to the SVN code base, so the XG-mode soundbank selection and drumbank selection never worked in the official FluidSynth code base. You do have a bank selection patch merged, see: http://sourceforge.net/apps/trac/fluidsynth/changeset/401/ Did you not see this, are you referring to another patch, or was the patch changed (before commit) in a way that broke it, or...? That change was only a partial implementation, I think it might allow for setting a channel to drum mode. My additional patch was never applied, which deals with the MIDI event handling and MIDI file usage of the combined [MSB, LSB] mapping -- again only in XG-mode. Read below for more of what my code would do. In other words, GS-mode hardwares only use 128 banks of 128 instruments for any particular hardware family. That's a limitation of using only MSB (7-bit number) for limiting bank selection. Yamaha XG hardwares, on the other hand use the more logical ordering of bits in the 14-bits numbers. They use combination of MSB and LSB to signify specific banks, including drum banks. Which allows for addressing fuller range of [16384 banks] x [128 instruments]. Of course, some numbers may have already been used by older hardware, and for backward compatibilities, some of those numbers may be avoided for the time being. But still, much more number of banks can be used in XG-mode. Not only that, MIDI-2 instruments of more recent years, all use the combination of MSB and LSB for bank selection. . . . Sorry for ripping the above out of context. The wBank number in the text above, specifically refers to the saved number in the soundfont file, rather than a calculation based on bank MSB and bank LSB. The wBank number is 128 (that is 128 zero based, i e 1000 in binary) for percussion, which gives up to 128 different kits given different wPresets. I have also verified, with Swami, that that's how the big fluid-soundfont-gm and fluid-soundfont-gs soundfonts are constructed. Do you have other soundfonts that work differently? So, the question of how to map the 14-bit number used in XG (and MIDI-2?) modes, to the Soundfont's wBank number, is still the tricky issue here. That is, with your patch in, I thought we had come up with something that worked reasonably well. // David Read the points I tried to make in my prevous message as quoted. Soundfont specs is a bastardized standard, to partially support MIDI. MIDI supports 128x128 banks, Sounfont specs chose to only allow 128 in their infinite wisdom. I brought up the point before and asked what to do with the MIDI spec. I got no answer from you or Pedro. When there is a will, there is a way. To move forward to full MIDI 128x128 soundbanks, FluidSynth can move beyond the 128 soundbank limitation (of SoundFont specs) without breaking the Soundfont specs in anyway. Just think of a sound font file as 128 sound banks, plain and simple. Now to support 128x128 soundbanks, just find a way to allow loading and using 128 different soundfonts simultaneously. Assuming the current situation as the default soundfont, index=0. For GM, MIDI2, XG, the current soundfont should map to MSB (CC0) value 0. Supporting that idea could be done various ways, one simple way is to say each soundfont file maps to one unique MSB number (for GM/MIDI2/XG mode, use LSB for GS mode), specifiy that in a config file, or some function parameters (for library loading), or commandline options... Again, this doesn't break Soundfont specs. It may work differently from current behavior. Because right now, loading multple soundfonts just override each other in the confined space of one set of 128 soundbanks. Which is not quite a full-MIDI support. Also, as MIDI hardware always do, if a specific soundbank is not valid (not implemented, no such instrument-set, no such drum-set), either keep the existing bank/instrument, or revert to the default (selection number=0) bank/instrument. Which is how my rejected patch try to do in XG-mode with FluidSynth. For example, in XG-mode with my patch, if the MIDI-file or MIDI events from MIDI cable try to use [MSB, LSB] soundbank of [120, 87], for the time being my patch would map that to [0, 87] for normal channel, or map to [0, 87] for drum channel, until FluidSynth can support loading 128 different soundfonts for full MIDI mapping. Assuming there is a soundbank at 87, it would be used. If there is no soundbank 87, it would try soundbank [0, 0] for normal channels, or soundbank [0, 127] for drum channels. I also think that's how things should work with GM-mode, and MIDI2-mode. Currently FluidSynth can't deal with [MSB, LSB] combination, so it is very broken with respect to full MIDI handling for soundbank, the way I see it. I pointed this out in my previous posting
Re: [fluid-dev] Soundfont banks
Note that chan-sfont_bank_prog does have the space for the full 14-bit [MSB, LSB] combination in place. And yes, the FLUID_BANK_STYLE_MMA handles the 14-bit combination of [MSB, LSB] just fine in those 2 functions. You and Pedro simply cripled XG-mode by rejected my changes. --- The patch I submitted, which was not applied: diff -pur fluidsynth.svnRev405.20110207/src/synth/fluid_chan.c fluidsynth.svnRev405.20110207.jnSysex/src/synth/fluid_chan.c --- fluidsynth.svnRev405.20110207/src/synth/fluid_chan.c2011-02-07 20:29:48.0 -0500 +++ fluidsynth.svnRev405.20110207.jnSysex/src/synth/fluid_chan.c 2011-02-09 17:20:05.0 -0500 @@ -239,7 +239,7 @@ fluid_channel_set_bank_lsb(fluid_channel oldval = chan-sfont_bank_prog; if (style == FLUID_BANK_STYLE_XG) - newval = (oldval ~BANK_MASKVAL) | (banklsb BANK_SHIFTVAL); + newval = (oldval ~BANKLSB_MASKVAL) | (banklsb BANK_SHIFTVAL); else /* style == FLUID_BANK_STYLE_MMA */ newval = (oldval ~BANKLSB_MASKVAL) | (banklsb BANK_SHIFTVAL); chan-sfont_bank_prog = newval; @@ -259,6 +259,9 @@ fluid_channel_set_bank_msb(fluid_channel /* The number 120 was based on several keyboards having drums at 120 - 127, reference: http://lists.nongnu.org/archive/html/fluid-dev/2011-02/msg3.html */ chan-channel_type = (120 = bankmsb) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC; +oldval = chan-sfont_bank_prog; +newval = (oldval ~BANKMSB_MASKVAL) | (bankmsb (BANK_SHIFTVAL + 7)); +chan-sfont_bank_prog = newval; return; } - The first part, in handling LSB, @@ -239,7 +239,7 @@ fluid_channel_set_bank_lsb(fluid_channel oldval = chan-sfont_bank_prog; if (style == FLUID_BANK_STYLE_XG) - newval = (oldval ~BANK_MASKVAL) | (banklsb BANK_SHIFTVAL); + newval = (oldval ~BANKLSB_MASKVAL) | (banklsb BANK_SHIFTVAL); The current code blindly wipe out the full 14-bit mask via [ ~BANK_MASKVAL], which means a change to LSB, will set/reset MSB to 0. Which is completely wrong!!! It should be handled the same way of FLUID_BANK_STYLE_MMA. For recent XG hardware, MIDI messages come in the order of MSB, LSB, progChange. If LSB event sets MSB to 0 no matter what, just be cause you don't care for any value beyond LSB (max of 128 soundbanks), that's just freaking asinine!!! No such restriction for FLUID_BANK_STYLE_MMA mode in that same function!!! Note that XG use of [MSB, LSB] is no different from FLUID_BANK_STYLE_MMA. My patch here will just change the LSB as it should be, don't mess with MSB here. The second part, in handling MSB, @@ -259,6 +259,9 @@ fluid_channel_set_bank_msb(fluid_channel /* The number 120 was based on several keyboards having drums at 120 - 127, reference: http://lists.nongnu.org/archive/html/fluid-dev/2011-02/msg3.html */ chan-channel_type = (120 = bankmsb) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC; +oldval = chan-sfont_bank_prog; +newval = (oldval ~BANKMSB_MASKVAL) | (bankmsb (BANK_SHIFTVAL + 7)); +chan-sfont_bank_prog = newval; The existing XG code path was a patch from me to allow setting a channel as a drum-channel, it returns out of the function without really setting the MSB value, which is missing my rejected patch. But the code prior to that didn't properly handle XG-mode drum channels correctly either, as you could see with: if (style == FLUID_BANK_STYLE_GM || chan-channel_type == CHANNEL_TYPE_DRUM) return; /* ignored */ My patch would properly set the XG-mode MSB value the way it should be, before return from that function. This should be no different than the way FLUID_BANK_STYLE_MMA is handled. Although, I think current code won't deal with FLUID_BANK_STYLE_MMA drum-channel MSB properly, because of the if-statement above. But I'm not concerned with MMA-mode for the time being. Because you and Pedro don't care or XG-mode use of MSB. You and Pedro sticking it to me, quoting some lame maximum 128 soundbanks limits, and my patch for MSB value-change never got applied. Let me say it again, this XG-mode setting of [MSB, LSB] should be no different than the way FLUID_BANK_STYLE_MMA is set, which is already in place in these functions. My other changes that you quoted, was applied for allowing any channel to use as Drum-channel. I had patches for several different things back then, including some SysEx patches for XG, some typo in existing code, some inconsistent commandline parameter of volume gain of 5 maximum in one place and 10 in another place --- Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
On 07/10/2012 12:56 PM, jimmy wrote: Read the points I tried to make in my prevous message as quoted. Soundfont specs is a bastardized standard, to partially support MIDI. MIDI supports 128x128 banks, Sounfont specs chose to only allow 128 in their infinite wisdom. I brought up the point before and asked what to do with the MIDI spec. I got no answer from you or Pedro. 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. When there is a will, there is a way. To move forward to full MIDI 128x128 soundbanks, FluidSynth can move beyond the 128 soundbank limitation (of SoundFont specs) without breaking the Soundfont specs in anyway. Just think of a sound font file as 128 sound banks, plain and simple. Now to support 128x128 soundbanks, just find a way to allow loading and using 128 different soundfonts simultaneously. Assuming the current situation as the default soundfont, index=0. For GM, MIDI2, XG, the current soundfont should map to MSB (CC0) value 0. Supporting that idea could be done various ways, one simple way is to say each soundfont file maps to one unique MSB number (for GM/MIDI2/XG mode, use LSB for GS mode), specifiy that in a config file, or some function parameters (for library loading), or commandline options... Again, this doesn't break Soundfont specs. It may work differently from current behavior. Because right now, loading multple soundfonts just override each other in the confined space of one set of 128 soundbanks. Which is not quite a full-MIDI support. 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. 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. Also, as MIDI hardware always do, if a specific soundbank is not valid (not implemented, no such instrument-set, no such drum-set), either keep the existing bank/instrument, or revert to the default (selection number=0) bank/instrument. Which is how my rejected patch try to do in XG-mode with FluidSynth. For example, in XG-mode with my patch, if the MIDI-file or MIDI events from MIDI cable try to use [MSB, LSB] soundbank of [120, 87], for the time being my patch would map that to [0, 87] for normal channel, or map to [0, 87] for drum channel, until FluidSynth can support loading 128 different soundfonts for full MIDI mapping. Assuming there is a soundbank at 87, it would be used. If there is no soundbank 87, it would try soundbank [0, 0] for normal channels, or soundbank [0, 127] for drum channels. I also think that's how things should work with GM-mode, and MIDI2-mode. Currently FluidSynth can't deal with [MSB, LSB] combination, so it is very broken with respect to full MIDI handling for soundbank, the way I see it. 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. I pointed this out in my previous posting on the mailing list without a response from you or Pedro. Moving along, I still think FluidSynth should support loading and using up to 128 separate soundfont files in their separate 128 slots, instead of cramming multiple soundfonts into one slot the way things work right now. Of course, I'm not saying you or Pedro have to implement that. I'm trying to say things aren't even MIDI-1 compliant, let alone MIDI-2. 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. Acknowledging that, then perhaps there is hope of finding a way to add code to support the missing MIDI feature. What I'm trying to say is Soundfont specs alone is inadequate for full MIDI support. If you and Pedro only care about Soundfont specs, don't care for MIDI specs, then that's your perrogatives. I do want MIDI supports. Implementing that would take some work, but not if patches are ignored. Patches are more likely to be accepted if we first agree on what should be implemented. My rejected patch deals with that broken handling of [MSB, LSB] in a limited way in XG-mode, but was rejected because you and Pedro
Re: [fluid-dev] Soundfont banks
Oops, I hit reply instead of reply all. Trying again to post to the mailing list. --- On Tue, 7/10/12, David Henningsson di...@ubuntu.com 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
Re: [fluid-dev] Soundfont banks (was: Re: OSC support)
--- On Mon, 7/9/12, David Henningsson di...@ubuntu.com wrote: From: David Henningsson di...@ubuntu.com Subject: Soundfont banks (was: Re: [fluid-dev] OSC support) To: FluidSynth mailing list fluid-dev@nongnu.org Cc: jimmy wg20...@yahoo.com Date: Monday, July 9, 2012, 6:55 AM On 07/09/2012 03:07 PM, jimmy wrote: SoundBlaster soundfont specs only allow 128 banks of 128 instruments -- That's what I get from Pedro and David. When ask about MIDI specs support for MSB (128 selections) and LSB (128 selections) for sound banks, they didn't have an answer. As for following specs or not, I'm pragmatic about it. I'd like to follow the specs whenever possible, but if something else proves useful to a lot of people, and does not break it for other people, I'm okay with merging such patches. As for soundfonts, I remember having discussions on how to best map CC0 and CC32 to the SoundFont's wBank value in different GM/GS/XG/GM2 modes, which was not trivial to answer. Therefore we have the synth.midi-bank-select option that uses different mappings depending the mode you select. Isn't that option working for you? My patch specifically allows XG-soundbankd and XG-drumbank selections, and only in XG-mode. XG-drumbanks can be at various MSB bank values of 120, 126, 127... in combination with various LSB bank values for different XG hardwares. Again, my patch only affects XG-mode. It allows Drumbanks to be used by any channel, not just channel 9 (10 with 1-starting-index). It also allows multiple drum channels at the same time, with is used by various XG hardwares and XG-MIDI files. Sadly, my patch never made it to the SVN code base, so the XG-mode soundbank selection and drumbank selection never worked in the official FluidSynth code base. As for the soundfont spec, it both says: MIDI CC0 Bank Select - When received, the following program change should select the MIDI program in this bank value instead of the default bank of 0 MIDI CC32 Bank Select LSB - When received, may behave in conjunction with CC0 Bank Select to provide a total of 16384 possible MIDI banks of programs. It means, by default, the value of CC0 and CC32 is assumed to be 0 (zero). Let me use 0-starting-index number here. Some instruments use 1 ss starting index, so adjust those numbers accordingly. Some earlier hardwares only use MSB, only send MSB (CC0), never send LSB (CC32). That's what [MIDI CC32 Bank Select LSB - When received,] tries to clarify. CC0 and CC32 each has 7-bits (0-127 in decimal values). So each is capable ot 128 values, putting them side-by-side, that's a 14-bit binary number that is 0-16383, or 16384 distinct numbers. Some vendors (including, but not just Roland and Yamaha) went about implementing it for their MIDI hardwares. It should not really matter if they follow the 14-bit numbering for calculating any of 16384 distinct banks. I look at it as MSB (Most Significant Bits) means higher-order bits like the hundreds or thousands, and LSB (Least Significant Bits) means the first few numbers when we start counting. Although, some people took short-cut, especially in Softwares, emulating Roland GS soundbank selection. For example, some earlier Roland GS hardware and software modules only use MSB (CC0), and assume LSB (CC32) to be 0. In other words, they simply ignored LSB (CC32) in those hardware and software GS-mode modules. So, some third-party hardware and software emulation of GS-mode simply use 7-bits of MSB for the soundbanks switching, completely ignore the LSB (CC32). If those third-party folks had use the 14-bit number from the beginning, simply zero-ing out the LSB (CC3) for bank selection, it would be simple to move forward. Here's a description of how Roland GS hardwares do (changes with successive hardware releases): https://en.wikipedia.org/wiki/Roland_GS Typically, cc#32 (Bank Select LSB) was used to select a family (i.e. 1 - SC-55, 100 - MT-32 etc.) then cc#0 (Bank Select MSB) was used to set a particular variation bank. In other words, it should have been the other way around. But, they use LSB for the different hardwares ID. Each hardware uses MSB for the maximum of 128 soundbanks of 128 instruments per bank. That's the [128 banks] x [128 instruments] limit per family of hardware, designated by the Hardware ID used by LSB (CC32). In other words, GS-mode hardwares only use 128 banks of 128 instruments for any particular hardware family. That's a limitation of using only MSB (7-bit number) for limiting bank selection. Yamaha XG hardwares, on the other hand use the more logical ordering of bits in the 14-bits numbers. They use combination of MSB and LSB to signify specific banks, including drum banks. Which allows for addressing fuller range of [16384 banks] x [128 instruments]. Of course, some numbers may have already been used by older hardware, and for backward compatibilities, some of those
Re: [fluid-dev] Soundfont banks
On 07/09/2012 05:39 PM, jimmy wrote: --- On Mon, 7/9/12, David Henningsson di...@ubuntu.com wrote: From: David Henningsson di...@ubuntu.com Subject: Soundfont banks (was: Re: [fluid-dev] OSC support) To: FluidSynth mailing list fluid-dev@nongnu.org Cc: jimmy wg20...@yahoo.com Date: Monday, July 9, 2012, 6:55 AM On 07/09/2012 03:07 PM, jimmy wrote: SoundBlaster soundfont specs only allow 128 banks of 128 instruments -- That's what I get from Pedro and David. When ask about MIDI specs support for MSB (128 selections) and LSB (128 selections) for sound banks, they didn't have an answer. As for following specs or not, I'm pragmatic about it. I'd like to follow the specs whenever possible, but if something else proves useful to a lot of people, and does not break it for other people, I'm okay with merging such patches. As for soundfonts, I remember having discussions on how to best map CC0 and CC32 to the SoundFont's wBank value in different GM/GS/XG/GM2 modes, which was not trivial to answer. Therefore we have the synth.midi-bank-select option that uses different mappings depending the mode you select. Isn't that option working for you? My patch specifically allows XG-soundbankd and XG-drumbank selections, and only in XG-mode. XG-drumbanks can be at various MSB bank values of 120, 126, 127... in combination with various LSB bank values for different XG hardwares. Again, my patch only affects XG-mode. It allows Drumbanks to be used by any channel, not just channel 9 (10 with 1-starting-index). It also allows multiple drum channels at the same time, with is used by various XG hardwares and XG-MIDI files. Sadly, my patch never made it to the SVN code base, so the XG-mode soundbank selection and drumbank selection never worked in the official FluidSynth code base. You do have a bank selection patch merged, see: http://sourceforge.net/apps/trac/fluidsynth/changeset/401/ Did you not see this, are you referring to another patch, or was the patch changed (before commit) in a way that broke it, or...? As for the soundfont spec, it both says: MIDI CC0 Bank Select - When received, the following program change should select the MIDI program in this bank value instead of the default bank of 0 MIDI CC32 Bank Select LSB - When received, may behave in conjunction with CC0 Bank Select to provide a total of 16384 possible MIDI banks of programs. It means, by default, the value of CC0 and CC32 is assumed to be 0 (zero). Let me use 0-starting-index number here. Some instruments use 1 ss starting index, so adjust those numbers accordingly. Some earlier hardwares only use MSB, only send MSB (CC0), never send LSB (CC32). That's what [MIDI CC32 Bank Select LSB - When received,] tries to clarify. CC0 and CC32 each has 7-bits (0-127 in decimal values). So each is capable ot 128 values, putting them side-by-side, that's a 14-bit binary number that is 0-16383, or 16384 distinct numbers. Some vendors (including, but not just Roland and Yamaha) went about implementing it for their MIDI hardwares. It should not really matter if they follow the 14-bit numbering for calculating any of 16384 distinct banks. I look at it as MSB (Most Significant Bits) means higher-order bits like the hundreds or thousands, and LSB (Least Significant Bits) means the first few numbers when we start counting. Although, some people took short-cut, especially in Softwares, emulating Roland GS soundbank selection. For example, some earlier Roland GS hardware and software modules only use MSB (CC0), and assume LSB (CC32) to be 0. In other words, they simply ignored LSB (CC32) in those hardware and software GS-mode modules. So, some third-party hardware and software emulation of GS-mode simply use 7-bits of MSB for the soundbanks switching, completely ignore the LSB (CC32). If those third-party folks had use the 14-bit number from the beginning, simply zero-ing out the LSB (CC3) for bank selection, it would be simple to move forward. Here's a description of how Roland GS hardwares do (changes with successive hardware releases): https://en.wikipedia.org/wiki/Roland_GS Typically, cc#32 (Bank Select LSB) was used to select a family (i.e. 1 - SC-55, 100 - MT-32 etc.) then cc#0 (Bank Select MSB) was used to set a particular variation bank. In other words, it should have been the other way around. But, they use LSB for the different hardwares ID. Each hardware uses MSB for the maximum of 128 soundbanks of 128 instruments per bank. That's the [128 banks] x [128 instruments] limit per family of hardware, designated by the Hardware ID used by LSB (CC32). In other words, GS-mode hardwares only use 128 banks of 128 instruments for any particular hardware family. That's a limitation of using only MSB (7-bit number) for limiting bank selection. Yamaha XG hardwares, on the other hand use the more logical ordering of bits in the 14-bits numbers. They use combination of MSB and LSB
