                MIDI DmxEtherGate Release Notes For Version 1.1.23.3

    1)  Clean up string formatting routine.
    2)  When saving port information it now clears everything out first.
    3)  Compatibility with newest unreleased ShowMan.

                MIDI DmxEtherGate Release Notes For Version 1.1.23.2

    1)  Clean up string formatting routine.
    2)  When saving port information it now clears everything out first.

                NetMIDI Release Notes For Version 1.1.23.1

    1)  Small fix that cures a theoretical future problem if the tool is
        renamed in the future.

                NetMIDI Release Notes For Version 1.1.23.0

    1)  Inserted dongle, control panel, and other Win 7 stuff.

                NetMIDI Release Notes For Version 1.1.17.13

	1) Killed a long standing and embarrassing bug that involved a global
	variable that should have been per MIDI Input Open client. Some retiming
	might be needed. Annecdotally this version is "quicker" on delivery.

                NetMIDI Release Notes For Version 1.1.17.12

	1) Insert some critical section locking to hopefully make NetMIDI
	hyperthreading and dual processor safe.

                NetMIDI Release Notes For Version 1.1.17.11

	1) Minor fix to correct inability to set only the upper 16 group
	numbers without at least one in the first 16.

                NetMIDI Release Notes For Version 1.1.17.10

	1) Help/About box changes.

                NetMIDI Release Notes For Version 1.1.17.9

	1) Help/About box changes.
	2) Windows XP fix.

                NetMIDI Release Notes For Version 1.1.17.8

	An error crept into the check for valid shownames in the NetMidi
code. It had given problems before and it turns out the change made
then was not quite correct.

                NetMIDI Release Notes For Version 1.1.17.7

Changed bevahior of review copies.

                NetMIDI Release Notes For Version 1.1.17.6

	1) Repair the Mediamation Memorial Vulnerability to attempts to cue the
	   same buffer multiple times.
	2) Repair defects in the MIDM_RESET message handling.

                NetMIDI Release Notes For Version 1.1.17.5

	Recompiled on an NT 4.0 machine. Apparently there is a backwards
incompatability when compiling on a Windows 2000 machine for some features
used in some E-Show tools. So I have recompiled them all.

                NetMIDI Release Notes For Version 1.1.17.4

	This version was compiled with modified compiler option flags that
remove a problem with W2K and rarely with NT4 whereby it was not always
found by ShowMan.

                NetMIDI Release Notes For Version 1.1.17.3

	Added company name and show name to the help/about panel.

                NetMIDI Release Notes For Version 1.1.17.2

	1) Added an explict closesocket() during socketCleanUp(). It is
safe, wastes no particular time, and if somehow processing gets to
socketCleanUp() with the socket still open this guarantees it is closed.

	2) Fixed a gotcha with long show and company names.

                NetMIDI Release Notes For Version 1.1.17.1
	Renumbered on subrevision from 1 to 17 to match subrevisions of
everything else.

	Corrected an embarrassing problem with socket creation that affected
all issues if NetMidi 1.1.x.x and another that created a problem with
show names showing in the edit boxes.

                NetMIDI Release Notes For Version 1.1.1.0

	This corrects a problem with TCP mode reading data from the registry.
(I am surprised 1.1.0.x worked at all in TCP mode.)

                NetMIDI Release Notes For Version 1.1.0.0

	This release is a special for a specific customer. It includes the
ability to establish a single TCP connection for MIDI Input and a single
TCP connection for MIDI Output. (No attempt has been made to handle more.)
The connection mode is selected in the control panel as UDP/TCP mode with
the new selector box. In the TCP mode you must enter the address of the
other machine for the connection.

	Note that the Client (the MIDI Output port) has a "feature". It waits
up to 20 seconds to connect before returning from a MidiOpen command.If
the corresponding Server (MIDI Input port) machine is already running a
connection will likely be established in a fraction of this time. If not
the open succeeds. However, on the first message sent the port will attempt
to send data and if the data cannot be sent because connection has not been
established an error will be returned at this time. If there is a signficant
time between the open and the first data sent this may give time for the
Server machine to be initialized allowing successful transmission.

	In testing I have noticed a feature of the Windows "WinSock" software,
which is used for the UDP and TCP transport. In TCP mode it has a lamentable
tendancy to coalesce packets. I left in a small piece of debugging code
which seems to fix this quite nicely. Unfortunately this is not a clean fix.
If packets come too close together they get coalesced in the WinSock
software. Unfortunately this mixes up header packets material with data
material on reception. If you get garbage upon reception please notify
RSD immediately. I'll try to build in some code which will detect this and
clean it up. In the meantime this version is testable. Reports of its
successes or failures will be appreciated. I also plan to work up a
version which supports multiple UDP packets per message with a filter on
the far end to prevent forwarding duplicates to the receiver. The duplicates
will be sent immediately following each other so the chances of getting them
all obliterated are non-zero. But the chances of getting packets out of order
is also small.

                NetMIDI Release Notes For Version 1.0.12.0

	Fixed an About window bug. And bumped rev number to match the new
MIDI_PLC_205_IO driver.

                NetMIDI Release Notes For Version 1.0.11.1

	Fixed an erroneous test for expiry.

                NetMIDI Release Notes For Version 1.0.11

	This is a commericial licenseable release for the NetMIDI type 1. It
incorporates support exipry warnings and notices and tests for NetMidi being
licensed. If it is not licensed or the demo flag is set NetMidi will cease
functioning after a half hour. The device will then have to be closed and
reopened before it can be used for an additional half hour.

                NetMIDI Release Notes For Version 1.0.10

	This is an interim test build for NetMIDI. It is not signal compatible
with the earlier versions. Most likely it will not be signal compatible with
subsequent releases. It is at the present a working proof of concept tool.

	NetMIDI is a different kind of beast than most of the MIDI "device
drivers" you will find, both in its internal construction and its usage.

	Internally it does not talk to hardware at all.

	It uses standard TCP/IP UDP packets in a broadcast mode for transmitting
data. Since all receivers listing to the broadcast port used, which is
hardwired to 1255 for this version, some means of sorting out signals meant
for a specific receiver is needed. Otherwise mass chaos ensues.

	NetMIDI introduces two filter concepts, "ShowName" and "Groups". The
filter values are inserted into the MIDI Stream as sent over the network
and then stripped from the MIDI Stream at the receiver fully transparently
to the normal MIDI data streams and the applications using the ports.
 
	Internally NetMIDi performs a checksum on the ShowName string. The
checksum value is used as a 4 byte long filter. Only broadcast packets on
port 1255 that match the 4 byte ShowName value are passed to the next level
of filter. This allows several "Shows" to share the same network and keep
their data quite separate and distinct.

	Within a given show, however, you may wish a complex network of MIDI
wires. Hence NetMIDI has its "Groups" concept. Every MIDI port which shares
a given ShowMan can select from 1 to 32 Group memberships. All signals sent
to a given Group are receveived by all other members of the Group. If an
output port is opened for "My Show" sending to groups 2, 5, 20, and 31 then
any input port opened for "MyShow" on any one (or more) of these group
numbers will receive one and only one copy of the messages sent via the
output port. Multiple output ports may share ShowName and group selections.
Thus "MyShow" has a cable matrix between all its output and input ports.

	Note that within NetMidi the input ports and output ports are defined
separately. This has more to do with the internals of the device driver than
it has to do with plans for its utility. However, since it gives you some
increased flexibility in the design for your network of virtual MIDI cables
this is not expected to change in the future.

	Please send bug reports to "lwilton@bix.com" AND "jdow@bix.com".

--- Performance Notes ---

It appears the general timing accuracies of the NetMIDI device falls within
about 1.2mS RMS with no errors beyond about 6-7mS RMS for a 1626 MIDI command
sequence over a 72 second selection. Repeatability between two runs of the
same sequence is in the 0.5mS RMS range with no outliers beyond about 2mS.

It appears to work with multiple receivers and multiple transmitters open at
the same time. However, the second port I used was not really up to the job.
MediaPlayer is not the world's best MIDI Player by a considerable margin.
NetMIDI did not appear to degrade the signal signficantly beyond NetMIDI's
inherent problems when MediaPlayer was run with its process priority
increased to RealTime priority. (Run TaskManager. Select the middle tab.
Find "mplay32.exe" and right click on it. Select "Set Priority" and select
"Realtime".)

{^_^}
