-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to find G1XFour drum pattern data and encode it #77
Comments
@nopeg Correct, the script just parses the binary data - the format is guessed from staring at the hexdump and figuring out what it might mean. The binary search I did was just to help you locate the data in the G1X_Four FW, which turned out to the be the same as G1_Four. The bytes that you highlight in your image are suspected to be a 3 byte pointer to the data which defines how the pattern plays the samples:
The script has the
The actual value of the pointer is uncertain. I suspect that it is the memory location of data after the file is loaded - rather than the offset of data within the file. It seems that the deltas between the pointers match the file data, so I use this... https://github.com/mungewell/zoom-zt2/blob/master/decode_patterns.py#L116
So a little note/clue to help you understand 'construct' better. The If you use the
|
If you wanted to create your own patterns, I guess you have to answer whether the understanding of the formatting is correct and whether it's possible to change it within the 129 file... which could then be repacked into the FW EXE file. Hint: Found this tool, which was able to replace the '133' file in the exe. I suspect that you'd have to work within the space already used/allocated in the file, as to not overwrite/displace data after the drum data. Maybe a first test would be to swap over the pointers and/or drum data to confirm that you can actually create a FW image and hear the effects of a change. This first step(s) might just be with a hex-editor and manually changing data. The script/Construct parse could then be used to automate the process. Q2. Does the pedal freak out when there are less (or more) items in the 'table' (with names/samples)? |
I have a nagging memory that the data for the drums may not be contiguous, IIRC it was split - so you might find that there's some other stuff in the middle that you will need to avoid corrupting.... |
Yes, I used this tool alongside HxD (https://mh-nexus.de/en/hxd/) to manually modify the pattern tables (in those headers in 129 file)
It seems to be working fine when I change any item:
yeah thats a problem. is there any way to tell which of the data is drum bytes? |
Looks like you are making good progress. I am travelling this week so away from my equipment. I didn't understand what you were trying to achieve with '3'. Just adding the 'Kik1.raw' name would not cause the sound, and it looks like the file name was added in the wrong place/address. The space for each of these names are 12 bytes long. Triggers would have to be added to the drum https://github.com/mungewell/zoom-zt2/blob/master/decode_patterns.py#L37 I'll refer back to the ASCII are representation; if you modify the |
Indeed it's not clear how the patterns data is being assembled and referenced after it's loaded, though this somewhat resembles section addressing (or resource references). If you look closer at the file offset So, for each rhythm the descriptor includes a section offset ("pointer") of its pattern sequence. To translate this into file offset the following formula can be used:
0x08 is to account for the section's base details (2 ints for offset and size). As for the pattern sequence, if one follows the formula above, it appears that the pattern is a sequence of two-byte events each consisting of the following details:
This yields somewhat differing file offsets than what's reported from the @mungewell script, but the pattern data is essentially the same; the difference is in the first spacing byte which is always 0x00, at least for G1 FOUR patterns. Pattern sequence data appears to be compiled in, so replacing it may be limited by length of the available "slots". Spilling over the slot most likely would corrupt the firmware. While most patterns (except for "Metro" and the actual "Dummy" sequence) are two-bar length, yet the number of events differs based on the complexity of the pattern. It may be fun to try to script some "upload" for rhythm patterns, but it may be too much of an effort for the purpose, as there are plenty of other choices to produce a rhythm track for practice. By the way, A1 FOUR packs quite a bit differing rhythms and sequences, though lacking fw updates it's not very likely to dig those from the pedal's internals. P.S. Impressive work effort by @mungewell to dig this out and nicely visualize the rhythm sequence!! |
As I understand
decode_pattern
finds offset from the bitmap of this header at which actual pattern data is storedI understand that this script is just a parser that uses construct to decode pattern data from the memory pointed to
The binary search confirmed that the location of the data is at the same offset (I don't know what is the next step)
I need help with understanding some basics of binary search and decoding all this stuff, like how to use decoded patterns to see how this system works.
Sorry in advance for my incompetence
The text was updated successfully, but these errors were encountered: