VOGONS


MIDI input patch

Topic actions

First post, by Srecko

User metadata
Rank Member
Rank
Member

I finally got to finishing the MIDI input support that I started in early 2007.
Location:
http://sourceforge.net/tracker/index.php?func … 551&atid=467234

Please test it if you have interest in midi input functionallity (but also GUS and SB MIDI output).

Changes:
-alsa and win32 midi input (sysex and MIDI)
-subsctiption port created for Alsa sequencer, in addition to trying to connect to a specified input port
-refactored midi configuration code (midi input/output config is separate, and few more options)
-added midi.h header which contains all common midi functions
-all devices output to their own channel handled by midi.cpp (later merged to a same host port)

-GUS UART MIDI input and output (GUS had plain serial port UART chip on board for that)
-SB UART MIDI input and output (uses SB DSP input buffer and SB IRQ)
-SB16 MIDi input (via port 330/1, active when intelligent=false)

-largely rewritten MPU401 intelligent mode code (reference tables, restructuring of code, few bugs corrected...)
-input in intelligent mode: tested on Ballade, Prism, Texture and Midisoft recording session (win 3.11fw)
->mode for synchronisation to external midi clock
->metronome sound generator
->MIDI through channel (not captured)
->separation of realtime and normal messages (for capturing MIDI)

missing/TODO:
-system/realtime messages on Alsa
-midi input for mpu401 uart mode with running on irq 2/9 (now pure uart mode will call SB16 irqs)
(if you know any app that uses this, let me know)
-sb uart timestamps (now they're set to 0, not used by apps AFAIK)
-add API dependant hook to use port 331 TX status throttling (AFAIK not possible on win32, but might be with Alsa)
-implement alsa rawmidi backend (maybe).
-try to create build integrated with the MT-32 latency patch (by a request)
-test if sysex input works (only limited testing for now)
-improve metronome: and check that minor/major tick dfference is audible enough
-add forwarding of various midi channels (gus,sb,mpu401 and midi through) to different midi output ports?
-improve input device autodetection

To activate, please put a device number to inconfig parameter, and in midioptions one of: inputgus, inputsbuart,inputmpu401 or inputauto

I mostly tested it using Renoise and MIDI Yoke, and vkeybd & timidity on Fedora 8.

Attached is a win32 VS2008 build (should require pdcurses.dll, SDl.dll, SDL_net.dll, maybe also libpng and zlib, and probably VS2008 c++ runtime files).

Attachments

  • Filename
    db_midiin_06_01_08.zip
    File size
    934.17 KiB
    Downloads
    945 downloads
    File license
    Fair use/fair dealing exception

Reply 1 of 60, by janfry

User metadata
Rank Newbie
Rank
Newbie

Hi.

First of all, thanks for the patch.

I've used the patch in Windows XP, DosBox 0.72 and with Prism Sequencer.

If I press the Record button playing the song from the beginning, all is OK.
However, if I play the song from another location, not the beginning, when I press
the Record button the playing song stops and nothing is read.

I use in the config file:
inconfig=0
inmidioptions=inputmpu401

I have a sound blaster live! 5.1 digital.

Any ideas?

Thanks,

Janfry

Reply 4 of 60, by dbarton

User metadata
Rank Member
Rank
Member

I am using the TESTMT32 patch from DVWJR which is talked about here a lot, and fixes the MIDI output issues I had.

I'm wondering if any of the fixes are yet included in your version so I can have MIDI in *and* working MIDI out now?

Reply 5 of 60, by Srecko

User metadata
Rank Member
Rank
Member

The input patch doesn't change how midi output works (aside that because of some refactoring in midi.cpp it could require a manual merging of patch chunks for that file).
I haven't been looking at MT32 patches though. So nothing yet.

Reply 6 of 60, by dbarton

User metadata
Rank Member
Rank
Member

Much appreciated. Just a reminder that in my case Im not actually using an MT32. I use a music sequencer called Sequencer Plus.

The issue I had is that If I have a note that is held constantly and pitch bend messages are sent thru the duration of the note, the bend messages seem to be corrupted.

Also, in some cases solo notes overlapping will get stuck.

I do notice that in both cases if I just send some 16th notes to nowhere, it alleviates the problem.

The other bug is that the MIDI time clock being sent is *very* inconsistent. Internal timing seems great - it's only the actual clock signal being sent out that is all over the place.

I tried the TESTMT32 patch which Im told was:
"really just a minor bug fix made in the Dosbox v0.70 function: MIDI_RawOutByte() from the MIDI.CPP file in the course of adding SYSEX timing delays for Roland MT-32 rev00 synths. Many games of the late 1980s and early 1990s used the Roland MT-32, with many models being the revision 00 that needs around 48 milli-seconds delay between successive SYSEX strings. Even though games would not transmit real-time MIDI bytes, I thought that these MIDI bytes should be properly handled" was correct. 😀

This was from DWJR, and has completely solved all the output timing issues, and I have used it for all this time very happily. I'd love to have MIDI input available, so am very excited about your patch and his someday being both available in DOSBOX..

Reply 8 of 60, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Why would it be?

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 10 of 60, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I don't know. Tell me.

how witty...
if you don't know a reason why it should be added to CVS why did you ask it then?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 13 of 60, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

one of the biggest problems with dwjr's patch is that there is no patch. Only compiled executables.

Water flows down the stream
How to ask questions the smart way!

Reply 14 of 60, by valnar

User metadata
Rank Oldbie
Rank
Oldbie

OK, well that makes sense. Would it not be an advantage to DOSBox in general? Has anyone asked him for a patch?

Just curious... I didn't mean to stir up a hornet's nest. It sounded like something that can only benefit DOSBox, with no detriment.

Reply 16 of 60, by Srecko

User metadata
Rank Member
Rank
Member

janfry: So I decided to give it a try, but I am not able to reproduce your issue. How exactly to record from a different location in Prism?

dbarton: Which version of sequencer plus are you using? There is downladable "Gold" version, but this one uses UART mode. Anyway I'm completely confused with the interface of this program 😀

Didn't even notice that mpu rev 000 patch source was actually never released. I'm not even sure how it helps with erratic timings. Maybe windows midi stack copes when bursts of data are handed out to it too fast (would like to know how it is with ALSA or OSX API when they send to a real midi output). Second possibility is that dosbox thread execution is unpredictably delayed while being briefly blocked in win32 midi calls. In that case a fix is to put those calls in a separate thread and have a FIFO buffer between (probably what rev000 patch does).

Reply 17 of 60, by dbarton

User metadata
Rank Member
Rank
Member

I'm completely happy to work with you in any way I can to help you get Sequencer Plus running. It's quite simple actually..

It uses intelligent mode by loading a driver which should be in the download you have. The MPU401 driver is called vapimpu.

A good batch file to launch SPGold might look like:

vapimpu
spg.exe /res:1 /rows:41

(the /res:1 will speed up loading a lot)

I'm happy to talk via phone or email to make it a bit easier for you, and I hopefully have extra clues to help you any I can..

Reply 18 of 60, by Srecko

User metadata
Rank Member
Rank
Member

I checked and sequencer plus actually uses UART mode. Only the driver, at loading, checks if there is intelligent mode, but later sequencer just sets UART mode with 0x3F and that's it.

Does this app support midi input from mpu401? If yes, it is a first test case that uses mpu401 IRQ to input in UART mode.

So, the corruption problem appears not to be related to the intelligent mode implementation.

Does it happen only with rev 000 patch, or also with "stock" 0.72, or even with the midi input patch? Do you have corruption when you configure, for example, MS GS synth as output device?

Reply 19 of 60, by dbarton

User metadata
Rank Member
Rank
Member

Yes, in real DOS you chose the driver, and then it supports input and output from that driver, so yes full MPU401 support. (This was the premier MIDI sequencer at the time and sold over a million copies.) You can also choose Sound Blaster driver instead and that seems to also work with DosBox.

>Does it happen only with rev 000 patch, or also with "stock" 0.72, or >even with the midi input patch? Do you have corruption when you >configure, for >example, MS GS synth as output device?

It fails with stock 070 which I first tried, but then the testmt32 patch fixed it very well, so I use that. That is a modified .70. There has never been an update to testmt32 for .72. I checked with the author of the testmt32 patch and he said that no changes were made to 072 that would affect my problems, so I'd have the same issues with .72. I did not try your input patch as you told me it *only* affected input. While I'd love to have MIDI input, for my needs stable output was more vital, so I've held off.

For the most part the timing issues are with sending real time messages such as midi clock or pitch bend. Mix those with note messages and it's a mess.

If I have a note that is held constantly and pitch bend messages are sent all thru the duration of the note, the bend messages get corrupted.

Also, in some cases solo notes that overlap will get stuck.

I did notice that in both cases if I just send a bunch of dummy 16th notes to nowhere, it reduced the problem.

The other bug is that the MIDI time clock being sent is *very* inconsistent. Internal timing seems fine - it's only the actual MIDI clock signal being sent out that is all over the place. Note placement dramatically affects the midi clock, which makes no sense at all.

I asked for some clarification at the time, and the gist of the fixes in testmt32 that works so well seemed to be that the DosBox MIDI code works as long as everything is purely sequential - that is every byte is either part of a MIDI SYSEX message or a MIDI channel message.

My understanding if is that if a "real-time" one byte MIDI message comes through, it gets one of three outcomes:
1 it gets treated as and end of SYSEX (EOX) and is lost.
2 it aborts any currently assembling MIDI_CHANNEL_MSG and is sent instead.
3 it comes at the right 'time' and is sent out normally.

I was told that the testmt32 change dealt with real-time MIDI bytes without interfering with any in-progress SYSEX_STRING or MIDI_CHANNEL_MSG.

I was hoping that dvwjr would hop in with a response, but I think he is not currently available to be involved.

I hope this is helpful!