Hello all,

Today I released a new version of DOSMid, my midi player for DOS. Changelog below.

DOSMid v0.9.4 [09 Dec 2018]
- UI displays channels as 'piano' if no instrument is explicitely loaded,
- reduced libc dependencies (smaller footprint),
- displaying the MIDI tracks count,
- displaying the amount of memory used by the MIDI file,
- backspace key jumps to previous song of the playlist,
- minor memory optimizations,
- fixed a memory leak in midi code,
- fixed RIFF-RMID header decoding,
- fixed playlist gap delay computation (fixed /delay behavior, too),
- adaptations to compile in small memory model (smaller, faster),
- removed /log from the default build,
- /noxms can be passed via config file now,
- GUS support (requires the ULTRAMID TSR).

Homepage: http://dosmid.sourceforge.net

Was testing out the latest release this morning and unless I"m doing something wrong, it is giving me errors when trying to load up the Sysex files from the quest studios pack. I can get it to play the other .mids from that pack for the MT-32 that use standard instrument mt-32 mapping, but I'm not able to get any of the sysex files to load. Just gives an error trying to load the sysex file through Dosmid?

CrossBow777 wrote:

Was testing out the latest release this morning and unless I"m doing something wrong, it is giving me errors when trying to load up the Sysex files from the quest studios pack. I can get it to play the other .mids from that pack for the MT-32 that use standard instrument mt-32 mapping, but I'm not able to get any of the sysex files to load. Just gives an error trying to load the sysex file through Dosmid?

Well, sysex is the one thing I never ever use... Possibly a regression then. I assume it worked fine in 0.9.3, and stopped working in 0.9.4, right? Can you tell me what command line you use to run DOSMid, and point me to the exact files you try to run? This way I will be able to reproduce the same problem and see what's going south.

Correct it seems to work fine in 0.9.3 so this is a new issue introduced in the latest version. As an example of the files I'm using. On the first page of this thread is an attachment to the Quest Studios mids from some of the Sierra adventure games. Several of those mids include specific MT-32 versions of the mid files along with matching Sysex patches to go with them. So as an example I was trying to load up the willy beamish mt-32 mid file so I had the following typed to make that happen.

dosmid /syx=willymt.syx willymt.mid

I get the dosmid screen but then would get a red error message window telling me it couldn't load up the sysex file? Version 0.9.3 doesn't give the error and loads up the sysex patch correctly.

I have the /mpu=330 in the .cfg file already which, is why you don't see it typed out in the above command line.

CrossBow777 wrote:

Correct it seems to work fine in 0.9.3 so this is a new issue introduced in the latest version. As an example of the files I'm u […]
Show full quote

Correct it seems to work fine in 0.9.3 so this is a new issue introduced in the latest version. As an example of the files I'm using. On the first page of this thread is an attachment to the Quest Studios mids from some of the Sierra adventure games. Several of those mids include specific MT-32 versions of the mid files along with matching Sysex patches to go with them. So as an example I was trying to load up the willy beamish mt-32 mid file so I had the following typed to make that happen.

dosmid /syx=willymt.syx willymt.mid

I get the dosmid screen but then would get a red error message window telling me it couldn't load up the sysex file? Version 0.9.3 doesn't give the error and loads up the sysex patch correctly.

I have the /mpu=330 in the .cfg file already which, is why you don't see it typed out in the above command line.

Thanks! I reproduced the problem and located the bug, it's related to the disk-buffering feature of my file-handling library. Apparently the disk cache is missing a byte sometimes on cache boundaries. Well, that's what happens when one tries to be smarter than than the libc folks and reimplements his own stuff instead of relying on stdio.h... I will fix it later and get back here.

...and now I released v0.9.5.

DOSMid v0.9.5 [10 Dec 2018]
- Fixed file-reading module (buff corruption on first cache boundary read).

Thanks to CrossBow777 for reporting this bug!

For the case of /GUS and UltraMID is not loaded, can you attempt to do a 'lh ultramid' automatically? (and unload on exit if it was loaded successfully 'on demand' ?)

elianda wrote:

For the case of /GUS and UltraMID is not loaded, can you attempt to do a 'lh ultramid' automatically? (and unload on exit if it was loaded successfully 'on demand' ?)

Well, technically I could, but that's not something I am willing to do :) I think it is not the kind of actions that a program should perform. It's up to the user to set up his rig however he likes it.

I have not looked into the UltraMID API, however can you comment:

Is there any difference in loading UltraMID and using DOSMID /GUS to loading MegaEM and using DOSMID /MPU regarding the output?

What does DOSMID do in the case the 1 MB RAM is not sufficient, e.g. if I run it with UltraMID -16 and load a Midi file that uses a lot of different instruments?

elianda wrote:

Is there any difference in loading UltraMID and using DOSMID /GUS to loading MegaEM and using DOSMID /MPU regarding the output?

What does DOSMID do in the case the 1 MB RAM is not sufficient, e.g. if I run it with UltraMID -16 and load a Midi file that uses a lot of different instruments?

These are interesting questions, unfortunately I have to say that I have no clue about either. Sadly I don't have a GUS card, so I cannot test anything real. My only factual knowledge is that "it works with dosbox", so I assume it should work on a real GUS as well, although I don't know with what kind of limitations.

I also do not know the behaviour of ULTRAMID when too many samples are used by a song to be loaded all into memory. I *believe* that it will unload some of the instruments and load others on the fly (in background), and if my understanding is correct, this will force the first note to be skipped every time an instrument is freshly loaded. This "skipped note" effect doesn't happen on songs that use instruments that all fit in RAM, only because DOSMid takes care to pre-load all necessary instruments before playing the song.

But again - all this I am half-guessing, due to not having actual hardware to test. Hopefully users will tell whether or not it works for them.

mateusz.viste wrote:

...and now I released v0.9.5. […]
Show full quote

...and now I released v0.9.5.

DOSMid v0.9.5 [10 Dec 2018]
- Fixed file-reading module (buff corruption on first cache boundary read).

Thanks to CrossBow777 for reporting this bug!

Wow thank you for such a speedy look into this. I will give this a shot later when I home from work!

elianda wrote:

Is there any difference in loading UltraMID and using DOSMID /GUS to loading MegaEM and using DOSMID /MPU regarding the output?

Additional comment on this one: while I have no clue whether the output is different or not, there is a major difference in how these two drivers work. ULTRAMID is a 100% "clean" 16-bit real-mode DOS driver that comes with a well-documented API, while MEGAEM is a nasty hack that runs in protected mode to emulate hardware that is not there. It's a very clever hack, but still very nasty, in many ways similar to AWEUTIL (for SB AWE cards). I'd expect MEGAEM to be troublesome in at least some setups, while ULTRAMID should work much more reliably. It is also possible that ULTRAMID works on pre-386 computers (although I don't know for sure, but I don't see why it shouldn't), while MEGAEM requires a 386 cpu running in virtual 86 mode (and v86 mode alone is a nasty, nasty thing that I myself avoid at all cost on my computers).

0.9.5 seems to be working just fine! Listened to the entire Codename: Iceman soundtrack when I got home for full testing. Thanks again for the quick fix on this!

CrossBow777 wrote:

0.9.5 seems to be working just fine!

Awesome :)

Thanks again for the quick fix on this!

My pleasure.

hello

i am not sure if you read my pm.
would be nice if dosmid would have a basic gui to select drive, folder and midi file.

K.A.R.R. wrote on 2020-03-30, 18:40:

i am not sure if you read my pm. would be nice if dosmid would have a basic gui to select drive, folder and midi file.

Hello Karr, in fact I have seen your pm only now. Yes, some basic gui would be nice indeed, but to be honest I doubt I will ever find the time to do it. It's not trivial because such browser would have to understand MIDI structures to display nice titles and so on, and ideally it should also allow to work while the MIDI plays in the background. Anything simpler does not have much sense, since it would be better/easier to use DOS navigator or some similar browser and configure it so it executes DOSMid to play MIDI/RMI/MUS files.

mateusz.viste wrote on 2020-03-31, 07:54:

it would be better/easier to use DOS navigator or some similar browser and configure it so it executes DOSMid to play MIDI/RMI/MUS files.

great idea 😀
question is how to do that

K.A.R.R. wrote on 2020-03-31, 18:03:

mateusz.viste wrote on 2020-03-31, 07:54:

it would be better/easier to use DOS navigator or some similar browser and configure it so it executes DOSMid to play MIDI/RMI/MUS files.

great idea :-) question is how to do that

from the few DOS file browsers that I could quickly check, it appears to be a fairly easy task.

DosZip: add a line under the [Filetype] section of dz.ini saying "mid=C:\DOSMID\DOSMID.EXE
DOS Navigator: there is a special in-program menu for that under "Options/Viewers"
Norton Commander 5.5: in-program menu "Commands/Extensions file edit"

thx for the fast reply

it works 😀

i just found a small problem with dosmid.... but this has nothing to do with the dos navigator part.
happens also when i start it manually

i have 2 midi files
when i play file 1 it plays ok same for file 2

but when i play file 1 and then quit dosmid and play file 2
there are strange playback errors.

to fix that i have to close and restart dosbox
may be its a bug in dosmid or with ultramid not resetting gus memory completely after each midi file

K.A.R.R. wrote on 2020-03-31, 18:43:

i have 2 midi files when i play file 1 it plays ok same for file 2 […]
Show full quote

i have 2 midi files
when i play file 1 it plays ok same for file 2

but when i play file 1 and then quit dosmid and play file 2
there are strange playback errors.

to fix that i have to close and restart dosbox
may be its a bug in dosmid or with ultramid not resetting gus memory completely after each midi file

That does sound like some "missing-reset" issue somewhere. Could you please provide me the 2 midi file so I could reproduce the problem?