Unpredictable behaviour when CUE recording with Ableton Link enabled

josh

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!

Jack

Hi josh,

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.

josh

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?

josh

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:

A last resort (but maybe the most powerful solution) would be to disable Ableton completely, enable CUE (I think it's a very useful feature to have) and to keep track of all the information inside Mozaic (I only need to make sure that the tempo in both GTL and AUM is equal, I guess). As long as I only interact with GTL through Mozaic, I could probably keep a "mirror" of GTL's state inside my script and as such could create my own triggers which are tied closely to GTL's behaviour. I'm unsure though whether not any "inprecisions" would appear after a while, because in the end AUM/Mozaic and GTL are not "really" tied to each other, both keep their own timeline (which hopefully do not drift apart from each other)...

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?

josh

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?

josh

Notes to myself (before I forget them, as I'm going away for the weekend):

• Regardless of Link running, when arming an 8 count loop, GTL waits until it reaches an "8 count dividable" beat. This means, I won't be able to record a short loop (e.g. 1 or 2 counts), let it play once or twice, and then directly record an 8 count loop: I will always have to wait until "8" is reached.

• 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.

  • Although using Mozaic's @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.

  • In this situation, stopping recording needs to be done manually.

• "Sync Quantum" is only relevant for switching groups, not for recording (???)

• Instead of trying to force GTL to act in a way that it does not provide at the time being, I could try to use another looper app (e.g. Loopy HD) side by side with GTL: for example, to create drum patterns in the very beginning (which I need the "1+8 bars use case" for) I could first send the signal to Loopy HD, record 1 bar, then let it play and immediately start and record an 8bar loop in GTL (I would need to disable the count-in for this).
  • But maybe there are better ways of achieving some drum patterns, recorded from a mic, e.g. something like Samplebot?

Jack

@josh said:
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?

Hi Josh,

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.

Cheers

josh

Oh, I see. This is a bit confusing IMHO. Thanks for pointing it out.

josh

@Jack said:
Hi josh,

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.

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).

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.

As I need GTL to be synced with AUM, turning Link off is not really an option.

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.

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.