PDC and beat-time devices: a discussion and a possible solution

[jbone1313]

Many of us are aware that built-in device modulation synced to the Live transport (i.e. synced to a specific beat-time position) is not compensated. E.g., Beat Repeat and Arpeggiator are not latency compensated when they are preceded by latency inducing devices in their signal path.

As a proof-of-concept and as an experiment, I tried to wrap Live's Arpeggiator effect in Max For Live and set its Free (not synced) parameter value to a calculated value given the current tempo and desired beat division. It worked fine for evenly divisible values, but other values would cause the effect to tempo drift. If the resolution of the Free parameter were finer, then it could have "worked," but there would always be some drift. In practice, that drift might be unnoticeable with the right float precision. IIRC, at a fine enough precision, the drift would be nanoseconds even after like 24 hours.

I think most users would accept an unnoticeable amount of drift in exchange for delay compensation - especially if it were a toggleable option.

Could Ableton update their beat-time based effects with a "Compensated Sync Mode" option with the caveat that there could be some miniscule and unnoticeable tempo drift?

[schlam]

+ 1

[SpecialGuest]

After writing on that other thread I'd already considered wrapping the plugin in Max for live but there is no way to get the total plugin delay compensation value as far as I know. You would need to query that and then use it to offset the virtual transport guiding that nested plugin. Also the way I've been testing it is with a sine wave phase inverted against itself and you can see exactly how far its offsetting things. So the modulator plugin just does what it does and then you phase invert that with utility which is actually how I do ducking by using an external bus feeding it a unit impulse then gate. An individual wrapper kind of sucks though and if we don't have a way to query the total plugin delay compensation I don't see this being as good a solution as updating the way live remote mapping works. That reason was on another forum perhaps but the guy seemed to either be from Ableton or know why they did this and yeah I think they just hadn't figured it out and then once they were gonna do max for live that locked it in and they weren't gonna correct it.

[jbone1313]

Just to make sure we are talking about the same thing: the issue is the lack of delay compensation for beat-time devices like Beat Repeat and Arpeggiator?

If that is the case, then I don't think any wrapping in Max for Live devices will help. IIRC, I have tried that for days. I have my own Max for Live wrapper devices for delay compensating other plugins. But, even if you know the amount of latency for which to compensate, the issue is delaying the incoming signal and then reporting the latency to Ableton does not work for beat-time devices.

The solution I proposed here is for Ableton to update its devices to - under the hood - use millisecond values that correspond to the current tempo. As I wrote in the OP, I think that is impossible to be perfect, because floating point math will never divide evenly for all tempos, but with large enough floating point precision it would not matter.

Perhaps there could be an option in each device to toggle latency compensation on/off with a warning that turning it on means a loss of accuracy.