@openmixer/omx-contract 1.2.1 → 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (42) hide show
  1. package/README.md +41 -4
  2. package/bin/omx-contract.mjs +14 -3
  3. package/data/kernels/balance.json +18 -14
  4. package/data/kernels/band_dyn.json +132 -0
  5. package/data/kernels/chorus.json +87 -56
  6. package/data/kernels/comp.json +67 -29
  7. package/data/kernels/deesser.json +114 -86
  8. package/data/kernels/delay.json +67 -57
  9. package/data/kernels/drive.json +118 -87
  10. package/data/kernels/eq.json +284 -113
  11. package/data/kernels/fbs.json +150 -0
  12. package/data/kernels/flanger.json +74 -44
  13. package/data/kernels/gate.json +76 -21
  14. package/data/kernels/geq.json +32 -27
  15. package/data/kernels/hrp.json +68 -0
  16. package/data/kernels/limiter.json +25 -9
  17. package/data/kernels/mixmatrix.json +11 -0
  18. package/data/kernels/phaser.json +110 -100
  19. package/data/kernels/pitch.json +35 -17
  20. package/data/kernels/reverb.json +176 -142
  21. package/data/kernels/rotary.json +189 -177
  22. package/data/kernels/rta.json +17 -0
  23. package/data/kernels/transient.json +64 -36
  24. package/data/kernels/tremolo.json +59 -48
  25. package/data/primitives.json +51 -0
  26. package/data/rates.json +29 -0
  27. package/dist/ts/omx-contract.d.ts +527 -21
  28. package/dist/ts/omx-contract.js +832 -57
  29. package/include/omxcontract/omx_contract_limits.h +233 -0
  30. package/lib/data.mjs +115 -3
  31. package/lib/eq-defaults.mjs +87 -0
  32. package/lib/fmt.mjs +24 -4
  33. package/lib/semver.mjs +12 -2
  34. package/lib/validate.mjs +99 -3
  35. package/package.json +1 -1
  36. package/render/c.mjs +76 -10
  37. package/render/doors.mjs +6 -3
  38. package/render/ts.mjs +40 -2
  39. package/schema/omx-contract.schema.json +39 -3
  40. package/share/omx-contract/omx-contract.json +759 -71
  41. package/render/c/omx_plugin_param.h +0 -25
  42. package/render/c/params-generate.mjs +0 -83
@@ -1,51 +1,81 @@
1
1
  {
2
2
  "$schema": "../../schema/omx-contract.schema.json",
3
- "FLANGER_RATE_RANGE": {
4
- "kind": "travels",
5
- "doc": "The flanger's jet sweep (§3b).",
6
- "travel": {
7
- "min": 0.05,
8
- "max": 5,
9
- "step": 0.01,
10
- "unit": "Hz",
11
- "default": 0.25,
12
- "defaultFrom": "desk"
3
+ "controls": [
4
+ {
5
+ "name": "rate",
6
+ "kind": "travel",
7
+ "doc": "The flanger's jet sweep (§3b).",
8
+ "travel": {
9
+ "min": 0.05,
10
+ "max": 5,
11
+ "step": 0.01,
12
+ "unit": "Hz",
13
+ "default": 0.25,
14
+ "defaultFrom": "desk"
15
+ }
16
+ },
17
+ {
18
+ "name": "depth",
19
+ "kind": "travel",
20
+ "doc": "The flanger's peak-to-peak excursion above its declared 0.5 ms base (§3b).",
21
+ "travel": {
22
+ "min": 0,
23
+ "max": 5,
24
+ "step": 0.1,
25
+ "unit": "ms",
26
+ "default": 2,
27
+ "defaultFrom": "desk"
28
+ }
29
+ },
30
+ {
31
+ "name": "feedback",
32
+ "kind": "travel",
33
+ "doc": "The flanger's SIGNED resonance (§3b). The ±0.95 clamp is DECLARED here — a PATCH asking for 1.0 is answered by this travel — and the kernel's own clamp is the enforcement half.",
34
+ "travel": {
35
+ "min": -0.95,
36
+ "max": 0.95,
37
+ "step": 0.01,
38
+ "unit": "",
39
+ "default": 0.6,
40
+ "defaultFrom": "desk"
41
+ }
42
+ },
43
+ {
44
+ "name": "mix",
45
+ "kind": "travel",
46
+ "doc": "The flanger's wet/dry, as an instance of DRIVE_MIX_RANGE: 50 %, equal dry and wet, where the comb is deepest (§3b).",
47
+ "travel": {
48
+ "min": 0,
49
+ "max": 100,
50
+ "step": 0.1,
51
+ "unit": "%",
52
+ "default": 50,
53
+ "defaultFrom": "desk"
54
+ }
13
55
  }
14
- },
15
- "FLANGER_DEPTH_RANGE": {
16
- "kind": "travels",
17
- "doc": "The flanger's peak-to-peak excursion above its declared 0.5 ms base (§3b).",
18
- "travel": {
19
- "min": 0,
20
- "max": 5,
21
- "step": 0.1,
56
+ ],
57
+ "constants": {
58
+ "FLANGER_BASE_MS": {
59
+ "kind": "scalar",
60
+ "doc": "The flanger's base delay, ms: the sweep rides on it up to the depth.",
22
61
  "unit": "ms",
23
- "default": 2,
24
- "defaultFrom": "desk"
25
- }
26
- },
27
- "FLANGER_FEEDBACK_RANGE": {
28
- "kind": "travels",
29
- "doc": "The flanger's SIGNED resonance (§3b). The ±0.95 clamp is DECLARED here — a PATCH asking for 1.0 is answered by this travel — and the kernel's own clamp is the enforcement half.",
30
- "travel": {
31
- "min": -0.95,
32
- "max": 0.95,
33
- "step": 0.01,
34
- "unit": "",
35
- "default": 0.6,
36
- "defaultFrom": "desk"
37
- }
38
- },
39
- "FLANGER_MIX_RANGE": {
40
- "kind": "travels",
41
- "doc": "The flanger's wet/dry, as an instance of DRIVE_MIX_RANGE: 50 %, equal dry and wet, where the comb is deepest (§3b).",
42
- "travel": {
43
- "min": 0,
44
- "max": 100,
45
- "step": 0.1,
46
- "unit": "%",
47
- "default": 50,
48
- "defaultFrom": "desk"
62
+ "value": 0.5
63
+ },
64
+ "FLANGER_MAX_MS": {
65
+ "kind": "scalar",
66
+ "doc": "The longest delay a flanger sweep reaches, rounded up to whole ms: the base delay plus the depth maximum. The delay line is sized from it.",
67
+ "unit": "ms",
68
+ "value": {
69
+ "derive": "ceilSum",
70
+ "of": [
71
+ {
72
+ "ref": "FLANGER_BASE_MS"
73
+ },
74
+ {
75
+ "ref": "FLANGER_DEPTH_RANGE.max"
76
+ }
77
+ ]
78
+ }
49
79
  }
50
80
  }
51
81
  }
@@ -1,74 +1,124 @@
1
1
  {
2
2
  "$schema": "../../schema/omx-contract.schema.json",
3
- "GATE_LIMITS": {
4
- "kind": "travels",
5
- "doc": "The legal range of each gate field (engineering units). The widget clamps drags to these, `normalizeGate` enforces them, the row's codec refuses by them and the travel sheet publishes them — one source of truth. `rangeDb` reaches GATE_RANGE_FLOOR_DB, shown as \"−∞\" in readouts (a gate fully closed is silence).",
6
- "fields": {
7
- "thresholdDb": {
3
+ "controls": [
4
+ {
5
+ "name": "keySource",
6
+ "kind": "choice",
7
+ "doc": "Where the gate listens: its own input (self), or the key it is handed (sidechain), in the order of the integer the key port carries.",
8
+ "ids": [
9
+ "self",
10
+ "sidechain"
11
+ ]
12
+ },
13
+ {
14
+ "name": "thresholdDb",
15
+ "kind": "travel",
16
+ "table": "GATE_LIMITS",
17
+ "travel": {
8
18
  "min": -80,
9
19
  "max": 0,
10
20
  "step": 1,
11
21
  "unit": "dB",
12
22
  "default": -40,
13
23
  "defaultFrom": "desk"
14
- },
15
- "rangeDb": {
24
+ }
25
+ },
26
+ {
27
+ "name": "rangeDb",
28
+ "kind": "travel",
29
+ "table": "GATE_LIMITS",
30
+ "travel": {
16
31
  "min": -90,
17
32
  "max": 0,
18
33
  "step": 1,
19
34
  "unit": "dB",
20
35
  "default": -90,
21
36
  "defaultFrom": "desk"
22
- },
23
- "kneeStartDb": {
37
+ }
38
+ },
39
+ {
40
+ "name": "kneeStartDb",
41
+ "kind": "travel",
42
+ "table": "GATE_LIMITS",
43
+ "travel": {
24
44
  "min": -80,
25
45
  "max": 0,
26
46
  "step": 1,
27
47
  "unit": "dB",
28
48
  "default": -43,
29
49
  "defaultFrom": "desk"
30
- },
31
- "kneeEndDb": {
50
+ }
51
+ },
52
+ {
53
+ "name": "kneeEndDb",
54
+ "kind": "travel",
55
+ "table": "GATE_LIMITS",
56
+ "travel": {
32
57
  "min": -80,
33
58
  "max": 0,
34
59
  "step": 1,
35
60
  "unit": "dB",
36
61
  "default": -37,
37
62
  "defaultFrom": "desk"
38
- },
39
- "attackMs": {
63
+ }
64
+ },
65
+ {
66
+ "name": "attackMs",
67
+ "kind": "travel",
68
+ "table": "GATE_LIMITS",
69
+ "travel": {
40
70
  "min": 0,
41
71
  "max": 500,
42
72
  "step": 0.5,
43
73
  "unit": "ms",
44
74
  "default": 1,
45
75
  "defaultFrom": "desk"
46
- },
47
- "holdMs": {
76
+ }
77
+ },
78
+ {
79
+ "name": "holdMs",
80
+ "kind": "travel",
81
+ "table": "GATE_LIMITS",
82
+ "travel": {
48
83
  "min": 0,
49
84
  "max": 2000,
50
85
  "step": 5,
51
86
  "unit": "ms",
52
87
  "default": 10,
53
88
  "defaultFrom": "desk"
54
- },
55
- "releaseMs": {
89
+ }
90
+ },
91
+ {
92
+ "name": "releaseMs",
93
+ "kind": "travel",
94
+ "table": "GATE_LIMITS",
95
+ "travel": {
56
96
  "min": 0,
57
97
  "max": 5000,
58
98
  "step": 10,
59
99
  "unit": "ms",
60
100
  "default": 100,
61
101
  "defaultFrom": "desk"
62
- },
63
- "hysteresisDb": {
102
+ }
103
+ },
104
+ {
105
+ "name": "hysteresisDb",
106
+ "kind": "travel",
107
+ "table": "GATE_LIMITS",
108
+ "travel": {
64
109
  "min": 0,
65
110
  "max": 24,
66
111
  "step": 0.5,
67
112
  "unit": "dB",
68
113
  "default": 3,
69
114
  "defaultFrom": "desk"
70
- },
71
- "ratio": {
115
+ }
116
+ },
117
+ {
118
+ "name": "ratio",
119
+ "kind": "travel",
120
+ "table": "GATE_LIMITS",
121
+ "travel": {
72
122
  "min": 1,
73
123
  "max": 100,
74
124
  "step": 1,
@@ -77,5 +127,10 @@
77
127
  "defaultFrom": "desk"
78
128
  }
79
129
  }
130
+ ],
131
+ "tables": {
132
+ "GATE_LIMITS": {
133
+ "doc": "The legal range of each gate field (engineering units). The widget clamps drags to these, `normalizeGate` enforces them, the row's codec refuses by them and the travel sheet publishes them — one source of truth. `rangeDb` reaches GATE_RANGE_FLOOR_DB, shown as \"−∞\" in readouts (a gate fully closed is silence)."
134
+ }
80
135
  }
81
136
  }
@@ -1,33 +1,38 @@
1
1
  {
2
2
  "$schema": "../../schema/omx-contract.schema.json",
3
- "GEQ_BAND_RANGE": {
4
- "kind": "travels",
5
- "doc": "One graphic-EQ fader's travel: EQ_GAIN_RANGE by reference (a graphic fader is an EQ gain), with the come-up value it needs as a row field — flat, 0 dB (graphic-eq-31 spec §3).",
6
- "travel": {
7
- "min": -15,
8
- "max": 15,
9
- "step": 0.5,
3
+ "controls": [
4
+ {
5
+ "name": "band",
6
+ "kind": "travel",
7
+ "doc": "One graphic-EQ fader's travel: EQ_GAIN_RANGE by reference (a graphic fader is an EQ gain), with the come-up value it needs as a row field — flat, 0 dB (graphic-eq-31 spec §3).",
8
+ "travel": {
9
+ "min": -15,
10
+ "max": 15,
11
+ "step": 0.5,
12
+ "unit": "dB",
13
+ "default": 0,
14
+ "defaultFrom": "desk"
15
+ }
16
+ }
17
+ ],
18
+ "constants": {
19
+ "GEQ_BAND_Q": {
20
+ "kind": "scalar",
21
+ "doc": "The graphic EQ's band Q: the ISO third-octave bandwidth, `2^(1/6)/(2^(1/3) − 1) ≈ 4.318`, to one decimal as the M32 GEQ carries it. Read by the `geq31` preset and the graphic EQ's section design (graphic-eq-31 spec §3).",
22
+ "unit": "",
23
+ "value": 4.3
24
+ },
25
+ "GEQ_PROTO_DB": {
26
+ "kind": "scalar",
27
+ "doc": "The prototype gain the `true` solve's first interaction matrix is evaluated at (spec §2, §3): the middle of the travel's magnitude, where a matched-Z section's dB response per dB of gain is closest to its average.",
28
+ "unit": "dB",
29
+ "value": 12
30
+ },
31
+ "GEQ_DESIGN_GAIN_MAX_DB": {
32
+ "kind": "scalar",
33
+ "doc": "The ceiling on a section gain the `true` solve may ask for (spec §3): above the travel's worst case (26.0 dB, the alternating ±15 set) with margin. A solve past it clamps and the row says so (`designClamped`), never silently.",
10
34
  "unit": "dB",
11
- "default": 0,
12
- "defaultFrom": "desk"
35
+ "value": 30
13
36
  }
14
- },
15
- "GEQ_BAND_Q": {
16
- "kind": "scalar",
17
- "doc": "The graphic EQ's band Q: the ISO third-octave bandwidth, `2^(1/6)/(2^(1/3) − 1) ≈ 4.318`, to one decimal as the M32 GEQ carries it. Read by the `geq31` preset and the graphic EQ's section design (graphic-eq-31 spec §3).",
18
- "unit": "",
19
- "value": 4.3
20
- },
21
- "GEQ_PROTO_DB": {
22
- "kind": "scalar",
23
- "doc": "The prototype gain the `true` solve's first interaction matrix is evaluated at (spec §2, §3): the middle of the travel's magnitude, where a matched-Z section's dB response per dB of gain is closest to its average.",
24
- "unit": "dB",
25
- "value": 12
26
- },
27
- "GEQ_DESIGN_GAIN_MAX_DB": {
28
- "kind": "scalar",
29
- "doc": "The ceiling on a section gain the `true` solve may ask for (spec §3): above the travel's worst case (26.0 dB, the alternating ±15 set) with margin. A solve past it clamps and the row says so (`designClamped`), never silently.",
30
- "unit": "dB",
31
- "value": 30
32
37
  }
33
38
  }
@@ -0,0 +1,68 @@
1
+ {
2
+ "$schema": "../../schema/omx-contract.schema.json",
3
+ "controls": [
4
+ {
5
+ "name": "amount",
6
+ "kind": "travel",
7
+ "doc": "How much of the computed correction HRP applies: 0 = analyse only, 1 = the full cut. It comes up at 0.5, half the computed cut.",
8
+ "travel": {
9
+ "min": 0,
10
+ "max": 1,
11
+ "step": 0,
12
+ "unit": "",
13
+ "default": 0.5,
14
+ "defaultFrom": "desk"
15
+ }
16
+ }
17
+ ],
18
+ "constants": {
19
+ "HRP_MAX_CUT_DB": {
20
+ "kind": "scalar",
21
+ "doc": "The largest automatic cut HRP may place on one harmonic, as a POSITIVE dB magnitude. Well inside the ±15 dB an operator band may hold (core's `EQ_GAIN_LIMIT_DB`): an automatic correction the operator did not ask for gets far less authority than one they dialled themselves.",
22
+ "unit": "dB",
23
+ "value": 6
24
+ },
25
+ "HRP_MAX_VOICES": {
26
+ "kind": "scalar",
27
+ "doc": "How many simultaneous musical voices the detector may report on one channel. PINNED to `OMX_HRP_MAX_VOICES` in `pipewire-native/src/hrp_pitch.h` — the C voice set is a FIXED-SIZE array, so a TS number above the macro promises voices the analyser structurally cannot return, and one below it silently drops notes the C already found. `core/src/output-delay-ceiling.test.ts` reads the header and holds the pair equal. EIGHT (operator sizing, 2026-09-01): a guitar sounds six strings, a piano or string-section voicing sits at eight. It is a SEARCH ceiling, not a cost — the detector abandons a round as soon as no credible candidate remains, so monophonic material costs what it always did.",
28
+ "unit": "",
29
+ "value": 8
30
+ },
31
+ "HRP_BAND_Q": {
32
+ "kind": "scalar",
33
+ "doc": "The Q of an HRP correction band — one declared number, operator-adjustable later. A musical cut, not a ring killer: FBS's default notch Q is ~116 because a howl is a single frequency, whereas a partial that is too loud is a note an instrument is playing and a surgical null on it would be heard as a hole. 5 sits mid-band in the 4…6 range a musical subtractive cut occupies, and inside EQ_Q_RANGE — the gain-carrying shapes' extent — so it survives the store's clamp unchanged. Deliberately NOT derived from the harmonic index. A derivation invented with no measurement behind it is a second declaration wearing a formula; this is revisited when the analyse-only surface shows what real corrections look like.",
34
+ "unit": "",
35
+ "value": 5
36
+ },
37
+ "HRP_EXCESS_THRESHOLD_DB": {
38
+ "kind": "scalar",
39
+ "doc": "How far a partial must stand above its LEARNED BASELINE before HRP calls it a resonance (increment 8, §23–§24: `deviation = measured − baseline[note][harmonic]`). A partial level tells you nothing on its own; what marks a resonance is a partial louder than THIS instrument normally measures at THIS note. Three decibels is the same order as the feedback detector's peak-to-neighbour gate and for the same reason: below it, an ordinary performance's variation — a bow dug in, a verse sung harder — would be flattened, and flattening expression is not correcting a room. (Before the learned model existed this same threshold gated the placeholder neighbour rule; the number and its reasoning carried over.)",
40
+ "unit": "dB",
41
+ "value": 3
42
+ },
43
+ "HRP_GAIN_STEP_DB": {
44
+ "kind": "scalar",
45
+ "doc": "How far ONE reconcile pass may move an HRP band's gain, in dB — §48's gain smoothing, done at the control level because the native cascade applies pushed coefficients verbatim and §48 forbids interpolating there. An unbounded gain step is a waveform discontinuity — the click heard when a correction entered or left at full depth (found live, 2026-08-20, the evening increment 9 raised the enter/leave rate). Bounded, a correction ENTERS by deepening from silence and LEAVES by walking to exactly 0 dB — the provable parked identity (`eqBandIsIdentity`) — from which removal is bit-identical. Two decibels per pass at the corrector's 10 Hz cadence walks the full HRP_MAX_CUT_DB travel in ~300 ms: the same order as the tracker's stability hold and FBS's lift steps, while each individual move stays below audibility on a Q-5 bell.",
46
+ "unit": "dB",
47
+ "value": 2
48
+ },
49
+ "HRP_COLLISION_CENTS": {
50
+ "kind": "scalar",
51
+ "doc": "How close two correction candidates must sit, in cents, to count as the SAME spectral region (§30): within it, the stronger candidate is selected and the weaker discarded rather than two near-identical filters being planted. One semitone, and the number follows from HRP_BAND_Q: a Q-5 bell's −3 dB half-width is ~170 cents, so two cuts a semitone apart overlap over most of their travel — the second one deepens the first far more than it shapes anything of its own. The spec orders the threshold configurable and tested (§30's last line): declared once here, a parameter everywhere below.",
52
+ "unit": "cents",
53
+ "value": 100
54
+ },
55
+ "HRP_ATTRIBUTION_CENTS": {
56
+ "kind": "scalar",
57
+ "doc": "The ATTRIBUTION window (§11): two partials closer than this are one spectral event as far as the desk can tell — the same ±1 bin `omx_hrp_bin_peak` reads over, expressed musically so it holds across the range. A different law from HRP_COLLISION_CENTS (§30's SELECTION window, which stays above it): this one is the analyser's resolution, that one the corrector's. Generated into `omx_contract_limits.h` as `OMX_HRP_ATTRIBUTION_CENTS`; `hrp_attribute.h` reads it.",
58
+ "unit": "cents",
59
+ "value": 60
60
+ },
61
+ "HRP_DEFAULT_MAX_AUTO_BANDS": {
62
+ "kind": "scalar",
63
+ "doc": "How many bands HRP may plant on ONE channel — its half of the machine budget, and the number that makes the budget FORECASTABLE rather than emergent. Without it the count is whatever the material happens to provoke: the placement law is sparse, so a clean note plants two bands and a resonant room plants nine, and nobody can answer \"will this fit?\" until it does not. With FBS senior (§9.3(b)) that discovery would happen at showtime, to the junior planter, silently. Declared instead, the whole sum is arithmetic an operator can read before a note is played: operator bands + FBS maxAutoBands + HRP maxAutoBands <= EQ_MAX_BANDS EIGHT — ONE CORRECTION PER VOICE at full polyphony (operator sizing, 2026-09-01). The detector's ceiling is HRP_MAX_VOICES voices, a guitar's six strings and a piano/string voicing's eight, and a budget below the voice count would decide by arithmetic which of the notes actually sounding may be corrected — a limit nobody could read off the desk. Scarcity is handled where it belongs instead: the candidates from every voice meet in ONE globally ranked list (spec §29) and the head of it is what gets planted. It is NOT a claim to seniority, and it is larger than FBS's six. Seniority is the ALLOCATION ORDER — `HrpPlanter` takes only `EQ_MAX_BANDS − others.length`, the remainder after the operator and every other machine — so a bigger junior default cannot reach a senior slot; it only means HRP asks for more of what is left. `eq-budget-fits.test.ts` asserts both halves. The per-channel DEFAULT; the row's travel is HRP_AUTO_BANDS_RANGE, so a channel that needs more can have more, as an explicit decision with a visible cost.",
64
+ "unit": "",
65
+ "value": 8
66
+ }
67
+ }
68
+ }
@@ -1,26 +1,37 @@
1
1
  {
2
2
  "$schema": "../../schema/omx-contract.schema.json",
3
- "LIMITER_LIMITS": {
4
- "kind": "travels",
5
- "doc": "The precision limiter's travels (`2026-09-27-precision-limiter.md` §2), rendered into `omx_contract_limits.h` as `OMX_LIMITER_*` by `harness/contract-limits-gen.mjs`, so `mix_limiter.h` reads them and never restates one (R-094). The ceiling is a TRUE peak in dBFS (the ×4 detector); the look-ahead sets the declared latency; the release is the envelope's time constant on the gain depth.",
6
- "fields": {
7
- "ceilingDb": {
3
+ "controls": [
4
+ {
5
+ "name": "ceilingDb",
6
+ "kind": "travel",
7
+ "table": "LIMITER_LIMITS",
8
+ "travel": {
8
9
  "min": -12,
9
10
  "max": 0,
10
11
  "step": 0.1,
11
12
  "unit": "dBFS",
12
13
  "default": -1,
13
14
  "defaultFrom": "desk"
14
- },
15
- "lookaheadMs": {
15
+ }
16
+ },
17
+ {
18
+ "name": "lookaheadMs",
19
+ "kind": "travel",
20
+ "table": "LIMITER_LIMITS",
21
+ "travel": {
16
22
  "min": 0.5,
17
23
  "max": 5,
18
24
  "step": 0.1,
19
25
  "unit": "ms",
20
26
  "default": 1.5,
21
27
  "defaultFrom": "desk"
22
- },
23
- "releaseMs": {
28
+ }
29
+ },
30
+ {
31
+ "name": "releaseMs",
32
+ "kind": "travel",
33
+ "table": "LIMITER_LIMITS",
34
+ "travel": {
24
35
  "min": 1,
25
36
  "max": 1000,
26
37
  "step": 1,
@@ -29,5 +40,10 @@
29
40
  "defaultFrom": "desk"
30
41
  }
31
42
  }
43
+ ],
44
+ "tables": {
45
+ "LIMITER_LIMITS": {
46
+ "doc": "The precision limiter's travels (`2026-09-27-precision-limiter.md` §2), rendered into `omx_contract_limits.h` as `OMX_LIMITER_*` by `harness/contract-limits-gen.mjs`, so `mix_limiter.h` reads them and never restates one (R-094). The ceiling is a TRUE peak in dBFS (the ×4 detector); the look-ahead sets the declared latency; the release is the envelope's time constant on the gain depth."
47
+ }
32
48
  }
33
49
  }
@@ -0,0 +1,11 @@
1
+ {
2
+ "$schema": "../../schema/omx-contract.schema.json",
3
+ "constants": {
4
+ "BUS_INPUT_CAP": {
5
+ "kind": "scalar",
6
+ "doc": "The input cap a summing bus can be sized to — **the engine's declared input ceiling**, read from `@freemixer/declarations` rather than re-typed here. A gig with more than this many inputs needs more than one engine node; below it a bus is sized to `min(N, BUS_INPUT_CAP)`. It was a literal 64 until 2026-09-15, said to mirror the engine's `MAX_BUS_INPUTS` — and it did, but that 64 was the PipeWire builtin mixer's single-tier fan-in (8 × 8), never the engine's bound: the native node has allocated `OMX_MAX_STRIPS` (128) strips all along. Two literals agreeing by hand is how the console came to refuse a 96-channel desk it could carry. `native-input-ceiling.test.ts` holds this to the C header; spec `docs/design/specs/2026-09-14-console-allocation.md` §9 carries the ruling and the measured cost of width.",
7
+ "unit": "",
8
+ "value": 128
9
+ }
10
+ }
11
+ }