AbletonOSC mute values are duplicated to the previous track index

General
1

Hi,

I’m using an OSC Connection to AbletonOSC to get mute feedback for individual tracks in my Canvas, and the received values seem to be written to two track addresses at once.

Setup

  • AbleSet 3.1.5 (3.1.5)
  • macOS Tahoe 26.6.1
  • AbletonOSC installed and selected as Control Surface in Live
  • OSC Connection named AbletonOSC, Send Address 127.0.0.1:11000, Listen Port 11001
  • Listening started with, for each track index 0–10:

js

  sendOsc(":AbletonOSC/live/track/start_listen/mute", int(i));

What happens

When I mute a single track in Live, the value is set both on the correct address and on the address of the track before it. Muting track index 3 results in both of these being true:

:AbletonOSC/live/track/2/get/mute   true
:AbletonOSC/live/track/3/get/mute   true

The same offset happens for every track. Muting track 1 sets index 0 and 1, muting track 2 sets index 1 and 2, and so on. In the Canvas this means the button for the track I muted and the button for the track above it both change color.

Sending mute commands works correctly. /live/track/set/mute with the right index always affects the intended track in Live, so this only seems to affect received values.

Log output

With this in the Project Script:

js

for (let i = 0; i <= 10; i++) {
  onOscChange(`:AbletonOSC/live/track/${i}/get/mute`, (args) => {
    log(`track ${i}: ` + JSON.stringify(args));
  });
}

muting one track in Live produces two entries:

track 2: [true]
track 3: [true]

Note that the argument is just [true], without the track index that AbletonOSC normally sends as the first argument, so I assume the compatibility layer strips the index and writes the value to two addresses.

Is this a known issue, or is there something wrong with my setup? Any workaround would be appreciated.

Thanks!

Values - OSC - AbleSet
Values - OSC - AbleSet1640×2360 218 KB

2

Hey @joelstromgren, welcome to the forum, and thank you for the detailed description!

I just tried to reproduce this issue on my end but it all seems to work as expected here:

One thing I noticed though is that the index of a track’s events stays locked even if its position changes, so adding a new track and then sending all of these start_listen commands again could cause this issue you’re experiencing.

Maybe sending stop_listen commands before subscribing to changes in order to make sure everything is clean will help.

Let me know if this works for you. I’m looking forward to your reply! :slight_smile: