This FAQ answers questions about connecting MIDI gear, particularly with regard to a MIDI setup that includes a computer, and setting up computer MIDI hardware/software.
When it comes to solving problems with an entire setup (ie, more than one, self-contained piece of equipment), you need to learn how to do something called "trouble-shooting". What this involves is simply going through your entire setup, one item at time, isolating that individual piece of equipment and checking that it is operating as you expect.
If you suspect that a particular item is the source of your problems, try to remove just that one item from your setup. Replace it with a suitable, substitute item (or nothing at all if your system can operate without that one item). If your problems disappear, then you've found the "bad" item, and can concentrate upon trying to "fix" this one item. Every single detachable item should be regarded as a separate item to be checked, including all cords and cables, power strips, and even each program you're using on your computer.
Don't go running around the room, checking items at random. Start with one item at the end of your MIDI daisy-chain and follow the MIDI connections through to the last item. As you move from item to item, remember to check the MIDI cable connecting the 2 items. Replace it with another MIDI cable and see if that makes any difference. Look for obvious mistakes on each item such as forgetting to turn the power on, forgetting to turn the volume up, connecting a MIDI OUT jack to another MIDI OUT jack or MIDI IN jack to another MIDI IN jack (MIDI OUT or THRU jacks always connect to MIDI IN jacks, and vice versa), forgetting to make an essential connection (such as the power cord or audio cable), etc. Check for loose connections. Plug a pair of headphones directly into the output of a sound module if you suspect a problem with your mixer. Play the sound module from its own local keyboard if you suspect a problem with the MIDI output of your sequencer.
A very helpful program for diagnosing MIDI problems is MIDI-OX, which lets you see the MIDI data going in and out of your computer's MIDI ports. Get it here.
Questions in this FAQ are:
How do I troubleshoot PC card problems?
Why do MIDI IN jacks connect to MIDI OUT jacks?
Why won't my MIDI controller play the sounds
on my card?
Why does my fancy daughterboard sound the
same as my card's crummy built-in FM/wavetable sounds?
How do I setup my software so that its 'software
mixer' patch names will match the sounds (ie, patches) on my sound module?
Why can't 2 Windows programs use my card simultaneously?
Can I put 2 sound cards or MIDI interfaces
in my computer?
How do I setup my multi-port interface under
Windows?
Why is my computer randomly losing MIDI input?
How can I direct one program's MIDI output
to another program's MIDI input?
Why is my sound module playing only some
of the MIDI channels?
Does daisy-chaining MIDI modules (via THRU
jacks) cause note delays?
Why does my sound card show 3 separate output
devices for MIDI playback?
How should I setup MIDI channels for my sequencer
tracks?
Why won't my parallel port MIDI interface
work?
Why won't my serial port MIDI interface work?
To what extent are piano pedals supported
in MIDI?
Why isn't my sustain pedal working properly?
How can I set my MIDI modules to respond
to only certain MIDI channels?
If your MIDI interface is on on an IBM PC card, make sure that no other PC card is set to use the same IRQ line (ie, number) or port (ie, base address). Check your "jumpers" or DIP switches on the cards. A common problem with a card not working is due to port, and especially IRQ, conflicts with another card. One good sign that you may have an IRQ conflict is when MIDI playback works fine, but MIDI recording doesn't. Many cards do not use the IRQ for playback (ie, polled output) but most all do use the IRQ for recording (ie, interrupt-driven input). Also, make sure that your card isn't set to some IRQ that is being used by a component upon your motherboard. For example, IRQ 7 is used by the parallel port. Do physically inspect your hardware to make sure that every device in your system is set to a different IRQ and base address. I can't possibly stress this enough. If you're not sure what IRQ's the other devices in your system are using, then open up the box and take inventory. (I urge people who buy pre-built systems to insist that the vendor provide them with a list of the devices in their system indicating which devices use which IRQs, base addresses, and DMA channels when you buy the system. Demand it. And then make sure you do get it). Apparently, there are lots of people who enjoy playing what I call "the IRQ guessing game". Without knowing what IRQs, base addresses, and DMA channels are in use in his system, this person will arbitrarily set the jumpers on a new device being added to his system, install the card, and then hope that when he boots up everything will magically work. It usually doesn't. In fact, by the time that the person has played this game for a suitably long time, monkeying around with drivers, he has really messed up his entire software installation. It isn't worth doing that when, if you have a list of what devices use which resources in your computer, changing or adding hardware to a PC is typically a very simple, quick, trouble-free process. I've done this a lot to my own system and others' systems. (You know all those horror stories about installing PC cards? They come from people playing the "IRQ guessing game").
n order to unequivocally determine what IRQs, base addresses, and DMA channels are in use, you need to know the jumper settings of your devices. This includes all of your ISA cards as well as any devices on your motherboard. IRQ conflicts appear to be the biggest cause of conflicts. Base address and DMA conflicts aren't nearly as common (but if you have 2 or more of the same type of card in your system, for example, 2 MIDI/audio cards, the chances of base and DMA conflicts increase dramatically as many manufacturers of the same types of cards follow each others' "standards" for IRQ/base/DMA settings. For example, most MIDI cards use the Roland MPU-401 standard base address of 330). Here's a list of what I've found to be the most common IRQ assignments. I think that it's pretty safe to assume these, but beyond the standard devices (ie, clocks, keyboard, serial + parallel ports, HD and floppy controllers, math chip), check all of your other devices:
IRQ #
0 System timer
1 Keyboard
2 Cascade for second interrupt chip
3 Serial (COM) port 2 (often a modem is attached to this)
4 Serial (COM) port 1 (usually a serial mouse is attached to this)
5 Parallel port 2 (not often used)
6 Floppy controller
7 Parallel port 1 (usually a printer is attached to this)
8 Realtime clock
9 free (but some video cards may use this for EGA emulation)
10 free
11 free
12 free
13 Math chip
14 HD (IDE) controller
15 Second IDE controller (usually a CD-ROM is attached to this. This second
IDE controller may even be on your sound card, such as an SB card)
Often sound cards are set to use IRQ 5. This is often a good choice. Usually, IRQs 10, 11, and 12 are safe to use (assuming other ISA cards aren't using such).
That small yellow exclamation mark you see next to a device name in the Windows Device Manager page indicates a conflict (usually IRQ) or that something is wrong with the device's response.
Another, even more common problem concerns software drivers. The fact of the matter is that programmers do write buggy software, and there's a chance that any problem which looks hardware-related may actually be due to some bug in the card's driver. Check with the card's manufacturer that you have the latest drivers. Ask if there have been any problems reported that may be applicable to your own setup.
And definitely don't rule out the possibility that you may have configured the driver's setup (ie, "Properties" in Microsoft-speak) incorrectly.
The accepted way actually makes a lot of sense. Think about it. You want MIDI data to go out of your controller and in to your sound module. After all, you wouldn't connect the audio out jack of your sound module to the outputs of your mixer, would you? No, you connect the audio output to an audio (mixer) input. And then you connect the mixer outputs to the inputs of your amplifier. And then you connect the amp's speaker outputs to the speaker inputs. Same thing with MIDI. Think of MIDI data as "flowing" in the same way that audio signals "flow" through your audio system.
The built-in sound module on a typical computer card is not internally connected to the card's MIDI IN. Rather, the internal module is internally connected to the card's MIDI OUT (or in the case of Creative Labs' cards, and certain other cards, the sound module is entirely separate from the MIDI IN and OUT, and is considered a separate "device". The MIDI OUT is reserved for a daughterboard connection such as a Roland SCD-10). That way, when a program outputs MIDI data, the internal sound module will "see" and thus play that MIDI data. If you plug an external controller into the MIDI IN of your card, you won't automatically be able to play the built-in sound module on your card. You need to run some software program that provides a "software THRU switch" (usually referred as "MIDI Echo" in programs). In other words, the program reads the MIDI data coming into the card's MIDI IN, and immediately resends that data to the card's MIDI OUT. At that point, the built-in sound module "sees" the MIDI data from the controller. Yeah, it's a roundabout way of getting the sound module to see data from the card's MIDI IN, but if the sound module was connected to both the MIDI IN and MIDI OUT jacks, then it would get very confused if both a sequencer (sending data to MIDI OUT) and a controller (sending data to MIDI IN) were both sending MIDI data simultaneously.
Of course, what would be nice is a card that had a switch whereby the sound module could be switched between the MIDI IN and MIDI OUT jacks. That would eliminate the need for a software THRU function (which eats up CPU cycles). It would be even better if this hardware switch could be toggled via software. Any manufacturers listening? No?
The problem here is that you haven't reconfigured your operating system (or your MIDI software) to use the daughterboard instead of the Sound Blaster's built-in module. Hence, you're still hearing that old built-in module. The built-in module is considered to be a separate "device" apart from the daughterboard. The daughterboard is actually attached to the MIDI OUT of the card, so you need to go into your operating system's (or your MIDI software's) MIDI settings and select the Sound Blaster's "MIDI Output" as opposed to "WaveTable Synth" (or something to that effect, which refers to the card's built-in module). Different operating systems have different ways to do this. In Win95, you use the Control Panel's MultiMedia notebook, open to the MIDI page, and select the SB's MIDI Out as the "Single Instrument". (Or, you could go to Custom Configuration, and divide up the MIDI channels between "MIDI output", ie, the daughterboard, and "WaveTable Synth", ie, the built-in sound module if you wish to use both sound sources together). Under another OS, you may have to add some parameter in your CONFIG.SYS file to indicate that the MIDI Out should be used as the destination for MIDI playback. If your sequencer uses Windows MCI drivers directly, make sure that you've assigned tracks to the card's "MIDI output" rather than its "WaveTable Synth" (ie, the sequencer will no doubt have its own built-in MIDI setup screen).
The problem here is that your Yamaha doesn't have a General MIDI patch set, but that's what your software "mixer panel" assumes your module has. So, when you select some "Fretless Bass" patch using your software, the software sends a MIDI Program Change to where the General MIDI "Fretless Bass" patch is located (ie, patch #36). But, your Yamaha has an accordian patch in that location instead (ie, #36). You need to have your computer remap the GM patch set to where those respective patches are really located on your Yamaha. (For example, if your Yamaha's "Fretless Bass" patch is #12, you need to tell your computer that when you select "Fretless Bass" on your software mixer, it should send a Program Change to patch 12 instead of 36. You'll need to go through all 128 GM patches, and select the correct patch number on your Yamaha for each, or the closest patches that you can find). Or, if your MIDI software supports it, you need to tell your software what the real names of all of the patches on your sound module are (in the correct order from patch #1 to the last patch), so that the software mixer will display those patch names.
Let's consider the second option since that is more flexible (ie, you aren't stuck with using only the GM patch names). Some MIDI software has its own "patch naming" features. CakeWalk has a feature whereby you can enter the name of each patch on your sound module. You list these names in the correct order (ie, from patch #1 to the last patch). For example, you can create a listing of all patches on your EMU Proteus sound module, specifying that patch #1 is called "Tuba Surprise" (or whatever), patch #2 is called "Deep Bass", etc. Then you can apply this patch set to a particular track. Now when you use the software's mixer panel, it uses the patch names you specified (rather than the GM patch set names), and will select the proper patches. Usually, the software allows you to create an individual set of patch names for each one of your sound modules, and then select any set for any given sequencer track. So track 1 can display the patch names of your Proteus (when you use the software mixer), and yet track 2 may display the patch names of your JV-90, and track 3 may display a standard GM patch set for your SCC-1 card. (ie, Your tracks can have different patch sets applied to them, which is very useful if you're using MIDI sound modules that have different patch sets, as above).
This is a limitation of your card's driver. The driver simply doesn't allow more than one program at a time to use it. You're just going to have to run only one MIDI program at a time. (Yes, it's a hassle).
Some drivers are written such that they do allow more than one program to use the driver simultaneously. (ie, The driver doesn't use "global data". It's fully re-entrant). Such a driver is referred to as "multi-client" (or "multi-instance"). If you have one for your sound card or interface, you won't see the above problem. But until Windows gets a real "MIDI Manager", you still have to be careful not to cause two programs to be simultaneously doing MIDI output (or simultaneous MIDI input). In that case, one program may mess up the output (or input) of the other. You can have both programs loaded simultaneously, but only operate one at a time, as you're switching between them. (ie, Don't hit the play button on a sequencer, leave it running, and then flip to another program and do something which causes that second program to do MIDI output simultaneously).
Maybe. Of course, both cards must be set to use a different IRQ #, and port address.
If both cards are of the same model/type, and therefore use the exact same driver file, you had better hope that the driver is written to support more than one of the cards installed. It may need to be "multi-client", as explained above.
If the cards are different, then they'll likely have different drivers. Install both drivers. Then, using Win95's Control Panel's MultiMedia notebook (ie, the MIDI page), do a Custom Configuration as explained in . For Win3.1, you'll use the MIDI Mapper. You're still stuck with a 16 MIDI channel limitation in software (even though you really have 32 MIDI channels support in hardware). But at least you can divide up those 16 channels between the 2 cards (and that helps reduce bandwidth problems).
On the other hand, if you have software that can query and directly use all installed MIDI drivers (as opposed to software that only uses the default MultiMedia settings), then it likely will support all available MIDI inputs and outputs fully. For example, with two installed drivers, CakeWalk will recognize two MIDI ports (each with 16 channels IN and OUT).
The external Sound Canvas is connected to one of the 16 available MIDI OUT jacks on your interface, and since the Sound Canvas is multitimbral, it's going to hog all 16 MIDI channels (of one jack) for itself. So obviously, since you've got 15 other ports available, you'll want to attach your other gear to those ports. Attach one MIDI device per port as long as you've got enough ports. (ie, Each MIDI module attaches to a different MIDI OUT jack on your interface).
(As a side note, it IS possible to tell the Sound Canvas to ignore certain MIDI channels. You do this by sending it MIDI System Exclusive messages. So, you could daisy-chain all your equipment to one MIDI OUT jack on the interface, and then divide up the 16 MIDI channels between all your gear by telling each module to only recognize a smaller, unique set of MIDI channels. But this is a waste of your other MIDI OUT ports).
Your real question is "how do I get my MIDI software to recognize, and direct its MIDI data to various ports on my MIDI Interface"? This is ENTIRELY a software issue. (Yeah, you can start shivering in fright now. You know that software issues pertaining to particular pieces of hardware means that we're talking about DRIVER SUPPORT, CONFIGURING YOUR DRIVER, and CONFIGURING YOUR APPLICATION SOFTWARE. Yep, this is going to be painful, especially if you're dealing with companies that make poor drivers and/or inflexible applications. Grab your ankles and grimace).
Hopefully, the Windows driver with your Interface is designed such that it tells Windows that there is more than one MIDI output. (If it doesn't, toss away the hardware. Without decent driver support, it's useless). Assuming Win95, open the Control Panel's MultiMedia notebook. Turn to the MIDI page. Look at the list of driver names under "Single Instrument". What do you see there? Is there more than one item there (ie, indicating that there is more than one MIDI output available)? For example, for your MasterTrax brand interface, maybe you'll see several items called something like "MasterTrax Output 1", "MasterTrax Output 2", etc. (I'm making up these names. The names are determined by what strings were in the .INF file that shipped with your driver, which you used when you installed the driver. This INF file is just a regular text file that you can read in a text editor. Think of it as a CONFIG.SYS for the sound card alone). If you see multiple items, you're cooking with gas. Your driver has successfully "installed" several "MIDI outputs (ie, devices)" with Windows.
Now, you need to use Windows software that queries and can access all of the MIDI devices installed on your system. Typically, the software will allow you to choose which MIDI data goes to which MIDI output, and which input supplies incoming MIDI. For example, CakeWalk will present a list of all installed MIDI devices, and you can choose which ones you want the software to access. Then, you can route each CakeWalk track to whichever output (of the ones you enabled) you want that track to be sent.
So what if your software doesn't query and use all installed MIDI devices, nor allow you to somehow route the MIDI data between those outputs? Well, that means that the software is written to only use one MIDI output at a time. Which MIDI output is that? Well, go back to the Control Panel MultiMedia "MIDI" page. Did you select "Single Instrument" or "Custom Configuration"? If you selected "Single Instrument", then the output which is used is the one whose name appears in the box immediately below "Single Instrument". For example, maybe you've selected the output "MasterTrax Output 1" which is the first MIDI OUT jack on the interface. Maybe you've connected your Sound Canvas to that jack. The result is that all MIDI data (output by your software) will be sent to the Sound Canvas. If you'd like your software to use another output, scroll through the list of outputs below, and select the desired one. You have to do this every time that you want the software to use a different output, and the software can only use 1 output at any given time.
If you selected "Custom Configuration", this allows you to divide up 16 MIDI channels among several outputs. Never mind that your MIDI interface is capable of handling 256 channels among its 16 outputs. You're going to have to stick to a channel limitation of 16, and divide those up between available outputs. For example, maybe for MIDI channels 1 to 5, you'll select the output "MasterTrax Output 1" which presumably is the first MIDI OUT jack on the interface. Maybe you've connected your Sound Canvas to that jack. The result is that all MIDI data (output by your software) on channels 1 to 5 will be sent to the Sound Canvas. Maybe for MIDI channels 6 to 9 and 11 to 16, you'll select the output "MasterTrax Output 2" which is the second MIDI OUT jack on the interface. Maybe you've connected your Korg M1 to that jack. The result is that all MIDI data (output by your software) on channels 6 to 9 and 11 to 16 will be sent to the M1. Maybe for MIDI channel 10, you'll select the output "MasterTrax Output 3" which is the third MIDI OUT jack on the interface. Maybe you've connected your drum box to that jack. The result is that all MIDI data (output by your software) on channel 10 will be sent to the drum box. Win95's MIDI "Custom Configuration" setup is basically Win3.1's MIDI Manager (without the "Patch remapping" feature -- this feature is now assumed by Win95's Instrument Definition Files, or IDF's). With Custom Configuration, you're still limited to 16 channels (as you would be by daisy-chaining all of your gear to only one MIDI OUT jack on your interface), but at least you're using more than one MIDI OUT jack on your interface (which helps to relieve some problems with MIDI bandwidth).
But of course, the best solution is using software that recognizes and uses the multiple MIDI devices (outputs) on your interface.
Whenever I try to record MIDI (from my controller), some (but not all) data gets lost randomly. I've tried various controllers, and various sequencer programs to no avail. I did NOT use MIDI mapper.
MIDI playback works perfectly.
Is this a hardware problem with my MIDI interface?
I suspect that you're right as to hardware deficiencies being part of your problem, but I also think that your real problem may be due to something called "interrupt latency" (which is sort of dependent upon both software and hardware). In a nutshell, all that means is that your computer isn't running the sound card driver's interrupt handler often enough that the driver is grabbing all of the MIDI data from the card's MIDI IN port. That data is only available for a limited time on the card's MIDI IN port, and if the driver code ISN'T run (by your computer's CPU) in time to grab that byte and pass it off to your software, then the data byte is lost forever when the next incoming MIDI data byte arrives.
Solutions (to be tried in the following order):
It sounds like your MIDI interface has no, or anemic, hardware buffering on its MIDI input.
If the two programs aren't designed to use some sort of scheme to internally pass MIDI data between themselves, then you can use a software MIDI router, which runs on your PC. Try MIDI Yoke, available here.
Alternatively, you can rig up some connection between MIDI input and MIDI output. That could be as simple as just connecting the computer interface's MIDI OUT to its MIDI IN with a MIDI cable.
There are two possibilities here. First, does your sound module support all 16 MIDI channels simultaneously? Some older models do not. For example, a Roland D-70 only has 5 "Parts", which means that it can play only 5 MIDI channels simultaneously. You get to pick out which 5 channels to play (ie, by setting the MIDI channel for each Part), but you're still limited to 5 MIDI channels at any given moment. Some sound cards, particularly early Sound Blasters and their ilk, also didn't recognize all 16 MIDI channels. There is only one official MIDI specification, and it specifies 16 MIDI channels. But, Creative Labs generally makes sound cards for game players, not musicians, so the cards typically aren't as "full-featured" as cards for musicians. Game players buy cheap sound cards, and that means CL had to "cut corners" on that "esoteric MIDI stuff". One way that CL cut corners was by not supporting all 16 MIDI channels. Early CL cards had very limited polyphony, so it wasn't as if anyone was going to do complex MIDI arrangements on them anyway. So, two "sub-standards" were devised known as "base level" and "extended level" MIDI. "Base level" supports only something like 8 MIDI channels and really limited polyphony, and discards any MIDI events on the remaining MIDI channels. "Extended level" supports slightly more channels and polyphony. Both are for cheesy sound cards. "Base level" is for really shitty, now-obsolete sound cards. "Extended level" is for the slightly less shitty, but equally obsolete cards (ie, you know, essentially the same basic shit design repackaged in a box with the word "Pro" appended to the name of the sound card).
If your sound card or module DOES recognize all 16 MIDI channels (and you've checked that it is in fact setup to do so -- try connecting a controller directly to it and sending messages on one of the troublesome MIDI channels), the problem could be software related. If you're using "Custom Configuration" in Win95's MultiMedia MIDI setup, make sure that you've got the MIDI channels set to the intended device. Also, check your sequencer software's MIDI configuration. Maybe it's your sequencer program that is setup for "base level" or "extended level" MIDI (and therefore the program itself is discarding MIDI data on those extra MIDI channels). Check your sequencer's "MIDI setup" options, and look for something that says "base level" or "extended level". Turn that off. Instead select full MIDI support, sometimes indicated by the label "General MIDI". Incidentally, if your software DOES screw around with this "base level" and "extended level" crap, this is good indication that you've got "toy" music software there, which was designed to be used with "toy" audio cards. Professional music software does NOT bother with "base level" and "extended level".
No, but this is such a popular myth that it has been elevated to the status of "urban MIDI legend". The amount of time that it takes the MIDI signal to pass from a module's MIDI IN jack to a properly configured MIDI THRU jack is a matter of a few microseconds. You would need to daisy-chain MANY (ie, certainly more than 30) modules before you could even begin to ascertain any kind of delay.
How did this myth get started? Well, in the early days, MIDI modules were very limited in polyphony. They weren't even multi-timbral, so you usually needed many, many modules in order to play a MIDI arrangement with lots musical parts and heavy "note density" (ie, lots of notes playing upon the same beat). This was a really expensive proposition, so in the early days, musicians tended to do simpler arrangements with typically small, limited MIDI setups. They didn't tax the MIDI bus with lots of notes and therefore, didn't notice the limitations of "MIDI bandwidth". Later on, as MIDI sound modules got cheaper, with more polyphony, musicians started daisy-chaining more modules together. They also started making more complex MIDI music to use all of this additional polyphony. And that's when MIDI bandwidth reared its ugly head. The musicians failed to recognize that they were taxing the MIDI bus with denser arrangements now. Instead, they mistakenly assumed that the delays that they were hearing must be due to daisy-chaining MIDI modules. Hence, the "MIDI THRU Delay Theory" was born. It's incorrect.
Now, note above that I've emphasized properly configured. Some manufacturers foolishly do not follow the MIDI specification properly. The MIDI THRU jack is supposed to be "directly coupled" to the MIDI IN jack. Instead, some manufacturers process the MIDI IN, and THEN send it out the MIDI THRU jack. (A telltale sign that this is likely being done is a module that has no dedicated MIDI THRU jack. Rather, it has a "software switchable" MIDI OUT/THRU jack). This "processed output" likely will introduce more delay than a direct coupled MIDI THRU -- a LOT more delay. But we're talking about an aberration of the MIDI spec. My advice is to avoid using that THRU jack, or only buy gear that follows the MIDI spec precisely. I tend to buy Roland stuff because the company is religious about not screwing around with the MIDI specification. (Roland is one of the few companies that even go so far as to implement Active Sense).
A processed MIDI THRU is a very, very, very, very bad thing. It shouldn't be necessary, and if you got it and don't need it, you can't get rid of it. (If you're daisy-chaining so much gear that you need to worry about "cleaning up" the MIDI signal along the path, then you should DEFINITELY be considering a multi-bus MIDI configuration to solve the problem. DO NOT SOLVE THE PROBLEM WITH PROCESSED MIDI THRU SIGNALS. That introduces more problems than it ever solves). Avoid it. Avoid products that do this. Stick with products that follow the MIDI spec. We've been using it for a long time. It works. There are much better solutions to connecting gear than a processed MIDI THRU.
You actually have 3 separate output devices (all on one card). You have the SB FM Synth. That supports 16 MIDI channels.(But since its sound quality and polyphony is extremely poor, you likely won't be using it much except for music on really old game software). You have the SB WaveTable Synth. That supports 16 more MIDI channels. And you have the SB MIDI Out (to which the DB50 is internally attached). That supports another 16 MIDI channels. So, each one of the components is its own output device, not internally daisy-chained to the other 2 components, and therefore has its full 16 MIDI channels which it does not need to share with the other devices. (You have a total of 16+16+16 MIDI channels). That's why you have 3 outputs listed -- because even though they're on the same card, they each have their own set of 16 MIDI channels.
MIDI channel #1 on your AWE32's WaveTable Synth is not the same as MIDI channel #1 on your DB50. Why? Because these two devices are not daisy-chained together. (If they were, then they'd be using the same MIDI channel 1). They each have their own set of 16 MIDI channels to work with. So, if you set one CakeWalk track to output to the AWE32 WaveTable Synth on MIDI channel 1, and you set another track to output to the SB MIDI Out (ie, the DB50) on MIDI channel 1, then these are going to two different places (ie, outputs). They're not the same MIDI channel 1. One is on the AWE32 WaveTable output, and one is on the MIDI OUT output.
So there's no reason whatsoever for you to divide up MIDI channels between devices, assuming that you're using a sequencer program which supports outputting to all 3 devices SIMULTANEOUSLY, such as CakeWalk. If you have a sequencer that supports only 1 output device at a time, and therefore only 16 MIDI channels total, then you'll need to use Win95's Advanced MIDI setup or Windows 3.1's MIDI Mapper, and divide up the 16 channels among your output devices. I'd recommend using 6 channels for the AWE32 WaveTable, and 6 for the DB50, and forget the FM synth).
Of course, if you attach external MIDI modules to the AWE32's MIDI Out, then you're effectively daisy-chaining these to the DB50, since the daughterboard is internally attached to the AWE32's MIDI Out. Now, you've got to share the MIDI Out's 16 channels between the DB50 and other external modules. (Setup each module to ignore certain channels. The DB50 can be set to ignore channels via System Exclusive messages). No, you can't reroute some of WaveTable Synth's or the FM Synth's 16 channels to the MIDI Out (and therefore have more than 16 channels going to MIDI Out). The MIDI Out has only its own 16 channels with which to work, and these must be divided among all modules attached to MIDI Out, including the DB50.
That depends upon what is on each track.
You'll likely need to have each "instrument" in your arrangement upon a separate MIDI channel. For example, don't put the piano and the sax parts upon the same MIDI channel (unless the parts don't occur during the same musical bars. I'll explain that later). Why? Because a single MIDI channel can't simultaneously play 2 different patches. A patch is usually analogous to one instrument sound. (On some modules, a patch can be setup to divide the MIDI note range between 2 or more instrument sounds. But on General MIDI devices, such as what you have, most patches feature only a single instrument sound across the entire MIDI note range. The GM patch named "Bass + Lead" is an exception. Notes lower than middle C play a bass guitar sound, whereas notes above C play a synth lead sound. So you can play two instrument sounds with that one patch. But that's an exception, and the other GM patches feature only 1 instrument sound across the entire MIDI note range).
But that's not necessarily to say that every sequencer track will be on a different channel. Maybe you'll have 2 tracks that are both using the same piano sound (ie, same patch) on the same module, and have the same settings (ie, the same panning, volume, etc). Maybe one track is some background piano part, and you decided to put the piano solo upon a separate track (so that it is easier to edit separately from the background piano notes). In that case, you'll likely have the tracks set to the same MIDI channel. After all, even though you're using 2 sequencer tracks, they are both playing the same part -- the piano part.
Of course, if you have 2 instrumental parts that don't occur during the same musical bars, then you can put both parts upon the same MIDI channel. For example, let's say that you have a trumpet solo during bars 1 to 16. Then you have a sax solo during bars 16 to 32. At no time do any trumpet solo notes sound while the sax solo notes are sounding (and vice versa). Although you may choose to record the solos to separate sequencer tracks, you can have both solos set to play upon the same MIDI channel and the same sound module. You would have a MIDI Program Change at the start of the trumpet solo. It would change to the trumpet patch. Then at the beginning of bar 16, after all of the trumpet notes have stopped but before any sax notes have started, you would have a MIDI Program Change to switch to the sax patch. Using the same MIDI channel for instruments whose parts do not occur upon the same musical bars (ie, the parts don't overlap) is a good way to conserve your MIDI channels for musical parts that do overlap.
Sometimes you do have to use more than 1 MIDI channel for a certain instrument if you're doing some stereo effect. For example, let's say that you want to have all of the piano notes played with the left hand panned to the left, and all of notes played with the right hand panned to the right. You'll need to record the notes for each hand upon a separate MIDI channel. Why? Because not only is a single MIDI channel limited to playing only one patch, it is also limited to only one pan position. That means that you can pan notes on MIDI channel 1 to the left, or to the right, but not both. You can't have some notes panned to the right and other notes simultaneously panned to the left. You'll need to separate the left and right hand parts to 2 separate MIDI channels, and pan one channel to the right and the other channel to the left.
But, mostly, you'll have each instrument's part on just one track (with its own, unique MIDI channel). Especially if your arrangement doesn't use more than 16 patches, you've got it covered with only 16 MIDI channels, and you can safely dedicate a unique MIDI channel to each instrument (ie, patch).
First, get into your BIOS setup, and check whether you have the parallel port set to "Enhanced" or "Bi-directional" modes. Some parallel port MIDI interfaces do not support these two modes, and will only work when the parallel port is in a basic, uni-directional mode. (Of course, changing this may then affect your printer operation if it shares the port).
Secondly, if you have a printer already using the first parallel port (ie, LPT1), it may be that the printer's driver is not allowing the MIDI interface's driver to use the IRQ (ie, #7). If you have a second parallel port (ie, LPT2), then use that (and make sure that you let the MIDI driver know that it should use IRQ 5 -- but make sure that you don't have another sound card set to that, since many SB cards use this IRQ by default). If you don't have another parallel port, you may have to try removing your printer driver to see if that resolves some conflict.
Do you actually have free resources associated with the COM ports? Note that COM1 and COM3 both share IRQ 4, and COM2 and COM4 share IRQ 3. So, if you have two devices that require use of the IRQ, you can't set them to COM1 and COM3 respectively as that would force them to both try to simultaneously use IRQ 4. Ditto with COM2 and COM4. If you have a serial mouse plugged into serial port 1, and you have a modem plugged into serial port 2 (an internal ISA card will also typically be set to use the second COM port and its IRQ), then you've already used those IRQ's associated with the COM ports. You won't be able to also use your serial port MIDI interface with a serial mouse and modem already in your computer.
Of course, you'll want to make sure that you serial port isn't disabled in your BIOS. Also, make sure that your serial port uses a chip (such as the 16550) that supports the 38KHz baud rate that serial MIDI interfaces require.
MIDI has many "controller functions" to adjust such things as a patch's volume, pan, portamento time, modulation (which could be setup to implement a vibrato effect, or tremulo effect, or other effects), reverb amount, chorus amount, and many other functions. There is even a controller that specifically functions as a sustain pedal. (ie, When "on", it causes the module to "hold" the sustain portion of its volume envelope even after receiving a note-off. When "off", the envelope proceeds to its release portion as usual when a note-off is received. So yes, it does implement a "pedal up" and "pedal down" simulation of a piano sustain pedal). There are two other specific controllers to simulate the "soft pedal" and the "sustenuto pedal". These controllers are all part of the MIDI spec itself.
The GM spec simply states that a module must support particular controllers, in a particular way. Think of GM as a minimum standard for what portion of the MIDI spec a module must support, and how it must support that portion of the spec. GM is just a minimum level of support -- a minimal "setup" such as 128 specific patches and 47 specific drum sounds that a module must have in order to be at least GM compliant. The reason for GM is to ensure that all modules have a minimal, standard setup so that MIDI files that adhere to this minimum standard can playback easily and properly upon all GM equipment.
One of the controllers that GM mandates support for is the sustain pedal, so virtually every module supports that function. (The soft and sustenuto pedals are not part of the GM spec, and are rarely supported, so you'd have to specifically shop for a module that supports such, ie. goes beyond GM support, if you want those other 2 pedals).
Most modern sound modules support many of the above functions (ie, adjustment of volume, pan, reverb level, sustain on/off, etc), although how extensive the module's support is may vary according to price and model. Many modules offer an assignable pedal input. That is to say that you can assign the pedal to control any of the above functions (or maybe just a limited set of functions). This pedal will also typically generate a MIDI controller message. Typically, it will use a "generic" controller number, since you can assign the pedal to control any one of a variety of functions. Most modules also have a pedal jack that is hard-wired to that sustain pedal function. This will generate that defined controller number for the sustain pedal (ie, controller #64). Virtually all modules support this particular controller, and will respond in a similiar (if not identical) manner.
Most modules implement dynamic voice allocation, which means that as voices are all used up (because you're sustaining notes) and you play more notes, previously played notes are "stolen" (ie, a previously played note is muted so that a new note may sound). This is no standard algorithm for dynamic voice allocation. Some modules have a more intelligent scheme than others, and will try to drop the "least important" notes first. (For example, one module may discern that you're sustaining the 4 notes C-E-G plus another C an octave above the first. Even though the E may have been the last played note, maybe the module will steal a C note because it's a doubling of another playing C. Some modules try to avoid stealing the highest and lowest sounding notes, as your ear tends to be most sensitive to these dropping out). So, it may be possible that you'll prefer one module's dynamic voice allocation to another. To be sure, the more voices that a module has, the less likely you'll run into a "problem" with voice allocation.
Personally, I think that 32 voices is more than enough to simulate a piano well (but of course, with a multitimbral module, you may be playing other patches simultaneously, and spreading out voices among numerous patches).
You bought a pedal that was made for a keyboard that had a reverse polarity to yours. Some modules want "open circuit" switches and some want "closed circuit" switches. You can tear open the pedal and rewire it, assuming that your module doesn't have some feature to reverse the polarity (ie, many new units have that function selectable by the user, or if you press down your pedal while turning on the unit, it may automatically adjust to using reverse polarity). But a better idea is to buy a pedal that has a polarity switch on it.
There is no standard MIDI message to explicitly tell a sound module to ignore certain MIDI channels. Many sound modules do support their own System Exclusive message to do that. But that message will vary from manufacturer to manufacturer, as Sysex messages tend to do, and some modules may not offer any way to setup MIDI reception other than by manually using the module's control knobs. You'll have to check the manual for each module, and see if it offers such a Sysex message.
Now, I said that there's no MIDI message to explicitly tell a sound module to ignore MIDI channels, but in later revisions of the MIDI specification, the MIDI controller message, "Monophonic Operation" (ie, controller 126) is redefined to work in conjunction with the "Omni Off" Controller (ie, 124) message to allow you to set a MIDI module to respond to only a limited set of MIDI channels. One caveat with using this method is that the MIDI channels must be adjacent numbers. For example, you can get a module to respond to channels 6 through 10. But you can't tell it to respond to 6, 7, 8, and 10 (ie, skipping channel 9). Well, not via the Monophonic Controller message anyway.
There's another caveat. You must manually set the "Base Channel" of every module to be different. (Again, some modules let you select the Base Channel with a System Exclusive message). The "Base Channel" is the channel upon which messages such as Omni Off and Monophonic Operation must be sent in order for the module to recognize the message.
Here's how Monophonic Controller works in conjunction with Omni Off. (NOTE: The following discussion assumes a multi-timbral module. Monophonic Operation does not work the following way for modules that aren't multi-timbral).
Like all controllers, a Monophonic Operation Controller message has a data value associated with it. If Omni is off (ie, you have sent the Omni Off Controller message already -- most multi-timbral modules automatically powerup in this state anyway), this value tells how many MIDI channels the module is expected to respond to. In other words, if Omni is off, this value is used to select a limited set of the 16 MIDI channels (ie, 1 to 16) to respond to.
If Value is 0, what this means is that the module should play as many MIDI channels as it has multi-timbral "Parts". So, if the module can play 16 of its patches simultaneously, then it can respond to MIDI messages on all 16 channels.
If Value is not 0 (ie, 1 to 16), then that's how many MIDI channels the module is allowed to respond to. For example, a value of 1 would mean that the module would be able to respond to only 1 MIDI channel (and therefore play only 1 Part). If a module is asked to respond to more MIDI channels than it has Parts to accomodate, then it will handle only as many MIDI channels as it has Parts. For example, if a module can play only 5 Patches simultaneously, and receives the value 8 in the Mono message, then the module will play 5 patches on MIDI channels 0 to 4 and ignore messages on channels 5 to 7. (Here we assume a base channel of 0).
Most multi-timbral modules allow you to specify a Base Channel. This will be the lowest MIDI channel that the module responds to. For example, if a Mono message specifies that the module is to respond to only 2 channels, and its Base Channel is 4, then the module responds to channels 4 and 5.
Of course, in order to be able to send an individual Mono message to each of your modules, each one has to be set to a different Base Channel. Otherwise, 2 modules with the same Base Channel would both respond to the same Mono message. And of course, you need each module set to a different Base Channel in order to also have each use its own, unique range of MIDI channels. After all, the Base Channel is the first channel that the module always responds to.
Getting a headache yet? As you can see, because of this Base Channel hassle, the above method of setting up a multi-timbral module's MIDI reception means that you likely have to setup each module manually anyway (unless the module also allows setting Base Channel via System Exclusive). It would have been nice to have a dedicated MIDI message to set channel reception which, like System Exclusive, didn't need to be sent upon a particular MIDI channel, and had two data values to set the desired lower and upper ranges for MIDI channels. But the MIDI designers didn't think of this at first, and this method of hacking the Monophonic Controller was the best, backward-compatible trick they could devise later on. Because of its convoluted and inflexible hassles, many multi-timbral modules don't even support the Monophonic Operation controller at all. So it's not even very much of a "standard" approach today. Why didn't the MIDI designers think to have a dedicated message to set MIDI channel reception right from the start? Well, it never occurred to them that it was important. They didn't have multi-timbral modules back then. And it's a weird concept to setup MIDI channel reception using MIDI messages. Think about it.
Most modules instead use a simple System Exclusive message to set MIDI channel reception, and usually this allows for picking MIDI channels in any order. For example, the Yamaha DB50XG daughterboard uses the SyxEx message (values in hexadecimal):
F0 43 10 4C 08 Channel 04 7F F7
where Channel is the desired MIDI channel that you want the DB50XG to ignore. (0 is the first MIDI channel). You would repeat this message for each channel that you wish ignored, substituting that channel number in the message.
But the drawback with SysEx messages is that everyone does it differently. There's really no easy, "works for all MIDI modules" way to setup a module's MIDI channel reception over MIDI.