VOGONS


MIDI input patch

Topic actions

Reply 20 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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

static struct {
Bitu status;
Bitu cmd_len;
Bitu cmd_pos;
Bit8u cmd_buf[8];
+ Bit8u rt_buf[8];
struct {
Bit8u buf[SYSEX_SIZE];
Bitu used;
} sysex;
bool available;
MidiHandler * handler;
} midi;

void MIDI_RawOutByte(Bit8u data) {
+ /* Test for a realtime MIDI message */
+ if (data>=0xf8) {
+ midi.rt_buf[0]=data;
+ midi.handler->PlayMsg(midi.rt_buf);
+ return;
+ }
/* Test for a active sysex tranfer */

Reply 21 of 60, by dbarton

User metadata
Rank Member
Rank
Member

>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.

Reply 22 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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 😈

Reply 23 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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!

Reply 24 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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).

Attachments

  • Filename
    midiin_rtpatched.zip
    File size
    1.06 MiB
    Downloads
    508 downloads
    File comment
    Build needs MS Visual Studio 2008 runtimes which are available (if not somewhere else) from VS Express 08.
    File license
    Fair use/fair dealing exception

Reply 25 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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.

Reply 27 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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.

Reply 28 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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 😐

Reply 29 of 60, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 30 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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.

Reply 31 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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).

Attachments

  • Filename
    fixrtmidi.diff
    File size
    386 Bytes
    Downloads
    462 downloads
    File license
    Fair use/fair dealing exception

Reply 32 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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?

Reply 33 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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).

Reply 35 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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 😈

Attachments

  • Filename
    midiin26Oct08.zip
    File size
    1.06 MiB
    Downloads
    709 downloads
    File license
    Fair use/fair dealing exception

Reply 36 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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..

Reply 37 of 60, by Srecko

User metadata
Rank Member
Rank
Member

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.

Reply 38 of 60, by dbarton

User metadata
Rank Member
Rank
Member

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.