Ableton Live & Nome I - Aggregate Device - problems introduced by Abletons Return Channels.

[IslabBlanca]

I’m using the midronome Nome I with Usync Plugin in bidirectional way and everything is landing around 3 ms - both audio and midi datas recorded from the elektron analog rytm into ableton live. But as soon as I add one Return Channel, even without sending something into the return, I get a unexpected shift which only will go away when I delete that return track. i’m running mac os tahoe on a mac book pro and use an aggregate device of apollo x8p gen 1 with a ssl big six. All synths are being recorded with the apollo and routed via ableton live and apollo line outs into the ssl big six. Only the analog rytm’s kick is feeding a mono channel of the ssl big six directly and the main bus of the analog rytm’s is also directly connected to a ssl big six stereo channel. I feed the signal of the ssl main bus back into ableton and from there into the main bus from ableton’s monitor path. keep latency is set to off while delay compensation is active. So in my case I need to use audio channels for FX sends instead of return channels otherwise everything is off grid. in usync I have the box checked for large latencies and my shift is set to 0 ms. is that a known issue with abletons return channels routing?

[simntonic]

Hi

First thing I do want to mention that we have not tested with aggregated audio interfaces. If it works then great, but this is not an officially supported configuration.

Regardin the return track, this sounds like the timing of the recording changes to the same as the "monitoring timing".
Could you:
1. Try to delete the return track, and turn on the monitoring - this should land the recording very "late" - is this the exact same position as the one you get when you add the return track?
2. When you add the return track (with monitoring off), does moving the U-SYNC "SHIFT" slider move it back in place?

Simon

[IslabBlanca]

Ok so then you know it at least now: Aggregate Device with Mac Tahoe is possible, but please note that Abletons Routing Matrix for the return channels will introduce an unwanted shift on all channels even when you don’t send something into it. Otherwise my usync settings is a 0 ms and everything is around 2.5-3 ms on the grid. But as soon as i load a return channels into the project, the same kick will land somewhere and shift doesn’t change something at all. So with aggregate device just dry to avoid return channels.

Yesterday I tested both audio interfaces in solo modus and there everything is working well with the returns, but aggregate device modus with both is not.

[IslabBlanca]

Just to let you know when a return channel is added:
If shift in U-sync is set to 0, the kick lands aroun 184 ms to early, when shift is set to +100 ms it is +41 ms to early, when shift is set to -100 ms the print is 241 ms to early. It doesn't matter if it is recorded with Monitoring In, Monitoring Auto or Monitoring OFF. all prints land around the same position there is no difference between those settings.

[IslabBlanca]

Hi Simon, thanks again. To sum up what I already tested:

Adding an empty Return track is enough. Nothing is sent to it. As soon as it exists, recorded kicks land ~184 ms early. Deleting the Return brings everything back on the grid (~3 ms).
Monitoring makes no difference. In, Auto and Off all give the same offset, as does buffer size (128/256).
The shift slider doesn't compensate linearly (+100 ms → 41 ms early, −100 ms → 241 ms early).
Enabling drift correction on both sub-devices of the aggregate brought the kick closer to the grid, but then the Return itself was ~266 ms off.

For comparison, I have now moved recording to REAPER (same aggregate Apollo x8p + BiG SiX, same Nome I FW 5.5, U-SYNC plugin, no bidirectional control): kick lands +1.9 ms after the grid, jitter ±0.4 ms, measured over 43 hits at 122 BPM. Returns in REAPER are just regular tracks with sends; I will test those next.

One more REAPER finding in case it helps others: the Analog Rytm MKII did not start on REAPER's play (Nome display showed "PLA") while other gear on the same MIDI distributor did. A resync (long press / CC 103 = 20) started it. The fix was to disable "Receive CC/NRPN" on the Rytm; now it starts from any position.

So in Live the issue seems tied to how Live handles latency compensation once a Return track exists with an aggregate device.

[simntonic]

Hi

Thanks for all this feedback. I did some testeing with return tracks. I do not think the return track itself has any impact, the real impact are the plugins you put on the return track. Those plugins move the overall Ableton timing backwards, and I guess you in case those plugins have a huge plugin latency (a total of 184ms I would assume).

The lack of linearity when moving the slider is caused by the fact that as you move that slider, the U-SYNC plugin latency changes compared to the return track, and depending on who's bigger this gives strange results.

The normal way to solve this would be to use the checkbox "I use plugin with large latency" - this works with latency on normal tracks but it seems it has no effect when the latency is from a return track.

Could you:
* try anyways to see if setting the checkbox has in any impact in your case
* try changing the track delay on the U-SYNC track

Simon