Hi. I’d really appreciate being able to delete a track from within the mixer. There is already an ‘Add Track…’ command in the channel right-click menu so an adjacent ‘Delete Track(s)’ command would seem to be a logical addition. How about it?
2 Likes
A delete command in mixer will delete a corresponding track in the project window and this is not wanted…
If you need to hide a track in the mixer then you can already use the “Visibility” tab…
Why is it not wanted?
I certainly would not mind being able to delete a track from the mix console with the expectations that it is removed in the project page too.
I would guess some users work quite extensively in Mix Consoles without having the Project Page even open.
1 Like
This is not possible… no project window open, no project loaded…
By “open” I meant not visible on the display monitor. Either the Project Page is behind the mix console, or the Project Page minimized.
Yeah, for me the whole point is that I don’t want to have keep switching to the project page when I’m playing around with routing, replacing a stereo track with a mono, etc - all jobs that I would tend to do in the mixer, as everything is there in front of you. We used to have to do this to add a track too but as this has now been remedied I don’t see any reason why we can’t have the delete made available too. And while we’re on the subject, I can’t see any reason why the ‘Add Group/FX Channel to Selected Channels…’ can’t be made available from the project. Edit: Forget this bit in italics, folks, it is there after all (thanks, @ozinga )
Thanks for the support @greggybud. Would you click to Vote please, so we can get the ball rolling? Cheers, C 
It can. It is in the add track menu when you right click the track header. I had a hard time locating it too 
1 Like
Delete tracks in mixer: (workarround?)
Macro:
Project - Bring to front
Project - Remove selected tracks
Create Keycommand
1 Like
Thanks for the suggestion but I don’t fancy it tbh. I find the macro editor a bit clunky and there’s always the chance it goes unforesee-ably wrong. I don’t think my nerves could take it! 
+1. For FX/Group/VCA especially.
You can use my macro (see above) also for this.
Well, yes, I already use macros like that for these circumstances. The suggestion implies a question on design philosophy.
We have different terms for track, and channel. There is Sync Project & Mixconsole that tries to reconcile those two, and let us work more freely, considering both to be the same in our mind if we wish, but window focus is still something to watch out for.
Now, a track has data. I mean meaningful data. Events, parts, this kind of thing. Of course, if we are talking about a Group track (in the project window), I don’t find the volume automation to be the most valuable piece of data. Neither when we’re talking about the 8 outputs of an Instrument track (that count as automation under one [1] instrument track by the way, when in the Mixconsole they are 8 distinct channels).
For these cases (groups, returns, vcas), the mixconsole as a layout offers a much much better (in my opinion always) overview of meaningful data, and thus I find myself issuing commands to groups, vcas and returns mainly from the mixconsole. The project though, as the “brains” of the whole operation, allows us to execute actions like “Add Selected Tracks to group”, which is clearly an action belonging to the mixer. What does adding tracks to a group even mean? Is there a new rendition of the sum of all events as data? No. Can we add midi tracks to a group and get a condensed midi spartito? No. Rather, it is accepted that “the output of the channels that these tracks corespond to will be routed to a group.”, and we know that and it’s fine. Why is it a problem if we go the other way around and decide that we need to delete a track by means of its channel at the mixconsole? 
TL,DR: It makes sense to delete a group from the mixer, because that’s its home. If focus is a problem, maybe an automatic Project:Bring to Front should be baked into every command, and save us from having to create such uninspiring macros.
Yep, for me, as a design philosophy, macros are for user-specific jobs, not basic functions.
If you’re using Microsoft Windows, the Alt-Tab on the keyboard will Toggle the Displays of the Windows that are open, including the Project Window. Another hit of the Alt-Tab will bring you back to your mixer.
Also, I highly recommend a 2nd monitor. Really helps the workflow.
Good advise for a user with just a couple windows open, that probably works fine.
The problem is…for a user of multiple display monitors, I keep many windows open regularly. Therefore it’s never just Alt-Tab toggling, but toggling…or scrolling multiple times over multiple open windows simply to arrive at the window you want focused.
Also, there are certain “windows” that don’t get focused when using Alt+tab making Alt+tab even further worthless unless you can remember what gets focused and what won’t get focused.
They need to improve basic focus issues, and it’s been requested many times. I think they are improving but slowly. An example would be reversing the 3 mix consoles behavior in C11 so the KC focuses the mix console, the second same KC press deletes that mix console. The old way prior to C11 was delete the mix console, then a 2nd press to bring it back.
@delta thanks for reminding me this is achieved with a macro.
Yes but it’s not the same as having it right there under your nose. I wouldn’t have mentioned it only I do find it a nuisance having to do this, just as I used to find it a nuisance having ‘Add FX/Group etc…’ available only in the mixer.
Steinberg clearly recognises that it’s necessary to make available certain commands in both views and I think ‘Delete track’ falls into this category. Having the same access to channels/tracks wherever they show up is a good thing, isn’t it?
Quite a discussion this is turning into! 
Already using a second monitor here, where mixconsole 1 resides all the time. Commands still need to find their target, and while the situation is much improved, there are still some commands (like the one in this thread) that could be a added to the list.
This goes without saying! But there is just one case where I’m happy with this current situation, and this is Visibility Configurations. Having separate visibility configurations for the project and the mixconsole allows me to quickly apply 16 presets by either one or two keypresses. (With Sync Project and Mixconsole, Sync Visibility enabled, I use one “direct key command” for the mixer’s configs and “bring to front + keycommand” for the project.)
For me, it would be the same thing if the list of Configurations was common between the project and the mixer, but we had direct access via keycommand to double the configurations. It’s the same thing, but it’s not, and that’s what we’re discussing about! The hows and whys, and if a certain philosophy has advantages or disadvantages to it.
Overall, I am of the opinion that since focus is such a pain to establish (and for the reason that we don’t have reliable mindreading technology yet, which reads where my command is aimed to), steinberg is on the right road with expanding the list of commands, so that commands common to both the project and the mixconsole work anywhere regardless of focus, and merging their targets when it’s possible.