Waldorf Quantum/Iridium: add a Sample location option for QPAT sample paths

[douglas-carmichael]

Problem

A QPAT preset created by ConvertWithMoss and placed on the SD card of a Quantum/Iridium does not load its samples automatically — the device shows the "Find Sample Map" screen and asks you to locate the samples by hand. On a busy patch, that manual resolution can also noticeably tax the CPU.

Cause

Each sample-map path is written with a leading drive number that tells the device which drive physically holds the samples (it copies them into internal memory when the preset is loaded). This was hard-coded to 4:. On the Iridium (OS 4) the drives are 2: = SD card, 3: = internal memory, 4: = USB drive — so the hard-coded 4: only resolves for samples placed on a USB drive, and a samples folder on the SD card is never found.

So the original 4: was correct for USB users; it only ever broke SD-card users. Changing it to another single hard-coded prefix would just move the breakage to the other group — hence an option rather than a different fixed value.

Fix

Add a "Sample location" option to the creator — SD card (the new default), USB drive, or internal memory — which selects the drive number written in front of the sample paths. Copy the preset together with its samples sub-folder to the matching drive and it loads automatically; the device copies the samples into internal memory.

• GUI: a drop down under the Waldorf QPAT options.
• CLI: -p QPATSampleLocation=2|3|4 (2 = SD card, 3 = internal memory, 4 = USB drive).

Reading is unaffected — the detector already strips any N: drive prefix. The CHANGELOG and the format documentation (a new "Loading the result on the device" note) are updated to match.

The drive numbers were hardware-confirmed on an Iridium (OS 4.0.5); they may differ on the Quantum or other firmware, which is exactly why the value is user-selectable rather than hard-coded.

[douglas-carmichael]

[Corrected] The hardware result in this comment was a false positive — the samples were already in internal memory from an earlier test — and the 3: fix here is wrong. See my updated comment below for the verified drive map (2: SD card, 3: internal, 4: USB) and the reworked fix.

[douglas-carmichael]

Correction to my earlier comment — that first "clean import" was a false positive (the samples were already in the Iridium's internal memory from a prior test). I've since tested properly on my Iridium (OS 4.0.5): 3: is not the fix, and the drive map in the original description was wrong. Verified on hardware: 2: = SD card, 3: = internal memory, 4: = USB drive. The original 4: was correct for USB and only ever broke SD-card users.

@git-moss — this has to be fixed, and not as a nice-to-have. Every QPAT written to an SD card today is broken on load: the device cannot resolve its own samples and drops you into a manual "Find Sample Map" hunt on every single preset. That alone is a UX failure — but the bigger issue is performance. Sample-map resolution runs on the same CPU that is playing voices, so on a busy patch that forced lookup competes with the audio engine and can make it choke. A sampler that stutters when you load a card-based patch is a hardware-performance bug, not a cosmetic one.

I have reworked this PR to fix it at the source: a "Sample location" option (SD card / USB drive / internal memory, default SD) that writes the correct drive prefix, plus a CLI parameter — all tested on hardware across the three settings. This should go into the next release. Tell me what you would like changed.

[git-moss]

@douglas-carmichael I was in dicsussion with Waldorf about this and they even did not have an answer. One would expect that if a sound is imported, that the importer would adjust that.