VOGONS


First post, by Ozzuneoj

User metadata
Rank l33t
Rank
l33t

I posted about about this in another thread here but figured it'd be worth its own thread if this is something that is common on other Roland GM\GS modules. I have a rather rare MT-200, which is apparently very similar to an SC55 but is more focused on being able to record\remix music tracks using its built in floppy drive. After a little tinkering I figured out how to make it useful as a simple sound module for my PC. But I've noticed that I'm getting some incorrect sounds when playing GM music through it. I'm testing with the Descent sound setup program, simply by hitting enter to start and stop the music test. My PC is a K6-2 500 and the MIDI data is coming through a Midiman MM401.

Basically, it sounds like reverb effects get stuck on some times, or the track will start with notes (the distorted guitar at the beginning) dragging on like they are being held too long or are STILL playing from the last time (even though the track has stopped and there's silence before it starts), or a long note will hang for the entire song. It seems to mostly do this when I stop and restart the track. I have a 3 way AV switch hooked up between the MT200, SC7 and MT32. I can flip through them back and forth (they are all getting the MIDI signal simultaneously) and only the MT200 has these problems. I have my midi devices daisy chained through the "THRU" ports as follows: Midiman MM401 -> MT200 -> MT32 -> SC7... so the MT200 also has the least amount of cabling\devices between it and the source and yet it is the only one to have these issues. It also doesn't go away if I disconnect the device from the MT200's THRU port.

It would seem that it HAS to be something specific to the device, as the problems are happening on it alone and aren't being passed on to the others. Turning it off and turning it back on fixes the problem... until it happens again, either by stopping and restarting a track, or if a certain note happens to get stuck playing.

I don't know if this is just a side effect of the device doing its own thing, intended for recording\remixing tracks, or if it is actually faulty.

I will say, this is a really cool device but I get the feeling it wasn't ever totally meant as a stand alone midi sequencer, attached to a computer. It is definitely more geared toward actually using it for recording, cutting and mixing tracks using the floppy drive.

I got it for a really good price and it seems to be worth quite a bit on eBay, but I'd probably trade it for a nice SC-88 or SC-55MKII. I am interested in composing music at some point, but I'm certainly going to be using modern MIDI software on my PC for that.

Has anyone ever experienced the GM playback problems I've mentioned above?

Now for some blitting from the back buffer.

Reply 1 of 4, by PhilsComputerLab

User metadata
Rank l33t++
Rank
l33t++

Hmm the only thing that sticks out is the fast processor. This might be causing issues with the ISA cards.

What can do is go into the BIOS, disable L1 cache, then boot into DOS and try again. The machine will be slowed down significantly, so try not to boot into Windows, it will take a long time...

The other thing you can do is try another modern MIDI interface. Like a USB MIDI interface, or a joystick port on a Live! Just download the MIDI files and play them with a media player for example.

YouTube, Facebook, Website

Reply 2 of 4, by Ozzuneoj

User metadata
Rank l33t
Rank
l33t
PhilsComputerLab wrote:

Hmm the only thing that sticks out is the fast processor. This might be causing issues with the ISA cards.

What can do is go into the BIOS, disable L1 cache, then boot into DOS and try again. The machine will be slowed down significantly, so try not to boot into Windows, it will take a long time...

The other thing you can do is try another modern MIDI interface. Like a USB MIDI interface, or a joystick port on a Live! Just download the MIDI files and play them with a media player for example.

Thanks. I can try this, but wouldn't the problems exist on all three midi modules if it were the source? I can literally flip a switch between the audio output of the sc7 and the mt200 to hear them back to back and the mt200 will repeatedly have artifacts where the sc7 never does... And the sc7 is connected to the MT200's THRU port, so they are getting the same data the same time.

Now for some blitting from the back buffer.

Reply 3 of 4, by Ozzuneoj

User metadata
Rank l33t
Rank
l33t

Just wanted to ask the question from my previous post again.

Can CPU speed issues effect one external MIDI module without effecting another? I always assumed that CPU speed problems related to MIDI were created by the MPU401 interface (in this case an MM401), which would cause the issues to be present on anything connected to that interface. In this case, I only have issues with one device. The rest are fine.

Any input is appreciated. 😀

Now for some blitting from the back buffer.

Reply 4 of 4, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie
Ozzuneoj wrote:

Just wanted to ask the question from my previous post again.

Can CPU speed issues effect one external MIDI module without effecting another? I always assumed that CPU speed problems related to MIDI were created by the MPU401 interface (in this case an MM401), which would cause the issues to be present on anything connected to that interface. In this case, I only have issues with one device. The rest are fine.

Any input is appreciated. 😀

What happens if the MIDI devices are swapped in the chain? Now you have the failing unit connected as last, into the MIDI THRU of first unit? Because, every time a signal passes from MIDI IN to MIDI THRU, there is a slight degradation in the signal (unless the MIDI bytes are received and retransmitted with UART, but it never is, it is just electrical pass through). So if still the same unit fails and the next unit still works, then the MIDI IN and THRU paths are OK, and it's something internal in the failing unit.

Another thing is that back when CPUs were slower, they could not send data so fast. I mean, the CPU has to poll if the MIDI UART is ready for another byte, and then send it. When CPUs are faster, they can just do that faster, so the gap between bytes on MIDI wire is shorter, and maybe your failing MIDI synth can't receive continuous back-to-back byte stream if it has too slow CPU.