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

what a patch srecko! thx vewy much!!! O-:

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

It goes again on the TODO list, so it will be examined when I'll have enough free time.

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?

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.

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

Has this been integrated into CVS yet?

Why would it be?

DosFreak wrote:

Why would it be?

I don't know. Tell me.

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?

He probably meant to ask why wouldn't it be.

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

Has DWJR's patch been included in DOSBox, and if not, why?

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

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.

Maybe give dwjr a nudge to up a patch if he's released a binary; gpl.

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

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

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?

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!