^ oh! spooky! 😁
thanks for your support!

You are welcome. 😀 I am grateful to have stumbled upon them after missing the first run of the green boards while lurking on and off here. I've been wanting MPU cards for a long time. DOOM/DOOM 2 sound so amazing on the Sound Canvas.

yes it is true - once you go quality midi you can't go back! It was the same for me as well, games just become way more enjoyable!

Just an update, I received jheronimus's card this morning and I confirmed the issue was a semi-dead Z8.
For simple stuff (like Hocus Pocus music for example) it worked fine, when you went to "heavy" mt-32 usage then it started lagging or something. I replaced it and all was good again. Will keep this card for archival reasons since I did not have any of these early wavetable versions 😀

Are there any instructions on how to set this card up -- I have one but haven't really tested it yet. I.e. jumper settings for address, irq, etc. I assume it's all jumper configured?

doaks80 wrote:

Are there any instructions on how to set this card up -- I have one but haven't really tested it yet. I.e. jumper settings for address, irq, etc. I assume it's all jumper configured?

http://www.mediafire.com/file/h7qh5c15hz8ft3g … age_v2.zip/file

😎

In short: the default base address is 330h and the default IRQ is 2 (but on some machines, IRQ2 may be troublesome, so you might be better off using one of the alternatives, such as 3, 5 or 7).
You don't need to install any drivers or load any utilities or anything. Just configure your software to use an MPU-401 interface, and you're done.

keropi wrote:

doaks80 wrote:

Are there any instructions on how to set this card up -- I have one but haven't really tested it yet. I.e. jumper settings for address, irq, etc. I assume it's all jumper configured?

http://www.mediafire.com/file/h7qh5c15hz8ft3g … age_v2.zip/file

😎

Thanks 😁

Possible interested people contact me about availability for these cards.

😀

Scali wrote:

In short: the default base address is 330h and the default IRQ is 2 (but on some machines, IRQ2 may be troublesome, so you might be better off using one of the alternatives, such as 3, 5 or 7).
You don't need to install any drivers or load any utilities or anything. Just configure your software to use an MPU-401 interface, and you're done.

Conflict with ACPI?

A little toggle on the top of this card that switches between port 300/330 would have been very useful. I have it next to another card with onboard midi, but many, many games are hardcoded to 330, meaning I have to leave this card at 330 if I want to use it with them. The other card is software configured but i can't set it to 330 while this card is on it. It would be perfect apart from this.

doaks80 wrote:

A little toggle on the top of this card that switches between port 300/330 would have been very useful.

You can connect a simple switch to the jumper header on the card, so it should be very easy to make your own. You could even connect it to the turbo switch on your case for example.

gdjacobs wrote:

Conflict with ACPI?

Nah, I had the problem on a 286. And I also have a Commodore PC20-III that generates IRQ2s, I think because of the onboard mouse controller. Pretty sure it won't work there either.

Scali wrote:

doaks80 wrote:

A little toggle on the top of this card that switches between port 300/330 would have been very useful.

You can connect a simple switch to the jumper header on the card, so it should be very easy to make your own. You could even connect it to the turbo switch on your case for example.

Good idea, I might try that!

Since I have accumulated (too much?) MIDI gear, I decided to hook them up through an 8-port MIDI "patchbay". In doing so, I noticed for the first time that this card is flooding MIDI realtime messages constantly as its default behaviour, presumably the MIDI clock. I can't seem to find a way to turn this off, e.g., running mqreset.exe doesn't help. Is there any way to disable this programmatically?

Arkku wrote:

Since I have accumulated (too much?) MIDI gear, I decided to hook them up through an 8-port MIDI "patchbay". In doing so, I noticed for the first time that this card is flooding MIDI realtime messages constantly as its default behaviour, presumably the MIDI clock. I can't seem to find a way to turn this off, e.g., running mqreset.exe doesn't help. Is there any way to disable this programmatically?

This is a non-issue and basically the way it is supposed to be as per midi protocol standards, the mpu is a master device so clock is always ticking to sync slave (=midi modules) devices.
mqreset resets other things (like metronome settings for example) it does not cause the mpu to shutdown.

keropi wrote:

This is a non-issue and basically the way it is supposed to be as per midi protocol standards, the mpu is a master device so clock is always ticking to sync slave (=midi modules) devices.

Well, it can be an issue when multiple computers are connected through a patchbay/merger to the same devices, in which case their clocks also get merged an thus multiplied. Also, the clock isn't required anywhere in a MIDI system by the MIDI standard, and if one wants to treat the MPU as a MIDI interface rather than a "master" in its own right, then it should be the MIDI software that sends the clock (or doesn't), so in that sense if the clock is truly forced to be always sent this is less flexible than a "dumb" MIDI interface.

Anyway, I set up the patchbay to block MIDI realtime messages from the MPU to remove the practical issue of having multiple clocks merged, but of course this means that I need to change that setting if I ever actually want to send the clock (or other realtime messages). However, I'm not entirely convinced that there wouldn't be a software solution… e.g., the early PC music making software with their internal MIDI clock, I find it hard to believe they would all either be incompatible or have to support this device specifically.

Arkku, you cannot have 2 masters, only 1, if you want to make PCMIDI as slave you need to disconnect midi out from it. Please read MIDI protocol, clock section, some devices do have this behavior. Protocols are standard and cannot be changed.

Please do not confuse hardware connection clock signals with software ones, that's not how things work.
Clock is required in hardware level in the midi protocol so devices sync. And since the mpu is the one sending data to other devices it IS the master in the chain, there is no such thing as treating it as a "midi interface" instead of a master this does not exist. Clock will always be present no matter what, just like other ports in your computer. If the clock is causing issues in your setup and you want to send data to the mpu then just disconnect the OUT cable - but this shouldn't be an issue to begin with, it's not a PCMIDI-only thing that's how all mpu interfaces work no matter the platform/make.

I have the feeling you are confusing the software side of things with the hardware side, see here: http://www.gweep.net/~prefect/eng/reference/p … l/midispec.html
Pretty sure you are confusing "Hardware" on the beginning and "MIDI Clock" later on the midi messages section, these two are different.

Just get a midi input selector for your patchbay , there is a reason Roland made several midi thru/switch boxes back in the day for use in midi networks, this way you'll flick a switch/button and chose sources if your device can't do that easily and needs tedious configuration each time.

If your goal is to have several modules that need to work with more than one computer then all you needed was a midi selector and thru box. All midi modules connect to the thru box, the thru box INPUT connects to the input selector's OUTPUT and your computers connect to the midi selector INPUTS.

keropi wrote:

Please do not confuse hardware connection clock signals with software ones, that's not how things work.
Clock is required in hardware level in the midi protocol so devices sync.

I'm sorry, but this is just plain incorrect. As a warning, this is going to be a long post, but I hope it will be interesting to people into MIDI-based equipment in general. For background am very familiar with the MIDI standard, as I have tinkered extensively with MIDI synthesizers (i.e., the stand-alone type, not PC), including programming MIDI implementations for microcontrollers.

To clarify, let's start with the MIDI protocol specification from https://www.midi.org/specifications-old/item/ … 0-specification (which I have read several times over while implementing MIDI stuff). The clock is first introduced along with other realtime messages. Note that already the second passage here notes that they are "normally ignored by keyboard instruments and synthesizers".

The MIDI System Real Time messages are used to synchronize all of the MIDI clock-based equipment within a system, such as sequencers and drum machines. Most of the System Real Time messages are normally ignored by keyboard instruments and synthesizers.

The clock (or indeed most other real time messages) are, as noted in the specifications, used to synchronise clock-based equipment, of which sequencers and drum machines are given as examples. The drum machine here does not refer to a sound module that simply produces drum sounds, but to a drum machine which has its own patterns, thus requiring the clock to synchronise the tempo. The sequencer does require a clock, but in almost all MPU-based uses the PC is the only "sequencer" in the system, as it plays back the notes, such as from a game to a sound module. In this case it is the game which acts as the clock, and it would be incorrect to sync the clock to an incoming MIDI tempo, or to a "hardware clock" generated outside the game. In theory the game could ask the MPU to generate a hardware clock at a specific tempo and then sync itself to that clock, but even in this scenario it is not required to send out the clock anywhere, since the game is again the only "sequencer" or other clock-based thing in the system.

In particular, let's be clear here that devices like the MT-32 and SC-55 and any GM, GS and XG sound modules do not need a MIDI clock. This is trivially provable by observing the MIDI data transmitted and noting the absence of the real time clock is not an issue (e.g., connect any "plain" MIDI keyboard and play, or observe the data sent from a regular PC MIDI interface, or even take a signal which includes the clock and remove those – this is what I am currently doing in my patchbay for the MPU card; the MOTU MTP AV patchbay can do advanced filtering, routing and remapping on MIDI data).

Some fancier sound modules and synthesizers, as well as most drum machines, may also include a built-in sequencer or MIDI file player, in which case they may indeed offer the capability to send out the clock (I have several synthesizers and drum modules that do). Then, yes, there is the option to setup your device as either a master or a slave with regard to the clock. This is necessary because in the MIDI data stream the clock beat is simply the single constant byte (0xF8), and thus doesn't include any channel information to denote which device it is meant for. This means that if multiple devices send out a clock in the same system, and those clocks get merged inadvertently, any recipients of this multiplied clock will see the sum of the tempos (with strangely spaced beats, no less). So, yes, it is possible for a single device to be selectable between a clock master and slave. The setting has no other effect than to source the clock, and thus doesn't exist in "plain" synthesizers or sound modules (such as the MT-32 and most classic keyboard synths) – they are not "slaves", because the simply ignore the clock (as pointed out by the MIDI specification) altogether!

So, let's get back to the MPU card and its "hardware clock". The only time it matters is when you are syncing multiple sequencers/drum machines to the same clock and you want the MPU to be the clock master. If you are not syncing any other clock-based devices (such as when the PC containing the MPU is the only sequencer, as is always the case when playing game music), sending the clock out is unnecessary.

Now, if the PC containing the MPU card is the clock master and you wish to sync other devices (such as a drum machine) to it, yes, you want it to send out the clock but you must also sync to that clock yourself, i.e., either the sequencer/composer software you run on the PC must follow that exact same clock that is being sent out, or it must be able to disable the "hardware clock" and instead send out its own "software clock" (which is, on the MIDI protocol level, the same constant 0xF8 bytes, but the clock source is different). Likewise if you wish to sync a software sequencer or drum machine to an external device (such as a hardware sequencer which is what the musician is likely to actually be operating during a live performance), the MPU card must have the option to become slave to that external clock. Sure, you could simply receive an external clock beat on the MIDI IN, but then you would be sending the wrong clock out, unless it is possible to disable the hardware clock. (edit: And indeed the MPU specifically has a command to become a slave to an external clock, stopping the internal one, see the next post.)

Anyway, like said, I have solved this issue for my (admittedly complex) setup by simply setting up my patchbay to ignore all realtime messages (including the clock beat) from the MPU input, but merge others into the outputs going to the various sound modules. This allows me to keep a bunch of sources, including 4 different computers, connected all the time and sharing the same sound modules, without having to worry about powering on the MPU and inadvertently messing up the tempo sync in the (admittedly rare) case that I would have another clock master and clock-based slaves on the same patchbay. (One example of such a case would be to use the TR-8 drum machine with its nice tempo adjustment and start/stop buttons as the clock master through the patchbay while using Ableton Live and some of the vintage sound modules.) (edit: See next post for solutions.)