Group The Loop / AUM: Unpredictable behaviour when CUE recording with Ableton Link enabled

josh83

I'm still puzzled about the whole Ableton Link thing. So I created a video demo of what I feel is strange and confusing.

I often want to start a performance with a very short (1 bar) drum loop in main group's slot 1. Then I want it to play once, and then immediately I want to record a longer (usually 8 bar) loop in group 1's slot 1 (while the drum keeps playing).

The following video demonstrates that the recording of the 2nd loop (8 bar) always starts at a seemingly unpredictable point in time. So sometimes the record kicks right in (first attempt in the video), while other times it takes "ages", and during that time only my drum is playing, which is very boring to the audience.

I need to understand what's going on here. I guess it has to do something with Ableton Link "setting the tone" somewhere in the background, but I have no idea 1) how to control this or even 2) how to see Ableton Link's current state so I could adapt to it (if I can't control it myself).

I'm running GTL from AUM. I have enabled the CUE option and Ableton Link with the following options:

And here's how I load GTL through AUM:

By the way: I need GTL's CUE option active, and also I need GTL to sync to AUM, because in AUM I'm running a Mozaic MIDI script that relies on events like @OnNewBar and @OnNewBeat. And while we're on the subject: where does the @OnNewBar info come from? From GTL? From Ableton Link? From AUM itself? Is a bar always 4 beats? Or does it rely on the clock setting in GTL?

Thanks a lot. If I can figure this out I'll be ready to go performing.

[Deleted User]

That timeline shows you're halfway through a bar. It starts form the left and counts out the beats of the bar. in 4/4 it will have 4 segments like in your pic. if you stop the transport, it will stop where it is, and restart form there unless you click the left arrow first, which will take you back to the start of the timeline. In that state the bar takes up full width, but as soon as you hit play it starts again from the left.

It might be something to do with cueing your second loop when you're halfway through a bar sometimes? So there's not enough time to cue and it has to go through another full bar. Not sure.

You could try resetting that bar line to 0 in AUM each time before looping in GTL, to see if that fixes it.

_ki

@SimonSomeone Your description of AUMs timebar behavior is correct if Link is disabled, but in the OPs case Link is active.

In my experience its like: If Link is enabled in AUM and there is at least one link enabled external app loaded, then the bar line is running even if AUM is stopped. Pressing play in AUM (and perhaps its the same in GTP) will start playing AUM and its plugins starting from bar 0 when this line reaches its end - not when you pressed start.

So if one presses play while the line is still more to the left, there will be a longer gap before actually starting to play. If pressed right before the turn-over, its only a short gap.

In Link, there is no sync master - the Link library drives the clock and bar sync. Therefore none of the Link apps can advance the timeline, all the can do is set a new tempo or issue a Link Start/Stop command send to the other apps. Link Start is probably send ‚on the next regular bar-start‘, In my experience Link Stop is done immediately.

.

But i‘m no Link expert, that just what i deducted from using the Lumbeats apps (drummers and i-bassist) in conjunction with AUM

josh83

Thanks for your explanations, guys. I'm slowly getting kind of an image of how this all works together, and what's its peculiarities.

It might be something to do with cueing your second loop when you're halfway through a bar sometimes? So there's not enough time to cue and it has to go through another full bar. Not sure.

@SimonSomeone This is an interesting point. I thought about something like that earlier myself. At present I don't really think it's the case, but I will keep it in mind.

@SimonSomeone Your description of AUMs timebar behavior is correct if Link is disabled, but in the OPs case Link is active.

In my experience its like: If Link is enabled in AUM and there is at least one link enabled external app loaded, then the bar line is running even if AUM is stopped. Pressing play in AUM (and perhaps its the same in GTP) will start playing AUM and its plugins starting from bar 0 when this line reaches its end - not when you pressed start.

@_ki Yeah this is exactly the problem. As soon as GTL is connected through AUM and is connected Link, Link starts to run regardless of the Play/Pause state. I really wonder whether that's wanted behaviour, and what's the reasoning behind it. I will see whether I can reach out to the developers of Ableton Link for this.

Jack responded to the same question in the GTL forum (I sometimes post clones of my questions there to receive more attention by the GTL staff):

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.

So I still feel that I'm missing some important information about Link in AUM: I understand now that GTL asks Link for when the next 8 bar phase can start. GTL even indicates this by changing the resolution of its own timeline progress bar:

So there must be some additional information available within Link that is not revealed by AUM's timeline (which only displays 4 bars all of the time):

If I could see this information somewhere, I could maybe adapt my behaviour to it. Maybe there's even a possibility to retrieve this information from within Mozaic?

josh83

As soon as GTL is connected through AUM and is connected Link, Link starts to run regardless of the Play/Pause state.

Just to prove this point: It's not even depending on whether GTL is somehow loaded through AUM, see here:

Janosax

Try to change sync quantum setting in AUM, the mini timeline can match GTL CUE setting. Also, use Link start stop (enabled in both apps).

Sync quantum in GTL in my experience must be set to 1, 2 or 4 bars, but not longest loop or you will eventually have to wait a long time when tap play.
1234 count in can sometimes also introduce too much time to wait.
You can also enable force phase alignment setting.

_ki

Yes, that the idea - the Link enabled apps don‘t need to ‚load‘ each other - still they are able to detect others apps and sync - they don‘t even need to be on the same device to find each other just in the same WLAN and computer network.

.

I assume that the sync phenomenon is the expected and desired behavior. As mentioned above - the purpose of Link is to enable multi-device / multi app syncing, there is no master all Link clients have the same rights (set tempo, issue a global start or global stop) but none of them really drives the clock - thats independend of all apps or devices. As soon as there is a link session, the clock starts ticking and all others sync to it.

Link Start and Link Stop are new features added with version 3, i didn‘t yet look it up, but Link Start might even be defined as ‚start on the next bar‘