Wishlist: Delete channels from an entire cuelist from the command line

This can be done in blind spreadsheet mode using 2 commands

Cue A/1 Thru Enter to select all the cues in the cue list

x Thru y At Enter to remove the channels from the cues

I would prefer to do it in one command.  Also, Cue 1 is not always the first cue.

Cue 1/Home inserts the first cue of the cuelist

This is what Macros are good at. Make a command that does what you want, the way you want it, without waiting for the developers to come around to your way of thinking.

I know that. I'm not asking the forum for a workaround. It's just a wishlist item everyone, relax. The console functionality is inconsistent; the syntax in my original post can be used to remove channels from Subs, Cues, Palettes, and Presets, but not Cue Lists. ETC won't fix it if no one asks them to. 

Well, they'd have to add a "Channel" key to all of the consoles.

Also, that syntax would delete the entire CueList, not just certain channels.

EOS has a structure and that structure is what makes things predictable.

When you toy with the structure, things get confusing and corrupts your show.

There is a way to do what you want it to do with almost identical effort to your way.

. . . . . .

The hardest part of what you ask is selecting every Q in your Cuelist.

On that front, I might suggest adding the ability to select every Q in a Cuelist by typing:

[Q] (1) [/] [0] [Enter]

???  . . Just a thought.

If it's impossible for the console to use that syntax, then it should respond with a command line error.  Instead, it asks you to confirm, and then it does nothing.  Not even deleting the entire Cue List, like you suggest.

For the record, Cue 1 / 0 Enter results in an error

Yes.... [Q] (1) [/] [0] [Enter] results in an error. That's exactly my point. It's an invalid command that can be programmed in the OS to select all cues in a cuelist.

Your proposed command line doesn't come back as invalid because the programmers didn't write code to generate an "invalid command" reply to that structure.

Code isn't magic.

Cue 1/ Home Thru Enter already selects all cues in a cuelist and you don't have to know the first cue for that

Unbelievable, that explains the odd behaviour i saw yesterday. I has to delete a channel from a whole cue list and entered a code like the above. I didnt check if it really happend because without an error-message I was sure it did happen. Who is programming this way?? Usually you do it like that:

• parse the command
• set some return status variable to 'unhandled'
• let the command be handled by appropriate function
• every subroutine involved retuns its status to the caller
• ​at the end you check the returned status, if it is 'error' oder still 'unhandled' you post an error to the user.

This is coding 101…

rhavin said:

Unbelievable, that explains the odd behaviour i saw yesterday

Its a bug, that happens in software, the command parser correctly parsed it and so didn't throw an error, but the downstream code processing the parse tree didn't do anything useful with it. 

(As a side point, with modern programming languages you wouldn't actually code return statuses as that is way too easy to mess up, you just throw an exception and that ripples up the stack until something explicitly catches the exception.)