Persistent target window identification

Injected events to an Ableton window are working just fine for me. However, I have dozens of presets for them. They all need to be updated manually every time I start Bomes (because the window identification is unique for each instance).

Is there a way around this very tedious task? Some persistent window identifier? Or the ability to use a global variable in the Target Control Identifier field?

Since the window identification may be different each time you start Live, I’m not sure how anticipating the target window ID would be possible in MT Pro. With that said, perhaps there is another type of solution. Perhaps a given event could be mapped to a midi note, or cc and then Ableton Live could use that information to provide whatever change you need. Maybe if you can provide an idea of what your current events are doing, I can help you determine if there is an alternate solution.


Independent Bome Programming Specialist and Bome Q&A Board Moderator.


I’ve no idea why, but injecting a mouse click from bome is a lot faster than midi mapping to a controller surface that selects clipslots.
Here’s the main reason I’m using a windows injection for mouse clicks and keystrokes: Ableton (to my knowledge) provides no midi map to focus/select clipslots, which is necessary if you want to delete/copy/paste.
People have written python controller scripts that work around this, but I’ve given up on that method because it introduces about 75ms lag on each click (on my system anyway).
(And I’m using injection so that my standalone VSTs can be in the foreground, rather than ableton.
After posting this topic yesterday, it occurred to me that I could just make a simple windows script that does a search-and-replace on the bome savefile. That will work. But it sure would be nice to be able to assign a ’global’ Target Control Identifier (or assign it to a variable.

Yes, your solution is probably the best for now if you intend to use Bome SW for the solution. Thanks for the explanation! I suspect the delay using python scripting has to do with the fact it is a interpretive language instead of compiled.