Unpredictable behaviour when CUE recording with Ableton Link enabled
Please see https://forum.audiob.us/discussion/40394/group-the-loop-aum-unpredictable-behaviour-when-cue-recording-with-ableton-link-enabled/p1?new=1.
Although it's a GTL specific question, I posted it in the Audiobus forums as people seem to be more responsive there. I'd be very happy for some comment from your side though, @Jack!
So when we record an 8 bar loop, GTL asks Link for the beat time to sync to. As it's 8 bars GTL gives Link an 8 bar "phase" to work with. Link then returns a beat time which conforms to this phase. Link has to synchronise phase across multiple apps so all apps start their 8 bar loop at the same time. This means that GTL has no control over the beat time over a particular phase so it could come in at any point through the sequence. This is why you are seeing the unpredictable behaviour when cuing to record the 8 bar loop. If you turn Link off then GTL manages the phase and it becomes more predictable as GTL doesn't care what other apps are doing.
I think using GTL with CUE turned off is the only way to set exactly where you want the loops to start and stop recording. You can try changing the 'Sync Quantum' to 1 bar but this only really affects starting and stopping the session and switching between groups.
Hope that helps.
Thanks for your explanations. I'm learning a lot here (mostly about stuff I wished I never needed to know ).
So now I have disabled Link and did the same experiment again. Now it is fully predictable, but I don't get why I need to wait until an 8 bar phase reaches its end when only a 1 bar loop is running?!
I feel that the "Sync Quantum" option should not look at the currently set clock length (at least when Ableton is disabled, as it doesn't have to wait for any other application now), but at the longest loop in the running (or main) group. Don't you think?
Ah, I see that "Sync Quantum" doesn't have an effect on recording, only on switching groups, as you have indeed pointed out above already.
This is really sad. This means I have to disable CUE to make my performance work (record 1 bear, then let it play once, then immediately record an 8 bar loop). But without CUE I'm completely on my own with no clock length etc., which is too scary for me. I could probably handle everything with Mozaic as explained here:
But I hoped this would not be necessary.
Maybe you should consider an option that CUEing something will only depend on the longest loop of the current group (or the main group), and has nothing to do with any "general phase" of anything. Do I miss something here? Or do you find this a viable suggestion, @Jack?
Another question: it seems that GTL sometimes "loses" some advanced Link settings, like "Sync Quantum". They are just not displayed anymore, although Link is enabled:
Is this a bug? Or do I miss something?
Notes to myself (before I forget them, as I'm going away for the weekend):
Only when Link is running and Ableton's general phase is running in the background, my needed situation may occur from time to time, but it's hardly predictable.
@OnHostStart(and knowing about the individual parameters that configure Link) it would probably be possible to create a script that can calculate the necessary things and knows exactly when to do what so my situation could be predictably re-created. Still, it would be pretty fragile.
When disabling CUE, all the "clock length" and "count in" features in GTL are not available.
"Sync Quantum" is only relevant for switching groups, not for recording (???)
I expect you are tapping on the clock view at the top of the screen. This doesn't show the advanced options. You will need to go into the settings and scroll down the clock settings to find the advanced options such as 'sync quantum.
Oh, I see. This is a bit confusing IMHO. Thanks for pointing it out.
I'm really struggling to find a way to "predict" this behaviour. My requirement is that my Mozaic script can predict the point in time when all apps start this 8 bar loop at the same time. This is due to the fact that Mozaic will need to set up the inputs that are sent to GTL just before that point in time.
As Mozaic knows GTL's current clock length (I manage its state only through Mozaic so I can track it), there must be a way to talk either talk to Ableton Link somehow and retrieve the state, or that GTL itself would send some signal using MIDI that then could be received by Mozaic (for example, the signal could be sent 1 bar before the actual start, so my script would know that it can set up the inputs at the end of the current bar).
As I need GTL to be synced with AUM, turning Link off is not really an option.
I thought about doing that and renounce all the nice features that CUE offers. But this would mean a lot for me to handle in the background, which would probably be possible with Mozaic, but I fear that GTL and AUM would diverge in synchronicity after a while (e.g. due to "lags" or high CPU load). So having Link taking care of these very basic things is really good. But for my use case it's very bad that I just cannot predict this very moment described above.