One event-injection point's prepared scheduling shift, counted in samples at the program's compiled sample rate.
More...
One event-injection point's prepared scheduling shift, counted in samples at the program's compiled sample rate.
Compensation shifts the SCHEDULING WINDOW; it never rewrites event data. PlaybackProgram is immutable and shared by the offline and realtime paths, and NoteProgramEvent::sample is authoritative against the exact CompiledTempoMap the program was compiled with. Folding a host-derived latency into that field would make the program a function of the host graph as well as the document, and would force a full recompile on every device swap. Reading the stream from origin + shift instead leaves the program untouched: the downstream chain delays the events back into place, so they land on the sample the document authored.
Samples, never ticks. A device's latency is a property of its buffering, not of the music, so a tempo ramp must not change it. Expressing the shift in ticks would shrink it as tempo rises, which is the reason timeline::ProductionDeclaration's lookahead is barred from reaching a delay-compensation computation in the first place.