Hardware API: Binding a Track's Selection to a Button

Post Reply New Topic
RELATED
PRODUCTS

Post

Hi all,

new recruit here, thanks for letting me in!

I'm wondering if anyone might know if there is a way to bind a HardwareAction (in my case a HardwareButton's pressedAction() to the action of selecting a track. I have a track bank with n tracks and n hardware buttons and would like to bind each button so that it selects the track bank's track at equal index.

For the heck of me I can't find a HardwareBindable on the track, cursor track or track bank.

Any pointers would be great as it'd be much cleaner than creating the various observers necessary to do the bidirectional communication and covering those edge cases when scrolling the bank, adding/removing tracks etc.

Many thanks in advance!

Post

Yo bossi, sorry for the super late reply.

Were you able to figure this out? Yeah that is a little annoyance of the api... but you can do it.. if there is no action provided by the Bitwig object, you can create your own...

ControllerHost.createAction() is the way. or in your case... you provide a lambda and then it will get called when the event you assign it to occurs.

If you need specific code examples let me know.
----------------------------------------------------------------------
/CTRL → http://slashctrl.io
Music & mixes → http://soundcloud.com/kirkwoodwest

Post

Hey Kirkwood West,

thanks for getting back to me! No, I didn't end up finding a built in action to bind to, it seems like there is none. Thanks for pointing out the option for custom actions, that's what I know I could do but tried to avoid for two reasons:
  1. It's (obviously) more verbose, partially defeating the benefits (or at least nice side-effect) of the hardware API.
  2. Uncertainty whether or not custom actions actually yield the performance benefit of the hardware API: Do they get compiled down into the C layer? I doubt it as it's just a regular Java implementation you're writing just as you would without using the hardware API, no?
If b. is not the case and custom actions don't end up running in the C execution environment, would there be any reason to use the hardware API, as long as we're only considering this one action?

I was also a bit surprised to not find a built in action for track selection as it seems like a fairly common use case but it will likely get added in the future and seems to have a few quirks that might make implementation more specific that others.

Yeah, mainly wanted to confirm with someone who's been using the API for a bit longer if I'm just missing it, so thanks for confirming! If anyone does figure out a native solution or it gets added to the API later on, it'd be great to document it here!

Thanks again for your pointer to the custom action, no need for further example, I think I've got that dialed in but cheers!

~Bossi

Post

Bossi wrote: Tue Apr 29, 2025 2:57 am
Yeah, mainly wanted to confirm with someone who's been using the API for a bit longer if I'm just missing it, so thanks for confirming! If anyone does figure out a native solution or it gets added to the API later on, it'd be great to document it here!

Thanks again for your pointer to the custom action, no need for further example, I think I've got that dialed in but cheers!

~Bossi
Selecting track is likely a non-performant issue so thats why its like that. I'm quite sure you are right about the custom built in actions being more performant. I cant think of a way to verify the speed, that would be fun.
----------------------------------------------------------------------
/CTRL → http://slashctrl.io
Music & mixes → http://soundcloud.com/kirkwoodwest

Post

Yeah, I haven't explicitly run into noticeable latency issues with somewhat more complex actions in the Java layer either but it seems to be an issue that is obvious enough to make the decision and develop the hardware API from what I understand. I do wonder if that's the main reason though or possibly a requirement for extensions to integrate more deeply with some of the more advanced control surfaces that seem like they might (I'm just guessing) execute partially on the device itself; I've been wondering if that might be the case with with devices requiring some standardized locally executed control to drive and customize the controls (displays, lights etc.), but yeah, just speculating. At any rate, thanks for the pointers. Custom actions it is for now for those track select troublemakers!

Post Reply

Return to “Controller Scripting”