Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Getting old DOS games working. (DOSBox topics belong in DOSBox areas below, not here).

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby mateusz.viste » 2016-5-19 @ 07:55

ElBrunzy wrote:I use your player to play .mid on dos using the awe32 and some .sbk. Do you know of any good general midi .sbk around 28mb?


Sorry, can't help you there. Myself, I have only 4M of RAM on my AWE64 (Gold), and I use the 2M chaos_gm.sbk sound bank, which I find perfect already.

've even try to implement an "autoplalist" with dosmid in mind : viewtopic.php?f=7&t=47739


I wonder - why wouldn't you create a playlist, so you could feed it to DOSMid directly? It is as simple as this:
Code: Select all
DIR /S /B /-P *.MID > playlist.m3u


At some point I was wondering about adding a "play from directory" feature in DOSMid, but it would require me to scan an entire directory, recursively going through all possible subdirectories and keep everything in RAM, which could be quite memory-intensive, while I want DOSMid to be as lightweight as possible (and since a playlist is so easy to compute, I didn't see the point of implementing such feature).

About the 0.9 version; it now detect the opl at port 388h and play a .mid if I use the "/opl" or "/opl=388" command.


That's cool! Thank you for your tests!

On the 0.9, the music are recognizable and sound not too bad, but it look like it's missing some channels, some instruments sound like they are pitched maybe one or two octave too high and dont seem to be the right instrument


Maybe that's just a matter of using the right instruments? By default DOSMid uses OPL instruments that are probably not the best approximation of GM. Have you tried to load some alternative IBK banks? For instance, when using an IBK file with Doom instruments, I am unable to tell the difference between DOSMid and the real DOOM playing E1M1.

Using the debug version 0.9, you can load an IBK sound bank for instruments, and also optionally a second IBK bank for drums, as such:
Code: Select all
DOSMID /opl /sbnk=INSTR.IBK FILE.MID
or
DOSMID /opl /sbnk=INSTR.IBK,DRUMS.IBK FILE.MID


This SBawe32 share a computer with a GUSclassic, but that I try to init the gus or not, it doesnt seem to change a thing. Do you think it's worth the while (and the risk) to remove completely the gus to do some more testing ?


No, I am pretty sure your GUS is out of the equation here. I did have some suspicions when it came to OPL detection (I don't know the GUS, suspected that it might try to emulate an OPL chip somehow), but if detection works fine for you now, and you hear things, then I don't see how your GUS could be the problem now.

However, many AWE models exhibit a buggy OPL behavior after the EMU8K chip has been used. On one of my card, I have to call AWEUTIL /S after every time that I use the EMU8K (through a game or DOSMID /AWE), otherwise the OPL chip sound is either mute or distorted.
User avatar
mateusz.viste
Newbie
 
Posts: 49
Joined: 2015-7-17 @ 13:03

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby ElBrunzy » 2016-5-20 @ 01:55

mateusz.viste wrote:I wonder - why wouldn't you create a playlist, so you could feed it to DOSMid directly? It is as simple as this:
Code: Select all
DIR /S /B /-P *.MID > playlist.m3u

At some point I was wondering about adding a "play from directory" feature in DOSMid, but it would require me to scan an entire directory, recursively going through all possible subdirectories and keep everything in RAM, which could be quite memory-intensive, while I want DOSMid to be as lightweight as possible (and since a playlist is so easy to compute, I didn't see the point of implementing such feature).

I just dont want to have many and possibly outdated .M3U files hanging around everywhere and I want the solution to work for other players as well. I was never a fan of frontend but that DOSMid dont support wildcart felt a bit unexpected. You could add a recursion switch, but I would prefer a randomize switch. I dont have much sub-dir in my music collection and recursively on other players tend to crash or take ages to scan so I usually don't care about that feature.

I took your idea of creating a .M3U and create a DM.BAT in my DOSMid directory:
Code: Select all
dir /s /b /-p /a-h /on %1 > playlist.m3u
dosmid playlist.m3u /opl /sbnk=gm.ibk

of course you cannot shuffle the list.

Maybe that's just a matter of using the right instruments? By default DOSMid uses OPL instruments that are probably not the best approximation of GM. Have you tried to load some alternative IBK banks? For instance, when using an IBK file with Doom instruments, I am unable to tell the difference between DOSMid and the real DOOM playing E1M1.
Using the debug version 0.9, you can load an IBK sound bank for instruments, and also optionally a second IBK bank for drums, as such:
Code: Select all
DOSMID /opl /sbnk=INSTR.IBK FILE.MID
or
DOSMID /opl /sbnk=INSTR.IBK,DRUMS.IBK FILE.MID


Wow! Great! I wasn't aware of what was a .IBK until this morning when I read your reply. I did some research today about it. I've found a .IBK called GENMIDI.IBK in the CakeWalk 5 directory and it sound great! I start to see a lot of potential in your DOSMid now, MIDIER is great too but I prefer your GUI and DOSMid don't need SBMIDI.EXE and SBSIM.COM. Unfortunately, I've yet to find a good DRUMS.IBK, I downloaded some stuff this afternoon like SBTimbre, SBANK and ADLMIDI, I might find something in there. Do you have any suggestion where I could find a rather general DRUMS.IBK file ?


No, I am pretty sure your GUS is out of the equation here. I did have some suspicions when it came to OPL detection (I don't know the GUS, suspected that it might try to emulate an OPL chip somehow), but if detection works fine for you now, and you hear things, then I don't see how your GUS could be the problem now.

However, many AWE models exhibit a buggy OPL behavior after the EMU8K chip has been used. On one of my card, I have to call AWEUTIL /S after every time that I use the EMU8K (through a game or DOSMID /AWE), otherwise the OPL chip sound is either mute or distorted.

Maybe I'm at fault here. You see, I did found your recommendation to use AWEUTIL.COM /S as a good idea and add it on my AWE.BAT initialization file and did some testing to see if I have a buggy AWE32 and found the behavior very odd so I tidy a bit the configuration of both cards. The GUS classic is never used for recording so I think it can use the same DMA for playback and record, and for some reason the DMA 1 seem to be avoided on that GXPRO computer (who use GUS's SB emulation when the real thing is just at reach?). So after some time I realize that I don't have a buggy AWE32 OPL as you described (phew!) but also OPLD.EXE resulted as "DETECTED OK" in the five methods, and DOSMid 0.8 now work just as well too !
User avatar
ElBrunzy
Member
 
Posts: 417
Joined: 2014-1-26 @ 03:50
Location: Quebec / Canada

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby mateusz.viste » 2016-5-20 @ 07:05

ElBrunzy wrote:I just dont want to have many and possibly outdated .M3U files hanging around everywhere and I want the solution to work for other players as well.


To avoid having plenty of *.m3u leftovers at the end of the day, you might wrap this into a batch script that would use a temporary file, as so:
Code: Select all
REM to use this script, run it as:
REM PLAYDIR PLAYER.EXE DIRECTORY_TO_BE_PLAYED
DIR /S /B %2 > %TEMP%\tmp$play.m3u
%1 %TEMP%\tmp$play.m3u
del %TEMP%\tmp$play.m3u


Would be best if %TEMP% pointed to a ramdisk there, as to speed things up a little, and avoid unnecessary write operations to the drive.
Of course I understand that's not necessarily what you want to hear :) Just suggesting alternative ways to solve the problem here.

You could add a recursion switch, but I would prefer a randomize switch.


You surely mean "no need to recurse into directories, at least the ability to play a flat directory would be better than nothing", right? DOSMid already randomizes its playlists natively (and non-configurably). Anyway, playing a flat directory is something I might implement in v1.0.

I took your idea of creating a .M3U and create a DM.BAT in my DOSMid directory:
Code: Select all
dir /s /b /-p /a-h /on %1 > playlist.m3u
dosmid playlist.m3u /opl /sbnk=gm.ibk


of course you cannot shuffle the list.


No need to. DOSMid shuffles playlists on its own already. Of course other players are another story.

Wow! Great! I wasn't aware of what was a .IBK until this morning when I read your reply.


Learning stuff is a life-long exercise for all of us :)

So after some time I realize that I don't have a buggy AWE32 OPL as you described (phew!) but also OPLD.EXE resulted as "DETECTED OK" in the five methods, and DOSMid 0.8 now work just as well too !


And the princess is saved! Praise the Lord of eternal retro-computing. :)
About buggy OPL on AWE: I think this happens only on models (or a subset of models) that reroute the OPL output through the EMU8000 DSP as to allow effects on OPL (reverb and such). Your card probably don't do that, which is why it has a stable OPL independent of the AWEUTIL initialization.
User avatar
mateusz.viste
Newbie
 
Posts: 49
Joined: 2015-7-17 @ 13:03

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby ElBrunzy » 2016-5-20 @ 14:52

mateusz.viste wrote:To avoid having plenty of *.m3u leftovers at the end of the day, you might wrap this into a batch script that would use a temporary file, as so:
Code: Select all
REM to use this script, run it as:
REM PLAYDIR PLAYER.EXE DIRECTORY_TO_BE_PLAYED
DIR /S /B %2 > %TEMP%\tmp$play.m3u
%1 %TEMP%\tmp$play.m3u
del %TEMP%\tmp$play.m3u


Would be best if %TEMP% pointed to a ramdisk there, as to speed things up a little, and avoid unnecessary write operations to the drive.
Of course I understand that's not necessarily what you want to hear :) Just suggesting alternative ways to solve the problem here.

I'm always open to suggestion, that's the purpose of posting on a forum I think. I'm quite happy with my usual solution of having a small batch file for each player that I call locally in it's own dir. Of course I have to know the structure of my music collection by heart but eh, that's DOS 8). I did try a solution similar as the one you suggest yesterday and I can see two problems : 1) You will end up in the temp directory after a playlist and 2) .IBK loading will be problematic here as you will have to give the full path to them which is longer to write if you have two of them.

You surely mean "no need to recurse into directories, at least the ability to play a flat directory would be better than nothing", right? DOSMid already randomizes its playlists natively (and non-configurably). Anyway, playing a flat directory is something I might implement in v1.0.

Yeah right, sorry for my unclear english, I try to edit my post to make them concise and clear but I sometime end up with something confuse (french Canadian here). With my batch that build a local playlist in the directory where DOSMid reside and knowing that it shuffle the list I'm now a happy camper, of course and again, it would be more user friendly to support wildcard.

Learning stuff is a life-long exercise for all of us :)

What a refreshing tough. But I would have preferred you help me to find some standard drum set .IBK here, that's really the last thing that refrain me to use DOSMid now.

About buggy OPL on AWE: I think this happens only on models (or a subset of models) that reroute the OPL output through the EMU8000 DSP as to allow effects on OPL (reverb and such). Your card probably don't do that, which is why it has a stable OPL independent of the AWEUTIL initialization.

Not sure at all, I'm using the SPDIF connector of that AWE32 card to listening .MOD and .MID at them purest expression :lol: so I doubt it has this bug. Why Creative routed the OPL to the EMU8k and not the PCM Digital channel has always been a mystery to me, do you have any idea ? I will do some precise testing as to know if I have to run AWEUTIL /S to have the EMU and OPL playback on the SPDIF channel and get back with the results, because now I did put it on my AWE.BAT which is called by AUTOEXEC.BAT, I remember having to run DIAGNOSE.EXE to test the SPDIF output at first but that was when I setup the digital solution to my receiver and I realize I had a far from perfect setup of GUS and AWE back then.
User avatar
ElBrunzy
Member
 
Posts: 417
Joined: 2014-1-26 @ 03:50
Location: Quebec / Canada

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby gdjacobs » 2016-5-20 @ 15:41

ElBrunzy wrote:I'm always open to suggestion, that's the purpose of posting on a forum I think. I'm quite happy with my usual solution of having a small batch file for each player that I call locally in it's own dir. Of course I have to know the structure of my music collection by heart but eh, that's DOS 8). I did try a solution similar as the one you suggest yesterday and I can see two problems : 1) You will end up in the temp directory after a playlist and 2) .IBK loading will be problematic here as you will have to give the full path to them which is longer to write if you have two of them.


That directory problem has an easy fix in Windows NT and above. For DOS, I have to use something from a third party, saved as PUSHD.BAT:

Code: Select all
REM to use this script, run it as:
REM PLAYDIR PLAYER.EXE DIRECTORY_TO_BE_PLAYED
PUSHD
DIR /S /B %2 > %TEMP%\tmp$play.m3u
%1 %TEMP%\tmp$play.m3u
del %TEMP%\tmp$play.m3u
POPD


Code: Select all
@echo off
:: Create a fragment containing "cd ". Code from
:: http://www.ericphelps.com/batch/lines/frag-dbg.htm
:: The script is in the TEMP directory, but the
:: fragment will be in the WINDOWS directory so we
:: know it will be in the "path".

:: Original file used POPPATH.BAT and PUSHPATH.BAT. I use
:: POPD.BAT and PUSHD.BAT for consistency with Linux and Win.
echo e 100 "cd "> %temp%\script.txt
echo rcx>> %temp%\script.txt
echo 3>> %temp%\script.txt
echo n %DOSDIR%\popd.bat>> %temp%\script.txt
echo w>> %temp%\script.txt
echo q>>%temp%\script.txt
debug < %temp%\script.txt > nul
del %temp%\script.txt
:: Now finish off the batch file by appending the current directory
truename | find ":" >> %DOSDIR%\popd.bat


As for the other, you could certainly set a shell variable like %SFDIR% or similar for your IBK, SBK, and SF2 files (if you have them). Then you can reference IBK files like %SFDIR%\MYFILE.IBK.
User avatar
gdjacobs
l33t
 
Posts: 4429
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby Cloudschatze » 2016-5-20 @ 17:11

mateusz.viste wrote:However, many AWE models exhibit a buggy OPL behavior after the EMU8K chip has been used. On one of my card, I have to call AWEUTIL /S after every time that I use the EMU8K (through a game or DOSMID /AWE), otherwise the OPL chip sound is either mute or distorted.

The OPL3 core certainly isn't at fault here. The EMU8000 has to be specifically initialized to allow OPL3 input (which AWEUTIL /S does). It sounds like the EMU8000 initialization routine that DOSMID uses for AWE playback may not be taking this into account, requiring subsequent (correct) re-initialization of the EMU8000 for OPL3 input afterward.

ElBrunzy wrote:Why Creative routed the OPL to the EMU8k and not the PCM Digital channel has always been a mystery to me...

Creative was able to save the cost of an additional DAC by routing the OPL3 digital output through the EMU8000. This, of course, also allows for the digital application of the EMU8000's EQ/chorus/reverb effects to the OPL3 output, as well as digital output via the S/PDIF header.
User avatar
Cloudschatze
Oldbie
 
Posts: 956
Joined: 2005-6-16 @ 14:32

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby mateusz.viste » 2016-5-21 @ 13:52

Cloudschatze wrote:The OPL3 core certainly isn't at fault here.


I never claimed so. I said "buggy OPL behavior", meaning the behavior of OPL music is buggy - and it is. The OPL chip itself is very unlikely to be the root cause of the problem, as you stated. Still, for the end user the result is just the same: "OPL does not work".

The EMU8000 has to be specifically initialized to allow OPL3 input (which AWEUTIL /S does). It sounds like the EMU8000 initialization routine that DOSMID uses for AWE playback may not be taking this into account


That's correct, yes. DOSMid uses the official Creative API, which explicitly explains that the OPL is being reactivated, but it is not. It's probably a bug inside the Creative API, which is simply masked on some boards (these that do not reroute OPL through EMU8K). The same buggy behavior is common to many AWE-aware applications, not only DOSMid. Notably the entire Doom series (Doom, Doom 2, Doom Ultimate), so typically running Doom and then Wolf3d results in either no music or very distorted music.
User avatar
mateusz.viste
Newbie
 
Posts: 49
Joined: 2015-7-17 @ 13:03

Re: Midi player for DOS? supporting SB1, SB PRO, SB 16, ADLIB, General Midi...

Postby ElBrunzy » 2016-5-22 @ 23:52

Mateusz : why dont you just reinit the awe chip before you play any music?
User avatar
ElBrunzy
Member
 
Posts: 417
Joined: 2014-1-26 @ 03:50
Location: Quebec / Canada

Previous

Return to DOS

Who is online

Users browsing this forum: No registered users and 2 guests