Automate backside controls?

[Loque]

How can i make a control like a knob or switch, that is only on the backside, automatable?

[Rising Night Wave]

via combinator?

[Loque]

via combinator?

This is the RE development sub forum, so no, via the SDK.

[Rising Night Wave]

aha. my pardon.

[orthodox]

How can i make a control like a knob or switch, that is only on the backside, automatable?

There is no difference whether it's on front or back side, a control (a property, tba, which can be referenced by several controls) can support automation. It's just that developers rarely declare them as such.

[joeyluck]

It's fun to watch the knobs on the back of ABL3 turn by themselves with automation

A dev can always do like Audiorealism did with ABL3 and tie a knob on the back to a knob on the front. Then those knobs on the back can be automated.

A dev could probably also hide those knobs on the front behind another panel if they didn't want the redundancy and have it taking up space (if the back panel is the focus here).

The way it happened with ABL3 was there were a those controls only on the back first. Then there were requests for users to be able to automate them, so then those knobs were added to the front and to maintain compatibility the knobs remained on the back. They are tied together, controlling the same parameter.

[Loque]

How can i make a control like a knob or switch, that is only on the backside, automatable?

There is no difference whether it's on front or back side, a control (a property, tba, which can be referenced by several controls) can support automation. It's just that developers rarely declare them as such.

Thanks

[joeyluck]

Hmmm see I thought they had to be tied to controls on the front like on ABL3, because ABL3 is the only time I've seen it.

[buddard]

How can i make a control like a knob or switch, that is only on the backside, automatable?

There is no difference whether it's on front or back side, a control (a property, tba, which can be referenced by several controls) can support automation. It's just that developers rarely declare them as such.

I'm sorry, but this is incorrect.
We are not allowed to automate properties that are only available on the backside.
If you submit an RE like that it will fail the acceptance test already on the automated stage.

If you try a workaround like "hiding" a property in a custom display on the front panel, then it will probably fail the manual phase of the acceptance test:

[ ] Verify that no parameters on the back panel are automatable via a placeholder on the front panel.

[Loque]

There is no difference whether it's on front or back side, a control (a property, tba, which can be referenced by several controls) can support automation. It's just that developers rarely declare them as such.

I'm sorry, but this is incorrect.
We are not allowed to automate properties that are only available on the backside.
If you submit an RE like that it will fail the acceptance test already on the automated stage.

If you try a workaround like "hiding" a property in a custom display on the front panel, then it will probably fail the manual phase of the acceptance test:

[ ] Verify that no parameters on the back panel are automatable via a placeholder on the front panel.

But there are a lot of parameters in several devices, which do not have any control on the front. What about those?

[buddard]

I'm sorry, but this is incorrect.
We are not allowed to automate properties that are only available on the backside.
If you submit an RE like that it will fail the acceptance test already on the automated stage.

If you try a workaround like "hiding" a property in a custom display on the front panel, then it will probably fail the manual phase of the acceptance test:

But there are a lot of parameters in several devices, which do not have any control on the front. What about those?

Such as...?

[orthodox]

If you submit an RE like that it will fail the acceptance test already on the automated stage.

Sorry, totally forgot about acceptance testing. Never read the list thoroughly, the requirements keep surprising me when my device is rejected

[buddard]

A great development tip is to run the automated acceptance tests locally in Recon, as described here.

[Loque]

But there are a lot of parameters in several devices, which do not have any control on the front. What about those?

Such as...?

I have a few in my mind, but wont name them here

I must check some stock devices or RS RE if they have non-visible automatable parameters. They do not have parameters, that have automation on the back for sure.

But since Joey mentioned ABL3, this one has automatable backside controls Maybe this is the reason we never saw a new update

[pongasoft]

A great development tip is to run the automated acceptance tests locally in Recon, as described here.

Or if you use re-cmake, there is a simple command to run it (re.sh validate) that takes care of all the details...

Yan

[buddard]

Such as...?

I have a few in my mind, but wont name them here

Don't worry, there's no risk in naming devices that have already been approved!

Even Reason Studios mess up sometimes, just look at the "automatable" and "remotable" REC and RUN buttons on Drum Sequencer... Which can't be fixed after the fact since it would break backwards compatibility.

But since Joey mentioned ABL3, this one has automatable backside controls Maybe this is the reason we never saw a new update

I don't have ABL3... But I'm guessing that he added those properties to the custom display in the front (to avoid the automated test failure), and then the acceptance tester didn't notice the workaround.

But I doubt that this has anything to do with it not receiving any updates. Perhaps it was impossible to add some of the new features due to SDK limitations, or maybe it was too much work to port it?

[Loque]

I have a few in my mind, but wont name them here

Don't worry, there's no risk in naming devices that have already been approved!

Even Reason Studios mess up sometimes, just look at the "automatable" and "remotable" REC and RUN buttons on Drum Sequencer... Which can't be fixed after the fact since it would break backwards compatibility.

But since Joey mentioned ABL3, this one has automatable backside controls Maybe this is the reason we never saw a new update

I don't have ABL3... But I'm guessing that he added those properties to the custom display in the front (to avoid the automated test failure), and then the acceptance tester didn't notice the workaround.

But I doubt that this has anything to do with it not receiving any updates. Perhaps it was impossible to add some of the new features due to SDK limitations, or maybe it was too much work to port it?

Ok. I have Tribute in my mind, which has several more detailed parameters, which are not available at the front. And i think the devices from Oenkenstein Audio have automatable backside parameters, but not sure.

For some others i need to check...

[buddard]

Ok. I have Tribute in my mind, which has several more detailed parameters, which are not available at the front.

OK, I don't have Tribute either, but looking at the screenshot in the shop I only see one parameter on the back panel, and that's Polyphony.
Which are the other parameters that you're referring to?

[Loque]

Ok. I have Tribute in my mind, which has several more detailed parameters, which are not available at the front.

OK, I don't have Tribute either, but looking at the screenshot in the shop I only see one parameter on the back panel, and that's Polyphony.
Which are the other parameters that you're referring to?

They are not on the backside, just only automatable. You can change the unison, filter left/right and a few things more.

[buddard]

OK, I don't have Tribute either, but looking at the screenshot in the shop I only see one parameter on the back panel, and that's Polyphony.
Which are the other parameters that you're referring to?

They are not on the backside, just only automatable. You can change the unison, filter left/right and a few things more.

OK, sorry, I misunderstood you then. I thought the question was about automating properties that only appear on the backside.

[Loque]

They are not on the backside, just only automatable. You can change the unison, filter left/right and a few things more.

OK, sorry, I misunderstood you then. I thought the question was about automating properties that only appear on the backside.

Yea, automating backside is the main question, but if hidden parameters can be automated, why not the backside? Or have hidden properties as a workaround?

[buddard]

OK, sorry, I misunderstood you then. I thought the question was about automating properties that only appear on the backside.

Yea, automating backside is the main question, but if hidden parameters can be automated, why not the backside? Or have hidden properties as a workaround?

Hidden properties are not supposed to be automated either, but they are harder to catch with automated checks, so they can slip through acceptance testing unnoticed.