Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TU externally clocked lags before locking onto tempo for channels that are multiplied #39

Open
giftculture opened this issue Aug 10, 2018 · 4 comments

Comments

@giftculture
Copy link

It appears when trying to clock the TU externally at 48PPQ or 96PPQ that for channels that are using multiplication, the TU waits until the next quarter note to start multiplying the clock. In any case, there seems to be a noticeable bit of lag before the multiplied channel locks onto a tempo

Perhaps this is expected behavior, but I would think that with 48 or 96 PPQ that assuming evenly spaced pulses, that the TU would be able to more quickly determine what rate to output clock multiples by, say, either averaging or sampling the first several pulses and then using that to extrapolate a tempo

@mxmxmx
Copy link
Owner

mxmxmx commented Aug 10, 2018

hi,
yeah, changing the multiplier takes effect only on the next trigger, which for 48/96PPQ.
https://github.com/mxmxmx/temps_utile-/blob/master/soft/t_u_REV/APP_CLK.ino#L1078

can't remember whence, tbh, ... or whether I or @jeremybernstein added this.

@giftculture
Copy link
Author

Unfortunately the behavior that I am seeing is happening when I leave the multiplier static between runs (on V 1.2.3)

For example, I set a channel to x2. If I then send a clock at 48 or 96ppq that channel seems to wait until the next quarter note to start multiplying. If I stop the clock and then start it again, the same thing happens, even when the multiplier doesn't change between runs. Division doesn't seem to be affected by the same lag.

multiplier x2 copy

In the scheme of things, it's not the end of the world, I can clock the TU at my max desired rate (say 32nd or 64th notes) and then subdivide down.

That does bring me to a question about the reset pulse - should it occur on stop of the sequence or on start of the sequence?

@mxmxmx
Copy link
Owner

mxmxmx commented Aug 13, 2018

yeah, not ideal. that's because (as is) the multiplier / scale factor is derived from the quarter notes. the thing needs two clock signals to figure out the speed; it could be derived from the ppq clock, i suppose, but that won't make things more precise i'd suspect and there's still be a delay (probably negligible), ie by 1/48th or 1/96 quarter note.

@giftculture
Copy link
Author

Ah, ok. Well, that makes sense. I appreciate your taking a look at it - sounds like clocking at a higher rate and subdividing is going to be the way to go...

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants