been working on reverse engineering the octatrack’s data files over the last few months. the result is this rust library crate which can be used to read/inspect/modify/write .work and .strd data files.
i’ve got most of the files worked out. there’s only a few missing fields left. and arrangement checksumming (which has been doing my head in).
releasing / publicising it now because i’ve got some life stuff this has been distracting me away and it’s in a decent enough state to be ‘useful’, even just as a reference. there are probably some bugs / code still needs cleaning up. so bear that in mind.
Hey, congrats, that is big. I was trying not to get pulled in the RS trend, this might change my mind.
I would definiiley compile the examples and run them, I’ll post issues if anything shows up.
Very interested by the checksum computation, I had been too lazy to look into it seriously. I believe pple at Elektroid, Octalib or Octachainer would be interested too !
I really want to be interested in this, because I’m usually really interested in Octatrack utilities. Sadly, I don’t understand any of the documentation and have no idea what any of this actually does. (that’s not a criticism; well, it is, but not of you or this, simply of me lol…I’m bad at anything more complex than CSS )
Very interested by the checksum computation, I had been too lazy to look into it seriously
i think working out bank checksums was like the second or third time i’ve ever gotten really emotional over code that i’ve written (is still a very draft version, need to rework it as quite hacky).
yeah, i wouldn’t have a year ago either this was a good hobby project to start learning rust with … it can be a bit of an opaque language until you understand some of it.
if you focus on the ‘structs’ and ‘modules’ and read the fields in the structs you should notice stuff that’s familiar to the octatrack menus. like Part in ot_tools_io::banks::parts - Rust
Congrats on the release! And also on having the patience to reverse-engineer the OT binary file formats, I know from experience that that is a slog of a job.
Any plans to build out a UI for this, or will it be strictly CLI? Also, I see you have this on GitLab and GitHub, will those two repos be kept in sync?
also, I see you have this on GitLab and GitHub, will those two repos be kept in sync?
ah yes … erm … well …
i forgot about the sync’d github release repo… i’ve hidden it for now as that was synced from an ‘older’ gitlab repo which has some ‘extras’ you’ve obviously seen …
i’ve been figuring out copying banks between projects – turns out to be quite complicated but i’m a decent way there with it. needs a lot of clean up and scanning the markers settings file though.
so yeah, might be more stuff coming. needs some work before i’ll be happy with it. but also don’t want to over promise anything.
Any plans to build out a UI for this, or will it be strictly CLI?
I’d only do a CLI.
I’m more interested getting additional language bindings for the io library and the ‘extra’ library for python, nodejs, c# etc – so other people can make UI based tools / apps in other languages.
i spent several days in a coffee shop trying to get the octarranger implementation to work. it didn’t work for all arrangement test files. it only works for some of them.
using a modified version of your pastebin dump running against a number of previously ignored test case
it may be a path towards getting it working, but it doesn’t seem to be the correct implementation just yet.
having said that, the test data for arrangements was done quite a while ago. might be worth someone sitting down an walking through them to double check they do what they say in the filename. (TIP – use ot-tools-io to create a corresponding yaml file for each test file, then read through the yaml file to confirm it does what then file name indicates).
additional note on the pastebin code – it was incorrect/unsuitable to merge in in several ways
the OtToolsIoError::ChecksumError enum variant doesn’t exist
the while loop always errors due to index out of bounds: the len is 11336 but the index is 11336
the bytes length check is redundant
inconsistent code style versus other calculate_checksum implementations
too heavily commented e.g. // Serialize the entire file to bytes (including current checksum placeholder) for the let bytes = bincode::serialize(&self)?; line.
at the very least, please test code submissions and confirm it works if using ‘next-word-with-highest-probability’ generators (basically, the first two bullet points)
also, non-UTF-8 character parsing for project files should hopefully be fixed too. along with a more obvious error message when there’s a OS version mismatch.