1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
In general everything brings down to figure out:
-ID
-Position
-Possible value range
There seems to be three possible ways to figure that out.
1) Use USB sniffer together with X-Edit
Once you set up X-Edit and usb sniffer, set some option.
USB sniffer should report something like this being sent to device:
(all numbers here are hex)
04 F0 00 00 04 10 00 5E 04 02 41 00 04 30 09 00 07 00 34 F7
MIDI data is transferred over USB using 32-bit USB-MIDI Event Packets.
Byte 0 is Cable Number (high nibble) and Code Index Number (low nibble).
Bytes 1, 2 and 3 are data.
Every bulk transfer on USB MIDI endpoint contains atleast one such packet
(those are sent one after each other).
In case of Digitech devices, the Cable Number seems to be 0 (correct me,
if I'm wrong).
There are three different Code Index Numbers that are being used in this
particular case:
0x4 - SysEx starts or continues (Byte 1, 2 and 3 from this packet are
part of our MIDI message)
0x5 - SysEx ends with following single byte (we just need to take Byte 1
from this packet)
0x6 - SysEx ends with following two bytes (we just need to take Byte 1 and 2
from this packet)
0x7 - SysEx ends with following three bytes (we need to take Byte 1, 2 and 3
from this packet)
Unused bytes in USB-MIDI packets are supposed to be 0.
To get SysEx command out of it, apply above rules, so we have:
F0 00 00 10 00 5E 02 41 00 30 09 00 00 34 F7
SysEx message format seems to be formed like this:
SysEx start byte - F0
Manufacturer ID - 00 00 10
Device ID - 00
Family ID - 5E (RP)
Product ID - 02 (RP250)
Procedure - 41 (see MessageID in gdigi.h)
As MIDI messages must not contain bytes with MSB bit set, Digitech
devices use packing system.
First byte contains MSB bits from following 7 bytes (this scheme
continues as many times as needed) (see pack_data() and unpack_message() in
gdigi.c for details).
Assuming message has been unpacked, the meaning of next bytes:
ID - in this example 30 09
Position - in this example 00
Value - in this example 00 (can be more bytes long, see below)
Checksum - to calculate it, XOR all bytes (of packed message)
Every message ends with F7
So for above example:
ID = 3009 (hex) = 12297 (decimal)
Position = 0
One of possible values is 0. Usually value range is 0 to 99,
albeit in some cases it's different - you have to check what values can
X-Edit assign (there doesn't seem to be any sanity check in firmware)
This is especially needed for IDs that set some effect type.
2) Save preset patch
Patches seem to be simple XML files.
Every parameter is written like this:
<Param>
<ID>65</ID>
<Position>2</Position>
<Value>0</Value>
<Name>Pickup Enable</Name>
<Text>Off</Text>
</Param>
ID is ID, Position is Position and Value is one of possible values.
To get all possible values you can:
do
change value to next one possible in X-Edit
(for example next effect type)
save new patch
check patch file and note the change
while you don't have all possible values
3) Use gdigi
After starting gdigi turn the knobs on your device.
Check out console output, you should notice something like this:
** Message: Received parameter change ID: 210 Position: 4 Value: 0
ID is ID, Position is Position and Value is one of possible values.
To get all possible values keep turning knobs and watch the output.
If you change effect type usually there's more messages - where,
usually the first one is type change, and rest are default values.
This way you *CANNOT* gather all information (there're X-Edit only
controlled values, check device manual for more information).
|
