-
Notifications
You must be signed in to change notification settings - Fork 53
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
Comments
hi, can't remember whence, tbh, ... or whether I or @jeremybernstein added this. |
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. 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? |
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. |
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! |
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
The text was updated successfully, but these errors were encountered: