Add beat-based TransportControl APIs for position and loop range#14
Merged
Conversation
Adds setPosition(BeatPosition) / getPositionBeats() and setLoopRange(BeatRange) / getLoopRangeBeats() on TransportControl, centralising the conversion against Edit::tempoSequence so callers no longer need to re-derive seconds from beats around tempo changes. Stage 1 of #12 — internal storage stays in TimePosition for now; these are wrapper overloads that delegate to the existing time-based setters after converting through the Edit's TempoSequence.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Stage 1 of #12. Adds beat-based overloads on
TransportControlso callers can pass musical-time intent directly and let TE own the conversion againstEdit::tempoSequence.void setPosition(BeatPosition)BeatPosition getPositionBeats() constvoid setLoopRange(BeatRange)BeatRange getLoopRangeBeats() constInternal storage stays in
TimePositionfor now — these are thin wrappers that convert through the Edit'sTempoSequenceand delegate to the existing time-based setters. The point is to centralise the conversion inside TE instead of having each caller cache beats and recompute seconds on every BPM change.Why
The motivating bug: changing BPM while looping is active causes the playhead to drift out of loop bounds, because MAGDA caches beat values, recomputes seconds against the new tempo, then pushes seconds back to TE — and the playhead is already in flight against the old conversion. With these APIs the caller hands beats to TE, and TE converts at the moment of use against whatever tempo is current.
This fixes the immediate bug after the MAGDA-side port (separate PR) and removes a whole class of
time → beat → timedrift issues across transport.Test plan
make debuggreen)