Thought I’d provide a refreshed header topic starter summarizing what we’ve learned so far as at 3rd June 2026, as below. Will try to another refresh in maybe a few months if helpful!
SD card structure: what’s known
- The card is FAT32 in Elektron’s factory image, with three top‑level folders:
.system,Elektron, andUser. .systemcontainsactive_projectwith various project‑state files; it is visible on Windows, and on macOS it behaves like a normal dot‑folder (hidden unless you show hidden files).Elektronholds the factory content, including the Tonverk Factory Library with drum sets, multisamples, single samples, and other bundled material.Usermirrors the factory library structure and is the default target for saving projects, presets, samples, instruments, etc. Elektron explicitly recommends putting your own content only underUserto avoid collisions with factory assets.- Samples are not project‑local: if you move or delete samples or folders, all projects referencing them will lose those sounds and show them as missing.
Illustrative takeaway: the SD layout is essentially a shared asset pool, where projects and presets hold references into a common sample tree rather than embedding audio.
File types: format and semantics
.eldrum (Drum Set mapping)
.eldrumis a human‑readable TOML mapping that defines an Elektron drum set.- Structure is based on repeated
[[key-zones]]sections, each containing a MIDIpitch,key-center, and nestedvelocity-layers, which in turn containsample-slotswith asamplefile name. - The
sampleentries expect filenames located in the same folder as the.eldrumfile. - Values such as
velocityandstrategy(e.g.Forward) define velocity mapping and playback mode per zone.
Net effect: .eldrum is a straightforward TOML version of a multi‑zone drum kit definition, conceptually similar to SFZ key/velocity mapping but in TOML syntax.
.elmulti (Multi‑sample Instrument mapping)
.elmultiis also TOML and structurally very similar to.eldrum, but used for melodic multisampled instruments.- It also uses
[[key-zones]]withpitch,key-center,velocity,strategy, and per‑zonesampledefinitions. - The file includes a header with
# ELEKTRON MULTI-SAMPLE MAPPING FORMAT,version, andnameof the instrument. - Samples referenced in
.elmultilive in the same folder, named with Tonverk’s autosampling convention (e.g.4 Toys-000-060-c3.wav).
Important nuance from the thread: on‑device autosampling aggregates individual WAVs into a single “chain” file internally, but the exported .elmulti mapping still references the individual WAV files when using a PC‑based workflow. This suggests the format supports both “many files” and “single chain” backends.
.tvpst (Preset)
.tvpstis again structured as a TOML‑like plaintext file containing aversion,category, optionaltags, a huge[parameters]table, and a nested[parameters.gen_drum_mapping_slot]structure with its ownkey-zonesmapping.- A preset does not embed audio; it holds references to samples or instruments on the SD card:
- Single Player: one sample path.
- Subtracks: up to eight separate samples collected as a drum‑style instrument.
- Multi Player: one multisample instrument (.elmulti).
- The preset also captures the entire track sound‑engine state: SRC machine choice, filter settings, amp envelope, two insert FX configurations, modulation, LFOs, performance mod destinations, etc.
- If the track uses the MIDI machine, the preset contains no sample references at all.
The [parameters.gen_drum_mapping_slot] section demonstrates full absolute paths like /mnt/sdcard/Elektron/Tonverk Factory Library/..., confirming that presets can reference assets anywhere on the card, not just in a local directory.
Design inferences and practical implications
- All three formats (.eldrum, .elmulti, .tvpst) are built on TOML and visibly borrow ideas from SFZ‑style key/velocity mapping. Posters infer Elektron used TOML rather than XML to keep the format extensible and easier to evolve without full SFZ compatibility obligations.
- Because the formats are text and relatively regular, several participants note that simple scripts/utilities should be easy to write for:
- Bulk editing mappings or parameters.
- Renaming and path‑rewriting when you reorganize your sample folders.
- Generating
.elmultimappings from a directory of chromatic samples. - Fixing “virtual latency” by trimming silence or adjusting mapping parameters.
- There is an explicit interest in a browser‑based instrument maker that would take WAVs (drag‑and‑drop), generate the corresponding mapping files and folder structure, and output Tonverk‑ready content.
Mentioned in the post below: a utility that can turn pre‑existing multisample sets (e.g. “All the Samples from Mars”) into Tonverk multisamples, supporting both “individual slices” and “sample chain per velocity layer” modes.
Still‑open or partially answered questions
1. Exact behavior of .system and project internals
- While
.system/active_projectis known to contain project‑related files, the thread does not fully document their individual schemas or which parts of project state live there vs in.sstproject files. - It is not fully clarified whether users should ever manipulate
.systemdirectly, or whether doing so risks corrupting state; the practical advice is implicitly “leave it alone”.
Unanswered angle: a rigorous mapping of project‑level state across .system, .sst, and other internal files.
2. Path rules and portability constraints
.tvpstexamples show hard‑coded absolute paths (/mnt/sdcard/...), while.eldrumand.elmultimappings shown use local filenames only.- There is no definitive statement in the thread on:
- What happens if you move a mapped instrument to another folder and then bulk‑update paths.
- Whether paths must stay within
Elektron/Useror can be arbitrary. - How robust presets are to path changes across cards (e.g. a user‑cloned card with slightly different folder layout).
In practice, it is clear that moving or deleting files breaks references, but the exact rules for safe re‑organization plus automated rewriting remain to be systematized.
3. Performance implications: chain vs many files
- One user notes that Tonverk internally “aggregates all the samples into a single file” for multisamples, and the utility they are building can either use individual slices (robin mode) or a sample chain per velocity layer.
- They speculate, reasonably, that reading a single large sample buffer could be more efficient than opening many small files, especially for large, detailed multisamples with thousands of slices.
- However, there is no benchmark data in this thread specifically comparing:
- On‑device performance of native autosampled chain vs multi‑WAV PC‑generated
.elmulti. - Impact on load times, polyphony, or glitch resistance in extreme cases.
- On‑device performance of native autosampled chain vs multi‑WAV PC‑generated
So the optimal engineering pattern for massive multisample libraries (chains vs many files) remains an open performance‑tuning question.
4. Official vs community tooling for instrument creation
- Multiple posts express a desire for:
- An Elektron‑provided utility to create Multi Player instruments from existing WAV collections.
- Or at least documentation and support for third‑party tool authors.
- Elektron has not, in this thread, announced such a tool, and a respondent from “Samples From Mars” indicated they have no current plans to add
.elmultifiles to their libraries and are not familiar with Tonverk yet. - One community developer states they are actively working on a converter/utility, but the thread does not yet present a finished, widely available tool with full feature coverage.
Open area: a mature, documented, widely‑used toolchain for generating .elmulti and .eldrum programmatically from third‑party libraries.
5. Specification completeness and versioning
- The example files show
version = 0(for.eldrum/.elmulti) andversion = 2for.tvpst, but the thread does not contain an explicit spec of what each version number implies, or which fields are optional/required. - There is no clear backward‑/forward‑compatibility guidance (e.g. how Tonverk behaves if it sees unknown keys, or how future OS versions might extend these formats).
Unanswered: a formal, “spec‑level” description of these formats and their evolution, which would matter if you’re building robust external tooling.
Practical “known‑good” working guidelines
Based on the thread, the following practices are safe and supported:
- Keep user content under
Userand do not edit.systemor factory content unless you really know what you are doing. - When designing libraries, treat
.eldrumand.elmultias TOML mapping layers over 48 kHz mono/stereo WAVs or AIFFs; other sample rates will play but with some quality degradation. - If you plan to re‑organize samples, expect to update paths in
.tvpst(and potentially.elmulti/.eldrum) or accept broken references. - Building small utilities in Python or similar to:
- Generate mapping files from directory listings.
- Rewrite paths.
- Apply systematic parameter tweaks.
is entirely feasible and aligns with how the formats are structured.



