mxmxmx / temps_utile-

teensy 3.2 trigger generator
Other
146 stars 52 forks source link

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

Open giftculture opened 6 years ago

giftculture commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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!