Shane

When setting a tempo relative interval interval (4n, b.b.u etc) you are in sync with the master clock. If you adjust the tempo, jit.mo.time adjusts accordingly. 

If you change the interval however you are no longer in sync. If you change the interval back you are not in sync. If you change to accum and then back to function you are not in sync. As jit.mo.time allows us to animate without a mess of phasors with snapshots driven by render bangs, it would be very useful to have 

These would engage when an @interval was set, and their behavior would mimic rate~

I suppose this is an issue, but it read like a bug upon discovery. 

When setting a tempo relative interval interval (4n, b.b.u etc) you are in sync with the master clock.  If you adjust the tempo, jit.mo.time adjusts accordingly. 
If you change the interval however you are no longer in sync. If you change the interval back you are not in sync.  If you change to accum and then back to function you are not in sync. As jit.mo.time allows us to animate without a mess of phasors with snapshots driven by render bangs, it would be very useful to have 
@sync off (default) 
@sync cycle
@sync lock 

These would engage when an @interval was set, and their behavior would mimic rate~ 

I suppose this is an issue, but it read like a bug upon discovery. 


When setting a tempo relative interval interval (4n, b.b.u etc) you are in sync with the master clock.  If you adjust the tempo, jit.mo.time

jit-mo-time-not-in-time

interesting finding. it would be super helpful if you could provide a patch demonstrating these issues, and I'll get it ticketed.

jit.mo.time - not in time