Tonverk: SD card - about its folders and filetypes ONLY

Elektron Gear Tonverk
63

Some more things I noted:

  • presets don’t support folders, everything that is in a subfolder is ignored
  • wavetables can be sorted into folders, and the maximum number of characters displayed in the wavetable selector is 20, so longer file names (excluding the number of samples per frame) are not helpful
64

I’ve refreshed the collective knowledge from everyone’s posts in a new header post to this topic. Hopefully useful

Also, given the direction of travel with discoveries, Python can sit in the middle of this whole Tonverk + SD‑card ecosystem as the “glue” layer: generating the TOML mapping files, enforcing conventions, and automating all the tedious file operations that the box itself is bad at.

Below are ideas -

1. Instrument and kit generation

Given the text‑based .elmulti / .eldrum formats, Python is ideal for turning large sample libraries into Tonverk‑ready instruments.

Typical tasks:

  • Scan a folder tree of WAVs and build .elmulti per instrument or per articulation (e.g. “Piano Bright”, “Piano Soft”).
  • Derive MIDI note and velocity from filenames (e.g. Piano_C4_vel080.wav), map to pitch, key-center, and velocity, and emit a TOML mapping automatically.
  • Build .eldrum kits from a set of one‑shots, enforcing a consistent pad layout (e.g. C3 kick, D3 snare, etc.) using a simple config file that defines the scheme.
  • Batch‑generate preview variants (e.g. “Lite” kits with fewer layers, or round‑robin vs. single sample‑slot) from the same underlying WAVs.

Result: you treat your sample libraries as data, and Python as your instrument compiler.

2. Path, rename, and refactor tooling

Because presets and mappings use file paths and filenames directly, reorganising the SD card by hand is fragile.

Python can:

  • Parse .elmulti, .eldrum, and .tvpst as TOML, then rewrite paths when you:
    • Move an instrument to User/JustinLib/....
    • Standardise naming (e.g. adding prefixes like JVN_).
  • Detect broken references by walking all mapping/preset files and checking that every sample = ... path exists on the SD card clone on your PC.
  • Produce a “link‑check” report before you sync to the card, similar to a static analysis pass over your sound library.

Effectively configuration management for the SD card: a Python script becomes the single source of truth for folder layout and naming policies, and you apply it before writing to hardware.

3. Mass editing and normalisation

The formats encode more than just which sample plays; you can programmatically adjust the sound‑design layer.

Examples where Python is handy:

  • Normalize or loudness‑match large libraries using ffmpeg or sox via subprocess, then regenerate mappings.
  • Auto‑trim silence and apply fade‑ins across thousands of samples to mitigate perceived latency in multisamples.
  • Insert or tweak loop points in .elmulti for sustained instruments (you can store loop metadata in a sidecar JSON/YAML and have the script write the TOML fields like loop-enabled, loop-start, loop-end).
  • Apply systematic parameter changes to presets: e.g. “make a darker version” by reducing filter cutoff and send level across a folder of .tvpst files.

This gives you “programmatic sound design” at the layer where Tonverk exposes parameters in text, without touching the box.

4. Staging, backup, and synchronization

Treat the SD card as a deployment target and Python as the deploy tool.

You can:

  • Maintain a canonical repository on your NAS or workstation with:
    • Raw sample libraries.
    • Config for how they become Tonverk instruments.
    • Generated .elmulti, .eldrum, and .tvpst under build/.
  • Use Python to:
    • Build or rebuild all instruments from source libraries.
    • Compare the build output with the SD card (rsync‑style), copy only changes, and optionally timestamp/backup previous versions.
    • Snapshot .system and Elektron/User content for quick rollback if you experiment and want to revert.

SD contents become a compiled artefact, not something edited directly in “production”.

5. Companion utilities and UX

A couple of community examples show that lightweight companion tools are already emerging; Python lets you build your own variants alongside them.

Potential tools you’d probably actually use:

  • A CLI browser that prints a tree of instruments/kits, showing: sample count, key range, velocity layers, and whether any samples are missing.
  • A simple local web UI (Flask/FastAPI) that lets you:
    • Drag‑and‑drop WAVs to define a kit layout or keymap.
    • Edit loops and velocity splits in a grid.
    • Export the result as .elmulti/.eldrum into your Tonverk library.
  • A “library auditor” that enforces rules like: no more than N velocity layers per instrument, sample names within length limits, and paths below a certain depth.

These don’t need to be polished products; even rough internal tools would eliminate a lot of repetitive menu diving.

6. Integration ideas

  • Git + Python: version control not just the scripts but also the generated mapping files (or at least their configs), making regressions obvious.
  • Templated configs: define “instrument recipes” (e.g. number of layers, tuning scheme, FX defaults) as TOML/YAML, and have Python render both the .elmulti and a matching .tvpst starter preset with your preferred filter and FX template baked in.
  • Scheduled tasks: if you have a central box (or a WSL/cron environment), run periodic checks, rebuilds, or backups of the Tonverk library.
3 Likes