You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, when reset() is called, there is a large processing load to get the first block. This can happen when the transport jumps/loops or the clip loops. Some kind of reset is required to avoid syncing problems.
Pros
It has been suggested that SetNextSyncPoint could be used instead of reset() as this has the capability of not only specifying the stretch/pitch ratio but also a sync point. This in theory means that instead of calling reset, we could call SetNextSyncPoint and discard any fifos, the next supplied input buffer would then produce an output buffer in sync.
Cons
The main problem with this approach is that calls to SetNextSyncPoint have to be 4096 samples apart which is roughly equal to 90ms at 44.1KHz. If we can only adjust with this granularity, timing might drift as we play back blocks at incorrect stretch ratios whilst we wait for a new ratio to be applied.
For further context at 180bpm (3bps, 0.003bpms), a quarter note would last ~83ms so we would only be able to adjust the tempo/stretch factor every 83ms which means we could be playing the wrong tempo for nearly a whole quarter note.
Our internal tempo changes are accurate to 1/4 quarter note.
This also probably means we have to queue up new stretch/pitch ratios and dispatch them after the required num samples have elapsed.
The text was updated successfully, but these errors were encountered:
At the moment, when
reset()
is called, there is a large processing load to get the first block. This can happen when the transport jumps/loops or the clip loops. Some kind of reset is required to avoid syncing problems.Pros
It has been suggested that
SetNextSyncPoint
could be used instead ofreset()
as this has the capability of not only specifying the stretch/pitch ratio but also a sync point. This in theory means that instead of calling reset, we could callSetNextSyncPoint
and discard any fifos, the next supplied input buffer would then produce an output buffer in sync.Cons
The main problem with this approach is that calls to
SetNextSyncPoint
have to be 4096 samples apart which is roughly equal to 90ms at 44.1KHz. If we can only adjust with this granularity, timing might drift as we play back blocks at incorrect stretch ratios whilst we wait for a new ratio to be applied.For further context at 180bpm (3bps, 0.003bpms), a quarter note would last ~83ms so we would only be able to adjust the tempo/stretch factor every 83ms which means we could be playing the wrong tempo for nearly a whole quarter note.
Our internal tempo changes are accurate to 1/4 quarter note.
This also probably means we have to queue up new stretch/pitch ratios and dispatch them after the required num samples have elapsed.
The text was updated successfully, but these errors were encountered: