Martin Beck

Is there a way to set the focus on a specific live.numbox from within the patch so it mimics that it was clicked by the user?

Question relates to the following problem when overwriting an automation during recording. I have an [incdec] object connected to a live.numbox and if the focus is not on the numbox a previously recorded automation in Live will update the numbox and the value set with incdec-tickbox will only shortly take effect. The automation and the tick box value compete against each other resulting in a flipping of values. There is no such problem if the focus is initially on the numbox during recording.

So I am looking for a way to set the focus on the live.numbox when the [incdec] is clicked.

M4L_Q_numbox_automation_tickbox.amxd

Question relates to the following problem when overwriting an automation during recording. I have an [incdec] object connected to a live.numbox and if the focus is not on the numbox a previously recorded automation in Live will update the numbox and the value set with incdec-tickbox will only shortly take effect. The automation and the tick box value compete against each other resulting in a flipping of values. There is no such problem if the focus is initially on the numbox during recording.
So I am looking for a way to set the focus on the live.numbox when the [incdec] is clicked.

Is there a way to set the focus on a specific live.numbox from within the patch so it mimics that it was clicked by the user?
Question relat

set-focus-on-a-live-numbox

Not to my knowledge. Standard numboxes have a 'select' message but live.numbox doesn't.

But I also don't understand the situation you're concerned about based on your description. I get the sense that you're using this special [live.numbox] behavior when focused to solve a problem that might better be solved using [change] objects or some other programatic logic between your [incdec] and your [live.numbox].

Not to my knowledge.  Standard numboxes have a 'select' message but live.numbox doesn't.

But I also don't understand the situation you're concerned about based on your description.  I get the sense that you're using this special [live.numbox] behavior when focused to solve a problem that might better be solved using [change] objects or some other programatic logic between your [incdec] and your [live.numbox].

The problem is related to how Live recognises if a parameter automation is supposed to be overwritten and therefore should not affect the live.numbox. I don't see how this can be solved with [change] objects as the problem is related to the automation architecture from Live. So if the focus is initially on the live.numbox during recording Live shows this parameter as active parameter in the automation lane and the [incdec] works as expected, but automation and [incdec] compete if the focus is not on the live.numbox.

The problem is related to how Live recognises if a parameter automation is supposed to be overwritten and therefore should not affect the live.numbox. I don't see how this can be solved with  [change] objects as the problem is related to the automation architecture from Live. So if the focus is initially on the live.numbox during recording Live shows this parameter as active parameter in the automation lane and the [incdec] works as expected, but automation and [incdec]  compete if the focus is not on the live.numbox. 

Behaviour is a little bit weird, also found some inconsistencies to my description above meanwhile. So I guess it will be best to listen for the 

and disconnect the [incdec] appropriately.

Behaviour is a little bit weird, also found some inconsistencies to my description above meanwhile. So I guess it will be best to listen for the live.observer record_mode and live.observer session_record_status and disconnect the [incdec] appropriately.

Set focus on a live.numbox