Why do we still use a DOS like command line?

[SmiffD266]

Hi All,

I have been a bit of a lurker on here for a while, and just felt the need to post something.

 

I came across the Jands Vista V2 software/ console the other day, and with its GUI based interface and ease of use, it got me thinking, why when in the outside world, we moved away from DOS based systems in the 90's to a visual system because it was more user friendly, why are we still using a type based (and sometimes very complex) command line syntax?

 

I know that lots of people a happy with what they know, but speaking to a some others I know, it seems they are even un willing to even look at a Vista, because its not a pearl or a chamsys.

 

it seems a bit odd that when something could make you life easier, we still choose to do thing the hard way "because that’s how we have always done it"

 

I would love to hear some thoughts from people on this.

 

cheers

 

Dave.

 

 

 

 

 

[alistermorton]

The same question gets asked over and over with "DOS" and *nix command lines - why bother when you have a gui? The answer is that often an experienced operator can often achieve more and/or do it more quickly by typing what appears to be a complex and arcane command line, instead of using a pointing device (even if it's their finger on a touch screen) and buttons and menus and drop down lists. Conversely, you would probably find that you could position and focusa moving head more quickly with a trackball (or even a mouse) and wheels than you would by typing rotation and tilt values directly (although again, an experienced operator might instinctively "know" roughly what values to enter for a given target).

 

 

[Bryson]

Well, I haven't used a Vista, so this isn't a comment on it specifically, but as a frequent AutoCAD user, and a dabbler in the Terminal, I have to point out that when you're trying to get real work done, then the command line interface is far from dead. The GUIs are nice for learning curve, but the command line has significant advantages as far as speed and efficiency go. So, that's probably why...

[Nick512]

Remember more often than not all the GUI is doing is triggering commands in the background anyway, Knowing how to properly use the command line of a console often provides you with a feature set far more powerful than that of the GUI alone and can significantly speed up programming large shows with hundreds of lights. It is the most important part of hugely powerful desks such as MA and V676. On these consoles some of the most powerful functions can only be accessed through the command line as creating a GUI for them would be far too time consuming to use repeatedly.

 

Very Basic example-

 

You have 25 cues on a pearl - either in a list or on separate faders and want to change the colour and position of one moving head fixture throughout cues 1 to 25 - you would have to load each cue and save the information manually into each of the 25 cues resulting in 50+ button presses.

 

On an MA the same can be done with the following command "Store Cue 1 thru 25" (ignoring the update function for this example)

 

This results in a significant time saving when you have 500+ fixtures and 10,000 cues!

 

I personally when programming use the command line almost exclusively - the GUI is used for recalling pallets, effects and viewing cue lists and fixture data.

[Joe Bleasdale]

As already mentioned speed and efficiency are big pluses. Also, if people like it and it works - why change that? I think command lines in some way, shape or form will continue to be present in our consoles for a long time to come and I for one am happy that way. A balance between a good GUI and Command line is great. And hey, the consoles that can perform every possible task in either format are going down a storm at the moment!

 

Thanks.

[timsabre]

Most consoles have a variety of different ways of doing the same thing, because that enables operators to work in the way they are familiar with, especially when swapping between different consoles. Command line is just one of those. Multiple methods of working are very common in software with a lot of legacy users - CAD software is another good example.

As a manufacturer you don't want to lose potential customers by saying "No, we don't support command line any more, it's so 1980's and look how pretty our touch screen is. Get with it." Well, unless you're Microsoft.

[Robin D]

Even with Windoze 7 there are still a huge number of commands available to those who need them to do all the thing in the engine room you can't get at through the GUI!

[alistermorton]

A balance between a good GUI and Command line is great.

 

That's the crux of it - both have their uses, and whichever is the best tool for the job for the person concerned will get used.

[bwerst]

I agree with everyone about speed and efficiency. Someone said it well about the GUI actually sending command line instructions in the back ground.

 

In addition having a full functioning command line makes it easier to add "Macros" functionality. Macros are usually just a script of command line instructions. Personally, the awesome thing about macros is they allow users to come up with additional functionality that the console vendor might not have conceived of or had a chance to implement yet. This adds a tremendous amount of flexibility for the users.

 

A similarity on speed and efficiency: Advanced computer users will memorize the keyboard shortcuts for programs they use frequently. Every time the users hand needs to leave the keyboard to go for the mouse to navigate the GUI they slow down. Just the act of moving your hand off and then back to the keyboard slows you down.

[Albatross]

Does the Vista have a qwerty keyboard anywhere, or attached to it?

I bet it's not a touch screen one, or one you click on each character to 'type' :blink:

 

As has been already said in many ways, I find that a command line is just much faster for some functions.

Need a light at a specific level? Well you could roll it up on a wheel or drag your finger, but I bet that to get it most accurately at that level, I'm pretty sure that most people will type it in.

 

Cheers,

Ric

[smalljoshua]

Growing up, I was never exposed to a command line to operate a PC (showing my lack of age here!) and therefore, had no "preprogrammed" disposition to prefer a system I knew (GUI) to one that I didn't (Command Line). I learnt lighting on a non-command line desk (Sirius 24) and didn't use any command line until I started using MagicQ (2008). Despite all of this, I still prefer command line! It's much quicker and easier for me to work in this way than it is to use a screen or physical faders for most programming.

 

Would I busk from just the command line? Heck no! Could I program and run an entire week of theatre (including Am Dram panto where improv and extra specials are required all the time) sure.

 

I suppose it's almost down to how your mind works with these things. I know a couple of well regarded LDs down here who are very good at their art yet willingly acknowledge that they couldn't even program a VCR. They're more than happy to use a Fader per Channel desk for their lighting or when requirements dictate, get in a programmer with a larger desk to program and operate for them. Conversely, I operate in the opposite way, I can create a technically good rig plan, focus, plot and program yet the artistic nature of the beast isn't something that comes so naturally.

 

I wonder if this is a common correlation? Is it that those of us who'd prefer a GUI are more artistically skilled and minded whilst those of us who prefer command line are more technically skilled and perhaps from a more technical background where Command line was the norm for much longer than a GUI.

 

I suppose this raises more questions than it answers! Another thought is that perhaps the lack of exposure to command line of people of my generation and below is a detrimental thing and actually limits our ability to efficiently interface with a computer/lighting desk etc.

 

Josh

[karl]

The important thing is that the system's human interface should be intuitive.

 

An intuitive interface will be easier to learn and quicker to use than one that isn't.

 

Unfortunately in many lighting controllers, both hardware and software based, packing in the maximum functionality seems to take precedence over interface design.

 

I recently had to use a well known computer based control system and I found it a real pain to get to grips with. This was despite the fact that I work in IT and have several years experience on various hardware lighting desks. Banks of soft buttons whose function shifts as you select other soft buttons is a nightmare. It's like being in a maze where every time you move forward the walls shift around and reconfigure the route.

 

Hardware type controllers can be just as bad. If I set up an output state and tell the desk to save it as a cue I want it to save that exact state so that calling up the cue replicates what was being output at the time of the save. I don't want it to ignore some fixtures because I set their levels using a submaster rather than the programmer - why would I want this? Surely a sensible default is save the complete output state unless I say otherwise, rather than save only part of the current state unless I explicitly say I want to save it all.

 

If you are going to provide an Edit button that can be used to quickly edit a cue whilst in play mode then surely it makes sense for it to edit the cue that is currently being output. If it's a tech rehearsal and I feel the need to edit a cue it is pretty much certain to be the current one: the one I'm looking at right now and have spotted a problem with. What sense is there in giving me an edit button which snaps to the next cue in the stack and edits that?

 

It's not rocket science and yet the designers of lighting control systems seem to struggle to produce easy to use interfaces whether GUI or command line.

[indyld]

 

Hardware type controllers can be just as bad. If I set up an output state and tell the desk to save it as a cue I want it to save that exact state so that calling up the cue replicates what was being output at the time of the save. I don't want it to ignore some fixtures because I set their levels using a submaster rather than the programmer - why would I want this? Surely a sensible default is save the complete output state unless I say otherwise, rather than save only part of the current state unless I explicitly say I want to save it all.

 

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

 

The Programmer concept (active channels, whatever you like) is an important and flexible tool just as Tracking is. With many desks you can set the default record to include Subs et al, record entire output / snapshots every time if that's your poison.

 

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.

 

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.

 

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.

[paulears]

I'm lost. Are we saying that there's a better system than 10@Full, or 1thru 10@50?, or complicated ones like 1thru6+49+54+306thru461@full?

 

How would that be done graphically, better? (and quicker)?

[Joe Bleasdale]

Sometimes selecting fixtures graphically can be quicker when you are using a complex selection order. On the fixture screen, POKE, POKE, POKE a dozen times will be less keystrokes and faster if you have labelled well. What you do after that is irrelevant really, you got that selection fast and now it can be used, stored or whatever. Sometimes when making a specific offset "chase" as an FX is when this comes in very handy or doing fanned timings. Usually I'll make my FX then store that fixture selection to come back to later. The key with GUI is to label things clearly as you go, otherwise you end up not knowing what on earth is on that touchscreen and that speed edge is gone.

 

Thanks.