#exult logs

#exult full logs for 15 Apr 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[02:23:27] --> shazza has joined #exult
[05:20:44] <-- shazza has left IRC (Ping timeout: 255 seconds)
[05:42:38] --> shazza has joined #exult
[05:42:38] --> 36DAAELNS has joined #exult
[09:23:30] <-- Darrenor64 has left IRC (Ping timeout: 264 seconds)
[11:33:30] <-- Marzo has left IRC (Ping timeout: 256 seconds)
[12:04:57] --> TheCycoONE has joined #exult
[13:38:38] --> Quester has joined #exult
[13:38:42] --- Quester is now known as timquester
[13:39:15] <timquester> hi
[13:40:54] <Dominus> hi
[13:42:42] <timquester> wjp: I have some errors when try to build idados-master: http://paste.org.ru/?h1dey7
[13:46:03] <Dominus> Colourless: sorry for nagging. by listening to too much of the intro I also wonder about the FMOPL driver. The intro, especially the birds don't sound like anything one gets in dosbox (meaning with the FMOPL driver in Exult they sound like electronic deep beeps, while in dosbox they seem to be bird beeps :)
[13:47:08] <wjp> timquester: hm, at least the first 3 of those are in IDA SDK headers
[13:53:41] <timquester> wjp: wrong sdk version? or compiler?
[13:55:46] --> TheCycoTWO has joined #exult
[13:58:19] <-- TheCycoONE has left IRC (Ping timeout: 245 seconds)
[14:00:11] <wjp> hm, I can't easily check here
[14:01:31] <Serel> I should hurry up and actually learn to code..
[14:03:49] <-- TheCycoTWO has left IRC (Ping timeout: 248 seconds)
[14:07:22] <wjp> timquester: did the sdk itself build ok?
[14:07:43] <Dominus> another thing about the intro, we play sfx #115 for static but sfx #115 is out of range with jmsfx but fine with the sqsfxbg pack....
[14:08:12] <Dominus> and sorry timquester and wjp for talking in between you, just wanted to record this here :)
[14:10:36] <timquester> ida sdk only for c++ builder, I can't build it in mingw
[14:15:22] --> TheCycoONE has joined #exult
[14:15:40] <wjp> timquester: hm, you may have to define __NT__
[14:16:48] <wjp> oh, but, the mingw Makefile already does that
[14:24:08] <-- TheCycoONE has left IRC (Ping timeout: 246 seconds)
[14:30:16] --> TheCycoONE has joined #exult
[14:52:44] <-- TheCycoONE has left IRC (Ping timeout: 260 seconds)
[14:56:55] --> TheCycoONE has joined #exult
[15:02:29] <-- TheCycoONE has left IRC (Ping timeout: 245 seconds)
[15:07:31] --> TheCycoONE has joined #exult
[15:17:31] <Dominus> hmm, interesting just now noticing that the commit the other day to find out whether a mt32 conversion, could have been done by midi_driver->isMT32() as well
[15:18:35] <Dominus> but I wonder...
[15:18:42] <-- TheCycoONE has left IRC (Ping timeout: 264 seconds)
[15:19:37] <Dominus> wjp, can you check Midi.cc:340 and :471?
[15:20:21] <Dominus> doesn't this if (!midi_driver->isFMSynth() && !midi_driver->isMT32() &&
[15:20:22] <Dominus> music_conversion != XMIDIFILE_CONVERT_NOCONVERSION)
[15:21:13] <Dominus> mean that this only if midi_driver is not fmsynth AND if it is not MT32 AND music conversion is not ....?
[15:21:45] <Dominus> shouldn't this be a || instead of a && or am I misunderstanding that use there?
[15:21:47] <wjp> that is a bit peculiar
[15:23:07] <wjp> but I really don't know enough about these modes to say much more
[15:24:52] <Dominus> funnily when it's either fmsynt or mt32 then it should be XMIDIFILE_CONVERT_NOCONVERSION set
[15:27:50] <Dominus> also, wjp, I can't find where midi_driver->isFMSynth() or midi_driver->isMT32() are defined
[15:29:38] <wjp> audio/midi_drivers/MidiDriver.h, audio/midi_drivers/MT32EmuMidiDriver.h, audio/midi_drivers/FMOplMidiDriver.h
[15:29:48] <wjp> interestingly isMT32 seems to be isMT32emu?
[15:32:05] <Dominus> yes, strange
[15:33:40] <Dominus> but what I meant is, I don't understand where Exult knows whether either of these two are being used as driver
[15:34:32] <Dominus> to me it seems as if that midi->is... only checks whether the driver exists, not as if it is used
[15:34:48] <wjp> it's created dynamically based on platform, config, etc
[15:35:39] <wjp> mainly the driver field in the config
[15:35:57] <Dominus> so the virtual bool isMT32() { return true; } in mt32emudriver.h is only true when the driver is used?
[15:36:14] <wjp> no, it's only called when that driver is used
[15:36:31] <wjp> for other drivers the default in MidiDriver.h is called
[15:36:37] <Dominus> I see
[15:38:15] <Dominus> I really wonder about those && then
[15:39:26] <Dominus> especially the Midi.cc:471 should be if (midi_driver && (!midi_driver->isFMSynth() || !midi_driver->isMT32())) load_timbres(); instead of
[15:39:26] <Dominus> if (midi_driver && !midi_driver->isFMSynth() && !midi_driver->isMT32()) load_timbres();
[15:39:31] <Dominus> to my understanding
[15:39:59] <wjp> no, that can't be right
[15:40:10] <wjp> (!midi_driver->isFMSynth() || !midi_driver->isMT32()) is always true
[15:40:27] <Colourless> the synth mt32 device has instant timbre loading so it behaves differently
[15:41:12] <Colourless> but that doesn't really matter.
[15:41:32] <Dominus> hmm, what if I use
[15:42:09] <Colourless> <wjp> interestingly isMT32 seems to be isMT32emu? << this is pretty much true.
[15:44:31] <Colourless> its called isMT32 because *maybe* another driver might return true to that, but none do. An idea would be something like sending sysex messages to the output device and detecting if it is actually a mt32 at the other end. we don't have midi input support so it is kind of pointless
[15:45:51] <wjp> the conversion field is intended to cover not knowing the capabilities of the output device?
[15:46:13] <Colourless> yeah pretty much
[15:51:55] <Dominus> but how can that work: if (!midi_driver->isFMSynth() && !midi_driver->isMT32() &&
[15:51:55] <Dominus> music_conversion != XMIDIFILE_CONVERT_NOCONVERSION)
[15:53:08] <Dominus> shouldn't that all be OR instead of &&? For that to be true don't all three things have to be?
[15:53:14] <wjp> what do you mean by 'work?
[15:53:45] <Colourless> !midi_driver->isFMSynth() => isNotFMSynth
[15:54:30] <Colourless> ( isNotFMSynth AND isNotMT32 AND Conversion is not No Convert)
[15:54:38] <Dominus> yes, I mean, and I am probably misunderstanding this, for this to be true all thre things have to be not true
[15:55:02] <Dominus> shouldn't this be OR?
[15:55:09] <Colourless> no
[15:55:10] <wjp> with or it would always be true
[15:55:19] <Colourless> if it was or, it would proably always be true'
[15:55:36] <Dominus> ok, so chalk it up to me not understanding this :)
[15:55:39] <wjp> currently it continues into the rest of the function if mt32emu or if fmsynth or if noconversion
[15:56:07] <Dominus> ok, I think I got it now
[16:00:45] <Colourless> a note about the sysex overflow. the code is supposed to be inserting waits *before* it sends a sysex if one was sent too recently. The time a sysex is sent is recoded and the 'correct' time that the message will take to process is calculated and no sysex are allowed to be sent until the time has expired. My mt32 is one of the models that will get the overflows. However Exult does not trigger
[16:00:51] <Colourless> them for me with the current code.
[16:00:53] <Colourless> It makes me suspect that some os midi output drivers may be inserting some buffering so the commands aren't going out on to the wire as soon as the function call completes.
[16:01:30] <Dominus> colourless, do you think you could at any point look/listen at the intro? When the guardian appears in the digital music (and when played through dosbox + mt32) sounds correctly some kind of swoosh, with our code and mt32 no swoosh but some kind of drums
[16:01:50] <wjp> I think I got a sysex overflow when I tried a few weeks ago
[16:03:32] --> TheCycoONE has joined #exult
[16:04:50] <Colourless> understandably difficult for me to debug when it never happens to me. :/
[16:05:41] <Colourless> could be a number of reasons actually. something as simple as (os) timer accuracy could explain it even
[16:06:50] <Colourless> i probably should make the code more conservative (by default) and allow people to make it more agressive if it works on their system
[16:10:37] <Dominus> so far I couldn't reproduce the overflows myself
[16:11:03] <Dominus> marzo complained about them and people on the forum
[16:11:43] <Dominus> not all of them on linux though or that would have been a reason
[16:12:29] <Dominus> or their connecting device but I'm myself on a cheapo usb2midi
[16:12:43] <Dominus> and a rev0 mt32
[16:15:24] <Colourless> i'm using some cheap usb2midi device too
[16:17:27] <Dominus> some kind of manual delay would probably work best then
[16:17:50] <Dominus> wjp: how are you connecting your mt32?
[16:23:33] <-- 36DAAELNS has left IRC (Ping timeout: 248 seconds)
[16:23:41] <-- shazza has left IRC (Ping timeout: 252 seconds)
[16:31:54] <-- timquester has left #exult
[16:48:54] <wjp> Dominus: gameport on an old soundblaster card
[16:52:00] <wjp> also have a usb2midi thingie lying around somewhere, but unused atm
[16:57:08] <Dominus> maybe those cheap usb2midi add an additional delay that takes care of this overflow ;)
[16:57:52] <Dominus> wjp: time to try it, he he
[21:04:35] <-- TheCycoONE has left IRC (Quit: And then there were n-1)