Halve the bar-stop lead, and add exact bar looping
60ms was too blunt: at 180 BPM a 32nd note is 42ms, so the lead swallowed the final 32nd of the bar, and it swallowed a whole 32nd from 125 BPM upward. Testing against GetPlayPosition2 rather than GetPlayPosition removes the render-ahead from the equation -- it reports the block about to be rendered rather than what is currently audible -- so the lead only has to cover the daemon's polling interval, not both delays. 35ms suffices, which is safe for 32nds to about 214 BPM. Polling cannot do better than its own interval, so for genuine precision Ctrl+Alt+Shift+Space loops the bar via the loop points instead, letting the audio engine own the boundary. That is sample accurate at any tempo or grid size. It borrows loop range and repeat state; the daemon restores both once transport stops, including when stopped with Space.
This commit is contained in:
@@ -83,6 +83,7 @@ actions by hand in Actions → Show action list. That always works.
|
||||
| `Alt+H` | Toggle hold mode | — |
|
||||
| `Alt+Space` | Play from start of the current bar, onwards | works in both modes |
|
||||
| `Ctrl+Alt+Space` | Play the current bar only, then stop | works in both modes |
|
||||
| `Ctrl+Alt+Shift+Space` | Loop the current bar (exact) | works in both modes |
|
||||
| `Alt+A` | Repeat current cell (speak + sound) | — |
|
||||
| `Alt+S` | Set root and scale | — |
|
||||
| `1`–`9` | Grid size — REAPER's own grid actions | same |
|
||||
@@ -157,9 +158,36 @@ Both of these play from the **top of the bar the cursor is in**, and say which
|
||||
bar:
|
||||
|
||||
- **`Alt+Space`** — plays from the bar line and keeps going. Stop with `Space`.
|
||||
- **`Ctrl+Alt+Space`** — plays that bar **only**, stopping at the next bar
|
||||
line. Nothing to stop by hand, so you can fire it repeatedly while nudging a
|
||||
note and hear the same bar each time.
|
||||
- **`Ctrl+Alt+Space`** — plays that bar **only**, stopping just before the next
|
||||
bar line. Nothing to stop by hand, so you can fire it repeatedly while
|
||||
nudging a note and hear the same bar each time.
|
||||
- **`Ctrl+Alt+Shift+Space`** — **loops** that bar, exactly. Repeats until you
|
||||
press `Space`.
|
||||
|
||||
### Which of the two bar actions to use
|
||||
|
||||
`Ctrl+Alt+Space` stops by polling, and a polling loop can only be as precise as
|
||||
its own interval — about 33 ms at frame rate. It therefore stops a little
|
||||
early, and notes falling inside that window do not sound. In practice:
|
||||
|
||||
| Tempo | 16th note | 32nd note | 35 ms lead is |
|
||||
|---|---|---|---|
|
||||
| 120 BPM | 125 ms | 62 ms | 0.28 of a 16th, 0.56 of a 32nd |
|
||||
| 180 BPM | 83 ms | 42 ms | 0.42 of a 16th, 0.84 of a 32nd |
|
||||
| 240 BPM | 62 ms | 31 ms | 0.56 of a 16th, 1.12 of a 32nd |
|
||||
|
||||
So it is safe for 16ths at any sane tempo, and safe for 32nds up to about
|
||||
214 BPM. Past that, the final 32nd of the bar is inside the lead and will not
|
||||
be heard.
|
||||
|
||||
`Ctrl+Alt+Shift+Space` has no such limit. It hands the bar boundary to REAPER's
|
||||
audio engine through the loop points, which is sample accurate, so the next
|
||||
bar's downbeat can never leak in at any tempo or grid size. Use it when you are
|
||||
working at 32nds or faster, or whenever you want certainty. Looping also suits
|
||||
the job well — leave it running and edit while it plays.
|
||||
|
||||
It borrows the project's loop range and repeat state, and the daemon restores
|
||||
both once transport stops, including when you stop with `Space`.
|
||||
|
||||
Auditioning a cell tells you what a note *is*; playing from the downbeat tells
|
||||
you whether it is in the right *place*. At 16ths or 32nds that difference is
|
||||
@@ -177,15 +205,17 @@ script — a script that stayed alive waiting for the bar to end would trigger
|
||||
REAPER's "already running" prompt on the next press. Stopping can move the
|
||||
edit cursor depending on your preferences, so the daemon puts it back.
|
||||
|
||||
It stops **60 ms before** the bar line rather than on it. Two delays stack up
|
||||
otherwise: the daemon runs at about frame rate, and REAPER renders audio ahead
|
||||
of the play position it reports, so a note sitting exactly on the next bar line
|
||||
has already reached the instrument by the time the stop lands — and you hear
|
||||
the downbeat you were trying to exclude. Leading by more than both delays keeps
|
||||
it silent, at the cost of a few inaudible milliseconds off the tail.
|
||||
It stops **35 ms before** the bar line rather than on it, or a note sitting
|
||||
exactly on the next bar line would sound. The test uses `GetPlayPosition2`,
|
||||
which reports the block REAPER is about to render rather than what you are
|
||||
currently hearing — that removes render-ahead from the equation, so the lead
|
||||
only has to cover the daemon's own polling interval. (Testing against
|
||||
`GetPlayPosition` instead needed 60 ms to cover both, which was enough to
|
||||
swallow a whole 32nd note from 125 BPM upward.)
|
||||
|
||||
If a next-bar note still sneaks through — a large audio buffer will do it —
|
||||
raise `stoplead` in `ExtState`.
|
||||
`stoplead` in `ExtState` tunes it. Raising it is the fix if a next-bar note
|
||||
still sneaks through; lowering it recovers a little more of the bar's tail at
|
||||
the risk of leaks.
|
||||
|
||||
## Shifting notes in time
|
||||
|
||||
@@ -278,7 +308,7 @@ In `ExtState` section `midigrid`:
|
||||
|---|---|---|
|
||||
| `vel` | 96 | Velocity of inserted notes |
|
||||
| `velstep` | 8 | Velocity change per keypress |
|
||||
| `stoplead` | 0.06 | How early to stop, in seconds, when playing one bar |
|
||||
| `stoplead` | 0.035 | How early to stop, in seconds, when playing one bar |
|
||||
| `chan` | 0 | MIDI channel (0-based) |
|
||||
| `previewdur` | 0.4 | Preview note length, seconds |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user