 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
chronoboy
Into the past with a splash
Joined: 04 Jun 2010
Posts: 162
Location: Canada
|
 Posted: Sat Dec 04, 2010 10:22 pm Post subject: OHRRPGCE under Linux can only use freepats? |
 |
|
Why can OHRRPGCE under Linux only use FreePats for midi music output?
I downloaded some better quality soundfonts, and OHRRPGCE does not play any midi music if I tell Timidity to use these soundfonts.
As a test to see if it was the MIDI files or OHR, I opened up Wander.RPG in custom, exported the MID file for the title screen. I then used Timidity directly to play it using each soundfont, and it worked, and the music even sounded richer. In fact, playing the title screen in Timidity using freepats, it says that freepats is missing instruments to even play the title screen music. This is the reason why MIDI in OHR just sounds better under Windows, because FreePats is absolutely horrible quality compared to FluidSynth or even the 8MB General MIDI Soundfont from a AWE32 soundcard install CD.
Please provide me info on why OHR will not play midi using any other soundfont but FreePats, and if this is fixable somehow.
For the record it is possible to bypass timidity entirely under Linux and just connect to the ALSA midi port 128:0. If the soundcard does not support General midi, the Timidity server takes over this ALSA MIDI port. As soon as Timidity is installed on recent Linux distros, it auto-starts a Timidity server at system boot.
Thanks.
Using FreePats to play the title screen MIDI:
| Code: |
$ timidity title.mid
Playing title.mid
MIDI file: title.mid
Format: 1 Tracks: 7 Divisions: 192
All Rights Reservedt © 1998 by <Song Author Name>
Text: Generated by NoteWorthy Composer
Text: Unnamed-000
Track name: Unnamed-000
Instrument: Unnamed-000
Text: Unnamed-001
Track name: Unnamed-001
Instrument: Unnamed-001
Text: Unnamed-002
Track name: Unnamed-002
Instrument: Unnamed-002
Text: Unnamed-003
Track name: Unnamed-003
Instrument: Unnamed-003
Text: Unnamed-004
Track name: Unnamed-004
Instrument: Unnamed-004
Text: Unnamed-005
Track name: Unnamed-005
Instrument: Unnamed-005
No instrument mapped to tone bank 0, program 17 - this instrument will not be heard
No instrument mapped to tone bank 0, program 39 - this instrument will not be heard
No instrument mapped to tone bank 0, program 43 - this instrument will not be heard
No instrument mapped to tone bank 0, program 92 - this instrument will not be heard
No instrument mapped to tone bank 0, program 105 - this instrument will not be heard
|
UPDATE: Here is a copy of each MIDI file rendered into a OGG to show the difference in quality from FreePats to the Roland General Midi(included with windows):
http://c0018321.cdn1.cloudfiles.rackspacecloud.com/title-roland.ogg
http://c0018321.cdn1.cloudfiles.rackspacecloud.com/title-freepats.ogg
I'm only using the Wandering hamster title song as an example, as most of us have heard it at least once. The title screen isn't that far off from how it should sound, but other midi I have heard in both Windows and Linux's freepats from various RPG games does sound very off(it is very dependent on the instruments used). I cannot remember which one exactly, but one of the midi's included in the IMPORT folder sounds completely horrible under FreePats, where it sounds great under Roland's GM included with Windows. I'll go through the midi's in the import folder and upload a sample to show the differences.
UPDATE: Okay, here are the worst sounding MIDI's in the IMPORT folder when played using FreePats, that otherwise sound great using Rolands GM: Green.mid and Rozwell.mid
Green.mid doesn't even play under Timidity using FreePats, and sounds great using Roland's GM soundfont. It plays in Custom, but sounds absolutely horrible, makes you want to mute the music...
Rozwell.mid is missing 2 crucial instruments, and it sounds horrible in FreePats, but sounds like a dream under Roland's GM. Below is a sample of Rozwell both in FreePats and Roland's GM(which is used in Windows):
http://c0018321.cdn1.cloudfiles.rackspacecloud.com/Rozwell-freepats.ogg
http://c0018321.cdn1.cloudfiles.rackspacecloud.com/Rozwell-roland.ogg
_________________
Current project: Chronoboy Adventures
Website: http://www.chronoboy.com/ |
|
| Back to top |
|
 |
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Sun Dec 05, 2010 4:37 am Post subject: |
|
|
SDL_Mixer uses a forked and ancient version of TiMidity++, in fact back then it was called TiMidity. And even TiMidity++ hasn't had a new version released in six years!!
So yes, unfortunately SDL_Mixer does not support the same instrument bank formats: it only supports Gravis Ultrasound .pat files, and also it doesn't understand the same config file options as the timidity++ install on your machine either. And it might be configured to look for the config file in different locations as well.
However freepats is absolutely terrible, and you should be able to get much better SDL_Mixer-compatible instruments. I can't remember what I did last time I mucked around with it under Linux. I think James has said something about this a few times, you could search these forums. I believe that most Linux distributions package freepats because it's the worst package they can find or something.
Also, SDL_Mixer only supports playing MIDIs using the system interface on Mac OS X, Mac OS Classic, and Windows.
This is yet another reason I'm tempted to fork SDL_Mixer.
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Sun Dec 05, 2010 10:09 am Post subject: |
|
|
Yes, I did successfully get SDL_Mixer's embedded timidity to play with a better soundfont, but it was a real pain. I haven't tried to do it on my current computer.
I used to dreamwish that somebody would eventually add all the missing instruments to freepats, but I don't think that will happen now. It seems unmaintained. |
|
| Back to top |
|
|
chronoboy
Into the past with a splash
Joined: 04 Jun 2010
Posts: 162
Location: Canada
|
| Posted: Sun Dec 05, 2010 11:45 am Post subject: |
|
|
How does DOSBox connect to the ALSA Midi port? DOSBox is SDL based, and perhaps they have a workaround that works with SDL_mixer.
| Code: |
mpu401=intelligent
mididevice=default
midiconfig=128:0
|
This is what I use in my DOSBox config for example to use General MIDI in games.
Perhaps an Adlib emulation library would sound better than FreePats?
I'll take a quick look at the DOSBox source code for their mixer and see what they use or how they interface this MIDI port from ALSA. It may provide some ideas.
UPDATE: Well Dosbox does use SDL Audio, just not SDL_mixer, they wrote their own mixer... Which might give you ideas on how to build a custom mixer for the engine. In the source is can be found in: src/hardware/mixer.cpp
How many other projects use SDL_Mixer? Perhaps looking at those projects, may provide some insight, or even projects which completely replace it with their own implementation.
The code for connecting to the ALSA Midi port: src/gui/midi_alsa.h and src/gui/midi.cpp
I'll be more than happy to test out any proposed backends, if you plan on building a custom Mixer, or simply Extending the class of SDL_Mixer. I'll take a look at SDL_Mixer source code and see if it would be possible to sub-class it and add custom features such as better MIDI support.
UPDATE: Well, I have been rather busy in the last hour and have been downloading source code from many projects. prBoom for example, uses Timidity++ and SDL_Mixer. Although the prBoom source code is very confusing to navigate. I also downloaded the latest source for SDL_Mixer to see what was going on and why it only uses FreePats and emits silence if FreePats is not in the config file.
SDL_Mixer has an older version of Timidity built right into it, so rather than calling a linked timidity shared library, it just uses it's own embedded timidity(which is bad programming for the most part). Anyways, I browsed through the Timidity source in SDL_mixer, and it does read the Timidity config file, but only understands a subset of it's configuration. It does not understand the soundfont config option for example.
I then downloaded and installed the Timidity++ source code to see how complex it might be to integrate the new code into SDL_mixer. With a little work, I do believe it would be possible to make it work. Since Timidity unfortunately does not expose a nice juicy API, I will need to directly copy and paste the updated code from Timidity++ to Timidity in SDL_mixer. Let's just say, the first version may be rather sloppy in the timidity source directory. I will only copy over the MIDI relevant code, everything else seems fine for the moment. I am surprised how small the source trees for both SDL_mixer and Timidity are. Even prboom is very small, as well as DOSBox.
UPDATE: Well, I am at the last error that needs correcting before SDL_mixer successfully compiles(or so I think...). Since I copied all of Timidity++ into the SDL_mixer source tree and patched files as I went along, timidity.c still has it's main() function, which SDL_mixer does not need. So, the last order of business here, is to remove all the non-essential functions and make it SDL_mixer compatible. It's a shame that I need to operate on this file, as it includes all the configuration file reading functions and still that SDL_mixer does need. Hopefully, this won't give me too much trouble.
UPDATE: I decided to download the nightly of the OHRRPGCE source tree to see how music is done in the various backends... After reviewing music_native.bas, it looks very similar to how DOSBox sends MIDI commands the ALSA MIDI port. Would a ALSA backend be possible? As there is a native backend for Windows, which sends MIDI commands very similar to how DOSBox sends MIDI commands to ALSA.
The sub PlayBackThread in music_native.bas looks very similar to MPU401_WriteCommand and MPU401_WriteData in src/hardware/mpu401.cpp. The hex commands being sent are similar, if not the same commands.
appears to be the magic word in FreeBASIC to connect to the ALSA library. You will need to compose your own header file to use the exported API, as I have been reading on the FreeBASIC forums. This forum post is a good starting point:
http://www.freebasic.net/forum/viewtopic.php?p=26137
http://www.freebasic.net/forum/viewtopic.php?t=4004
I'll see if I can make a quick FreeBASIC program which uses the ALSA MIDI interface to play a MIDI file. If successful, I'll post the source code here for you guys. Hopefully this will inspire a Linux native music backend.
UPDATE: I am attempting to use SWIG to convert the ALSA library headers over to FreeBASIC format, but the person who uploaded the FB-compatible SWIG, only uploaded a Windows EXE version. He did provide a DIFF file, but no version number of SWIG?!?!?! So now I'm basically pulling out my hair downloading each and every version of SWIG and running PATCH against it. So far no luck, it all returns failed. Furthermore, the SWIG EXE will not run under Wine(I figure it's a CGYWIN binary), so I cannot figure out the version number by running the EXE. All I have to work with is the date the DIFFs were done, which was in 2004, and I already tried all the 2004 versions of SWIG. Some programmers just drive up the wall in what they do sometimes. I may just manually convert the ALSA headers and try my luck that way, it's really all I got to work with. SDL_mixer with the new Timidity just doesn't want to compile, and now SWIG is just a problem to work with. Manually doing the header might be my only solution at this point.
All I want is better sounding MIDI music in my RPGs, is that too much to ask for...
UPDATE: The midi commands are the same in music_native.bas and in DOSBox's midi_alsa.h
| Code: |
case &HB0 to &HBF 'controller
if curevent->data(0) = &H6F then 'rpg maker loop point
labels(0) = curevent
else
'shortMidi curevent->status,curevent->data(0),curevent->data(1)
BufferEvent curevent->status,CByte(curevent->data(0)),CByte(curevent->data(1))
end if
case &H80 to &H8F, &H90 to &H9F 'note on/off
BufferEvent curevent->status,curevent->data(0),curevent->data(1) * music_vol
case &HA0 to &HAF 'pressure
BufferEvent curevent->status,curevent->data(0),curevent->data(1) * music_vol
case &HC0 to &HCF 'program change
BufferEvent curevent->status,curevent->data(0),-1
case &HD0 to &HDF 'channel pressure
BufferEvent curevent->status,curevent->data(0),-1
case &HE0 to &HEF 'pitch bend
BufferEvent curevent->status,curevent->data(0),curevent->data(1)
case &H0, &HF0 'Sysex
'first, check the id
|
| Code: |
case 0x80:
snd_seq_ev_set_noteoff(&ev, chanID, msg[1], msg[2]);
send_event(1);
break;
case 0x90:
snd_seq_ev_set_noteon(&ev, chanID, msg[1], msg[2]);
send_event(1);
break;
case 0xB0:
snd_seq_ev_set_controller(&ev, chanID, msg[1], msg[2]);
send_event(1);
break;
case 0xC0:
snd_seq_ev_set_pgmchange(&ev, chanID, msg[1]);
send_event(0);
break;
case 0xD0:
snd_seq_ev_set_chanpress(&ev, chanID, msg[1]);
send_event(0);
break;
case 0xE0:{
long theBend = ((long)msg[1] + (long)(msg[2] << 7)) - 0x2000;
snd_seq_ev_set_pitchbend(&ev, chanID, theBend);
send_event(1);
}
break;
default:
LOG(LOG_MISC,LOG_WARN)("ALSA:Unknown Command: %08lx", (long)msg);
send_event(1);
break;
|
_________________
Current project: Chronoboy Adventures
Website: http://www.chronoboy.com/ |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Mon Dec 06, 2010 8:15 am Post subject: |
|
|
| Quote: | | DOSBox is SDL based, and perhaps they have a workaround that works with SDL_mixer. |
DOSBox would have no use for SDL_mixer, because it's for playing audio files in popular formats. DOS programs emit either raw waveform streams (I'd like to point out that you can't play your own streams using SDL_mixer, ie, you can't use it as a mixer!), or play old DOS music formats like BAM using the FM synthesis chip on the sound card, or rarely, use the MIDI port/synthesizer. DOSBox has an OPL2/3 FM software synthesizer (borrowed from the MAME project (and it would be cool to use this to play BAMs instead of translating to MIDI)).
| Quote: | | prBoom for example, uses Timidity++ and SDL_Mixer. |
Very interesting. I guess they've decided that using SDL_mixer's Timidity fork is a bad idea, and I think we should stop doing it too.
There are lots of DOOM ports (they're all derived from one-another) and similar game port projects which use SDL_mixer. I come across them all the time when searching for information about SDL_mixer bugs.
SDL_mixer also includes an old fork of mikmod, but luckily they've cleaned that one up so that you can now choose (at compile time) to use an external library instead of this old one.
Mike Caron wrote all the MIDI code in music_native and music_native2; I don't know my way around it.
| Quote: | | Would a ALSA backend be possible? As there is a native backend for Windows, which sends MIDI commands very similar to how DOSBox sends MIDI commands to ALSA. |
Here's an idea. music_native/native2 are Audiere for everything except MIDI plus native Windows MIDI. We could add ALSA support to music_native/2, and I could also add Mac OS X MIDI support to it by reusing the SDL_mixer OS X native MIDI code, which I was recently working on.
I suggest that we split the music backend into two pieces: MIDI, and everything else. For 'everything else', we can have two options: SDL_mixer, and Audiere. For MIDI, the two options are SDL_mixer, and our own collection of native MIDI routines for ALSA, OS X, Windows, and maybe OSS (below). That way we can ditch SDL_mixer's TiMidity fork (we would still allow it as an option though. Some of our Windows users use it: seems to be common for Windows' MIDI support to break)
However, ALSA is Linux-only. OSS on the other hand is supported on lots of different Unices, so it would be nice to have OSS output, though it's not necessary. ALSA is recommended for Linux anyway, so it's still a good idea to use that (we have zero BSD users afterall).
This plan sounds a bit better to me than forking SDL_mixer, as that's a nuisance, and it's a pretty standard library in GNU/Linux distributions, so it's much much easier to use as it is. But there are a lot of other people who would love to see the TiMidity fork in SDL_mixer updated or removed, so that's definitely a worthwhile project to work on.
One big hurdle is that the MIDI code in music_native and music_native2 is currently very buggy. Luckily I recently (in Chronoboy Adventures) found lots of good testcases for previously hard to reproduce bugs
'' . bug_title('244') . '' (music_native)
'' . bug_title('359') . '' (Audiere)
'' . bug_title('450') . '' (music_native)
'' . bug_title('867') . ''
'' . bug_title('298') . '' (music_native2)
'' . bug_title('866') . ''
I don't know much about SWIG. There's an alternative though, h_2_bi: http://www.freebasic.net/forum/viewtopic.php?t=15364
_________________
"It is so great it is insanely great."
Last edited by TMC on Mon Dec 06, 2010 5:46 pm; edited 3 times in total |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Dec 06, 2010 10:47 am Post subject: |
|
|
| The Mad Cacti wrote: | | I suggest that we split the music backend into two pieces: MIDI, and everything else. For 'everything else', we can have two options: SDL_mixer, and Audiere. For MIDI, the two options are SDL_mixer, and our own collection of native MIDI routines for ALSA, OS X, Windows, and maybe OSS (below). That way we can ditch SDL_mixer's |
I totally agree about splitting the music backend. We need a backend for midi and a backend for everything else. That would give us more ability to mix and match options to figure out which works best.
=MIDI OPTIONS=
* SDL_Mixer (sucks on linux)
* Timidity++ (difficult to interface?)
* Native (use music_native's approach on Windows, and Alsa on Linux. ??? on Mac)
=EVERYTHING-EXCEPT-MIDI OPTIONS=
* SDL_Mixer (works but sucks)
* Audierre (works? Even more unmaintained than SDL_Mixer)
* Bundle our own libbogg+libvorbis+mikmod (???) |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Mon Dec 06, 2010 7:42 pm Post subject: |
|
|
Cool. I'll work on it... at some point. This time we can go with runtime selectable music/midi backends, as we have for graphics.
midi_*
| James Paige wrote: | =MIDI OPTIONS=
* SDL_Mixer (sucks on linux)
* Timidity++ (difficult to interface?)
* Native (use music_native's approach on Windows, and Alsa on Linux. ??? on Mac) |
I don't know whether Timidity++ has any application interface other than a MIDI port. FluidSynth could be another option.
Also, we have two alternative native MIDI implementations on Windows, music_native and music_native2. Maybe it would be cleaner to give all the OS-specific midi backends separate names, ie. midi_sdl, midi_alsa, midi_win, midi_win2, midi_osx, midi_oss.
music_*
| Quote: | =EVERYTHING-EXCEPT-MIDI OPTIONS=
* SDL_Mixer (works but sucks)
* Audierre (works? Even more unmaintained than SDL_Mixer)
* Bundle our own libbogg+libvorbis+mikmod (???) |
The last option sounds an awful lot like "fork SDL_mixer" to me.
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Tue Dec 07, 2010 9:33 am Post subject: |
|
|
| The Mad Cacti wrote: | | I don't know whether Timidity++ has any application interface other than a MIDI port. |
Yeah, using Timidity++ directly might be a matter of spawning timidity in an external process with the midi file on its command-line... which might be a really bad idea for a few reasons. :)
| The Mad Cacti wrote: | | FluidSynth could be another option. |
I forgot about FluidSynth! That is a good one!
| The Mad Cacti wrote: | | Also, we have two alternative native MIDI implementations on Windows, music_native and music_native2. Maybe it would be cleaner to give all the OS-specific midi backends separate names, ie. midi_sdl, midi_alsa, midi_win, midi_win2, midi_osx, midi_oss. |
Seconded. That really sounds much cleaner. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
