A failover resulting in loss of loop control - any ideas?

Support
1

Hi folks,

Very weird one at a show last night… I’ll try my best to explain the order of events as they happened.

I was running a redundant setup with a PA1U, Ableton/AbleSet open on A and B laptops, both connected to a router, and an Oaktone Mini controlling both. There was also a MioXM on stage, with a bunch of keyboards playing software instruments on Ableton via RTP.

Firstly, in case it’s relevant - I had AbleNet enabled for the Oaktone buttons on laptop A. I noticed that occasionally, laptop B wasn’t triggering playback when I pressed play on the Oaktone. No idea why but I thought to enable AbleNet on laptop B’s Oaktone mappings and that seemed to fix it.

During the show, I see the PA1U fail over to laptop B. Laptop A looked like it was working fine, though - playback still going, MIDI instruments all working. I switch it back via the PA1U front panel. No issues for a while.

Then, I get to a song in which I have a series of loops set up which I have to escape as the tune progresses. I press my mapped ‘Loop Escape’ button on the Oaktone… nothing happens on either laptop.

I then try clicking the Loop Button on AbleSet, on laptop A - the button goes to its ‘off’ state, but the section is still looping.

Then I try clicking on the next song section after the loop, again on laptop A - the section highlights for playing, but after the 1-bar of quantising ‘queuing up’ time… it goes back to the loop.

Ultimately I have to go into Ableton itself and disengage the loop via the dedicated button on the UI. On the other song where looping occurs, I get stuck again; this time, the ‘looping’ button never even highlighted on AbleSet.

Odder still that I retained some control on the Oaktone. I was able to trigger playback on both laptops.

Unfortunately I can’t remember what I was seeing on laptop B, but I do know that I was not able to escape the loops via the Oaktone button.

I’m at a bit of a loss. I’ll be the first to admit that I still have a lot to learn, but this was one of those “never seen that happen before!” moments that was made all the more stressful due to it being an important show in front of a lot of people.

  • OS and Version: macOS Sequoia 15.7.3
  • Version of AbleSet: 3.0.7 (have now just updated to 3.0.11)
  • Version of Ableton Live: 12.3.7

Logs here :slight_smile:

2

Hey @LewisDavie,

Very sorry to hear you ran into this.

Reading through your description, a couple of things stand out that could explain what you experienced:

1. AbleNet toggle on the Oaktone MIDI mappings on both laptops

This is the part that jumps out the most. When both laptops are receiving the same MIDI commands directly (e.g. from a controller that’s connected to both, or via RTP MIDI on the network), the AbleNet toggle on the MIDI input should be off on both. Otherwise, each press gets executed once locally and forwarded to the other host, meaning every command runs twice on each machine.

For a Loop Escape specifically, this could result in escape → re-enter loop happening almost simultaneously, which would look exactly like the button is doing nothing.

So if:

  • Both computers receive the same MIDI → AbleNet toggle off on both.
  • Only one computer receives MIDI → AbleNet toggle on on that one only.

2. Possible state desync after the PA1U failover

When the PA1U failed over to B and you switched back manually, it’s also possible the two instances ended up in slightly different playback states. AbleSet instances are independent — they only stay in sync as long as commands flow through AbleSet itself. The symptom you described (loop button visually toggling off but the section still looping, or jumping to the next section and bouncing back) is consistent with AbleSet’s view of the playhead diverging from Live’s actual position.

The Sync Playback Now option in Settings → AbleNet is meant for exactly this kind of recovery, but not something you can do while Live is playing.

What I’d suggest now:

  • Try to reproduce the conditions in 3.0.11. Same redundant setup, same MIDI routing, same Oaktone mappings. If you can trigger the loop-escape failure, that gives us a much better shot at nailing the cause.

  • Double-check the AbleNet toggle on the Oaktone mappings on both laptops based on how MIDI is actually reaching each one. If both are receiving the Oaktone independently, turn it off on both.

  • Worth keeping macOS up to date: Sequoia has some known networking quirks, and staying current on point releases tends to help, especially for redundant setups that rely heavily on RTP MIDI, and stable network behavior.

There’s a good rundown of the AbleNet + MIDI redundancy logic in the official tutorial that might also help confirm your setup is correct.

Once we’ve gone through the logs and you’ve had a chance to test 3.0.11, we’ll have a much clearer picture.

Let me know how it goes!

1 Like
3

Augustin, thank you so much for the detailed response! I’m going to read this through a couple more times to properly internalise it, and try your suggestions. I should have time next week to give it a shot (and finally update the Mac, which I’ve been unable to do with a lot of big shows happening - good problem to have I suppose!).

A quick follow-up on AbleNet, if you don’t mind - what you say makes a lot of sense. Can I ask, do you think this is why I had an issue regarding triggering tracks on Laptop B prior to enabling AbleNet? If AbleNet being enabled on laptop A effectively means Play/Pause is happening twice on B, that would explain why laptop B sometimes didn’t trigger - because it actually did trigger, but then it triggered again.

Then when I enabled AbleNet on B, it’s effectively firing it… a third time? It’s both receiving the Oaktone button, sending on AbleNet, and receiving on AbleNet?

Oh dear, bit of a mess! You learn from your mistakes :joy: