I can't seem to get DOSMID to detect my OPL2 card. I know the card works since it autodetects and plays music in other software, and Mod Master and SBVGM can play opl2 VGM for it.
My system is only a 10MHz 286, so it's not as if an autodetection routine is going too fast. What could be wrong? I don't have XMS for it at the moment.

Edit: Curiously, DOSMid 0.9.2 seems to see the OPL2. Though it does run out of memory on any file above ~35K since I've only got 512K of ram at the moment... I suppose I need to go upgrade that next.

Error 0x7CF wrote on 2021-09-14, 01:17:

I can't seem to get DOSMID to detect my OPL2 card. I know the card works since it autodetects and plays music in other software, and Mod Master and SBVGM can play opl2 VGM for it.
My system is only a 10MHz 286, so it's not as if an autodetection routine is going too fast. What could be wrong? I don't have XMS for it at the moment.

Edit: Curiously, DOSMid 0.9.2 seems to see the OPL2. Though it does run out of memory on any file above ~35K since I've only got 512K of ram at the moment... I suppose I need to go upgrade that next.

There is a bug in current DOSMID that prevents OPL routines initialization when no XMS memory is available. It is likely you are hitting this. Attached is the 0.9.6 beta version (not released yet)... let me know if it works for you.

Two notes:
1. I did not enable AWE32 support in this beta, to make the binary smaller.
2. v0.9.6 comes with an adjustment of OPL settings, everything plays one octave lower now because I've got reports about DOSMid playing one octave too high. I'd welcome any feedback on its new playback.

Yes, it does detect fine in 0.9.6. I also have more free RAM now that there's no AWE32, which is lovely. I'm greatly relieved that it was a known problem, because the adlib card I'm using is one I built myself, and I was concerned it may be failing some detection routine.

My PC's mic-in (what I was using before for audio) is having a driver at the moment so I can't confirm whether the octave change helped. I did feel like the MIDIs were playing a bit high before.

Hello all, quick message to announce that I published DOSMid v0.9.6 right now. Changelog follows. Enjoy.

DOSMid v0.9.6 [03 Jan 2022]
- reset the RPN Pitch Bend between songs
- added /preset=GM|GS|XG|NONE (preset device into specific mode, default=GM)
- new DOSMIDLT.EXE binary ("lite" for low-memory systems), w/o AWE support
- fixed OPL support when combined with /noxms
- OPL emulation plays files an octave lower (suggested by Campbell Kerr)
- low-BPM files timing fix (reported by Campbell Kerr)

Download available on DOSMid's homepage, as usual: http://dosmid.sourceforge.net

hello

i made the same experience like vladimiro that some midi files are played a bit to slow with dosmid.
here some test files

seems it happens not with all files
https://www.mediafire.com/file/qr4iv56nfdkx45 … ditest.zip/file

tested the files with dosmid and with playmidi player with gus

K.A.R.R. wrote on 2022-01-10, 19:09:

i made the same experience like vladimiro that some midi files are played a bit to slow with dosmid.
here some test files

Hello KARR, could you tell me more about this? I played your WAV files but was unable to spot any difference between the "dosmid" and "gus" versions... What should I look at exactly? I even loaded the files side by side in audacity to compare them, but still cannot see anything noticeably different... Help me out please.

Have you tested with the latest DOSMid version (0.9.6)? I fixed there a timing issue that was miscalculating the tempo on some MIDI files.

hi
i tested them with 0.9.6.

dosmid1 sounds slower compared to gus1

u can easily hear and see the difference with gus1.wav and dosmid1.wav file
with audacity
best is to import them and play both at the same time.

song 2 and 3 seems to run at the same speed
i included them to compare

K.A.R.R. wrote on 2022-01-10, 20:16:

u can easily hear and see the difference with gus1.wav and dosmid1.wav file with audacity best is to import them and play both a […]
Show full quote

u can easily hear and see the difference with gus1.wav and dosmid1.wav file
with audacity
best is to import them and play both at the same time.

song 2 and 3 seems to run at the same speed
i included them to compare

Thanks for the clarifications, I was focusing on the wrong files. Looking carefully at the gus1 vs. dosmid1 versions it does seem like DOSMid plays the file slightly slower. I compared the length of the original MIDI file as reported by another player, and it comes up about 2s shorter than what DOSMid computes, which would translate roughly to 0.9% difference. I am amazed that you were able to spot such difference at all. I am not sure of the source of this inaccuracy, but it's most probably a rounding error in timing calculations. It does not seem to be a regression, since v0.9.5 computes the same time, so it's a little inaccuracy that is probably present in all DOSMid versions. I will definitely look into this.

mateusz.viste wrote on 2022-01-10, 21:25:

K.A.R.R. wrote on 2022-01-10, 20:16:

u can easily hear and see the difference with gus1.wav and dosmid1.wav file with audacity best is to import them and play both a […]
Show full quote

u can easily hear and see the difference with gus1.wav and dosmid1.wav file
with audacity
best is to import them and play both at the same time.

song 2 and 3 seems to run at the same speed
i included them to compare

Thanks for the clarifications, I was focusing on the wrong files. Looking carefully at the gus1 vs. dosmid1 versions it does seem like DOSMid plays the file slightly slower. I compared the length of the original MIDI file as reported by another player, and it comes up about 2s shorter than what DOSMid computes, which would translate roughly to 0.9% difference. I am amazed that you were able to spot such difference at all. I am not sure of the source of this inaccuracy, but it's most probably a rounding error in timing calculations. It does not seem to be a regression, since v0.9.5 computes the same time, so it's a little inaccuracy that is probably present in all DOSMid versions. I will definitely look into this.

Hm. I could not reproduce the slowdown problem with version 0.9.6 and using MPU output. Dosmid detected the length of Angieshe.mid as 3:31 ( it seems gus1.wav and dosmid1.wav are the recordings of this file).
It is very close to the real length of the file that is 3:31.31.

Falcosoft wrote on 2022-01-10, 21:47:

Hm. I could not reproduce the slowdown problem with version 0.9.6 and using MPU output. Dosmid detected the length of Angieshe.mid as 3:31 ( it seems gus1.wav and dosmid1.wav are the recordings of this file).
It is very close to the real length of the file that is 3:31.31.

Angieshe.mid is indeed the file to look at, and yes - DOSMid reports its length as 3:31. What I did is that I loaded it in a Linux MIDI player (audacious with a MIDI plugin) and I noticed that it reported the file as being 3:29, so I assumed (naively, perhaps?) that the Linux player computes the proper length.

How did you obtain the 3:31:31 length exactly?

mateusz.viste wrote on 2022-01-10, 21:59:

Falcosoft wrote on 2022-01-10, 21:47:

Hm. I could not reproduce the slowdown problem with version 0.9.6 and using MPU output. Dosmid detected the length of Angieshe.mid as 3:31 ( it seems gus1.wav and dosmid1.wav are the recordings of this file).
It is very close to the real length of the file that is 3:31.31.

Angieshe.mid is indeed the file to look at, and yes - DOSMid reports its length as 3:31. What I did is that I loaded it in a Linux MIDI player (audacious with a MIDI plugin) and I noticed that it reported the file as being 3:29, so I assumed (naively, perhaps?) that the Linux player computes the proper length.

How did you obtain the 3:31:31 length exactly?

I checked it with my Midi player that is very precise in this respect (and has no such reported issue with a rather large user base). I have also tested with GNMIDI that is also a trustful program:

So it seems to me that the really audible slowdown in dosmid1.wav is not because of miscalculated song length.

@Edit:
There are legitimate events at time 3:31.31 (position: 213001; beat 111-04-361) but some players tries to be smart by skipping some events from calculations (End of Track, All Sounds Off etc.) to prevent long running empty/silent parts.
The above or simply badly written calculations can explain the difference. I do not want to be over confident but I'm 99% sure that my calculation is correct.

Falcosoft wrote on 2022-01-10, 22:27:

I checked it with my Midi player that is very precise in this respect (and has no such reported issue with a rather large user base). I have also tested with GNMIDI that is also a trustful program:
angie1.png

So it seems to me that the really audible slowdown in dosmid1.wav is not because of miscalculated song length.

Very interesting, thanks for checking it out. It would seem the Linux player I used to check the length of the MIDI file is not very precise then and can't be trusted as a reference.

I compared the time displayed by DOSMid with an actual clock, and I measured that the angieshe.mid file is being played for 3:40 instead of the displayed 3:31. The other files also seem to have a slight slowdown, but not as much. I did the tests on dosbox though, so I can't be sure the slowdown doesn't come (entirely or partially) from it. I will have to retest on actual hardware to be sure.

@KARR - a couple of questions:
1. did you test on real hardware or on some kind of emulator?
2. If it's on real hardware, what kind of hardware (CPU) is it?
3. did you measure how long the playback actually takes on your computer?

thx for looking into it

1. i used dosbox-x
3. not yet but i can do that

edit:
with playmidi the file plays 3:31
with dosmid 3:38:5

when i use sb16 emulation in dosbox
the file plays only 3:28:5 with dosmid

btw i converted the file with GNMIDFMT
from format 0 to 1 because the old gus playmidi player
has problems to play midi 0 files which have a karaoke track

the player will hang, crash or won't play at all
to fix this the file needs to be either in format 1, or has the karaoke track removed
or the player is started in -verbose or -debug mode

but the org. format 0 angieshe.mid file has the same slow downs with dosmid

K.A.R.R. wrote on 2022-01-10, 23:42:

1. i used dosbox-x 3. not yet but i can do that […]
Show full quote

1. i used dosbox-x
3. not yet but i can do that

edit:
with playmidi the file plays 3:31
with dosmid 3:38:5

when i use sb16 emulation in dosbox
the file plays only 3:28:5 with dosmid

Sounds to me like some timing glitch related to GUS emulation... I tested the angieshe.mid file now with DOSEmu and it plays for exactly 3:31.
I tested it then under DOSBox again (v0.74), but with different sound outputs:
* no sound (dosmid /nosound) = 3:31
* OPL output (dosmid /opl) = 3:31
* MPU output (dosmid /mpu) = 3:31
* GUS output (dosmid /gus) = 3:40

The file also plays correctly on my 386SX through the AWE driver (dosmid /awe) with a SB 64 AWE Gold.

The problem appears to be strictly related to GUS. Unfortunately I do not have a real GUS, so I cannot test if the slowdown would appear on real hardware or not. I suspect this might be either a timing inaccuracy in DOSBOX, or a glitch in the ULTRAMID driver (that's what DOSMid uses for GUS output). I suppose that the GUS playmidi tool does not rely on ultramid and performs direct hardware calls instead, so perhaps that is the reason of the different behavior.
I don't really know what I can with this, the ULTRAMID API is relatively straight-forward, all I do is feeding the ULTRAMID driver with MIDI notes, I have no control over what's happening inside ULTRAMID itself.

yep may be its the ultramid driver.
i also have no real gus to test this.

but thx for looking into this

Hi,
I have noticed that even when /preset=NONE command line switch is given DosMid always sends a GM Master Volume to maximum(127) SysEx message (F0 7F 7F 04 01 7F 7F F7) at the beginning and also at the end of each song.
It seems this can cause problems with Dreamblaster S2 that resets its settings when GM related SysEx messages are sent to it. Can you make a test version that does not send such SysEx messages at least when /preset=NONE switch is given?
Thanks in advance.

Falcosoft wrote on 2022-01-18, 01:25:

I have noticed that even when /preset=NONE command line switch is given DosMid always sends a GM Master Volume to maximum(127) SysEx message (F0 7F 7F 04 01 7F 7F F7) at the beginning and also at the end of each song.

That is correct, yes. The /preset switch controls only the reset sysex (GM RESET / GS RESET / XG RESET / NO RESET).

In any case, a few settings are always pre-executed: RPN=0, pitch bend sensitivity=512 and volume=100%. I execute them to avoid breaking songs when the MIDI song that played last changed any of these settings and forgot to reset them afterwards.

The exact code that performs this initialization is this:

1  /* load piano to all channels (even real MIDI synths do not always reset
2   * those properly) - this could just as well happen during dev_clear(), but
3   * there are users that happen to use DOSMid to init their MPU hardware,
4   * and resetting patches *after* the midi file played would break that
5   * usage for them */
6  for (i = 0; i < 16; i++) {
7    if (i != 9) dev_setprog(i, 0); /* do not set program on percussion */
8    /* set pitch bend to a default preset */
9    dev_controller(i, 100, 0);  /* RPN MSB 0 */
10    dev_controller(i, 101, 0);  /* RPN LSB 0 -> RPN 0x0000 = "pitch bend" */
11    dev_controller(i, 6, 2);    /* Pitch Bend Sensitivity MSB */
12    dev_controller(i, 38, 0);   /* Pitch Bend Sensitivity LSB */
13  }
14
15  /* reset the device's master volume via sysex */
16  dev_sysex(0x7F, "\xF0\x7F\x7F\x04\x01\x7F\x7F\xF7", 8);
17
18  /* preset the midi device to GM/GS/XG mode (or nothing) */
19  switch (params->gmgspreset) {
20    case PRESET_GM: /* GM RESET */
21      dev_sysex(0, "\xF0\x7E\x7F\x09\x01\xF7", 6);
22      break;
23    case PRESET_GS: /* ROLAND GS RESET */
24      dev_sysex(0, "\xF0\x41\x10\x42\x12\x40\x00\x7F\x00\x41\xF7", 11);
25      break;
26    case PRESET_XG: /* YAMAHA XG RESET */
27      dev_sysex(0, "\xF0\x7E\x7F\x09\x01\xF7", 6); /* prefixed with GM reset */
28      dev_sysex(0, "\xF0\x43\x10\x4C\x00\x00\x7E\x00\xF7", 9);
29      break;
30  }

Falcosoft wrote on 2022-01-18, 01:25:

It seems this can cause problems with Dreamblaster S2 that resets its settings when GM related SysEx messages are sent to it.

I don't have a Dreamblaster to test, but this sounds like a hardware bug, doesn't it?

Falcosoft wrote on 2022-01-18, 01:25:

Can you make a test version that does not send such SysEx messages at least when /preset=NONE switch is given?

Sure, here is a version for you that never performs the volume sysex (ie. line 16 of the above code extract is commented out):

http://mateusz.viste.fr/tmp/dosmid-falco/

mateusz.viste wrote on 2022-01-18, 10:10:

That is correct, yes. The /preset switch controls only the reset sysex (GM RESET / GS RESET / XG RESET / NO RESET). […]
Show full quote

Falcosoft wrote on 2022-01-18, 01:25:

I have noticed that even when /preset=NONE command line switch is given DosMid always sends a GM Master Volume to maximum(127) SysEx message (F0 7F 7F 04 01 7F 7F F7) at the beginning and also at the end of each song.

That is correct, yes. The /preset switch controls only the reset sysex (GM RESET / GS RESET / XG RESET / NO RESET).

In any case, a few settings are always pre-executed: RPN=0, pitch bend sensitivity=512 and volume=100%. I execute them to avoid breaking songs when the MIDI song that played last changed any of these settings and forgot to reset them afterwards.

The exact code that performs this initialization is this:

Copy code to clipboard

1  /* load piano to all channels (even real MIDI synths do not always reset
2   * those properly) - this could just as well happen during dev_clear(), but
3   * there are users that happen to use DOSMid to init their MPU hardware,
4   * and resetting patches *after* the midi file played would break that
5   * usage for them */
6  for (i = 0; i < 16; i++) {
7    if (i != 9) dev_setprog(i, 0); /* do not set program on percussion */
8    /* set pitch bend to a default preset */
9    dev_controller(i, 100, 0);  /* RPN MSB 0 */
10    dev_controller(i, 101, 0);  /* RPN LSB 0 -> RPN 0x0000 = "pitch bend" */
11    dev_controller(i, 6, 2);    /* Pitch Bend Sensitivity MSB */
12    dev_controller(i, 38, 0);   /* Pitch Bend Sensitivity LSB */
13  }
14
15  /* reset the device's master volume via sysex */
16  dev_sysex(0x7F, "\xF0\x7F\x7F\x04\x01\x7F\x7F\xF7", 8);
17
18  /* preset the midi device to GM/GS/XG mode (or nothing) */
19  switch (params->gmgspreset) {
20    case PRESET_GM: /* GM RESET */
21      dev_sysex(0, "\xF0\x7E\x7F\x09\x01\xF7", 6);
22      break;
23    case PRESET_GS: /* ROLAND GS RESET */
24      dev_sysex(0, "\xF0\x41\x10\x42\x12\x40\x00\x7F\x00\x41\xF7", 11);
25      break;
26    case PRESET_XG: /* YAMAHA XG RESET */
27      dev_sysex(0, "\xF0\x7E\x7F\x09\x01\xF7", 6); /* prefixed with GM reset */
28      dev_sysex(0, "\xF0\x43\x10\x4C\x00\x00\x7E\x00\xF7", 9);
29      break;
30  }

Falcosoft wrote on 2022-01-18, 01:25:

It seems this can cause problems with Dreamblaster S2 that resets its settings when GM related SysEx messages are sent to it.

I don't have a Dreamblaster to test, but this sounds like a hardware bug, doesn't it?

Falcosoft wrote on 2022-01-18, 01:25:

Can you make a test version that does not send such SysEx messages at least when /preset=NONE switch is given?

Sure, here is a version for you that never performs the volume sysex (ie. line 16 of the above code extract is commented out):

http://mateusz.viste.fr/tmp/dosmid-falco/

Thank you.
Just to make things clear: In another topic I recommended DosMid as a tool that can be used to switch Dreamblaster S2 to MT-32 mode.
There is a Roland prepared midi file that does this process with multiple steps (CC#0 Bank switch on all channels etc) . This works perfectly on Windows but on Dos using DosMid something resets the settings when DosMid quits.
So the problem is not something with the init sequence but with the out sequence. And I noticed that the Master Volume SysEx is also sent AFTER a song is played.
Otherwise it's definitely a hardware related quirk that does not affect the Dreamblaster X2 only the S2. If the above modification does not work my last tip is the Reset All Controllers message executed by DosMid on all channels when it finished playing.

mateusz.viste wrote on 2022-01-18, 10:10:

I don't have a Dreamblaster to test, but this sounds like a hardware bug, doesn't it?

Hi,
Finally I have got my S2 from Serge so I could investigate and I found what caused the problem:
The S2 reacts to CC#121 (Reset All Controllers) messages in an unusual way:
It also forgets previous Bank select messages. According to specification CC#121 messages should not affect selected banks and in case of X2(GS) it works as it should.
So the problem has nothing to do with Volume SysEx messages.
Would you be so kind to to create a parameter for DosMid (or make a special build) that disables the sending of CC#121 messages when the program finished playing or quits?
This way DosMid could be used to switch the S2 into MT-32 mode.
Thanks in advance.

@Edit:
Meanwhile I grabbed the source of DosMid and commented out the CC#121 sending part in OUTDEV.C -> dev_clear().
Now it works perfectly with the S2. So I can confirm that the problem is really the the sequence of Reset All Controllers messages.