- Gravis ultrasound soundfont driver#
- Gravis ultrasound soundfont Patch#
- Gravis ultrasound soundfont professional#
SGM is still my favorite, a nice balance of quality instruments and size. So will SGM v2.01 in your opinion provide me with the best "bang for the buck" by itself keeping in mind its file size (~200MB)?
Gravis ultrasound soundfont professional#
I don't need 4.5GB of samples, 'cos I'm neither a professional musician, nor do I wish to download such huge files just for MIDI support. Quote from: James2000 on 07:48:59 Also, SGM v2.01 was recommended to me above as well. The option to do so is located in the Advanced section of the Preferences dialog, under Playback. MUNT will fail gracefully if it cannot locate its relevant data files, although it won't emit any errors to the console unless you enable the debugging information. The ROM images are fairly easy to locate, although Roland is still in business, so I can't exactly distribute them freely. I included it mainly for the MT-32 support, but the simulated GM mode is good for a throwback to days of old.
Gravis ultrasound soundfont driver#
It is enabled unconditionally for any MIDI file which contains MT-32 SysEx commands, or if you select it in the driver list, it also enables for non-MT-32 files, in which case a General MIDI compatibility instrument bank is loaded. It requires either MT-32 control and PCM ROMs, or CM-32L ROMs. It uses very little memory in practice, since most MIDI files don't utilize every single instrument, or even every single key range in each instrument that they do use.Īlso, Gravis UltraSound PAT banks are much simpler and therefore easier to support, but SoundFont banks support much more elaborate effects, such as more than 16 samples per instrument (I think that's the limit of PAT), stereo samples, multi-layered instruments, multiple velocity ranges, pitch modulation, resonant filters, the list goes on.Īs for MUNT, that is the open source MT-32 emulator.
Gravis ultrasound soundfont Patch#
That way, you can get away with setups like mine, namely the entire 4.5GB worth of Colossus.SF2's 44.1KHz patch set, with the drum kit bank left out and SGM v2.01 loaded at the top of the sflist just to pull in any missing instruments and the drum kits. I also amended it with my own dynamic sample loading system, so each instance of FluidSynth loads every sample as the MIDI file plays them, rather than loading the entire banks at startup. I am using a newer version of FluidSynth than the release version, namely the SubVersion trunk. The crash on missing SoundFont banks was not due to improper error handling, but due to a failure to check if a file handle was NULL before closing it in the SoundFont loader destructor function. I fixed the typo, and also error reporting if a sflist file fails to open outright. So in your next version, along with fixing that spelling (these things kinda irritate me! ) and also updating FluidSynth if it isn't the latest, can you please add a "file existence" check? In case the SF2 or SFLIST doesn't exist (it could even have been loaded from a removable drive), then maybe foo_midi can revert back to Emu de MIDI with a warning message? Also, I haven't used MUNT yet (no idea what it is), but while you're at it, you can also add a similar check for MUNT's data path disappearing, if such a check isn't already there. Started foobar, tried to play a MIDI and boom! My first foobar crash. I moved the file to another folder, but forgot to change the path in foo_midi. But I had selected an SF2 from my Downloads folder. Thanks, although 200+ Does foo_midi support BUG REPORT: Selecting FluidSynth and any SF2 or SFLIST works fine.