Hey everyone,

After the deep dive into the RP2350 cache architecture yesterday, another math/DSP problem came to mind that I wanted to share. It's about a tool I wrote for my PicoVintageSynthCollection to solve a painful classic: finding loop points for long samples without spending an evening on each one.

If you have ever used software like Polyphone to prepare samples (e.g. for FluidSynth or embedded players), you know the pain. Finding loop points manually is tedious, and auto-loop tools usually settle for the first zero-crossing that roughly matches in amplitude. That catches a zero-crossing, but not necessarily one at the same point in the wave cycle — and the result is a click, a phase cancellation, or a loop that sounds a semitone-ish off because it is short or long by half a cycle.

To fix this for my sampled engines (Reface CP port), I wrote a small pattern-matching tool. Instead of scoring a single point, it matches the phase pattern around the loop end against the phase pattern around candidate loop starts.

diagram

The algorithm

1. The stencil. The tool collects every zero-crossing in the file and takes the last one as its reference. Around it, it builds a small template: the crossing's direction (rising or falling) plus the distances back to the previous, second-previous and third-previous crossing — d₁, d₂, d₃. Four points, three intervals. Where that reference sits is up to you: the tool uses the end of the file, so you trim the input to somewhere in the stable part of the tone (around 1.5–2 s works well) before running it.
2. A period estimate. d₁ — the distance to the previous crossing — becomes the unit of length, P̂. Note this is not the full cycle: any waveform has at least two zero-crossings per cycle, so for an asymmetric wave P̂ is typically the shorter half of one cycle. In the diagram, P̂ = 47 samples while the true period is 122.
3. Where to look. For a candidate loop length k, the tool centres a search window at loopEnd − k·P̂ and opens it up by ±2·P̂ to both sides. Every zero-crossing inside that window is a candidate.
4. Scoring. A candidate of the wrong direction is rejected outright — a rising crossing never matches a falling one, whatever the distances say. The rest get a weighted relative error:
5. The nearest interval weighs three times as much as the farthest, because the crossing right next to the splice is where an error is most audible. Lowest score in the window wins.
6. Choosing k. It starts at k = 10 and, if the score is worse than 0.01, walks upward to 30, stopping at the first window that clears the threshold. If nothing does, it walks back down to k = 3, and keeps the best it saw. So it isn't a global minimum over all k — it is the first window good enough to stop looking, which in practice is what you want, because every extra period is flash you pay for.

Why three intervals instead of one

A single zero-crossing carries almost no information: a 440 Hz note at 32 kHz has one every ~36 samples and they all look alike. Direction plus three intervals pins down where in the cycle you are. In the diagram's search window there are three candidates: one is a falling crossing (rejected on direction alone), one is a rising crossing that sits at the wrong point in the cycle and scores 0.064, and one reproduces d₁/d₂/d₃ exactly. Only the last one splices cleanly.

The other thing this buys you is that the loop length comes out as a whole number of cycles automatically. You never end up half a cycle short, which is the usual cause of that "the loop is slightly out of tune" feeling.

What it does not do

Worth being clear about, because it changes how you use it:

• No crossfade. The splice is a hard cut. It works because the phase matches, not because anything is smoothed over.
• No amplitude matching. Only distances and direction go into the score — never the sample values. On a sample that is still decaying noticeably, the loop start is louder than the loop end and you will hear the level step on each pass, no matter how good the score is. Trim into a region where the decay has flattened out.
• It won't rescue a bad sample. Noisy or inharmonic material produces jittery crossings and no window scores well. The tool reports that (>0.15 it says so outright) rather than pretending.

Within those limits it has been reliable for me: for the CP and MKS-20 sample sets it found scores under 0.01 for the large majority of notes, unattended.

The implementation

One C++17 file, no dependencies, reading and writing 16-bit mono WAV:

tools/cp_sampleprep/build_loop_finder.sh
tools/cp_sampleprep/FindLoopPoints <sample.wav> [num_periods]

It overwrites the input WAV in place, trimmed to the loop end, and writes the loop start to a <sample>.loop file next to it. Work on copies. In the collection it isn't run by hand — prepare_samples.py shells out to it once per sample while building the voice headers.

Source: tools/cp_sampleprep/src/FindLoopPoints.cpp in https://github.com/Michi71/PicoVintageSynthCollection.git

Have you built similar pattern-matching loops for your samplers, or do you still rely on manual crossfading? And has anyone tried scoring the derivative across the splice as well — I suspect that would catch the cases where the phase matches but the slope doesn't quite.

Hey everyone,

Over the weekend I profiled two engines in my PicoVintageSynthCollection for the RP2350 to settle something that had been bugging me:

Why does PicoFaceRD (Roland MKS-20 / MK-80 digital piano) need a 480 MHz overclock and both cores to hold 12 voices, while the newer, sample-heavy PicoFaceJV (JV-880) runs 24 voices at 444 MHz on a single core at 69 % peak load?

Intuitively the 1986 machine should be the easy one. It isn't, and the reason turned out to be more specific than "old hardware is weird."

It's not the arithmetic, it's where the samples live

Both engines are descriptor-driven — the original firmware's voice programming was captured offline and is replayed on-device. Neither is emulating a CPU. So the difference isn't emulation overhead. It's the shape of the memory access.

PicoFaceJV. A JV-880 patch has up to 4 tones, and each sounding tone is one voice — same unit the original machine counts, where 28-voice polyphony means a 4-tone patch gives you 7 notes. My cap is 24, so 24 concurrent sample streams, worst case, each decoded sequentially through its own region. Measured on hardware with B33 Brass Combo at full polyphony: 69 % peak, of which about 5 % is fixed cost (chorus, reverb, block overhead) and ~2.7 % per voice.

PicoFaceRD. Here's the wild part. To get its characteristic sound, the MKS-20 layers 10 separate parts per single note. At the 32 kHz base limit of twelve voices, the engine issues 119 wave-ROM loads per output sample — one per part, ten parts per note, exactly as the architecture predicts.

So it's 24 streams against 119, on the same chip, for one note each.

What the cache does with that

I built a probe that captures every wave-ROM address the RD engine issues and runs the stream through a model of the RP2350's XIP cache (16 KB, two-way, 8-byte lines). Measured miss rates at 12 voices, per patch:

patch  3   85.7 %        patch  8   43.0 %
patch 14   84.6 %        patch  7   16.2 %
patch  0   77.1 %        patch  5    0.2 %
patch 13   83.1 %        patch 15    0.1 %

That spread is the actual finding, and it surprised me more than the average did. It is not "the MKS-20 thrashes the cache." It's patch-dependent by a factor of several hundred. Patch 15's wave data fits the cache and every voice reuses it — and it stays that way as voices are added, still 0.1 % at 32 voices. Patch 3 goes the other way: 66 % of the cycle budget lost to stalls at 12 voices, 96 % at 24.

The base limit of twelve is set entirely by patches like 3. Patches like 15 are being punished for their neighbours — which suggests a per-patch limit derived offline is the obvious next lever, and my voice governor doesn't have it yet.

The 480 MHz is not what it looks like

I want to correct something I'd have written a week ago. The higher clock is not buying flash bandwidth. On this board:

• RD at 480 MHz: QMI CLKDIV=4 → 120 MHz flash, within spec
• Every other instrument at 444 MHz: CLKDIV=3 → 148 MHz flash, above the chip's nominal 133 MHz

The divider is an integer, so pushing the core to 480 actually leaves RD with the slowest flash in the collection. The 480 MHz buys arithmetic throughput and core-1 parallelism; it pays for that with flash speed. Anyone reaching for an overclock to fix a memory-bound problem should check which side of that trade they land on.

What I have not shown

The probe measures miss rates. Converting those to "percent of cycle budget" assumes 96 CPU cycles per miss (120 MHz QSPI, 4:1 ratio) — halve or double that and the absolute numbers move. The ordering and the several-hundred-fold spread don't.

And it does not show that the cache-friendly patches could run 24 voices. Arithmetic scales with voice count too, and this probe doesn't measure that at all. If patch 15 fails at 24 voices, it won't be flash. That's a hardware test I still owe: patch 15 against patch 3, both at 24 fixed voices, reading peak load off the footer.

Conclusion

Newer doesn't mean harder. A 1992 PCM synth streaming 24 sequential voices is gentler on a modern MCU than a 1986 digital piano layering 10 parts per note across scattered ROM regions — and even that isn't uniform, because within the same engine, one patch can be 500× more flash-bound than another. Access pattern beats both age and instruction count.

Repo, including the probe and the full write-up with the numbers above: https://github.com/Michi71/PicoVintageSynthCollection

Context — the JV-880 clone this came out of: https://www.reddit.com/r/synthdiy/comments/1vi0qz5/picofacejv_a_jv880_clone_for_the_rp2350/