Why do we still use a DOS like command line?

[Grum]

Sounds like you're talking about the Strand Pallet? use the mouse to click on each channel you want to control then the scroll wheel to set the level.

 

I worked in a venue that had one of those and in the three years I worked there it was used as a door stop most of the time. Occasionally someone who didn't initially like the other desk (Chamsys) would set it up and try and use it but within no time at all they gave up.

 

Command line operation dominates for several reasons but primarily because its the most practical for the job in hand.

[Andrew C]

complicated ones like 1thru6+49+54+306thru461@full?

That bit might be quicker with a mouse to select the channels you want to alter. Particularly so if you were say looking at the screen to see which channels were already at a certain level.

[J Pearce]

The strand palette does command line too, it's not just mouse select. (I am aware of its other faults but it's not a bad desk for small-medium scale theatre).

[indyld]

The strand palette does command line too, it's not just mouse select. (I am aware of its other faults but it's not a bad desk for small-medium scale theatre).

 

Indeed. As we are talking about the merits of command line, the Palette OS added some command line frills and intuition to the Genius Pro which makes some aspects of command line input 'better'. It's a pig of a desk in many other respects and I'd avoid like the plague, but it must be acknowledged that command line on the Palette had some merit.

 

IMHO, the MA is probably the best for command line goodness at the moment in terms of function and power.

[rossmck]

I know some people dislike it (and I was never the biggest frog fan) but I must admit the command line 'hints' on the newer Zero88 ZerOS desks are quite helpful at times - and people who I've spoken to who are new to operating and programming lighting find them invaluable it seems.

 

Little touches like that make the CLI a lot less intimidating to newer users

[Mexi]

I'm an autocad user, and stick to the command line method. It does help when theres an upgrade to the software or you have to use an different machine, rather than finding out where the icons have moved to I can still type my commands. Its much quicker than having to keep moving eyes to locate the pointer to the icon as the keyboard always stays in the same place.

 

I'm a chamsys user but have never actually tried the command line, which is a direct contradiction to my autocad use. I think you do tend to learn a method of work and stick to it. I learnt chamsys graphically and would need to relearn command line - its just laziness I suppose.

[cfmonk]

It's the same reason that people still code HTML by hand and no real software developer ever used the "Toolbox" of their IDE. Once you know what you're doing it's just quicker to bash it in with a keyboard rather than useing SOMEONE ELSE'S interpretation of "ease of use".

[karl]

Although this is more related to programming concepts rather than interface, there are many more situations where I DON'T want to record entire output most obviously including:

 

* When the houselights or working light is up on a Sub so others can carry on working.

* When others are focusing off a running sub as you program.

* When you are building up memory blocks, palettes or other 'incomplete' cues

Fair enough but my logic says you provide a way of making subs into hidden subs. So you set house lights on sub 1 and define it as hidden, warm wash on sub2, cool wash on sub3, etc. You can then set up your state using the subs and record your cue with something like RECORD CUE 1. The hidden subs would be excluded from the recording unless you over ride the hides. That makes more sense to me than ignoring ALL subs by default just in case one of them has houselights, workers, etc. on them.

 

It's unfair to suggest that this level of functionality is a foul up on the part of the lighting console designers in an attempt to make users life hard, it isn't.

Yes, that would be unfair and it isn't what I said. I'm not saying they do it on purpose and certainly not to deliberately make things hard. It's more a case of ever more functionality being added which sometimes makes simple things more complicated.

 

The case above is a good example. Some users want to be able to exclude subs when recording cues. This functionality is added and suddenly everybody who doesn't want to exclude them has to take special action to undo the effects of the new functionality. I always think the default action should be based on the simplest and/or most logical behavior (like recording all of the current output to a cue). If you want to do more clever stuff (like exclude some/all subs) then that should require actions in addition to the default.

 

The thorny issue of layers of softbuttons under softbuttons can complicate things but I guess that's where you end up if are limited by the number of individual inputs (physical buttons or screen tiles) on any given surface and then have seemingly unlimited possibilities in the complex software. MagicQ is particularly guilty of "not making any sense" on the softbutton front for the uninitiated, some functions appear to have been cobbled onto available buttons and then moved to others during development which makes some things stupidly hard to find - for me, every time! This feeling of being lost in an ever changing maze could be mitigated by some indication of where you actually are at the time, and how that relates to where you want to be. Bit like breadcrumbs on the Web, I suppose.

I'm so glad I'm not the only one. People seem to rave about it, and yes it is very powerful. But I find using it a painful experience.

 

If a desk only relied on keypad entry and command line, this problem would go away. But the user would then be left to drift in a sea of commands and syntax that they had to learn before they could even start. And then try to figure our if they need to hit RECORD CUE 1 or CUE 1 RECORD.

This problem would also go away if the people who design these systems thought about how to make them logical and intuitive. In some ways even just having some sort of standard design features would help like in the old fashioned Windows programs where Load, Save, Print were always under the File menu. Just about every program followed the same basic layout - you want to cut or paste then go to the Edit menu. Easy, or at least it was before some idiot invented the ribbon!!!!

[chelgrian]

It's the same reason that people still code HTML by hand and no real software developer ever used the "Toolbox" of their IDE. Once you know what you're doing it's just quicker to bash it in with a keyboard rather than useing SOMEONE ELSE'S interpretation of "ease of use".

 

I think there are a few things people are missing here. To start off with what DOS and indeed the the command interpreter shipped with Windows have don't deserve to be called a command line they stink utterly. I think one of the main reason the generation brought up on Windows associated command lines with obsolete or old technology is because of the utterly deficient one they are exposed to if they ever even start it up.

 

I think the one reason that command based interfaces to lighting desks persist is because they are mostly quicker than GUI based interfaces. The reason for this is with sufficiently powerful command syntax every time you write a command you are really writing a small program which is then interpreted by the system. This can allow almost arbitrary complexity in how you interact with the desk where as with a GUI system you are usually constrained to certain set operations which have been fixed at design time.

 

The best interfaces combine different user interface elements, for example a command interface and tracker balls to input positions in two axis at once for example.

 

Lighting desk designers aren't trying to make something that you can just walk up to and use in the way that, say, the iPad's touch interface is so intuitive that toddlers can pick up many of its basics. They are trying to make something that once you have been taught the basic concepts if you try something based on those concepts then it's probably going to do what you think it ought to do.