for discussion: use existing clock delta when applying kria reset #71
Conversation
|
whoa, apologies for the delay! i'd be happy to go with the majority desire of the thread participants on this one. |
|
another couple months gone by. shall we merge this? |
|
I don't think anyone has complained, one user said it did fix the problem for them. Probably fine to merge it and revisit if it comes up again. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Kria measures the clock frequency to calculate gate durations and ratchet timing relative to the clock. When an incoming external clock stops completely, then starts again, the measurement code needs two rising edges to measure the clock rate, causing a different note duration for the first note played.
This patch, when resetting the Kria playhead, replaces the previous measured edge time t_{-1} with t_{0} - \delta, where t_{0} is the current time and \delta is the existing edge measurement t_{-1} - t_{-2} , causing the next clock measurement to evaluate to t_{0} - (t_{0} - \delta) = \delta.
This resolves the issue described here, using Pamela's New Workout to clock / reset Kria in sync with other modules. Since this potentially affects trigger ratcheting as well, I suspect this may also be a factor in issue #37, also reported when clocking / resetting Kria with Pam's. @fourhexagons if you would like to test this patch, there is a build posted here.
This change does however represent a change to behavior that users may be relying on. Specifically, when modulating the external clock frequency or changing Ansible's main internal clock rate, duration and ratchet timings will now lag by one clock cycle after a reset pulse, rather than tracking the clock edge-for-edge. Note that the same code will run when changing the active pattern sets
pos_reset = true, so this could affect behavior when e.g. metasequencing and changing the Ansible main clock performatively. Another flag could be used to avoid this, but then stopping the clock, changing the pattern, and starting the clock would be affected by the same issue that this patch is intended to address.