The 1010music Blackbox and the Bitbox mk2 share the same firmware architecture and the same preset model. So does the Bitbox Micro. A preset built on the Blackbox loads correctly on the Bitbox mk2, and vice versa, because the underlying file format is identical. Understanding that model once covers all three devices.
This guide explains how presets are structured, how they reference audio files, the Pack Preset command, multi-sample folder loading, and how to migrate presets between cards or share them with another user.
What a preset actually is
A 1010music preset is a folder. It lives inside the Presets/ directory at the root of the microSD card, and it always contains a file called preset.xml. That file stores the complete state of the preset: which sample or folder is assigned to each pad, the playback mode, envelope parameters, effect settings, and routing.
microSD Root/
└── Presets/
├── DrumKit01/
│ ├── preset.xml
│ └── RC000001.wav
└── SynthPads/
└── preset.xmlThe audio files themselves don’t have to live inside the preset folder. By default, they don’t. Pads reference samples by their absolute path on the card, so your kicks, loops, and textures can be organized into whatever folder structure works for you. The preset just points to wherever they are.
How presets, pads, and sample folders fit together
A preset is what you save, load, and recall. The folder name is the preset name. Everything you’ve configured lives in the preset.xml inside it.
A pad is one of the 16 sample slots on the touchscreen. Each pad holds a path to a WAV file or folder on the card, plus all the playback parameters for that slot. The pad contains settings, not audio. When you reassign, rename, or move the file a pad is pointing to, the pad goes silent on the next reload because the path in preset.xml no longer resolves.
Sample folders are the audio collections elsewhere on the card. They can be organized any way you like: by instrument, by genre, by session. The only constraint is that the paths in preset.xml need to resolve at load time.
The path dependency is the thing behind most preset problems. Build a preset, then reorganize your sample library, and the pads that pointed to moved files go silent. The XML wasn’t updated when you moved the files. Pack Preset (covered below) is how you protect against this before sharing or reorganizing.
Inside preset.xml
The preset.xml is a plain text file. You won’t normally edit it by hand (the device writes it every time you save), but it’s worth knowing what it contains.
For each pad, the XML stores the assigned sample path, the pad mode (One-Shot, Gated, Clip, Granular, Slicer), start and end points, envelope parameters, filter settings, effect send levels, and (on the Bitbox mk2) CV and gate routing. When you load a preset, the device reads this file and reconstructs the entire pad layout from scratch.
The path format is what changes when you pack a preset. An unpacked preset has absolute paths from the card root:
<sampleFile>/Drums/kicks/kick_hard.wav</sampleFile>After packing, the paths are relative to the preset folder:
<sampleFile>kick_hard.wav</sampleFile>Relative paths resolve from wherever the preset folder lands, so the preset works on any card regardless of how the rest of the card is organized.
Multi-sample folder loading
Instead of pointing a pad to a single WAV file, you can point it to a folder. The device reads all the WAV files in that folder, sorts them alphabetically, and maps them to consecutive MIDI notes starting at C2.
A folder of three files:
Kicks/
├── 1_kick_soft.wav → C2
├── 2_kick_mid.wav → C#2
└── 3_kick_hard.wav → D2Alphabetical order controls the mapping. Prefixing files with numbers (1_, 2_, 3_) is the standard way to set the sort order explicitly. Without numeric prefixes, ASCII alphabetical applies: uppercase letters sort before lowercase, which can produce a different order from what you expect when filenames are mixed-case.
Multi-sample loading covers two different use cases. For drum kits it’s typically velocity layers: kick_soft.wav, kick_mid.wav, kick_hard.wav triggered at different MIDI velocity ranges. For melodic instruments it’s chromatic mapping: a folder of piano notes or synth tones recorded at consecutive pitches maps into a playable keyboard instrument on one pad. On the Bitbox mk2, a sequencer or keyboard elsewhere in the rack drives pitch via CV and MIDI. On the Blackbox, an external MIDI controller does the same job.
The starting note is C2. If you’re building a melodic multi-sample and need specific octave placement, plan the folder contents accordingly: the first file alphabetically lands on C2, each subsequent file steps up a semitone.
Recording and the RC naming convention
All three devices record audio from their inputs directly into the active preset’s folder. The naming is automatic: the first recording saves as RC000001.wav, the next as RC000002.wav, and so on. The recording is automatically assigned to a pad in the preset immediately after capture.
Presets/
└── DrumKit01/
├── preset.xml
├── RC000001.wav
├── RC000002.wav
└── RC000003.wavTakes accumulate numerically without overwriting each other. If you record a lot during a session, the preset folder fills up with numbered files. Before sharing a preset, prune the recordings you don’t need so the recipient doesn’t receive a folder of outtakes alongside the preset XML.
Pack Preset
Pack Preset is the command that makes a preset portable. Without it, preset.xml contains absolute paths, and those paths only resolve on the card where they were originally written. Copy the preset folder to a different card or hand it to another user, and the paths break: the device can’t find the samples.
Run Pack Preset and the device copies every WAV file the preset references into the preset folder, then rewrites the XML paths to point to those local copies. After packing, the preset folder is self-contained. Everything it needs is inside it.
On the Blackbox and Bitbox mk2, Pack Preset is in the preset management screen. Hold the preset name in the browser to bring up the preset options.
Two things to know about how it works:
Pack Preset copies files, it doesn’t move them. Originals stay in their source folders; the preset gets its own copies. If the same kick appears across 20 presets and you pack all of them, you’ll have 20 copies of that file on the card. On a 256 GB card this is almost never a problem. On a 64 GB card with many large presets, duplicate copies are worth accounting for.
Pack Preset only copies files it can find. If a pad was already pointing to a missing or moved file before you ran it, that pad doesn’t get packed. The file can’t be copied if it isn’t there. Reassign any broken pads to their correct files on the source device, save the preset, then repack.
Sharing and migrating presets
The workflow for sharing a preset:
- On the source device, load the preset you want to share.
- Run Pack Preset.
- Remove the card and open it on a Mac or PC.
- Copy the preset folder from
Presets/to the destination card’sPresets/directory, or zip it and send it directly. - The recipient drops the folder into their card’s
Presets/directory and loads it.
No path adjustments are needed because Pack Preset rewrote the references to relative paths.
Migrating between your own cards follows the same process. If you’re building presets on a studio card and want to move specific presets to a live performance card, pack them first, copy the folders, and you’re done. The destination card doesn’t need to have your entire sample library; packed presets carry their own audio.
Moving an unpacked preset manually is possible but requires copying both the preset folder and every audio file it references while preserving the same directory hierarchy from the card root. That’s tedious and easy to get wrong. Pack Preset does it correctly and automatically.
Common problems
Pads are silent after copying the preset. The preset wasn’t packed before copying. The preset.xml contains absolute paths from the original card. Those paths don’t exist on the destination card. Go back to the source device, run Pack Preset, then copy the folder.
Some pads are still empty after packing. Those pads were pointing to missing or moved files before Pack Preset ran. It can only copy what it can find. On the source device, tap each empty pad, open the file browser, navigate to the file’s current location, reassign it, and save the preset. Then repack.
Multi-sample mapping isn’t landing on the expected notes. The files are sorting alphabetically in a different order from what you intended. Check for mixed case (uppercase letters sort before lowercase), unexpected leading characters, or missing numeric prefixes. Rename with explicit numeric prefixes to take control of the sort order.
A Blackbox preset doesn’t have CV routing after loading on the Bitbox mk2. CV assignments are a Bitbox mk2 feature. The Blackbox doesn’t write CV routing data into preset.xml because it has no CV inputs. The preset loads correctly, but you’ll need to set up CV assignments on the Bitbox mk2 after loading.
The preset folder is much larger than expected. Either in-session recordings have accumulated (RC000001.wav and counting), or Pack Preset has duplicated large sample files that appear in many presets. Delete recordings you don’t need, and on small cards, consider which presets actually need to be packed versus which can stay path-referenced.
The Bitbox mk2 sample management guide covers the CV integration, polyphony budget, and granular mode in more depth for Bitbox mk2 users. If you’re preparing a library to populate multiple presets from a consistent source, SampleStack reads WAV, AIFF, and FLAC, converts to the format your device expects, and writes a clean folder structure to the card that preset paths can reference reliably.