[Request] Support for MIDI input

[teimoso]

Description

I request that support for MIDI input for devices such as MIDI keyboards is added to DOSBox-X.
Since this is (probably) a demanding task with a small use-case, this may be more suited for a long-term goal (if considered at all).

Extra Information

An old DOSBox patch ⁽²⁰⁰⁸⁾ that adds MIDI input might prove helpful (but at that age, maybe not; it predates DOSBox 0.73).
Patch files and binaries at this VOGONS thread.
Patch files are also available at this SourceForge ticket. More organized than the VOGONS thread, but seems to be missing a couple of updates.

(June 06, 2019) A new version of the patch mentioned above was posted to VOGONS in May.

In favor of MIDI input

• Currently, there doesn't appear to be any usable method of MIDI input for MS-DOS programs without using a compatible version of Windows/DOS
  My searches for MIDI input on an emulated DOS system have been fruitless so far, leading me to believe that (at the moment) passable MIDI input support for DOS programs doesn't exist for any operating system that isn't Windows ME or older (therefore outing Mac OS X and Linux).
• Further support for music creation software (particularly important for AdLib)
  The amount of music composition software that can make AdLib music, runs on modern systems, and has MIDI input support is miniscule (as far as I know, only one program meets that criteria).

Against MIDI input

• Potential userbase is small
  Most users that need MIDI input support for creating music have their needs covered by newer software.
• Most DOS music creation software allow use of a regular keyboard
• Large undertaking(?)
  I am unfamiliar with development/programming involving MIDI, but I wouldn't expect that adding this feature would be easy.

[joncampbell123]

I'm not familiar with MIDI enough to implement this, however when I or anyone else does, I have an old copy of Cakewalk for Windows 3.1 that could be used to test this against.

[teimoso]

Some other music software that accept MIDI input are AdLib Visual Composer, EdLib (MPU-401 interface), Fasttracker II, and Sound Club (MPU-401, Gravis Ultrasound, and Sound Blaster interfaces).

If anyone's interested in implementing MIDI aftertouch & velocity, I know that EdLib and Fasttracker II support both (the other programs may or may not).

[heydojo]

Hi All,
Hopefully I can add something to the discussion here.

My use of the term "MIDI input" might be kind of inaccurate since I think some form of MIDI input is already used to support some MIDI synthesizers/sound cards (like MT-32 or GUS).

There is no MIDI input support emulated in MPU401 as far as I can tell in either DOSBox or Dosbox-X.

An old DOSBox patch (2008) that adds MIDI input might prove helpful (but at that age, maybe not; it predates DOSBox 0.73).

That patch is for a very old version of DOSBox, is around ten years old and consists of a three thousand line diff which constitutes a major rewrite of mpu401 emulation and there are also many changes to associated code.
Back porting the patch is some serious work and none trivial.

I have an old copy of Cakewalk for Windows 3.1 that could be used to test this against.

Some other music software that accept MIDI input are AdLib Visual Composer, EdLib (MPU-401 interface), Fasttracker II, and Sound Club (MPU-401, Gravis Ultrasound, and Sound Blaster interfaces).

The most interesting piece of software to want midi input support for is Voyetra's Sequencer Gold Plus. It was the tool of choice for Bobby Prince (the author of Doom's soundtrack among others.)

[teimoso]

There is no MIDI input support emulated in MPU401 as far as I can tell in either DOSBox or Dosbox-X.

Thanks for clarifying.
To specify, I thought a small portion of MIDI input (not necessarily MPU-401) was emulated so devices like the Gravis Ultrasound card could connect properly.

That patch is for a very old version of DOSBox, is around ten years old and consists of a three thousand line diff which constitutes a major rewrite of mpu401 emulation and there are also many changes to associated code.
Back porting the patch is some serious work and none trivial.

I mentioned it less as a suggestion for a back-port and more as a possible pointer towards how to start integrating MIDI input. Judging by your comments, though, it seems it doesn't have anything to contribute in that regard.
Should I remove its mention from the issue?

[heydojo]

To specify, I thought a small portion of MIDI input (not necessarily MPU-401) was emulated so devices like the Gravis Ultrasound card could connect properly.

Nope. I don't think so. And that patch set you linked not only adds the support to DOSBox for gus midi in but also sound blaster.
It's super difficult to merge into Dosbox-X because the midi system in Doxbox-X is very different to how DosBox was ten years ago.

I will also add that there are a few reasons the patch wasn't merged into DOSBox although one was not given on the issue tracker. I think the most relevant reply on the forum arrived in the form of the comment: "NO."

I mentioned it less as a suggestion for a back-port and more as a possible pointer towards how to start integrating MIDI input.

Yeah, it's easy for people to think that patches for DOSBox will just "drop in" to Dosbox-X and it's not always the case. And well there are two ways to go about adding midi input support: You are either familiar with the MPU401 emulation code in Dosbox-X, good at C++ and add the input code from scratch taking pointers from the linked patches and elsewhere or you attempt to back port the linked patch by carefully merging each change - the compiler output will tell you if you have errors.

Should I remove its mention from the issue?

Nah. I wouldn't say so. Do what you like.

The obvious issue against midi input in any version of DOSBox is that modern professional audio applications which support midi input already exist, you don't need to emulate them, they are years better than their DOS predecessors and run (if engineered and configured correctly) in real time.
Capturing input as close to real time as possible is extremely important when creating music.

Part of the difficulty includes the clock send and receive. Midi hardware devices can also be daisy chained.

[joncampbell123]

https://www.vogons.org/viewtopic.php?f=41&t=31881&p=680216#p680216

[heydojo]

https://www.vogons.org/viewtopic.php?f=41&t=31881&p=680216#p680216

Any idea what that patch is Jon?
At first glance it looks like a version of the patch @teimoso linked but approximately 1000 lines lighter and with (maybe) the contents of the new file midi.h included.

Do you know if the patch applies to Dosbox-X? Or is it another attempt at adding midi input to DOSBox in the past?

[joncampbell123]

I don't know yet, haven't tried to apply the patch yet.

The link is posted here as a reminder.

[heydojo]

I don't know yet, haven't tried to apply the patch yet.

I'm going to guess that the patch is a copy of the same patch which was available before the person working on it came back and finished it in 2008. I think I read that there were issues where the input would become erratic or drop. My guess is that the extra code adds the metronome and timing stuff which because they were missing, were the cause of some or all of the issues people were reporting.

This is all speculation of course. It would be interesting, if in the future anyone can confirm or deny it.

[teimoso]

It looks like a derivative of Srecko's patch surfaced about a month ago. I don't have an account on VOGONS, so I can't view the attachment(s), but maybe it could be useful?

[joncampbell123]

If someone wants to record MIDI with it, that's fine with me.

[noghiri]

The 2019 derivative of Srecko's patch is a diff just shy of 3000 lines. I'll try to get them to send it out this way, as I do have an account.
I'm not much of a programmer, but it seems to take the approach of adding the input code to the MPU401 emulation, as heydojo suggested. I'll experiment with the patch, and see what I can dig up.

To specify, I thought a small portion of MIDI input (not necessarily MPU-401) was emulated so devices like the Gravis Ultrasound card could connect properly.

Nope. I don't think so. And that patch set you linked not only adds the support to DOSBox for gus midi in but also sound blaster.

The 2019 patch does all three, but it seems to be using a generic midi library. How much that library handles, I don't know yet - I'm not versed in C++, and I'm not done giving myself a crash course.

The obvious issue against midi input in any version of DOSBox is that modern professional audio applications which support midi input already exist, you don't need to emulate them, they are years better than their DOS predecessors and run (if engineered and configured correctly) in real time.
Capturing input as close to real time as possible is extremely important when creating music.

Sequencer Plus Gold has a better workflow than most modern programs I've used for midi sequencing, and supports a step input mode that I've wanted to exist for a long time and only just recently discovered. If any modern DAWs support that mode, I've not found one yet.
Step input has the advantage of being not particularly latency sensitive.
That said, my current workflow has the old software feeding into a modern DAW, because modern DAWs are better for literally every other thing you could think of.

[cambertian]

I'm mostly interested in this feature due to an inability to get compositions off of my Roland PMA-5 without using an old Windows 3.1/95 application that only accepts MIDI input. It's niche, but the need is there.

[joncampbell123]

If there are any other good DOS/Windows 3.1 programs to test MIDI input, please list them here.

[noghiri]

For just testing, MIDIMON was one of the go-tos from what I've read - it should report all the messages it receives, and that should be useful for development. Audio Simulation AudioSim, an early software synth, may also work for testing, but I don't have a copy.

the 2019 patch doesn't apply without modification, but that wasn't exactly unexpected. Notably, it also doesn't completely line up with Dosbox's SVN - the diff references changes to a midi.h, and that doesn't exist in the version that the patch author says they tested it on, unless I'm missing something obvious.

[Deftaudio]

I just second that I'm still very interested in the MIDI input. However MIDI Output timings are awful, - checked with MIDIGal, this makes Voyetra currently unusable with Dosbox even for the output only.

[landloafer]

There are some DOS based utilities hosted by a group of MT32 hobbyist.

http://www.midimusicadventures.com/queststudios/mt32-resource/utilities/

[pokemon099]

I use DOSBOX 074-2 to play music with the DOS software SEQUENCER PLUS GOLD by VOYETRA.

Works #1 for playback but would love to build songs with it if there was the MIDI IN option.

[wyatt8740]

The obvious issue against midi input in any version of DOSBox is that modern professional audio applications which support midi input already exist, you don't need to emulate them, they are years better than their DOS predecessors and run (if engineered and configured correctly) in real time.

Is that obvious, though?

I have yet to find a good way to create D-50 and MT-32 patches on a modern Linux machine. I'm certain there are other "classic" MIDI synthesizers that are in a similar situation.

Wine can't run LA-Synth (some floating point exception in 16-bit code creates a stack trace that contains no debugging symbols, just hex addresses and I don't even know where to begin), Dr. T's MT-32 can't support MIDI in in Dosbox/Dosbox-X, I don't see any obvious method for interfacing an ALSA midi device with QEMU, and JSynthLib's code for the MT-32 is only partially functional: you can create patches, but you can never save them/export them. Support for banks is also incomplete, the program's written in Java (so I don't want to touch it), and it's not been updated in about 16 years.

The only thing I've been able to make work at all is emulating an Atari ST and using a D-10 editor for it (the Caged Artists MT-32 one is corrupted or something; claims it's not got enough memory even when maxed out). And to even do that, I need to do a lot of magic with the snd_virmidi linux driver to allow simultaneous access from the host and the emulator, so it isn't usable with other operating systems at all.