great and intersting topic

Ableton users???

Hi! For me, using Ping detect for Additional Delay Compensation in ReaInsert works properly, achieving total nullification in phase cancel testing while maintaining synchronisity inside REAPER (for any sidechain nodes etc). Pinging the latency with ReaInsert from analog output to analog input via hardware loopback gives exactly the same number as the driver reported latency. At least with UFX+ and UCX, although there could be some difference when using separate AD/DA converters; to my understanding the driver reports entire roundtrip latency including the internal converters.

This is true also for chaining multiple hardware inserts. But instead of stacking individual ReaInsert plugins in REAPER, I build the hardware effect chain in TotalMix as far as possible, and then use the chain start and end I/O points in a single instance of ReaInsert, and again latency pinging achieves total null in phase cancel test, and software monitoring latency remains as low as possible.

I don't think it's possible to work around the additional latency introduced when stacking multiple ReaInserts in one signal chain as long as the audio itself passes through REAPER and then back to hardware without breaking phase sync between tracks? To my understanding, this is true for all DAWs; passing audio from DAW to external hardware and back inheritly introduces system latency on each pass. Also, REAPER (or any other DAW) has no way of 'knowing' the additional latency introduced from additional routings done in TotalMix and/or external hardware. Except via pinging the latency, of course, and this seems to work properly.

The problem I've encountered with ReaInsert is while 'rendering' individual tracks with ReaInsert hardware inserts. In REAPER I also do this by setting the track recording source as track output (normal mode, not latency compensated), then record the track onto 'itself' as a new take, and after that just bypass the FX chain. Although the latency is compensated while listening/monitoring after restarting the playback, sometimes the recorded track output doesn't get placed correctly resulting in phase/time offset between the original source and recorded output.

But this might also be buggy behavior with ReaInsert. For example, the FX chain latency based on driver reported latency could be 201 samples, and ReaInsert Ping detected additional latency is 9 samples. For some reason, REAPER might compensate the recording with 201 sample offset, instead of the correct value of 210 samples. This can be seen in the track FX chain total reported latency in REAPER, which might show the driver reported latency (or previous manual adjustment) for ReaInsert(s), and not take the current Additional Delay Compensation of ReaInsert(s) into account even after restarting playback, as suggested in ReaInsert UI.

This can be 'fixed' quite easily. After setting up all the routings, ReaInserts and pinging the latencies, simply disabling (bypassing) the entire FX chain in REAPER, and then re-enabling it makes REAPER now show the correct Plugin Delay Compensation values in the FX chain, and now also recording track output gets compensated correctly.

Note, when doing render/freeze/bounce-in-place/commit with hardware inserts in REAPER by recording track output, choosing the latency compensated output recording will compensate the recording into a position after monitoring latency. Which naturally introduces 'latency' in form of positioning offset in the source item. Choosing the non-compensated output recording will maintain the original source position.

In my case, default/stock settings in REAPER seem to work correctly, without any need for manually adjustments. Only the ReaInsert plugin itself needs 'manual' attention, requiring to be pinged and finally 'restarting' the FX chain after routings/changes are done, just to be sure.