OK, I didn't realize that you send actual 0xF8 (midi clock) messages out. that can certainly create problems with dosbox if your sequencer interrupts normal midi or sysex with realtime msgs.

Here is description how realtime midi (0xF8-0xFF) should be handled: http://www.cotse.com/dlf/man/midi/realtime.htm
I partially took care of this in the input patch, but only for intelligent mode, so it won't apply to UART mode.
(also it's fun to slave dosbox's mpu401 clock to external MIDI software that sends midi clock 😎 )

But that is not hard to fix for UART mode. midi.cpp handler needs a check to detect realtime commands (>=0xF8 single-byte writes) and that's it.

Your pitch band msg problems are probably a repercussion of above. Pitch band messages aren't (to my knowledge) realtime messages,
so they shouldn't be sent in the middle of sending midi message.

Here's an attempt to correct above problem (and also help in case when realtime message corrupts the midi capture file 😁 ). So, RFC :

midi.cpp

1static struct {
2	Bitu status;
3	Bitu cmd_len;
4	Bitu cmd_pos;
5	Bit8u cmd_buf[8];
6+	Bit8u rt_buf[8];
7	struct {
8		Bit8u buf[SYSEX_SIZE];
9		Bitu used;
10	} sysex;
11	bool available;
12	MidiHandler * handler;
13} midi;
14
15void MIDI_RawOutByte(Bit8u data) {
16+	/* Test for a realtime MIDI message */
17+    if (data>=0xf8) {
18+         midi.rt_buf[0]=data;
19+         midi.handler->PlayMsg(midi.rt_buf);
20+         return;
21+    }
22	/* Test for a active sysex tranfer */

>Pitch band messages aren't (to my knowledge) realtime messages,
>so they shouldn't be sent in the middle of sending midi message.

I think pitch bend are "CHANNEL VOICE" messages.

Not quite sure then if pitch bend counts as 'real time', but musically it's normal to hold a note on, or a few notes, and then bend them before releasing.

Bends are held thru clock messages as well.

My sequencer isn't sending any sysex at all. I'd imagine that's currently troublesome too, so never tried that.

Yes, but MIDI uses a separate message for "note on" and "note off", and pitch band is just sent between those two.

Then there is also MIDI "status"(which is also preserved even if there is a realtime messages between two notes). MIDI status means that you can omit first byte of the message if previous message had the same first byte (that one is always >0x7F and encodes MIDI message type and channel, others bytes are always < 0x7F ). Reciever should recognize this and remember the missing byte. I guess it was convenient to save midi bandwidth in the 80's 😈

Very nice.

Is this already set for us to test? I'm not clear what that .CPP file is for.. \ (I'm hoping that there will be some .exe created to try out.)

One last thing dvwjr told me a few months back.. Not sure if it helps you in any way, but just in case:
"The fix for your MIDI timing problem was not MIDI status byte related.."

Thanks for looking at this !!!
Exciting!

It's not (only) midi status related.

.cpp is source, of course. Try this build, it contains midi input patch, above change, and cakewalk fix.
(source files changed from the last midi input patch version are in the archive).

I'm now downloading MS Visual Basic.. Am I right in guessing that I need to install that to get the runtimes I need?

I'm not at all familiar with the develop environment for DosBox or what I need to do to get an EXE.

You can download the runtimes here

2008: http://www.microsoft.com/downloads/details.as … &displaylang=en

2008 SP1 : http://www.microsoft.com/downloads/details.as … &displaylang=en

Ok, first report is that it does seem to work, which is very nice!

I loaded .070 and this new .72 on this same test machine, and this is MUCH better than .70!!!

I did direct comparisons between the 070 & 072 versions:
The send clock timing does not jump all over now. Steady.
The note timing with pitch bend is MUCH better.
The MIDI input seems to work as well, but as far as I can tell it does not recognize pitch bend messages as input. Is that correct? Seemed like it choked a little bit on input, but more testing needed.

I can't run this on the production machine, so have not done a direct comparison to testmt32 version to see about timing, but I *think* this version musically 'feels' a tiny bit sloppy. Could any of that be that I'm running the non compiled version with runtimes?

(Also, this test machine is not as good as the production machine, so that may be part of it.)

I do need to test more to try and see if overall timing feel is good, but so far a great improvement!!!

Much appreciated.

OK, here is a build which is identical except that the patch I posted here isn't included. If you will have timing and corruption problems with this build (as I expect), then we found the problem and I will post a formatted patch against CVS version and propose inclusion in CVS.

Regarding input testing, I will be able to test midi input with sequencer plus myself (not immediately though) before I post again with results and improvements. Also this is debug build, maybe it's 'sloppier', but no idea 😐

You might not want to use debug builds where timing is important. I have found the debugger creates some problems. Callbacks (DOSBox's internal replacement for some software interrupts), cause the timer to lose ticks, and the more often they are called, the worse the effect. As an example, playing in Cakewalk is at about half normal speed using a debug build, and its timing is normally very precise.

Ok I tried this .72 that you just sent using identical setup, only changing the exe. Timing problems back in that one, so your patch is very good so far.

By the way both versions say "SOUNBLASTER:raising IRQ" fairly often. Maybe a bit more often during pitch bend messages?

Looking forward to a normal .exe so I can do some serious timing tests.

Maybe it defaults to sound blaster based midi input for your application (sb uart). Try with
midioptions=inputmpu401
in the midi section of dosbox.conf (other options are inputsbuart, inputgus and inputauto). SB16 input mode (as far as I remember 😁) is on only if intelligent mode of mpu401 is off, as they use same port but different mechanism (different IRQ) for input.

I will post non-debug version of the build this weekend for more serious input tests. In the meantime, since we obviously found the problem, I'm posting the patch which can safely go to CVS (it improves midi handling to what's specified in MIDI protocol).

I just changed sbtype to none and the message went away.
I am actually using MPU401, so I guess they were both switched on.

These are the settings I have had on the whole time as well, just FYI.
[midi]
mpu401=intelligent
device=win32
config=
inconfig=0
inmidioptions=inputmpu401

This last line is not what you just wrote to me now, but is taken from an earlier message. Should be 'inmidioptions' as I have it, not 'midioptions', correct?

midioptions is correct. It's that way in latest iteration of the patch (that's on sf.net).

Right, if mpu401 is configured to intelligent mode, but program initializes uart mode, input will be triggering first mpu401 irq and then a sb16 irq, displaying your message.

Although it isn't practically a problem because default int handler(s) will do nothing, I think I will disable sb16 input mode when mpu401 is preconfigured as intelligent and do the opposite when it's uart (after all, the dual irq could never happen on real hardware).

ok changed to:

mpu401=intelligent
device=win32
config=
inconfig=0
midioptions=inputmpu401

So is next step is for me to test improved MIDI input whenever you are ready?

thnx

A non-debug build to test for timing (and everything else). Have fun.

Also includes a cleanup of some parts mpu401 code and at few other places. Also locking scheme for input got improved, it is always good to be careful with that stuff (especially as it's harder to debug).

I also noticed a minor problem that appears sometimes in Texture, probably conductor related. But I got bored too much to dig into that ATM 😈

ok, will test it.

Can you elaborate a bit on the problem in Texture? Conducter is a Texture thing? It's be nice to know any little issues..

Also "locking scheme"? Not sure I follow what you mean there..

Conductor, used by many intelligent mode programs, allows to queue commands, like tempo change or turning on off various features, during playback.

You can try, in Texture, to turn the metronome "on" during playback and see what happens if you then stop and start. Second issue was that sometimes when I start the program, and open song for the first time, it plays but doesn't produce any midi and doesn't rewind at start/stop, until I reopen the file.
Could be of course that those are bugs in the Texture itself..(turning metronome on/off works normally with Prism for example).

Locking scheme: meaning thread synchronisation, used to disable parallel access to same data in cases when it could lead to corruption (like here when mpu401 internals and midi input want to write/read from to the same buffer). It's just a technical detail.

Ok, I will specifically turn metronome on and off and such to put SPG / DOSBOX thru it's paces.

So far, I was able to playback, record pitch bend, and use clock in *and* out. All looks good.

Not yet sure the overall tightness in timing, but I have some stricter tests I will do very soon.

added fixrtmidi.diff to cvs