Bank+Slots+Samples transfer to other project - CLI tool (demo)

Elektron Gear Octatrack
1

i’ve been working on this and some other tools in a rust library crate for over a year now (on top of ot-tools-io). this was the big tool i wanted to get right so it’s taken a while.

this is the age old most requested “thing” in this forum. so i figured i’d share it ahead of sorting out the rest of the library.

should work with properly updated OS 1.40A/B/C projects (see this note about ensuring a project is completely updated).

TAKE A BACKUP BEFORE USING THIS

i’ve tested this on one of my favourite projects by copying each bank over like for like (A → A, B → B etc.) and it seems to have worked correctly – every sample seems to be there and playing/trigging correctly. at the very least everything is in a “yeah i think that sounds like it’s supposed to” state.

i can’t guarantee it is perfect though. so i accept no responsibility if this breaks your projects and you cannot recover your data. it is your responsibility to take appropriate backups. my suggestion would be to run this tool on a local copy first, i.e. not using it directly on projects located on your CF card. maybe even copy into projects in a completely new set to start with.

i also recommend you read this post thoroughly to understand exactly what to expect from this tool.

downloads

usage

in a terminal / CMD / powershell etc. (on windows the binary file name has an .exe extension)

$ ./ot-tools-bank-transfer-demo --help

Usage: ot-tools-bank-transfer-demo [OPTIONS] <SOURCE_PROJECT_DIRPATH> <SOURCE_BANK_ID> <DESTINATION_PROJECT_DIRPATH> <DESTINATION_BANK_ID>

Arguments:
  <SOURCE_PROJECT_DIRPATH>
          path to the source project directory
  <SOURCE_BANK_ID>
          character id of the source bank to transfer [possible values: a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p]
  <DESTINATION_PROJECT_DIRPATH>
          path to the destination project directory
  <DESTINATION_BANK_ID>
          character id of the destination for the bank [possible values: a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p]

Options:
  -f, --force
          if the destination bank is not empty, force writing over it
  -d, --dry-run
          dry run -- will do everything up to copying / writing files
  -h, --help
          Print help
  -V, --version
          Print version

you can use LOG_LEVEL="debug" to increase logging levels (trace logs need some work).

LOG_LEVEL=debug ot-tools-bank-transfer-demo ./path/to/project/src a ./path/to/project/dest b

in CMD / powershell you need to use their respective methods to set an env var

CMD

D:\> set LOG_LEVEL="debug"
D:\> ot-tools-bank-transfer-demo.exe .\path\to\project\src a .\path\to\project\dest p

powershell

PS D:\> $env:LOG_LEVEL="debug"
PS D:\> .\ot-tools-bank-transfer-demo.exe .\path\to\project\src a .\path\to\project\dest p

how it works

for Static and Flex slot types [0]

  • get slot assignments from source bank – Part Track Machine and Pattern P-Lock [1]
  • plan slot transfers into the destination project slot list
    • if source slot exists in destination [2] [3] [4]: remap bank slots (machine/p-locks) to existing destination slot
    • if source slot does not exist in destination – create new slot in destination, remap bank slots (machine/p-locks)
  • apply slot transfers to data in memory [5]
  • plan sample file transfers for files related to newly created slots

then, if not using --dry-run

  • writes octatrack project files
  • copies sample files incl. .ot files [6]

[0]: recording buffer slots are not transferred in any way shape or form, even if you’re using them as extra flex slots

[1]: only the working copy of a part for a bank is transferred – i.e. the part data that’s actually live and changes when you twiddle with knobs. during the transfer parts are essentially force saved.

[2]: 128 slots / 16 banks = 8 slots each if distributing slot usage evenly. unfortunately, most of my banks use at least 12 samples (on average). free slots in a project fill up very quickly if there’s no deduplication. so that’s why the tool looks to re-use existing slots where possible.

[3]: slot matches are based on fields in the slot’s data excluding the slot id. so path, trim stretch, trig quantization, gain, bpm etc. i’ve assumed a slot path myfilename.wav in two projects is the same file. because it is usually true for me, and i built this tool primarily for me.

[4]: source project audio files ARE NOT CHECKED against the destination audio files. if you have multiple sample files across projects/sets etc which use the same name but are actually different sample files … this tool will cause breakage. name your sample files better? :shrug: … see end of [6] for cases when this is likely to happen

[5]: things are split into “planning” and “comitting” stages because iterating over each source slot and copying files one-by-one etc can lead you to a point where you run out of slots, but you’ve already been copying sample files etc. i ran into this about 9 months ago and spent circa 3-6 months rewriting the whole library around this problem. massive PITA.

[6]: if the above shared file name case from [4] happens then the original file will be unrecoverable as it will have been written over. this should only happen it two specific cases (same name different file in two set audio pool directories, same name different file in two project directories)

i’m gonna go watch netflix and hopefully get a good night’s sleep now.

have fun.

3 Likes
2

updated binary files with fix for possible checksum issues