VOGONS


DOSMid - an open-source MIDI player for DOS

Topic actions

Reply 20 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

How was your flight? Not jet-lagged are you? 🤣

mateusz.viste wrote:
James-F wrote:

2. The "apply syx" should be BEFORE the "apply reset" but only at start.

I am not sure I follow why. The SYX file could very well wish to set things like volume, pre-load some patches, etc. Running the 'apply reset' afterward would undo actions that the user tried to execute via the SYX.

99.99999999% of external SYX are just sysex Reset commands.
Have you every seen otherwise?

As you observed, I do nothing at exit since yesterday's version.

This is actually worse than it was.
It is IMPORTANT that you run Notes Off, Sounds Off, Ctrl Offs. at the end of playback to prevent hanging notes.
It will require a different reset sequence than the one at start.
What if I exit when a note plays (Note On)? It will continue to sound FOREVER. 😢


my important / useful posts are here

Reply 21 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
James-F wrote:

How was your flight? Not jet-lagged are you? :lol:

Perfect. They even have wifi in planes these days, wow. Although I find the weather in Chicago to be far too hot to my taste. Can't wait to get back to my way more temperate (french) climate.

James-F wrote:

99.99999999% of external SYX are just sysex Reset commands.
Have you every seen otherwise?

You can still have users that try to achieve different things. For example, there are even users that try using the DOSMid player as a "MPU initializer" ;-)
The question is rather whether it harms to perform the reset before the syx - I fail to see any possible troubles doing so, while the reverse order might be unpleasant for the 0.1% of users that wish to pre-set custom patches with their syx.

James-F wrote:
This is actually worse than it was. It is IMPORTANT that you run Notes Off, Sounds Off, Ctrl Offs. at the end of playback to pr […]
Show full quote

As you observed, I do nothing at exit since yesterday's version.

This is actually worse than it was.
It is IMPORTANT that you run Notes Off, Sounds Off, Ctrl Offs. at the end of playback to prevent hanging notes.
It will require a different reset sequence than the one at start.
What if I exit when a note plays (Note On)? It will continue to sound FOREVER.

I'm pretty sure you are right, yes. Even though the specific case you mention (hanging note because DOSMid exits in-between a note-on and note-off) doesn't apply here, because DOSMid takes care to turn all remaining notes off all by itself. But there still could be troubles with some clunky hardware that goes into some kind of unstable state.

you should find this version much closer to your need: http://mateusz.viste.fr/temp/dosmid-james/

Here's its step-by-step behavior:
1. clear device (all notes off, all controllers off, master volume reset)
2. preload all-piano patches
3. apply syx, if any
4. playback
5. clear device (all notes off, all controllers off, master volume reset)

Reply 22 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

The question is rather whether it harms to perform the reset before the syx

Not really. Each way will be okay.

The test build is Perfect!
I hope this will be the next release and not only "james version"


my important / useful posts are here

Reply 24 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
James-F wrote:

Question, why DOSMid is so slow to quit?

What do you mean? On my 386SX 20 MHz it's almost immediate. How long is 'slow' in your case? On what kind of PC, and what kind of sound device? Does it happen with all MIDI files? Is it as much slow with other types of sound devices (OPL, SB)?

DOSMid performs a few cleanup operations before exiting, but nothing that should be humanly noticeable. When used with MPU, it also switches the MPU back into intelligent mode (ie. MPU reset), maybe this takes a second or two on some hardware? Does it happen also when called with /noxms and/or /nosound ?

Last edited by mateusz.viste on 2016-06-12, 19:44. Edited 1 time in total.

Reply 25 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

The machine in my signiture.
Taked three seconds after I hit esc, that is quite long.
Thr MPU is UART on a typical sound blaster.
I'm off to sleep, I will expdriment in 8 hours or so.


my important / useful posts are here

Reply 26 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
James-F wrote:
The machine in my signiture. Taked three seconds after I hit esc, that is quite long. Thr MPU is UART on a typical sound blaster […]
Show full quote

The machine in my signiture.
Taked three seconds after I hit esc, that is quite long.
Thr MPU is UART on a typical sound blaster.
I'm off to sleep, I will expdriment in 8 hours or so.

I agree that three seconds between pressing ESC and getting out to the DOS shell is a lot of time. On a 233 MHz it should be instant. My blind guess is that it's related to the sound blaster card getting busy for some reason - if that's the case, then running DOSMid with either /nosound or /opl should not exhibit this delay. Perhaps using /sbmidi could act differently as well (this talks to the SB DSP directly, instead of going through the card's MPU emulation)

Reply 28 of 151, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie

Mateusz.Viste: Great you put the link to the new 0.9 "beta" version. I'm quite eager to give it a try and know more about that /sbmidi feature you are talking (havent read the full thread yet). Just a thing, when you release beta or test version like that, could use add "b" like "0.9b" so we know it's not the official version. Of course it's nothing compared to your work of compiling that software, but I run your player on many of my vintage computers and it's always a guess to know if I have a "true" 0.9 or a test 0.9, if you get my drift? Some computers arent that easy to copy file on them.

Reply 29 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

If you actually run DOSMid beta, it says v0.9.1
Great improvement of the reset behavior over 0.9.

As for /sbmidi, use that if you have a Sound Blaster card and not a real MPU-401 board.
Like mateusz.viste said, DOSMid switches to UART mode before playback and returns to Intelligent mode after playback is the "/mpu" command is used.
With a typical SB card there is no Intelligent mode, it's always UART so there is no need to switch to UART before playback, or reset to Intelligent after.
With /sbmidi it skips the switching of modes and still uses MPU-401 port on your sound blaster.


my important / useful posts are here

Reply 30 of 151, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:
If you actually run DOSMid beta, it says v0.9.1 Great improvement of the reset behavior over 0.9. […]
Show full quote

If you actually run DOSMid beta, it says v0.9.1
Great improvement of the reset behavior over 0.9.

As for /sbmidi, use that if you have a Sound Blaster card and not a real MPU-401 board.
Like mateusz.viste said, DOSMid switches to UART mode before playback and returns to Intelligent mode after playback is the "/mpu" command is used.
With a typical SB card there is no Intelligent mode, it's always UART so there is no need to switch to UART before playback, or reset to Intelligent after.
With /sbmidi it skips the switching of modes and still uses MPU-401 port on your sound blaster.

are you James Rofle the angry video game nerd ?

Reply 32 of 151, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:

If you actually run DOSMid beta, it says v0.9.1
Great improvement of the reset behavior over 0.9.

what is it really about that /switch /sbmidi ? the soundblaster is a real bad guy, one should not waste time about it

Reply 33 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

@mateusz.viste
Adding a /syx=gsreset.syx to dosmid.cfg doesn't work, it only works from the command line.
It's really useful to reset the midi synth before playback.
Also, a delay after the SYX file is important, some synths require a delay after a sysex command.


my important / useful posts are here

Reply 34 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
James-F wrote:

Adding a /syx=gsreset.syx to dosmid.cfg doesn't work, it only works from the command line.

You are quite right. Fixed in beta version: http://mateusz.viste.fr/temp/dosmid-beta/

Also, a delay after the SYX file is important, some synths require a delay after a sysex command.

Do you actually have a problem with syx being unable to load properly? DOSMid is emitting artificial delays since v0.9 exactly for this purpose.

Reply 35 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
ElBrunzy wrote:

what is it really about that /switch /sbmidi ? the soundblaster is a real bad guy, one should not waste time about it

DOSMid supports a variety of MIDI interfaces: MPU, AWE, OPL, RS-232, etc... SoundBlaster is just one of them. Not every SoundBlaster cards comes with an MPU emulation (that is, this thing that make it looks like it is an MPU, but actually forwards re-wrapped bytes to the SB DSP). Some do not have this MPU interface (v1.x and v2.x IIRC), while other expose it but in buggy ways. If one uses a SB card to emit MIDI data to an external synth, it makes more sense to use its native DSP interface (/sbmidi) instead of going through the MPU hoops.

Reply 36 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie
mateusz.viste wrote:

Do you actually have a problem with syx being unable to load properly? DOSMid is emitting artificial delays since v0.9 exactly for this purpose.

It's not like the MT-32 v1 buffer problem, requiring 40ms delay.
I'm using a Roland SC-55 and it takes around 100ms for the effects (reverb/chrous) to come back after a reset.
Meaning, the song starts to play while the reset procedure of the unit is still in progress.

There is no need for a delay after every F7 in the midi (read next sentence), but only after the SYX file loaded with the /syx=xxx command, before playback starts.
Midi songs that use sysex commands inside and were composed on a real hardware synth, take this into account and delay the playback of notes until all the sysex are loaded properly.

Yep, you fixed the syx inside the cfg bug, although I really would like a small 200ms delay after the GS Reset for the SC-55 to behave more predictably.
What if I send a huge SYX file? A playback delay is a must!


my important / useful posts are here

Reply 37 of 151, by mateusz.viste

User metadata
Rank Member
Rank
Member
James-F wrote:

Well I'm using a Roland SC-55 and it takes around 100ms for the effects (reverb/chrous) to come back after a reset.

I see.. The MPU accepts the sysex bytes, the UART says it's 'ready' again, but the MPU is actually still processing the new setting somehow in parallel (since it's able to play notes in-between). Sounds weird, but totally plausible. I added a non-compressible single delay of 100ms after loading/executing the syx file. The beta version should work fine for you now: http://mateusz.viste.fr/temp/dosmid-beta/

There is no need for a delay after every F7 in the midi (read next sentence), but only after the SYX file loaded with the /syx=xxx command, before playback starts.

Actually it seems there is, DOSMid adds a delay of 40ms after each F7 sysex string to avoid 'buffer overflow' messages on MT32 rev00 gears, and 250ms before 'all parameters reset'.

I really would like a small 200ms delay after the GS Reset for the SC-55 to behave more predictably.
What if I send a huge SYX file? A playback delay is a must!

Before today, there were 2 delays already:
40ms after each F7 sysex string
250ms after each 'all parameters reset' (0x7F) sysex

In the beta version that I uploaded a few minutes ago, there is an additional single 100ms delay after all sysex processing, before playing the file. I hope it's enough, because all these delays really start looking hacky :)

Reply 38 of 151, by James-F

User metadata
Rank Oldbie
Rank
Oldbie
mateusz.viste wrote:

In the beta version that I uploaded a few minutes ago, there is an additional single 100ms delay after all sysex processing, before playing the file. I hope it's enough, because all these delays really start looking hacky 😀

Delays are not hacky, they are important and beneficial for correct playback of midis. 😀

Pardon my bold request, but can you set it to 200ms...
I don't think you should make this "delay after SYX" hard-coded, but user changeable.
Some synths take longer than others to load various parameters, and each SYX file is different.

Something like this:

dosmid /syx=*.syx 200 midi.mid

Here's how a 100ms delay after a GS Reset sound with the SC-55:

Filename
doom 100ms.zip
File size
625.73 KiB
Downloads
128 downloads
File license
Fair use/fair dealing exception

You can clearly hear the Reverb delaying at the start, so 100ms is still not enough for the SC-55 to recover after a GS reset.


my important / useful posts are here

Reply 39 of 151, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie
mateusz.viste wrote:

DOSMid supports a variety of MIDI interfaces: MPU, AWE, OPL, RS-232, etc... SoundBlaster is just one of them. Not every SoundBlaster cards comes with an MPU emulation (that is, this thing that make it looks like it is an MPU, but actually forwards re-wrapped bytes to the SB DSP). Some do not have this MPU interface (v1.x and v2.x IIRC), while other expose it but in buggy ways. If one uses a SB card to emit MIDI data to an external synth, it makes more sense to use its native DSP interface (/sbmidi) instead of going through the MPU hoops.

Very intersting, I never understood too well how was going the midi output of the soundblaster. All I got was a sbpnp32 and used it's midi out to control a mt32 and that's as far as I go. I remember when I was a kid always in big questionning "should I use the mpu401 from the guspnp or the awe32?" 😉