Using instance variables in actions and feedbacks in preset definition

[wojtek14a]

Using instance variables is possible in style section of preset definition, it gets automatically updated with instance name. Using the same approach whilst defining actions and feedbacks would be useful as well.

One thing to consider is whether to implement it "as such" and always translate it into instance variable after detecting variable format or adding some other way of marking such option as variable in order to avoid translating something that the user didn't want to transform into variable (but would the user use variable format then?)

presets.push({
	type: 'button',
	category: `${String(i).padStart(3, '0')} - ${portName}`,

	name: `${portName} - talk to selected`,
	style: {
		text: `Talk to:\\n$(generic-module:port_${i}_selected_port)`,  // here it is possible to use instance variable
		size: 'auto',
		color: combineRgb(255, 255, 255),
		bgcolor: combineRgb(0, 0, 0),
	},
	steps: [
		{
			down: [
				{
					actionId: 'talk',
					options: {
						port: i,
						talk_to: "custom",
						custom_talk_to: `$(generic-module:port_${i}_selected_port)`, // here it is not possible to use instance variable
						mode: "toggle",
					},
				},
			],
			up: [],
			500: [
				{
					actionId: 'talk',
					options: {
						port: i,
						talk_to: "custom",
						custom_talk_to: `$(generic-module:port_${i}_selected_port)`, // here it is not possible to use instance variable
						mode: "off",
					},
				},
			],							
		},
	],
	feedbacks: [
		{
			feedbackId: 'is_talking',
			options: {
				port: i,
				talk_to: "custom",
				custom_talk_to: `$(generic-module:port_${i}_selected_port)`, // here it is not possible to use instance variable
			},
			style: {
				bgcolor: combineRgb(255, 0, 0),
			},
		},
	],
})

[Julusian]

I cant find it, but I am pretty sure I have said that is a semi-deliberate choice on my part. Due to a mix of not wanting to introduce other issues, and being limited in how the parsing works today..

The issue I see is that the way we match these variables could lead to false positives if we aren't parsing something intended for us to parse (eg bitfocus/companion#2577).
And as we haven't ever tried to fix up variables in these options before, what will be the impact to other modules if we do so now?

So the recommendation for now is to use the current label when generating the presets, and regenerate them when the module config is updated. that works around it until we have something builtin for you