#exult logs

#exult full logs for 12 Dec 2012 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:26:15] <Marzo> Dominus: you have one guess as to which version I implemented in Exult
[00:28:44] <Marzo> Of course, I used the single-thread mode as I wasn't aware about the other one
[00:37:20] <Marzo> Interestingly, one of Zenzu's test images is U7 :-)
[00:41:48] <Marzo> Wow, he did a substantial rewrite
[02:24:14] --> i30817 has joined #exult
[02:24:14] <-- Dominus has left IRC (Ping timeout: 240 seconds)
[02:27:10] --> Dominus has joined #exult
[02:27:11] --- ChanServ gives channel operator status to Dominus
[02:40:55] <i30817> Hello. If i actually manage to do a patch that uses the last version of the mt32 emulator for exult; but don't actually create the required makefile for building it (since i don't know why and would like keeping using cmake for the builld), would you be willing to do the makefile for it's inclusion?
[02:41:16] <i30817> why should be how in that sentence
[05:18:59] <-- Kirben has left IRC ()
[05:24:31] --> Kirben has joined #exult
[05:24:32] --- ChanServ gives channel operator status to Kirben
[05:58:56] <i30817> Ok i think it's 'easy' to adapt the new mt32emu to exult. But i want to build it daily (both exult and the mt32em from upstream). So my includes and patch will be different (in the makefiles and included headers) than what will probably end up in exult if you do the same.
[05:59:09] <i30817> Patch would be probably useless for you.
[06:19:04] <i30817> I haven't touched the 'sysex data problem'
[06:19:24] <i30817> LowLevelMidiDriver looks very complicated.
[06:22:23] <i30817> Also, in the patch i'm testing, i'm not using autotools to make the mt32emu but it's own cmake (because i'm going to build it from upstream). So i'm actually disabling compilation of the mt32emu dir in the autotools makefiles. Therefore; you'd need to do the hard work of creating another makefile for the emu in another style.
[06:25:42] <Eviltar> i think the mt32emu sounds pretty good
[06:25:50] <Eviltar> compared to fmopl
[06:26:49] <Eviltar> i was suprised what a difference it made with the roms for it
[06:35:31] <i30817> You can run it without the roms!??
[07:40:06] <Dominus> i30817: how do you plan to test newl implemented munt if you can't compile Exult with it?
[07:40:21] <Dominus> makefile is easy as it is autogenerated from makefile.am/in
[07:40:51] <Dominus> and when you look at them you see that it isn't much more than adding the newly added files
[07:41:09] <i30817> Will not work if upstream changes.
[07:41:27] <i30817> While the other hopefully will.
[07:41:49] <Dominus> that's why I'm asking, how do you plan to do it?
[07:42:10] <Dominus> as a lib, how we use fluidsynth?
[07:43:10] <i30817> Yes a lib. Launchpad imports part of Sergm repository; the debian/rules file makes the lib; and the makefile links against it and includes the headers from upstream too.
[07:44:01] <Dominus> just adding the lib in makefiles will not make Exult use it...
[07:44:12] <i30817> It's how i'm building dosbox in the other daily build ppa i did.
[07:44:24] <i30817> How so?
[07:44:32] <Dominus> you apply a patch to dosbox that adds more than the makefile
[07:45:12] <i30817> Oh, but you're already using the mt32emulator. Not much changed there.
[07:45:21] <i30817> Dosbox source had nothing.
[07:45:39] <Dominus> you can add any lib to Exult through the makefiles but Exult has to *know* that it should use the lib
[07:45:41] <i30817> BTW, the patch is not mine, but Sergm
[07:46:08] <Dominus> otherwise it will just keep on using the implemented munt not the external
[07:47:13] <i30817> Sure. That's why i disabled the makefile for audio/midi_drivers/mt32emu in audio/midi_drivers/Makefile.am. Easy to do with a diff
[07:48:32] <i30817> Then just redirect the headers of the mt32mididriver to the linked in version.
[07:48:43] <i30817> Which is where i'm having trouble now.
[07:49:53] <Dominus> I can imagine since you need to include the headers and not just add the lib through makefiles...
[07:50:45] <i30817> if BUILD_MT32EMU
[07:50:47] <i30817> EXTRA_INCLUDE_MT32=-I$(srcdir)/munt/include
[07:50:48] <i30817> endif
[07:50:50] <i30817> INCLUDES = $(EXTRA_INCLUDE_MT32) -I$(srcdir)/../../headers -I$(srcdir)/../../conf -I$(srcdir)/../.. \
[07:50:51] <i30817> -I$(srcdir)/.. -I$(srcdir)/../../files -I$(srcdir)/../../imagewin \
[07:50:53] <i30817> -I../../conf -I../../files -I../../objs -I$(srcdir)/../../shapes \
[07:50:54] <i30817> $(SDL_CFLAGS) $(KMID_INCLUDES) $(INCDIRS) $(WINDOWING_SYSTEM) \
[07:50:56] <i30817> $(DEBUG_FLAGS) $(CPPFLAGS)
[07:51:27] <i30817> My problem right now is this:
[07:51:29] <i30817> In file included from MT32EmuMidiDriver.h:27:0,
[07:51:30] <i30817> from MidiDriver.cpp:35:
[07:51:32] <i30817> ./munt/include/mt32emu/Synth.h:192:2: error: 'Synth' does not name a type
[07:51:47] <i30817> Weird part is that Synth.h is the Same file
[07:52:11] <i30817> And obviously the same namespace not?
[07:53:12] <Dominus> you disabled MT32EmuMidiDriver.h in the makefile.am BUT you are including it in Mididriver.cpp...
[07:53:40] <Dominus> you have to change #include "MT32EmuMidiDriver.h" in mididriver
[07:55:09] <i30817> Nah. I expressed myself wrong. In the make file there is:
[07:55:11] <i30817> if BUILD_MT32EMU
[07:55:12] <i30817> #MT32EMUDIR=mt32emu #not built by these makefiles
[07:55:14] <i30817> MT32EMUDRV= \
[07:55:15] <i30817> MT32EmuMidiDriver.cpp \
[07:55:17] <i30817> MT32EmuMidiDriver.h
[07:55:18] <i30817> endif
[07:55:20] <i30817> SUBDIRS = timidity $(MT32EMUDIR)
[07:55:21] <i30817> Just the subdir (to prevent the other makefile executing) are disabled.
[07:55:33] <Dominus> and then change makefile.common too that it doesn't look for"MT32EmuMidiDriver.o
[07:55:33] <i30817> is disabled
[07:55:39] <Dominus> same problem
[07:56:11] <Dominus> mididriver.cpp is including the MT32EmuMidiDriver.h but it doesn't get built
[07:56:58] <Dominus> actually it tries to build it
[07:57:18] <Dominus> BUT that header is #include "mt32emu/mt32emu.h"
[07:58:43] <Dominus> that's why I wrote you can't just add stuff through makefiles
[07:59:03] <Dominus> you have to change parts of the source too
[07:59:57] <i30817> guess the --enable-mt32emu wasn't working then?
[08:00:18] <Dominus> that's not the problem
[08:09:29] <i30817> I already changed the include before...
[08:09:31] <i30817> +#include "mt32emu/Structures.h"
[08:09:32] <i30817> +#include "mt32emu/Synth.h"
[08:09:34] <i30817>
[08:09:35] <i30817> That thing in the makefile.common was new to me, but it doesn't appear to be the cause of this error here.
[08:10:51] <i30817> -#include "mt32emu/mt32emu.h"
[08:10:53] <i30817> +#include "mt32emu/Structures.h"
[08:10:54] <i30817> +#include "mt32emu/Synth.h"
[08:10:56] <i30817> more like
[08:18:34] <i30817> That header Synth.h in munt has a class inside it that uses a Synth *.
[08:18:35] <i30817> Failing there.
[08:19:09] <Dominus> so it is not the same after all
[08:20:55] <i30817> Recursive definition WTF.
[08:21:09] <i30817> No there is only one Synth in mt32emu
[08:21:24] <i30817> Maybe it works with the sources in the same dir
[08:21:32] <Dominus> it will not
[08:22:04] <Dominus> you will not get by with just replacing the files
[08:23:08] <Dominus> I'm trying to tell you that you will need to code more something like the fluidsynth driver to include the external munt
[08:25:37] <Dominus> MT32EmuMidiDriver is expecting things to work in certain ways when you just throw the munt sources in there (directly or by changing the makefile) it's bound to not work as it isn't working for you...
[08:27:10] <i30817> Let me waste my time then
[08:28:52] <Dominus> be my guest. just wanted to spare you some frustrations and send you the more fruitful way. that's all up to you
[09:28:41] <i30817> Respect++ that you can bear this autotools crap.
[09:28:43] <i30817> I'd have replaced everything by scons or cmake or die trying.
[09:36:37] <-- Kirben has left IRC ()
[09:44:12] <-- ParuNexus has left IRC (Read error: Connection reset by peer)
[09:44:28] --> ParuNexus has joined #exult
[09:56:10] <Dominus> full of anger you are. to the dark side it leads...
[09:57:05] <Dominus> if you want you can add cmake rules as a patch, since they can live happily next to each other...
[09:58:32] <Dominus> btw. if you manage to get munt libbed in, this could also be accepted into Exult. I agree that it would be nicer to be up to date with munt.
[10:25:43] <Marzo> For what is worth, sometime back I was working on upgrading the version of Munt used by Exult; it was on the laptop that died
[10:26:20] <Marzo> Doing that would have forced me to deal with the sysex data problem, as I saw that the new version was stricter about timing
[10:27:05] <Marzo> I will see about doing it after the 22nd (when my semester ends) if it is not done by then
[10:59:40] --> Kirben has joined #exult
[10:59:40] --- ChanServ gives channel operator status to Kirben
[11:00:29] <-- Rottingbeef has left IRC ()
[11:01:09] <Dominus> ooh, dead laptop -> evil
[11:01:55] <Dominus> Marzo, if you get around to doing it I think the lib way would really be better.
[11:02:19] <Dominus> And I know how tempting it is to rather do something else than study, so don't be tempted to do it now
[11:02:23] <Dominus> stay focused :)
[11:02:23] <Marzo> What lib way?
[11:02:49] <Dominus> using Munt as an external lib (which is at least now possible)
[11:03:09] <Marzo> Ah, that
[11:03:14] <Dominus> same as Fluidsynth, instead of integrating current munt into Exult
[11:03:22] <Marzo> It is actually better for performance, but it requires some setup
[11:03:48] <Marzo> It is also how I saw that the sysex data problem was an issue
[11:03:53] <Marzo> (buffer overflows)
[11:04:09] <Dominus> yes (what I tried to tell i30817) needs setup
[11:04:51] <i30817> mt32emu has no package in the debian repos.
[11:05:32] <Dominus> i30817: can you show me the dosbox patch? Maybe I can muck around with it a bit
[11:05:56] <Dominus> (though probably not - I mostly fail at that stuff)
[11:05:59] <i30817> Yeah, dosbox makefile is nothing as complex as yours.
[11:06:06] <i30817> It won't help
[11:06:14] * Dominus sighs
[11:06:20] <Dominus> the makefile is NOT the problem
[11:06:34] <Dominus> can you show it to me anyways?
[11:07:19] <Dominus> pastebin or so
[11:07:29] <i30817> Code is here: http://bazaar.launchpad.net/~i30817/dosbox/packaging/view/head:/debian/patches/dosbox-0.74-mt32-patch.diff
[11:10:18] <Dominus> see that patch, you'd need to translate mostly the midi_mt32.h it creates for Dosbox to something Exult could use
[11:12:31] <Dominus> but thanks for the patch, maybe I'll create a munt dosbox snapshot for OSX through that. Meant to do it anyway...
[11:13:04] <i30817> Dominus, that patch is not mine, thank Sergm
[11:13:13] <i30817> most of it anyway
[11:13:45] <Dominus> I know :), I meant thanks for showing where to find it, so I don't have to search through the munt thread on vogons :)
[11:14:55] <i30817> Also i _still_ don't see why i would need to replace most of it unless it's because of what marzo said just now. The buffering and threading is taken care of in LowLevelMidiDriver.cpp which is a superclass.
[11:15:20] <i30817> It sends the sysex commands, and buffers. It's how the old version worked.
[11:15:28] --> Rottingbeef has joined #exult
[11:15:41] <i30817> The public api of mt32emu hasn't changed all that much
[11:15:43] <Dominus> you probably don't need to replcae most of it but some
[11:17:52] <Dominus> namespace, inlcuding pentagram.h etc...
[11:18:23] <Marzo> Lets see: if I use a new version of Munt with Exult, it constantly complains of buffer overruns
[11:18:43] <Marzo> It works OK with DOSBox, because the programs were made for real hardware
[11:19:04] <Marzo> But as is, it seems that Exult is sending data too fast
[11:19:17] <Marzo> I think there is a bug report about it as well
[11:19:42] <Dominus> https://sourceforge.net/tracker/?func=detail&aid=3149070&group_id=2335&atid=102335
[11:20:00] <Marzo> There it is :-)
[11:20:25] <Dominus> easy to find since it is assigne dot colourless :)
[11:23:19] <Marzo> I guess never got around having time to do it?
[11:23:42] <Marzo> Err: Colourless never got around ...
[11:24:16] <Dominus> yes, real life...
[11:25:06] <Dominus> (I really think that the dosbox patch I linked to could help setting this up)
[11:25:08] <Dominus> https://sourceforge.net/p/dosbox/patches/241/?page=1
[11:25:38] <Dominus> tracking down the commit from qbix now to see what he actually committed to dosbox in regards to this
[11:29:00] <Marzo> Anyway, I got to go
[11:29:14] <Dominus> you better before getting sucked in :)
[11:29:21] <Marzo> I will read the logs, so you can post it if you find it
[11:29:38] <Marzo> Be back later
[11:29:42] <Dominus> found it and just processing it to a good diff
[11:29:50] <Marzo> Ah
[11:29:55] <Marzo> Well, farewell
[11:34:14] <-- Marzo has left IRC (Ping timeout: 255 seconds)
[11:34:28] <Dominus> updated the bug report with the pastebin link http://pastebin.com/UkZqJFrs
[11:38:40] <i30817> Look i don't think that the emulator writes files to disk anymore. It's all memory now IIRC. So, there is no need to of most of the redirection of the callback in MT32MidiDriver.
[11:39:18] <i30817> Or the changes you had to do (probably to add 'read' and 'write' modes in the library).
[11:40:00] <i30817> So the ANSIFile can be moved outside and leave the lib as is. I'm going to try it.
[11:53:55] <i30817> In fact, i think open file proc is only used now to search for the roms.
[12:08:56] <i30817> So i can easily be replaced with 'baseDir'; which is nothing else than a string pointing to a directory.
[12:08:58] <i30817> And that whole ugly function goes away.
[12:09:27] <i30817> At least that's what the comments on the source of Synth.h lead me to
[12:32:37] <wjp> current git munt indeed has on file writing via props.openFile
[12:32:40] <wjp> s/on/no/
[12:32:54] --> Marzo_android has joined #exult
[12:33:06] <wjp> but note that our current version of that does more than just look in basedir, even for reading
[12:33:12] <wjp> on OS X, it also searches in the bundle
[12:33:25] <wjp> don't know if that's desirable, but it's something to at least realize
[12:33:51] <i30817> But you can't put the ROMs on the bundle; it's copywrited
[12:34:01] <wjp> s/writ/right/
[12:34:03] <i30817> Or is this something users can do?
[12:34:06] <wjp> yes
[12:34:10] <wjp> to keep it self-contained
[12:34:16] <-- Kirben has left IRC ()
[12:34:23] <wjp> Dominus: any opinion?
[12:42:16] <i30817> Well the hope that autotools would call cmake by itself was beautiful while it lasted.
[12:43:12] <i30817> make[2]: *** No rule to make target `audio/midi_drivers/munt/libmt32emu.la', needed by `exult'. Stop.
[12:44:25] <wjp> by itself?
[12:44:43] <wjp> based on which rules?
[12:47:58] <i30817> Eh. The rules from the cmake . produced Makefile i was planning to create in debian/rules on the launchpad recipe
[12:48:00] <i30817> Dirty... so dirty
[12:48:52] <wjp> _if_ you're going to do something like that you should at least let Exult's build system call cmake to generate the Makefile
[12:50:30] <-- Marzo_android has left IRC (Ping timeout: 264 seconds)
[12:50:55] --> Marzo_android has joined #exult
[12:52:19] <i30817> Yes... how?
[12:54:27] <wjp> you should be able to just add two custom targets to 1) build a Makefile using cmake and 2) build libmt32emu.la calling make using that Makefile
[12:54:56] <wjp> (using regular make syntax, bypassing most of automake)
[12:57:48] <-- Marzo_android has left IRC (Read error: Connection reset by peer)
[12:58:14] --> Marzo_android has joined #exult
[13:05:36] <-- Marzo_android has left IRC (Ping timeout: 264 seconds)
[13:11:14] --> TheCycoONE has joined #exult
[13:29:56] <Dominus> wjp, roms in bundle, yes, desired to make self contained bundles. and yes, not perfectly legal to offer such a bundle.
[13:30:15] <Dominus> but why make it possible for all files and leave those roms out of it? :)
[13:30:41] * Dominus is gone again
[13:31:06] * Dominus curses cmake for doing everything different in regards to building stuff
[13:31:54] <Dominus> before I go, i30817, why not make a shell script for that job (first making munt and then making exult) or is that not fitting with launchpad?
[13:34:45] --> Marzo has joined #exult
[13:35:19] <i30817> Launchpad forbids running of shell scripts yes. But i can place whatever i want in debian/rules. Right now the only problem is making autotools exult makefiles use the right target for cmake produced makefiles or this happens:
[13:35:21] <i30817> Making all in munt
[13:35:22] <i30817> make[4]: Entering directory `/home/paulo/NetBeansProjects/exult/exult_clean/audio/midi_drivers/munt'
[13:35:24] <i30817> make[4]: *** No rule to make target `all'. Stop.
[13:35:26] <i30817> I'm not sure it's a good idea to incorporate exult makefiles calling cmake (it's not like that patch would be accepted right?)
[13:35:37] --> Marzo1 has joined #exult
[13:35:37] <-- Marzo has left IRC (Disconnected by services)
[13:35:49] <wjp> no, it wouldn't be
[13:38:15] <wjp> um, unless munt itself uses cmake
[13:38:21] <wjp> in which case it might be
[13:38:39] <i30817> It does.
[13:39:07] <i30817> Or at least mt32emu part of munt does.
[13:39:27] <wjp> i.e., a procedure along the lines of: clone a copy of munt into the exult source tree, run exult's ./configure and then make, where configure and make would automatically detect and build munt would be fine by me
[13:42:30] <i30817> The (shallow) cloning part is what launchpad recipes do.
[13:42:31] <i30817> But libmt32emu should really be a system lib for a project like yours. Cloning doesn't seems very nice for packagers.
[13:42:55] <i30817> (if you want it updated periodically).
[13:44:53] <wjp> we can all wish that mt32emu would be a system lib, but that doesn't seem very realistic at this point
[13:44:58] <Marzo1> Why not also provide a libmt32emu package in the Exult PPA?
[13:45:11] <i30817> yessssss
[13:45:24] <i30817> good idea
[13:45:27] <Marzo1> As long as the ROMs are not distributed, I think it might be fine
[13:45:57] <wjp> disadvantage is that that would be completely useless for other distributions
[13:46:07] <Marzo1> True
[13:46:55] <i30817> The way you do it today (embedding) is the only surefire way to do that.
[13:47:22] <Marzo1> If embedding the new version, I think I would have the emulator run on a separate thread
[13:48:28] <i30817> But for my purpose (a daily, possibly broken build). I would prefer there was a way to disable that embedding and still be able to link to the /system lib
[13:49:51] <i30817> This was easy to do in dosbox, because it had nothing there to build. Eh. And i complained so much when it was not included.
[13:51:42] <-- Marzo1 has left IRC (Ping timeout: 252 seconds)
[13:52:15] <i30817> But i think i can patch/hack that in the diffs.
[13:52:26] --> Marzo has joined #exult
[13:52:42] <i30817> Not generally thou; am hopeless at autotools.
[13:54:49] <Marzo> Well, Exult can be compiled already with or without the included Munt, and neither option influences its ability to use Munt otherwise -- if you set it up properly
[13:55:48] <Marzo> For example, the Munt alsa driver can be used by setting the device type to MT32
[13:56:58] <Marzo> Hrm. Segfault when changing device types
[13:57:18] <Marzo> And disabling midi in one go
[14:00:52] <Marzo> Fixed, committed
[14:06:47] <-- Marzo has left IRC (Ping timeout: 260 seconds)
[14:09:07] --> Marzo has joined #exult
[14:21:39] <-- Marzo has left IRC (Ping timeout: 252 seconds)
[14:23:40] --> Marzo has joined #exult
[14:36:42] <-- Marzo has left IRC (Ping timeout: 264 seconds)
[14:38:30] --> Marzo has joined #exult
[14:51:00] <-- Marzo has left IRC (Ping timeout: 248 seconds)
[15:09:00] --> Marzo has joined #exult
[15:14:59] * Dominus is held hostage by his son and youtube...
[15:21:57] <-- Marzo has left IRC (Ping timeout: 276 seconds)
[15:22:58] --> Marzo has joined #exult
[15:36:23] <-- Marzo has left IRC (Ping timeout: 260 seconds)
[15:37:15] --> Marzo has joined #exult
[15:51:24] <-- Marzo has left IRC (Ping timeout: 244 seconds)
[17:29:59] --> Marzo has joined #exult
[17:36:25] <-- Marzo has left IRC (Ping timeout: 246 seconds)
[17:37:49] --> Marzo has joined #exult
[17:51:14] <-- Marzo has left IRC (Ping timeout: 260 seconds)
[17:52:22] --> Marzo has joined #exult
[18:06:12] <-- Marzo has left IRC (Ping timeout: 248 seconds)
[18:45:26] --> Marzo_android has joined #exult
[19:11:04] <-- Marzo_android has left IRC (Ping timeout: 252 seconds)
[19:33:05] <-- i30817 has left IRC (Quit: ChatZilla 0.9.88.2 [Firefox 17.0.1/20121129151842])
[20:09:19] --> ParuCodex has joined #exult
[20:10:55] <-- ParuNexus has left IRC (Ping timeout: 246 seconds)
[20:45:05] <Dominus> bah, cmake can be as annoying as autotools... (though as I read about cmake cross compiling, cmake could handle the expack problem better when cross compiling :))
[20:55:30] <-- ParuCodex has left IRC (Quit: ERROR: IRC ADDICT dejected!)
[20:56:13] --> ParuNexus has joined #exult
[20:56:16] <TheCycoONE> cmake -> visual studio works though, which is an improvement over autotools
[20:57:29] <-- ParuNexus has left IRC (Read error: Connection reset by peer)
[20:57:36] <TheCycoONE> annoying filling in all the parameters in windows because the autodetect doesn't work there, but otherwise it's a big improvement in my experience.
[20:57:42] <Dominus> ah, yes, that aspect of cmake is nice (cmake -> xcode works, too as far as I heard)
[20:57:52] --> ParuNexus has joined #exult
[20:58:26] <TheCycoONE> yeah
[21:47:41] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[21:55:52] --> Marzo has joined #exult
[22:08:21] <-- Rottingbeef has left IRC ()
[22:35:09] * Dominus hates cross compiling
[22:35:16] * Dominus hates glib2
[22:35:22] * Dominus hates fluidsynth
[22:49:46] --> Kirben has joined #exult
[22:49:50] --- ChanServ gives channel operator status to Kirben
[23:14:51] --> nutron has joined #exult