Roland MV-8000, S-7xx: convert the envelope times with the table of the sound engine

[douglas-carmichael]

Both formats convert their envelope times with 20 * 2^((v-127)/21), a formula which was never calibrated - the MV-8000 borrowed it from the S-7xx, and on the S-7xx it carries the comment "0 is instant - without this case every envelope stage would take at least 302 ms". That floor is the tell: a sampler whose fastest non-zero envelope stage is a third of a second is not credible, and the formula spans only 64:1 where every law we have recovered from firmware spans far more (Akai S1000 16384:1, Casio FZ 10922:1, the ZEN-Core law measured on a FANTOM-0 2150:1).

The table

Every time is a 0-127 setting which the sound engine looks up in a 128 entry table, and that table is in the firmware of both machines:

firmware	offset	layout
S-760 system disk 2.24 (S760224.OUT, Roland's own download)	0xB63EE	u16 little-endian, descending
MV-8000 OS 3.54, decompressed	0x50538C	u16 big-endian, ascending

All 127 overlapping entries are identical. It runs 30 to 65535 as a geometric series, ratio 1.0624 per step, spanning 2184:1.

That the two firmwares share it is incidentally what settles the lineage: the MV-8000 runs the S-7xx sound engine, not the XV one whose category list it borrows. Two further tables are shared (a 2:1 pitch ratio ramp and a linear ramp), the S-760 system disk identifies itself as S770 MR25A, and the MV-8000 OS carries dedicated S-7xx patch/partial/sample loaders.

The unit

The S-760 owner's manual documents LFO Delay, Partial, [0]-[127] as "the time (0.01 - 22 sec)". The table's ends are 30 and 65535, so

0.01 s / 30 = 1/3000 s per entry        65535 / 3000 = 21.845 s ~ "22 sec"

Both ends of a documented range matched within one percent, which fixes the unit:

t(setting) = TABLE[setting] / 3000 s     ~ 0.01 * 2^(setting/11.45)
           = 0.0100 s at 0 .. 21.845 s at 127

What changes

setting	new	old formula	factor
1	0.011 s	0.313 s	29.3x
15 (median of the factory patches)	0.025 s	0.496 s	20.1x
30	0.061 s	0.814 s	13.3x
60	0.378 s	2.191 s	5.8x
100	4.26 s	8.20 s	1.9x
127	21.85 s	20.0 s	0.9x

The two agree only near the top. Measured over the 4324 envelope times of the 103 factory patches, 62 % are non-zero with a median of 15 - squarely in the range where the old law was 20 times too slow. The factory 'Mark V' electric piano now attacks in 0.011 s and releases in 0.016 s, as an electric piano does, instead of taking 0.3 s to do either.

Please read this before merging

One step is inference, not proof. The manual documents that range for the LFO delay, and I could not locate the code which indexes the table, so that the envelope times use the same table is not shown directly.

What supports it:

• it is the only long-span geometric time table in the S-760 - the other two span just 131:1 and 102:1 over 5-720 ms;
• the ZEN-Core envelope law which ConvertWithMoss measured on FANTOM-0 hardware spans 0.010 s to 21.5 s, agreeing with this table at both ends within about 1.5 %, and that measurement was of envelope times;
• one shared time curve for all time parameters is the pattern in every sampler whose law has been recovered here.

Why the code was not found: the S-760's CPU is an Intel S80C196KB whose 64 KB address space is expanded to 1 MB by the HG62E33B0B gate array, with 1 MB of program DRAM holding the whole disk image. Overlay mappings can be recovered exactly where a computed goto appears (add Rn,#imm; br [Rn] puts the branch table at a known file offset), which gives K = 0x8400 for file 0xA5DB-0xF100 - but under every recovered mapping the table lies outside 16 bit range, and which window the gate array maps is internal to that custom part.

Recording the hardware would settle it in about ten minutes: one patch mapping a looped sine to a row of pads whose only difference is the time under test. I have that patch and the analysis script ready and would gladly hand them to anyone with an MV-8000 or MV-8800 - the same recording also confirms the curve shape. Happy to hold this until then if you would rather not take the inference; the current law is wrong either way.

The table conversion round-trips exactly over all 128 settings, so an MV0 read and written back keeps its stored values.

Note: this rewrites the paragraph about the unknown time curve in documentation/design/MV8000_FORMAT.md, which #369 also touches - if #369 goes in first this needs a trivial rebase, just say the word.