-
Notifications
You must be signed in to change notification settings - Fork 3
De re MS 70 CDR
These are the gratuitous "does useful stuff" strings I have found (either found via R&D but all tested on my MS-70 CDR).
| Function | Sysex String | Returns | Comments |
|---|---|---|---|
| Identify | f0 7e 00 06 01 f7 | f0 7e 00 06 02 52 61 00 00 00 32 2e 31 30 f7 | ****Universal String responds with model ID and firmware version. In this case 2.13 |
| NumPatches | f0 52 00 61 07 f7 | f0 52 00 61 06 32 00 7a 00 f7 | 0x32 = 50..num patches on pedal 0x7a=122 patch size |
| EditorOn | f0 52 00 61 50 f7 | Turn Editor mode on so Zoom pedal spits out some content | |
| EditorOff | f0 52 00 61 51 f7 | Turn Editor mode off | |
| PCModeOn | Not implemented on MS-70 CDR? Let me know if you find it | ||
| PCModeOff | Not implemented on MS-70 CDR? Let me know if you find it | ||
| TunerModeOn | B0 4A 40 | Dont seem to also need to send EditorOn as per B1On | |
| TunerModeOff | B0 4A 00 | ||
| GetMoreData | F0 52 00 61 60 05 00 F7 | whats in buffer | seems to flush the current buffer. Useful for getting clean data |
| CurrentBankNumber | f0 52 00 61 33 f7 | i.e. b0 00 00 b0 20 00 c0 00 | Midi CC of the current patch |
| LoadPatch | C0 ${hexLow} | i.e. C0 15 | hexLow is one less than the physical patch. Patch one is hex 0. Patch 33 is hex 0x20 |
| StorePatch | f0 52 00 61 32 01 00 00 ${patch} 00 00 00 00 00 f7 | i.e. 15 | Store current data into patch. Like a "copy". Patch is hex value for which patch to store |
| GetCurrentPatch | F0 52 00 61 29 F7 | F0 52 00 61 28 ... data ... F7 | Returns current patch in raw format. More on this later |
| GetPatch | F0 52 00 61 09 00 00 ${hexPatch} F7 | f0 52 00 65 08 ... | Returns given patch (value -1 as hex) in raw format |
| FXM_OnOff | F0 52 00 61 31 (M-1) 00 (00 or 01) 00 F7 | 6th byte is FX slot 1 - 5 => 0 - 4, 8th byte is 0 for off, 1 for on. | |
| FXM_PN | F0 52 00 61 31 ${hexFX} ${hexParam} ${hexValueLow} ${hexValueHigh} F7 | 6th byte is FX slot 1 - 5 => 0 - 4, 7th byte is parameter + 1, bytes 8 & 9 are low and high bytes of Parameter values |
I have not found a patch volume yet - this exists on other Zoom pedals. Maybe I havent looked hard enough or maybe it doesnt have one?
I have found patch tempo - and this is very bizarre. If you watch the pedal with a sniffer you can see the standard (MS-70 variant) sysex is sent. However, if you replay this the pedal does not accept the input. It is possible to patch the patch to do this. To fully explain this will require some text - and likely I will make a YouTube video about it.
Basically, all of the current patch reversing engineering efforts miss the "8 midi bytes encode 7 x 8 bit values" trick. So if you look at g200kg's excellent write up the model used is way to complex. If you unpack the sysex stream from the pedal then the tempo is spread over bytes 109 and 110. Where are these bytes? Well you ignore the first 5 (they are 'hi there - I am a Zoom patch dump', unpack and there they are. I will be writing a program to create Zoom patches.
This appears to be Zoom's first generation FX format. The G1XFour et all use ZD2 (Zoom Device version 2.00). I have written Python programs that can pull out the ZDLs from firmware, create JSON format for the parameters in MIDI format ... ie 0, 1, ... mmax rather than what the pedal displays. Some bugs to iron out. Alas I have not found yet how to get the data from the pedal (as Mungewell discovered for the Zooom G1Four class of pedals).
Here I used a command to probe if I get a response from the B1On for a given pattern.
Now this is my approach for probing for single PCMode command Sysex strings from the pedal. I have subsequently learnt that often the Zoom doesnt respond BUT you are changing the patch. More on that as I write it up - only just found how to detect this myself.
pi@raspberrypi:~/Software/ZoomPedalMS70CDR $ more probeSysexCmd.sh
#!/bin/bash -x
export MIDI_DEV=`amidi -l | grep ZOOM | awk '{print $2}'`
./EditorOn.sh
# no PC mode on a MS-70 CDR?
# ./PCModeOn.sh
for i in {0..127}
do
fs=`printf "%03d" $i`
hexSlot=`printf "%02x" $i`
probeString="F0 52 00 61 ${hexSlot} F7"
theFile=p_${hexSlot}_${fs}.bin
amidi -p ${MIDI_DEV} -S ${probeString} -r ${theFile} -t 1
let x=`ls -l ${theFile} | grep -c " 0 "`
if [ $x -eq 1 ]
then
echo $x
rm ${theFile}
fi
./EditorOn.sh
done
#./PCModeOff.sh
The above writes out files of the form p_dec_hex.bin. Here's the listing from a MS-70 CDR.
pi@raspberrypi:~/Software/ZoomPedalMS70CDR $ ls -1 p_*
p_01_001.bin
p_04_004.bin
p_05_005.bin
p_07_007.bin
p_0e_014.bin
p_16_022.bin
p_29_041.bin
p_2b_043.bin
p_33_051.bin
You could trial, at your own risk, on your Zoom pedal. Change the Device ID. I have done this on my Zoom B1XFour and G1XFour. Clearly Zoom is adding more commands with the new pedals. This is positive - better functionality BUT since they do not open it up it is also a little frustrating.
Here is an example of the input (raw from the file and as handled by g200kg and sixeight). Nothing wrong with playing with the raw bits - we have to do it anyhow in unpacked space - but I think the parameter patterns are easier to see in unpacked space.
Infile: currentPatch.bin
INPUT
f0 52 00 61 28
08 49 00 00 64 00 04 00 08 0a 50 52 00 42 09 00
00 00 00 00 00 11 00 00 40 50 03 78 00 23 50 10
00 60 19 00 00 00 00 00 00 00 75 00 00 4c 01 1c
00 00 33 00 00 00 00 00 00 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 08 00 00 00 40 0c 05 45
00 6d 70 74 79 20 20 20 00 20 20 00 f7
Empty
FXID[1] (ON) = 73 (49), GROUPID = 2 (02)
P1 = 7 (07) P2 = 1 (01) P3 = 20 (14) P4 = 37 (25) P5 = 5 (05) P6 = 40 (28) P7 = 148 (94) P8 = 0 (00) P9 = 0 (00)
FXID[2] (ON) = 17 (11), GROUPID = 0 (00)
P1 = 30 (1e) P2 = 30 (1e) P3 = 70 (46) P4 = 5 (05) P5 = 1 (01) P6 = 150 (96) P7 = 1 (01) P8 = 0 (00) P9 = 0 (00)
FXID[3] (ON) = 117 (75), GROUPID = 6 (06)
P1 = 10 (0a) P2 = 7 (07) P3 = 102 (66) P4 = 0 (00) P5 = 0 (00) P6 = 0 (00) P7 = 0 (00) P8 = 0 (00) P9 = 0 (00)
FXID[4] (ON) = 1 (01), GROUPID = 0 (00)
P1 = 0 (00) P2 = 0 (00) P3 = 0 (00) P4 = 0 (00) P5 = 0 (00) P6 = 0 (00) P7 = 0 (00) P8 = 0 (00) P9 = 0 (00)
FXID[5] (ON) = 1 (01), GROUPID = 0 (00)
P1 = 0 (00) P2 = 0 (00) P3 = 0 (00) P4 = 0 (00) P5 = 0 (00) P6 = 0 (00) P7 = 0 (00) P8 = 0 (00) P9 = 0 (00)
NumFX = 0 (00)
Volume = 0 (00)
TapTempo = 40 (28)
0c 05
OUTPUT
49 00 00 e4 00 04 00 0a 50 52 80 42 09 00 00 00 00 00
11 00 00 d0 03 78 00 23 50 10 60 19 00 00 00 00 00 00
75 00 00 4c 01 1c 00 33 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0 0c 05 45 6d 70 74 79 20 20 20 20 20 00
Allow patching of tempo, FXID etc. NOTE: if you just want to change a parameters value then you can do this directly with Sysex. I havent found yet if it is possible to set the FXID/GID - this is possible on the more modern pedals. On a B1On you can set the FXID but these leads to errors because I havent found how to set the GID. So far I have not found the MS-70 to respond. I will be correlating the "on pedal" patches with the ZDLs I have extracted from Zoom firmware NOTE: my pedals is some 2.x version with added FX. However, the official firmware updater is for a MS-50 pedal! And doesnt have as many FX. BUT I do have the Zoom Effects Manager and will be comparing values there.
I know how to set the tempo in unpacked space. Need to repack and send that. FXID/GID - I can derive what is changing (and hence how the repacked raw sysex) but I would like to see if the IDs I derive from the ZDLs is encoded some how.