summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorAndrej Shadura <andrew.shadura@collabora.co.uk>2021-10-07 16:12:09 +0200
committerAndrej Shadura <andrew.shadura@collabora.co.uk>2021-10-07 16:12:09 +0200
commitd4700c96fd551eea539921572c03842ecdc6c8c3 (patch)
treeac37ec6ef7d954feab5ad47c427e849f051da604 /HACKING
Import Upstream version 0.2.0+hg20110905r195
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING92
1 files changed, 92 insertions, 0 deletions
diff --git a/HACKING b/HACKING
new file mode 100644
index 0000000..3a0bc8b
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,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).