The Smart Rotary feature was implemented in Avantis v2.0.
While the improved usability of PEQ, FX, and Source Expander was great, I did find a few areas that I felt needed further refinement.
When “Comp Stortion” is selected, please swap it with ATTACK (Purple) so that OUTPUT (Red) appears as the third parameter from the top.
When comparing the order of the GUI on the screen with that of the Smart Rotary, the order is currently reversed.
Additionally, since the GAIN parameter is assigned to the third position from the top in the default compressor settings, users would appreciate it if the order were consistent for ease of use.
I noticed the encoder “order” issue during the Online stream A&H had last week. I thought it really strange that the encoders wouldn’t follow the order of the graphic of the FX, EQ, or whatever is being controlled. That seems like a major error on their part. I hadn’t noticed the color issues, but would agree that everything should be consistent and the “color errors” should definitely be changed to match.
Thanks to all for the input. I can assure you there was a lot of back and forth about how best to implement the mappings, and it was obvious that some compromises would need to be made. We will definitely watch this space and try to make improvements in the future based on your input.
For the v2.0 release, the general philosophy for mapping the contextual controls is as follows:
There are up to [6] mappable parameters for each device as specified for dLive, reduce this to [3] to fit the Avantis.
Order:
Follow the order of dLive mapping where possible
Create consistency between standard models and DEEP processing models for muscle memory (i.e. for a compressor - Ratio/Threshold/Makeup is the primary layout)
Prioritize muscle memory as it relates to control location over matching order presented on the GUI.
Add other important controls if possible (i.e. Release time added for the Mighty where Ratio control would otherwise be)
Colour:
We have an existing precedent for parameter colours (1-6) when presented to a rotary LED as evident on the custom rotaries on dLive. Therefore the controls for DEEP processing or FX units will follow that colour (i.e. Red = Gain) and not change to match the GUI.
With that said, the 16T is actually ‘wrong’ in the Avantis 2.0 release in that the colours do match the GUI, but the knob colour on this compressor is so iconic we decided to make an exception, although the order matches the default RMS/Peak compressor.
Further info on the mapping, in order, can be found in th Firmware Reference Guide here:
MelendyAH - thanks for the additional information. I certainly can follow the logic used, but I certainly do not agree with it.
First, from a user’s point of view, there is little to be gained by trying to match the DLive’s mapping to the Avantis. You talk about muscle memory, but the physical controls are not really that similar between the two systems, so there isn’t any “muscle memory” that directly carries over.
Second, it is far more intuitive for the encoders to match the graphics on the screen when it comes to these “smart encoders” that are only active and control the item being shown on the screen. If a graphic for one compressor has the threshold first and the ratio second, the encoders should match. If another compressor as the ratio first and the threshold second, the “smart encoders” should still match this (and therefore be the opposite of the first example).
Third, I can’t wrap my mind around the fact that A&H is prioritizing “matching the DLive color scheme” rather than trying to be consistent with what a user is actually looking at on the Avantis. This is prioritizing a “theoretical philosophy” rather than the physical “here and now” experience that the user is having on the Avantis. You should be matching what the user sees, not some other console that the user is not currently mixing on (and may never use).
Now that being said, I can understand wanting to bring some consistency between the two consoles, but this should be accomplished by coming up with one color scheme that is used across both consoles for all situations. If you don’t want to change the encoder color, then you need to change the color used on the graphic. There is no reason the graphic and the encoder shouldn’t match. It’s only an overnight (ie inconsistent design) on A&H part that they don’t match to begin with.
Furthermore, this color scheme need to be consistent. To have the colors set one way 90% of the time, but then change 10% of the time only leads to confusing. That is not helpful in any situation and needs to be 100% consistent - regardless of how “iconic” the compressor is.
I largely agree with you. Whilst I can understand Allen & Heath’s approach and really appreciate the effort they’ve put in and the truly massive improvements in this firmware, I too keep coming up against the rather odd logic of the encoders.
It is precisely with the ‘Low’ and ‘Highcut’ rotary controls you mention that it strikes me as extremely illogical that the highcut is on the lower rotary and the lowcut on the upper one…
Loosely related to this it has surprised me from the get go that with Avantis, A&H seem to implement things on Avantis that make sense on SQ and dLive but largely ignore the fact that Avantis has large touch screens and people would naturally assume they can control everything on them, if they wish to do so.
In stead, to this day, some things are still dictated to be controlled via the touch & turn legacy, while my (and I’m sure others’) initial intuition assumed they could be controlled by touching the GUI directly, that being the point of touch screens…
We’re still not able to control most parameters of dynamics processors by a touch and drag motion and almost none of the FX, whereas for EQ this is possible. It seems that A&H have decided to only allow for dragging manipulation on XY type of GUI situations like EQ and dynamic graphs.
That’s simple counter intuitive of a console clearly designed to make heavy use of its large touchscreen(s) and has the screen real estate to allow for control by dragging.
You can use the smaller encoders to control some of the GUI parameters, but not all. Some parameters are touchscreen only.
Other parameters are touch & turn only, like FX parameters.
If your touch & turn encoder ever fails (which happened to me) then you’re going to have a tough time controlling your effects.
So yeah, 'm of the opinion that the focus on maintaining the legacy in terms of control isn’t helpful to the Avantis experience, in fact I believe it rather hinders it.
I was of that opinion when I first demoed it and I’m of the same opinion now, after v2.0.
In fact, to my surprise that particular aspect has only marginally improved.
The only thing that comes to mind is the Q pinch on the EQs, which shoud’ve been there from the get go, of course.
I like the Avantis, but that part of it feel like a mistake to me. I haven’t come across anything that made me think like their approach is the best option. There"s ample screen realestate to allow for dragging, certainly if you allow dragging on both axes.
My €0,02.
I’ve said it before and I’ll say it again.
