I recently acquired a TC Electronic M350 effects unit. One if its features is midi connectivity, which allows you to backup or edit the presets on a PC - although the interface exposes every setting so there's not much reason to edit them on the PC.
Unfortunately the librarian/editing software that TC electronic make available (called Vyzor but actually a customised version of a librian product called Uniquest) doesn't work very well on Windows 7 64 bit.
They barely mention their sysex support in the manual and in fact what little they do mention, they get wrong! (The correct procedure to manually initiate a bulk preset dump is to hold the preset on/off key down for approximately 2.5 seconds, scroll up until the display says bd for bulk dump mode, and then press the preset on/off button again).
Anyway I could find no information on the internet concerning the sysex specification of the device so it was clear I needed to reverse engineer the M350's sysex messages and implement a driver for it in JSynthLib which is a librarian/editor that actually works on Windows 7 (and also Macs and Linux as it is cross-platform).
I have made the following notes which I am leaving up here in case they are useful to anybody in the future.
TC Electronic M350 system exclusive spec for firmware version 1.3:
Device Inquiry f0 7E 7F 06 01 F7 elicits a reponse F0 7E 7F 06 02 00 20 1F 58 00 00 00 00 00 01 03 F7. Note that prior to upgrading the firmware, it responded to the Device Inquiry thusly: F0 7E 7F 06 02 00 20 1F 57 00 00 00 00 00 01 01 F7. Note that not only does the software version increase form 1.1 to 1.3, the "device number" changes from 57 to 58, perhaps indicating that the sysex implementation has changed somewhat between versions.
The basic sysex format is:
F0 00 20 1F 00 58 mm <data> F7
mm is the message type and there seem to be the following message recognised:
20: patch data (bi-directional)
22: value change (bi-directional)
45: request patch (to device only)
47: request parameter value (to device only)
message type 20 patch data
F0 00 20 1F 00 58 20 pp uu aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa bb bb cc dd ee ff gg hh ii jj kk ll F7
pp = patch number, (00 = edit buffer)
uu: unknown always 00(maybe bank #? but unused as far as I can see)
aa 20 chars patch name
bb bb 2 bytes - tap (milliseconds, LSB first)
cc input gain
dd mix ratio
ee effect bal
ff delay effects
ii reverb type
jj decay time
kk colour filter
ll checksum - this is calculated simply by summing all the data bytes (i.e. not the header bytes and not the checksum/tail bytes)
message type 22 real time parameter changes sent by editor software or device (seems to be a duplicate of the normal midi controller messages)
f0 00 20 1F 00 58 22 01 xx yy yy F7
yy = value (second yy is 0 apart form for 0d tap in ms)
xx = parameter number:
00 = input gain
01 = mix ratio
02 = effect bal
03 = delay effects ( yy = 00 - 0f )
04 = delay timing
05 = feedback depth
06 = reverb type (yy = 00 - 0f)
07 = predelay
08 = delay time
09 = colour filter
0a = bypass toggle (yy = 00 / 7f)
0b = dual input mode toggle ??????? pure guess
0c = digital input toggle (yy = 00 / 7f)
0d = tap in ms ( 2 bytes, LSB first )
0f = toggles front panel lock - 40+ makes it remote controlled, less than that makes it editable
10 = delay effects on/off toggle?
11 = reverb effects on/off toggle?
Note that parameters 0a/0b/0c/0f/10/11 can be controlled via the software, but are not sent or stored in the patches.
message type 45 request patch
F0 00 20 1F 00 58 45 pp bb F7
pp is patch number
bb is always 00 but I speculate this could be bank number, possibly in future versions of this device.
message type 47 request parameter value
F0 00 20 1F 00 58 47 xx F7
xx = parameter number as listed for message 22