TrackGrabber behaviour

Hi, Im trying to understand a behaviour i am getting with the TrackGrabber and Ableton 10.0.6.

I am trying to launch two clips in slots 1 and 2 on a track by sending an OSC message into Ableton.

If I set the first two slots on the TrackGrabber to ClipNr, I can only seems to trigger the first clip on the track, no matter what messages I send into ableton and define in the S/R address box in TrackGrabber.

If I set the Trackgrabber to ClipName, the the clips launch in a round robin style.

What i ideally need is to be able to define 8 unique incoming OSC messages, and have them launch the first 8 Clips on a track, but i cant work out how to do this.



Also an added bonus feature would be if i could send an OSC message ‘thru’ ableton into another program. At the moment i can only achieve this by having an incoming OSC message to launch the clip, and then automating the clip to trigger a voidgrabber to send a message out of ableton into another program.

It works but its not a pretty solution.

the ideal situation would be the ability to launch a series of clip with user definable OSC messages, then i could match the incoming message with the message that my end software would like to see (Chamsys, OSC messages are pre-defined).

Hi Stuart,

Thanks for getting in touch.

When using ClipNr, it sounds like you may be sending string arguments to Live instead of the expected integers. Here is a Max patch that illustrates the difference:


If this doesn’t solve it, perhaps you could give us a bit more info:

  • which host are you sending OSC from?
  • would you able to add a print-screen of the messages in the Latest Messages Received panel of GrabberReceiver so that we can see exactly what messages you are sending?

I must say that TrackGrabber reacting at all when receiving a message destined for TriggeredClipNr with a string argument doesn’t sound correct. I added it to our todo list. Perhaps we can even do a red blink instead of a green or something like that.

When using ClipName: unfortunately I cannot reproduce the behavior you describe, launching clips round robin style. For me it works as expected. For this too it would help to know exactly what messages you are sending.

Regarding the ‘thru’ functionality, I think I see where you are coming from. With OSC, the way this is typically done is to send the same message to two different ports, one of which is listened to by Live, and another by Chamsys.

This requires your source application to support sending the same message twice though. If this is not supported, you could consider using an OSC routing application such as OSCulator to receive the single message from your source and send out two of them to different ports.

Let us know how you fare!

Yes you are correct, I am sending a string argument. Ill try with integers instead.

I am sending OSC from Node Red, running on the same laptop into Ableton.

The round robin ‘feature’ is actually quite useful for me personally, from looking around the net I couldnt find a plug in that would do this easily. maybe this feature has been discovered because im sending a string argument?

I understand about the implementation of the ‘thru’ function as it stands. the reason sending a message twice from the host doesn’t work for me is i want to input a trigger message into ableton, and then have ableton send out the outgoing message when the audio clip triggers. this allows me to keep ableton and chamsys cues in sync easily.

ill try integer messages and report back.



Here is a screenshot with the received OSC messages in the grabber receiver.

The outcome i am getting is that both messages are triggering the first clip slot on the track.

Hi Stuart,

Thanks for the additional info and for the screenshot. This explains what is happening.

I may have not been clear about the integer messages, the format required would be something like:
/clipNr 1,
/clipNr 2,

Furthermore it looks like Node Red should have the flexibility to implement the round robin behavior there, is that correct?

EDIT: if you want messages to be sent to Chamsys at the moment the clip actually triggers, I think somehow using automation in the triggered or another clip to send out a message is indeed the way to go.

Let us know if this gets you going or if you run into another question.