Exult Forum

Question. Because if it is using munt, i'd like to 'include' the latest version in the buildbot if i can.

Also does marzo have a repository for the keyring mod?

It's using a modified builtin early version of munt, so no easy way of replacing it with the latest (much better) munt sources. Someone would need to port it over (maybe you? - seriously). OR just use the standalone Munt and set Exult to use an external mt32 device.

But Exult is also using the recorded music from a mt32 device (digital music).

Marzo's keyring mod is in the Exult sources ( in /content/...).

Munt can be statically linked... 'porting' it was no big deal in the dosbox ppa... might be possible.

I see about the mod. That is good, because i don't think that launchpad allows downloads not from version control.

This might be possible with minimal pain (pain == patches).

The troll bag o'tricks ppa has a debian dir i can filtch for the ubuntu debbuilder infrastucture... only difference is that i would be using a recipe to autobuild instead of uploading.

The mt32 source changed alot. I guess this in practice means that MT32EmuMidiDriver.cpp function bodies needs to be changed too. Since exult includes the old munt sources, i'm not sure of the best way to fix this. I mean, sure, changing the upstream source to the latest version would help exult, but it wouldn't actually help me get the latest munt svn a few weeks from now.



Maybe both things need to be done.

Actually, now that i see the source of the mt32 patch, the only reason it was 'easy' is that someone else did all the hard work of integration of dosbox with the patch. I only changed it to read the roms from ~/.dosbox.

Doh.

Best way would probably be to rip out the included munt and make it link against the munt lib.

(Of course this doesn't help with another problem exult has that makes it not sound correctly as the original sounds with a real mt32 - which isn't limited to the mt32 emulation but also affects a real mt32 hooked up to Exult. if you are interested in that story, you will need to search the forum for a two or three years old thread)

Actually, now that i see the source of the mt32 patch, the only reason it was 'easy' is that someone else did all the hard work of integration of dosbox with the patch. I only changed it to read the roms from ~/.dosbox.

He he... But you might still be able to do it if you look how we use fluidsynth (also an external lib) and how the mt32 lib is used in dosbox...

I couldn't import the main subversion from sourceforge into launchpad (launchpad or sourceforge being dumb) and thus am now importing a github mirror (mirror of a mirror eh).

This is kinda nasty though.

BTW; the Marzo here is the same 'Marzojr' registered on Launchpad? If so, i can add him as part of the team on the launchpad project i did for exult (it's needed to use the buildbot, but you don't need to use it yourself or anything).

Just as a precaution in case i get hit by a bus or something.

I am, yes; so I gather that you are i30817?

Correct, i added you as a admin

Currently deleting the patch from the Dallen Wilson package and praying stuff still works (the patch won't work with launchpad compiles because
1 ) it changes files generated by autogen
2 ) recipes apply quilt patches after cloning
3 ) but the ./autogen can only be invoked in debian/rules - which is after the quilt.

I have no idea what i'm doing

MT32 emulation is not very good in Exult. If I remember correctly, the sysex data doesn't seem to work.

Not the fault of the emulator then? Is it never sent?

I don't think it is sent (or not properly. This is also an issue with an actual MT32 hooked up (I don't have one myself). I know changing the sysex that is supposed to be sent doesn't seem to do anything. I remember reading a post where someone manually played the sysex first before Exult plays the song and it works.

edit: Here's a link to the claim.

Yes, we are doing something wrong there...

Hey guys, made it compile... but it blows up a bit after:
Exult version 1.5.0svn
Built at: Dec 7 2012 08:55:29
Compile-time options: USE_TIMIDITY_MIDI, USE_FMOPL_MIDI, USE_ALSA_MIDI, USE_EXULTSTUDIO, HAVE_ZIP_SUPPORT
Compiler: gcc, version: 4.6.3

Platform: Linux version 3.5.0-19-generic
Exult path settings:
Data : /usr/share/games/exult
Digital music : /usr/share/games/exult/music

Looking for 'blackgate' at '/usr/share/games/exult/blackgate'... found game with identity 'FORGE'
Looking for 'forgeofvirtue' at '/usr/share/games/exult/forgeofvirtue'... but it wasn't there.
Looking for 'serpentisle' at '/usr/share/games/exult/serpentisle'... found game with identity 'SILVER SEED'
Looking for 'silverseed' at '/usr/share/games/exult/silverseed'... but it wasn't there.
Black Gate : not found (/)
Forge of Virtue : found
exult_bg.flx : found
Serpent Isle : not found (/)
Silver Seed : found
exult_si.flx : found
Checking rendering support
Windowed 8 bpp ok 16 bpp ok 32 bpp ok
640x480 8 bpp ok 16 bpp ok 32 bpp ok
720x480 8 bpp ok 16 bpp ok 32 bpp ok
800x480 8 bpp ok 16 bpp ok 32 bpp ok
800x600 8 bpp ok 16 bpp ok 32 bpp ok
1024x600 8 bpp ok 16 bpp ok 32 bpp ok
1024x768 8 bpp ok 16 bpp ok 32 bpp ok
1280x720 8 bpp ok 16 bpp ok 32 bpp ok
1280x768 8 bpp ok 16 bpp ok 32 bpp ok
1366x768 8 bpp ok 16 bpp ok 32 bpp ok
Creating AudioMixer...
Audio opened using format: 22050 Hz 2 Channels
Timbers Precached: On play only
OGG Vorbis Digital Music: Disabled
Trying: `Timidity'
timidity.cfg: No such file or directory
Failed to initialize midi player (code: 1)
Failed!
Trying: `alsa'
ALSAMidiDriver: Can't subscribe to MIDI port (65:0)
Failed to initialize midi player (code: -1)
Failed!
Trying: `UnixSeqDevice'
UnixSeqDevice: opening device: /dev/sequencer
UnixSeqDevice: failed: No such file or directory
Failed to initialize midi player (code: -1)
Failed!
Trying: `Forked'
Success!
Midi Output: Enabled
Starting forked player failed
XIO: fatal IO error 0 (Success) on X server ":0"
after 16 requests (16 known processed) with 0 events remaining.
Assertion 'pa_atomic_load(&(b)->_ref) > 0' failed at pulsecore/memblock.c:590, function pa_memblock_unref(). Aborting.
Aborted (core dumped)



What am i missing?

seems to be a problem with pulseaudio. Google the error, that gives some results. maybe you can figure it out.

It's not pulse audio, or at least, it's bad input to pulse audio:

http://exult.info/forum/viewtopic.php?p=298587#p298587

So you really should patch that default to the right value...
128:0

One could argue that Pulse is stupid

Intolerant maybe. Anyway, it's patched by a quilt patch now.

We'll discuss it later on irc, I think.

Think it's a good idea to require the audio-pack (instead of as currently, suggesting it)?

Exult doesn't actually output sound without it except if you chose FMOPL (or have a MIDI device installed)...

I could change the default to FMOPL with another quilt patch... then at least a person who only does

$exult would have sound, even if he doesn't have timidity, mt32, or soundfonts.

Well well well.

Pulseaudio might be stupid after all. That alsa setting only avoids the crash (by selecting a device successfully before trying the 'forked' device, which still crashes).

Requiring the music pack doesn't make sense if about 99% of computers are still perfectly able to playback midi.

Yeah.

But, unless i'm missing something;
alsa, unixseqdevice at least aren't actually working to output music (although alsa gets 'selected' after changing it's port to 128)

Unixseqdevice says:
UnixSeqDevice: opening device: /dev/sequencer
UnixSeqDevice: failed: No such file or directory

'Forked' crashes pulseaudio, so i patched it out by removing the appropriate defines.

Alsa says:
Trying config specified Midi driver: `alsa'
ALSA client initialised [128:0]
Success!
Midi Output: Enabled
Digital SFX's file specified: ... but file not found, and fallbacks are missing

... but doesn't output any music (and no SFX obviously)

The only one that outputs music to me is FMOpl
It's pretty strange Alsa doesn't output right?

Forgot timidity; but that fails without the additional dependency anyway, so i haven't tried.

The 99% that have working output are not running Linux
Seriously, I think this is a linuyx problem with their strange sound backends that easily break.

Do the sfx actually work when the sfx pack can be found?

Yes. BTW, the menu is whacked.

For instance, i selected UnixSeqDevice (which doesn't work) clicked the 'ok' and this was the output

Trying config specified Midi driver: `UnixSeqDevice'
UnixSeqDevice: opening device: /dev/sequencer
UnixSeqDevice: failed: No such file or directory
Failed to initialize midi player (code: -1)
Failed!
Trying: `FMOpl'
Success!

So it actually CHANGED my selection. And that is not all. I went to the menu again, and what was in the option for midi?
Right, UnixSeqDevice instead of the (actually being used) FMOpl

Well, i'm not going to be the one fixing the audiocode...

Stuff is too complicated... and is bitrotted on top. This code was taken from pentagram right?

yes, kind of taken from pentagram but written by the same person

Anyway think i have found the cause for the 'pulseaudio' crash.... somehow.

The forked player does this:
// NB: This function doesn't return unless execlp fails!
static void playFJmidifile(const char *name)
{
execlp("playmidi","playmidi","-v","-v","-e",name,(char *)0);
}

Thing is playmidi is not a dependency. I'm not sure yet (because i patched forked out), but i hadn't playmidi installed. The crash is probably something in the code that calls the forked player dealing badly with rejection.

Well, that prevented the crash, but since playmidi uses OSS, it doesn't work anyway since current alsa seems to have ditched the snd-seq-oss module which is the ALSA emulation of OSS.

Maybe i can replace playmidi by the alsa midi player...

Mmmm, aplaymidi requires knowing the device port... @!#$ it, going to use timidity.

Maybe put in a random delay if i can wrangle it from the timidity options.

^timidity in the forked driver that is^

Hey, you include the timidity source in the program? Why, since you could just depend on the system library?

Ugh, timidity.cfg is not a absolute path in
audio/midi_drivers/timidity.h

/* You could specify a complete path, e.g. "/etc/timidity.cfg", and
then specify the library directory in the configuration file. */
#define CONFIG_FILE "timidity.cfg"

No wonder people have so many problems with this file (it would search on the current directory in linux, windows shortcuts change the current dir).

This was the missing piece for timiditymididriver sound (probably to load the soundfonts).

Not sure the best way to fix this in the source so it works on both windows and linux.
Considering you're embeding timidity++, you might as well also embed the config file, however i guess people would like to keep using their custom soundfonts so searching in the default location could be better.

What's the best soundfont for ultima7 timidity?

The default, freepats?
fluid-soundfont?

Or something else?

Here is a small patch to replace the free floating timidity.cfg by the one in the default dir. Wasn't tested in windows:

http://diffboard.com/snippets/OXRoUVux/versions/1

You might, or might not want to apply this, since i suppose some people might want to use a config only for exult and are used to dropping that file in the exult dir.
but:
1 ) that doesn't work in linux
2 ) there is already a way to specify the timidity.cfg in the exult.cfg xml file.

So this patch just reuses the cfg file of the installed timidity if it is there.

Of course, you might as well say it's strange that you require timidity as a dependency when you actually embed it. I may just include the cfg file in the exult dir and use that one and remove the timidity dependency...

In fact, i think i will.

Can you recap what the problems are so far and what solutions you found?
And we already allow setting the path to the timidity cfg?

problems:
1 ) exult will crash if set to forked in recent ubuntu.

cause of the crash: unverified, probably the caller of the fork not dealing well with rejection.

cause of the cause of the crash: the fork exec command is failing to play - playmidi is no longer in the system because OSS was deprecated. Installing playmidi will make it not crash, but it will not play either (OSS is still deprecated and is not installed).

fixing strategy: i just removed the forkedmidi driver. Because the only alternative i found to playmidi was the commands aplaymidi (ALSA, requires port number) and timidity. Both have other more featurefull drivers, so i ditched it.


2 ) TimidityMidiDriver will fail
cause : this happens because the timidity library you include in exult doesn't find the timidity.cfg file.
It doesn't find it because the way it is used in the source specifies that it is searched on the location where the executable was invoked.
Result: file not found unless you invoke it on a place where the file is. Note that in windows this might not happen all that often because windows timidity install places the cfg path apparently (and windows shortcuts 'cd' to the target directory before running the executable - if the cfg is in the same dir as it it will always run ok).

fixing strategy: I included the cfg in the package (it's done by a bzr merge so i'm not actually changing anything on the windows side). On linux it is somewhat easy to fix this like this because exult is installed on a fixed absolute path (/usr/share/games/exult). On windows this seems impossible, and would require somekind of runtime path construction (say, for the home dir).
Doing things like this allows me to remove the timidity dependence (it wasn't actually used except to get the cfg) and move freepats (the soundfont) to the 'suggestions).
That's another thing - timidity will not output sound without freepats installed (it's 64 mb) and it's in alternative to the music pack anyway, so i moved it to optional like the music pack.

As you asked if you could replace the timidity.cfg location, it seems so to me - this is in timidity.cpp in your sources:
/* see if the pentagram config file specifies an alternate timidity.cfg */
#ifndef PENTAGRAM_IN_EXULT
SettingManager* settings = SettingManager::get_instance();
if (!settings->get("timiditycfg", configfile))
configfile = CONFIG_FILE;
#else
config->value("config/audio/midi/timiditycfg", configfile, CONFIG_FILE);
#endif

'PENTAGRAM_IN_EXULT' whatever it is, is not defined, so the first branch is always taken. That branch only sets the config file to the default setting if 'timiditycfg' is not defined (the 'get' fails to copy it into the 'configfile' variable)

3 ) ALSA not playing : I have no frigging clue what's happening here.

4 ) Did you know that the menu selection when a mididevice fails to be usable will cycle to another mididevice all by itself? And worse, when you open the menu again, you still have the same selection, so you might think you're hearing timidity, while still hearing FMOPL or something.

5 ) Another menu thing - if you set the sounds&music pack in the exult.cfg and set the files in the correct place.... thereafter the sound menu is lying all the time: you can select whatever MIDI driver you want, but you're always hearing the digital music. In fact, i eventually set it to 'disabled' and i still heard the music (although disabled is the right option in this case, to save resources).

6 ) If a midi sound drive 'succeeds' it might not actually be playing anything. This is happening with ALSA, and happens with timidity without freepats. This is a small problem only because the only sound driver i had working by default on install - FMOPL - without anything else -the soundfont or the music pack - was last, so ALSA gets selected first and the first experience of the user is exult without sound.

I'm thinking of 'solving' this by moving the FMOPL driver to the first one to be tested, but fixing ALSA would be better obviously.

7 ) why do the strange buttons without apparent use in some drivers are still selectable? What is a 'Fake Mt32' to the FMOPL driver? Those buttons were seriously confusing me.

4. + 7. I might be able to look into

2. before messing with default timidity cfg location we'd better make sure that you can set it in exult.cfg

5. no clue- that's strange. Works normal for me on osx

For other things, not sure if you really rip things out or ifdef it. Ifdef would ve bettter since this way we can apply a parch to main svn.especially the fork problem.

Eh, 5 is a question of releasing any open resources from the selected midi driver and hiding the option to change it when digital music is enabled. Disable it and it shows again. I think that done that way, there is no chance of misunderstandings (or resource waste).

I don't think the 'fork problem' has a good solution. Plenty of dinosaurs will still be wanting to use OSS in Debian stable or something. I just patched it out in my ppa because it's ubuntu specific.

At most, you'd probably want to investigate why it crashes and burns on a system like this (without playmidi). Just get into a linux system, install exult and uninstall playmidi and get into a dbg exult and select forked.

Nothing for me to debug
What I meant is whether it can be ifdefed in configure to not be used anymore on ubuntu.

Need to remember about all this midi code is I developed it all on Windows. I can not say anything about the quality of the drivers used in Linux compliations. My experience looking at the midi code for linux was midi support in linux is awful. *shrugs*