|
|
@@ -1,4 +1,4 @@
|
|
|
-# mpckit: MPC Sample project format and 0.5.0 / 2.0 scope
|
|
|
+# MPCkit: MPC Sample project format and 0.5.0 / 2.0 scope
|
|
|
|
|
|
Sources: three projects saved on an MPC Sample, in `testdata/device/` of `bajdev/mpckit` (first committed as `demo-projects/`), analysed 2026-11-10.
|
|
|
|
|
|
@@ -28,7 +28,7 @@ In:
|
|
|
- Export to a folder or zip: the `.xpj` plus its `_[ProjectData]` folder.
|
|
|
- Audio: WAV only.
|
|
|
|
|
|
-UI (mockup agreed 2026-11-10, "mpckit main screen mockup" artifact):
|
|
|
+UI (mockup agreed 2026-11-10, "MPCkit main screen mockup" artifact):
|
|
|
- Title row with an About link that opens a modal.
|
|
|
- Project name with New, Load, Export zip, Export to folder.
|
|
|
- Two tabs: Pads and Sequences. Each has bank buttons A-H, a 4x4 grid (pad 1 bottom-left) and a settings panel for the selected slot.
|
|
|
@@ -83,7 +83,7 @@ Rename the `.xpj` and the `_[ProjectData]` folder together. Nothing inside the f
|
|
|
5. Set `pad[n].tempo` to 20.0 (the value the device writes when the sample has no tempo).
|
|
|
6. Set `layer.sliceInfo.LoopCrossfadeLength` to -1 (what the device wrote for an untouched non-factory sample).
|
|
|
|
|
|
-The device gave the second pad its own copy of the file (`Linn 9000 kick001.wav`, byte-identical to the first) and its own pool entry. Sharing also works: a test project with two pads pointing at one file and one pool entry loaded and played (section 7), so mpckit can store each file once.
|
|
|
+The device gave the second pad its own copy of the file (`Linn 9000 kick001.wav`, byte-identical to the first) and its own pool entry. Sharing also works: a test project with two pads pointing at one file and one pool entry loaded and played (section 7), so MPCkit can store each file once.
|
|
|
|
|
|
### Move or copy a pad (proposed, not yet device-tested)
|
|
|
A pad's settings hold nothing that depends on its slot: all 128 blank pads are identical. So:
|
|
|
@@ -97,7 +97,7 @@ Recorded notes follow the slot, not the sample (a note stores 36 + n). Moving a
|
|
|
Three fields on the layer, written together:
|
|
|
- `layer.coarseTune` (semitones, integer; demo: 12)
|
|
|
- `layer.fineTune` (cents, integer; demo: 40)
|
|
|
-- `layer.pitch` = coarse + fine / 100, stored as a 32-bit float (demo: the device wrote 12.399999618530274; mpckit writes the shortest form of the same float64, 12.399999618530273)
|
|
|
+- `layer.pitch` = coarse + fine / 100, stored as a 32-bit float (demo: the device wrote 12.399999618530274; MPCkit writes the shortest form of the same float64, 12.399999618530273)
|
|
|
|
|
|
### Trim start and end
|
|
|
- `layer.sliceInfo.Start` and `layer.sliceInfo.LoopStart` = start frame (demo: 328)
|
|
|
@@ -218,7 +218,7 @@ Copy the blank sequence, set `sequences[].key` to the slot (0-based), then name,
|
|
|
- Seen: 44.1 kHz, 16-bit mono (user sample), 16-bit and 24-bit stereo (factory).
|
|
|
- Every file saved by the device carries extra chunks: `atem` (JSON: default slice, bar count, key), `smpl`, and on factory files `meta`. The non-factory kick has `atem` and `smpl` too, so the device adds them itself when it saves.
|
|
|
- The sample's key in the project (`C Natural Minor`) matches the `atem` chunk in its file.
|
|
|
-- Device-tested 2026-11-10 with plain WAVs placed straight into the project folder: 8, 16, 24 and 32-bit integer and 32-bit float; mono and stereo; 22.05, 44.1, 48 and 96 kHz all loaded and played at the correct pitch and full length. The device converts on load, so mpckit does not need to. `sliceInfo.End` is in the file's own frames at its own sample rate. Details and remaining unknowns are in the build plan, section 7.
|
|
|
+- Device-tested 2026-11-10 with plain WAVs placed straight into the project folder: 8, 16, 24 and 32-bit integer and 32-bit float; mono and stereo; 22.05, 44.1, 48 and 96 kHz all loaded and played at the correct pitch and full length. The device converts on load, so MPCkit does not need to. `sliceInfo.End` is in the file's own frames at its own sample rate. Details and remaining unknowns are in the build plan, section 7.
|
|
|
|
|
|
## 7. Device tests
|
|
|
|
|
|
@@ -243,8 +243,8 @@ Project name confirmed: the device shows `MpckitT1`, taken from the file and fol
|
|
|
Four projects written by the Go writer (`tools/checkpoint-a`, built from commit `f36cda3`). All loaded and passed on the device:
|
|
|
|
|
|
- **Kit** (`MpckitKit`): samples on A1-A4 and B1 play. Tuning at -24 and +24 semitones, -90 and +90 cents, and both combined (-24/-90, +24/+90) loads and plays as expected. Two hats in mute group 1 choke each other. Sequences of 1 and 64 bars work.
|
|
|
-- **Mute groups** (`MpckitMute`): the device offers none and 1-16. Pads written with group 16 choke each other; so do pads written with group 32, though editing such a pad's group on the device starts it at 16. mpckit writes 0-16 only.
|
|
|
-- **Tempo** (`MpckitTempo`): sequences at 20, 30, 300 and 999 BPM all work. The device's tempo control runs from 20 to 999, and mpckit uses the same range.
|
|
|
+- **Mute groups** (`MpckitMute`): the device offers none and 1-16. Pads written with group 16 choke each other; so do pads written with group 32, though editing such a pad's group on the device starts it at 16. MPCkit writes 0-16 only.
|
|
|
+- **Tempo** (`MpckitTempo`): sequences at 20, 30, 300 and 999 BPM all work. The device's tempo control runs from 20 to 999, and MPCkit uses the same range.
|
|
|
- **WAV headers** (`MpckitWav`): 48 kHz 24-bit stereo, 44.1 kHz 16-bit stereo and mono, all with the extensible header, play the same as a plain-header control.
|
|
|
|
|
|
Every item on the original 0.5.0 list (project name, pad sample assignment, sequence name, BPM, bar length, adding a sequence) plus pad tuning has now been written by these recipes and accepted by the device.
|
|
|
@@ -267,5 +267,5 @@ Five projects made from DemoFile in the app, exported, and loaded on the device
|
|
|
3. `triggerMode` values (0 and 3 seen) and how they pair with `loopMode`.
|
|
|
4. ~~When a sequence with notes is shortened, are notes past the new end kept or removed?~~ Answered 2026-11-11 (checkpoint B5): kept. They don't play while the sequence is shorter, and play again when it is lengthened on the device.
|
|
|
5. Sample rates outside 22.05-96 kHz and 64-bit float are untested. (The extensible header was confirmed in checkpoint A; other WAV bit depths and sample rates are confirmed; non-WAV formats are out of 0.5.0.)
|
|
|
-6. What key and tempo to write for a sample mpckit imports (the device detects them; mpckit cannot yet).
|
|
|
-7. Is `currentSequence` a slot number or an index into `sequences[]`? Every file seen has 0, and slot 0 is stored second, so the files cannot tell. mpckit treats it as a slot (build plan 4.3). Checkpoint B4 (removing the current sequence) worked, with Sequence 02 selected on open, but in that file slot 1 and list position 1 are the same sequence, so it does not tell them apart. Still open.
|
|
|
+6. What key and tempo to write for a sample MPCkit imports (the device detects them; MPCkit cannot yet).
|
|
|
+7. Is `currentSequence` a slot number or an index into `sequences[]`? Every file seen has 0, and slot 0 is stored second, so the files cannot tell. MPCkit treats it as a slot (build plan 4.3). Checkpoint B4 (removing the current sequence) worked, with Sequence 02 selected on open, but in that file slot 1 and list position 1 are the same sequence, so it does not tell them apart. Still open.
|
