REQ: Support for Roland SP-404 MK2 and SPD-SX (sampler formats)

[allcounter]

Hi Jürgen,

First, thank you for ConvertWithMoss (and DrivenByMoss). The detector→model→creator architecture and your careful *_FORMAT.md design docs are exemplary.

I'd like to request support for two Roland samplers that are absent from the current Roland coverage (MC-707/MV-8000/S5xx): SP-404 MK2 and SPD-SX. Both have large, active user bases (the SP-404 MK2 especially in beat-making), and neither is a ZEN-Core device — they're the SD-card sampler line (WAV samples in folders + binary project/pattern/kit data), so they'd be new format modules rather than variants of the existing Roland ones.

Why I think it's tractable, and how I can help: I own both devices and I'm currently building editors for them, so I'm actively reverse-engineering the formats. I can provide:

• Real exported project files from both — SP-404 MK2 SD-card projects and SPD-SX kits — across configurations (single/multi-sample, loops, various pad layouts).
• Any format notes I've gathered.
• Testing your builds on real hardware round-trips (import → device → export).

Would you be open to this? Happy to file separate issues per device if you prefer, and to structure the sample files however is most useful.

Thanks again — it's the reference framework in this space.

[douglas-carmichael]

@allcounter — I've opened #225 with a draft detector + creator for the SP-404 MK2, so there's something concrete to test against. (I'll leave the SPD-SX side to you — I haven't touched that format.)

What's in it:

• Reads a project folder: PADCONF.BIN (RFPD — both the 31,488-byte export form and the 52,000-byte device-internal form) plus the SMPL folder of BANK<b>-<p>.SMP samples (RFWV, 32-byte header, 48 kHz/16-bit, big-endian PCM).
• Since the MK2 is a pad sampler with no key ranges, each populated bank becomes one multi-sample and each pad a single-key zone — the same mapping ConvertWithMoss already uses for the MC-707 and Elektron drum kits.
• Writes the format back out. On a round-trip the audio is byte-identical and the PADCONF.BIN header and modeled pad fields come back byte-identical to a real device file, so conversions into the format work too.
• The reverse-engineering notes are in documentation/design/SP404MK2_FORMAT.md in that PR, so you can see exactly what's decoded and we don't duplicate effort.

Two things where your hardware and notes would genuinely help:

1. Does a written project actually import? This is the gap I can't close — I don't own the device, so I matched the byte layout of real exports as closely as I could, but that's not the same as a real IMPORT PROJECT. If you're willing to build the PR branch and try loading a project it writes, that would be the single most useful test.

2. The start/end/loop trim encoding. I have the field semantics — +0x04 play start, +0x2C loop start, +0x00/+0x08 data length, all byte offsets at 4 bytes/frame, and an untrimmed pad stores 512. What I couldn't pin from the projects I had is the exact frame base: (value − 512)/4 vs (value − 32)/4, about 2.5 ms. Some pads fit one, some the other, so there's a rule I can't see with the files available. Right now the reader deliberately extracts the full sample rather than risk cutting audio.

The quickest thing that would settle it: on one pad set Start to a spot you can identify (say exactly 1.000 s in), WRITE + EXPORT PROJECT, and tell me the raw value at record offset +0x04 (record N is at 0x80 + N×172 in the export form). A pad with an End trim and one with a custom loop start would confirm those two independently. Projects exercising mono samples, end-trims or custom loops would also make great regression material.

Thanks for filing the request with such a clear description of the format landscape.