 SysXDump

 Please read this document in entirety.  I took the time to make it explicit, clear, and very useful.  It took me
 longer to write it than it will ever take you to read it.  Therefore, you owe it to both of us to read it.  OK?

 SysXDump is an OS/2 2.X command line application that allows you to dump MIDI System Exclusive information
 (ie, Patch settings, waveform data, etc) from your external MIDI gear to the computer, and store that information
 upon your computer's media (ie, hard drive, floppies).  Subsequently, those data files can be sent back to the
 MIDI gear, again using SysXDump, to quickly restore those settings on the MIDI gear.  So, this utility allows you
 to backup and restore the settings of MIDI gear, utilizing the computer's storage medium.  Typically, floppy disk
 and hard drive storage is much cheaper than those RAM cards or some sort of dedicated MIDI "recorder" to
 capture SYSEX dumps.

 SysXDump also implements handshaking for most Roland gear, or any MIDI sampler that follows the MIDI
 Sample Dump Standard (ie, Prophet 2000/3000, Emu Emulator/Emax/ESI32, Peavey SP/DPM/SX, AKAI S1000 and
 derivatives, etc).  This not only allows you to verify the dump for any errors, but often also improves the speed of
 transfer.

 Furthermore, SysXDump stores a received MIDI Sample Dump Standard (ie, SDS) transfer as a WAVE file, so you
 can use any WAVE editor upon that file to edit and manipulate the waveform or play it back upon a computer
 card.	SysXDump also can send a WAVE file to a MIDI sampler via MIDI Sample Dump Standard.

 For dumps of other MIDI data besides sample dumps, SysXDump stores the data in MIDI file format (Type 0).
 So, you can load that file into any sequencer that supports System Exclusive data, and transfer the data to the
 MIDI unit using that sequencer.

 This is version 1.3.


COPYRIGHT

 This OS/2 Online Book and the related file SYSXDUMP.EXE are all copyright 1995 by Jeff Glatt.	These files are
 freely redistributable, and may be used by and distributed along with any software, be it commercial or
 otherwise, provided that these files are not internally modified, nor specifically sold as a complete product by
 themselves.  The only price that you have to pay is the one that you're already paying by spending all of your
 time in front of a computer instead of developing healthier outlets.

 NOT SO STANDARD DISCLAIMER:

 These programs are provided "as is" without warranty of any kind either expressed or implied or tatooed in a
 place that only a few people have ever seen, including but not limited to the implied warranties of
 merchantability, fitness for a particular purpose, and the dubious assumption that the software has been created
 by a sane individual who would never do anything that may hurt you. The entire risk as to the results and
 performance of the programs is assumed by you or someone who looks exactly like you.  Jeff Glatt does not
 guarantee that the functions in these programs will meet your requirements, especially if your requirements
 involve lots of latex and some docile, domesticated animal.  Nor does Jeff Glatt warranty the programs to be
 uninterruptable or error-free, although mercifully free of "General Protection Faults".  If you use said programs,
 you can not say anything nasty about the author, even if the programs inadvertently cause the erasure of your
 collection of X-rated GIFs of a conservative, overweight and overrated TV "personality" plooking himself vigorously
 with his royalty checks from some rancid paperback.  Jeff Glatt is not responsible for any damages as a result
 of anything that he has done, or hasn't done, or was supposed to do but never got around to it, and furthermore,
 he doesn't even care so leave him alone, ratface.  You may have more or less protections in certain states of
 the union, depending upon how far your local politician is willing to bend over for some bribe from a business
 lobbyist.  Just remember that Jeff Glatt has no money, so don't bother suing him as a result of any damages
 caused by this OS/2 program.  Tell your greasy lawyer to go after IBM, and make sure that you pick 12 really
 stupid pinheads for the jury.	If swallowed, induce vomiting immediately by contemplating the asthetics of
 Microsoft Windows.

 OS/2 is a trademark of International Business Machines Corporation.

 Windows is a trademark of Microsoft Incorporated, and furthermore, Bill Gates is to blame for it.

 If you have suggestions, comments, criticisms, and anything else other than dollar bills, then send them to
 someone else because you got it for free, and you know what you get for nothing?  But, if you do need to
 contact the author, then either phone some of the more prominent psychiatrict clinics in central New York state,
 or try this:

 Jeff Glatt
 6 Sycamore Drive East
 New Hartford, NY 13413
 (315) 735-5350


DRIVER REQUIREMENTS AND SETUP

 Of course, your computer needs some sort of MIDI interface card (ie, with MIDI IN and OUT jacks) to connect the
 computer to the MIDI unit.  Many Sound Cards offer the option of attaching a "box" with MIDI connectors to the
 card's joystick port.  This is the same thing as having a separate card that just does MIDI input and output.

 SysXDump requires that your MIDI interface or Sound Card has an OS/2 driver compatible to my MPUDEV.SYS
 driver.  Information sent to this driver via DosWrite() must be interpreted as outgoing MIDI data (without any
 timestamp).  (It would have to be a rather strange driver if it didn't interpret data as MIDI, but if you're using
 a sound card with WAVE playback in addition to a MIDI interface, it's conceivable that the Sound Card might
 interpret DosWrite() data to be WAVE data). Furthermore, information returned by this driver via DosRead()
 must be incoming MIDI data.

 Note:	SysXDump does not use MMPM.  An MMPM driver will not work with SysXDump unless it meets the
	above requirements.

 You must also know your driver's internal name (which might be different than the filename of the driver).  Often,
 this is the driver filename minus the .SYS extension.

 If you own an MPU-401, or some card that has an MPU-401 compatible interface (UART mode is good enough,
 but it must be actual hardware compatibility, not just some TSR software driver emulation such as what you get
 with cheesy sound cards), such as an SCC-1, RAP-10, MusicQuest MQX-16 or MQX-32, etc, then you can use my
 MPUDEV.SYS OS/2 driver.  See the documentation with that driver for its internal name and usage, or see the Set
 the MIDI driver command.

 By default, SysXDump will use my MPUDEV.SYS driver (ie, the first port MPUDEV1$), and so you don't have to
 supply it with that name.  If you want SysXDump to use a different driver, then you must supply the name of the
 driver to SysXDump.  If you run SysXDump from an OS/2 Command Prompt, then simply type the name of your
 driver as an argument immediately preceeded by "/D".  For example, to use a driver with the internal name
 BLORT, you would specify /DBLORT.

 If you run SysXDump from a Desktop icon, open up the Settings menu for SysXDump.  In the Parameters field,
 type the name of your driver, preceeded by the /D.  Now whenever you run SysXDump from the Desktop, it will
 use that driver.

 Note:	You must omit the .SYS extension from the driver name.

 If SysXDump can't open the specified driver, it will display an error message and its template, and then
 terminate.

 You may want to specify the /I switch when invoking the program if you don't desire the card to be reset when
 SysXDump starts up.  The RAP-10's entire GM module will be reset to default values otherwise.

 There are other startup parameters that you can pass to SysXDump, either by adding them to the command line,
 or entering them in the Parameters field of the Desktop icon. These will be covered later.


HANDSHAKING

 Most Roland units support the Roland type of handshaking, regardless of model.  But, some Roland units do not
 (ie, the older D-70 offers handshaking for transfers, but the newer JV-90 doesn't).  If a Roland unit supports
 Handshaking, it usually has some way to enable or disable this.  If you're going to be using only SysXDump to
 transfer the data back to your Roland unit, then you should enable Handshaking when you originally dump the
 data to the computer.	(Consult your owners manual for information about how you send a dump to the computer
 with or without Handshaking).	Handshaking makes the receive operation (as well as subsequent send
 operations) go much faster, and it also does error correction so that you're assured that a receive or send
 worked.  On the other hand, if you intend to have some sequencer playback the MIDI file, then you'll need to
 disable Handshaking when you originally dump the data to the computer, as most sequencers aren't designed to
 implement Handshaking.  The Roland S-10 is sort of an aberration.  This early device was one of the first to
 implement what later became Roland's standard Handshaking scheme with minor modifications.  Even though
 the S-10 implements Handshaking, SysXDump only supports dumps without Handshaking for it.

 MIDI Sample Dump Standard (ie, SDS) is a protocol for transferring waveform data.  It typically utilizes
 Handshaking.  A number of samplers support SDS.  Consult your owners manual to see if your unit does.	It's
 possible to do an SDS dump without Handshaking.  In this case, you'll originally receive the file using the R
 command rather than the W command.  (ie, The W command always implements Handshaking and error
 correction, and stores the received data as a WAVE file.  The R command doesn't do Handshaking nor error
 correction except with Roland gear, and stores data in a MIDI file).	As above, SDS Handshaking makes the
 transfers go faster, and implements error checking, but if you intend to have some sequencer playback the MIDI
 file (with imbedded waveform data), you'll undoubtably need to disable Handshaking and use the R command.

 SysXDump doesn't support anything but Roland or SDS Handshaking, so you must turn off Handshaking upon
 any unit that uses some other Handshaking scheme.

 If you receive a dump using Handshaking, then you must use Handshaking when you send the file back to the
 MIDI unit.  Conversely, if you receive a dump without Handshaking, then you must disable Handshaking when you
 send the file back to the MIDI unit.  Most Roland units are smart enough to detect when they're being sent data
 originally transferred with or without Handshaking, and so you don't usually need to setup Roland Handshaking
 before sending any Roland dump.  (On the other hand, you do need to set the Device ID to the same value as
 was used when originally transferring the data to the computer).  Likewise, most samplers are intelligent enough
 to deal with SDS Handshaking or not without being told what to expect beforehand.  (But, you do need to set the
 unit's MIDI channel to the same value as SysXDump's Channel setting).
	 For the most part, you only have to worry about enabling or disabling Handshaking when you originally
 dump the data to the computer.  For Roland gear, you have to decide whether you want Handshaking upon the
 original file, and then set it accordingly before the original dump.  Afterwards, you only need worry about the
 Device ID matching the same Device ID used for the original dump.  For SDS dumps, you have to use either the
 R or W command depending upon whether you want Handshaking or not.  Afterwards, you only need worry about
 the sampler's MIDI Channel matching SysXDump's Channel setting if you used the W command, or the
 sampler's MIDI Channel matching the same channel used for the original dump if you used the R command.


MENU

 After SysXDump starts up, it presents a menu choice in an OS/2 Command Prompt Window.	The menu looks
 like this:

 Enter a command:
   C			  Set MIDI channel for SDS transfer
   P			  Set Pulses Per Quarter Note
   T			  Set Tempo
   F			  List files in a directory
   D			  Set the MIDI driver
   E			  Toggle MPC Enforcement
   R			  Receive a data dump from a MIDI unit
   W			  Receive a waveform dump from a MIDI sampler
   S			  Send a data dump to the MIDI unit
   Esc			  Exit program

 You can make one of the preceeding selections.  For example, if you wish to receive a data dump from a MIDI
 sampler, press the w key on your computer.

 Note:	It doesn't matter if you use lower or upper case (ie, w or W).

 Depending upon which command you select, you may be prompted to type in more input.  The following sections
 describe each menu choice:


RECEIVE A DATA DUMP FROM A MIDI UNIT

 Press r to choose to receive a data dump from the MIDI unit (ie, the MIDI unit will be sending its data to the
 computer, to be stored in a MIDI file upon your computer's HD or floppy drive).

 SysXDump next prompts you to type the desired filename, followed by ENTER.  You can prepend a path if you
 don't want the filename to be saved in the current directory.  For example, to save the data in a file called
 Blort.mid in the directory MyDir on your C: drive:

 C:\MyDir\Blort.mid

 Note:	SysXDump will check for the existance of the filename that you choose.	If that file already exists, you
	will be asked if you wish to overwrite (ie, erase) that file.  Press Y for Yes, or N for no.  If you answer
	No, then the operation is aborted.

 If SysXDump has managed to initialize the new MIDI file, it will then display the following message:

 "Go to your MIDI unit, and start a SYSEX dump now. When the dump is finished,
  press any computer key (except Esc, which aborts). I'm waiting..."

 SysXDump will wait for your MIDI unit to perform its data dump.  You must start the dump via your MIDI unit,
 even if using Roland Handshaking.  Check the owners manual for how to cause your MIDI unit to dump data to
 another device (ie, the computer).

 If SysXDump starts getting some data from your MIDI unit, you'll see the message:

 "Receiving a SysEx dump... Esc will abort.
  Pressing any other key finishes the dump."

 If you don't see this message, then something is wrong.  SysXDump isn't receiving any data from your MIDI unit.
 Review all of the possible causes in "No data received and written to the file!".

 If you see this message, then allow the dump to proceed all of the way to the end.  You'll need to watch your
 MIDI unit for some sort of signal when the dump is completed.	When the dump is done, press any key (except
 for Esc) to finish the receive operation.  SysXDump will then tell you how many bytes it received.  For Roland
 units, SysXDump helps indicate the progress of the dump.  It displays the message "End of Roland Block. If
 no more data, press any key except Esc". whenever it comes to the end of a block of a Roland dump.  This may
 be the end of the entire dump from the Roland, or it may not be.  Sometimes, a Roland device sends its dump in
 several blocks.  For example, the D-70 allows you to choose whether to dump its Patch settings, Rhythm Part
 settings, and/or System settings.  If you choose to dump only 2 of the sections at one time, then the D-70 will
 send each section in its own block.  Therefore, you'll see 2 "End of Roland Block" messages before the
 entire dump is complete.  After that, you would press any key except Esc to tell SysXDump to end the receive
 operation.

 For Roland units, SysXDump implements error checking, so you're always assured that you have a good data
 transfer.  If you're using Roland Handshaking and an error occurs, SysXDump will coordinate with the Roland unit
 to correct the error.	If you're not using Handshaking and an error occurs, SysXDump will not be able to correct
 the error (although it does detect the error) and will therefore display the message "Bad Roland Packet!" and then
 terminate the receive (erasing the MIDI file).  In this case, you'll have to start the receive all over again.
       For other units besides Roland, SysXDump does no error checking upon the received data.	It's conceivable
 that a corrupted packet could be received and stored.	But, if this were the case, when you sent the data file back
 to the MIDI unit, the MIDI unit would undoubtably detect the error.  Therefore, you won't know whether the
 received data is complete and error-free until you try to send that data back to the MIDI unit.  If you've got errors,
 your MIDI unit should display an appropriate message.	A good policy is to do 2 receives to separate files, then
 follow them up with a send in order to test the integrity of the files.  Once you've determined that a received file
 checks out OK, make a backup of it.

 Note:	If you intend to use Roland Handshaking for transfers, make sure that you set up your MIDI unit to
	perform Handshaking on its dumps before initiating the receive.  Some units give you a choice of
	enabling/disabling Handshaking.  For other units besides Roland, disable any Handshaking since
	SysXDump only supports Roland Handshaking.

 At any time, you can press the Esc key to abort the dump.  Whatever data was received up to that point is
 erased.

 Note:	Always set your MIDI unit's MIDI channel as desired before any receive.  Some units have a "System
	Exclusive Channel number" that is different than the channel numbers used for other operations.  This is
	the channel number that you need to set.  For Roland units, set the Device ID as desired.  Roland units
	don't care about MIDI channels when transferring System Exclusive data, as they use Device ID numbers
	instead.  When you later send the file back to the MIDI unit, you'll need to set the MIDI channel or Device
	ID to this same value.

 It's possible to receive dumps from many devices, including devices of different manufacturers, different models,
 or even mix Roland Handshaking dumps with non-Handshaking Roland dumps, and store them all in one MIDI
 file.	What you should do is make sure that each MIDI unit is set to a different MIDI channel or Roland Device
 ID.  Then initiate SysXDump's receive operation.  Perform a dump from the first unit, as described above, but
 don't press any key to finish the receive operation after the first unit has sent all of its data.  Instead, go to the
 second unit, and cause it to send its dump.  Repeat this with all of the remaining units.  After all units have sent
 their dumps, one after the other, then you can press any key to tell SysXDump to finish the receive operation.
 The net result is that SysXDump will have stored all received data in one MIDI file.  Now, when you send this file
 back to your units, it will automatically setup each unit in turn, with just that one send operation.	But note that
 the time that you take inbetween initiating a dump upon each unit is "memorized" and applied when you send
 back the file.  A better method is to save dumps to separate MIDI files and then use a program that can merge
 them into one MIDI file.

 The Pulses Per Quarter Note (P) command works in conjunction with the R command.  When you invoke the P
 command, SysXDump will ask you to enter the desired pulses per quarter note resolution of the sequencer upon
 which you intend to play this file back.  (For SysXDump, any resolution of 24 or greater will work fine.  By default,
 the PPQN is 96).  Enter the number and press ENTER.

 You can set the Pulses Per Quarter Note to a specific value when you run SysXDump from an OS/2 Command
 Prompt, by simply typing /Pxxx as an argument, where xxx is the desired Pulses Per Quarter Note.

 If you run SysXDump from a Desktop icon, and wish to have the Pulses Per Quarter Note set to a specific value
 every time SysXDump is run, open up the Settings menu for SysXDump.  In the Parameters field, make sure that
 /Pxxx is included in the string, where the xxx would be the desired Pulses Per Quarter Note.  Now whenever you
 run SysXDump from the Desktop, Pulses Per Quarter Note will be set to that value.

 The Tempo (T) command also works in conjunction with the R command.  When you invoke the T command,
 SysXDump will ask you to enter the desired Tempo (in Beats Per Minute) that you intend to use when you play
 this file back upon some sequencer.  (For SysXDump, any Tempo of 10 or greater will work fine.  By default, the
 Tempo is 120).  Enter the number and press ENTER.

 You can set the Tempo to a specific value when you run SysXDump from an OS/2 Command Prompt, by simply
 typing /Txxx as an argument, where xxx is the desired Tempo.

 If you run SysXDump from a Desktop icon, and wish to have the Tempo set to a specific value every time
 SysXDump is run, open up the Settings menu for SysXDump.  In the Parameters field, make sure that /Txxx is
 included in the string, where the xxx would be the desired Tempo.  Now whenever you run SysXDump from the
 Desktop, Tempo will be set to that value.

 It's important to set Pulses Per Quarter Note and Tempo to the values that you intend to use upon the sequencer
 playing back that MIDI file.  (When the sequencer loads the MIDI file, it should automatically set itself up to that
 specified Tempo, and probably clock resolution as well).  If you subsequently speed up the Tempo or increase the
 clock resolution, the timing inbetween SysEx packets will be shortened such that the MIDI unit may no longer
 have the amount of delay inbetween packets that it expects, and the sequencer may send the data too fast for the
 MIDI unit to process, resulting in a bad transmission.

 If you're using Roland Handshaking, and then sending the data file using SysXDump, then the Tempo and Pulses
 Per Quarter Note settings are irrelevant.  SysXDump doesn't bother with sequenced playback when implementing
 Roland Handshaking.


RECEIVE A WAVEFORM DUMP FROM A MIDI SAMPLER

 Press w to choose to receive a waveform dump from a MIDI sampler that supports MIDI Sample Dump Standard
 (ie, the sampler will be sending a waveform to the computer, to be stored in a WAVE file upon your computer's
 HD or floppy drive).

 SysXDump next prompts you to type the desired filename, followed by ENTER.  You can prepend a path if you
 don't want the filename to be saved in the current directory.  For example, to save the data in a file called
 Blort.wav in the directory MyDir on your C: drive:

 C:\MyDir\Blort.wav

 Note:	SysXDump will check for the existance of the filename that you choose.	If that file already exists, you
	will be asked if you wish to overwrite (ie, erase) that file.  Press Y for Yes, or N for no.  If you answer
	No, then the operation is aborted.

 SysXDump then asks you which wave number on the MIDI unit you would like to receive.  (Check your owners
 manual for how the sampler numbers its waveforms.  SysXDump considers wave number 1 to be the first wave.
 Some samplers count wave number 0 as the first wave, so you may need to ask for a wave number that is one
 greater than the number you really desire.  For samplers that support sending the currently selected waveform,
 whatever it is, if you specify a wave number of 7F, then enter a Wave number of 0 if you desire that).  Type the
 wave number and press ENTER.  SysXDump will then automatically initiate the receive, with Handshaking, so that
 you don't have to operate the MIDI unit.

 If the sampler recognizes SysXDump's request to dump a waveform (ie, the sampler must be set to the same
 MIDI channel as SysXDump's Channel setting, and must have the desired wave number available to transfer),
 you'll see the message:

 "Receiving a SysEx dump... Esc will abort.
  Pressing any other key finishes the dump."

 If you don't see this message, then something is wrong.  SysXDump isn't receiving any data from your sampler.
 Review all of the possible causes in No data received and written to the file!.

 If the data that SysXDump is receiving is indeed a SDS transfer, then you should see the message "Received SDS
 Header".

 SysXDump will then receive the waveform data in its entirety.	SysXDump implements error checking, so you're
 always assured that you have a good data transfer.  If an error occurs, SysXDump will coordinate with the
 sampler to correct the error (assuming that the sampler properly implements Handshaking upon SDS transfers.
 Some cheesy samplers only implement a non-Handshaking version of SDS, which although it will work with the W
 command, completely defeats the error checking ability of SysXDump, and could potentially result in corrupted
 data being stored in the WAVE file).

 After all of the waveform data is successfully received, SysXDump automatically terminates the receive operation
 with the message "SDS completed", and then displays the menu again so that you can perform further operations.
 There's no need to press any key when the receive is complete.

 At any time, you can press the Esc key to abort the dump.  Whatever data was received up to that point is
 erased, and the sampler is told to abort.

 You can only save one waveform per WAVE file.	SysXDump does not support WAVE files with multiple waveforms
 (ie, audio channels).	Furthermore, SysXDump loses the Loop Type (ie, Normal or Backwards/Forwards) setting.
 This isn't too important as many samplers only implement Normal looping, and that's what most folks use
 anyway.  SysXDump does store the (sustain) loop points, in the first two Cue Points of a WAVE file's cue chunk.
 If the waveform has no looping enabled, these points will probably be set to the very end of the waveform.

 The Toggle MPC enforcement (E) command works in conjunction with the W command.  If you toggle MPC
 enforcement on, then any received waveform that isn't at 1 of the 3 MPC sample rates of 11.025, 22.05, or 44.1
 kHz sample rates, is set to the nearest such rate.  Note that SysXDump doesn't interpolate the data.  It just
 changes the sample rate, so the waveform's pitch may end up being transposed.  If MPC enforcement is off, then
 the waveform's original sample rate is preserved.

 By default, MPC enforcement is off.  You can toggle it on when you run SysXDump from an OS/2 Command
 Prompt, by simply typing /E as an argument.  For example, to use the DMS driver with its internal name MPU401,
 and toggle MPC enforcement on, you would specify /DMPU401 /E.

 If you run SysXDump from a Desktop icon, and wish to have MPC enforcement enabled every time SysXDump is
 run, open up the Settings menu for SysXDump.  In the Parameters field, make sure that /E is included in the
 string.  Now whenever you run SysXDump from the Desktop, it will turn MPC enforcement on.


SEND A DATA DUMP TO THE MIDI UNIT

 Press s to choose to send data contained in a MIDI (ie, System Exclusive data) or WAVE (ie, SDS data) to the
 MIDI unit.

 SysXDump next prompts you to type the desired filename, followed by ENTER.  You can prepend a path if the
 file isn't in the current directory.  For example, to send the MIDI file called Blort in the directory MyDir on your C:
 drive:

 C:\MyDir\Blort

 If the file that you've specified is a WAVE file, then SysXDump automatically assumes a MIDI Sample Dump
 Standard transfer with Handshaking.  SysXDump will prompt you to enter the WAVE number that you wish to
 send the waveform as.	(ie, The MIDI sampler may then load this waveform into that numbered "slot" within its
 architecture.	Check your owners manual for how the sampler numbers its waveforms.  SysXDump considers
 wave number 1 to be the first wave.  Some samplers count wave number 0 as the first wave, so you may need
 to specify a wave number that is one greater than the number you really desire.  For samplers that support
 loading the waveform into the current "slot", whatever it is, if you specify a wave number of 7F, then enter a
 Wave number of 0 if you desire that).	After you enter the WAVE number and press ENTER, SysXDump
 automatically begins the dump.  Some samplers require you to put them into a special mode before they will
 receive a dump.  If so, enter the WAVE number, but don't press the ENTER key.  Go over to your sampler and
 put it into its proper mode to receive the wave, then go back and press the ENTER key.  On the other hand,
 smarter samplers are able to recognize when they are being sent an SDS dump, and therefore you merely need
 to enter the WAVE number and press ENTER in order to start the dump.
	 SysXDump will send an SDS DUMP HEADER to the sampler, and display the message, "Sending dump to
 MIDI unit... Esc will abort".  If the sampler is set to the same MIDI channel as SysXDump (ie, use SysXDump's
 Channel command to set the desired channel for sending data) and properly responding (ie, Handshaking), then
 you should see the message "Sending packets..". as SysXDump sends the waveform data.  On the other hand, if
 you see a Timeout error message, then something is wrong.  Review all of the possible causes in "Timeout while
 awaiting ACK!".
	 SysXDump will perform the send in entirety.  There's no need to press any key when the send is
 complete.  If all went well, SysXDump will display the message "Send completed", report how many bytes of data
 were sent to the sampler, and then display the menu again so that you can perform further operations.
	 SysXDump does not support WAVE files with multiple waveforms (ie, more than one audio channel; not
 "mono").  SysXDump requires that the WAVE file contains a data chunk holding the waveform data.  SysXDump
 also assumes that the sustain loop points are the first 2 Cue Points of a WAVE file's cue chunk.  If these Points
 are set to the very end of the waveform, most samplers interpret this as looping disabled.  SysXDump sets the
 Loop Type to be Normal.  You can check that the structure of a WAVE file is suitable for SysXDump's use by
 using my WAVECHK.EXE program to inspect the file.
	 Pressing the Esc key at any time will abort the send.	The sampler will be told to abort.
	 The Channel (C) command works in conjunction with a WAVE file send.  When you envoke the C
 command, SysXDump will ask you to enter the desired MIDI channel you wish to use for SDS transfer.  Enter the
 number and press ENTER.  Make sure that your sampler's "SysEx Channel" is set to this same value.  Note that
 SysXDump considers Channel 1 to be the first channel.	If your sampler considers 0 to be the first channel, then
 you may have to enter a number that is 1 greater than what you really desire.	For samplers that support
 ignoring the channel if you set it to 7F (hex), then enter a Channel of 0 if you desire this feature.	For SDS
 transfers, MIDI allows 128 Channel numbers over one cable instead of just the sixteen for other MIDI data.
	 By default, the Channel is set to 1. You can set the Channel to a specific value when you run SysXDump
 from an OS/2 Command Prompt, by simply typing /Cxxx as an argument, where xxx is the desired Channel.
	 If you run SysXDump from a Desktop icon, and wish to have the channel set to a specific value every
 time SysXDump is run, open up the Settings menu for SysXDump.	In the Parameters field, make sure that /Cxxx
 is included in the string, where the xxx would be the desired channel number.	Now whenever you run
 SysXDump from the Desktop, it will be set to that SysEx Channel.

 If the file that you've specified is a MIDI file, then SysXDump will attempt to send out all System Exclusive
 messages found within the first track of the file.  (ie, When SysXDump creates a MIDI file, it stores the entire
 dump in the first track of a Type 0 MIDI file).
	 Before actually starting the send, SysXDump first displays the message "Press any key to start transmission
 (or Esc to abort)...."  This gives you a chance to prepare the MIDI unit to accept a data dump, if the unit
 needs to be placed into a special mode to do so.  Roland units usually do not need to be placed into a special mode
 to accept a data dump, and therefore you only need press any key (other than Esc) to initiate the dump.  If
 sending to a unit other than Roland, you may need to disable Handshaking before the send.  Or maybe not.
 That depends upon how intelligent the device is in recognizing and reacting to its own System Exclusive
 messages.  It shouldn't need to be indulged like a newborn baby, but some cheaply made units need that.
	 If the data file was originally received with Roland Handshaking enabled, then it will be sent with
 Handshaking.  This allows for much faster transfers, and with error correction.  If SysXDump detects that the
 data file was created with Handshaking, SysXDump will display the message "Enabling Roland Handshake with
 Device XX..." where XX will be the Roland Device ID used for the send.  If the Roland unit is set to that Device
 ID and properly responding (ie, Handshaking), then you should see the message "Sending packets..." as
 SysXDump sends the MIDI data.	On the other hand, if you see a Timeout error message, then something is
 wrong.  Review all of the possible causes in "Timeout while awaiting ACK!".
	 If the MIDI file was not created with Roland Handshaking, then SysXDump performs the dump without any
 Handshaking or error correction.  Hopefully, your MIDI unit will provide visual feedback indicating that it is
 receiving some data, and that the data is not corrupt.  Certain Roland units do not do this without benefit of
 Handshaking.  (ie, The D-70 displays messages when it is receiving data with Handshaking, but doesn't display
 messages when it is receiving data without Handshaking, even though it is capable of receiving dumps with or
 without Handshaking).	If the data is for a Roland unit (but without Handshaking), then SysXDump will display the
 message "Sending data to Roland Device XX..." where XX will be the Roland Device ID.
	 SysXDump will perform the send in entirety.  There's no need to press any key when the send is
 complete.  If all went well, SysXDump will display the message "Send completed", report how many bytes of data
 were sent to the MIDI unit, and then display the menu again so that you can perform further operations.
	 Pressing the Esc key at any time will abort the send.	If Roland Handshaking was enabled, the unit will
 be told to abort.  Otherwise, you may have to allow the MIDI unit to time itself out, or manually cause it to abort
 the dump.

 Note:	Before sending any WAVE file, always set your sampler's MIDI channel to the same channel as
	SysXDump is set to.  You can set the channel you desire to use for the SDS send, by using SysXDump's
	Channel (C) command, and then set your sampler to the same channel.  Before sending any MIDI file,
	make sure that your MIDI unit is set to the same MIDI channel as was used when you originally
	transferred the data to the computer.  For Roland units, set the Device ID to the same number as was
	used when you originally transferred the data to the computer.	(Note that SysXDump tells you to which
	Roland Device data is being sent.  Set your Roland unit to this same Device ID.  Any MIDI channel
	settings are irrelevant for Roland units).  Otherwise, the unit may ignore the send, and in the case of
	Roland Handshaking, you'll get a Timeout error.


SET THE MIDI DRIVER

 Using the Driver (D) command, you can change the MIDI driver used by SysXDump for sending and receiving
 dumps.  If you have more than one MIDI interface in your system, each with its respective driver, you can then
 switch SysXDump among the various "ports", perhaps to do dumps to/from various equipment that is attached to
 those ports.  Some drivers, such as my MPUDEV.SYS support multiple interface cards.  For example, MPUDEV
 supports 4 MPU-401 cards.  Usually the driver has a unique internal name for each port it supports.  You
 specify the name of the desired port.	For example, the first installed port in MPUDEV is called MPUDEV1$.  A
 second, installed port is MPUDEV2$.  So, if you wanted to use the first port of MPUDEV, you'd specify a driver
 name of MPUDEV1$.

 After you specify the driver name, and it can be successfully opened, SysXDump will ask if you wish to initialize
 the driver.  SysXDump needs any MPU-401 hardware to be in UART mode (ie, not INTELLIGENT mode), so if you
 accept driver initialization, SysXDump will send a Reset command to the driver via my own proprietary
 method used with my MPUDEV driver. If you aren't using an MPUDEV compatible driver, or don't want the driver
 and card to be reset whenever a driver is opened, you should turn not accept initialization.

 See the section on Driver Sharing for more pertinent information about drivers.




FILE DIRECTORY

 Press f to get a listing of the contents of some directory on your computer's HD or floppy.

 SysXDump will ask you to enter the directory that you wish to examine.  Use a full path if not the current
 directory.

 Then, SysXDump will list the files that match that file specification.

 Note:	You may use wild cards.  For example, to list all files in the directory BLORT on the C: drive which have
	the extension .mid, type:

	C:\blort\*.mid


DRIVER SHARING

 SysXDump allows shared access to a driver.  (ie, Another program may output MIDI data to, or read MIDI data
 from, that driver while SysXDump is running, and even while performing a send or receive operation).

 But you should avoid simultaneously running another program that also gets MIDI input from the same driver
 unless the other program looks for MIDI input ONLY when performing a specific operation, and otherwise doesn't
 do any DosRead() to the driver while "sitting idle".  SysXDump looks for MIDI input only while it is actually doing
 a receive operation, or a send operation with Handshaking.  So, SysXDump may be left "sitting idle" without
 interfering with the operation of another program that reads from the same driver.  On the other hand, if the
 other program doesn't also stop reading MIDI data while it is "sitting idle", it could interfere with SysXDump's
 receive and send operations.

 Shared MIDI output is usually fine, since when programs are "sitting idle", they usually aren't writing to the
 driver.  So, it's generally OK to simultaneously run two programs that do MIDI output to the same driver, as long
 as both programs aren't performing such operations simultaneously (ie, one program is "sitting idle" while the
 other is performing an operation that causes MIDI data to be output).

 It may even be possible for both programs to simultaneously output MIDI data to the same driver.  But both
 programs need to DosWrite() full MIDI messages to the driver (ie, not break up one MIDI message into several
 calls to DosWrite()).	If a program doesn't conform to this restriction, then its MIDI output may be destroyed by
 another program attempting to output MIDI data simultaneously.  (Of course, even if the two programs conform to
 this restriction, and therefore, their MIDI data can be successfully "merged", this merge process will slow down
 the operations of each program, and may cause each program to experience significantly longer delays in MIDI
 output than if both programs weren't simultaneously outputting MIDI data).  While sending a dump to a Roland
 unit, or sending an SDS transfer (ie, sending a WAVE file), SysXDump conforms to the restriction.  So, in these
 cases, performing a MIDI output with some other program that uses the same driver should be OK, even while
 SysXDump is doing a send or receive operation.  While sending data dumps for non-Roland equipment, or not
 an SDS dump, SysXDump may or may not conform to the restriction, so it's probably best not to cause any other
 program to output MIDI data to the same driver during such a send operation.

 Some drivers, such as MPUDEV, support several independent "ports" (ie, each port has its own MIDI hardware
 interface card), and each port has its own SHARED status.  Therefore, it's perfectly acceptable to have two
 programs running which both use MPUDEV simultaneously, and you won't have to worry about any of the above
 sharing conditions as long as each program uses a different port.


ERROR MESSAGES

 Here are the possible error messages that you may see.  Following each message is a description of likely
 causes for that error and possible remedies, and what happens as a result of that error (ie, does the program
 terminate, or stop transmission, or what?).

 When SysXDump finally terminates, as a result of a fatal error or the user exiting, if the last operation
 performed by the software resulted in an error, SysXDump returns a non-zero value to the OS.  A 0 returned
 value indicates that the last operation before termination was a success.  Note that this is returned in the REXX
 special variable RC when calling SysXDump from a REXX script (which could be done if you wanted to
 implement some sort of REXX patch editor for your MIDI unit using SysXDump to perform any transfers).


MIDI driver XXX didn't open!

 Synopsis	XXX will be the driver name that you supplied to SysXDump (the default of MPUDEV.SYS's first MIDI
		port, MPUDEV1$ is used if you didn't supply a name).  This error means that the requested driver
		did not open, and therefore SysXDump can't do any MIDI input and output.

 Cause		Some other program already has this driver open and has denied any other program access to it (ie,
		no Shared access).  When a program opens a driver for reading or writing, it may decide to restrict
		any other program from reading and/or writing to that driver.  Subsequent programs will not be
		allowed to open (and use) that driver while the preceding program is running.
 Cure		There's nothing you can do other than to terminate the program that is refusing to share the driver.
		If in doubt as to which program that is, terminate all other programs using this driver, and try
		SysXDump again.  See Driver Sharing for more information about this problem.

 Cause		The driver isn't installed properly with an entry in your config.sys file.
 Cure		Check that entry in your config.sys file.

 Cause		The name you supplied is not the true, internal name of the driver.  Every driver has an ascii string
		embedded inside of it, which is its real name as far as OS/2 is concerned.  This might not be the
		same as the driver's filename.  Usually, it is the filename minus the .SYS extension.
 Cure		Contact the author of the driver and verify the driver's name for a DosOpen().  Or use my
		LISTDRVS.CMD REXX script (included with File REXX) to display a listing of the internal names of
		all installed drivers, and pick out what you think is the real name of that driver.

 Error occurs	During program startup, or whenever you issue the Driver command.

 Result 	If the error happens during program startup, SysXDump terminates returning RC = -1.  Otherwise,
		SysXDump sets the error level to -1, and retains the previously opened driver for its MIDI input and
		output.



Driver Command 00: XXXXXXXX

 Synopsis	XXXXXXXX is the error number (in hex) returned by the driver after SysXDump issued a Reset
		Command via the driver's IoCtl interface.  My MPUDEV.SYS driver uses this scheme to reset an
		MPU-401.  That's what SysXDump needs to do when using an MPU-401.  So, I do it this way.

 Cause		If you're not using a MPUDEV compatible driver, then it probably doesn't need to be reset like this,
		will probably not recognize what SysXDump is telling it to do, and you'll see the error message.

 Cure		Specify the /I option when running SysXDump, or disable Initialize.  This tells SysXDump that you
		don't want it to try to reset the MIDI interface using my MPUDEV driver's procedure.  For example,
		if you had a driver named BLORT, and you didn't want it reset, here's what you might type as
		arguments when running the program (or type into the Parameters field of the Desktop icon)

		BLORT /I

 Error occurs	During program startup, or whenever you change the driver Name and allow SysXDump to initialize
		the driver.

 Result 	SysXDump doesn't regard this as a real error.  It's essentially ignored except for displaying the
		message, but the error level is set to -25.


Can't create Semaphore!

 Synopsis	SysXDump uses multiple threads for inputting and outputting MIDI data.	This allows you to abort
		any MIDI transfer in progress, or end the program at any time, by pressing the Esc key upon your
		computer.  SysXDump needs OS/2 to give it a semaphore for such use.

 Cause		For some reason, OS/2 didn't give SysXDump its requested semaphore.
 Cure		Shut down other apps, or OS/2 itself, and try SysXDump again.

 Error occurs	Only during program startup.

 Result 	SysXDump terminates returning RC = -2.


Can't start Receive thread!

 Synopsis	SysXDump uses multiple threads for inputting and outputting MIDI data.	This allows you to abort
		any MIDI transfer in progress, or end the program at any time, by pressing the Esc key upon your
		computer.  SysXDump needs OS/2 to startup the MIDI Receive thread.

 Cause		For some reason, OS/2 didn't startup SysXDump's MIDI Receive thread.
 Cure		Shut down other apps, or OS/2 itself, and try SysXDump again.

 Error occurs	Only during program startup.

 Result 	SysXDump terminates returning RC = -2.


Can't start Send thread!

 Synopsis	SysXDump uses multiple threads for inputting and outputting MIDI data.	This allows you to abort
		any MIDI transfer in progress, or end the program at any time, by pressing the Esc key upon your
		computer.  SysXDump needs OS/2 to startup the MIDI Send thread.

 Cause		For some reason, OS/2 didn't startup SysXDump's MIDI Send thread.
 Cure		Shut down other apps, or OS/2 itself, and try SysXDump again.

 Error occurs	Only during program startup.

 Result 	SysXDump terminates returning RC = -2.


Can't get memory!

 Synopsis	SysXDump needs to allocate some memory for inputting MIDI data.  SysXDump needs OS/2 to fulfill
		its request for that memory block.

 Cause		For some reason, OS/2 didn't fulfill SysXDump's memory request.
 Cure		Shut down other apps, or OS/2 itself, and try SysXDump again.

 Error occurs	Only during program startup.

 Result 	SysXDump terminates returning RC = -3.


Not enough memory to receive MIDI data!

 Synopsis	SysXDump needs to allocate some memory for inputting MIDI data.  SysXDump needs OS/2 to fulfill
		its request for that memory.

 Cause		For some reason, OS/2 didn't fulfill SysXDump's memory request.
 Cure		Shut down other apps, or OS/2 itself, and try SysXDump again.

 Error occurs	While receiving data from the MIDI unit.

 Result 	The error level is set to -4, the receive operation is aborted, and the incompletely received file is
		erased.


Can't create this file!

 Synopsis	A file, that you asked SysXDump to open so that you can receive and store data from the MIDI unit,
		didn't open.

 Cause		The filename that you specified is incorrect.
 Cure		Check the filename that you entered.  Did you specify some directory that doesn't exist?  SysXDump
		only creates files; not new directories.

 Cause		Some other program has this filename currently in use, and is preventing SysXDump from writing to
		it.
 Cure		Make that other program close this filename.

 Cause		The file exists, but although you agreed to overwrite it, it has its READONLY bit set, so SysXDump
		can't overwrite it.
 Cure		Use OS/2's ATTRIB command to turn off the READONLY status of this file.

 Cause		You chose to save data upon some media that is write-protected.
 Cure		Remove the write-protection.

 Error occurs	When you're selecting a filename for the MIDI data about to be received from the MIDI unit.

 Result 	The error level is set to -5, and the receive operation is aborted.


Bad start/end of MIDI file!

 Synopsis	In preparing to receive a data dump from the MIDI unit, to be saved within a MIDI file, SysXDump
		had a problem either initializing the new MIDI file, or finishing up final processing of the file after
		all data has been received.

 Cause		The media is full.  (The number of successfully received bytes should have filled up your media).
 Cure		Make sure that there is enough room on the media to contain the number of bytes that you intend to
		receive from the MIDI unit.  SysXDump can't predict required space before receiving the data, so
		use your own judgment.

 Error occurs	Immediately before or after data has been received from the MIDI unit.

 Result 	The error level is set to -6, the receive operation is aborted, and the incompletely received file is
		erased.


Bad write to the file after X bytes!

 Synopsis	While receiving MIDI data from the unit, there was a problem with being able to write some data to
		the file that you specified.  The X will be the number of bytes successfully received and stored up to
		the point when the error occurred.

 Cause		The media is full.  (The number of successfully received bytes should have mostly filled up your
		media).
 Cure		Make sure that there is enough room on the media to contain the number of bytes that you intend to
		receive from the MIDI unit.  SysXDump can't predict required space before receiving the data, so
		use your own judgment.

 Error occurs	Anytime while receiving a dump from the MIDI unit.

 Result 	The error level is set to -7, the receive operation is aborted, and the incompletely received file is
		erased.


Unexpected MIDI Status!

 Synopsis	During receipt of a SysEx message from the MIDI device, an illegal MIDI status was received,
		according to the MIDI specification.

		Note:  SysXDump properly allows (and ignores) MIDI Realtime messages sent at any time.	Thus
		       you can use the software to capture dumps even from units that implement Active Sense (ie,
		       lots of Roland gear, which gives headaches to dump utilities that don't account for MIDI
		       Realtime messages).

 Cause		Some other MIDI unit daisy-chained to your computer's interface output a MIDI message when it
		shouldn't have.
 Cure		Disconnect all other MIDI units.

 Cause		Your driver and/or interface card is feeding corrupted MIDI input to SysXDump.
 Cure		See the Cure listed under "Your driver and/or interface card isn't feeding MIDI input to SysXDump."
		for the "No data received and written to the File!" error message.

 Error occurs	Anytime during a dump, send or receive.

 Result 	The error level is set to -9, the receive operation is aborted, and the incompletely received file is
		erased.


Bad Roland Packet!

 Synopsis	While receiving MIDI data from a Roland unit without Handshaking, SysXDump detected corrupt data.
		Since Handshaking was not being used, SysXDump couldn't coordinate with the Roland unit to
		correct the data, and therefore had to terminate the dump.

 Cause		Your driver and/or interface card is feeding corrupted MIDI input to SysXDump.
 Cure		See the Cure listed under "Your driver and/or interface card isn't feeding MIDI input to SysXDump."
		for the "No data received and written to the File!" error message.

 Cause		There actually was an error in the data due to some hardware fluke.
 Cure		Try the receive again until you receive a dump without any errors.

 Error occurs	Anytime while receiving a dump from the MIDI unit.

 Result 	The error level is set to -10, the receive operation is aborted, and the incompletely received file is
		erased.


MIDI unit aborted the receive!

 Synopsis	Your MIDI unit sent a Roland or SDS message that told SysXDump to abort the receive.  (ie, You're
		receiving a file with Roland Handshaking, or an SDS dump with Handshaking, and for some reason,
		the MIDI unit has encountered what it perceives to be a problem).

 Cause		There's a conflict with some other unit daisy-chained to your computer's MIDI interface.
 Cure		Disconnect all other MIDI units from the computer's interface except the one desired MIDI unit.

 Cause		Your MIDI unit encountered its own internal error while transmitting data.
 Cure		Examine the error message that your unit (hopefully) displays, and consult its owners manual for
		any solutions.

 Cause		Your MIDI unit didn't acknowledge the Handshake being sent by SysXDump, perhaps timed itself out
		waiting for such, and decided to cancel the dump.
 Cure		Usually, your MIDI unit will eventually display a "Time out" error if there is a long delay in the
		communication happening between the computer and unit.	Make sure that SysXDump is not storing
		the file to an unusually slow media, or that the program's execution is not delayed by other running
		programs.  Furthermore, make sure that no other programs are simultaneously reading MIDI data
		from the same driver (even when "sitting idle") such that they may be stealing data that is intended
		for SysXDump.  Terminate other programs if necessary.  Finally, it's conceivable that some
		handshake may be "missed", in which case, you'll just have to try the receive over again.

 Cause		The driver may have stored a "cancel" message sent by the MIDI unit in response to a problem with
		a previous send or receive operation, and SysXDump misinterpreted this as a response to the
		current receive operation (when the driver subsequently feed this message to SysXDump).  This
		doesn't happen with a driver that supports the generic "Input Flush" IoCtl command which
		SysXDump uses to clear out previously received MIDI data.  MPUDEV supports this command, but
		other drivers may not, and may also cache received MIDI data.
 Cure		Try the receive operation again.

 Error occurs	Anytime while receiving a dump from the MIDI unit.

 Result 	The error level is set to -12, the receive operation is aborted, and the incompletely received file is
		erased.


No data received and written to the file!

 Synopsis	At the end of a receive operation (ie, when you finally press some computer key, other than Esc, to
		tell SysXDump not to look for any more incoming MIDI data, or when SysXDump automatically ends
		the receive at the end of a SDS transfer), SysXDump checks to see if it actually received any data
		from the MIDI unit.  If not, it posts this message.

 Cause		There's something wrong with your MIDI cable connections.
 Cure		Make sure that IN's go to OUT's on the MIDI interface and unit.  For Handshaking, you need a 2
		way connection.  Make sure that you don't have a bad cable or loose connection.

 Cause		Your driver and/or interface card isn't feeding MIDI input to SysXDump.
 Cure		Contact the driver author to verify that the driver meets the requirements outlined in the section
		Driver Requirements and Setup.	(My MidiView program can help verify that the driver is receiving
		data from the MIDI unit, and passing it on to SysXDump in the manner that my MPUDEV.SYS driver
		does.  My Piano program can help verify that the driver is outputting MIDI data to the MIDI unit in
		the manner that MPUDEV.SYS does).  Try the interface card with its included software to verify that it
		is receiving/sending MIDI data from/to your MIDI unit.	If that software works, but none of my MIDI
		programs do, it's likely that the driver doesn't conform to SysXDump's requirements (ie, isn't
		compatible with MPUDEV.SYS).

		Make sure that no other program is simultaneously doing any reads from that driver, by terminating
		any other programs which use the driver.

		If you're using a 100% compatible MPU-401 (ie, capable of Intelligent mode), it needs to be in
		UART mode before it will work with SysXDump.  If you specified the /I option because you're using
		a driver that doesn't support my MPUDEV protocol for resetting the hardware (see Driver Command
		00 error), then you'll have to find some way (ie, other software) to set (and keep) the hardware in
		UART mode before running SysXDump.  If you simultaneously run some other software which
		resets the MPU-401 out of UART mode, then you'll need to force the MPU-401 back into UART
		mode.  If you're using my MPUDEV driver, you can simply reenter the same driver Name with
		Initialize enabled.

		Make sure that the hardware interface or driver isn't filtering out System Exclusive messages.  You
		can check this by causing your MIDI unit to dump its data (without Handshaking) to the computer,
		and then use MidiView to see if those SysEx messages are getting through.

 Cause		Your MIDI unit aborted (ie, perhaps timed out) before sending any data.
 Cure		If your MIDI unit provides its own "progress display", watch it during the transfer to verify that your
		unit is not aborting before sending any data.  Maybe you're trying to do a Handshaking transfer upon
		equipment that SysXDump doesn't support.  (ie, SysXDump only supports Roland and SDS
		Handshaking).  In this case, disable Handshaking upon your MIDI unit.

		If you're using a Roland unit in Handshaking mode, but the unit aborts without sending any data,
		then it is likely not receiving its handshakes from SysXDump.  Check the cable connections and
		driver operation as described above.  Maybe try a transfer with Handshaking disabled.

		If you're doing an SDS receive, and the sampler doesn't even respond to the DUMP HEADER (ie,
		you never even see SysXDump's message that it is Receiving a SysEx dump now...), then check that
		the sampler's "Sysex Channel" is set to the same channel as SysXDump's Channel setting (which
		you can change with the C command).

		Unplug any other daisy-chained MIDI units to make sure that they aren't interfering with the dump.

 Error occurs	At the end of a receive operation.

 Result 	The error level is set to -6, and the empty file is erased.


Can't open this file!

 Synopsis	A file, that you asked SysXDump to open and send to the MIDI unit, didn't open.

 Cause		The filename that you specified is incorrect.
 Cure		Check the filename that you entered.  Did you specify some directory and file that exists?

		Note:  SysXDump does not support wildcards.

 Cause		Some other program has this filename currently in use, and is preventing SysXDump from reading it.
 Cure		Make that other program close this filename.

 Error occurs	When you're selecting a filename for a data file to be sent to the MIDI unit.

 Result 	The error level is set to -5, and the send operation is aborted.


This file is not a MIDI or WAVE file!

 Synopsis	A file, that you asked SysXDump to open and send to the MIDI unit, is not a MIDI or WAVE file.
		SysXDump only reads these two file formats.

 Cause		The file is corrupt.
 Cure		Use a backup copy of the file.

 Cause		The file is in some other format, such as MIDIEX.
 Cure		Use a file conversion program to convert the file to WAVE or MIDI format.  If the file is a MIDIEX file
		(ie, contains a raw dump of MIDI data containing System Exclusive events, either in Ascii or binary
		format), you can use my program X2MIDI to convert the file to MIDI format, or if the MIDIEX file
		contains an SDS dump use SDS2WAV to convert it to WAVE format.

 Error occurs	Immediately after you've selected a data file to be sent to the MIDI unit.

 Result 	The error level is set to -6, and the send operation is aborted.


Corrupted file!

 Synopsis	A file, that you asked SysXDump to open and send to the MIDI unit, is a corrupt MIDI or WAVE file.

 Cause		This WAVE file was created via SysXDump's W command, but you prematurely aborted the SDS
		dump by pressing some key other than Esc.  The resulting file is not a finished WAVE file (ie, it's
		truncated), but also wasn't erased.
 Cure		Don't prematurely abort the W command, unless you use the Esc key (which erases the incompletely
		received WAVE file).  On the other hand, it's OK to prematurely abort the R command, although an
		incompletely received dump may also give you problems when you attempt to send it back to the
		MIDI unit.

 Cause		This WAVE file doesn't contain a data chunk.  WAVE files with more than one waveform (ie, audio
		channel) contained therein, may have the waveform data buried in nested chunks.  SysXDump
		doesn't support that kind of complexity (as an SDS transfer only deals with one waveform at a time).
 Cure		Use some program to extract the waveform data and create a "Mono" WAVE file containing the
		desired waveform, so that SysXDump can better read that file.  You can use my WAVECHK.EXE
		program to display information about the WAVE file to verify that it's a WAVE file that SysXDump can
		deal with.

		Note:  SysXDump obviously can read any WAVE files that it creates, so always save that original
		       file before you use any other software which may modify the file.

 Cause		The file is corrupt.
 Cure		Use a backup copy of the file.

 Error occurs	Immediately after you've selected a data file to be sent to the MIDI unit.

 Result 	The error level is set to -7, and the send operation is aborted.


Bad source file!

 Synopsis	A file, that you asked SysXDump to open and send to the MIDI unit, is a corrupt MIDI or WAVE file.

 Cause		This WAVE file was created via SysXDump's W command, but you prematurely aborted the SDS
		dump by pressing some key other than Esc.  The resulting file is not a finished WAVE file (ie, it's
		truncated), but also wasn't erased.
 Cure		Don't prematurely abort the W command, unless you use the Esc key (which erases the incompletely
		received WAVE file).  On the other hand, it's OK to prematurely abort the R command, although an
		incompletely received dump may also give you problems when you attempt to send it back to the
		MIDI unit.

 Cause		The file is corrupt.
 Cure		Use a backup copy of the file.

 Error occurs	Anytime while sending a dump to the MIDI unit.

 Result 	The error level is set to -9, and the send operation is aborted.


Driver didn't output MIDI byte!

 Synopsis	While sending a data file to your MIDI unit, if you see this message, then the driver didn't properly
		output a piece of data.

 Cause		Your driver and/or interface card isn't accepting data from SysXDump.
 Cure		Terminate any other program that is currently using the driver.

		Contact the driver author to verify that the driver meets the requirements outlined in the section
		Driver Requirements and Setup.

 Error occurs	Anytime while sending a dump to the MIDI unit.

 Result 	The error level is set to -9, and the send operation is aborted.


Timeout while awaiting ACK!

 Synopsis	After sending a packet for data originally received with Roland Handshaking, or an SDS packet,
		SysXDump was waiting for an ACK response (ie, Handshake) from your MIDI unit.  This response
		never came within a reasonable amount of time, so SysXDump assumed that your MIDI unit wasn't
		properly handling the send.

 Cause		There's something wrong with your MIDI cable connections.
 Cure		Make sure that IN's go to OUT's on the MIDI interface and unit.  For Handshaking, you need a 2
		way connection.  Make sure that you don't have a bad cable or loose connection.

 Cause		Your Roland unit's Device ID is not set to the same value as when the dump was originally
		received.
 Cure		Make sure that its Device ID is set to the same value as was used when you originally received the
		data.  SysXDump displays to which Roland Device it is sending data, whenever it detects a Roland
		System Exclusive format within the MIDI file.  Set your Roland unit to that same Device ID number.

 Cause		Your Roland unit isn't the same model as the Roland unit that originally dumped the data to the
		computer, and has an incompatible dump format.
 Cure		Make sure that the unit accepts data dumps created by the Roland model that originally dumped the
		data to the computer.  Some Roland models will understand the dumps of different Roland models
		(or maybe only specific portions of the entire dump), but usually not.	If not, you're out of luck.

 Cause		You're sending a Roland dump created by a Roland model with Handshaking to another Roland
		model that doesn't support Handshaking.
 Cure		Send the data to the original model (that created the MIDI file with Handshaking).  Then, receive the
		data dump back to a new MIDI file upon your computer (using the R command), but this time,
		disable Handshaking on the Roland before initiating the dump.  Now, send this new file (ie, without
		Handshaking) to the other Roland model.  Note that this doesn't guarantee that the other Roland
		model will accept a data dump create by the original model.  Some Roland models will understand
		the dumps of different Roland models, but usually not.

 Cause		You're sending a MIDI file created by a Roland model with Handshaking to some other
		manufacturer's brand that doesn't support Roland Handshaking.
 Cure		You can try the Cure to the preceding Cause, but it's doubtful that the MIDI unit even understands
		Roland dump formats, with or without Roland Handshaking.

 Cause		Your sampler's "Sysex Channel" isn't set to the same value as SysXDump's Channel setting.
 Cure		Make sure that the sampler's "Sysex Channel" is set to the same value as SysXDump's Channel
		setting (or change SysXDump's Channel setting with the C command, to match your sampler's
		channel).

 Cause		You're trying to do an SDS dump (ie, sending a WAVE file) to a sampler that doesn't support SDS,
		or if it does do SDS, doesn't implement Handshaking.  SysXDump demands that your sampler offer
		such basic support when using the W command.
 Cure		For a sampler that doesn't do SDS, you'll have to receive its waveform dumps using the R command
		instead of the W command, saving it to a MIDI file.  Unless it's a Roland sampler, you'll have to
		disable Handshaking on it too, as the R command implements only Roland Handshaking.  You can
		then send this back to the sampler.  For a sampler that does SDS, but no Handshaking, you'll also
		have to use the R command.  Note that for a waveform dump received via the R command,
		SysXDump doesn't do error checking either (unless its a Roland sampler using Roland
		Handshaking).

 Cause		There's a conflict with some other unit daisy-chained to your computer's MIDI interface.
 Cure		Disconnect all other MIDI units.

 Cause		Your driver and/or interface card isn't pushing SysXDump's data out of the MIDI interface.
 Cure		Contact the driver author to verify that the driver meets the requirements outlined in the section
		Driver Requirements and Setup.	(My MidiView program can help verify that the driver is receiving
		data from the MIDI unit, and passing it on to SysXDump in the manner that my MPUDEV.SYS driver
		does.  My Piano program can help verify that the driver is outputting MIDI data to the MIDI unit in
		the manner that MPUDEV.SYS does).  Try the interface card with its included software to verify that it
		is receiving/sending MIDI data from/to your MIDI unit.	If that software works, but none of my MIDI
		programs do, it's likely that the driver doesn't conform to SysXDump's requirements (ie, isn't
		compatible with MPUDEV.SYS).

		Make sure that no other program is simultaneously doing any writes to that driver, by terminating
		any other programs which use the driver.  Also, if sending a Roland dump with Handshaking, or a
		WAVE file (as an SDS transfer), make sure that no other program is simultaneously doing any reads
		from that driver.

		If you're using a 100% compatible MPU-401 (ie, capable of Intelligent mode), it needs to be in
		UART mode before it will work with SysXDump.  If you specified the /I option because you're using
		a driver that doesn't support my MPUDEV protocol for resetting the hardware (see Driver Command
		00 error), then you'll have to find some way (ie, other software) to set (and keep) the hardware in
		UART mode before running SysXDump.  If you simultaneously run some other software which
		resets the MPU-401 out of UART mode, then you'll need to force the MPU-401 back into UART
		mode.  If you're using my MPUDEV driver, you can simply reenter the same driver Name with
		Initialize enabled.

		Make sure that the hardware interface or driver isn't filtering out System Exclusive messages.  You
		can check this by causing your MIDI unit to dump its data (without Handshaking) to the computer,
		and then use MidiView to see if those SysEx messages are getting through.

 Cause		The MIDI unit detected a checksum error (ie, the data was somehow corrupted), and because
		Handshaking wasn't used, it aborted the dump on its own.  Usually, the MIDI unit will display a
		message about such.  With Roland and SDS dumps, SysXDump error checks the data when it
		originally receives the data, and then can implement Handshaking to correct transmission errors
		during the dump, so the problem of corrupted data is confined to dumps without Roland or SDS
		Handshaking.
 Cure		First, try the send again just to make sure that the error wasn't caused by a hardware fluke (ie, the
		error maybe isn't in the data stored within the file itself).  If the error repeats, then try a second
		version of the original dump.  (ie, When originally dumping data from a MIDI unit that SysXDump
		doesn't support with error checking, you should have performed the dump twice to 2 separate files
		to minimize the risk of storing corrupt data).	If you don't have a backup version, then kick yourself
		in the butt, you dimwit, find another way to restore the data upon your MIDI unit, and then receive a
		new MIDI dump from your MIDI unit to the computer.  Check that this new file is not corrupt by
		sending it back to the unit.

 Error occurs	Anytime while sending a MIDI file containing a Roland dump with Handshaking, or when sending a
		WAVE file (as an SDS transfer) to the MIDI unit.

 Result 	The error level is set to -9, and the send operation is aborted.


MIDI unti aborted the send!

 Synopsis	Your MIDI unit sent a Roland or SDS message that told SysXDump to abort the send.  (ie, You're
		sending a file originally created with Roland Handshaking, or an SDS dump of a WAVE file, and for
		some reason, the MIDI unit has encountered what it perceives to be a problem).

 Cause		There's a conflict with some other unit daisy-chained to your computer's MIDI interface.
 Cure		Disconnect all other MIDI units from the computer's interface except the one desired MIDI unit.

 Cause		Your MIDI unit encountered its own internal error while accepting data.  For example, maybe you're
		trying to send a large waveform to a sampler that doesn't have enough RAM to hold that waveform,
		or the sampler doesn't support the waveform's sampling rate or bit resolution.  In such a case, the
		sampler will usually tell SysXDump to abort the send.
 Cure		Examine the error message that your unit (hopefully) displays, and consult its owners manual for
		any solutions.

 Cause		Your MIDI unit didn't acknowledge the data being sent by SysXDump, perhaps timed itself out
		waiting for such, and decided to cancel the dump.
 Cure		Usually, your MIDI unit will eventually display a "Time out" error if there is a long delay in the
		communication happening between the computer and unit.	Make sure that SysXDump is not reading
		the file off of unusually slow media, or that the program's execution is not delayed by other running
		programs.  Furthermore, make sure that no other programs are simultaneously outputting MIDI data
		such that the merging causes SysXDump's output to be delayed significantly.  No other program
		should be reading from the driver either (even when "sitting idle").  Terminate other programs if
		necessary.  Finally, it's conceivable that some handshake may be "missed", in which case, you'll
		just have to try the send over again.

 Cause		You've enabled Handshaking upon the MIDI unit, but are sending a data file that was originally
		received without Handshaking.
 Cure		Make sure that you enable Handshaking on your MIDI unit only with data files that were initially
		received with Roland or SDS Handshaking.  Usually, Roland units and samplers supporting SDS are
		smart enough such that you don't need to worry about the whether its Handshaking state matches
		the data file about to be sent.

 Cause		The driver may have stored a "cancel" message sent by the MIDI unit in response to a problem with
		a previous send or receive operation, and SysXDump misinterpreted this as a response to the
		current send operation (when the driver subsequently feed this message to SysXDump).  This
		doesn't happen with a driver that supports the generic "Input Flush" IoCtl command which
		SysXDump uses to clear out previously received MIDI data.  MPUDEV supports this command, but
		other drivers may not, and may also cache received MIDI data.
 Cure		Try the send operation again.

 Error occurs	Anytime while sending a dump (with Roland or SDS Handshaking) to the MIDI unit.

 Result 	The error level is set to -12, and the send operation is aborted.


No Sysex packets sent!

 Synopsis	At the end of a send operation, ie, after SysXDump has successfully transmitted any and all System
		Exclusive or waveform data in the file, SysXDump checks to see if there actually was any such data
		in the file.  If not, it posts this message.

 Cause		Your data file contains no data.  If the file is a MIDI file, you can check that it contains System
		Exclusive data by using my MIDI Disassembler (MF_DSM.EXE) program to visually display the
		contents of the MIDI file.  Look for some "System Exclusive" type of events in the first track.  If the
		file is a WAVE file, you can check that it contains waveform data by using my WAVECHK.EXE
		program.
 Cure		Receive a new MIDI dump from your MIDI unit to the computer.  Check that this new file contains
		data as above.

 Error occurs	At the end of a send operation.

 Result 	The error level is set to -11.
