Automate backside controls?
- Rising Night Wave
- Posts: 1265
- Joined: 03 Sep 2019
- Location: Vransko, Slovenia
- Contact:
via combinator?
Rising Night Wave & Extus at SoundCloud
HW: Asus ROG Strix G513QM | Focusrite Scarlett 2i2 3rd Gen | M-Audio M3-8 | M-Audio Uber Mic | Shure SRH1840 | Shure SE215 | Sony WH-1000XM5 | LG 49UK6400
SW: Windows 11 Pro | Reason 10 | Reason+
HW: Asus ROG Strix G513QM | Focusrite Scarlett 2i2 3rd Gen | M-Audio M3-8 | M-Audio Uber Mic | Shure SRH1840 | Shure SE215 | Sony WH-1000XM5 | LG 49UK6400
SW: Windows 11 Pro | Reason 10 | Reason+
This is the RE development sub forum, so no, via the SDK.
Reason13, Win10
- Rising Night Wave
- Posts: 1265
- Joined: 03 Sep 2019
- Location: Vransko, Slovenia
- Contact:
aha. my pardon.
Rising Night Wave & Extus at SoundCloud
HW: Asus ROG Strix G513QM | Focusrite Scarlett 2i2 3rd Gen | M-Audio M3-8 | M-Audio Uber Mic | Shure SRH1840 | Shure SE215 | Sony WH-1000XM5 | LG 49UK6400
SW: Windows 11 Pro | Reason 10 | Reason+
HW: Asus ROG Strix G513QM | Focusrite Scarlett 2i2 3rd Gen | M-Audio M3-8 | M-Audio Uber Mic | Shure SRH1840 | Shure SE215 | Sony WH-1000XM5 | LG 49UK6400
SW: Windows 11 Pro | Reason 10 | Reason+
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.
Last edited by orthodox on 20 Sep 2021, edited 2 times in total.
It's fun to watch the knobs on the back of ABL3 turn by themselves with automation ![🤘](//cdn.jsdelivr.net/emojione/assets/svg/1f918.svg)
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.
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.
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.
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:
acceptance_test_checklist.txt wrote: [ ] 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 wrote: ↑21 Sep 2021I'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:
acceptance_test_checklist.txt wrote: [ ] Verify that no parameters on the back panel are automatable via a placeholder on the front panel.
Reason13, Win10
Such as...?Loque wrote: ↑21 Sep 2021But there are a lot of parameters in several devices, which do not have any control on the front. What about those?buddard wrote: ↑21 Sep 2021
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:
A great development tip is to run the automated acceptance tests locally in Recon, as described here.
I have a few in my mind, but wont name them here
![Shocked :shock:](./images/smilies/icon_eek.gif)
![Confused :?](./images/smilies/icon_e_confused.gif)
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
![Smile :-)](./images/smilies/icon_e_smile.gif)
![Very Happy :-D](./images/smilies/icon_e_biggrin.gif)
Reason13, Win10
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
Don't worry, there's no risk in naming devices that have already been approved!
![Laughing :lol:](./images/smilies/icon_lol.gif)
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.
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.buddard wrote: ↑21 Sep 2021Don'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.
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?
For some others i need to check...
Reason13, Win10
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.
Reason13, Win10
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?
Reason13, Win10
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.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 0 guests