VOGONS


Reply 80 of 151, by K.A.R.R.

User metadata
Rank Newbie
Rank
Newbie

here are the 2 files

the doom midi file plays ok but
when i play the other file 1st (just 5 sec are enough) and then the doom file
the overdriven guitar plays with a strange sound

Attachments

  • Filename
    test.zip
    File size
    24.66 KiB
    Downloads
    81 downloads
    File license
    Fair use/fair dealing exception

Reply 81 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
K.A.R.R. wrote on 2020-04-01, 17:35:
here are the 2 files […]
Show full quote

here are the 2 files

the doom midi file plays ok but
when i play the other file 1st (just 5 sec are enough) and then the doom file
the overdriven guitar plays with a strange sound

Hello Karr, I finally found some time to set up dosbox with gus emulation. Sadly, I am unable to reproduce the problem... or incapable of hearing it. I recorded both tests I performed (playing the doom tune with and without running 0001.mid first), both my tests are here:
http://mateusz.viste.fr/tmp/vogons/

Do you hear the problem you described on any of these videos?

If not, then I'd be interested in knowing what is the difference in our setups. On my side, I use:
DOSBox v0.74-3
DOSMid v0.9.5
UltraSound TSR ver. 1.12

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 82 of 151, by K.A.R.R.

User metadata
Rank Newbie
Rank
Newbie

hi thx for testing the files

i can hear the problem with your test files:
with file dosbox_000.avi
after 16 seconds the overdriven guitar is played with a strange looping sound. (same at second 20 and second 25)

with dosbox_001.avi the song played flawless.

i tested the midi files with old gravis playmidi player and it does not have this bug when playing the other file first.

Reply 83 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
K.A.R.R. wrote on 2020-04-06, 11:53:

i can hear the problem with your test files:
with file dosbox_000.avi
after 16 seconds the overdriven guitar is played with a strange looping sound. (same at second 20 and second 25)

Ah, indeed - now I hear it. I wasn't sure what to pay attention to. I am impressed you were able to spot this, I would never notice that myself since both "versions" sound fun to me.
Anyway, it sounds like the 0001.mid enabled vibrato on the second channel, and it was kept on at the second song. I will do some investigations. If it's anything I can fix, I will fix it. Thanks for the report.

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 85 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member

After investigations I found out that the 0001.mid song is issuing an RPN controller setting that modifies a parameter called "Pitch bend", and the odd effect you noticed in the doom ep1 tune is a surviving consequence.

The reason why this RPN setting makes troubles is not entirely clear to me. DOSMid sends an explicit "all controllers off" message to the midi device before playing any file, yet the pitch bend controller does not appear to be impacted by this.

As a test, I also tried sending a "MIDI RESET" (status 0xff) message - but it does not reset the pitch bend either.

I am not sure what the good practice would be to deal with this... For the time being I added a hack that resets the pitch bend by crafting a controller set instruction before each file, but I doubt this is the proper approach - after all, there can be lots of RPNs (up to 16 thousands), and lots of NRPNs, too. I cannot possibly reset them all, esp. since their implementation and meaning may vary from one device to another.

Anyway, here attached is the hacked version. I will have to do some further research to devise a more generic solution, though.

Attachments

  • Filename
    dosmid_karr.zip
    File size
    47.17 KiB
    Downloads
    96 downloads
    File license
    Fair use/fair dealing exception

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 86 of 151, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
mateusz.viste wrote on 2020-04-06, 19:32:
After investigations I found out that the 0001.mid song is issuing an RPN controller setting that modifies a parameter called "P […]
Show full quote

After investigations I found out that the 0001.mid song is issuing an RPN controller setting that modifies a parameter called "Pitch bend", and the odd effect you noticed in the doom ep1 tune is a surviving consequence.

The reason why this RPN setting makes troubles is not entirely clear to me. DOSMid sends an explicit "all controllers off" message to the midi device before playing any file, yet the pitch bend controller does not appear to be impacted by this.

As a test, I also tried sending a "MIDI RESET" (status 0xff) message - but it does not reset the pitch bend either.

I am not sure what the good practice would be to deal with this... For the time being I added a hack that resets the pitch bend by crafting a controller set instruction before each file, but I doubt this is the proper approach - after all, there can be lots of RPNs (up to 16 thousands), and lots of NRPNs, too. I cannot possibly reset them all, esp. since their implementation and meaning may vary from one device to another.

Anyway, here attached is the hacked version. I will have to do some further research to devise a more generic solution, though.

Hi,
1. All Controllers Off (CC#121) does not affect RPN/NRPN settings. While the exact implementation details of CC#121 can depend on the device usually only these controllers are affected:

cc121.png
Filename
cc121.png
File size
340.66 KiB
Views
2388 views
File license
CC-BY-4.0

2. In case of GM/GS/XG compatible devices the best practice is to send GM/GS/XG reset SysEx messages to set all parameters to default.
In case of most players you can select what kind of reset message you would like to send before playing. I think it's important to preserve the option of no reset in case someone would like to use his own custom SysEx initialization message.
Besides RPN/NRPN problems All Controllers Off is definitely not enough in case of advanced GS/XG devices since many controllers that can affect the sound radically (e.g. CC# 72-75) are not reset to default by this.

3. In case of not so advanced devices like GUS or OPL you should manually reset known supported parameters to default. Fortunately these devices usually do not support NRPN messages at all. Also there are only 5 possible RPN messages defined.
( Theoretically more could be possible but they are not defined. RPN messages are not vendor specific)
Fortunately Midi files only use and also these devices usually only support Pitch Bend Sensitivity ( RPN 0,0).

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 87 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2020-04-06, 22:00:

1. All Controllers Off (CC#121) does not affect RPN/NRPN settings. While the exact implementation details of CC#121 can depend on the device usually only these controllers are affected:
cc121.png

2. In case of GM/GS/XG compatible devices the best practice is to send GM/GS/XG reset SysEx messages to set all parameters to default

Hello Falcosoft, thanks for your input! I figured the same after reading this Roland documentation:
https://static.roland.com/assets/media/pdf/FP … Imple_e01_W.pdf

I will add a /reset=GM|GS|XG|no switch to DOSMid, allowing the user to enforce resetting the hardware between each song to a selected program. GM will probably be the default, since I assume it is a common denominator for all the other. This won't have any effect on OPL emulation or to other primitive ways of producing music, but I do not think it's a problem, since these are unlikely to bother about RPN/NRPN parameters anyway.

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 88 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member

I have added a new feature to DOSMid, that presets the midi hardware into GM/GS/XG mode (/preset=GM|GS|XG|NONE). Unfortunately this does not make a difference with GUS, since Ultramid does not seem to react to a GM reset at all. Therefore ultimately DOSMid will do both a GM reset (or GS/XG if specified), and on top of that it will enforce a bend pitch RPN reset. This should, I hope, cover all practical cases. Attached the current version with these changes.

Attachments

  • Filename
    dosmid096beta-vogons.zip
    File size
    52.38 KiB
    Downloads
    119 downloads
    File license
    Fair use/fair dealing exception

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 89 of 151, by carlostex

User metadata
Rank l33t
Rank
l33t

Can i make some suggestions to this program?

Use a config file so we can define and assign a function key to a specific MPU port like:

F1 - MPU port 330
F2 - MPU port 320
F3 - GUS
F4 - SB MIDI

Something like this. This is somewhat similar to what GS Play does, but unfortunately GSPlay only allows you to define one MPU-401 port. It would also be nice if you develop the GUI a bit more like loading MIDI files from within the GUI.

Reply 90 of 151, by K.A.R.R.

User metadata
Rank Newbie
Rank
Newbie
mateusz.viste wrote on 2020-04-07, 20:21:

I have added a new feature to DOSMid, that presets the midi hardware into GM/GS/XG mode (/preset=GM|GS|XG|NONE). Unfortunately this does not make a difference with GUS, since Ultramid does not seem to react to a GM reset at all. Therefore ultimately DOSMid will do both a GM reset (or GS/XG if specified), and on top of that it will enforce a bend pitch RPN reset. This should, I hope, cover all practical cases. Attached the current version with these changes.

thx for the fix
sound much better now 😀

Reply 92 of 151, by johnnystarr

User metadata
Rank Newbie
Rank
Newbie

This is excellent. This brings up an interesting subject I've wondered about. Did games around the mid 90s compose their OPL tracks as MIDIs? Meaning, does it make sense to write in MIDI form and use something like this to convert? I dabble with homebrew DOS games and haven't quite reached the subject of OPL / General MIDI composition. I have seen Adlib Tracker II and played with it a bit. As a musician writing in MIDI seems a lot more promising than trying to write tracker files.

Reply 93 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
johnnystarr wrote on 2020-07-28, 20:25:

Did games around the mid 90s compose their OPL tracks as MIDIs?

That depends, I guess. Many (most?) games at that time supported several ways of producing sound - OPL was the most affordable (thus the most common), but it was usually possible to select in a setup menu MPU or (later) AWE32/64. For such multi-output games, it would seem obvious that MIDI is the format to use (sometimes obscured by a custom format like MUS). OPL was used then as a synth with custom "fonts".

Earlier games, when only OPL was available, are a different story - it is completely possible that authors used some kind of tracker - either from AdLib, or an external production, or maybe even some in-house tool.

johnnystarr wrote:

Meaning, does it make sense to write in MIDI form and use something like this to convert?

In 2020? Definitely. Unless you are some kind of an AdLib purist, of course.

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 94 of 151, by digistorm

User metadata
Rank Member
Rank
Member

I personally don't think it has to do with "purist" so much as that such limited hardware is really punished and under-utilised with a general (literally) MIDI track. That is why you see that on many limited platforms (8 and 16 bit consoles, Amiga) trackers were used to make the most of it. General MIDI is nice when you have a "real" General MIDI device doing the work. Of course you could develop a very smart AI powered OPL3 MIDI driver that interprets the composition exactly right and maximises the use of all OPL3 capabilities, but in reality it all sounds very generic if you ask me. I like Adlib Tracker files more then for example the DOOM music (that is MIDI-ish) played through an OPL chip.
Tyrian is a fun exception as the music was composed Adlib-first and I like the adlib version really much.

Reply 97 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
sarp wrote on 2020-10-12, 21:11:

Thanks mateusz, very useful program .... Cheers mate

I'm glad you like it, thanks for the heads up!

vladimiro wrote on 2020-09-18, 20:01:

Hello, how do you change the tempo ???
by default it is 95 and they are heard slow.
Thank you!

DOSMid follows tempo instructions that are present in the MIDI stream, the tempo may change dynamically many times during the song hence making it manually adjustable does not seem to be a useful feature. Some files may miss an explicit tempo instruction, in such case DOSMid is supposed to fall back to 120 BMP, that's a recommendation I had found in some MIDI specifications. Could you please provide me an example of a MIDI file that you have troubles with (ie. that DOSMid plays too slow)? I'd be interested to take a look at it and compare the playback with a few other players.

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 98 of 151, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie

I just realized I had an old version of dosmid and reading the history file I noticed you now support the GUS. I feel very thankful you did that. I did some testing and, to me, the midi sound as best as they can on a gus, although I dont know how ultramid work with midi that patch overflow the gus limit, reading the ultramid programmer guide I read there is that string 'UltraSound card - out of memory', maybe I can just test this myself using a midi that would trigger that.

Another concern I had reading ultramid's doc is that I see it use 24 channel, do you think it mean it always playback at 25725hz? That would be silly but the document dont give you the impression otherwise. I'm not sure this question belong to your thread but maybe you have insight ?

And one last topic, about your player this time. I dont know why dosmid say my gus port is at 078h while my gus is at 240h, am I missing something about hexadecimal ? Also if it's not too much problem for you, I think it's a penchant from many gus owner to know how many ram the patch of a midi take, but searching the ultramid doc I dont see an easy way to know, so I leave this up to you to decide about it.

Btw to answer elianda question about ultramid/megaem, I think ultramid will load the specified patch set needed to play a file (that's what we want!) while using "ultramid -c" or megaem it will load a subset of GM (or other mode) and work around what sound closest.

Reply 99 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
ElBrunzy wrote on 2020-10-27, 16:03:

I just realized I had an old version of dosmid and reading the history file I noticed you now support the GUS. I feel very thankful you did that. I did some testing and, to me, the midi sound as best as they can on a gus

I'm glad it works for you! I do not own a GUS myself, did all the development basing on the GUS emulation from DOSBox, so I wasn't sure it would even work on the real thing. I'm happy it does.

ElBrunzy wrote on 2020-10-27, 16:03:

I dont know how ultramid work with midi that patch overflow the gus limit, reading the ultramid programmer guide I read there is that string 'UltraSound card - out of memory', maybe I can just test this myself using a midi that would trigger that.

Ultramid applies a smart algorithm to drop the notes that are the least likely to be missed by the human ear. Here's an excerpt of the ULTRAMID Programmer's Guide:

        MIDI voices are allocated dynamically and
automatically. Each voice is allocated initially with a
priority of 1. The voices priority is lowered as it plays
through its envelope. So, a midi note that is fading out
has a better chance of getting stolen then a new note that
is sustaining. For example, if notes A and B start at the
same time, and note A sustains while note B starts to taper
off, then note B will be stolen before note A.

In my (limited) testing, this works very well.

ElBrunzy wrote on 2020-10-27, 16:03:

Another concern I had reading ultramid's doc is that I see it use 24 channel, do you think it mean it always playback at 25725hz?

Can't help. No idea why the number of voices would be tied to some playback frequency. I probably know too little about GUS to figure out your line of thoughts.

ElBrunzy wrote on 2020-10-27, 16:03:

I dont know why dosmid say my gus port is at 078h while my gus is at 240h, am I missing something about hexadecimal ?

The thing is that DOSMid actually does not talk to the GUS hardware. Instead, it talks to the Ultramid API, which is a driver sitting between the GUS hardware and the application. GUS itself knows nothing about MIDI, it only knows how to play samples at a given pitch. Ultramid, on the other hand, is a TSR that exposes simple MIDI-like functions and hides all the hardware complexity. It communicates with applications through an INT interface. What DOSMid displays is the interrupt vector that Ultramid has been detected at, in your case: int 0x78. Yes, the wording could be better (ie. it could say "int" in lieu of "port"), but I didn't want to introduce special UI cases just for this one GUS exception.

ElBrunzy wrote on 2020-10-27, 16:03:

Also if it's not too much problem for you, I think it's a penchant from many gus owner to know how many ram the patch of a midi take

I don't think this is something I can obtain from the Ultramid API, sorry.

ElBrunzy wrote on 2020-10-27, 16:03:

Btw to answer elianda question about ultramid/megaem, I think ultramid will load the specified patch set needed to play a file (that's what we want!) while using "ultramid -c" or megaem it will load a subset of GM (or other mode) and work around what sound closest.

-c is supposed to "preload" a GM set, yes, but what if there is not enough DRAM for the entire set? DOSMid does not require ultramid to be loaded with -c, as it analyzes the MIDI file upfront and asks the ULTRAMID driver to preload only the patches that will be required for playing the specific file. Not doing this would lead to the first note of every not-yet-loaded instrument to be missed.

http://mateusz.viste.fr | gopher://gopher.viste.fr