#exult@irc.freenode.net logs for 17 Dec 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:00:25] <sh4rm4> (regardless whether archwizard mode was previously active or not)
[00:00:33] <sh4rm4> night
[00:01:27] <sh4rm4> the crematory music sounds horribly wrong with fakemt32
[00:07:33] <sh4rm4> the "noise" tracks sound horrible with fluidsynth/fakemt32 as well...
[00:14:56] <Dominus> nah, not a big fan of adding f5 cheat spelling when there is already a spell cheat
[00:15:17] <Dominus> just advancing that would be more logical, imo
[00:16:17] <Dominus> other sfx are probably controlled by the sfx pack
[00:16:30] <Dominus> you might like jmsfx pack better
[00:17:04] <Dominus> thats soundblaster sfx not mt32 sfx
[00:17:11] <Dominus> now really sleep
[00:23:32] <sh4rm4> well to know about "archwizard" mode you have to be an exult diehard
[00:23:52] <sh4rm4> whereas when you know SERPENT MANIMAL, F5 is the first thing you try to cast spells
[01:38:40] <sh4rm4> Audio subsystem request: Music track # 15 in <STATIC>/mt32mus.dat
[01:38:59] <sh4rm4> ^ that track sounds hideous with GM
[08:32:15] <Dominus> sh4rm4: MIDI is not set in stone. It all depends on the midi device and/or the soundfont. If you have a GS soundfont and you set conversion to GM you are bound to run into bad sounding tracks
[08:32:43] <Dominus> Marzo had a nice music producing stack
[08:33:23] <Dominus> if you read the logs of around the time of his fluidsynth stack commit you can read what tracks he used
[08:33:32] <Dominus> what soundfonts he used
[09:44:31] --> Marzo has joined #exult
[10:26:22] <Dominus> d'oh
[10:27:13] <Dominus> wjp are things like (player->get_midi_driver() != "FMOpl") case sensitive? the FMOpl part I mean?
[10:27:31] <Dominus> that would explain why I couldn't make it to work with (player->get_midi_driver() != "fmopl")
[10:27:33] <Dominus> :)
[10:33:22] <sh4rm4> a string comparison is usually case-sensitive
[10:33:40] <sh4rm4> unless you use strcasecmp, stricmp oslt
[10:34:54] <sh4rm4> since string comparison is slow, and has oddities like case sensitivity, they shouldn't be used for such things
[10:35:02] <sh4rm4> instead an enum should be used
[10:35:40] <sh4rm4> enum MidiDriver Player::get_midi_driver() { return MD_FMOPL; }
[10:36:23] <Dominus> thanks, and why is http://pastie.org/8557879 working and http://pastie.org/8557882 is not? Not working means no ambient tracks for no case?
[10:37:30] <sh4rm4> && && ?
[10:37:58] <Dominus> sorry apart from the && && error, that was just done in pastie
[10:43:04] <sh4rm4> i'd set a breakpoint there and inspect each of the conditions
[10:43:31] <sh4rm4> the second paste looks technically correct
[10:43:44] <Dominus> hmm, seems to work for other cases except for the ogg case
[10:43:47] <Dominus> strange
[10:43:56] <Dominus> ah
[10:44:29] <Dominus> got it, the problem is that you can have ogg enabled but still technically have midi driver FMOpl
[10:44:42] <sh4rm4> ah
[11:20:08] <-- Marzo has left IRC (Ping timeout: 245 seconds)
[11:36:31] --> Marzo has joined #exult
[13:20:20] <Dominus> how can I use midi_driver->isFMSynth() in gamewin.cc? This could really help side stepping the case sensitive issue. wjp can you help?
[14:12:22] --> Marzo1 has joined #exult
[14:12:22] <-- Marzo has left IRC (Disconnected by services)
[14:22:50] --> TheCycoONE has joined #exult
[16:46:52] --> ShamblerDK has joined #exult
[18:27:46] <-- ShamblerDK has left IRC (Read error: Connection reset by peer)
[18:29:02] --> ShamblerDK has joined #exult
[19:35:01] <Dominus> so, I could commit a slightly less broken fix for the ambient background tracks OR I need help :)
[19:35:58] <Dominus> either get_midi_driver() needs to be fixed to be case insensitive or I need another way to exclude the fmopl driver.
[19:36:34] <Dominus> I think this could be done via midi_driver->isFMSynth but I don't succeed in getting that there...
[19:37:56] <sh4rm4> why dont you try to convert the string midi device identifier into an enum ? that should be really simple
[19:38:12] <Dominus> didn't succeed in that either
[19:38:51] <sh4rm4> when a string representation is needed, you can call a function midi_enum_to_string(enum) { switch(enum) { case MD_FMOPL: return "FMOpl"; ... }
[19:42:05] <Dominus> not getting this to work really. And I really thinkit should be doable via the isfmsynth thing :)
[19:43:16] <sh4rm4> shall i give the enum a try ?
[19:46:05] <Dominus> hmm, not yet :)
[19:47:40] <sh4rm4> it would make exult faster, at least
[19:55:06] <wjp> don't be silly
[19:55:14] <wjp> this is nowhere _NEAR_ a bottleneck
[19:55:22] <sh4rm4> it's O(1) instead of O(n+m)
[19:55:38] <wjp> where n and m are bounded by, what, 10?
[19:55:42] <sh4rm4> btw why are some files called .cc, others .cpp ?
[19:56:21] <sh4rm4> well yes 10 +10 and the function call overhead
[19:56:38] <sh4rm4> that saves at least 50 cycles
[19:56:45] <wjp> anyway, isFMSynth is likely the correct approach
[19:56:53] <sh4rm4> and it removes the errorprone string comparisons...
[19:57:23] <wjp> Dominus: where do you want to access that?
[19:58:59] <Dominus> wjp, in gamewin.cc:197
[20:00:38] <Dominus> when I enabled those ambient mt32 tracks for more than the ogg music, I made the mistake that apparently they still get played for midid drivers when conversion is set to mt32 or fakemt32 - even though the option is disabled in the audio settings gump
[20:01:07] <Dominus> my approach to fix this was http://pastie.org/8557879
[20:01:41] <Dominus> but that only works if FMOpl wasn't manually added to exult.cfg with different cases
[20:02:54] <wjp> hm, ideally any such logic would be in Midi.cc
[20:03:17] <Dominus> I tried http://pastie.org/8559043 but that efectively disabled it for oggs because you can have ogg music while the driver is set to FMOpl :)
[20:05:27] <sh4rm4> shouldn't ogg music be treated as a driver ? or is the midi functionality still needed for SFX ?
[20:05:40] <Dominus> damn, got to go, be back in half an hour. sorry... if I don't come back my next child is born...
[20:05:48] <Dominus> sh4rm4: it used to be a driver...
[20:06:09] <wjp> Dominus: oh wow; take care
[20:10:20] <Epitrope> Dominus++ good luck!
[20:14:36] --- sh4rm4 is now known as Jarrett
[20:15:01] --- Jarrett is now known as sh4rm4
[21:02:27] <Dominus> back :) nothing happening tonight it seems :)
[21:02:45] <Dominus> wjp, any idea about that isFMSynth?
[21:09:35] <wjp> mainly 21:02 <@wjp> hm, ideally any such logic would be in Midi.cc
[21:10:03] <Dominus> :)
[21:12:21] <Dominus> hmm, seems it grew from sfx which didn't feel right in Midi.cc to become that mt32 ambient background... which should be ...
[21:24:20] <Dominus> and I'm really stumped about how to use the isFMSyth outside of Midi.cc and whether it *actually* would be useful
[21:25:43] <wjp> there's currently no way to
[21:26:12] <wjp> the things in the public: section in Midi.h are what you can access
[21:26:22] <Dominus> cool, so I wasn't a total fool... :)
[21:27:04] <Dominus> yes, I got so far to get a slap on the wrist by clang for trying to access a private thing...
[21:29:56] <wjp> so the question is if the property of the midi setup you're trying to get is something "nice"
[21:30:23] <Dominus> huh?
[21:30:56] <wjp> what is the big "if" trying to check?
[21:33:14] <Dominus> the if should only allow ogg music, mt32emu and midi conversion mt32 and fakemt32 to play those background tracks
[21:33:30] --> denytornado has joined #exult
[21:34:48] <Dominus> the problem is that when you set midi driver to FMOpl, the cfg could still list midi conversion mt32 or fakemt32 and thus plays the tracks on FMOpld as well
[21:35:16] <Dominus> so I tried http://pastie.org/8557879
[21:35:19] <wjp> why only those?
[21:35:49] <Dominus> because they are midi tracks and are not playable with other drivers
[21:36:32] <Dominus> the data is somehow wrong and these background tracks produce horrible sounds
[21:37:03] <sh4rm4> like instead of a bird chirping, you hear random organ sounds
[21:37:28] <Dominus> they were introduced by Simon Quinn when he added the ogg music
[21:37:57] <Dominus> he discovered that the MT32 played additional background sfx
[21:39:23] <wjp> a few random options: we could add a supports_background_music() function to Midi.h
[21:40:07] <Dominus> wjp, when I tried http://pastie.org/8557879 I discovered that the player->get_midi_driver() != "FMOpl" is case sensitive and doesn't work in the few cases that fmopl is added manually to the cfg
[21:40:20] <-- denytornado has left IRC (K-Lined)
[21:40:49] <wjp> checking specific midi drivers is not so elegant
[21:40:50] <Dominus> supports_background_music_sfx() function sounds good
[21:41:46] <wjp> for the fmopl driver, conversion should be XMIDIFILE_CONVERT_NOCONVERSION right?
[21:41:58] <wjp> (same as with a true mt32)
[21:42:55] <Dominus> yeah but it is not reading that from the cfg file, it's set somewhere else on timbre loading or so
[21:43:42] <wjp> hm
[21:44:14] <wjp> so that's probably not a field to use outside of Midi.cc either
[21:44:20] --> Malignant_Manor has joined #exult
[21:44:48] <Malignant_Manor> I'm certain the midi background sfx issue was talked about before.
[21:44:51] <wjp> since we don't have enough information to use it there
[21:48:37] <Dominus> wjp, another approach would be to only allow ogg music and aynthing that midi_driver->isMT32 to be part of the supports_background_music_sfx() function
[21:49:14] <Dominus> these cases are covered in Midi.cc AFAICT
[21:50:26] <Dominus> Malignant_Manor: last time it was talked about was in april when I did the last commit there, not realizing the fmopl problem
[21:52:23] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[21:53:42] <Malignant_Manor> Dominus, http://log.usecode.org/exultlog.php?log=18Jan2013
[21:54:17] <wjp> an is_mt32() could be the cleanest option
[21:55:02] <wjp> just add a small function isMT32() (or something consistent) to Midi that calls midi_driver->isMT32() internally
[21:56:39] <Dominus> can you do that, please? even though it sounds easy I'm probably over my head
[21:56:39] <Malignant_Manor> It currently plays tracks, Marzo suggests doing it the sfx track way when not using MT32.
[21:57:24] <Malignant_Manor> I also suggest getting rid of COLOURLESS_REALLY_HATES_THE_BG_SFX and using a cfg setting.
[21:57:53] <Malignant_Manor> (and adding it to the audio menu)
[21:57:58] <Dominus> Hmm, Malignant_Manor I'm reading that differently...
[21:58:01] <Dominus> "Not playing the BG SFX with a non-MT32 midi device might be a good idea"
[21:58:22] <Dominus> that is exactly what we are trying to do
[21:58:43] <sh4rm4> just that it's SI
[21:58:56] <Dominus> same difference
[21:59:19] <Malignant_Manor> Yeah, saw old way before that. I was just skimming.
[21:59:32] <Malignant_Manor> I need to go now.
[21:59:48] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018])
[22:00:21] <Dominus> ok, catch you next time. if you want to get rid of COLOURLESS_REALLY_HATES_THE_BG_SFX just start doing it :)
[22:14:50] <wjp> Dominus: add this line in the 'public:' section: bool is_mt32() { return midi_driver && midi_driver->isMT32(); }
[22:14:54] <wjp> (in Midi.h)
[22:15:19] <wjp> not entirely happy with that that checks if midi_driver exists too, but technically if there's no midi driver it's definitely not an mt32, so...
[22:17:29] <wjp> hrm, although I suppose that will entirely miss the case of a true mt32
[22:17:38] <wjp> so never mind that :-)
[22:18:24] <wjp> bedtime now...
[22:18:48] <Dominus> thanks a lot wjp, now I'll see about getting that to work in gamewin :)
[22:22:53] <wjp> (so do note it's a far too simplistic test)
[22:23:12] <Dominus> hmm, it's failing there
[22:23:30] <Dominus> member access into incomplete type 'MidiDriver'
[22:23:57] <wjp> it should be moved to Midi.cc anyway if the test becomes more complicated
[22:24:19] <Dominus> I added it after void load_timbres(); in Midi.h:84
[22:29:12] <Dominus> and complains
[22:29:14] <Dominus> class MidiDriver;
[22:29:36] <Dominus> ./../audio/Midi.h:31:7: note: forward declaration of 'MidiDriver'
[22:29:49] <Dominus> because of that
[22:44:37] <Dominus> ah, needed #include "audio/midi_drivers/MidiDriver.h" in Midi.h
[22:56:32] <Dominus> hm, seems to not work... will have to ask for your help tomorrow again...