On Tue, 23 Feb 2010, Chuck Cochems wrote: > Current method is absolutely horrible. It ONLY seems to load bank 0 from > the soundfont, and ignore all others, at least in the standalone player > I tried.
I'll agree that TiMidity has issues with sf2 instrument loading.... But, given the history of the program, I don't think it is too horrible. TiMidity started out around 1995 or so using GUS .pat files from the Gravis Ultrasound. The GUS used a gravis.cfg file to map individual instrument files to each midi instrument number. There were no "banks" that you could just swap in and out, it was all specified in gory detail in the gravis.cfg file. TiMidity worked the same way, since the GUS was the standard consumer grade midi card at the time. SF2 support was added much later on top of the PAT support. I look at TiMidity more as a GUS .pat file player that includes some SF2 support. Although just specifying "soundfont whatevername.sf2" in a .cfg file doesn't seem to handle the non-0 banks properly, it *IS* possible to get TiMidity to use all the drumsets and SFX banks correctly. It's just painful the way I have done it on my system. I don't know if there is a better way or not, I've always just used .pat files, I didn't really get into SF2 until I started merging FreePats with FluidR3 over the weekend via config files. You can use sf2 files in the gravis.cfg and various other .cfg files similar to how you would use .pat files. You can specify each individual bank and each individual instrument within each bank, like the following: # loads instruments 49-51 from sf2 bank 0 into timidity bank 0 bank 0 49 %font "FluidR3_GM.sf2" 0 49 # String Ensemble 2 Slow 50 %font "FluidR3_GM.sf2" 0 50 # Synth Strings 1 51 %font "FluidR3_GM.sf2" 0 51 # Synth Strings 2 # loads drums 29-30 from sf2 bank drumset 0 into timidity drumset 0 # drumset loading from sf2 files is denoted with an extra 128 before the # bank/instrument drumset 0 028 %font "FluidR3_GM.sf2" 128 0 28 pan=-21 # Slap 029 %font "FluidR3_GM.sf2" 128 0 29 pan=-19 # Scratch 1 push 030 %font "FluidR3_GM.sf2" 128 0 30 pan=-19 # Scratch 2 pull You can define other banks and drumsets as well, like GS drumsets 8, 16, 24, 25, 26, 32, 40, 48, 49, 50, etc.. You can define GS SFX drumsets 56 and 127 too. Proper XG bank support is much more complicated, but is also possible to configure given the right .cfg file syntax. Yes, it's a lot of work to specify a line for every single bank and instrument (however, extra banks only need instruments that differ from bank 0, they will automatically fall back to bank 0 if missing). But, if they are already in a single sf2 file, it's really easy to just copy/paste a bunch of lines then go down the list and change the instrument numbers one at a time to specify each instrument separately. It's a little tedious... but doable. Once you have a .cfg file for the bank you want, you can then edit your timidity.cfg file to source that .cfg file, or a different one if you want to use a different instrument configuration. This would sort of work as a "bank change". I agree that the SF2 support isn't so great.... SF2 bank loading should be fixed to handle non-0 banks more easily, so that all it takes is a single "soundfont" line to correctly load the entire set of banks. Loading behavior also needs to be fixed so that instruments loaded later properly overwrite instruments loaded earlier (including PAT files). I think most of the problems stem from the behavior of the "soundfont" directive. SF2 loading seems to behave as expected when used on a per-instrument basis with the %font directive. I suspect the code that handles the soundfont directive might be the first place to look to see where the problems might be? Thank you for bringing this problem to the developers' attention. > Also the engine should support all awe32 sysex and NRPN Mainly tis means > GS sysex for reverb and chorus, and nrpn to control the LFOs and the > resonant filter. TiMidity actually DOES support most of the GS and XG SYSEX events, including chorus and reverb levels on a per-channel basis. The chorus and reverb might not sound as good as you'd like, but the support IS there, it's just the chorus and reverb engines that need some work. You may have to enable chorus and reverb support in the preferences, I'm not sure if they default to ON or not. Special audio effects, such as reverb, chorus, variation, etc. are probably the most difficult thing to add to a midi player. Once the special effects engines are written, adding the support for the SYSEX events is easy. Since special effects are hard to implement, it just hasn't happened, or if it has, the quality may not be as good as what you've come to expect from commercial solutions. Hey, it's free software written by people in their free time as a hobby, don't be surprised if it doesn't have all the features of a Roland or Yamaha sound module.... I don't think TiMidity has any linear frequency oscillators at all. Nor do most other softsynths, or even consumer level hardware for that matter. Since pretty much nothing else currently supports this either, I don't see much of a problem with it being missing.... > You want to play some final fantasy 7 awe midi files. :) I used to have a Yamaha SW60XG ISA card. It was awesome. I bought FF7 for PC and didn't need the included Yamaha S-YXG50 softsynth (for Win95/98/ME), since I already had the real hardware that was better. FF7 sounded great. GS and XG midi sounded great. I added XG support to TiMidity and it sounded ... not too bad once all the instrument changing SYSEX events were supported and configured. I can confidently say that, apart from special audio effects such as LFO and Variation, TiMidity does a good job of supporting GS and XG instruments and instrument changing SYSEX events, enough to play back midi that sound reasonable, as opposed to playing with all the wrong instruments due to missing the SYSEX instrument and drumset change events. TiMidity sounds WAY better than my Audigy ever did, since it didn't support GS or XG at all (at least not that I could tell). It couldn't even handle 2 drum channels, much less SFX drum channels. TiMidity's support is still more GS and XG support than almost every other solution out there. If you want near-perfect GS and XG support, your best bet it to aquire an old copy of Yamaha's S-YXG50 softsynth if you are running XP. The latest version you could get from Yamaha was 4.23.14, which was a WDM driver that was supposed to work under XP (but I could never get it to work). If you are running XP, you can download the Microsoft Windows Update 1403848.cab, which includes an even newer version, WITH the 4 meg ROM instead of the standard 2 meg ROM. Extract the CAB file with WinZip or something like that, then Add New Hardware the driver. Since it doesn't have an installer to create the registry entries, you'll need to add them yourself if you didn't install 4.23.14 from Yamaha beforehand (and use Update Driver under Device Manager). See the following link for details: http://www.wiki-mirror.us/wiki/Software_synthesizer It even works as an MPU-401 device under DosBox, so that great DOS midi players such as MegaMid v1.66 work perfectly :) Lucas Arts adventure games also sound very nice with it using ScummVM. I am currently running it, and I can say that it sounds almost as good as my SW60XG did on all my XG midi. It has a few issues with the volume being set too high internally so that it over-amplifies outside the 16-bit sample range and pops/crackles every now and then with really effects-loaded midi, but overall it sounds pretty good. WAY WAY better than the default Microsoft GS softsynth. If you are running Vista, there really isn't much in the way of software GS or XG support. Yamaha is currently selling software called MidRadio, but only in Japanese, and apparently only as a file player. It uses a crippled softsynth that only supports XG-Lite (no variation effects), but has a larger (11 meg) instrument bank than the S-YXG50 (4 meg, same as the SW60XG). There is a hack to turn the demo version into a VSTi plugin that you can be used with midi software that supports VSTi plugins, something even the full commercial version can't do. I found some full instructions over the weekend for how to do that, but I can't find the link at the moment. I'm running XP, so the S-YXG50 is good enough for me for now, especially since it works as a full blown Windows MIDI driver. > Notably no card that uses .sf2 seems to support portmenteau controller, > even though GS and XG standard both require it's support. If it isn't made by Roland or Yamaha, it probably doesn't have much of any GS or XG support at all :( I can't blame Creative or other consumer sound card makers, there just isn't much demand for it. I *can* however blame Roland and Yamaha. Damn them for discontinuing their consumer-level product lines *AND* their Windows software synthesizers. > If you wish to make a GS compliant timdity++, you must include this > controller. In theory, it should be possible to implement it in TiMidity, especially since it already implements portamento in MOD files. But the MOD engine is completely separate and just emits a series of internal pitch bend events to create the portamento effect, which is a bit of a hack. I think the best solution would be to implement something similar to how instrument envelopes are currently implemented. Add a voice variable that detunes the pitch by X amount. Add a separate variable that tells it how much to increment the first variable per time slice. Add a third variable that tells it at which point to stop (once the detune value has been reached). When a portamento event is issued, calculate the increment rate and endpoint for the detuning, then pass the modified detuned frequency to the resampling functions that are already used to change sample pitch. Three new variables to add to the voice data structure, a new function to write to calculate/set them on a portamento event, some extra code to write to increment the detuning value each timeslice. Cached pre-resampled notes would also need to be disabled for notes affected by a portamento. I think I mostly know which functions and data structure would need to be edited. This sounds quite doable to me. But, I don't have time for it at the moment, and I don't know about other developers. Thank you for bringing this to our attention, though. I wasn't aware that there was much need or demand for portamento support. I'd never seen it used in a midi file before. -Eric ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Timidity-talk mailing list Timidity-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/timidity-talk
