BTW I am all against a simple “delete” - why? Because it would require a “do you really want to?”… the risks of a simple delete for the complex matter are too high. I prefer a way in this case that protects us a little.
Cubase has a decent undo.
There’s a semantic question that those campaigning based on the precept that deletions should be uniform should consider.
Removing a Rack instrument isn’t a deletion, and the means of removing a Rack instrument is consistent with how removing VST instruments is done elsewhere in Cubase, and that is different thing than removing a track, or deleting an event.
It’s not about much, but still keeps me amused: some funny arguments against a simple and straightforward delete functionality by just clicking “delete” on a rack.
You can as well delete a whole track by “Shift-Delete”, without being bothered by any sheepish “do you really want to”? It’s no problem at all, due to Undo.
But of course you can follow another kind of logic:
“Why have things simple and straighforward, as long as a slightly more complicated alternative not making much sense (choose “No VST instrument” from a dropdown menu) is available?” 
Even better: you can argue for the workaround probably protecting us from evil forces destroying our work. 
Or best of all: the straigthforward solution might possibly be inconsistent with other minor remnants of screwed logic within Cubase. 
LOL Well said.
This. The metaphor is right there in the name: “rack”.
But what you propose isn’t simple and straightforward. If it were changed in the Rack, it would have to be changed in every other spot in the program where the function of adding or removing an Instrument plugin exists. Do you have the data needed to evaluate what other changes might be required as a result of this change, or how this will affect the workflow of the people who are used to this method?
We’re talking about two clicks. One to drop the menu down, and a second to select “No VST…” If there were a button to press, you still have two clicks, one to select, another to click the button.
We’re not debating how or if the the devs will implement something- that’s what they do in meetings, as users we can say what our needs are, and what we like and do not like about the program. (not that anyone has anything negative to say on internet forums 
)
But the method to remove the VSTi is precisely the same motion as using a context menu, click, move, click.
The point is that the means of doing this deleting is almost “hidden”.
It hardly comprises a DISCOVERABLE type of feature and as such is a bad design decision.
Yes there are consequences to consider as developer - some of yours might have merit but the case remains that as currently implemented this is very poor design.
The mere fact that I couldn’t even get to the steps required via a simple search in the Cubase manual - but had to resort to online forums and facebook for the answer demonstrates something is just plain wrong about this aspect of Cubase.
I beg to differ. It’s not hidden, by virtue of the fact that you use that drop down menu to add the vst instrument in the first place, and/or that the same menu is presented in multiple places in the program.
But by all means, make a feature request if that’s what you want to do. This is the ‘General’ subforum.
Should some things in Cubase be more discoverable? Yes. Is this one of them? IMHO, no.
The instrument rack is an advanced feature that few users ever encounter and, by working the way it does, it maintains consistency with other similar GUI features. Menus that deal with inserts, sends, busses, etc. all work the same way. Consistency is just as important, if not more so, as discoverability. A key aspect of good GUI design is: when you learn how one thing works, you should be able to apply that lesson to other similar features. It works the way it does for the good reason that it is consistent. Further, discoverability is relatively unimportant in advanced features. A novice would use instrument tracks, not the instrument rack.
I had no problem finding it here: VST Instrument Selector
I’m hesitant to post again, as I hate to be a bully thrashing on a poster who hasn’t done anything wrong (requesting a UI improvement is no reason to get beat up), but it seems that you are still rather new to Cubase and still getting to know its strengths and weaknesses. This won’t be the last time you have to go fishing to figure out how to make the app do something. Other DAWs have learning curves too…BIG TIME.
I can relate, I’m always a little lost when I first start using an App that’s new to me. It takes me a little time and experience to get the concepts, work-flow options, feature-sets, and yes, even to grasp how the documentation team thinks and organizes things. Parts, lanes, events, tracks, etc…all the terms can have different meanings from app to app.
As for Cubase documentation, it has gone through some changes over the years. Somewhere around version 9, I had to relearn how to best browse and search it myself. See, for decades it was an old style book…with a Table of contents, body, glossary, index, appendixes, etc. It even had 'tutorial chapters if you go back enough versions.
The new organization isn’t ‘wrong’, it’s just rather different. They are ‘gradually’ trying to convert it into something that makes sense to new age constructivist learners, suitable to all the learning styles out there. It has not been that long ago that it was designed more from a scaffold cognitive learning format (start from page 1, and read the whole thing once, then use headings, and/or the good old fashioned index), into a more constructionist format with hyper-links.
To be honest, in my opinion, the manual as it stands now hasn’t made a complete transition into a really good constructivist style manual, but the team is TRYING to put together a manual that is useful to learners of all types, and they are trying to do it in several languages. In my experience, the documentation people at Steinberg are very open to suggestions that might improve the manual.
Constructivist geared manuals are not easy things to make, as constructivist style learning is rather ‘random’ and very difficult to predict. To know what to ‘look up’, or what ‘links to click’, you need basic terminology, and an understanding of the framework. To get that much, you still need at least SOME old school cognitive style sequential READING. Sadly, fewer and fewer with each younger generation have the patience for it…plus not having a paper manual in one’s hands changes the psychology of…well…flipping through the pages and being able to quickly absorb how the manual is organized. It changes how people take notes (if they do at all). Jotting stuff in the margins is a thing of the past.
I know back things came with books or 3 ring binders…I was always browsing the things in my spare time and making little notes. Always looking for something I’d missed last time I scanned the thing. Always making mental notes (Oh, cool…will have to try that in the next project). These days, even with PDF docs loaded into my Kindle, I just don’t do that as much anymore. Computers are changing the way we learn…give it some time, make suggestions to the documentation teams.
What did you type in as your searches in the manual? Were you using the online version, or a PDF? Let the documentation team know what you were thinking, the things you tried that yielded a fruitless search. They can improve it much easier than programmers can change Cubase.
Hang in there…it won’t take you long to grasp it all…including how to make the most of the documentation.
Brian Roland, I share your view and your observations.
My suggestion to anybody is to acquire a minimum-skill in crossreading longer texts to capture the basic structure and content of big information “heaps”. Just-in-Time-Questions and - learning are of course desirable, but we (humans) cant process information that does not find a context in our brains, which is partly built by the terminology and concepts of the topic at hands.
The good news about this is: Some of the “old style” (fundamental cognitive skills, text understanding) approaches will help to get even MORE out of the “just-in-time”-findings. By embedding the just-in-time findings into the context one has built mentally the findings not only will help to solve the current problem but bring completely other ideas and solutions to related and not related problems/situations. An enormous extension of real understanding. In other words: By doing BOTH you will not only be able to handle exactly the current task but also learn far beyond that.
Compare it to someone who has just been trained to perform a certain predefined task in comparision to someone who has really learned the profession. It is all about our “mental repertoire”.
Cheers, Ernst
Well Brian, you’re seeing more than anyone else in that case; it does not tell you how to unload a VSTi from the rack.
No, it explains how to use the VST Instrument Selector, which clearly has an option “No VST Instrument”. Clearly this is the area of the app to manage VSTi plugins.
I suppose it’s ‘clear’ to me because I’ve been using Cubase for decades, and started when the Manuals still came on printed pages in 3 ring binders, and had a totally different method of learning psychology behind their authorship. Then again, I don’t recall this particular thing ever being a problem for me, as I saw the option every single time I added a new VSTi, and intuitively had an idea that that’s how to get rid of something in the rack as well.
It’s OK, everyone doesn’t think like me. I get it…
It’s easy enough to add a topic to the manual (which I agree can use many improvements), and key it into the search engine. Much easier than redoing the entire GUI.
We all know now that this functionality is in Cubase. It seems to me that adding an x to the rack to access the no instrument function(routine) would not require an entire rewrite of the GUI. It would add an easy way to delete an instrument. Now I understand X on a Mac may not have the same meaning as it does on a Windows machine but I think the Mac users can handle it.
+1
As a side note
Click the name, Delete, Enter
This is faster than selecting “No VST Instrument” by mouse.
Well, will you look at that. It’s a beautiful thing.
1 Like
I’ve been reading this thread and I’m kind of amused that considering the subject, it’s stretched to 2 pages. I almost feel guilty writing this. Almost.
The only thing that has ever bugged me about the process of deleting an instrument from the Rack is the phrase: “No VST Instrument”. On the face of it, it almost could be interpreted, that by clicking on it, one might create a new, blank Rack slot. It’s that inclusion of the word: “No”. In my opinion it should be replaced by the word: “Delete” or “Remove”, which gives a more precise description of what will happen when you click on it.
And nicely done, Brian Roland. Great post.
And I feel guilty for writing this .
The only thing that has ever bugged me about the process of deleting an instrument from the Rack is the phrase: “No VST Instrument”. On the face of it, it almost could be interpreted, that by clicking on it, one might create a new, blank Rack slot. It’s that inclusion of the word: “No”. In my opinion it should be replaced by the word: “Delete” or “Remove”, which gives a more precise description of what will happen when you click on it.
There are two kinds of menus in user interfaces. Command menus and option menus. Command menus have verbs, like “delete” or “remove”, because you are specifying an action to take place when you choose an item from the menu. The instrument menus in cubase, just like similar menus for busses, inserts, etc. are not command menus. They are option menus. Option menus use nouns, not verbs. That’s because they show what thing you have selected to go into this instrument slot. So, the instrument menu has items like “Massive” or “Omnisphere”. And therefore, to be consistent, the correct item to have in that menu to indicate the slot is not to contain any instrument at all is “No VST Instrument”.
It’s super important to be consistent with conventions like this in a user interface. Inconsistency contributes to users feeling uncomfortable. Even if they aren’t explicitly aware of what’s wrong when the user interface is inconsistent, they’ll feel that something just isn’t right.