#8731 closed patch
Add TiMidity++ MIDI server support
| Reported by: | SF/amdmi3 | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Audio: MT32 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
TiMidity++ can work as MIDI server listening on TCP socket, and can thus provide pretty good music quality on many platforms. Especially useful where there's no native sequencer at all (FreeBSD, for example) - timidity provides much better quality than Adlib emulation.
Ticket imported from: #1815526. Ticket imported from: patches/836.
Attachments (1)
Change History (14)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Since there is some overlapp in functionality between this and the FluidSynth music driver, it would be interesting to compare the two. (I'm not arguing for or against the patch here.)
I know that TiMidity traditionally used "GUS patches" for its instruments, while FluidSynth uses a SoundFont. (TiMidity++ can use either.) From what I understand, both have their advantages and disadvantages. I imagine TiMidity (with GUS patches) needs less CPU than FluidSynth, for one thing.
I know FluidSynth has problems with the very beginning of Day of the Tentacle. I don't know whether or not TiMidity has any such problems. I probably should report that as a bug to the FluidSynth developers (as I recall it, the same bug happens when hooking up FluidSynth through ALSA, so I don't think it's a bug on our side), but I never bothered subscribing to their mailing list.
FluidSynth offers a programming library, so it doesn't have to be run as a server. I assume this might make it a more portable solution. On the other hand, I never did manage to get FluidSynth to compile under MinGW...
Any other thoughts?
comment:3 by , 17 years ago
I actually don't know much about MIDI synthesizers/soundfont stuff. It just happened that there weren't any quality MIDI support (except AdLib) in FreeBSD port of ScummVM, and an acquaintance of mine asked to help with adding TiMidity support, so I spent some time and came out with this patch. Then I discovered that there was FluidSynth support, and also modified ScummVM port so FluidSynth could be enabled (this was committed yesterday), see http://www.freshports.org/games/scummvm.
Thus, I can't actually compare quality and features of FluidSynth and TiMidity, but I was told that TiMidity is better, but it eats much more CPU than FluidSynth.
It's true that functionality of both MIDI synths overlap, but still they work differently and each has it's own advantages (I mean technical, i.e. not taking quality into account). I don't think TiMidity is less portable as FluidSynth, as the server can by run everywhere, and client-side socket code is pretty simple, so this should work everywhere ScummVM can be compiled on. If you say there are problems with FluidSynth in specific environments, TiMidity may be used instead (at least, it shouldn't have any problems with MinGW).
This all can be of course tested, and also I can ask a guy who made me write this patch more on quality differences.
comment:4 by , 17 years ago
| Owner: | set to |
|---|
comment:5 by , 17 years ago
"and client-side socket code is pretty simple, so this should work everywhere ScummVM can be compiled on. "
well, everywhere *sockets* exist, which is not everywhere, which makes this less portable :-)
Anyway, I think it would be a good idea to integerate this. But I wonder if it compiles e.g. on Windows, or on other ports. Maybe we have to deactive the code on non-UNIX systems via a corresponding #ifdef...
Kirben, does this patch compile (or even "work" in some meaningful way) on Windows?
comment:6 by , 17 years ago
> well, everywhere *sockets* exist, which is not everywhere, which makes this less portable :-)
Hmm, can't imagine a platform which runs scummvm, but lacks sockets :) If such platform exists, surely #ifdef, but as far as I remember, Windows supports POSIX enough for simple socket code (though I didn't try). Anyway, if it does not compile/work, I'll be happy to try to fix it.
comment:7 by , 17 years ago
The updated patch, doesn't compile under mingw, so making code optional would be best.
Windows doesn't have any support for POSIX style sockets, the network code would need to be re-written for Windows.
comment:8 by , 17 years ago
Actually there is POSIX socket support in Win32 (http://msdn2.microsoft.com/en-us/library/ms737550.aspx). You could try to add #define "winsock2.h"
But I'm not sure about other functions used like getenv(), and I lack any ability to compile this on Windows, so I guess #if defined (UNIX) is needed after all. Updated patch attached. File Added: scummvm-timidity.patch
comment:9 by , 17 years ago
Well, you may not be able to imagine them, but they exist: Nintendo DS, PalmOS, Playstation 2, Playstation Portable, and more.
comment:10 by , 17 years ago
A user has posted a tutorial on how to get Timidity working under Windows (without sockets, using the Windows MIDI music driver) here: http://forums.scummvm.org/viewtopic.php?t=4639
comment:11 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → closed |
comment:12 by , 17 years ago
Since the driver now is proteted by an #ifdef UNIX, I commited this. Thanks for the contribution!
comment:13 by , 6 years ago
| Component: | → Audio: MT32 |
|---|
A bit updated version: remove #ifdef(UNIX) in sound/mididrv.cpp (just forgot to remove it - timidity support should be available on all systems) and move timitidy to softsynths group, where it belongs better. File Added: scummvm-timidity.patch