93 lines
3.8 KiB
Plaintext
93 lines
3.8 KiB
Plaintext
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).
|