So there’s now individual on/offs for each filter AND and an on/off for the whole filter section!!!
The individual on/offs are hidden until you hover over them, and they’re off by default.
You couldn’t make it more un-user friendly if you tried…
1 Like
@JamesNorth @vncvr @Kip @Janko_Kezar @Highly-Controversial @Pablin_Drummer @vinylizor
(I moved your posts into a new thread. I hope you don’t mind.)
Indeed, the new design is due to the automation issue with the previous design. Unfortunately, as you all have noticed, there is now an additional click needed to active the filters.
You can of course use the Q-LINK function in the MixConsole to enable multiple Pre-Filter sections at once.
6 Likes
They are always visible if you use the sliders instead of knobs.
Actually its easier to discuss the topic. Thanks Matthias.
I actually dont mind the extra step as long as the automation issues are resolved. The only thing I would ask is to include the on/off state when saving default setting for pre gain/filter section.
1 Like
I get allowing the automation to function properly is important - that bothered me for years … I just don’t understand why they are not enabled immediately you start turning a knob?
The behaviour of having to press a tiny button (for each of the two filters) before turning the knobs is completely inconsistent with the other bands on the EQ strip, ahd it’s a brand new step in using the EQ.
They are all disabled by default but immediately enable when you use that band without having to turn them on.
It might not seem like much but having to do that across 50 tracks, each track … and not being able to globally enable that adds a lot of new processes where it hadn’t been necessary for many years prior.
Much like the recent executive decision to reverse the zoom scroll direction on the previous point release, this one is another poorly considered UI change that has no functional benefit - all it does is increase the time taken to complete a task.
No problem Matthias,of course
This is not a global solution and must be done for every single project …
Ahd it’s not a new click to enable the filters, it’s a click per filter - two per channel.
Isn’t it actually consistent now with the EQ? Turning a know won’t activate the band. Clicking in the EQ graph will though. The difference is that you cannot enable and edit the Pre Filter in the graph, right?
Yes, that’s correct of course.
The team needed to fix the automation issues with Pre filter and we are well aware that the new design is a compromise.
1 Like
I’ll test my process out when I’m on the machine again - there were about 3 things that bothered me about the new method. I use the low cut one a lot across large projects and I found it very laborious with the new steps.
I’m extremely surprised process changes like this are just thrown into point releases these days.
I wonder whether saving a template will save the state of the input filter?
1 Like
That should do the trick.
1 Like
This was obviously implemented by someone who doesn’t actually use the software much!
If they could just default to being ON - as the other EQ bands do, then it wouldn’t be such a big issue. But filters get a lot of use. We’re now forced into yet more clicking just to fix an automation issue that’s used way less than just setting a filter to an appropriate frequency!
3 Likes
… unfortunately, a recurring theme with Steinberg over the past few years, for example the random decision to deface the F2 Transport Panel in C10. I have grown to accept many acts of UI absurdity from Steinberg over the years, but it’s the same across all sectors of software developement at the moment – “agile”, i.e. chuck some rubbish out there and eventually we will/may/might* fix it.
*if it increases profit
1 Like
Just to be clear, does this bug have to do with automation? or does it have to do with remote control/generic remote?
Did this change what I think it changed? (i’m not on 11 yet)
I love you, Steinberg, and Cubase… but, I’m going to have to be pretty direct and blatant in saying that this was a terrible change for what I see (correct me if I’m wrong) as a very insignificant “bug”.
One could say that that is subjective and my opinion, but I’m going to argue that this is objective and from a professional commercial engineering perspective - it’s not logical, and doesn’t make sense… at all.
This is an instance where fixing a “bug” was actually counter-productive and self-diminishing to the integrity and workflow of the software and if this change was made simply for the sake of notching a “bug” off the list without putting much thought into whether the solution will be diminishing… Than I would reverse this immediately @Matthias_Quellmann … In fact, I sort of demand that it’s reversed… like if it’s not… I’m strongly considering buying a $3000 plane ticket and camping outside Steinberg HQ like Greta Thunberg.
I put “bug” in quotations, because from an engineering perspective, people should not even really be using Automation on the Pre-Filters, I’m surprised people are even doing this, never thought of it myself, never heard of others doing it, never heard of this “bug” or seen it reported and imo, if anything, the ability to automate the filters should have just been removed instead of workflow and ergonomics in the channel editor being diminished.
Here’s why - - the Pre-Filters and Pre-Gain/phase are an engineering utility. This is like a push button filter on an API mic pre where there’s two buttons and three frequency/curve options, except in this case, the Cubase filter being digital it is fully variable.
The whole purpose, is to - as quickly as possible - and without much thought - cut away unneeded frequencies and problems and then move on down the rest of the signal chain. It is a set-and-forget engineering utility. It is a basic fundamental no-frills boring engineering utility - in which its ergonomics and ease of use are the primary importance
Anyone who is wanting to be doing automated filtering, should be doing so on the channel EQ low and high bands, and or, using an insert. If their contention then would be that the Channel EQ doesn’t have the same Filters as the Pre-Filters, then the Pre-Filters should be added to the Channel EQ as slope options.
Actually, it’s not ‘additional’, before there was no need to click at all if you had a mouse-wheel - you could mouse wheel a Pre-Filter on and select a frequency all in one stroke of the mouse wheel.
So before potentially there were 0 clicks, now, if I have 64 tracks, there are 128 clicks…
Sorry but, this is 1,000,000% a no go from me. This is completely a self-diminishing design change and the weirdos out there automating their pre-filters can automate something else.
This isn’t really a solution from commercially working professional engineer, because, filtering work is incremental across tracks and the visual of what has been engaged serves as an indicator as to what has been filtered, and what still needs to be/hasn’t (like button lights on a console)
The Channel EQ and Pre-Filter serve different tasks. With a Pre-Filter, someone is cutting away blatantly obvious unneeded frequencies on the source material, whereas when working with a Channel EQ someone is taking more time and perhaps setting frequency points and boost/cut amounts before engaging a band so their ears can properly discern and analyze the difference, essentially A/Bing each band.
That being said, if I had to choose, I would actually make the Channel EQ to work like the old Pre-Filter did, because someone might Default Preset certain curves and frequency points they like into the channel EQ and being able to mousewheel or one click engage by dragging the bands gain would be nice fluid workflow (like the Pre-Filter once was) almost like using a Graphic EQ.
_
_
What actually needed to be fixed, is that in MixConsole, dragging the Pre-Filter doesn’t auto-engage like it does (/did) in the channel editor, yet the Gain slide does. this was an actual bug and design inconsistency, which should be fixed after this change is reverted, and then you should just remove automation from Pre-Filters since it never worked anyways.
what should have been fixed:
(notice use of mouswheel)
I agree with @vinylizor , this seems like a change made by someone who is not mixing/engineering 14 hours everyday.
Sometimes @Matthias_Quellmann I think Cubase has been around for so long, with maybe different hands working on the same part, that the Devs forget why something was designed a certain way with a certain engineering workflow ethic and philosophy in mind and what seems like a small inconsequential change to remediate a “bug”, is actually a huge annoyingly consequential workflow-diminishing change.
I mean, I do love you…but… something was ruined that was already perfectly designed (apart from not being consistent in MixConsole, which is what was actually maybe causing the “bug”/problem??)
Who thought a post could be so long about… a filter section…
Please revert.
7 Likes
Are we finally seeing the Yamaha take over coming through ? I was always skeptical about the move ,could we be after all these years be seeing the true state of the merger ? Add a couple of tiny new features , less maintenance up dates but more cash ? This sort of thing will drive the young ones away and eventually force everyone to leave if it is .
I know someone that designed a new controller for using with the Channel strip , now just because of one tiny move by Steinberg he has to redesign the controller to incorporate two switches . lucky it hasn’t been released yet otherwise people would be asking for their money back
1 Like
Oof, since people hate that new switch as it is implemented, I would tell that hardware designer to communicate closely with Steinberg, in case the change gets reverted.
1 Like
Gah. And they did not fix the important bug shot this parameters could be mapped to a midi controller. And how do you map the slope to a QC?
That is considered to be covered by the new MIDI Remote API the team is working on.
1 Like
That’s good. But midi is a protocol, not a API so it is confusing. And midi is from early 80’s things have chance a bit since then.
So then was fixing this/breaking auto-engage more to do with new MIDI Remote API than it does being automatible?
Because even if I were using a hardware controller, in fact more so, I would want the filters to auto-engage.