MIDI input patch

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

MIDI input patch

Postby Srecko » 2008-1-07 @ 19:27

I finally got to finishing the MIDI input support that I started in early 2007.
Location:
http://sourceforge.net/tracker/index.ph ... tid=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
db_midiin_06_01_08.zip
(934.17 KiB) Downloaded 909 times
Srecko
Member
 
Posts: 466
Joined: 2003-9-08 @ 15:03

Re: MIDI input patch

Postby janfry » 2008-8-25 @ 10:18

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
janfry
Newbie
 
Posts: 3
Joined: 2008-8-19 @ 07:41

Re: MIDI input patch

Postby lightmaster » 2008-8-25 @ 17:53

what a patch srecko! thx vewy much!!! O-:
Image
User avatar
lightmaster
Oldbie
 
Posts: 605
Joined: 2005-10-01 @ 12:09
Location: Sol III(¡¿

Re: MIDI input patch

Postby Srecko » 2008-8-30 @ 16:47

Uh, I played with Prism (demo version only), but obviously it's still buggy :blah:

It goes again on the TODO list, so it will be examined when I'll have enough free time.
Srecko
Member
 
Posts: 466
Joined: 2003-9-08 @ 15:03

Re: MIDI input patch

Postby dbarton » 2008-9-09 @ 02:00

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?
User avatar
dbarton
Member
 
Posts: 142
Joined: 2005-2-10 @ 05:22

Re: MIDI input patch

Postby Srecko » 2008-9-09 @ 15:14

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.
Srecko
Member
 
Posts: 466
Joined: 2003-9-08 @ 15:03

Re: MIDI input patch

Postby dbarton » 2008-9-09 @ 18:25

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..
User avatar
dbarton
Member
 
Posts: 142
Joined: 2005-2-10 @ 05:22

Re: MIDI input patch

Postby valnar » 2008-10-15 @ 17:36

Has this been integrated into CVS yet?
valnar
Oldbie
 
Posts: 640
Joined: 2002-7-17 @ 13:50

Re: MIDI input patch

Postby DosFreak » 2008-10-15 @ 17:45

Why would it be?
Game Acronym List
DosBox CVS Builds
DosBox Feature Request Thread
DosBox FAQ
PC Game Compatibility List
"Who's got time to read all the way down to the bottom of an email?"
User avatar
DosFreak
l33t++
 
Posts: 9540
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: MIDI input patch

Postby valnar » 2008-10-15 @ 19:00

DosFreak wrote:Why would it be?


I don't know. Tell me.
valnar
Oldbie
 
Posts: 640
Joined: 2002-7-17 @ 13:50

Re: MIDI input patch

Postby Dominus » 2008-10-15 @ 22:29

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?
User avatar
Dominus
DOSBox Moderator
 
Posts: 7381
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: MIDI input patch

Postby ih8registrations » 2008-10-16 @ 00:22

He probably meant to ask why wouldn't it be.
ih8registrations
Oldbie
 
Posts: 931
Joined: 2003-7-25 @ 17:20

Re: MIDI input patch

Postby valnar » 2008-10-16 @ 11:44

Yes, of course that is what I meant. Thanks.

Has DWJR's patch been included in DOSBox, and if not, why?
valnar
Oldbie
 
Posts: 640
Joined: 2002-7-17 @ 13:50

Re: MIDI input patch

Postby Qbix » 2008-10-16 @ 11:59

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!
User avatar
Qbix
DOSBox Author
 
Posts: 10448
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: MIDI input patch

Postby valnar » 2008-10-16 @ 12:29

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.
valnar
Oldbie
 
Posts: 640
Joined: 2002-7-17 @ 13:50

Re: MIDI input patch

Postby ih8registrations » 2008-10-17 @ 00:36

Maybe give dwjr a nudge to up a patch if he's released a binary; gpl.
ih8registrations
Oldbie
 
Posts: 931
Joined: 2003-7-25 @ 17:20

Re: MIDI input patch

Postby Srecko » 2008-10-20 @ 22:53

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 :happy:

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).
Srecko
Member
 
Posts: 466
Joined: 2003-9-08 @ 15:03

Re: MIDI input patch

Postby dbarton » 2008-10-21 @ 00:07

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..
User avatar
dbarton
Member
 
Posts: 142
Joined: 2005-2-10 @ 05:22

Re: MIDI input patch

Postby Srecko » 2008-10-21 @ 18:18

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?
Srecko
Member
 
Posts: 466
Joined: 2003-9-08 @ 15:03

Re: MIDI input patch

Postby dbarton » 2008-10-21 @ 19:03

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!
User avatar
dbarton
Member
 
Posts: 142
Joined: 2005-2-10 @ 05:22

Next

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests