Re: [fluid-dev] Proposal: FluidSynth tester program
--- On Sat, 8/4/12, "Aere Greenway" wrote: > Where it has been stated that there are no fluidsynth > dependencies on > jack, I think you should re-examine that claim, based on the > problems I > encountered. Fluidsynth can be compiled with just Alsa, no need for Jack. So the claim is valid. What you see is the package requirements from your Ubuntu repositories. Where Ubuntu package folks decide to compile Fluidsynth with jack support, so that is distro-related default requirements. And it is common practice with most other Linux distros, too. Similarly the Linux kernel can be compiled for a cell phone with no supports, or dependencies on PCI, PCI-X, PCI-E bus, VGA, XGA display, IDE hard drive, parallel port... Knowing that it can be done, but you probably don't want that as your default boot-up kernel for your i386, or i586 PC. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Apt package dependencies -- WAS Re: Proposal: FluidSynth tester program
--- On Sun, 8/5/12, jimmy wrote: > If you still don't understand what I have written, it would > still be a big baffling mistery for you. Sorry, "mystery" not "mistery". More on decoding "apt-get" command you used. From the info you posted: >>> aere@Aere-HP-Vectra:~/fluidsynth-1.1.6$ sudo apt-get build-dep fluidsynth Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: jackd2 jackd2-firewire libjack-jackd2-0 The following NEW packages will be installed: jackd1 libjack-dev libjack0 0 upgraded, 3 newly installed, 3 to remove and 0 not upgraded. Need to get 0 B/637 kB of archives. After this operation, 371 kB of additional disk space will be used. Do you want to continue [Y/n]? Y Preconfiguring packages ... (Reading database ... 218822 files and directories currently installed.) Removing jackd2-firewire ... dpkg: libjack-jackd2-0: dependency problems, but removing anyway as you requested: zita-at1 depends on libjack-jackd2-0 (>= 1.9.5~dfsg-14) | libjack-0.116; however: Package libjack-jackd2-0 is to be removed. Package libjack-0.116 is not installed. Package libjack-jackd2-0 which provides libjack-0.116 is to be removed. Package libjack0 which provides libjack-0.116 is not installed. sndfile-tools depends on libjack-jackd2-0 (>= 1.9.5~dfsg-14) | libjack-0.116; however: Package libjack-jackd2-0 is to be removed. Package libjack-0.116 is not installed. Package libjack-jackd2-0 which provides libjack-0.116 is to be removed. Package libjack0 which provides libjack-0.116 is not installed. . . . [with many more messages about packages depending on "libjack-jackd2-0"] <<< You need to understand the messages from that command, apt-get build-dep fluidsynth it tells you exactly what it woud do: The following packages will be REMOVED: jackd2 jackd2-firewire libjack-jackd2-0 The following NEW packages will be installed: jackd1 libjack-dev libjack0 Which is NOT what is needed by the currently testing Fluidsynth version. Apparently, "build-dep fluidsynth" in your repository still refer to some old-old version of fluidsynth development packages which explicitly requires: jackd1 libjack-dev libjack0 but these are jack 1.x packages. If you proceed, it tell you that: The following packages will be REMOVED: jackd2 jackd2-firewire libjack-jackd2-0 You have to read that and understand the implication of answering "Yes" to proceed with that command. In order for you to compile the currently testing version of Fluidsynth, you should have answered "No" to quit that command. Because, obviously the repository you are using is very outdated as far as Fluidsynth is concerned. It means you have to manually figure out, and install all the package dependencies for the current Fluidsynth version and not depend on "apt-get" to resolve such dependencies for you. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Apt package dependencies -- WAS Re: Proposal: FluidSynth tester program
--- On Sun, 8/5/12, Aere Greenway wrote: > > The problem I am experiencing is with trying to run a test > of the fluidsynth release candidate. > Again, the real problem was depencies around a package that was alread installed on your system: libjack-dev which requires libjack0 which is jack 1.x. Any attempt to load anything require jack 2.x would not actually install jack 2.x at all. Until you explicitly remove both libjack-dev and libjack-dev which give you a clean slate relating to jack. Once that is done, you can install jack 2.x. Otherwise, none of jack 2.x would get installed on that system, and you should have problem with the currently being tested FluidSynth -- because current Fluidsynth requires jack 2.x for testing (I believe). If you still don't understand what I have written, it would still be a big baffling mistery for you. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Apt package dependencies -- WAS Re: Proposal: FluidSynth tester program
--- On Sun, 8/5/12, Aere Greenway wrote: > Given the problems I had getting qjackctl to co-exist with > the generated > version of fluidsynth, I am puzzled by why I had no problems > with my > Ubuntu partition. My guesses why are as follows: > > 1. I had previously done some testing of a Rosegarden fix, > and it has > similar dependencies to fluidsynth. Notably, it wants > jackd1 (rather > than jackd2, which qjackctl causes to be installed). > All this was > in-place and working before I attempted to build > fluidsynth. > > 2. I am using Ubuntu, rather than Xubuntu. I don't use Ubunto, nor Xubuntu, so I don't know the current "version" various packages like libjack, qjackctl... and pre-requisites of each of those. I use Debian Sid (Unstable repository), so the version of various packages available there are fairly recent. For example qjackctl in Sid would probably want jackd2. However, Debian Stable repository would (more likely) have much older "version" of qjackctl and related pre-requisite packages. I mention that just as an example. And everytime there is an update to the repository, some of those packages may require different pre-requisites. So some of your currently installed packages will get out of sync with the repositories, until you decide to install the latest and greatest version for each of those packages. In your case, it may not be fluidsynth and qjackctl which causes the dependency issues. It might be some other music related packages that you were playing with. I saw in one of your other posts mentioned: libjack-dev which I believe might be a set of jack 1.x development header files. If that is true, that package would require libjack 1.x libraries package, which cannot be installed concurrently with any jack 2.0 packages, at least from the perspective of the repository installation script when it tries to verify pre-requisites. I suppose you were toying with some apps that was still using jack 1.0 sometime ago which needed the jack 1.0 header files to compile. So that package was installed in the system was still there. Currently, most music packages that use jack do use jack 2.x. And the repository won't let you do that because jack 1.x and jack 2.x are mutully exclusive. It won't automatically remove all of jack 1.x packages and additional packages which need jack 1.x. The sticking point in your case was probably libjack-dev note that libjack-dev also need libjack0. What you need to do is to explicitly remove all the jack 1.x packages, then go ahead and install any jack 2.x packages that you want. The equivelance jack 2.x of that would be libjack-jackd2-dev which needs libjack-jackd2-0 package. When you try to remove all jack 1.x packages, it will also tell you what other packages were "also" to be removed, those would be the packages that depends on those jack 1.x packages. After installing jack 2.x packages you want, you can try to manually install those packages (not Jack itself) which were removed when you remove jack 1.x. I run apt-get -d install somepackage the "-d" say to download only. Which will show you what packages it would install or remove if it is to install "somepackage". If it won't remove any of the new jack 2.x packages, then I would let it completely download all the files it need. Then run: apt-get install somepackage which is the same command without the "-d" to go ahead and install "somepackage". So yes, while you were removing and purging some of those packages, it finally remove enough of jack 1.x packages to let you install jack 2.x in the system. The reverse is also true. If any packages which explicitely require some jack 1.x but not compatible with jack 2.x will not install if jack 2.x is already in the system until you explicitely remove jack 2.x. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
--- On Mon, 7/16/12, David Henningsson 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] Proposal: FluidSynth tester program
On Wed, 11 Jul 2012 20:57, David Henningsson wrote: > Something I've been thinking of for a while, and the recent > thread > reminded me of that thought... > > FluidSynth is quite a versatile program/library, and we all > want > different things out of it. No one of us has the full > picture, or uses > FluidSynth to all the different things it can be used for. > Making sure that none of all these use cases break, is one > of > FluidSynth's biggest challenges, and maybe sometimes it can > cause us to > be overly cautious. Same thing can be said for most softwares out there. I agree about being cautious, too. I definitely don't want malware backdoors in any softwares, or buggy softwares either. Although, being an open source community, it's the code contribution that make the software grow. Imagine Linus writing all the changes alone, by himself, for the Linux kernel in it's current form? That would be insane. I doubt that Linus even fully understand much of what's in the hundreds of device drivers in the kernel, nor the hardware to test those himself. Can't even test all those changes even if he has all the hardwares working in his lab(s), let alone having an "RC" (release candidate) available every weekend for people to test. > Here's a proposal that might help us with that challenge. > > . . . > > What do you think? It obviously won't be much of a tester > program > without a bunch of testers, so is this anything you think > would make so > much sense, that you would be willing to run a test or two > yourself? A 2-3 week testing period of some "release candidate" would help before a new release anyway. People's hardware and software configurations can and will change as machine break down, and replaced, as well as new releases of libraries, compilers... It would be good to have a skeletal test-report to fill out, and posted, so folks would have an idea of hardware/software, which distribution, 32/64-bit OS... Not sure if we need the library and compiler version number, but it shouldn't hurt if those are reported back. Some people might be on vacation, busy, out-sick... But as folks in the FS-dev mailing list subscribers, let's way every "release candidate" announcement should encourage everyone here to do a test and report back. Can't force anyone, but just say we hope folks here will help track down any potential bugs anyway. Of course, any bug(s) found, confirmed, and fixed should result in a new "release candidate" to be tested again, reset the testing time period. After a few rounds, we would have an idea of how many test-reports and what environments each "release candidate" got tested, along with how many problems found... Not quite as formal as some automated test-suite, but would help along the way. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
a new layer on top of FluidSynth, but there may be times when some features might be needed from FluidSynth to deal with the various info. Outside the XG-mode via my earlier patch(es), there's no way to use multiple drum channels, except adding the full 16-channels, remember to differentiate those channels, may have to add rules to MIDI router of some sort, just to use that one extra drum channel. Talking about twisted logic by some people with their GM-specs interpretation. Sad, but true. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
at the "no soundbank switching" as "the GM specs". I call that the "minimalist, default soundbank in GM-mode", provided as a "compatibility mode" back in the era when most instruments did not even have a "single" complete soundbank. GM specs also include CC0/CC32. Without numerous CC# events, it wouldn't be MIDI standard at all. By "default soundbank", I mean that GM specs allows for using CC0/CC32 to change to other soundbanks. But if no such additional soundbank was available for that CC0/CC32 combo, it would revert to use the "default soundbank". Of course, interpretation from 20, 30 years ago was the struggle to provide even one common soundbank for all hardwares. Nowaday, if any musical instrument come out providing just one single soundbank, make sure your calendar didn't show April 1st. > I'm also open to extending the XG mode to make use of that > feature, once > that feature is complete. Let me state my opion again here, that XG is just a play on GM-specs. If FluidSynth has proper support for GM specs, XG should not be a big deal. GM-specs include numerous CC# messages. Currently my point of contention is lack of full CC0/CC32 support (which is part of GM-specs). For those interested, a list of those can be found here: http://home.roadrunner.com/~jgglatt/tech/midispec/ctllist.htm I don't even know most of those things. Even the CC7 Volume (coarse) was at one time referred by some as "Master volume" for some hardwares, probably a carry over from some MIDI-controller, or some simple synth with just a few sounds which transmits on only a single channel. More recently it is used more appropriately as "channel volume". GM specs do not explicitly forbid drumset usage in other channels. It simply suggest that channel 9 be used for drum. What if someone want to use more than one drum-sets at the same time? GM specs didn't explicitly address that, but a flexible GM implementation should not forbid such usage either. GM2 suggests 2 specific channels for drums. What if someone want to use 3 drum channels, or use some other channel for drum instead? One of the XG-MIDI files above wanted 3 drum channels. Don't tell me that is against some specs, please. I brought it up because I want people to realize that softwares should be flexible to accommodate numerous different intrepretations, configurations and variations even years down the road. It comes down to having a flexible interpretation to begin with. If "drums was said to be on channel 9 by the GM specs" was the only interpretation, then there would be no options what-so-ever for drums to be used on any other channels at all. Such is just sad, IMHO. I was at a live hard-rock concert once, where there were two "over-full" drumsets on the stage, played by two drumers at the same time. It's not impossible. Hey, gutarists do it, symphonies do it, let the drummers do it. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks
. > 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 ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
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
ank [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 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. 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. 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 don't care about XG-mode handling. By "limited way", I mean without the drastic code changes to support the full 128 separate soundfont files. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Soundfont banks (was: Re: OSC support)
--- On Mon, 7/9/12, David Henningsson wrote: > From: David Henningsson > Subject: Soundfont banks (was: Re: [fluid-dev] OSC support) > To: "FluidSynth mailing list" > Cc: "jimmy" > 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,
Re: [fluid-dev] OSC support
> On Sun, 8 Jul 2012, Peter Eastman wrote: > > I didn't come here to argue. I'm suggesting ways to > make FluidSynth a > better program. If you don't want my help or ideas, > just say so and > I'll go away. > > Peter The way Pedro wants is for Fluidsynth to support: SoundBlaster Soundfont specs from 16th Century. Roland GS MIDI extension from 17-th Century. That it!!! God forbid any support for MIDI specs Yamaha XG MIDI extension MIDI-2 specs OSC you are on your own, dude!!! Yeah, I tried to submit a patch for generic Yamaha XG sound banks selection so it can support 128 x 128 banks of 128 instruments per bank in XG-mode (some bit and pieces already in place for partial XG-mode operation). "No way!!! Go away!!! 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. They simply ignored it. Heard of the "Soup Nazi" joke? This is the "SoundBlaster Soundfont Nazi" here. Not in the Soundfont specs? No sounds for you!!! No where near the "old, old" Roland GS specs for Win95/Win98 sound card hardware? No sounds for you!!! To hell with MIDI specs, let alone MIDI-2, or anything else new. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] complexity of soundfont synthesis engine
> On Mon, 19 Sep 2011 14:20:38 -0700 (PDT) Michael Geis > wrote: > > I posted a question on using fluidsynth to extract .sf2 > sounds to .wav files a few weeks ago. The answers I received > indicated I had to get a better grasp of the subject matter > and as a consequence I had to think over what I am doing. > > Sorry if this post is perhaps only marginally related to > fluidsynth. I am trying to develop a better grasp on > soundfonts and fluidsynth may or may not be what I will need > to use in my project (which I currently have a hard time > telling because of my limited understanding of the subject > matter). > If you are on Linux, you may want to try swami (soundfont editor). For a soundfont with lots of samples, it could be a bit overwhelming to try to figure out. However, I found that I can open a soundfont with large number of samples. Create a new (empty) soundfont within the same Swami session, copy from the existing soundfont, paste it to the new soundfont. It will copy all the parameters and internal links into the new soundfont. From there, you can export the sound samples for each instrument that is of interest to you. This approach helped me quite a bit. I suppose other soundfont editors should have similar functionality. There might be other soundfont <-> xml converter/extractor out there. I tried a soundfont to XML extractor (written in Python) sometime ago, it was very primitive and not complete. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Should playback_callback receive MIDI file events?
> On Sun, 18 Sep 2011 21:26:59 Matt Giuca wrote: > > This continues a discussion started in the bug ticket #101 > ( > https://sourceforge.net/apps/trac/fluidsynth/ticket/101) > (between myself and > David Henningson). > > Recently, a feature was added allowing the user of the FS > API to register a > custom playback_callback function, which is called every > time a MIDI event > fires. > > At present, I *think*, this callback receives only MIDI > channel and sysex > events, not meta events. > > . . . [snipped] . . . > > The question is: should they. The default callback will > ignore them anyway, > so it doesn't matter. But does anybody who's used their own > custom callbacks > have any opinion on this one way or another? Would you like > to receive meta > events such as copyright strings, and tempo changes? Will > this break any > existing callbacks? Please do send all events (including meta events). Perhaps you don't need them with your Midi files, but I have work with Midi segments that changes tempo (perhaps even time signature 3/4 <-> 4/4) on the fly. So looping back will need the meta events (tempo...) to play properly. There are other meta events, too. If you think the extra "setup time" may take too long for your usage, perhaps an option to specify whether to play all events, or allow omitting of certain event type(s). Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Code patch for GM, GS, XG "system-reset" SysEx's, and MasterVolume SysEx
If you prefer memcmp(), or strncmp(), you can do it. The main part is done,
I'm not sure I have time to mess around more with it. I'm not sure if these
byteArrays would be used over and over multiple times to deserve a pre-defined
variable for each.
It's a first try for the volume calculation. With the default being 0.2, the
scale is already way-off to start with. If someone finds a better way to
calculate master-volume, go right ahead. I only want/need a way to adjust it,
as long as it's in there, everyone can use it however they want.
Jimmy
--- On Wed, 2/16/11, David Henningsson wrote:
> From: David Henningsson
> Subject: Re: [fluid-dev] Code patch for GM, GS, XG "system-reset" SysEx's,
> and MasterVolume SysEx
> To: "jimmy"
> Cc: fluid-dev@nongnu.org
> Date: Wednesday, February 16, 2011, 5:39 AM
> Hmm, seems this patch went through
> unnoticed?
>
> Well, I don't mind a maximum gain of 10, it seems like a
> mistake if it's
> 5 in some places and 10 in others.
>
> About master volume sysex, I'm a little hesitant if the
> scale is right.
> What's the default master volume according to the spec?
> That should map
> against our default volume of 0.2. There is also no reason
> to ignore LSB.
>
> About the GS/XG/GM sysex (what about GM2 reset, btw?) I
> think the code
> would look nicer if you did a memcmp() instead of matching
> each
> individual byte.
>
> What do you think?
>
> // David
>
> On 2011-02-10 23:08, jimmy wrote:
> >
> >
> > Attached is a patch for 4 SysEx messages. This
> allow Fluidsynth to automatically switch between GM, GS, XG
> mode on the fly, without having to restart, that is.
> Often a "reset" sysex is sent at beginning of a midi file,
> but not always.
> >
> > Sys-Ex "reset" messages:
> >
> >
> myweb.tiscali.co.uk/mikesmusic/my_technical_articles2.html#sysex
> >
> > 1. GM Reset (understood by
> every GM-compatible instrument)
> > Sys-Ex String: F0 7E 7F 09 01
> F7
> >
> > 2. Roland GS Reset (Understood
> by all Roland GS instruments)
> > Sys-Ex String: F0 41 10 42 12
> 40 00 7F 00 41 F7
> >
> > 3. Yamaha XG reset (Understood
> by all Yamaha XG instruments)
> > Sys-Ex String: F0 43 10 4C 00
> 00 7E 00 F7
> >
> > About master volume:
> >
> >
> home.roadrunner.com/~jgglatt/tech/midispec/mastrvol.htm
> >
> > Master Volume
> SysEx: 0xF0 0x7F 0x7F 0x04 0x01 0xLL 0xMM
> 0xF7
> >
> > where (0xLL=LSB, 0xMM=MSB), where 7F 7F is maximum
> volume.
> >
> > My patch ignores LSB (LSB=0), simply takes the MSB
> (7-bit, max value 127) devide by 12.70 to get the range of
> [0.0 - 10.0].
> >
> > -
> >
> > In adding SysEx handler for master volume adjustment
> ("gain" in Fluidsynth), I found a few inconsitencies
> regarding "gain":
> >
> > -g, --gain
> >
> Set the master gain [0< gain< 10, default
> = 0.2]
> >
> > which sets fluidsynth settings of:
> >
> > synth.gain FLOAT
> [min=0.000, max=10.000, def=0.200] REALTIME
> >
> Master synthesizer gain.
> >
> > While the fluidsynth command shell and manual page
> have:
> >
> > gain value
> >
> Set the master gain (0< gain< 5)
> >
> > but the shell-command handler fluid_handle_gain()
> doesn't try to scale it in anyway to 10.0. Any reason
> for that? Or, it's just an oversight (in previous
> changes).
> >
> > In this patch, I go ahead and change all references
> regarding maximum "gain" from 5 to 10. Let me know if
> those need to be left alone.
> >
> > Jimmy
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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
Re: [fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
Some more thoughts... --- On Thu, 2/10/11, David Henningsson wrote: > 2) The SF2 spec - which Pedro quoted - says that sf2 bank > 0-127 is > melodic and 128 is drums. So there is no "SFX Voice" in the > SF2 > standard, and no "SFX Kit" either. So what do we do with > it? Currently, > we ignore MSB for 64/0x40 and map 126/0x7E, to drums, but > should we > change the bank calculation from "LSB" to MSB*128+LSB (mma > style), the > result for 64/0x40 would be a bank outside the valid SF2 > bank range. > So what if it is out side SF2 bank range? SF2 bank range calls for 128 instruments per LSB, up to 128 LSB values. How about having one MSB mapping to the above range. Any additional MSB value can have one extra set of the above range available. All instruments mapping have 2 fall-back tendencies at this time: Drum-channels gravitate toward GM-drum bank by default. Melodic channels gravitate toward GM-basic sound banks by default. If something is not found in the soundfont look up, we already have the substitution in place to use GM defaults (I put in the patch 2-3 years ago, Josh G. did that). SF2 bank range can be seen as basic 128-bank block under MSB. Just because decimal number range is 0-9 doesn't mean I can't have 10, 100, 1000. Or, binary range is only 0-1, I can't have 2, 4, 8, 16. > I understand that you want MSB*128+LSB / mma-style > calculation for XG, > I'm just not convinced that it's the right way to do. > So how do you suggest we handdle GM specs regarding MSB? Ignore it altogether, just because Roland GS folks don't use it? Jimmy Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: Patch for channel_type, also XG drum-channel
--- On Fri, 2/11/11, David Henningsson wrote: > I'm looking at the xg_spec from here: > http://web.archive.org/web/20060926124939/http://www.yamaha.co.uk/xg/reading/pdf/xg_spec.pdf > > "The Bank Select MSB selects melody voice, SFX voice, or > rhythm kit. The > MSB allows any channel to be designated for rhythm play. > Bank Select MSB values are as follows. > 00H: Melody voice > 01H to 3FH: not used > 40H: SFX voice > 41H to 7DH: not used > 7EH: SFX kit (SFX voices arranged over keyboard) > 7FH: Rhythm kit (Rhythm voices arranged over keyboard) > XG Specifications ver.1.26 > > And if I look at table 1 on page 35, you see that MSB stays > at 0 and LSB > varies, and that the variation in turn gives different > banks. > > Now, the two questions are: > > 1) Does the XG world work that way? Is the above wrong? I > e, unless > there is consensus here that we should deviate from the > standard, I'm > unhappy to do so. > > 2) The SF2 spec - which Pedro quoted - says that sf2 bank > 0-127 is > melodic and 128 is drums. So there is no "SFX Voice" in the > SF2 > standard, and no "SFX Kit" either. So what do we do with > it? Currently, > we ignore MSB for 64/0x40 and map 126/0x7E, to drums, but > should we > change the bank calculation from "LSB" to MSB*128+LSB (mma > style), the > result for 64/0x40 would be a bank outside the valid SF2 > bank range. > > > MSB=128 is drum in XG, > > MSB range is 0 - 127, so it can't be 128. > > > as well as MSB=126, MSB=120. No difference in > that regard (the number 128). The only difference is > that it is sent via CC#0. So for MMA-calculation > (basically convert to decimal number the combination of MSB, > LSB), MSB need to be shifted 7 bits further to the > left. And this is done only for XG bank-select style > in my code. I hope it help clear any confusion. > > I understand that you want MSB*128+LSB / mma-style > calculation for XG, > I'm just not convinced that it's the right way to do. The above XG doc is not wrong, it was mainly a guide (back in mid 1990's), check the date of that document. Since then, newer Yamaha instruments came out with Drum/SFX-kits using MSB=126, and more recently MSB-120. Some of their older SFX-kits use MSB=64, or so. I don't know what to make of that, being Melodic, or Drum treatment. But recent instruments have their SFX-kits in the MSB=126, and MSB=120 range with Drumkits. As I replied to Pedro's latest message about soundfont specs. So what if SF2 supports only 128 banks. For all we care, that fits completely into LSB banks. Consider MSB as the multiplier of LSB. If I want to use Unison.sf2 as MSB=0, SGM.sf2 as MSB=1, some NylonGuitar.sf2 as MSB=10, SomePiano.sf2 as MSB=20, ... how is that conflicting with Soundfont specs? Let alone that it is going to be done for XG-mode only for the moment. Just because you don't need MSB, don't care about MSB doesn't mean that you should throw away MSB. MSB is part of the GM and GM2 spec. Fluidsynth doesn't have know how to handle MSB, nor have any code working with MSB doesn't mean it should stay crippled. > >> I did look over the fluid_synth_program_change > function and > >> tried to > >> clear it up a little. It's also in r406. With that > patch > >> and your > >> example I now get: > >> > >> fluidsynth: warning: Instrument not found on > channel 6 > >> [bank=128 > >> prog=1], substituted [bank=128 prog=0] > >> > >> ...which is what it actually did, both before and > after > >> r406. > >> > >> // David > >> > > > > Hmmm... ??? I'll take another look on my > side. Again, can you try with: > > > > fluidsynth -o > synth.midi-bank-select=xg > > > > if and when you get a chance. > > My test included that option. > > // David In XG-mode the sequence of events recommended/expected are: MSB, LSB, ProgChange. Since your changes never kept the MSB in Fluid synth at all. More than that if any LSB message came int, it specifically zero-out MSB, too. How can it show anything higher than 128? As I said, with my patch, at least it keeps the MSB and shows the banks that's needed for such midi files. I can then search them in the midi files, or find a way to create/map a sound bank to work with it. As I said above about using multiple soundfonts, that's exactly what MSB means in XG, and MMA calculation. Don't let LSB be the limit of sound banks available in the system. You can use MSB to multiply your LSB up to
[fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
Oops, sent with wrong subject line, before I finished. I wrote more beyond
last message, so read this message instead of last.
--- On Thu, 2/10/11, "Pedro Lopez-Cabanillas"
wrote:
> > So bank numbers above 128 usually make no sense, which
> is why MSB is
> > ignored for XG (and why MMA style is not the
> default...). We're kind of
> > stuck between sf2's standard and XG's standard, and
> need to figure out
> > how to mediate between them.
>
> Agreed. This issue has been already posted and discussed in
> this list, so here are some relevant excerpts and pointers.
> The SoundFont2 PHDR sub-chunk has this header structure:
>
> struct sfPresetHeader
> {
> CHAR achPresetName[20];
> WORD wPreset;
> WORD wBank;
> WORD wPresetBagNdx;
> DWORD dwLibrary;
> DWORD dwGenre;
> DWORD dwMorphology;
> };
>
> Where wBank is a 16bit field, like wPreset. But the
> specification states the
> range from 0 thru 127 for both the wBank and wPreset.
> Document "sfspec21.pdf", page 27:
>
> "The WORD wPreset contains the MIDI Preset Number and the
> WORD wBank contains
> the MIDI Bank Number which apply to this preset. Note that
> the presets are
> not ordered within the SoundFont compatible bank. Presets
> should have a
> unique set of wPreset and wBank numbers. However, if two
> presets have
> identical values of both wPreset and wBank, the first
> occurring preset in the
> PHDR chunk is the active preset, but any others with the
> same wBank and
> wPreset values should be maintained so that they can be
> renumbered and used
> at a later time. The special case of a General MIDI
> percussion bank is
> handled conventionally by a wBank value of 128. If the
> value in either field
> is not a valid MIDI value of zero through 127, or 128 for
> wBank, the preset
> cannot be played but should be maintained."
>
> http://connect.creativelabs.com/developer/SoundFont/Forms/AllItems.aspx
>
> Regards,
> Pedro
>
For soundfont bank number, what's wrong with creating some virtual sound bank
look up scheme beyond 128, somehow... eventually... in XG mode... or some
Fluidsynth enhanced mode? Remembering MSB is the first step anyhow.
Just because GM say channel 10 is drum doesn't mean it should be the only one.
Or, that there are 128 banks in GM, doesn't mean we can't have, or use more
than 128. Same goes for soundfont specs. Aim high, don't go for the bare
minimum.
Try to browse through various Cakewalk .ins instrument defintion files, or
calculation formulae for Yamaha instrument banks. They use that to talk to
those devices bi-directionally (record and/or playback), I think. They make
use of the bank change MSB's, not throw them away. I am not a Cakewalk user,
only glancing through bits of info.
Rosegarden also use some instrument description file to talk to specific midi
devices.
With Timidity configuration file, one can use a virtual bank mapping to select
a specific bank in one soundfont to override another bank in a different
soundfont.
How about Fluidsynth uses a configuration file to map some chunk of
128-LSB-bank-set to one of the MSB number? In other word, using multiple
GM-soundfonts files, each would have a separate MSB number. What's wrong with
that? Nothing. If anything, it opens up a whole new world of MSB to us. And
can work fine with XG MSB's, too.
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: fluid-dev Digest, Vol 94, Issue 11
--- On Thu, 2/10/11, "Pedro Lopez-Cabanillas"
wrote:
> > So bank numbers above 128 usually make no sense, which
> is why MSB is
> > ignored for XG (and why MMA style is not the
> default...). We're kind of
> > stuck between sf2's standard and XG's standard, and
> need to figure out
> > how to mediate between them.
>
> Agreed. This issue has been already posted and discussed in
> this list, so here are some relevant excerpts and pointers.
> The SoundFont2 PHDR sub-chunk has this header structure:
>
> struct sfPresetHeader
> {
> CHAR achPresetName[20];
> WORD wPreset;
> WORD wBank;
> WORD wPresetBagNdx;
> DWORD dwLibrary;
> DWORD dwGenre;
> DWORD dwMorphology;
> };
>
> Where wBank is a 16bit field, like wPreset. But the
> specification states the
> range from 0 thru 127 for both the wBank and wPreset.
> Document "sfspec21.pdf", page 27:
>
> "The WORD wPreset contains the MIDI Preset Number and the
> WORD wBank contains
> the MIDI Bank Number which apply to this preset. Note that
> the presets are
> not ordered within the SoundFont compatible bank. Presets
> should have a
> unique set of wPreset and wBank numbers. However, if two
> presets have
> identical values of both wPreset and wBank, the first
> occurring preset in the
> PHDR chunk is the active preset, but any others with the
> same wBank and
> wPreset values should be maintained so that they can be
> renumbered and used
> at a later time. The special case of a General MIDI
> percussion bank is
> handled conventionally by a wBank value of 128. If the
> value in either field
> is not a valid MIDI value of zero through 127, or 128 for
> wBank, the preset
> cannot be played but should be maintained."
>
> http://connect.creativelabs.com/developer/SoundFont/Forms/AllItems.aspx
>
> Regards,
> Pedro
>
For soundfont bank number, what's wrong with creating some virtual sound bank
look up scheme beyond 128, somehow, eventually, in XG mode, or Fluidsynth
enhanced mode? Remembering MSB is the first step anyhow.
Just because GM say channel 10 is drum doesn't mean it should be the only one.
Or, that there are 128 banks in GM, doesn't mean we can't have, or use more
than 128. Same goes for soundfont specs. Aim high, don't go for the bare
minimum.
Try to browse through various Cakewalk .ins instrument defintion files, or
calculation formulae for Yamaha instrument banks. They use that to talk to
those devices bi-directionally (record and/or playback), I think. They make
use of the bank change MSB's, not throw them away. I am not a Cakewalk user,
only glancing through bits of info.
Rosegarden also use some instrument description file to talk to specific midi
devices.
With Timidity configuration file, one can use a virtual bank mapping to select
a specific bank in one soundfont to override another bank in a different
soundfont.
How about Fluidsynth uses a configuration file to map some chunk of
128-LSB-bank-set to one of the MSB number? In other word, using multiple
GM-soundfonts files, each would have a separate MSB number. What's wrong with
that? Nothing. If anything, it opens up a whole new world of MSB to us.
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Code patch for GM, GS, XG "system-reset" SysEx's, and MasterVolume SysEx
Attached is a patch for 4 SysEx messages. This allow Fluidsynth to
automatically switch between GM, GS, XG mode on the fly, without having to
restart, that is. Often a "reset" sysex is sent at beginning of a midi file,
but not always.
Sys-Ex "reset" messages:
myweb.tiscali.co.uk/mikesmusic/my_technical_articles2.html#sysex
1. GM Reset (understood by every GM-compatible instrument)
Sys-Ex String: F0 7E 7F 09 01 F7
2. Roland GS Reset (Understood by all Roland GS instruments)
Sys-Ex String: F0 41 10 42 12 40 00 7F 00 41 F7
3. Yamaha XG reset (Understood by all Yamaha XG instruments)
Sys-Ex String: F0 43 10 4C 00 00 7E 00 F7
About master volume:
home.roadrunner.com/~jgglatt/tech/midispec/mastrvol.htm
Master Volume SysEx: 0xF0 0x7F 0x7F 0x04 0x01 0xLL 0xMM 0xF7
where (0xLL=LSB, 0xMM=MSB), where 7F 7F is maximum volume.
My patch ignores LSB (LSB=0), simply takes the MSB (7-bit, max value 127)
devide by 12.70 to get the range of [0.0 - 10.0].
-
In adding SysEx handler for master volume adjustment ("gain" in Fluidsynth), I
found a few inconsitencies regarding "gain":
-g, --gain
Set the master gain [0 < gain < 10, default = 0.2]
which sets fluidsynth settings of:
synth.gain FLOAT [min=0.000, max=10.000, def=0.200] REALTIME
Master synthesizer gain.
While the fluidsynth command shell and manual page have:
gain value
Set the master gain (0 < gain < 5)
but the shell-command handler fluid_handle_gain() doesn't try to scale it in
anyway to 10.0. Any reason for that? Or, it's just an oversight (in previous
changes).
In this patch, I go ahead and change all references regarding maximum "gain"
from 5 to 10. Let me know if those need to be left alone.
Jimmy
diff -pur fluidsynth.svnRev405.20110207/doc/fluidsynth.1 fluidsynth.svnRev405.20110207.jnSysex/doc/fluidsynth.1
--- fluidsynth.svnRev405.20110207/doc/fluidsynth.1 2011-02-07 20:29:49.0 -0500
+++ fluidsynth.svnRev405.20110207.jnSysex/doc/fluidsynth.1 2011-02-09 15:51:53.0 -0500
@@ -415,7 +415,7 @@ Print out the presets of all channels.
.B AUDIO SYNTHESIS
.TP
.B gain value
-Set the master gain (0 < gain < 5)
+Set the master gain (0 < gain < 10)
.TP
.B interp num
Choose interpolation method for all channels
diff -pur fluidsynth.svnRev405.20110207/src/bindings/fluid_cmd.c fluidsynth.svnRev405.20110207.jnSysex/src/bindings/fluid_cmd.c
--- fluidsynth.svnRev405.20110207/src/bindings/fluid_cmd.c 2011-02-07 20:29:47.0 -0500
+++ fluidsynth.svnRev405.20110207.jnSysex/src/bindings/fluid_cmd.c 2011-02-09 15:51:53.0 -0500
@@ -119,7 +119,7 @@ fluid_cmd_t fluid_commands[] = {
{ "chorus", "chorus", (fluid_cmd_func_t) fluid_handle_chorus, NULL,
"chorus [0|1|on|off]Turn the chorus on or off" },
{ "gain", "general", (fluid_cmd_func_t) fluid_handle_gain, NULL,
-"gain value Set the master gain (0 < gain < 5)" },
+"gain value Set the master gain (0 < gain < 10)" },
{ "voice_count", "general", (fluid_cmd_func_t) fluid_handle_voice_count, NULL,
"voice_countGet number of active synthesis voices" },
{ "tuning", "tuning", (fluid_cmd_func_t) fluid_handle_tuning, NULL,
@@ -981,8 +981,8 @@ fluid_handle_gain(fluid_synth_t* synth,
gain = atof(av[0]);
- if ((gain < 0.0f) || (gain > 5.0f)) {
-fluid_ostream_printf(out, "gain: value should be between '0' and '5'.\n");
+ if ((gain < 0.0f) || (gain > 10.0f)) {
+fluid_ostream_printf(out, "gain: value should be between '0' and '10'.\n");
return -1;
};
diff -pur fluidsynth.svnRev405.20110207/src/synth/fluid_synth.c fluidsynth.svnRev405.20110207.jnSysex/src/synth/fluid_synth.c
--- fluidsynth.svnRev405.20110207/src/synth/fluid_synth.c 2011-02-07 20:29:48.0 -0500
+++ fluidsynth.svnRev405.20110207.jnSysex/src/synth/fluid_synth.c 2011-02-10 09:24:19.0 -0500
@@ -1221,18 +1221,88 @@ fluid_synth_sysex(fluid_synth_t *synth,
if (len < 4) return FLUID_OK;
- /* MIDI tuning SYSEX message? */
+ /* GM Reset:F0 7E 7F 09 01 F7 */
+ if ((0x7E == data[0]) && (0x7F == data[1]) && (0x09 == data[2]) && (0x01 == data[3]))
+ {
+ if (synth->verbose)
+ FLUID_LOG(FLUID_INFO, "FLUID_BANK_STYLE_GM");
+
+ if (handled) *handled = TRUE;
+ if (!dryrun)
+ {
+ fluid_synth_setstr(synth, "synth.midi-bank-select", "gm");
+ synth->bank_select = FLUID_BANK_STYLE_GM;
+ fluid_synth_system_reset(synth);
+ }
+ return FLUID_OK;
+ }
+ /* GS Reset:F0 41 10 42 12 40
[fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
quot; of how GS does it, how XG does it, resulted in code that assume too much and cut out the full calculation. I think both of them are calculated the same as MMA-style. For example, in XG drum bank usage, currently only MSB is used. But it should not be assumed that LSB will never be used with drum banks. The "return if channel is drum-channel" check in both Fluidsynth functions should not be there, I believe. - The way I see it, the check "if channel is drum-channel" in both fluid_channel_set_bank_msb(), and fluid_channel_set_bank_lsb() should be ripped out. For example, in GM mode it is "commonly" assumed that it can use any bank number except bank number 128. And that channel 10, defaults to bank number 128 cannot be changed to any other number. That's just wrong. I think any channel should still be able to change to use bank number 128 (which has drum sounds for notes). Of course, XG uses MSB=128 (that is 128*128, or 16384 in MMA-style decimal number, 16383 for 0-offset), I believe GS uses LSB=128, that's all. On the other hand, I think channel 10 should still be able to use any banknumber, too. Not being tied to bank number 128. Regardless, once a channel is determined to be drum, or melodic, the only difference between them is the bank fall-back lookup scheme. Melodic channels fall-back eventually to bank number 0. Drum channels fall-back to bank number 128 (XG use of MSB=120, or 126, for example). 2-3 years ago I put in the patch for melodic bank number fall-back scheme. Back then, if a bank could not be found, the channel went completely silent. Since then, for XG midi files that uses drum bank 126, I will hear Piano. It doesn't sound good, or right, but at least now I know something needed to be changed (the midi file), or fixed (in the soft synth), rather than not knowing anything is there at all. Now with drum channel auto switching (at least in XG mode), I can say that drum channels finally sound like drums. If it doesn't sound good, maybe a better soundfont could help. I don't have to hear Piano thumping on drum channels (on channel other than 10) any more. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
--- On Thu, 2/10/11, David Henningsson wrote: > So bank numbers above 128 usually make no sense, which is > why MSB is > ignored for XG (and why MMA style is not the default...). > We're kind of > stuck between sf2's standard and XG's standard, and need to > figure out > how to mediate between them. By the way, no problem running my code here. It works just fine with Unison.sf2 . Multiple drum channels and all. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
--- On Thu, 2/10/11, David Henningsson wrote: > > Basically the problem is that Soundfont files can have bank > numbers up > to 128 only, and that bank numbers 0-127 are melodic and > bank 128 is > percussion. At least that's the way SWAMI works. I checked > Unison.sf2, > and it follows this as well. I assume it's somewhere in the > sf2 standard. > > So bank numbers above 128 usually make no sense, which is > why MSB is > ignored for XG (and why MMA style is not the default...). > We're kind of > stuck between sf2's standard and XG's standard, and need to > figure out > how to mediate between them. Perhaps you are talking about GM, GS mode where bank# is LSB. Now, just think XG uses MSB instead of LSB. MSB=128 is drum in XG, as well as MSB=126, MSB=120. No difference in that regard (the number 128). The only difference is that it is sent via CC#0. So for MMA-calculation (basically convert to decimal number the combination of MSB, LSB), MSB need to be shifted 7 bits further to the left. And this is done only for XG bank-select style in my code. I hope it help clear any confusion. > > -- > > > > And in fluid_channel_set_bank_msb() you modified it > as: > > ... > I did look over the fluid_synth_program_change function and > tried to > clear it up a little. It's also in r406. With that patch > and your > example I now get: > > fluidsynth: warning: Instrument not found on channel 6 > [bank=128 > prog=1], substituted [bank=128 prog=0] > > ...which is what it actually did, both before and after > r406. > > // David > Hmmm... ??? I'll take another look on my side. Again, can you try with: fluidsynth -o synth.midi-bank-select=xg if and when you get a chance. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
> Hey jimmy,
>
> Thanks for the research. I've committed the patch now (with
> some trivial
> changes). Thanks for your contribution!
>
> And to the rest of you - this bank select handling seems to
> be a never
> ending debate, and it's not my area of expertise, so let me
> know if this
> change screwed something up for you.
>
> // David
Your change is not correct in both MSB, and LSB handling for XG bank
calculation.
-
The problem with fluid_channel_set_bank_lsb():
if (style == FLUID_BANK_STYLE_XG)
newval = (oldval & ~BANK_MASKVAL) | (banklsb << BANK_SHIFTVAL);
is that any existing MSB values will be zerroes out (your code is using
~BANK_MASKVAL, instead of ~BANKLSB_MASKVAL). So it should be:
if (style == FLUID_BANK_STYLE_XG)
newval = (oldval & ~BANKLSB_MASKVAL) | (banklsb << BANK_SHIFTVAL);
which is the same as MMA style calculation.
My patch also saves the LSB with XG drum-channels. The current flow ignores
drum channels LSB for XG mode.
--
And in fluid_channel_set_bank_msb() you modified it as:
if (style == FLUID_BANK_STYLE_XG)
{
/* XG bank (128*MSB+LSB), save MSB, do drum-channel auto-switch */
/* 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;
return;
}
Don't "return" there, it has not save MSB yet. That's why the "if-statement"
in my patch was written without the "return", so it would flow through to the
code below.
So if a "return" is preferred from within the block, then the code bock above
should be changed to:
if (style == FLUID_BANK_STYLE_XG)
{
/* XG bank (128*MSB+LSB), save MSB, zero out LSB, do drum-channel
auto-switch */
/* 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;
}
My original patch shares the MMA calculation, using "~BANKMSB_MASKVAL" to
update the MSB value.
There are some midi files which use 2 drum channels in XG mode in:
psrtutorial.com/songs/Yamaha/XGCurrent.zip
Trying Fluidsynth in XG mode with Unison.sf2:
fluidsynth -o synth.midi-bank-select=xg Unison.sf2
Playing the midi file "JazzJung Yamaha '96.mid". Without this patch, using
latest SVN code, the message I get from fluid command interface:
fluidsynth: warning: Instrument not found on channel 6 [bank=0 prog=1],
substituted [bank=0 prog=0]
with this patch, the message is:
fluidsynth: warning: Instrument not found on channel 6 [bank=16128 prog=1],
substituted [bank=16128 prog=0]
Which will help figuring the real midi processing behind the scene, 16128 =
(126 * 128). So that's [MSB=126,LSB=0,prog=1] it is looking to use.
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch
--- On Sun, 2/6/11, "Pedro Lopez-Cabanillas" wrote: > I've > never been a XG user, so changeset #340 included several > TODOs and FIXMEs that this patch has finally addressed. But > there is still one (FIXME: pending implementation of SYSEX > midi mode changes) that somebody has to work on, and there > may be a few issues more than bank changes involved. > > Regards, > Pedro I'm about done with the SysEx's for GM/GS/XG reset, as well as the Master Volume SysEx. Need to do a little bit of testing before posting it here. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Patch for channel_type, also XG drum-channel autoswitch
Great, I'll try the new code a bit later. Jimmy --- On Fri, 2/4/11, David Henningsson wrote: > From: David Henningsson > Subject: Re: [fluid-dev] Patch for channel_type, also XG drum-channel > autoswitch > To: "jimmy" > Cc: fluid-dev@nongnu.org > Date: Friday, February 4, 2011, 11:23 AM > Hey jimmy, > > Thanks for the research. I've committed the patch now (with > some trivial > changes). Thanks for your contribution! > > And to the rest of you - this bank select handling seems to > be a never > ending debate, and it's not my area of expertise, so let me > know if this > change screwed something up for you. > > // David > > On 2011-02-03 01:08, jimmy wrote: > > > > > > It seems MSB of 127, 126, 120 have been used for > Yamaha/XG drum kits. > > > > For PSR-2000 keyboard, [MSB,LSB,Prog] for MSB 126: > > > > [127,0,xx] Various drum > kits > > > > [126,0,0] SFX Kit1 > > [126,0,1] SFX Kit2 > > [126,0,35] Arabic Kit > > > > For PSR-S900 (similarly in Tyros-2, Tyros-3): > > > > [127,0,xx] Various drum > kits > > > > [126,0,0] SFX Kit1 > > [126,0,1] SFX Kit2 > > [126,0,35] Arabic Kit > > [126,0,40] Cuban Kit > > [126,0,43] PopLatin Kit > > > > [120,0,0] Standard Set > > [120,0,8] Room Set > > [120,0,16] Power Set > > [120,0,24] Electronic > Set > > [120,0,25] Analog Set > > [120,0,32] Jazz Set > > [120,0,40] Brush Set > > [120,0,48] Orchestra > Set > > [120,0,56] SFX Set > > > > From the drum key/sound mapping list, it seems > that, for MSB=127: > > > > [127,0,0] Has full set > of drum sounds > > [127,0,xx] Has sparse > set (some note/key has no sound), so it would fall back to > the sound from the full [127,0,0]. > > > > Similar mapping scheme for MSB=126, as well as > MSB=120: > > > > [126,0,0] Has full set > of drum sounds > > [126,0,xx] Has sparse > set > > > > [120,0,0] Has full set > of drum sounds > > [120,0,xx] Has sparse > set > > > > Seems like a "fall-back" sound lookup scheme, similar > to the non-drum voices. So if key/sound for MSB=120 > could be found with: > > > > [120,0,xx] if not found, try: > > [120,0,0] if not found, > try: > > [127,0,0] always there, > this is also GM-drumkit. > > > > Like-wise, with MSB=126 drum sound: > > > > [126,0,xx] if not found, try: > > [126,0,0] if not found, > try: > > [127,0,0] always there, > this is also GM-drumkit. > > > > > > PDF manuals for the keyboards are available online if > folks want to take a closer look. > > > > Jimmy > > > > > > > > > > > > > > > > > > > > ___ > > 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] Questions about soundfont, voice rendering, pitch shift...
Lots of questions. If someone can answer just some of them, please do. Some of these might be more than just Fluidsynth, but Fluidsynth is used to produce the final output and the notes don't sound too good for now. I'm trying to make a soundfont from a single audio sample (somewhere between octave C3-C4). The sample is about 4 seconds. So it is set to the whole range of notes (0-127). What happens is the lower octave notes seems to lose some volume. More problematic are the upper octave notes, they sounded so short (1-2 seconds, or less). It may sound OK for short-duration sounds like like piano, xylophone, but for synth strings, sawWave, squareWave, pads... It also sounds much less like the original sound. I know that in pitch shifting, tempo can be kept constant, which also sound much closer to the original sound characteristics. Some library, like: www.surina.net/soundtouch/ can do so and is part of apps like mhwaveedit, rezound, ardour, audacity... I have tried on a whole song (non-realtime) in audacity and it sounds good. So, I wonder if Fluidsynth voice rendering can be changed to keep the sound length constant (same as original sample)? Of course, this is just some experiment for the time being. Does anyone have time to look into it? Or perhaps, give me some pointers as to where to look in Fluidsynth code so I can try it on my own? Also, if original audio sample rate is 192 kHz, with jackd and fluidsynth run with 44.1 kHz, does Fluidsynth scale the sample to the appropriate pitch using 192 kHz, then resample to 44.1 kHz? Or, how does Fluidsynth do that right now? What's recommended in this case to get better sound out of a single sample to be use as the only sample for all 128 notes? Thanks, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Patch for channel_type, also XG drum-channel autoswitch
It seems MSB of 127, 126, 120 have been used for Yamaha/XG drum kits.
For PSR-2000 keyboard, [MSB,LSB,Prog] for MSB 126:
[127,0,xx] Various drum kits
[126,0,0] SFX Kit1
[126,0,1] SFX Kit2
[126,0,35] Arabic Kit
For PSR-S900 (similarly in Tyros-2, Tyros-3):
[127,0,xx] Various drum kits
[126,0,0] SFX Kit1
[126,0,1] SFX Kit2
[126,0,35] Arabic Kit
[126,0,40] Cuban Kit
[126,0,43] PopLatin Kit
[120,0,0] Standard Set
[120,0,8] Room Set
[120,0,16] Power Set
[120,0,24] Electronic Set
[120,0,25] Analog Set
[120,0,32] Jazz Set
[120,0,40] Brush Set
[120,0,48] Orchestra Set
[120,0,56] SFX Set
>From the drum key/sound mapping list, it seems that, for MSB=127:
[127,0,0] Has full set of drum sounds
[127,0,xx] Has sparse set (some note/key has no sound), so it would fall
back to the sound from the full [127,0,0].
Similar mapping scheme for MSB=126, as well as MSB=120:
[126,0,0] Has full set of drum sounds
[126,0,xx] Has sparse set
[120,0,0] Has full set of drum sounds
[120,0,xx] Has sparse set
Seems like a "fall-back" sound lookup scheme, similar to the non-drum voices.
So if key/sound for MSB=120 could be found with:
[120,0,xx] if not found, try:
[120,0,0] if not found, try:
[127,0,0] always there, this is also GM-drumkit.
Like-wise, with MSB=126 drum sound:
[126,0,xx] if not found, try:
[126,0,0] if not found, try:
[127,0,0] always there, this is also GM-drumkit.
PDF manuals for the keyboards are available online if folks want to take a
closer look.
Jimmy
diff -pur fluidsynth.svn399.20101221/include/fluidsynth/synth.h fluidsynth.svn399.20101221.jnDrumChannel/include/fluidsynth/synth.h
--- fluidsynth.svn399.20101221/include/fluidsynth/synth.h 2010-12-21 19:02:51.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel/include/fluidsynth/synth.h 2011-02-02 16:24:53.0 -0500
@@ -99,6 +99,14 @@ FLUIDSYNTH_API int fluid_synth_get_chann
FLUIDSYNTH_API int fluid_synth_program_reset(fluid_synth_t* synth);
FLUIDSYNTH_API int fluid_synth_system_reset(fluid_synth_t* synth);
+enum fluid_midi_channel_type
+{
+ CHANNEL_TYPE_MELODIC = 0,
+ CHANNEL_TYPE_DRUM = 1
+};
+
+int fluid_synth_set_channel_type(fluid_synth_t* synth, int chan, int type);
+
/* Low level access */
FLUIDSYNTH_API fluid_preset_t* fluid_synth_get_channel_preset(fluid_synth_t* synth, int chan);
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_chan.c fluidsynth.svn399.20101221.jnDrumChannel/src/synth/fluid_chan.c
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.c 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel/src/synth/fluid_chan.c 2011-02-02 16:44:01.0 -0500
@@ -68,7 +68,8 @@ fluid_channel_init(fluid_channel_t* chan
int prognum, banknum;
prognum = 0;
- banknum = (chan->channum == 9)? 128 : 0; /* ?? */
+ chan->channel_type = (9 == chan->channum) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC;
+ banknum = (CHANNEL_TYPE_DRUM == chan->channel_type) ? DRUM_INST_BANK : 0;
chan->sfont_bank_prog = 0 << SFONT_SHIFTVAL | banknum << BANK_SHIFTVAL
| prognum << PROG_SHIFTVAL;
@@ -231,16 +232,18 @@ fluid_channel_set_bank_lsb(fluid_channel
int oldval, newval, style;
style = chan->synth->bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_GS ||
- chan->channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_XG == style)
+ {
+ /* XG bank (128*MSB+LSB), save LSB, even for drum channel */
+ }
+ else if (FLUID_BANK_STYLE_GM == style ||
+ FLUID_BANK_STYLE_GS == style ||
+ CHANNEL_TYPE_DRUM == chan->channel_type)
return; /* ignored */
oldval = chan->sfont_bank_prog;
- if (style == FLUID_BANK_STYLE_XG)
- newval = (oldval & ~BANK_MASKVAL) | (banklsb << BANK_SHIFTVAL);
- else /* style == FLUID_BANK_STYLE_MMA */
- newval = (oldval & ~BANKLSB_MASKVAL) | (banklsb << BANK_SHIFTVAL);
+ /* style == FLUID_BANK_STYLE_MMA */
+ newval = (oldval & ~BANKLSB_MASKVAL) | (banklsb << BANK_SHIFTVAL);
chan->sfont_bank_prog = newval;
}
@@ -251,11 +254,16 @@ fluid_channel_set_bank_msb(fluid_channel
int oldval, newval, style;
style = chan->synth->bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_XG ||
- chan->channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_XG == style)
+ {
+ /* XG bank (128*MSB+LSB), save MSB, do drum-channel auto-switch */
+ chan->channel_type = (120 <= bankmsb) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC;
+ }
+ else if (FLUID_BANK_STYLE_GM == style ||
+ CHANNEL_TYPE_DRUM == chan->channel_type)
+ {
return; /* ignored */
- //TODO: if style == XG and bankmsb == 127, convert t
Re: [fluid-dev] Revised patch for new channel field is_drum_channel
If someone has a pressing need for this patch, let us know. I can try to
revise and resubmit the simple patch, without XG support for the moment.
Otherwise, before I send the patch for drum channel, perhaps we can hash out
how Fluidsynth should deal with XG MSB, LSB, ProgChange messages and the
expected sequence/order of these messages.
-
Some info on XG (about 8 pages each):
www.jososoft.dk/yamaha/pdf/xgformat.pdf
www.jososoft.dk/yamaha/pdf/introxg.pdf
Some other info on XG MSB, LSB Bank Change info:
www.jososoft.dk/yamaha/articles/style2_8.htm
myweb.tiscali.co.uk/mikesmusic/my_technical_articles2.html#msb
hem.passagen.se/mrstone/_html/xgmidi.html#Overview
-
XG bank calculation is (128*MSB+LSB). XG recommends sending MSB, LSB,
ProgChange in that order. LSB is optional (calculate as LSB=0 if not sent).
When MSB is 64 (SFX), 126 (SFX-kit), or 127 (drum-kit), LSB is most likely
optional. When MSB is less than 64, more likely additional LSB value should
follow the MSB message.
GM sound set is at bank 0 (MSB=0, LSB=0). GM drum bank is 16256 (MSB=127,
LSB=0).
Note from:
en.wikipedia.org/wiki/Comparison_of_MIDI_standards
has links to some archived XG docs (PDF), and regarding XG drum channels:
every channel can play drum kits with Bank Select MSB (CC#0) set to 7FH
Published in 1995:
www.jososoft.dk/yamaha/pdf/introxg.pdf
implies that MSB=126 (7Eh, 0x7E) is SFX-kit, special effects mapped each to a
key.
From:
www.heikoplate.de/mambo/index.php%3Foption=com_content&task=view&id=426&Itemid=63
"The XG percussion voices are organisized in the bank MSB=127/LSB=0, the
Arabic Kit (only PSR-9000) in the bank MSB=126/LSB=0."
PSR-9000 was available around the year 2000.
I'll try to look up some more manuals on drum-kits, SFX-kit relating to
MSB=126. For now, about channel_type auto-switching (in XG mode), we are
looking at:
(126 <= MSB) --> DRUM channel (MSB 127, or 126)
(125 >= MSB) --> MELODIC channel
-
Within XG-mode handling, not mentioned is should the sequence [LSB, ProgChange]
(without MSB preceding) is allowed at all??? I would assume it means using
existing MSB.
What about [ProgChange] only without MSB, or LSB preceded ProgChange? Does
this mean using existing MSB and LSB ??? I would assume it is. Do all
Midi-keyboard controllers (no sound module on board) always send MSB (CC#0)?
Or, some of them send ProgChange only?
Potentially, the sequence [LSB, MSB, ProgChange] may come in, too. This may
also happen in midi-merge cases, besides midi files.
-
So how should Fluidsynth deal with MSB, LSB for XG ?
The recommended the sequence of messages are [MSB, LSB, ProgChange]. Omitting
LSB is allowed and would assume LSB=0. In this case, Fluidsynth handling of
MSB message can set LSB=0. If LSB is next message in the sequence it will
override the LSB=0 (set by MSB handling). Keep in mind that when MSB is 64 or
higher (currently only 64, 126, 127 are used), then LSB is completely optional
(not needed, but may be there) for any "current" XG devices.
But if some midi file(s), or midi-merge have [LSB, MSB, ProgChange] sequence
(not recommended), MSB message handling should not set LSB=0 at all --
especially if MSB is less than 64. Should Fluidsynth try to handle this
sequence of messages for XG mode at all?
-
All the above are only to set/save MSB, LSB, ProgChange values, needed for
recording Midi. Not dealing with instrument substitution portion afterward in
voice rendering, yet.
Jimmy
--- On Sun, 1/30/11, David Henningsson wrote:
> From: David Henningsson
> Subject: Re: [fluid-dev] Revised patch for new channel field is_drum_channel
> To: "jimmy"
> Cc: fluid-dev@nongnu.org
> Date: Sunday, January 30, 2011, 12:13 AM
> On 2011-01-29 21:01, jimmy wrote:
> > --- On Fri, 1/28/11, David Henningsson
> wrote:
> >>
> >> On 2011-01-28 23:07, jimmy wrote:
> >>>
> >>> Here's the revised patch file for the new
> channel
> >> field "is_drum_channel".
> >>
> >> Thanks, but you're missing the patch :-)
> >>
> >> // David
> >>
> >
> > Oops, here it is.
>
> Thanks. I've fixed a few bugs in your patch - see the
> attached diff.
>
> But there was one thing keeping me from committing the
> fixed version:
>
> +
> + /* if style == XG and bankmsb == 127, convert the
> channel to drum mode.
> + * How should "newval" above be
> calculated (same as MMA style) ??? */
> + if (style == FLUID_BANK_STYLE_XG && (127 ==
> bankmsb))
> + {
> + chan->is_drum_channel =
> CHANNEL_TYPE_DRUM;
> + }
> +
>
> ...this doesn't feel right. First, it seems you can alter
> your cha
[fluid-dev] Withdrawn -- Revised patch for allNotesOff, allSoundsOff
You are right, this patch won't work. I have to think and try again later. Jimmy --- On Sun, 1/30/11, David Henningsson wrote: > From: David Henningsson > Subject: Re: [fluid-dev] Revised patch for allNotesOff, allSoundsOff > To: "jimmy" > Cc: fluid-dev@nongnu.org > Date: Sunday, January 30, 2011, 12:37 AM > On 2011-01-29 20:54, jimmy wrote: > > --- On Fri, 1/28/11, David Henningsson > wrote: > > > >> In think you missed my original comment: > >> > >> Can you elaborate on where/why this is useful? > These are > >> not public API > >> functions and aren't used anywhere. I was thinking > of > >> removing the ones > >> not starting with _LOCAL. > >> > >> // David > >> > > > > > > Sorry, I missed it. > > > > I do play around with vkeybd. Sometimes the > mouse or keyboard switched out before the note is released > and I got stucknotes. Playing with aplaymidi and > Ctrl-C out of it leaves stuck notes. I try other > stuff, too, but those are the simplest examples. > > > > Short of trying the "fluid_synth_system_reset()" > (which also reset all the current settings for all channels, > which I don't want most of the time). I simply need to > turn all the notes/voices off without having to call the > full "fluid_synth_system_reset()". > > > > Of course, I prefer not having to call > allNotesOff/allSoundsOff once per channel. > > Right, but my point is that since these are not public API > functions, > how can you use the new functionality anyway? > > If you want them to be public API functions, and I'm ok > with that if > people find it useful, here is what you need to do: > > 1) Make sure they're declared in include/fluidsynth/synth.h > rather than > src/synth/fluid_synth.h, and prefixed with FLUIDSYNTH_API. > > 2) Make sure any dereference to synth is inside > fluid_synth_api_enter / > fluid_synth_api_exit (or one of the macros calling this > function). If > you have called fluid_synth_api_enter, all exit paths must > call > fluid_synth_api_exit before returning. > > Also note that FLUID_SYNTH_ENTRY_CHAN returns with error if > chan == -1. > > // David > ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Revised patch for new channel field is_drum_channel
--- On Fri, 1/28/11, David Henningsson wrote:
>
> On 2011-01-28 23:07, jimmy wrote:
> >
> > Here's the revised patch file for the new channel
> field "is_drum_channel".
>
> Thanks, but you're missing the patch :-)
>
> // David
>
Oops, here it is.
Jimmy
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_chan.c fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.c
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.c 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.c 2011-01-28 13:30:52.0 -0500
@@ -52,6 +52,7 @@ new_fluid_channel(fluid_synth_t* synth,
chan->synth = synth;
chan->channum = num;
+ chan->is_drum_channel = (9 == num) ? CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC;
chan->preset = NULL;
chan->tuning = NULL;
@@ -68,7 +69,7 @@ fluid_channel_init(fluid_channel_t* chan
int prognum, banknum;
prognum = 0;
- banknum = (chan->channum == 9)? 128 : 0; /* ?? */
+ banknum = (chan->is_drum_channel) ? DRUM_INST_BANK : 0;
chan->sfont_bank_prog = 0 << SFONT_SHIFTVAL | banknum << BANK_SHIFTVAL
| prognum << PROG_SHIFTVAL;
@@ -231,9 +232,9 @@ fluid_channel_set_bank_lsb(fluid_channel
int oldval, newval, style;
style = chan->synth->bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_GS ||
- chan->channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_GM == style ||
+ FLUID_BANK_STYLE_GS == style ||
+ chan->is_drum_channel)
return; /* ignored */
oldval = chan->sfont_bank_prog;
@@ -251,11 +252,9 @@ fluid_channel_set_bank_msb(fluid_channel
int oldval, newval, style;
style = chan->synth->bank_select;
- if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_XG ||
- chan->channum == 9) //TODO: ask for channel drum mode, instead of number
+ if (FLUID_BANK_STYLE_GM == style ||
+ chan->is_drum_channel)
return; /* ignored */
- //TODO: if style == XG and bankmsb == 127, convert the channel to drum mode
oldval = chan->sfont_bank_prog;
if (style == FLUID_BANK_STYLE_GS)
@@ -263,6 +262,14 @@ fluid_channel_set_bank_msb(fluid_channel
else /* style == FLUID_BANK_STYLE_MMA */
newval = (oldval & ~BANKMSB_MASKVAL) | (bankmsb << (BANK_SHIFTVAL + 7));
chan->sfont_bank_prog = newval;
+
+ /* if style == XG and bankmsb == 127, convert the channel to drum mode.
+ * How should "newval" above be calculated (same as MMA style) ??? */
+ if (style == FLUID_BANK_STYLE_XG && (127 == bankmsb))
+ {
+ chan->is_drum_channel = CHANNEL_TYPE_DRUM;
+ }
+
}
/* Get SoundFont ID, MIDI bank and/or program. Use NULL to ignore a value. */
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_chan.h fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.h
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.h 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_chan.h 2011-01-28 13:08:42.0 -0500
@@ -74,6 +74,10 @@ struct _fluid_channel_t
* flag indicating whether the NRPN value is absolute or not.
*/
char gen_abs[GEN_LAST];
+
+ /* Drum channel flag, CHANNEL_TYPE_MELODIC, or CHANNEL_TYPE_DRUM. */
+ int is_drum_channel;
+
};
fluid_channel_t* new_fluid_channel(fluid_synth_t* synth, int num);
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_synth.c fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_synth.c
--- fluidsynth.svn399.20101221/src/synth/fluid_synth.c 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel//src/synth/fluid_synth.c 2011-01-28 13:48:14.0 -0500
@@ -1876,13 +1876,13 @@ fluid_synth_program_change(fluid_synth_t
/* Special handling of channel 10 (or 9 counting from 0). channel
* 10 is the percussion channel.
*
- * FIXME - Shouldn't hard code bank selection for channel 10. I think this
+ * FIXME - I think this
* is a hack for MIDI files that do bank changes in GM mode. Proper way to
* handle this would probably be to ignore bank changes when in GM mode. - JG
*/
if (prognum != FLUID_UNSET_PROGRAM)
{
-if (channel->channum == 9)
+if (channel->is_drum_channel)
preset = fluid_synth_find_preset(synth, DRUM_INST_BANK, prognum);
else preset = fluid_synth_find_preset(synth, banknum, prognum);
@@ -1893,7 +1893,7 @@ fluid_synth_program_change(fluid_synth_t
subst_prog = prognum;
/* Melodic instrument? */
- if (channel->channum != 9 && banknum != DRUM_INST_BANK)
+ if ((! channel->is_drum_channel) && (DRUM_INST_BANK != banknum))
{
subst_bank = 0;
@@ -4990,3 +4990,22 @@ void fluid_synth_api_exit(fluid_synth_t*
}
}
+
+
+/**
+ * Set midi channel type
Re: [fluid-dev] Revised patch for allNotesOff, allSoundsOff
--- On Fri, 1/28/11, David Henningsson wrote: > In think you missed my original comment: > > Can you elaborate on where/why this is useful? These are > not public API > functions and aren't used anywhere. I was thinking of > removing the ones > not starting with _LOCAL. > > // David > Sorry, I missed it. I do play around with vkeybd. Sometimes the mouse or keyboard switched out before the note is released and I got stucknotes. Playing with aplaymidi and Ctrl-C out of it leaves stuck notes. I try other stuff, too, but those are the simplest examples. Short of trying the "fluid_synth_system_reset()" (which also reset all the current settings for all channels, which I don't want most of the time). I simply need to turn all the notes/voices off without having to call the full "fluid_synth_system_reset()". Of course, I prefer not having to call allNotesOff/allSoundsOff once per channel. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Revised patch for new channel field is_drum_channel
Here's the revised patch file for the new channel field "is_drum_channel". The comment regarding GM-mode bank select is left in there. If things look OK, can someone apply the patch? Thanks, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Revised patch for allNotesOff, allSoundsOff
Attached is the revised patch file for handling allNotesOff, allSoundsOff for
all channels at once.
If it looks OK, can someone apply the patch? Thanks,
Jimmy
diff -pur fluidsynth.svn399.20101221/src/synth/fluid_synth.c fluidsynth.svn399.20101221.jnAllSoundsOff//src/synth/fluid_synth.c
--- fluidsynth.svn399.20101221/src/synth/fluid_synth.c 2010-12-21 19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnAllSoundsOff//src/synth/fluid_synth.c 2011-01-28 12:21:55.0 -0500
@@ -1455,19 +1455,19 @@ fluid_synth_sysex_midi_tuning (fluid_syn
/**
* Turn off all notes on a MIDI channel (put them into release phase).
* @param synth FluidSynth instance
- * @param chan MIDI channel number (0 to MIDI channel count - 1)
+ * @param chan MIDI channel number (0 to MIDI channel count - 1), (chan=-1 selects all channels)
* @return FLUID_OK on success, FLUID_FAILED otherwise
*/
int
fluid_synth_all_notes_off(fluid_synth_t* synth, int chan)
{
fluid_return_val_if_fail (synth != NULL, FLUID_FAILED);
- fluid_return_val_if_fail (chan >= 0 && chan < synth->midi_channels, FLUID_FAILED);
+ fluid_return_val_if_fail (chan >= -1 && chan < synth->midi_channels, FLUID_FAILED);
return fluid_synth_all_notes_off_LOCAL (synth, chan);
}
-/* Local synthesis thread variant of all notes off */
+/* Local synthesis thread variant of all notes off, (chan=-1 selects all channels) */
static int
fluid_synth_all_notes_off_LOCAL(fluid_synth_t* synth, int chan)
{
@@ -1477,7 +1477,7 @@ fluid_synth_all_notes_off_LOCAL(fluid_sy
for (i = 0; i < synth->polyphony; i++) {
voice = synth->voice[i];
-if (_PLAYING(voice) && (voice->chan == chan))
+if (_PLAYING(voice) && ((-1 == chan) || (chan == voice->chan)))
fluid_voice_noteoff(voice);
}
return FLUID_OK;
@@ -1486,12 +1486,14 @@ fluid_synth_all_notes_off_LOCAL(fluid_sy
/**
* Immediately stop all notes on a MIDI channel (skips release phase).
* @param synth FluidSynth instance
- * @param chan MIDI channel number (0 to MIDI channel count - 1)
+ * @param chan MIDI channel number (0 to MIDI channel count - 1), (chan=-1 selects all channels)
* @return FLUID_OK on success, FLUID_FAILED otherwise
*/
int
fluid_synth_all_sounds_off(fluid_synth_t* synth, int chan)
{
+ fluid_return_val_if_fail (synth != NULL, FLUID_FAILED);
+ fluid_return_val_if_fail (chan >= -1 && chan < synth->midi_channels, FLUID_FAILED);
int result;
FLUID_API_ENTRY_CHAN(FLUID_FAILED);
@@ -1499,7 +1501,7 @@ fluid_synth_all_sounds_off(fluid_synth_t
FLUID_API_RETURN(result);
}
-/* Local synthesis thread variant of all sounds off */
+/* Local synthesis thread variant of all sounds off, (chan=-1 selects all channels) */
static int
fluid_synth_all_sounds_off_LOCAL(fluid_synth_t* synth, int chan)
{
@@ -1509,7 +1511,7 @@ fluid_synth_all_sounds_off_LOCAL(fluid_s
for (i = 0; i < synth->polyphony; i++) {
voice = synth->voice[i];
-if (_PLAYING(voice) && (voice->chan == chan))
+if (_PLAYING(voice) && ((-1 == chan) || (chan == voice->chan)))
fluid_voice_off(voice);
}
return FLUID_OK;
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose changes for drum channels support
--- On Thu, 1/27/11, Matt Giuca wrote: > Yeah, but the comment was about bank selection (and that it > was hard-coded to channel 10, or 9 if counting from 0). > Given that your patch no longer hard-codes channel 10, how > does it handle bank selection for drum channels? My patch does away with " == 9", by using the added field is_drum_channel. It doesn't really change anything regarding "bank selection" previously in FS. Sure I added a touch of change on XG MSB bank select based on "dum select" comment in the code, doesn't have anything to do with the hard-coded " == 9". > Right, so the implementation can do whatever it wants -- it > isn't specified. But that is a policy decision that it > seems like FS hasn't made yet, one way or the other > (hence the presence of this comment). By removing the > comment, you are effectively committing to a particular > policy decision. I can leave that comment if it really make any difference. > I am saying that either a) the comment should remain in the > program, in some form (modified to describe the new > situation after the drum patch, but still giving developers > an idea of the as-yet-unmade policy decision), or b) the FS > developers need to commit to a particular policy (such as > "FS will ignore bank change commands when in GM > mode" or "FS will go out of GM mode if a bank > change occurs"), change the code to match that > decision, and then remove the comment. In other words, the > comment shouldn't simply disappear without an active > decision, rather than just "it happens to work this way > now." > > > > Matt The code has been working this way all along, no behavior changes regarding FS handling of GM-mode bank select in anyway, with or without that comment. I will leave that part of the comment back in there. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose changes for drum channels support
--- On Wed, 1/26/11, Matt Giuca wrote: > I didn't mean to suggest you shouldn't be using > fluid-dev. I was just disclaiming that when you read my > reply, you shouldn't consider it to be representative of > the opinion of the FS devs (for example, just because I like > it does not mean it will be accepted). However, David is > (one of?) the lead developers, so he has a good idea of what > it will take to get a patch included, and he seems to like > it too. I got your point originally, no problem. > Ah, good point. Well FluidSynth mail archive seems to > include attachments; for example: > http://lists.nongnu.org/archive/html/fluid-dev/2010-10/msg7.html > I'll keep that in mind. > So isn't there still the potential need for FluidSynth > to ignore bank changes when in GM mode or go out of GM > mode? I think, by default, FS really does not enforce strict GM-mode at all (ignore all bank changes). I believe that FS, by default, allows bank changes. > So the first half of the comment is handled by this patch, > the later part of that comment is a wash. > > You mean "Shouldn't hard code bank selection for > channel 10." How does your patch handle it? Does it > hard code bank selection for all drum channels now? > Or does it not hard-code it at all? > > > > Matt I mean that the (channel==9) has been the hard-coded hack at the time, and is now replaced by the new hack "is_drum_channel" field. At initialization, the new code still hard-code a 9, but not anywhere else as they were previously. The later part of the comment on ignoring bank select is "comment in the code" that can be implemented either way, based on what I can understand from various bit and pieces of GM-spec docs and related documents. Basically, FS can do whatever in this case. GM specs, and official stand on this issue is a wash, water under the bridge, nothing, nada. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose changes for drum channels support
> On Wed, 26 Jan 2011 23:41:19 -0800 Chris Moeller wrote: > > Further to this, I propose a change to the bank number > handling. While I > already saw some changes under way to use MSB or LSB or > both depending > on the MIDI standard, I think it's better to combine the > approach. > > [snipped] > Let's hear how others feel about the idea. Anything that helps playing XG-drums without too much fuss for me would be a good thing to have. Anyone deals with any funky GS drum stuff, which these new changes may affect? We will need your help to test your GS stuff (to make sure they aren't broken) if these new changes made it into FluidSynth. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose changes for drum channels support
> On Wed, 26 Jan 2011 22:01:45 +0800 yanli lei wrote: > > I wonder when can this changes be commit into the next > stable release? I > have a SF2 soundset with the Studio Drum sounds so much > realistic than the > hardcode one. Do let me know so the students can enjoy it. Yanli, Unless you want 2 or more simultaneous drum channels (as in GM2, or XG midi files), you don't really need this patch. Even then I only made sure it still works with existing GM-midi files. I haven't done any real tests regarding GM2 (I haven't found one out there), or XG midi files yet. If you want to override the current drumkit in the default soundfont (SF2), you can specify both soundfont files. I believe the second soundfont will override any soundbank/drumkit in the first soundfont. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose change: all_notes_off, all_sounds_off
--- On Wed, 1/26/11, David Henningsson wrote: > fluid_synth_all_notes_off_LOCAL (synth, chan); > > -1 won't pass through here - will be stopped on the line > above: > > fluid_return_val_if_fail (chan >= 0 && chan < > synth->midi_channels, > FLUID_FAILED); > > Same thing might apply to the other functions. > > // David > Good catch, you are right, I had both patches in my test code then try to separate them into 2 independent patches and missed that one. That line should really be: fluid_return_val_if_fail (chan >= -1 && chan < synth->midi_channels, FLUID_FAILED); I didn't see similar 2 checks in the other function, and wasn't sure if I should add those. Perhaps we could add them now that we are at it. Thanks, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Propose changes for drum channels support
--- On Tue, 1/25/11, Matt Giuca wrote:
> Hi Jimmy,
>
> I am not a FluidSynth developer, just an interested person,
> so my opinions don't represent the view of the
> FluidSynth project.
>
> This seems like a valuable generalisation of a previously
> hard-coded value. Given that your new flag will default to 0
> for all channels and 1 for channel 9, it won't change
> anything but add a useful new feature.
>
I'm not a FS dev either. Just seeing something I may want to use isn't there,
so I just take a crack at it. Everyone on this [fluid-dev] list is one way or
another interested in the coding/development side of FS one way or another.
That's why I ask for opinions instead of contacting just one of the FS
developers and try to push through some new features.
> A few points: Firstly, in the future could you attach your
> patches as attachments instead of pasting them at the end.
> It makes them much easier to read and apply.
>
There are some pro's and con's of this. Attachments are cleaner so folks don't
have to cut and paste them. However, most mailing lists will not archive
attachments, just the messages. From time to time I have seen archived
messages (sometimes from mirrored/relayed lists) referring to attachments
that's just not there. I don't think Yahoo lists would archive attachments
either. Such have been pointers to nowhere for me, and I don't like that.
Perhaps, I could attach and include them (2 copies in the message).
>
> Since this is a "boolean" (the name is
> is_drum_channel), your code should use the constants FALSE
> and TRUE instead of 0 and 1 (existing FluidSynth code uses
> these constants, but uses the type 'int' instead of
> 'bool').
>
>
>
> Might it be better to generalise to an enum?
>
> enum fluid_channel_type
> {
> CHANNEL_TYPE_MELODIC,
> CHANNEL_TYPE_DRUM
> };
>
> And call the field "fluid_channel_type
> channel_type".
Such are coding styles, I don't mind either way. Sometimes in printing
debugging messages, enum/boolean make it extra work to print out info. I often
use simple int type, just personal preference. No big deal for me here,
however the FS dev's want to commit the code.
> It's questionable whether there would ever be more
> channel types in the future other than melodic and drum, but
> at least it would make code clearer to see, for instance,
> "chan->is_drum_channel = (9 == num) ?
> CHANNEL_TYPE_DRUM : CHANNEL_TYPE_MELODIC;" instead of
> "chan->is_drum_channel = (9 == num) ? 1 : 0;".
> Can anybody think of any reason why, in the future, there
> would be more channel types than melodic or drum?
>
For musical use, I don't know. For MIDI lightings, stage control, video
mixing, animation... who knows, perhaps those things may become more common.
> This comment reads more like a commit log than a comment --
> the changes you have made and the rationale for them (and
> discussion of breakages) don't belong in comments in the
> code itself. I would delete all but the first line of this
> comment.
>
>
>
> As for the issues raised in there, I think we should
> definitely only set channel 9 to drum, for backwards
> compatibility.
>
Comments were just my rationalization, if it's not needed, or could be shorten,
let it be.
That's right, the patch doesn't break any backward compatibility, I did put
such consideration in the comment so later on, folks can go back and see why.
> - * FIXME - Shouldn't hard code bank selection for
> channel 10. I think this
>
> - * is a hack for MIDI files that do bank changes in GM
> mode. Proper way to
>
> - * handle this would probably be to ignore bank changes
> when in GM mode. - JG
>
> */
>
> I don't think this FIXME has been fully resolved. I
> don't quite understand it, but it says that the proper
> way to handle it would be to ignore bank changes, which
> isn't what your patch is doing. Can you explain what
> this comment means and why it's OK to remove it?
>
>From what I understand, and strictly speaking, GM mode doesn't allow bank
>changes at all, 128 instruments and some drum kits, that's it.
Even later comments on GM specs, it's up in the air whether hardware and
software synths should disallow bank changes at all. It was noted that some
implementations automatically switch out of GM-mode when a bank change message
is received.
So the first half of the comment is handled by this patch, the later part of
that comment is a wash.
> Good work on that patch.
>
Thanks for sharing your thoughts, much appreciated.
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Propose changes for drum channels support
GOAL FOR THIS PATCH:
This patch would allow the flexibility to set any individual channel to be drum
channel, and/or unset them (revert back to melodic channel).
Add a flag to struct:
_fluid_channel_t
to indicate it is a drum channel, using int type, with value:
0: melodic channel
1: drum channel
Previously all checking for drum channel was hard-coded to compare to the
number 9 (i.e. chan == 9). So even with 32, 48, 64 channels, only channel 9
was drum channel. The channels 25, 41, 57 could not handle drums at all, even
though each 16 midi channels were showing up as a separate ALSA-Midi port.
XG allows multiple drum channels, some use channels 9 and 10 (8, 9 with
zero-indexing) and FludSynth could not deal with this previously.
GM2 allows 2 drum channels 10 and 11 (9, 10 with zero-indexing).
This patch is based on somewhat dated fluidsynth.svn399.20101221 (5 week old)
code.
Let's hear if this is a reasonable change to the code base, or not.
Jimmy
- Patch starts below: -
diff -rup fluidsynth.svn399.20101221/src/synth/fluid_chan.c
fluidsynth.svn399.20101221.jnDrumChannel/src/synth/fluid_chan.c
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.c 2010-12-21
19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel/src/synth/fluid_chan.c
2011-01-24 12:28:01.0 -0500
@@ -52,6 +52,7 @@ new_fluid_channel(fluid_synth_t* synth,
chan->synth = synth;
chan->channum = num;
+ chan->is_drum_channel = (9 == num) ? 1 : 0;
chan->preset = NULL;
chan->tuning = NULL;
@@ -68,7 +69,7 @@ fluid_channel_init(fluid_channel_t* chan
int prognum, banknum;
prognum = 0;
- banknum = (chan->channum == 9)? 128 : 0; /* ?? */
+ banknum = (chan->is_drum_channel)? 128 : 0; /* ?? */
chan->sfont_bank_prog = 0 << SFONT_SHIFTVAL | banknum << BANK_SHIFTVAL
| prognum << PROG_SHIFTVAL;
@@ -233,7 +234,7 @@ fluid_channel_set_bank_lsb(fluid_channel
style = chan->synth->bank_select;
if (style == FLUID_BANK_STYLE_GM ||
style == FLUID_BANK_STYLE_GS ||
- chan->channum == 9) //TODO: ask for channel drum mode, instead of number
+ chan->is_drum_channel)
return; /* ignored */
oldval = chan->sfont_bank_prog;
@@ -252,10 +253,8 @@ fluid_channel_set_bank_msb(fluid_channel
style = chan->synth->bank_select;
if (style == FLUID_BANK_STYLE_GM ||
- style == FLUID_BANK_STYLE_XG ||
- chan->channum == 9) //TODO: ask for channel drum mode, instead of number
+ chan->is_drum_channel)
return; /* ignored */
- //TODO: if style == XG and bankmsb == 127, convert the channel to drum mode
oldval = chan->sfont_bank_prog;
if (style == FLUID_BANK_STYLE_GS)
@@ -263,6 +262,15 @@ fluid_channel_set_bank_msb(fluid_channel
else /* style == FLUID_BANK_STYLE_MMA */
newval = (oldval & ~BANKMSB_MASKVAL) | (bankmsb << (BANK_SHIFTVAL + 7));
chan->sfont_bank_prog = newval;
+
+ /* if style == XG and bankmsb == 127, convert the channel to drum mode.
+ * How should "newval" above be calculated (same as MMA style) ???
+ * Anticipate a progChange after a bankSelect, so not much else to do here */
+ if (style == FLUID_BANK_STYLE_XG && (127 == bankmsb))
+ {
+ chan->is_drum_channel = 1;
+ }
+
}
/* Get SoundFont ID, MIDI bank and/or program. Use NULL to ignore a value. */
diff -rup fluidsynth.svn399.20101221/src/synth/fluid_chan.h
fluidsynth.svn399.20101221.jnDrumChannel/src/synth/fluid_chan.h
--- fluidsynth.svn399.20101221/src/synth/fluid_chan.h 2010-12-21
19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnDrumChannel/src/synth/fluid_chan.h
2011-01-25 13:07:49.0 -0500
@@ -74,6 +74,21 @@ struct _fluid_channel_t
* flag indicating whether the NRPN value is absolute or not.
*/
char gen_abs[GEN_LAST];
+
+ /* Drum channel flag, 0 for melodic channel, 1 for drum channel.
+ * Previously, even for 32, 48, 64 channels only channel 9 can be drum,
+ * channel 25, 41, 57 were not treated as drum channel at all, even though
+ * ALSA shows 2, 3, 4 ports (each with 16 midi channels).
+ * We can optionally initialize channel 25, 41, 57 be GM drum channel if we
+ * want for each of those 16 midi channels -- need to change channel
+ * initialization, but may break existing apps unless they explicitly set
+ * these channels.
+ * Moreover, GM2 allows 2 drum channels 10 and 11 (9, 10 with zero-indexing).
+ * Some older XG may use drum channels 9 and 10 (8, 9 with zero-indexing).
+ * Added at end of structure, hopefully existing apps using this structure
may
+ * still work without having to recompile for the time being. */
+ int is_drum_channel;
+
};
fluid_channel_t* new_fluid_channel(fluid_synth_t* synth, int num);
diff -rup fluidsynth.svn399.20101221/src/synth/fluid_synth.c
fluidsynth.svn399.201012
[fluid-dev] Propose change: all_notes_off, all_sounds_off
Propose changes for handling of "All notes off", "All sounds off".
GOAL FOR THIS PATCH:
Turn off all notes/sounds on all channels at once.
If FluidSynth allows the parameter "chan" value -1 to mean operate on all
channels, it is a reasonably simple and efficient change.
The code changes are in:
static int fluid_synth_all_notes_off_LOCAL(fluid_synth_t* synth, int chan)
static int fluid_synth_all_sounds_off_LOCAL(fluid_synth_t* synth, int chan)
will affect behaviors of:
int fluid_synth_all_notes_off(fluid_synth_t* synth, int chan)
int fluid_synth_all_sounds_off(fluid_synth_t* synth, int chan)
the main difference between the two functions are:
fluid_synth_all_notes_off() will calls fluid_voice_noteoff();
fluid_synth_all_sounds_off_LOCAL() will calls fluid_voice_off(();
although, I don't know what's the differences between fluid_voice_noteoff(),
and fluid_voice_off();
---
Previously, "All notes off", "All sounds off" will only operate on individual
channel.
To do so for 16, 32, 48, 64 channels, one has to loop through for each channel.
Not too bad, but looking at the implementation, it is just not effecient at
all.
This patch is based on somewhat dated fluidsynth.svn399.20101221 (5 week old)
code.
Let's hear if this is a reasonable change to the code base, or not.
Jimmy
- Patch starts below: -
diff -ur fluidsynth.svn399.20101221/src/synth/fluid_synth.c
fluidsynth.svn399.20101221.jnAllSoundsOff/src/synth/fluid_synth.c
--- fluidsynth.svn399.20101221/src/synth/fluid_synth.c 2010-12-21
19:02:53.0 -0500
+++ fluidsynth.svn399.20101221.jnAllSoundsOff/src/synth/fluid_synth.c
2011-01-25 12:57:46.0 -0500
@@ -1455,7 +1455,7 @@
/**
* Turn off all notes on a MIDI channel (put them into release phase).
* @param synth FluidSynth instance
- * @param chan MIDI channel number (0 to MIDI channel count - 1)
+ * @param chan MIDI channel number (0 to MIDI channel count - 1), (chan=-1
selects all channels)
* @return FLUID_OK on success, FLUID_FAILED otherwise
*/
int
@@ -1467,7 +1467,7 @@
return fluid_synth_all_notes_off_LOCAL (synth, chan);
}
-/* Local synthesis thread variant of all notes off */
+/* Local synthesis thread variant of all notes off, (chan=-1 selects all
channels) */
static int
fluid_synth_all_notes_off_LOCAL(fluid_synth_t* synth, int chan)
{
@@ -1477,7 +1477,7 @@
for (i = 0; i < synth->polyphony; i++) {
voice = synth->voice[i];
-if (_PLAYING(voice) && (voice->chan == chan))
+if (_PLAYING(voice) && ((-1 == chan) || (chan == voice->chan)))
fluid_voice_noteoff(voice);
}
return FLUID_OK;
@@ -1486,7 +1486,7 @@
/**
* Immediately stop all notes on a MIDI channel (skips release phase).
* @param synth FluidSynth instance
- * @param chan MIDI channel number (0 to MIDI channel count - 1)
+ * @param chan MIDI channel number (0 to MIDI channel count - 1), (chan=-1
selects all channels)
* @return FLUID_OK on success, FLUID_FAILED otherwise
*/
int
@@ -1499,7 +1499,7 @@
FLUID_API_RETURN(result);
}
-/* Local synthesis thread variant of all sounds off */
+/* Local synthesis thread variant of all sounds off, (chan=-1 selects all
channels) */
static int
fluid_synth_all_sounds_off_LOCAL(fluid_synth_t* synth, int chan)
{
@@ -1509,7 +1509,7 @@
for (i = 0; i < synth->polyphony; i++) {
voice = synth->voice[i];
-if (_PLAYING(voice) && (voice->chan == chan))
+if (_PLAYING(voice) && ((-1 == chan) || (chan == voice->chan)))
fluid_voice_off(voice);
}
return FLUID_OK;
- Patch ended above -
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
--- On Sat, 8/7/10, Elimar Green wrote: > From: Elimar Green > Subject: Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket > #65) > To: "jimmy" > Cc: fluid-dev@nongnu.org > Date: Saturday, August 7, 2010, 9:51 AM > This was all basically implemented at > one point in FluidSynth with a > settings option and detection of SYSEX MIDI mode change > messages, > which would modify the current settings value > dynamically. It was > removed because it was deemed incomplete (as far as all the > additional > functionality which comes with being in different > modes). It seems > like re-implementing this with minimal bank switching > behavior logic, > may make sense in the short term. But implementing > the complete XG > spec for example, is not a trivial undertaking. > > Elimar I agree with your assessment regarding XG implementation. XG may have other prorietary processing which may require special chips on the hardware side, or special DSP libraries on the software side. I don't know that for sure, just speculating. I do know that many Yamaha arranger keyboards claim to have XG, some lower end keyboards have XG-Lite, whatever that means from Yamaha specs. Even the full XG keyboards have different sound bank(s), different "sound engine(s)" under the hood. Midi and style files that sound superb on one XG keyboard may sound so-so on a different XG keyboard, may even require manually tweaking those files. I think they intentionally do so, in order to sell the new keyboards, for sure. So a softsynth may be able to emulate some part(s) of XG, but to be able to emulate any one XG keyboard would be difficult enough. Emulating the complete line of XG keyboards would be a huge undertaking. Especially now that XG specs and XG marketing material have all but disappeared from Yamaha web sites. Top of the line Arranger Keyboards all have XG features, are Tyros-3, Tyros-2, Tyros, they have some decent manuals. Below that are the PSR-S910, PSR-S900, PSR-S710, PSR-S700 (older are PSR-9000, PSR-7000, PSR-5000, PSR-3000, PSR-2000, PSR-1000). Some Yamaha XG synth(s) may support one GS mode, but they probable won't support all the features of all the GS synths and keyboards out there. I read that GS mode in Yamaha XG synths may take some individual GS sys-ex commands but won't process bulk GS sys-ex commands. If FS wants to support GS/XG mode, it should be noted as "work-in-progress and may-never-complete", so users should be apprehensive about it. Of course, all implemented features (however minute) should be documented so everyone can understand what to expect, and/or eventually augmented with more/better features. Yamaha and Roland have agreed to support GM2 within the last few years. Both may have throtled back their proprietary GS/XG marketing push. So I think moving forward with GM2 support maybe better than spending too much time and efforts on GS/XG. GM2 sounds like more standardized GM1 (especially the ambiguous parts), also allowing support for 2 drum channels. If GM2 become more popular, there will sure be converter utilities to mass convert GS/XG files to GM2, at least in term of bank select, reset, drum channels... Proprietary sys-ex will always be there, depends on special hardware anyway. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
May be this would help if someone decides to try adding some basic support for detecting GM/GS/XG modes. Of course, full support may require more work. About GS-reset: www.bandtrax.com.au/sysex.htm www.2writers.com/eddie/TutSysEx.htm XG-reset info: www.xg-central.com/xgc-introduction-midi.php www.heikoplate.de/mambo/index.php?option=com_content&task=view&id=431&Itemid=63 www.heikoplate.de/mambo/index.php?option=com_content&task=blogcategory&id=75&Itemid=57 http://www.soundonsound.com/sos/sep98/articles/xgexplained.html Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
> Date: Fri, 06 Aug 2010 18:06:12 -0500 > From: "S. Christian Collins" > > Another option, rather than try to guess what bank select > mode to use > would be to default to the GS standard, but have an option > to use XG > mode--this could even be a switch added to Qsynth easily > enough for us > GUI folks. > > That being said, if the guessing is pretty foolproof, then > that's > probably the best option. > -~Chris If such option(s) are provided, please allow dynamic mode change. I mean so that FS can play midi files (or live sequences from keyboard/sequencer) continuously without having to restart to get into a different mode (raw/GM/GS/XG). I suppose the virtual-organs folks would prefer to still get the bare-metal (raw) mode. Already mention in my last post, will repeat here. I have read somewhere that there are fairly short sys-ex messages for XG-reset, GS-reset and possibly GM-reset. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
> Date: Fri, 6 Aug 2010 07:52:14 +0200 > From: Pedro Lopez-Cabanillas > > On Friday, August 6, 2010, Elimar Green wrote: > > > I want to remark the above quotation from the SF2 > specification. SF2 bank > > > numbers for melodic channels are numbers in the > range 0 to 127, 7 bits. > > > > That is only for General MIDI (GM) compatibility > though. > > No. General MIDI (GM) doesn't use banks, CC#0 and CC#32 are > ignored in GM mode > by all standards compliant devices. > GM1 was ambiguous, but GM2 does use CC#0 and CC#32. Maybe we can try to dig into GS and XG specs to setup the specific mode for them. Many GS/XG midi files should already have some GS-reset or XG-reset sys-ex messages at the start of the MIDI sequence. From what I remember (web searches), Timidy already list the detection of GM/GS/XG mode as one of the features. Otherwise, GM1 was ambiguous so if we want, we may find a way to allow customized configuration for specific device(s) with regards to MSB, LSB, ProgChange handling. Perhaps we can also have a GM2 mode for this, which is straight forward. From http://en.wikipedia.org/wiki/General_MIDI_Level_2 It has some good info on specific GM2 bank selects (CC#0 and CC#32) before a ProgramChange to select instrument voice, separately similar info for selecting GM2 drumkit. >>> Program and bank change events General MIDI 2 compatible synthesizers access all of the 256 instruments by setting cc#0 (Bank Select MSB) to 121 and using cc#32 (Bank Select LSB) to select the variation bank before a Program Change. Variation bank 0 contains full GM sound set. <<< My take of GM level-1 is that it specified a minimum requirements, not forbidding, but allowing for additional expansion for vendor enhanced features. I think GM level-2 is similar, again quoting form wikipedia page above: >>> General requirements * Number of Notes: 32 simultaneous notes * MIDI Channels: 16 * Simultaneous Melodic Instruments - up to 16 (all Channels) * Simultaneous Percussion Kits - up to 2 (Channel 10/11) <<< Systems with 64/128/256 notes polyphony will meet the "Number of Notes" requirements, and not disqualified because they have more than 32-notes polyphony. My take with bank changes for GM level-1 is similar, the specs for GM level-1 does leave room for enhancements, that's all. Of course, different vendors have their own implementation(s), sometimes deliberately, so that they won't get sued by their competitor(s). That's why we see mumbo jumbo in MSB, LSB when crossing brand-names. Within the same brand, things are fairly consistent (except when company merged). They may change because they have to, with newer/better design/implementation goals moving forward (from Organ, FM-synth, MIDI-keyboard, Analog Synth, Digital Synth, Sampler, Workstation, Arranger...) Of course, if a MIDI files/sequences recorded on one device (or using one soundfont) being played by a different device (using a different soundfont), it may not have the appropriate instrument voice(s), and/or drumkit. In such situation, we should print out a warning, and fallback to some sane/safe (similar, if possible) instrument voice or drumkit. Our only common denominator is GM1 sound set as a required set of features. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: Migration of services
If there are only a dozen or two, I can help extracting them and a few of us here can probably manually cut and paste a few tickets each and be done with them. If there are 50, 100, or more tickets, then scripting it would be worth-while. Ticket migration can probably be automated. The following assume SourceForge, but it should work with most other web sites via HTTP, too. wget can do HTTP post, and support userid/password (with web cookies saved to a file). So you can use wget to login, save the SourceForge cookie to a file, then use that cookie for every ticket you want to create, or submit to SourceForge. More specifically, use a shell script (or perl script) login, saving the session cookie to a cookie file), loop and extract each ticket to a temporary text file, then send (http post) each ticket to SourceForge using that session cookie info. Perl may have plenty of HTTP libraries to deal with it, I haven't used those much. I assume that you can delete invalid, or unwanted tickets, right? Which is inevitable with the first few "testing" tickets. Well, in theory that's all doable. One has to try it and see if it works. Of course, userid/password is needed, using temporary password and reset it afterward is an option, too. This is script programming (Bash, Perl, or your choice of scripting language). Firefox javascript (XUL) maybe another option, too. But I'm not familiar with it and have never tried it. If you want, I can try creating a couple of tickets and see if I can create a dozen new test tickets this way. I don't know if anyone can just create a ticket. Chances are I'll have to get a SF account to get permission to create new ticket(s). Of course, the original submitter info (if we still have those) will have to be part of the textual description anyway (accounts from different systems). Let me know if you want me to try it, give me the new web site and URL for creating new ticket(s). Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: More commits on the way to 1.1.1
BTW, about instrument loading fall-back scheme... my requested changes were released as part of 1.0.9, not quite sure if it was in 1.0.8. But definitely has nothing to do with 1.1.x changes. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: More commits on the way to 1.1.1
> Date: Fri, 04 Dec 2009 19:32:32 -0800 > From: j...@resonance.org > > As I mentioned, previous FluidSynth versions would assign > incremental > program numbers to each channel. So MIDI Channel 1 > would be program > 1, channel 2 program 2, etc. There wasn't really any > reason for that > behavior. What I was referring to, was not GM > SoundFont files, but GM > MIDI files. Some GM MIDI files may assume that > program 1 is the > default for all channels, which it should be for GM > compliance. > > I'm not really convinced that having the previous policy > of > incremental program assignment is better than having it be > GM > compliant, since it would still be assigning the whole > channel space, > just different instruments for every channel. So you > would still end > up with instruments assigned to all channels, except in the > case where > the SoundFont happens to not have instruments on those > program #s. > > Or perhaps I'm overlooking something? Did previous > versions of > FluidSynth not have instruments assigned to every channel > in > incremental fashion? I don't know if the channels loaded up with incremental programs, just vaguely know that in Qsynth, when an instance of fluidsynth is loaded up it loaded the soundfont and there were some instruments loaded in the channels. I didn't try with non-GM soundfont as the only soundfont to know for sure. I do know that FS did not load anything if the specificly requested bank and program number is not available. That was a problem with quite a few Midi files out there which used GS, or XG instrument banks (no directly mappable sounds with just basic GM soundfonts). So I requested the instrument substitution to revert to bank#0, and if no instrument existed there, revert to bank#0,prog#0. That way most generic Midi files will at least sound something vs. sounded mostly silenced for those invalid instrument selections. This is also consistent with virtually all hardware synth's behavior out there. Sorry if that causes trouble for some folks who relied on such "features" previously. Perhaps the secondary reverting to bank#0,prog#0 is now causing this problem. I would have thought that folks would want to do this, especially for soundfont (especially non GM soundfont) designers to be able to hear at least some instrument. If they don't want to hear from a channel, perhaps a channel mute option would be more appropriate. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: KMid (was Re: [fluid-dev] Re: lost connection to Jack server)
--- On Mon, 11/16/09, Pedro Lopez-Cabanillas wrote: > From: Pedro Lopez-Cabanillas > > Anonymous SVN repository (provisional) > svn://anonsvn.kde.org/home/kde/trunk/playground/multimedia/kmid2/ > Compile it with KDE 4.2 or later. > > Little user documentation, at this moment: > http://userbase.kde.org/KMid2 > Thanks, Pedro. I'll check it out when I got a chance. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Thread safety long-term thoughts
> Date: Mon, 16 Nov 2009 00:37:40 -0800 > From: j...@resonance.org > > Quoting David Henningsson : > > > However, nothing new without a downside. Since the > sample is used by > > the voice renderer, freeing a preset or soundfont is > not solved easily. > > But outlined, first we should check if there is an > audio thread > > running, if there isn't (embedded case, fast-render), > we can just go > > ahead. Otherwise send a voice event saying we should > kill active voices > > referencing the preset or soundfont. We then block the > call until the > > audio thread has processed our message (simplest). > Optionally we could > > return asynchronously, but then we still need some > kind of garbage > > queue. > > > I think reference counting would help a lot with > this. When a voice > is using a sample, it holds a reference. The sample > references its > parent SoundFont, etc. This is how libInstPatch > works. If a > SoundFont gets removed or changed, different presets get > assigned, > causing the samples to become unreferenced, ultimately > freeing the > SoundFont if no more references are held. > Don't know how practical this is, but just some more ideas for the discussion. Often in MIDI, the same type of data is used time and again as the verses repeat. Depends on resources available. If the system have plenty of resources available, Fluidsynth could probably move the unreferenced presets into a cache, probably with some last-used timestamp. Don't know if the time to look up a preset in the cache again may be any faster or slower than allocating new preset, or may add an overhead to a preset that doesn't already in the cache. The cache may have its own expiration purge cycle periodically, depends on system resources, or user configurable options. For extreme scenario example, some presets may be used again within 5-10 minutes, or even 15-20 minutes for a fairly long song. But for a movie-like environment, or studio-session, should the cache keep presets longer than 30 minutes? Or the cache is so large that looking up a preset takes longer than allocating a new preset, then it becomes counter productive. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] re: Same client for Jack audio and MIDI
> Date: Fri, 23 Oct 2009 22:54:27 -0700 > From: j...@resonance.org > > I suppose we could just make the assumption that there wont > be > multiple Jack audio or Jack MIDI clients and call it > good. I could > see a user perhaps wanting to use separate Jack servers for > audio and > MIDI though. > > Any opinions or ideas on this? I haven't gotten to try running separate jackd for each soundcard. So I don't know what implications there maybe about single instance of jackd. I do know that qjackctl currently (last check was last year, though) only deal with one jackd instance. If I already have jackd started, qjackctl just assume control of that instance. Only heard on the grapevines that separate jackd can be run, and can be synchronized. I don't understand what you are refering to. Are you talking about the decription/name of the jackd-client, or jackd-client port number, or something else? I don't know of jackd options to show existing list of jackd clients, except using qjackctl, or maybe something like 'patchage'... With qjackctl, I see under the audio tab: 'fluidsynth' -- with 'left', 'right' audio channels under the Jack-MIDI tab: 'fluidsynth-mid' -- with 'midi' port below it or, under the Alsa-MIDI tab: 130:FLUID Synth() -- 0:Synth input port() Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: KMid (was Re: [fluid-dev] Re: lost connection to Jack server)
--- On Wed, 10/21/09, Pedro Lopez-Cabanillas wrote: > > I used to use Kmid, but no one ported it to Qt4/Kde4 > yet, not sure how long > > before it would be called an orphan. > > I'm already starting the adoption process. Pedro, Alright, good to know. You got SVN/CVS, discussion group for it somewhere? Would it be better depending on just QT4, or QT4.5, instead of KDE. I prefer lighter-weight apps that works well with simple interface, nothing fancy. I just read a couple of articles on Slashdot about Pulse Audio. The project lead, and some of their developers want it on every desktop and claimed that "latency is good" (???, !...@#(!^#!!!), that 20-second audio buffer would help them make less interrupt calls to save power or so. Yeah, right... Saving energy on a few lousy hardware interrupts and blast away on the speakers, or their "continuous reconfiguration daemon". Their idea of "playing music" is to use their couch-potato ears. No wonder the rap craps are everywhere and they think they are great musicians, too. > KMid is about 10 years old. It is time for a revamp. My > plans for it are: > * Remove the deprecated OSS /dev/sequencer interface > support. It has been > dropped from OSSv4, anyway. > * A fair ALSA sequencer implementation: don't > create/destroy the client and > port instances on each play/pause/stop action. This would > allow the usage of > KMid with a MIDI patchbay application like qjackctl. So you spent sometime with the adopted kid (uh... code) already :-) > * MIDI Output implemented on pluggable backends. First one > will be the ALSA > sequencer backend, but I would like to develop win32 and > Mac native backends > some day. Jack-midi could probably help on win32 and even Mac, I think??? > Also, a multiplatform backend based on > libfluidsynth would be > interesting for casual users, needing only to configure a > SF2 file and the > audio output. Some new features would be needed in > libfluidsynth to create > this backen> > Regards, > Pedro d, for instance: parse and process the lyric and > text SMF events. That is if libfluidsynth care to spend time with lyrics and midi-text events at all. Although, I think fluidsynth code is not pretty to add new functions to it. Haven't looked at Gleamsynth (a sort-of Fluidsynth in C++) since the Spring, but I think it did have some performance issues back then. I think the new kmid (or whatever its new name maybe) could do what it always does... send midi events to alsa-seq, or jack-midi, and also parse and display lyrics/midi-text. It may be interesting if it (or its library) also has a separate output port (output-only ???) for lyrics/midi-text events separately from the normal midi port. This way, people can make their own UI, or even network-UI if they want. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: lost connection to Jack server (svn Rev 243, over the weekend)
--- On Mon, 10/19/09, David Henningsson wrote: > > First - thanks for helping out with the much needed > testing! > Actually thanks to all those who have contributed to the project. > Out of curiosity, you mentioned aplaymidi before. Do you > play the song via aplaymidi and alsa-seq drivers, or do you > supply the midi file to fluidsynth on the command line? Short answer: for this test, I use aplaymidi to send midi events via alsa-seq to fluidsynth, which sends audio to jackd to the hardware driver. Later I can look into having audio effect plugins (i.e. jack-rack), have tried it, but don't use sound effects much yet. Round-about answer, it depends on what I feature(s) want to use. I'm just trying different things with different apps. I used to use Kmid, but no one ported it to Qt4/Kde4 yet, not sure how long before it would be called an orphan. If I find time to practice playing the midi keyboard, I would like to play (practice) along with some midi file(s). With a separate app, I can use it to send the midi event to "virtual midi port" and not having to worry about the various midi-port number/name changes. Patchage, or various other conneciton saving apps haven't wow'ed me yet. Sometimes I want to pick up a sequence of fast notes, for keyboard or guitar practice, tempo control allows me to slow things down. I want to be able to eventually play live on a midi keyboard, having the PC/laptop as a decent sound module and arranger keyboard functions (live rhythm machine with chord change cappability for accompaniments, with maybe a couple of separate PC-keyboards for the arranger function controls). Most of the hardware arranger keyboards and rhythms machines have very limited user interface, to me at least. Generally for computer stuff, I prefer the Unix approach of using the best tool for each task rather than a monolithic app, only run the tasks I need and each of those can be changed or switched out for something better without too much difficulties. Most of the time monolithic apps are resource hogs and slow, it would be worse if you don't like some part of it. Users don't use all the feautures all the time anyway. I cringe everytime I bring up RoseGarden, especially on some older laptops, or even older desktops. For midi's with lyrics, I like Kmid's ability to display midi text/lyrics, tempo change, transpose, keyboard note display. Timidity lyrics display sucks, only one interface allows decent control for skiping forward/backward, tempo change, transpose, while note display maybe just in win32... PyKaraoke is good at lyrics display but doesn't have any other controls I want from time to time like tempo change, transpose... Rosegarden doesn't show lyrics, it does display notes for each midi channel in realtime pretty well. It allows lasso-select from the mouse to play the selected notes as each note (or a bunch of notes) got selected. Also use Timidity from time to time, it used to have an annoying "clicking" problem with some soundfonts, which has been fixed in recent code change (last few months to a year I think). It was about some release parameters, or looping ability of the sample, if I remember that right. It may be nice to have all of those feature(s) in one huge app, but then the UI might suffer, or I may not like how it may be presented, or the logical flow sequence... Also, for large apps like Rosegarden, or even Fluidsynth, it is a pitty task to try to revamp, refactor, or add new functions. No pun intended, just a fact of life. > > As I type this, I use the mouse to drag the scroll bar > in a GUI text editor, with the midi song playing in the > background, I definitely hear the jitters during the mouse > drag. Not surprising, just mention it here anyway. > > Are XRUNs reported from Jackd? In that case, it is probably > not FluidSynth's fault. Is jackd and fluidsynth running > under rtprio? You are right. XRUNs got in the way, causing jitters/noise. > > Unison.sf2 seems to give the least noise/jitters for > me. It is also the smaller soundfont compare to the > ones listed below. > > Interesting. I've heard that before, that smaller > soundfonts are less CPU intensive, my only theory is that > this has to do with the CPU cache, with more samples, > there'll be more cache misses. This seems a little bit > far-fetched though (not only for the CPU, ha ha). Would be > interesting to know if prefetch instructions could improve > the situation. It is much more detectable on slower hardware like older PCs or laptops -- combination of slower RAM, CPU, HDD... often with less RAM, too. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] e: lost connection to Jack server (svn Rev 243, over the weekend)
--- On Mon, 10/19/09, David Henningsson wrote: > From: David Henningsson > Subject: Re: [fluid-dev] Re: lost connection to Jack server (svn Rev 243, > over the weekend) > To: "jimmy" > Cc: j...@resonance.org, fluid-dev@nongnu.org > Date: Monday, October 19, 2009, 7:28 PM > jimmy wrote: > > > > --- On Mon, 10/19/09, j...@resonance.org > > wrote: > > First - thanks for helping out with the much needed > testing! > > > I tried again, same midi file at > > "http://mmacdonald.com/midi/XG/Conquistador 3K > MM.MID". Note that this is a fairly busy, quick > tempo/pace. > > Out of curiosity, you mentioned aplaymidi before. Do you > play the song via aplaymidi and alsa-seq drivers, or do you > supply the midi file to fluidsynth on the command line? > > > As I type this, I use the mouse to drag the scroll bar > in a GUI text editor, with the midi song playing in the > background, I definitely hear the jitters during the mouse > drag. Not surprising, just mention it here anyway. > > Are XRUNs reported from Jackd? In that case, it is probably > not FluidSynth's fault. Is jackd and fluidsynth running > under rtprio? > > > Unison.sf2 seems to give the least noise/jitters for > me. It is also the smaller soundfont compare to the > ones listed below. > > Interesting. I've heard that before, that smaller > soundfonts are less CPU intensive, my only theory is that > this has to do with the CPU cache, with more samples, > there'll be more cache misses. This seems a little bit > far-fetched though (not only for the CPU, ha ha). Would be > interesting to know if prefetch instructions could improve > the situation. > > // David > ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: lost connection to Jack server (svn Rev 243, over the weekend)
--- On Mon, 10/19/09, j...@resonance.org wrote: > From: j...@resonance.org > Subject: Re: [fluid-dev] lost connection to Jack server (svn Rev 243, over > the weekend) > To: "jimmy" > Cc: fluid-dev@nongnu.org > Date: Monday, October 19, 2009, 11:25 AM > Hello Jimmy, > > I was also experiencing this. Try increasing the Jack > timeout delay (-t 2000 for example, to set it to 2 > seconds). > > I'm not sure why this is occurring. Makes me wonder > if its related to what SoundFont is being loaded > though.. Hmm. > Hi Josh, I tried again, same midi file at "http://mmacdonald.com/midi/XG/Conquistador 3K MM.MID". Note that this is a fairly busy, quick tempo/pace. As I type this, I use the mouse to drag the scroll bar in a GUI text editor, with the midi song playing in the background, I definitely hear the jitters during the mouse drag. Not surprising, just mention it here anyway. I increase the Jackd timeout to 1000 (1 second). The song plays to the end for all the soundfonts. Of course Fluidsynth non-verbose mode give the leaast jitters, verbose mode the most jitters while the Fluidsynth process is in the foreground, a little less noisy when another window/process is in the foreground. The following are about the noise/jitters in Fluidsynth verbose mode. Unison.sf2 seems to give the least noise/jitters for me. It is also the smaller soundfont compare to the ones listed below. (Personal Copy's) PC51f.sf2, FluidR3_GM.sf2, GeneralUser_GS_SoftSynthv1.43.sf2 are fairly noisy in Fluidsynth verbose mode. SGM-V2.01.sf2 seems to give the most jitters, is the largest of these soundfonts. It seems the soundfont sample size may contribute to some processing (rendering, mixing) delays perhaps? Which may contributes to the delinquency of Fluidsynth ability to respond quick enough for Jackd? I also tried vkeybd while playing the midi song. There is no noticeable delay from vkeybd via jackd to fluidsynth, which should be excellent for live playing if there is no random the noise/jitters at times. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: lost connection to Jack server (svn Rev 243, over the weekend)
--- On Mon, 10/19/09, jimmy wrote: > From: jimmy > Subject: lost connection to Jack server (svn Rev 243, over the weekend) > To: fluid-dev@nongnu.org > Date: Monday, October 19, 2009, 9:28 AM > > > This is with this weekend SVN checkout of Fluidsynth, > trying with a single soundfont for each of > > SGM-V2.01.sf2 > PC51f.sf2 > Unison.sf2 > > playing the midi file from > > "mmacdonald.com/midi/XG/Conquistador 3K > MM.MID" > > wiht Unison.sf2, Fluidsynth completes the music OK. > > I restart jackd, fluidsynth, aplaymidi everytime. The > problem is when using SGM-V2.01.sf2 (always), or PC51f.sf2 > (sometimes), Fluidsynth gives me error message that it lost > connection to Jack server. The first 2-3 tries with > PC51f.sf2, Fluidsynth never completed playing, after a few > more tries, it does seem to play to completion. I > still have yet to get to the conclusion of the song with > SGM-V2.01.sf2. The messages: > > > cannot read server event (Connection reset by peer) > zombified - calling shutdown handler > fluidsynth: error: Help! Lost the connection to the JACK > server > > > The error can be earlier (more consistent) with Fluidsynth > "-v" (verbose) option. > > The machine is 2.4GHz, 1 GB RAM, fairly recent Debian > Sid. May be more problematic on slower hardware. > For what it's worth, I just tried with some other soundfonts and verbose option. With Unison.sf2 and verbose (-v) option, I also get the same problem and error message: cannot read server event (Connection reset by peer) zombified - calling shutdown handler With FluidR3_GM.sf2, no obvious noises, but same problem with Jack server connection in both verbose and non-verbose mode. With GeneralUser_GS_SoftSynthv1.43.sf2, it is noisy at times but most of the time Fluidsynth can plays it to the end of the song in both verbose and non-verbose usage. Once in a while, it suffers the same lost connection problem to Jack server in verbose mode. Haven't played it too many times in non-verbose mode at the moment. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] lost connection to Jack server (svn Rev 243, over the weekend)
This is with this weekend SVN checkout of Fluidsynth, trying with a single soundfont for each of SGM-V2.01.sf2 PC51f.sf2 Unison.sf2 playing the midi file from "mmacdonald.com/midi/XG/Conquistador 3K MM.MID" wiht Unison.sf2, Fluidsynth completes the music OK. I restart jackd, fluidsynth, aplaymidi everytime. The problem is when using SGM-V2.01.sf2 (always), or PC51f.sf2 (sometimes), Fluidsynth gives me error message that it lost connection to Jack server. The first 2-3 tries with PC51f.sf2, Fluidsynth never completed playing, after a few more tries, it does seem to play to completion. I still have yet to get to the conclusion of the song with SGM-V2.01.sf2. The messages: cannot read server event (Connection reset by peer) zombified - calling shutdown handler fluidsynth: error: Help! Lost the connection to the JACK server The error can be earlier (more consistent) with Fluidsynth "-v" (verbose) option. The machine is 2.4GHz, 1 GB RAM, fairly recent Debian Sid. May be more problematic on slower hardware. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] drumkit substitution issue
I did an SVN checkout late Friday night (2009/10/16), just to give it a test run. I suppose the following is also a problem with the current version, too. This is on Debian Sid (up to date with jackd/qjackctl, libfluid/fluidsynth/qsynth, not up to date with other packages, but fairly current within 3-4 months). Here's the command I run fluidsynth with jackd, using PersonalCopy's soundfont PC51f.sf2: fluidsynth -a jack -j -r 48000 -g 0.40 PC51f.sf2 trying with some midi files at http://mmacdonald.com/midi/XG/ , I'm using aplaymidi to play: aplaymidi -p 130:0 "Can't Take My Eyes Off Of You MM 3k.mid" the fluidsynth messages: > fluidsynth: warning: Instrument not found on channel 0 [bank=45 prog=11], > substituted [bank=0 prog=11] fluidsynth: warning: Instrument not found on channel 8 [bank=16256 prog=0], substituted [bank=0 prog=0] fluidsynth: warning: Instrument not found on channel 9 [bank=16256 prog=27], substituted [bank=16256 prog=0] fluidsynth: warning: Instrument not found on channel 12 [bank=1024 prog=3], substituted [bank=0 prog=3] fluidsynth: warning: Instrument not found on channel 13 [bank=122 prog=49], substituted [bank=0 prog=49] fluidsynth: warning: Instrument not found on channel 14 [bank=115 prog=84], substituted [bank=0 prog=84] fluidsynth: warning: Instrument not found on channel 0 [bank=45 prog=11], substituted [bank=0 prog=11] The problem is on the drum channel (#9), [bank=16256 prog=27] was requested. It seems Fluidsynth only try to load the drumkit from: [bank=16256 prog=27] [bank=16256 prog=0] and stop searching right there. Which won't help for most people with GM-only soundfont. I suppose the drumkit search order could be a bit more generous: [bank=16256 prog=27] [bank=16256 prog=0] [bank=127 prog=27] [bank=127 prog=0] which should help whether there is any drumkits at all in bank #16256. This way, it will work for normal GM users, as well as for soundfont creators/testers, too. Although, I suspect these midi files are recorded on some arranger keyboard, or using hardware sound modules of some sort. There is at least one more midi file there for this test: "http://mmacdonald.com/midi/XG/Sweet Talking Guy MM 3k.mid" for which, Fluidsynth messages show: fluidsynth: warning: Instrument not found on channel 9 [bank=16256 prog=86], substituted [bank=16256 prog=0] I haven't had time to tried more files on that site yet. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: MIDI mode
> Date: Mon, 12 Oct 2009 20:17:21 -0700 > From: j...@resonance.org > > Quoting "S. Christian Collins" : > > > j...@resonance.org > wrote: > >> It still seems a bit weird to me to try and pick a > minimum note > >> duration, which will work well with most > instruments, which could > >> have different attack durations, etc. It may > be that it works fine > >> in practice though. I just don't like > it. If you have a > >> percussion instrument that has a short release > phase, you'll just > >> end up with a 8ms or 10ms percussion sound, so it > will still get > >> cut short and sound weird. If a MIDI file is > truly expecting > >> note-offs to be ignored, it wont be getting that > behavior. > > In theory, however, there shouldn't be percussion > instruments with > > short release times, unless that instrument's length > is variable > > (guiro, whistle, SFX). There are two conventions > that are understood > > regarding this: > > 1. Instruments that are struck and then > resonate are programmed with > > an appropriately long release to allow the sample to > play fully > > regardless of how long the note is held down... just > like a real > > percussion instrument. > > 2. Sequencers that program 0-length MIDI > events expect the above behavior. > > > > Assuming the sample programmer in convention #1 did > his job correctly, > > convention #2 will always work with the note-off > delay. > > > > -~Chris > > Ok, that makes a little more sense now. So I guess > the "missing > percussion" issue is because the note duration is less than > the attack > time? So, with a minimum note duration setting, so > long as its > greater than the attack time of the percussion instruments, > should work. > > Josh > How about Fluidsynth chooses a default minimum-note-duration for now, and allows for using configuration file and/or a way (passing configuration settings via some API, or commandline arg) to change it. This way, folks can also test against their own MIDI files and set it to their liking, or give us feedback/suggestion as to what the better default minimum note duration shoud be for future releases. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: MIDI mode
I think GM support is all I can ask for, but understand how GS, XG are designed and know how to scale them back to GM level is all Fluidsynth need to do. About MIDI mode of GM, GS, XG... I don't have any official reference, but from what I understand, GM only has 128 defined instrument list, and maybe a few drumsets. That can get old after a while. The many hardware makers of "MIDI modules", MIDI capable "synth keyboards", and "arranger keyboards" need to add better sounds on their higher priced jewels. So they decide to keep the basic GM common between one price-level to the next by adding better sounds and drumsets as extensions (extra sounds in extra banks, still keeping the familiar 128 instruments GM definition loaded with relatively cheaper sounds). Some may just be the exact sound samples with different special effect settings (panning, reverb, cutoffs...) For example they can have 4 different nylon guitar (or Sax, Strings...) sounds on the same program number, but on different banks, even if there are few or no other voices on these extra banks. They would have different "demos", or "songs", or "rhythms" using those different nylon guitars that sound much better than the cheaper hardwares they have. The cheaper hardware when trying to play those nylon guitar instruments won't have those instruments in the defined banks (via MIDI cables, or MIDI files), will fallback to use the same program number on bank #0 (GM instrument). Likewise, SYSEX's are hardware specific, mostly depends on what sound chips and what type and how many special effects (DSP) chips are on that box. If a hardware sound module/keyboard doesn't know how to handle some SYSEX messages, it simply ignores those SYSEX's. Even the higher end Yamaha keyboards won't work with SYSEX's from cheaper Yamaha keyboards, and vice versa. Because they have different hardware engines (firmwares and chips...) I know of no hardware boxes that claims to support all the SYSEX's out there, each will only handle its own particular SYSEX's to control it's own specific hardware model. That's also how GS and XG claims that they are extensions of GM and all the hardware MIDI playing (via cable connection, or MIDI files) can still render appropriate sound, of course, "appropriate sound" may only match the type of instrument voice (i.e. Strings, Nylon Guitar, Oboe, French Horn, Sax...) and may not sound at all as good as it is intended for the hardware it was tweaked for. So as long as Fluidsynth provide the appropriate "fallback" instrument-voice look up and all the basic GM features, Fluidsynth is at least as good as any GM hardware modules out there. In fact a GM-supported Fluidsynth allowing changing of soundfont would be better than all the GM hardwares that won't allow changing (customizing) of their instrument voices. I think GM support would be great... However Fluidsynth interpretes the GM specs, all hardware makers out there does the same anyway. After that, GM2 might be something to look forward to. Since Yamaha already snuffed out XG (removed all references to XG softwares and XG specs), and Roland doesn't seem to get any better brainshare with GS. Those existing MIDI files out there still only sound best on the hardware they were created on, Fluidsynth only need to sound the appropriate voices as the notes are played. The rest depends on having a superb GM soundfont and maybe a few special soundfonts on top of GM sounds. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Win32 midi loopback driver -- WAS Re: Build help on win32 with MinGW (resolved)
> Date: Sun, 11 Oct 2009 00:17:28 -0700 > > Now to > figure out how to route some MIDI through the winmidi > driver and test > some SYSEX data. Clues into how to do this would be > most welcome! Josh, Haven't use Windows for years, but have read about "Midi Yoke", or "Hubi's Loopback". I believe they provide some virtual midi ports or connection-points or something along that line. In another message, you said something about XG soundfont. There are some soundfonts with some sort of XG mapping. Of course, those may not have much to do with SYSEX handling, but may provide some lite XG soundbanks/drumsets. Not sure if any of them can qualify to support "XG-Lite" definition from Yamaha. www.rodi.dk/download1.php?yamahaxg.zip XG_Sound_Set__from_SoundMAX_DLSbyXG_.sf2 yamaha-xg-sound-set.sf2 yamaha-xg-sound-set.sf2 yamaha_xg_sound_set_re-map.sf2 yamaha_xg_sound_set_re-map.sf2 Bennet's AnotherXG.sf2 Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] re: MIDI mode
> Date: Thu, 08 Oct 2009 01:07:54 -0700 > From: j...@resonance.org > > So I went ahead and added GM On/Off and GS Reset SYSEX > handling. > There are now 2 parameters synth.midi-mode=normal/gm/gs > and > synth.midi-mode-lock=no/yes. If midi-mode-lock is set > . . . > > Feedback and testing would be appreciated :) The > "normal" value for > midi-mode doesn't sound great, but I couldn't think of a > better word. May I suggest that "gm" be the default mode for inter-operability with keyboards and sound modules. GM would probably be expected mode for most (80-90%???) of MIDI users, especially the beginners. Instead of "normal", I suppose "advance/advanced", or "fs/fluidsynth" mode (because these features exist only in Fluidsynth) would be more appropriate for the tecnically advanced, or detail specific users. Anyone wanting the more customized/advanced feature that Fluidsynth offer would be spending time to learn and tweak their MIDI's for the "advanced" mode in Fluidsynth anyway. So for them to specify the "advanced" mode would be not much of a big deal. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: FluidSynth tuning and more commits
> Date: Fri, 18 Sep 2009 12:18:06 -0700 > From: j...@resonance.org > I'm a little bit perplexed in regards to the tuning > routines though. > It seems that it allows for arbitrary per MIDI note > tuning > modifications, using floating point values in cents. > Tunings are > added by instrument bank and program #s. What is > strange, is that it > seems these tunings only take effect when > fluid_synth_select_tuning() > is called, to activate an existing tuning on a given bank > and program. > What is strange, is that this is never called in the > FluidSynth code > base, meaning that tunings will only be active if an > external > application activates them, which seems to defeat the > purpose of > bank:program tuning assignment. It seems to me like a > tuning should > be automatically used when a bank/program change occurs, if > there is > an assigned tuning for the given bank/program. The > tuning > infrastructure should probably also be integrated with MIDI > tuning > standards, for assigning tunings via MIDI. It seems > like the tuning > system is currently not entirely complete. Any > opinions on this? I'm not at all familiar with Fluidsynth tuning usage, nor the code. I only know that with MIDI controller(s) often allow hardware knobs, sliders, or pitch-bend wheel to manipulate a note's pitch. It allows one to play a note, turn the pitch-wheel, and the note pitch can be raised, or lowered to a different note range. The pitch wheel are often used to bend a note like slider guitarist would move the slider after a string has been struck. More often, I have seen keyboards that can program the pitch-wheel to bend a note up 1-semitone up/down (2-semitone range all the way to 1 full octave up/down (2 full octaves range) for the knob/slider/wheel physical range. The pitch wheel has springs-like hardware like a joystick to keep it at center if not held down, the default is normally 2-semitones up and 2 semitones down for the full range of the knob. So pushing it up all the way will change the sound by 2 semitone, push part of the way gives a proportional pitch shift of that 2-semitone range, releasing it and the sound revert back to the original note. Pushing down just does similar thing for 2 semitones down by default. Some keyboards also have modulation wheel which doesn't have spring loaded. It allows sound modulation (note vibration) for emphasis on some notes playing live. So generally, live playing needs some real-time sound synthesis for some individual notes. Of course, for people who work with soundfont, or some particular instrument range and want to try to tweek and listen to to all the samples with such adjustments, then the per bank/program selection might be the way to go for them. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Thread safety
e that > limitation. I'm thinking > > that you probably want to do a lot of initialization > at time 0. But > > perhaps we can avoid the queue altogether in case 1 > and 2? > > > Indeed. As I wrote above, functions could detect from > which thread > they are being called from and act accordingly (queue or > execute > directly). If for some reason a queue is maxed out > though, I suppose > the function should return a failure code, though it risks > being > overlooked. > > > > > >>>> Sure, if it improves things in the short > term, go ahead add it. Fixing > >>>> FluidSynth's threading issues, and doing > it right, is likely going to be > >>>> a bit of a larger task than doing simple > fixes. So it might be good to > >>>> try and address the more severe issues, > while coming up with a long term > >>>> solution. > > > > I've done so now. I did it in two steps, first all the > underlying work > > that enables the sequencer to work as a buffer for > MIDI threads > > (revision 193), and enabling that feature for > fluidsynth executable > > (revision 194). When the synth has better thread > safety on its own, we > > revert 194 only. > > > > I would really like some feedback from the community > about these > > changes, to ensure they don't change the > responsiveness or latency, or > > mess anything else up. I've tested it with my MIDI > keyboard here and I > > didn't notice any difference, but my setup is not > optimal. > > Here's my my comments on special effects processing (SFX, for short here) in sound synthesis. But since Midi allow for some live manipulation of some paramenters, it may allow for per channel manipulation, too? I guess one way to describe it is how many "SFX processors" can be used concurrently in a chained sequence. JackRack is one such implementation where each plugin is 1 SFX processor. Each of these SFX processor parameters can change in real-time. I would love to have SFX processing for individual Midi channel (individual solo instrument pan, sustain, delayed echo, vibrato...), or all channels combined audio signal (like reverb, delayed echo, pitch shift). But I guess individual solo instruments with SFX could be simulated by running in a separate instance of FS. So if per channel SFX is possible, please do allow for ways to specify which channel(s) these SFX processors should work on. You may also want to allow users to define/specify, or loaded-on-the-fly (maybe some sample code to use) these SFX processors from configuration files, and let parameters be changed in real-time. The simplest case is 0, or 1 SFX processor. More complicated are 2, 3, or more sound effects chained together, but too many of these chained together will introduce audio lags of some sort. Of course, you can impose or set a limit on the number of SFX processors, i.e 3 max per voice/channel, 8 total... Or if no specific SFX limit is imposed, at least give a word of warning so people don't have wild ideas that they can chain 5-10 SFX per channel for 32 channels... or 100 SFX together and still get real-time response on 1-2 core CPU's, or that the audio would sound like anything we can still recognize. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Re: What is the best way start fluidsynth with zero/low latency? (Louis B.)
You are right Pedro, my bad. I remembered that wrong. I got that mixed up with jackd and qjackctl combo. Jimmy --- On Sat, 5/23/09, Pedro Lopez-Cabanillas wrote: > From: Pedro Lopez-Cabanillas > Subject: Re: [fluid-dev] Re: What is the best way start fluidsynth with > zero/low latency? (Louis B.) > To: fluid-dev@nongnu.org > Cc: "jimmy" > Date: Saturday, May 23, 2009, 11:50 AM > On Saturday, May 23, 2009, jimmy > wrote: > > I still suggest they use qsynth to start > fluidsynth. Do mention that if > > they have a problem with qsynth, they can try to > start fluidsynth > > manually. Once they use qsynth to start > fluidsynth, they can use: > > > > ps -ef | grep fluidsynth > > > > to get the commandline that qsynth uses to start > fluidsynth. With that > > info, they can start fluidsynth themselves from the > commandline, or from a > > script. They can learn more about fluidsynth > commandline options after > > that if they want. > > That suggestion makes no sense at all. QSynth doesn't start > the fluidsynth > commandline executable in any way. It is a standalone GUI > program using > libfluidsynth, in a similar way that fluidsynth is a CLI > program using the > same library for the same purposes. > > There are no shortcuts, except understanding the involved > concepts. You may > ask here, in this mailing list, to the people that is > delivering these > programs to you if you have any doubts or need > clarifications. > > Regards, > Pedro > ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: What is the best way start fluidsynth with zero/low latency? (Louis B.)
> Date: Sat, 23 May 2009 13:50:49 +0100 > From: "Louis B." > > The point I was trying to make was that fluidsynth can be > rather > difficult for non techie users to get running correctly > especially > with low latency. I still suggest they use qsynth to start fluidsynth. Do mention that if they have a problem with qsynth, they can try to start fluidsynth manually. Once they use qsynth to start fluidsynth, they can use: ps -ef | grep fluidsynth to get the commandline that qsynth uses to start fluidsynth. With that info, they can start fluidsynth themselves from the commandline, or from a script. They can learn more about fluidsynth commandline options after that if they want. > The more I think about it a fluid-start and fluid-stop > script might > make it very easy for non techie users to startup > fluidsynth with low > latency. It could do a "cat /proc/cpuinfo | grep MHz" to > determine if > users had a low, medium or high powered machine. Now that > FluidR3_GM.sf2 is pretty good this script could > automatically start > fluid with that sound font (Is FluidR3_GM.sf2 available to > most Linux > distribution? are there any licensing restrictions with > FluidR3_GM.sf2?). It is just an idea anyway. I may have read somewhere, or have the impression that Intel Atom is just a new release of the i386 core (or i486), probably with socket (pins) change. Remember the netbooks are for web browsing, not a speed daemon. Basically they have the same CPU speed as 7-10 year old laptop. I have qsynth, qjackctl running OK on a 700MHz, 256MB RAM notebook. The problem may also be lack of memory when using a large soundfont file, which does require memory swapping, affecting response time. On that machine, I have to use a small soundfont. Do note proper IRQ, and process priority settings may improve response time, as mention in one of the links of my last message on this thread. > There is always the problem with underruns, My atom > baised NetBook is > probably a good example of the absolutely the lowest spec > machine that > could run with low latency. Hopefully the main stream > Linux > distributions will improve to guarantee a quality of > service to > fluidsynth. You may get underruns if you try to use too low a response time settings. Bump it up 2-4 times the minimum should get rid of most underruns with just a slight compromise on real-time playing, which may be no worse than playing "strings", or "synthesized voice" instruments. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: What is the best way start fluidsynth with zero/low latency?
> Date: Thu, 21 May 2009 15:19:26 -0500 > From: "S. Christian Collins" > > Regarding the rt kernel, it seems that the newer default > Linux kernels > seem to handle realtime audio quite well even without using > a rt > kernel. I stopped using the rt kernel in Kubuntu > 9.04, because the > standard kernel seems to perform just as well, but without > the > instability the rt kernel brings. Does anybody else > have a similar > experience? > > -~Chris > Re: What is the best way start fluidsynth with zero/low latency? The fastest way and shortest answer is to install Linux from a music (MIDI) oriented liveCD. Read below for more info. --- The last 5-6 Linux kernel releases had high-resolution timer features that will work with for MIDI low latency. The last 2-3 kernel releases had merged in the realtime patch. But recently there is a new kernel realtime patch started again by the same people. Started a while back when I compiled my own kernel, I only needed the high-resolution timer configuration, I don't use the realtime kernel patch, and high-resolution timer works fine for MIDI low latency. If I am not mistaken, using Alsa directly normally only alow one app to use the sound card at any time. Using Jack, it works as a virtual mixer of sort for all jack-enabled apps. Midi low latency involves configurations of various hardware, linux kernel, and softwares that are specific to real-time response for midi events. It can be overwhelming for new users. I highly recommend starting with a music/MIDI oriented Linux liveCD distro. LiveCD allows people to just boot directly from the CD/DVD and it takes care of auto configuration. These music oriented liveCD already has either realtime or high resolution timer kernel preconfigured and will launch jackd preconfigured in their application menu. If pianobooster.sourceforge.net is somewhat stable (usable) and don't have licencing problems, you may want to lobby the various music oriented liveCD distro to include PianoBooster on their CD. Some of those liveCD's I can remember right now are Musix, PureDyne, 64 Studio. Although, the latest Musix beta is now half of a DVD so it should have plenty of room. These 3 liveCD are Debian compatible (can use Debian repositories directly) and can be installed onto hard drive if the users want to install more apps, or tweaks. I haven't tried their recent releases, but some liveCD's running directly from the CD/DVD may allow for saving your configurations on to USB, or hard drive and use such configuration in subsequence boot from CD/DVD. By the way, Ubuntu is Debian derrived (not directly compatible) and uses its own repositories. -- This fluidsynth web page currently (2009-05) has some info for using Alsa driver directly. http://fluidsynth.resonance.org/trac/wiki/LowLatency These links have info on kernel configuration, IRQ interrupt priorities, and jackd info. http://sarigama.namaste.jp/micro/la.txt http://www.rosegardenmusic.com/wiki/low-latency_kernels http://code.goto10.org/projects/puredyne/wiki/KernelAndSystemOptimization https://help.ubuntu.com/community/HowToJACKConfiguration https://help.ubuntu.com/community/HowToQjackCtlConnections Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Thread safety
> Date: Tue, 19 May 2009 07:28:07 +0200 > From: David Henningsson > Here's an answer for you, jimmy, and anyone else whose > questions can be > shortened to "you won't break anything, will you?" :-) > > First, to me it seems like the current synchronization > handling is very > broken, and I see ticket #43 as evidence of this. So > something really > needs to be done. > > As for the latency/performance issues, I haven't noticed > any difference > in responsiveness when I've tried it here. There is a > theoretical > possibility though, that > > 1) midi events in some cases will be delayed up to 64 > samples, i e 1.5 > ms with the normal sample rate, but on the other hand, in > some other > cases the current handling will delay the midi events > instead. > > 2) since the audio thread has to do more work, this might > increase the > possibility for an underrun. That would be if you trigger > very many midi > events at the same time. (Note: If you use MIDI physically, > i e the > 5-wire DIN connection, this won't be an issue. That > protocol is so slow > that it can only insert approximately one midi event per > millisecond > anyway.) > > Last, I will test my patch here before I commit it. But I > won't test all > platforms and applications, so I count on you to do that > when my patch > has reached the repository. If it turns out that it breaks > responsiveness or anything else, we can either improve the > patch, or in > worst case, throw it away. > > // David David, One quick way you can test the realtime responsiveness is to play some notes with vkeybd while having kmid (or other apps) playing a midi sequence. Clicking on a piano key in vkeybd (or press a valid key on the PC keyboard while vkeybd has proper keyboard focus) should render the sound almost instantly. If there is perceivable delay before a sound is heard then the latency may be a problem for live playing. You can try with the current behavior and the new code to have an idea. I suggest that, because I don't normally build FS from source that often. I think I understand some of the problem with FS is because the way it set and get nested structure variables directly without checking for null (which could be (un)set by any thread). IMHO, the real way to fix that is to change the codes to use getter/setter functions and check for nulls there. But such changes will be a major code overhaul (everywhere in FS) and may potentially affect some api's too. Of course, that will slow down FS somewhat, too. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Thread safety
Some more questions for David, I don't know of the FS internal threading code or David's propose changes. But let me ask if the change may affect apps that use 32, 48, 64, or more channels? There are some apps that use such features in FS. Along with that, what about cases of running multiple apps and multiple hardware sequence players (drum machine, background sequences, and midi keyboards... at the same time) that connect through jackd to FS playing in live (in real time, low-latency)? Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] The 1.1.0 milestone
> Date: Sun, 19 Apr 2009 12:25:30 +0200 > From: Bernat Arlandis i Ma?? > Thanks Jimmy for caring about the fate of my efforts. You > might not know > that everything I've done is in the public trac repository > > (http://fluidsynth.resonance.org/trac/browser/branches/2.x), > the changes > I was in the middle of won't get committed since they would > break it, > and the other things that were already thought out aren't > written > anywhere, so it's just what's there. There's one > refactoring change > done, and some little fixes, one patch is already merged in > the stable > version. So that's everything and it's not that much as you > can see, I > was just starting. > > It seems like something has sparked Josh's interest and > he's the > maintainer, so I guess that's the new path to take and we > must > reposition ourselves to the new plan. My interest on FS was > going for > the big things and I don't feel like developing them with > the current > codebase (I explained what would make my work > easier), so here is where > my FS development interest ends. I'm a bit upset at Josh > for not knowing > how the new plan affected the previous one, specially > because it's been > just a few months since we talked about it. > > I don't feel bad for the time spent doing this, I've get to > know the > project and the people behind it better, and I've dropped > some ideas > that could be useful, it's not wasted time. I might find > time to help in > the list and do some small patches for fixing bugs that I > find, that's > all I want to do for now. > > Best regards. > > -- > Bernat Arlandis i Mañó Bernat, thanks for pointing out the 2.x code branch is already there. I took a diff of that and fluidsynth SVN 20090317 (last time I got it, close enough). There are some changes but not alot of changes so far between 1.0.9 and 2.x. Anyone who had made any code diff's for 1.0.9 branch should have little problem merging their changes with the current 2.x code branch. The real question should be this: is the 2.x code as it exist now is reasonable to adopt and move forward with. The majority of the code is still identical. If 1.1.0 is to go ahead and add changes with gobject, and libinstpatch, those changes will introduce much more changes to the underlying structures than the differences between 1.x and 2.x code base right now. So anyone who has an hour to spare, you can do a check out of 1.x SVN and get the 2.x zip file from the trac page that Bernat pointed out, do a quick diff, take a look and add your comments if you will. Those with code diffs for new features, take a look and see for yourself how much or little work it would take to merge. Again the real question is whether the current 2.x code is something that has severe adverse affects on anyone. Of course, moving forward is going to be much different and will affect existing code for everyone, especially with the adoption of gobject, and libinstpatch. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: The 1.1.0 milestone
Let me clarify what I think. So Josh has agreed that all the "new features of 1.1.0" will be implemented. Which means those new features will have to be ported to 2.0 (API compatible or not). But let's not create more work this way and then make the folks who adopted these new features (I mean additional users of 1.1.0 new features beyond currently counted) migrate to 2.0 shortly there after (if they want to). If they don't want to migrate, we have to support and fix any bugs and that's more work than neccessary. Why not go ahead and work on 2.0 (however it goes)? Since there won't be 1.1.0 or any major changes in 1.0.9 code base, those who uses 1.0.9 with the "new features" (only a few at the moment) won't have to worry about major code base changes, and prevent new folks from adopting these new features and become legacy issues. Not only that, document the design of these new features for 1.1.0, then having to possibly re-explain, or changed totally in the new code base of 2.0 because of new API would cause lots of headache for everyone involved. Best regards, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Re: The 1.1.0 milestone
> Date: Thu, 16 Apr 2009 20:01:04 +0200 > From: David Henningsson > I think a wrapper (as jimmy suggested) is an almost > must-have. I don't > know how much incompatibilities there will be, but we have > 10-30 > projects depending on us, so if we don't, my guess is at > least half of > them will stay with 1.x. Although I name it as a possible thing to do, I do question the true cost of efforts being worthwhile thing to do. Folks who want to use old features should just stick to 1.0.x code base. I think for the price of progress, a migration is for the better. Just think about how I was shackled to Windows because I continue to use and accepts MS Office file format. Once I decided (several years back) that I will only create new files using Koffice, or OpenOffice file format, and convert any older files I need right away to the new format. Also, any old files I don't need to access right away won't be converted until absolutely needed, this way I don't have to waste time converting files I may never need. Suddenly, I am free as a bird. > > I decided to go by myself since there wasn't any > active contributors > > interested and it was a bit hard for me to explain in > detail what I was > > going to do in advance. I think is still hard to work > together in the > > direction I've taken without talking a lot, but > there's many things that > > can be done still in the stable branch in parallel. > > So, how do you (and the others on this list) think we > should proceed now > that there are active contributors interested? > > Let's sum up some possible ways: > > 1) The 2.0 is merged with current 1.0.9 asap and then we > all make an > 1.1.0 (i e with no API changes that are not backwards > compatible). > Requires somebody to write wrappers for the parts already > API broken. > > 2) We never make a 1.1.0 and we all start working with 2.0 > instead. > Requires lots of talking and work. And preferrably a > release date/plan? > > 3) We continue to work in parallell with 1.1.0 and 2.0, > with new > features in 1.1.0, means double-work and hard merging. > > 4) We continue to work in parallell with 1.1.0 and 2.0, > with almost no > new features in 1.1.0, means 1.1.0 will be restrained "hey, > you can't > touch this". > > >> > Being one of the people "jumping in", I don't > know much about Miguel's > >> > fork/branch or the 2.0 branch. That's why I > asked for some pointers, so > >> > I don't have to read an entire year of > messages. What I'm looking for > >> > the answer to is why all of you decided to > branch instead of doing code > >> > cleanup one piece at a time, into the stable > branch. I'm sure you had > >> > good reasons for doing so, I just don't see > them. > > The main problem was breaking API compatibility and > other > > quality/stability issues that might be important for a > stable branch. Of course I don't speak for anyone but myself. I'm just thinking aloud here. It seems no one has really seen Bernat's new refactored code yet. So it is not really clear if it makes good sense to make pre-judgement on how good or bad the new code base and new API may be. I assume Bernat is more than willing to donate the code back to this community to bring uo the issue here. It would be nice if we take at least a quick look at the code and see how it goes from there. But so far, there's no interest in hosting the the refactored code package. It may offend some folks, or may cause a riff if the code is posted elsewhere, so Bernat may be reluctant to do so, besides the added responsibilities of maintaining such code. I guess Josh may be busy with so many projects and other things to do, he may not want to take this code and it falls on his plate as additional responsibility since it is hosted by this project. Plus, this new code base is somewhat new and has different slant to how things are stuctured and fit together. I could only suggest that Josh should go ahead and create a temporary branch, call it something unoffictial and obscure, like 0.0.8765 and anyone here who is interested could take a look. This way each of us can decide if the new refactored code looks OK or not and decide what may be better. I see the push for 1.1.0 in similar light of not wanting to apply and migrate such code diff's for every new release of FS. At the same time, such new code diff's are so new that there is only one or two people using it. So it is not too critical, so let us not rush to adopt such new features and having to maintain it along with any possible bugs or issues as p
[fluid-dev] Re: The 1.1.0 milestone (jimmy)
> Date: Wed, 15 Apr 2009 05:15:31 -0700 (PDT) > From: jimmy > And I don't think gleamsynth is not API compatible at all > with fluidsynth, mostly because of data structures. Uh, typo on my part. What I mean to say is GleamSynth is not API compatible with FluidSynth, from what I saw -- Gleam 0.0.2. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
re: [fluid-dev] 1.1.0 Schedule, Trac permissions, etc
> Date: Tue, 14 Apr 2009 17:56:29 -0700 > From: Josh Green > > To help make things a bit more organized I will set forth a > plan for the > 1.1.0 development cycle. This is not set in stone and > is open for > input. > > Development cycle will be 3 months, which means FluidSynth > 1.1.0 will be > released around July 12th. Feature freeze will occur > 2 weeks before. > > June 28th: Feature freeze > July 12th: FluidSynth 1.1.0 release Unless these are current diff's that can already be applied, I think new efforts in reworking existing code with gobject, libinstpatch... will probably cause API issues, too. So why not have everyone take a quick look at Bernat's propose code first, which is currently fully functional, then decide. Why not create a branch 0.2009.x, or whatever code branch, for Bernat code for people to take a quick look and see how reasonable it may be to work with it? Sure, we don't have to claims it being official future FS code. Otherwise, that Bernat's code will be obsolete quickly with 1.1.0 changes. Short of that being "made available" here, it might turn into a real forked project because his code can't seem to see the light of day in the code repository. I could feel Bernat's worries. I only had a simple hack and didn't want to re-patch FS everytime a new version comes out. His changes are major restructuring, or morphing of sort... Ouch!!! Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Re: The 1.1.0 milestone
> From: Bernat Arlandis i Ma?? > > Right now it's fully functional and equivalent to 1.0.9, I > didn't want > to loose any functionality and it hasn't, but it has broken > API > compatibility. Great. Now we should try to determine if the 2.0 API are sensible and expandable for future changes. As for backward compatible API, we can try to determine if it is at all possible, to make libfluidsynth-1.x.x wrapper (separate lib) around the 2.0 API without having to make 2.0 itself backward compatible. > I decided to go by myself since there wasn't any active > contributors > interested and it was a bit hard for me to explain in > detail what I was > going to do in advance. I think is still hard to work > together in the > direction I've taken without talking a lot, but there's > many things that > can be done still in the stable branch in parallel. Fully understandable. Of course folks who have made changes to 1.0.x who don't want to see their changes lost can contribute their diff's and we can gather them up for 1.1.0. Everyone understand that 1.x.x is aging and could use different libraries (libInstPatch...) But to spend too much time on the new timer code on 1.x.x just for faster than realtime rendering (for some folks, not even other projects) is much less productive, IMHO. Especially these changes are iffy as to how flexible the new code may fit into 1.x.x. I'd rather see such efforts spent on how to work the new timer into the 2.x code base. > Having a new branch with a similar aim to 2.0 is > meaningless and not > that useful because when the two branches differ more and > more it'll be > harder to merge some changes from one to the other. There's > also some > areas where the solution taken for 1.1.0 might not work for > 2.0, so > unless it's something critical we could rather fix issues > in other areas. Same thinking here. > On Tue, 2009-04-14 at 18:06 +0200, David Henningsson > wrote: > > > > Being one of the people "jumping in", I don't > know much about Miguel's > > > fork/branch or the 2.0 branch. That's why I asked > for some pointers, so > > > I don't have to read an entire year of messages. Miguel's CPP implementation (gleamsynth.sf.net) seems to only basic support Alsa and Jack driver on Linux when I tried it a couple of months back. Not sure about other platforms since I don't use those. The major problem for me was audio performance, it does seem to have some lags or skipping when I tried live-playing. Although I haven't spent much time with it since. And I don't think gleamsynth is not API compatible at all with fluidsynth, mostly because of data structures. > I don't mean to be an obstacle for new development, so if > this sound too > restrictive for the new programming forces we should decide > whether we > hold to the old 2.0 plan or refrain from it and start > another one. You > should understand that doing long-term work on a project > that might > shift direction anytime isn't pleasant. > > -- > Bernat Arlandis i Mañó I can see your pain :-( Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: The 1.1.0 milestone
It seems we are all looking forward to 2.0, while 1.0 is agreed as legacy code base. I don't know how far along the code refactoring (FS 2.0) is. Can we get a status update, or current functions available. What's missing compare to 1.0.9? It may be better if we put more efforts to work toward the new 2.0 code and get it to a somewhat fully functional equivalence of 1.0.9. It would be a waste of time to make changes to 1.0 code, only to have to redesign everything because 2.0 won't be compatible at all. Sure, the 2.0 code could be using libInstPatch and any other libraries, or features that makes sense. Let's get a way so folks can checkout the 2.0-dev code first, new patches can be posted here before checked in to the code repository by a couple of main contributors for now. This way, folks can try, or test out the new patches without checking out half-broken daily updates. Anyone who can't live with 1.0.9, and must have the current extra patches, feel free to patch your own code. Since 1.0.9+ won't be too active. Just my thoughts. If it makes sense, just put in your personal informal vote so by next week we could have enough vote of confidence on where to put most of our efforts next. My vote is let's go for 2.0. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Re: Timing revisited
> Date: Saturday, April 11, 2009, 9:00 AM > . . . > Okay, I stand corrected. Judging from the design of the > audio drivers > and the player/sequencer, it seems like those parts were > designed for > live usage only (up to now). Whatever changes made, please do keep in mind, and test the live usage scenario. The test can be simple as playing a midi file, and have vkeybd (conneted to same fluidsynth) plays live at the sametime. Any serious lags from the time of vkeybd note is played and the sound is heard would be bad for live playing. vkeybd is very small and fairly simple to try. I am learning to play along, so live playing is prefered, and much needed. As for faster than real time rendering, it is nice to have, but please don't break live playing feature. If you have only a few files, what's the hurry? If you have a few hundred (or thousand) files to convert, what about overnight, or weekend batch convert? Don't know if the following may affect Fluidsynth in any way now, or later. Some note on new system/kernel timer module, I saw in kernel 2.6.29, there a new module: snd-hrtimer . I did a web search, and read a few blurbs. I haven't load the latest Alsa, or latest jackd/qjackctl yet. But the following already works with my (not up to date) Debian Sid: kernel 2.6.29 SMP PREEMPT (high-res timer) alsa-base 1.0.16-1.1 jackd 0.116.1-2 jackd can make use of the snd-hrtimer after: sudo modprobe snd-hrtimer jackd -c h -Xseq (and other args) I think audio group may need to own /dev/hpet . One can get some info from running: cho " --- /proc/asound/timers ---" cat /proc/asound/timers echo " --- /proc/asound/seq/timer ---" cat /proc/asound/seq/timer before and after starting jackd and note any differences. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[Fwd: [fluid-dev] Midi standards (was: Fix for problem with CC changes to Bank MSB)]
> Date: Sun, 05 Apr 2009 11:14:57 +0200
> From: David Henningsson
> I've tried to dig a bit deeper here. It is hard to find
> free standards
> on the net (has anybody bought a copy from midi.org?), but
> I found the
> XG standard here:
>
> http://web.archive.org/web/20060926124939/http://www.yamaha.co.uk/xg/reading/pdf/xg_spec.pdf
David, thanks for this link. I will appreciate any other XG info out there,
too.
> The first question is: What do we really support? GM? GM2?
> GS? XG? For
> XG, the drum kit bank is 127, not 1.
Here what I think, from the patched code, it uses:
(unsigned int)((bank_msb << 7)
which is " 0001" shifted left 7-bits makes it:
1000 (binary)
which is 128 if counting from 1 (or 127 counting from 0). So that is the drum
channel. I think the original midi spec uses 8-bit machines, so bit #8
(highest bit of that time) was reserved for drum.
With 16-bit (32-bit, 64-bit) hardware, using only 8-bits is such a waste. So
GM and GS were born using 16-bit hardware, extending their own MIDI usage using
the higher bits while trying to keep the first 8-bits backward compatible. I
think that's how we call these the Most Significant Bits (higher bits) and
Least Significant Bits (lower bits) in the same 16-bit integer.
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
> Date: Sun, 15 Mar 2009 18:51:06 -0700 > From: Josh Green > > Hello Jimmy, > > Sorry for the delay. I looked over your proposed > changes. It doesn't > seem like that is really the proper place for them though > (would affect > the default SoundFont loader only). > > I went ahead and implemented this logic in > fluid_synth_program_change. > > This seems to satisfy basic preset fallback > selection. So I've closed > Ticket #23. Please let me know if this functionality > works as expected. > > http://fluidsynth.resonance.org/trac/ticket/23 > > Best regards, > Josh Green It seems to work now. Thanks. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: XG programChange -- Was: Re: [fluid-dev]
> Date: Wed, 18 Feb 2009 16:16:01 +0100 > From: Peter Gebauer > > Heya Jimmy! > > ... Ideally, > I'd like to retain XG > mode on my piano, but let fluidsynth interpret them as > simple GM program > change messages. > I've seen a few patches for GS (Roland), but none for > XG and I've yet to > come across a complete spec. Seems like most hackers just > reverse enginere > it. Before XG disappeared from Yamaha website, I think they did make some XG docs available at least for a short while. That's what I could piece together from the waybackmachine. There are quite a few free tools (win32, or java) from jososoft.dk site that deal with Yamaha style files for all kind of Yamaha keyboards, don't know how he does it, might be the reverse engineering trick. > I do realize that there might be patent complications or > similar, which > is why I was looking to write code that doesn't really > handle XG, but simply > extracts whatever it needs to change the program number > based on XG > messages, not really implementing XG as such. > > As it is, writing "prog # #" is easy enough, > I'm not sure I want to spend > hours reverse engineering XG to get the program change > support. :/ > Anyway, thanks for your answer! I think a bank select prior to prog change is expected with XG, not quite sure, but should not hurt. You might want to try Alsa's arecordmidi to record just the midi portion you want and see if you can work from that. There is a couple of midi2text, text2midi converter out there. A perl one still be at interglacial.com/~sburke/pub/midi_text24.pl Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: XG programChange -- Was: Re: [fluid-dev]
> Date: Mon, 16 Feb 2009 19:32:41 +0100 > From: Peter Gebauer > > Hi again, Jimmy! > > It's hard to search for these things, 99% of the hits > are online stores > selling Yamaha products. In any case, the midi events > logged contain just > one program change event, the rest are control changes and > system > exclusives. > I really don't know why they aren't simply sending > one program change, > I cannot make any sense of what it sends now. Maybe I can > force it into > GM only mode. > > /Peter Peter, You mean searching for the Yamaha manuals? If I forget where to start, I normally goto yamaha.com, look around for musical instrument, keyboard area, then browse around for manual library. Anyway here are the links to the yamaha manual library, pdf format: www.yamaha.co.jp/manual/english/index.php text format: http://www.yamaha.co.jp/manual/english/text/ The P-85 does seem to have a data list, but only show up on the PDF search, no text format: http://www2.yamaha.co.jp/manual/pdf/emi/english/cla/p85_en_dl_a0.pdf Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: XG programChange -- Was: Re: [fluid-dev]
> Date: Mon, 16 Feb 2009 16:30:05 +0100 > From: Peter Gebauer > > > Hi Jimmy, > > migth this be what happens with my Yamaha P-85 when I > change istrument? > > Logged midi events when changing: > > 2754,M Audio Delta 1010LT:0,System exclusive,,10,f0 43 73 > 7f 4b 11 00 45 > 00 f7 > 2752,M Audio Delta 1010LT:0,Control change,1,94,0 > 2752,M Audio Delta 1010LT:0,System exclusive,,9,f0 43 10 > 4c 08 00 11 7f f7 > 2751,M Audio Delta 1010LT:0,System exclusive,,10,f0 43 10 > 4c 02 01 40 00 > 00 f7 > 2749,M Audio Delta 1010LT:0,Control change,1,91,25 > 2749,M Audio Delta 1010LT:0,System exclusive,,10,f0 43 10 > 4c 02 01 00 01 > 11 f7 > 2747,M Audio Delta 1010LT:0,System exclusive,,10,f0 43 73 > 7f 4b 11 00 45 > 7f f7 > 2745,M Audio Delta 1010LT:0,Program change,1,0, > 2745,M Audio Delta 1010LT:0,Control change,1,32,112 > 2745,M Audio Delta 1010LT:0,Control change,1,0,0 > > /Peter Peter, I don't know for sure how the Yamaha P-85 handles it. Though, you could try to do a program change to a distinctively valid instrument (piano, string, nylon guitar), then try to set it to use the same, or one of the other instrument (program number) on a different and invalid bank (i.e. bank #111, ...) and see how it handles that program change. I also think that there are some sound banks that have only a few instruments (not all 128 instruments). So midi, or style files from one sound module (or keyboard) will generally sound different from a different sound module, because non-existing selection reverts to using the basic GM (bank 0) 128 instrument sounds. If you look here: www.mboss.force9.co.uk/miditext/Xgvoice.txt you can see someone had taken some notes on some XG instruments mapping there. Note the bank and prog combination. I believe some Yamaha keyboard manuals do list their instrument map, especially the more costly models. Not 100% sure, but if interested, you can search the Yamaha keyboard manual library for Tyros, Tyros2, Tyros3, psr-s900, psr-s700, psr-s500, psr-9000, psr-3000, psr-1500, psr-1000, or your own P-85. I believe Yamaha also has text version of some of their keyboard manuals, too, which would help if you want to take personal notes by extract some of those mapping table. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
XG programChange -- Was: Re: [fluid-dev] invalid instrument/drum selection
Hi Josh, About XG (and GS) program changes, and how missing instruments might be handled, Here are some comments and observations I found around the web. I think missing drum-kits should be handled similarly. >>>>> archive.cs.uu.nl/pub/MIDI/DOC/xg.txt Both specs also operate a scheme of tone 'fallback', whereby if a variation tone is not present at a given bank program number, then the synth will fall back to using the corresponding GM tone. (the GS spec does this in a cascading fashion, i.e. falling back to the next lowest variation tone of the same program numberthis can be confusing). The advantage of the fallback scheme is that if a song uses variation tones and is played on a synth of lesser specification (or purely GM specification) then the voicing will still be acceptable (although not ideal). <<<<< >>>>> cybermidi.powweb.com/faq/content/3/22/en/what_s-the-difference-between-gm-gs-and-xg.html Although the XG format defines an extensive range of parameters and allows exceptionally fine musical control, not all XG devices need to conform to the full XG specification. The XG format allows features and capabilities to be "scaled" according to price and target applications. When music data is played on a scaled-down XG device, playback is adapted to the capabilities of the device used. If, for example, a specified voice is not available for a certain part, that part will be played using a similar basic voice. On the other end of the scale, models equipped with a graphic equalizer can be automatically set to play hard rock pieces or classic compositions with appropriate overall EQ. <<<<< >>>>> www.somascape.org/midi/help/intro.html The voices in the extra banks align with those in the standard GM bank, thus providing variants on the standard voices. This means that a MIDI file composed for use with a GS or XG device will sound okay when played using a standard GM device (because a GM device will ignore any Bank Select messages and just respond to the Program Change messages). <<<<< Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
Hi Josh,
One more try. This also takes care of drum bank 128 fallback. Here is
fluid_defsfont.c : fluid_defsfont_get_preset()
>>>>>
fluid_defpreset_t* fluid_defsfont_get_preset(fluid_defsfont_t* sfont, unsigned
int bank, unsigned int num)
{
fluid_defpreset_t* preset = sfont->preset;
fluid_defpreset_t* fallback_preset = NULL;
while (preset != NULL) {
if (num == preset->num) {
if ((preset->bank == bank)) {
return preset;
}
if ((128 != bank) && (0 == preset->bank)) {
fallback_preset = preset;
}
}
if ((128 == bank) && (0 == preset->num)) {
fallback_preset = preset;
}
preset = preset->next;
}
if (( fallback_preset != NULL )) {
FLUID_LOG(FLUID_WARN, " --- fluid_defsfont_get_preset: no instrument found
for [bank, prog: %d, %d], substituted with: [bank, prog: %d, %d]", bank, num,
fallback_preset->bank, fallback_preset->num );
return fallback_preset;
}
return NULL;
}
<<<<<
Please don't forget
fluid_ramsfont.c : fluid_ramsfont_get_preset()
Best regards,
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
> Date: Sat, 31 Jan 2009 20:20:45 -0800
> From: Josh Green
> On Fri, 2009-01-30 at 10:14 -0600, S. Christian Collins
> wrote:
> > I'm used to the following behavior when using MIDI
> on a Creative card:
> > when I select an instrument not present, such as bank
> 8 program 20,
> > the MIDI track will sound using bank 0 program 20
> instead. This seems
> > like a simple and logical way to deal with missing
> patches, and is
> > what I've come to expect when working with MIDI.
> >
> > -~Chris
>
> Easy enough. I'll add something to this effect.
> Josh
Hi Josh,
I haven't tried to see how I could get to invoke , or try
fluid_ramsfont.c : fluid_ramsfont_get_preset()
Anyway, here's what I tried for
fluid_defsfont.c : fluid_defsfont_get_preset()
>>>>>
fluid_defpreset_t* fluid_defsfont_get_preset(fluid_defsfont_t* sfont, unsigned
int bank, unsigned int num)
{
fluid_defpreset_t* preset = sfont->preset;
fluid_defpreset_t* fallback_preset = NULL;
while (preset != NULL) {
if ((preset->num == num)) {
if ((preset->bank == bank)) {
return preset;
}
if ((preset->bank == 0)) {
fallback_preset = preset;
}
}
preset = preset->next;
}
if (( fallback_preset != NULL )) {
return fallback_preset;
}
return NULL;
}
<<<<<
That would use a fallback_preset, still return NULL if no prog_number is found.
Of course it is just my hack at the code. It may or may not be the
appropriate place, but is the most efficient from the little that I could
understand. If it looks OK, you may want to put in the changes as appropriate,
and similar change for
fluid_ramsfont.c : fluid_ramsfont_get_preset()
Best regards,
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Fluidsynth internal structures
> That's me, and for the record I'm still working on > it. Work just goes > more slowly than I would like because most of my energy > goes into my > real job :-). But anyway most of the functionality I > initially set > out to achieve is there. > > -- > Miguel > Check out Gleam, an LGPL sound synthesizer library, at > http://gleamsynth.sf.net Hi Miguel, I know you have a Debian package prebuilt. I did try to take a look at buiding gleamsynth from source, but the build tools were not available as packages on Debian (I use mostly Debian Sid/Unstable). Plus some of those have versions that only work with some older tools like (GCC 3.3) or so. That was more hassles than I had the time to deal with. Best regards, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
[fluid-dev] Fluidsynth internal structures
Hi folks, I know Miguel(???) was working on a reimplementation of FS using CPP. Plus, some folks here are looking to modularize FS. You may want to use some kind of dictionary, or table look up for some of the structures (objects) used in FS. Hopefully for a more efficient and a little faster real-time look up. For what it's worth, I have been tracing through some of the FS code and find that the structure: fluid_sfont_t can be a virtual pointer to a font structure of type: fluid_defsfont_t which contains a pointer to a "preset" structure: fluid_preset_t There is a preset for each prog_num in each soundbank(s) of a soundfont. As used in fluid_defsfont.c : fluid_defsfont_get_preset() The fluid_preset_t is a link-list structure pointing to the next fluid_preset_t structure. Basically, that function walks through consecutive presets: preset for bank 0 prog 0 preset for bank 0 prog 1 preset for bank 0 prog 2 . . . preset for bank 0 prog 128 follow by presets for any additional instrument bank(s), and drum bank 128. This lookup is used for every prog_change. That's a simple and straigh forward way to implement the system using linear link-list, but can be very inefficient for look up time. Best regards, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
> I'm used to the following behavior when using MIDI on a > Creative card: > when I select an instrument not present, such as bank 8 > program 20, the > MIDI track will sound using bank 0 program 20 instead. > This seems like > a simple and logical way to deal with missing patches, and > is what I've > come to expect when working with MIDI. > > -~Chris Chris, Do you know of a way to query loaded instrument or combination of which soundfont+bank+patch number for the midi channels for Creative cards on Linux? >From time to time I want to try overriding some instruments so I load up >multiple soundfonts with FS (which qsynth shows), or on the Creative SB 5.1 >Live (which I don't know how to query). Thanks, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
Hi Josh, Thinking some more about hardware and software designs, I believe the safest thing to do when encounter an invalid request is to ignore it, not blindly follow the request/instruction that will cause the system to misbehave. I think FS misbehaves in this case, although it is just my opinion. You and others may think differently, and I respect that. For example, hardware keyboard or sound modules that has only one sound bank (#0) will ignore requests to use soundbank 15. The keypad selection of prog_number may let me type 834, but if there is no such prog_number, it won't allow that selection. User login would not be allowed if an invalid password is entered. For database, a request for adding a tabble, or even just a row would not be allowed if that database user doesn't have sufficient permission. My take for midi rendering is that I would rather keep whatever instrument already loaded in each channel than dropping the instrument from that channel. For a more lively example, let's say a band of 4 players trying to play a classical symphony record on vinyl that was written for 50 players using 20 instruments but only 4-10 instruments at any given time, the band may not have all the instruments available, but they can play their specialized instruments well enough to replace the viola with bass guitar, the flute with violin, drum and bass with keyboard ballroom (modern) rhythm instead of the original symphony with varying pace and tempo at times... Rather than saying, I don't have a viola or a flute, just butcher that section and wait for the the part with my instrument, which is what FS does right now. Best regards, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
> Hi Jimmy, > > Just keeping the already selected instrument when an > invalid selection > is received seems strange to me. Do you think that would > create the > desired effect in most MIDI files? It is a case of the > MIDI file > expecting an instrument to be present, which is not, right? > I'm not > convinced that just keeping the previous instrument > selection is any > better than trying to be a little smarter about it, > depending on the > mode (GM, GS, XG, etc). If a SoundFont was loaded, which > supported all > the instruments of the playing MIDI file, then there would > be no issue. > > Best regards, > Josh Hi Josh, Sure, you decide what's best to implement, when you have a chance that is. I only wish that assume that when I load up several soundfonts, with at least one complete GM soundfont, in any order, that FS won't skip out on any XG sound selection -- like prog_change channel 5 bank 15231 prog_numb 43. Since GM only assure bank 0 is available and complete. Softsynths, and soundcards also allow multiple soundfonts to be loaded to override some instruments using bank_number and prog_numbers base on some soundfont loading order. Some of those soundfonts may not have complete set of GM instruments. >From what I know of XG, and XG keyboards, those may have sound banks and drum >kits that you and I don't have. Basically, they are hardware sound modules. Soundcards with midi, and/or XG supports are PC emulation of those hardware sound modules. FS is just software emulation of such. And I haven't seen a hardware sound module skips any midi sound channels the way FS does. I have played XG sequences onto a Casio keyboard, non-XG of course, and they do sound something, not exactly as it may sound on a Yamaha XG keyboard, but it won't skip out on any sound at all, probably just use corresponding prog_number of the complete GM soundbank it has. Similar result with a PCI SB 5.1 Live! soundcard if I have a GM soundfont loaded -- I haven't tried with just a non-GM single-instrument soundfont. I am fairly certain that most XG sound modules (including electronic keyboards) have soundbank 0 that has a complete GM set of instruments. All other soundbanks (non-0) may be virtual pointer to instruments in soundband 0 with some or all instruments tweaked with different effects -- similar to synthesizer keyboards that allow custom sound editing. I guess that's the case, because many older XG keyboard specs I have seen showed only a few megabytes of sound samples. Even Tyros, Tyros 2, and Tyros 3 (top of the line arranger keyboards of its time) have only a few dozen megabytes of sound samples. Many of those XG arranger keyboards were implemented on a few "sound engines". Even with the same "sound engine" (hardware soundchip, number of effect processors, sound samples), I believe those XG keyboards have different number of soundbanks and different soundbank numbering schemes (but same GM prog_numbering) over the years. The only fairly certain thing I know about them is that people can record midi sequences from those keyboards, or copy style files for those keyboards. When playing back those midi sequences, or styles on a different XG keyboard models they will sound differently, even badly, because of different sound engines and soundbank numbering schemes, but I don't think any of the sounds are skipped, or ignored. Again, I can't recall where I read it, but I believe that the XG prog_number mirrors GM scheme in most cases. If you insist, I can try to locate that info. Just that XG uses many more sound banks, and the more expensive the hardware, the better sound sammples and sound engine they have. I think XG, and XG-Lite are examples of pricing the market. Best regards, Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
Hi Josh, I do agree that the appropriate instrument should be used and your approach is fine if FS has one soundfont loaded and it is GM. >From time to time I try to load several soundfonts to override some >instruments. Each soundfont has its own bank 0. FS allows several soundfonts >to be loaded, in any order, so bank 0 (of which loaded soundfonts???) of a >non-GM soundfont may not have 128 instruments and may not help in this case. One example is a bit of a stretch. Let's say I want to test a special soundfont that has only 2-3 instruments. I can try to load all channels with piano. Playing some midi to try out those non-piano instruments. So when the midi selected other instruments that my soundfont doesn't have, it should keep the already loaded piano. This way, I can hear and have a feel for the instrument I'm testing along with piano and still hear the full song or rhythm, or example. Of course I could substitute the piano with silence-instrument for such test, too. I suggest you implement your approach anyway, with that last option as a last resort. Only because I think I can try loading soundfonts in any orders on a PCI SB 5.1 Live! and it doesn't have any muted-channel problem I currently have with FS. Best regards, Jimmy --- On Wed, 1/28/09, Josh Green wrote: > From: Josh Green > Subject: Re: [fluid-dev] invalid instrument/drum selection > To: wg20...@yahoo.com > Cc: fluid-dev@nongnu.org > Date: Wednesday, January 28, 2009, 10:18 AM > Hi Jimmy, > > Just keeping the already selected instrument when an > invalid selection > is received seems strange to me. Do you think that would > create the > desired effect in most MIDI files? It is a case of the > MIDI file > expecting an instrument to be present, which is not, right? > I'm not > convinced that just keeping the previous instrument > selection is any > better than trying to be a little smarter about it, > depending on the > mode (GM, GS, XG, etc). If a SoundFont was loaded, which > supported all > the instruments of the playing MIDI file, then there would > be no issue. > > Best regards, > Josh ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
Hi Josh, Also, I dont know much about XG, only bit and pieces I can find on the web. I would love to get to some of the XG docs that were available a while back. I don't know any real info about GS, since I haven't done much searching for GS info. Since I play around with some Yamaha arranger keyboards for rythm/styles, I did try to see how to get XG stuff to work with GM soundfonts on Linux. I found AnotherXG soundfont, but of course, it's not complete. On Windows, I think VanBasco Midi Player seems to play everything. Although I don't use Windows anymore if I can help it. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
Hi Josh, If bank 0 has a full GM soundfont, then what you said should work. In an ideal situation, since FS allows loading multiple soundfonts in any order, I think a search for all soundfonts and all soundbanks of each soundfont for the first available prognum for this substitution scenario. However, I do know this could potentially slows FS down, I think this mapping of 128 "fall-back" instruments could be done once, after all soundfonts have been loaded, and cached for performance reasons. Of course, if one of these 128 fall-back instruments doesn't exist, then keep the currently loaded instrument on that channel. My suggested "if-statement" only keeps the currently loaded instrument. Whatever you did last year did solve the drum portion already, for me at least. Somehow that also did seem to take care of invalid program change for those 6 or so midi test files of the time. I only notice the problem with this one midi file because several of the instruments did not sound, and one instrument is panned off-center so it sounded odd, and I took a closer look. Best regards, Jimmy --- On Tue, 1/27/09, Josh Green wrote: > From: Josh Green > Subject: Re: [fluid-dev] invalid instrument/drum selection > To: wg20...@yahoo.com > Cc: fluid-dev@nongnu.org > Date: Tuesday, January 27, 2009, 5:30 PM > Hello Jimmy, > > I remember discussing this issue way back when, but kind of > left it for > later, since I wasn't really sure what the best > solution was. I should > probably read over the older thread, since I think I did > have some good > ideas of how to resolve it then (something about > determining whether the > MIDI file is expecting a GM, GS or XG MIDI device). > > In summary and to check my understanding.. > > MIDI file selects an instrument in an alternative > bank/program, > expecting a variation on an instrument. The loaded > SoundFont doesn't > have the particular bank/program combination. Currently > FluidSynth > mutes the channel. What you are proposing is to just have > it continue > using the previously selected instrument. > > Personally I think FluidSynth should listen for MIDI events > indicating > GM, GS or XG mode and also have the ability to override the > mode > manually. When in GS or XG mode, it could fall back to > bank 0 same > program #, if an instrument is not found. Does that sound > adequate? > Josh ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection
Hi Josh,
Again, the test midi is:
www.sternton.com/midi/xgmidi/orion_xg.mid
May I suggest a change in
src/fluid_synty.c: fluid_synth_program_change()
changing the two lines near the end from:
fluid_channel_set_sfontnum(channel, sfont_id);
fluid_channel_set_preset(channel, preset);
put an extra check that "preset" is not NULL first, to become:
if ( preset ) {
fluid_channel_set_sfontnum(channel, sfont_id);
fluid_channel_set_preset(channel, preset);
}
It would take care of the case when the preset is NULL, which is the case when
the loaded soundfonts doesn't have the prognum.
>From what I understand in XG sounds, the same prognum for different soundbanks
>are the same type of instrument. In the simplest case, it can simply be same
>instrument with different effects.
The suggested change doesn't guarrantee the same type of instrument, just keep
the already loaded instrument in that channel. Currently it sets the channel
to point to invalid, non-existing instrument.
Preferably, FS should try to find any soundbank with that prognum and use that
instrument instead. Maybe you can decide what best to do here.
Thanks,
Jimmy
___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] New development
> Date: Mon, 26 Jan 2009 15:25:13 -0500 > From: Ebrahim Mayat > > ...and while we are on the topic of new development...one > thing that has > been on my mind for a while is the subject of effects > plug-ins. For the > last few releases, I have chosen not to add the option of > LADSPA for the > simple reason that this often causes spontaneous crashes > particularly > when running qsynth. > > Since lv2 is the new alternative to LADSPA > > <http://ll-plugins.nongnu.org> > > I think that it would be a good idea to consider including > lv2 as a > feature that could be coded into the new branch. > > Such considerations would probably affect future planning. > Ebrahim, I think the crashes might be because many places in FS, variables are accessed directly and chained structure.substructure.variable are set and accessed without verifying validity of such data structure, or variable values. I think the original code cheated this way for speed-shake. Which might be a valid trade-off at the time. But it is mighty hard trying to track down spontaneous crashes. So I think LV2 support might be good thing to look forward to if someone can add that, it doesn't guarrantee anything regarding spontaneous crashes. I have seen one or two midi's that plays extra fast tempo that causes FS to crash, not sure if I have the time to track it down for the time being to even report it. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] New development
> Date: Mon, 26 Jan 2009 01:47:12 +0100 > From: Bernat Arlandis i Ma?? > > > Although it's mainly about whatever we can agree that > is good for the > development of the project, I have some generic ideas that > I think would > work. These are modularization, decoupling the API from the > internals, > and also introducing the glib and other dependencies that > would ease work. > > Specifically, on the modularization aspect I'd like to > break FS down in > several libraries that could build separately if needed. > This libraries > might be, guessing a bit: fluid-synth (the synthesis > engine), > fluid-soundfont (sound font loader), fluid-midi (midi > playing > capabilities incl. midi drivers), fluid-midir (midi > routing), > fluid-audio (audio conversion utilities and output drivers, > maybe LADSPA > too), fluid-ctrl (shell and server). > > Some of these components could grow and become independent > projects, in > particular I think midi routing could become a general > library being > able to read routing rules from a XML file and with a front > end for > editing these files. Some other components might just > disappear if > there's some external one that can do the same. > > Being able to break it down and build it like this would be > a good > modularization test. It would also help 3rd party > developers taking just > what they need and connect all the parts in more flexible > ways than is > possible now. > > In some way, the code has already been developed with this > goals in > mind, so we're not that far. It's really difficult > to fully reach these > goals in one try, or even two, but we're already > somewhat close. Bernat, I think those are good ideas. Keep in mind I don't do any work for FS at all, except running into a few problem here and there. While people want backward compatibility, I can see that FS code is not that easy to change. So a new version with new API would be just as well. Allow me to also suggest that while you do code decoupling, internal variable changes should verify that it is valid before allowing the changes. This is best funneling variable changes in a common function and call it from other places. I have seen many places in FS code that assigns variables blindly, i.e. midi program change, soundfont bank change that causes invalid instrument selection and FS messed up that midi channel, and that channel is silenced. Jimmy ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] invalid instrument/drum selection problem
Hi Josh,
Oops, my bad on the source code path mentioned in the last email. For this
particlular song
www.sternton.com/midi/xgmidi/orion_xg.mid
the problem includes invocation of fluid_synth_program_change() for unavailable
or invalid "prognum" on channels 2, 3, 4 (counting from 0) and maybe a few
other channels, too.
I now track it down to the function.
src/fluid_synty.c: fluid_synth_program_change()
at:
>>>>>
} else {
preset = fluid_synth_find_preset(synth, banknum, prognum);
}
sfont_id = preset? fluid_sfont_get_id(preset->sfont) : 0;
fluid_channel_set_sfontnum(channel, sfont_id);
fluid_channel_set_preset(channel, preset);
return FLUID_OK;
}
FLUID_LOG(FLUID_ERR, "Index out of range (chan=%d, prog=%d)", chan, prognum);
return FLUID_FAILED;
}
<<<<<
And I believe when the "preset" variable above is NULL, the channel got set to
a NULL-preset.
Jimmy
--- On Mon, 1/26/09, jimmy wrote:
> From: jimmy
> Subject: Re: [fluid-dev] invalid instrument/drum selection problem
> To: "Josh Green"
> Cc: fluid-dev@nongnu.org
> Date: Monday, January 26, 2009, 7:05 AM
> Hi Josh,
>
> I am replying to an old message so you can hunt down the
> original messages with the same email subject line if it may
> help refresh your memory. This time, similar problem,
> different midi song.
>
> Let me refresh your memory of the scenario. The result was
> that even if an invalid bank_num, or prog_num was selected,
> fluidsynth keeps the existing instrument already in that
> channel. Previously, fluidsynth assigned invalid bank_num,
> or prog_num to the channel anyway which causes the channel
> to point to non-existing instrument so the whole channel was
> muted. From what I understand, hardware soundcards would
> keep existing instruments and won't allow invalid
> selection of bank_num, or prog_num to mute the channel, it
> just keep playing the already loaded instrument.
>
> I think the ticket number was:
>
>http://fluidsynth.resonance.org/trac/ticket/8
>
> The midi files to test were:
>
> www.geocities.com/TheTropics/Cabana/4967/inicial.html
> www.geocities.com/TheTropics/Cabana/4967/Amor_Eterno.mid
> www.geocities.com/TheTropics/Cabana/4967/Ansiedad.mid
> www.geocities.com/TheTropics/Cabana/4967/allanera.mid
> www.geocities.com/TheTropics/Cabana/4967/Bailamos.mid
> www.geocities.com/TheTropics/Cabana/4967/bamboleo.mid
> www.geocities.com/TheTropics/Cabana/4967/besame.mid
> www.geocities.com/TheTropics/Cabana/4967/caballo.mid
>
>
> You did fix up fluidsynth using those midi files as test
> cases.
>
> Recently, I try listening to some at
> www.sternton.com/midi/xgmidi/ . I try to play this midi
> file:
>
>www.sternton.com/midi/xgmidi/orion_xg.mid
>
> For what it's worth, Debian timidity 2.13.2-20 plays it
> just fine, so does a SoundBlaster 5.1 Live! PCI card.
>
> However, I try with both Debian fluidsynth 1.0.8-1.1, and
> fluidsynth.svn.20090108. What I seem to get is that the
> drum channel still plays drum just fine, but a few channels
> seem to load up invalid instrument, and causes the channel
> to turn mute.
>
> So far, I tracked it down to the following code in
> src/fluid_synth.c:
>
> >>>
>
> int fluid_synth_program_select( . . .)
>
> . . .
>
> preset = fluid_synth_get_preset(synth, sfont_id,
> bank_num, preset_num);
> if (preset == NULL) {
> FLUID_LOG(FLUID_ERR,
>"There is no preset with bank number %d and
> preset number %d in SoundFont %d",
>bank_num, preset_num, sfont_id);
> return FLUID_FAILED;
> }
>
> <<<
>
> I believe the "preset" variable should have been
> set to NULL because the bank_num is not available for the
> loaded soundfonts, but fluid_synth_get_preset() returns a
> non-NULL value. So the "preset" would be used a
> few statements below that to select the invalid instrument.
>
> Can you take a look when you have a chance? This is low
> priority, casual listening for me. Let me know if you can
> reproduce the problem, or if I could be of any further help.
> Thanks,
>
> Jimmy
>
>
>
> --- On Wed, 1/9/08, jimmy wrote:
>
> > From: jimmy
> > Subject: Re: [fluid-dev] invalid instrument/drum
> selection problem
> > To: "Josh Green"
> > Cc: fluid-dev@nongnu.org
> > Date: Wednesday, January 9, 2008, 10:50 AM
> > --- Josh Green wrote:
> >
> > > Hello Jimmy,
> > >
> > > On Mon, 2008-01-07 at 16:15 -0800, jimmy wrote:
> > > > For quick test, I use Kmid to play th
Re: [fluid-dev] invalid instrument/drum selection problem
Hi Josh,
I am replying to an old message so you can hunt down the original messages with
the same email subject line if it may help refresh your memory. This time,
similar problem, different midi song.
Let me refresh your memory of the scenario. The result was that even if an
invalid bank_num, or prog_num was selected, fluidsynth keeps the existing
instrument already in that channel. Previously, fluidsynth assigned invalid
bank_num, or prog_num to the channel anyway which causes the channel to point
to non-existing instrument so the whole channel was muted. From what I
understand, hardware soundcards would keep existing instruments and won't allow
invalid selection of bank_num, or prog_num to mute the channel, it just keep
playing the already loaded instrument.
I think the ticket number was:
http://fluidsynth.resonance.org/trac/ticket/8
The midi files to test were:
www.geocities.com/TheTropics/Cabana/4967/inicial.html
www.geocities.com/TheTropics/Cabana/4967/Amor_Eterno.mid
www.geocities.com/TheTropics/Cabana/4967/Ansiedad.mid
www.geocities.com/TheTropics/Cabana/4967/allanera.mid
www.geocities.com/TheTropics/Cabana/4967/Bailamos.mid
www.geocities.com/TheTropics/Cabana/4967/bamboleo.mid
www.geocities.com/TheTropics/Cabana/4967/besame.mid
www.geocities.com/TheTropics/Cabana/4967/caballo.mid
You did fix up fluidsynth using those midi files as test cases.
Recently, I try listening to some at www.sternton.com/midi/xgmidi/ . I try to
play this midi file:
www.sternton.com/midi/xgmidi/orion_xg.mid
For what it's worth, Debian timidity 2.13.2-20 plays it just fine, so does a
SoundBlaster 5.1 Live! PCI card.
However, I try with both Debian fluidsynth 1.0.8-1.1, and
fluidsynth.svn.20090108. What I seem to get is that the drum channel still
plays drum just fine, but a few channels seem to load up invalid instrument,
and causes the channel to turn mute.
So far, I tracked it down to the following code in src/fluid_synth.c:
>>>
int fluid_synth_program_select( . . .)
. . .
preset = fluid_synth_get_preset(synth, sfont_id, bank_num, preset_num);
if (preset == NULL) {
FLUID_LOG(FLUID_ERR,
"There is no preset with bank number %d and preset number %d in
SoundFont %d",
bank_num, preset_num, sfont_id);
return FLUID_FAILED;
}
<<<
I believe the "preset" variable should have been set to NULL because the
bank_num is not available for the loaded soundfonts, but
fluid_synth_get_preset() returns a non-NULL value. So the "preset" would be
used a few statements below that to select the invalid instrument.
Can you take a look when you have a chance? This is low priority, casual
listening for me. Let me know if you can reproduce the problem, or if I could
be of any further help. Thanks,
Jimmy
--- On Wed, 1/9/08, jimmy wrote:
> From: jimmy
> Subject: Re: [fluid-dev] invalid instrument/drum selection problem
> To: "Josh Green"
> Cc: fluid-dev@nongnu.org
> Date: Wednesday, January 9, 2008, 10:50 AM
> --- Josh Green wrote:
>
> > Hello Jimmy,
> >
> > On Mon, 2008-01-07 at 16:15 -0800, jimmy wrote:
> > > For quick test, I use Kmid to play the MIDI
> files,
> > > connect to Qsynth/FluidSynth wiht QJackctl. I
> > drag
> > > the MIDI file to Kmid and it interrupts the
> > existing
> > > playing, starting to play the new file. So
> > probably
> > > Fluidsynth doesn't know much (or just
> guessing)
> > about
> > > a new file being played.
> > >
> > > But how about using FluidSynth as a sound module
> > for
> > > praticing or live playing? If a
> > song/accompaniment
> > > ends, I may still want to have my preloaded
> > > instruments exactly the way they are, so I can
> > > continue on to the next song and not have to
> > reselect
> > > all the instruments again.
> > >
> >
> > If MIDI files were played directly with FluidSynth,
> > then it would have a
> > concept of when a new one started and could reset
> > accordingly. In the
> > case where the MIDI sequencer of FluidSynth isn't
> > being used, then it
> > could still listen for SYSEX messages requesting GM,
> > GS or other modes.
> > Not all MIDI files have them, but I have seen quite
> > a few of them that
> > do.
>
> OK, right now I don't often play a midi file by
> fluidsynth directly. I do use Kmid, PyKaraoke, or
> even some Timidity GUI as Jack client to FluidSynth.
> Have a separate FluidSynth instance for praticing my
> keyboarding. Recently found Stygmorgan as a software
> arranger (for accompaniment). I don't know how well
> each of those apps filter out, or reset in between
>
