‘Hide All Automation’ should work just as ‘Hide Automation’ works,
and then there should be a new command - ‘Remove all unused automation lanes’
I don’t know… if there is no data, there is nothing to delete
visible lanes with no data are still lanes with no data
the problem is not that the lanes get deleted… the visibility doesn’t get restored…
I’m running out of ideas to describe it…
You’re running out of ideas to describe it because you’re pussy footing around the clarity of issue and refusing to backtrack your statements and are instead playing dumb - in my opinion, correct me if I’m wrong on that… but I’m certainly right on this issue.
The issue doesn’t have to do with whether or not there is data - it is irrelevant. stop bringing it up. If I were to secede to your statements, it would be to say that - there is no way in the program for a user to preemptively setup their automation lanes in a template the way they are likely to need them, and then minimize them all, and show them all. There’s nothing about writing data in there. a user shouldn’t have to write data. A user doesn’t have to write data in order to show a lane, or minimize the lanes. The other commands ‘restore’ the automation lanes to how the user set them.
How else do I describe this for you, for you to finally get it? It’s like I’m trying to communicate with you using a flashlight which could be done, except that I’m on Earth and you’re on the moon.
Wait… Hide All Automation actually deletes the automation? I’m not able to test right now, but that’s a big deal. I’ll have to test later. (also, I thought I’d used that command tons in the past… I never noticed this)
It doesn’t delete automation data or remove automation tracks/lanes with data on them
it removes automation tracks/lanes without data, that the user has made to be visible.
Ah ok. (I get the semantic argument now) But ya, it should behave the same… and if I’d set up a template for potential automation, I’d want it to be retained.
yes…
if Stoss wants to argue about whether we call it a bug or not, fine. argue about that Stoss.
But if it’s not a bug, it’s a bad design mistake… and I consider bugs and bad design mistakes to both be ‘issues’
It is not a bad design… your intention is wrong
you are trying to tailor the software to your needs ignoring the needs of many others
automation lanes that contain no data are senseless…
if you need automation lanes in your template you should write initial data
I would seriously ban you if I had the power. Try adderall, or sticking a fork in an electrical outlet.
can you stop this please?
@vncvr this sounds like more of a feature request for some kind of automation lane presets.
Or as a workaround, as @st10ss said, add an automation point in the template you create in the lanes you want kept visible.
The proposed workaround (which I was already aware of) is counter productive to creating an efficient template. It means.
1.) I have to take the time to add a data point to each lane I want at the ready
edit @Steve I also then would have engage automation bypass on that lane, because ‘Read’ enable on a track is track wide with no way around, and additionally, if later on in the project I am freely setting parameters tied to that automation lane in which I am setting a staring point… I then have to go back to that initial parameter to remove it.
2.) I then have to remove that data point each time.
This isn’t a feature request, it’s a thread pointing out the blatantly obvious discrepancy between two already existing protocols in which one works one way, and the other works a different way.
Let’s put this in the context of a rocketship or airplane in which I want to control engine power and fuel lines on a GUI.
One function simply minimizes the controls of each engine/fuel line out of view one at a time to make room for other things on the GUI.
Another function named pretty much the same thing as the first function, supposedly does the exact same thing - but for all fuel lines and engines at once. So I click that function thinking it does the same thing just faster.
oh sh!t! engine fire! open all the controls back up! oh sh!t! none of them are visible anymore!
if the feature request is to not have a protocol be blatantly confusing and contradicting, then fine, it’s a feature request
I can see both points being made but personally find things like this really frustrating also. For me, it’s definitely one of those overlooked design details that Steinberg often seems to miss. I think all views, window setups, window sizes, columns sizes, tabs etc, etc etc etc should always maintain their state! The one that comes to mind is the Inspector. Organize the Inspector but then go to the setup for it, make a simple change and watch all your tabs collapse even if they are pinned, super frustrating! There are many, many aspects that behave like this.
1 Like
This heated discussion would have never happened if a MIDI/instrument track could automagically pull all parameters from a vst preset and lay them out in as many automation lanes, with the preset’s parameters as initial values. 
Maybe for you, for people who have to complete entire scores in a single day need make use of any single percentage gain of efficiency as possible.
I already negated your “make initial data point” argument. That’s an efficiency diminishing workaround. Are you aware of how automation works?
I’m not even sure how this effects you? Explain that to me? What is your actual opposition to my encouraging that this protocol become consistent?
**Because, why would you even be adding automation lanes that you do not need enmasse in which you would need to use this command as it currently is?**
Am I missing something? Because your issue with my contention doesn’t make sense even by your own arguments of “automation lanes that contain no data are senseless…”
that could be a feature request on its own, but not really a solution here or relative because that could be a hundred parameters.
This has to do with selecting a handful of parameters I commonly need at the ready.
Yes, short sighted inconsistency is annoying.
If they had called the command function “Remove All Unused Automation Lanes”, or made it so that “Hide Automation” (per selected track) had the same protocol end result function as “Hide All Automation” (all tracks) … I wouldn’t be here complaining… I would be in a different thread making a feature request for “Minimize/Fold Automation” (Per selected track) and “Minimize/Fold All Automation” (all tracks)
but because of Steinbergs inconsistency here - which is the issue - and is an issue -, there is no right or wrong in perceiving which way both functions - should - be consistent in their end result because by their blatant similarity in function name - a user would expect them to work similarly with one being for selected tracks, and the other for all tracks - - - - I don’t get what some people in this thread aren’t getting here - - - - -.
@st10ss
If you want to argue, that ‘Hide Automation’ should work as ‘Hide All Automation’ currently does, then fine! Then I will make a feature request that we get two new commands: ‘Minimize/Fold Automation Tracks’ (Selected) and ‘Minimize/Fold All Automation Tracks’.
But because neither functions work consistently - we don’t know - if they are supposed to be consistent or supposed to not be consistent and - we don’'t know - which way they are supposed to be consistent if they are supposed to be consistent and if they aren’t supposed to be consistent than my issue is with how they are consistently named but with inconsistent behavior in which case my issue is with Steinbergs naming of the functions and my feature request is that Steinberg name their functions better to better describe what the function does.
One Command does one function (minimizes/folds automation lanes back into the selected trac(s)) and the other command does two functions (removes unused automation lanes and minimizes/folds used automation lanes back into all tracks)
Is this not a blatant inconsistency and discrepancy easily measured against the similarity in naming of the two functions?
edit
@John_R_Cardona sorry, what started as reply to you, ended up as a rant not directed at you. it’s not you I’m asking
Steinberg ! If you read this… I just want to say I LOVE YOU GUYS and your PRODUCTS !!! I only speak in hopes that all the really fine workflow details get addressed parallel to all the evolutionary aspects of the platform.
CUBASE RULES !!!
I share this sentiment
but when I have a critique, I have a critique.
You know, I think it’s a misstype. I think it should be “Hide All Used Automation”. I mean they’re together in the same menu with “Show All Used Automation”.
And then you can understand why giving the command will purge all empty automation lanes.
At least Show Automation and Hide Automation work as expected for this particular case.
1 Like
Possibly, not denying that that could be the case… But I’m not sure that would make sense either both as an explanation, or as a name for the current function as it is either because, it would allude to hiding only used automation… It wouldn’t really make sense imo.
but thanks for bringing this up, because when you think about it - ‘Show All - Used Only’ is effectively a double use command that can also be used to “Remove All Unused Automation Lanes” in which if @st10ss was angry Steinberg ended up altering these commands the way I’m suggesting, he could create a macro:
-Show All - Used Only’
-Hide All Automation
which effectively would replicated what ‘Hide All Automation’ currently does (but shouldn’t do).
Either way,
‘Hide Automation’
and
‘Hide All Automation’
One way or the other, should behave exactly the same apart from one being for selected tracks, and the other for all tracks just as there is currently ‘Show Used Automation (selected tracks)’ and ‘Show All - Used Only’
edit
Side note, even the naming of ‘Show Used Automation (selected tracks)’ and ‘Show All - Used Only’ is kind of sloppy and inconsistent - - why not: ‘Show Used Automation (selected tracks)’ and 'Show Used Automation (all tracks)? so that they show up in the same place in key commands