Home of the opto isolated, bus powered, DMX512 interface with both in and out universes. Cheap and simple to build. USBDMX logo

Command Line Implementation Notes

The command line is designed to help users when plotting, or to make some quick changes to the output. Because a user will want a command to be executed immediately no matter what state the rest of the desk is in, any channels modified by the command line are captured. This means that no matter what other level changes happen in other providers the output for these channels will not change.

The other way channels can be captured is with solo mode. This not only captures the changed channels, but also captures and zeros all the other channels.


A command is broken down into tokens. Each token is a key part of the command. Currently the following tokens are defined in LOCommandToken.h :-

  • Number
  • Thru
  • Minus
  • Plus
  • At
  • On
  • Off
  • Solo
  • Release

With the exceptions of the number token each one could be mapped directly to a key in a traditional lighting desk. A number holds the value of the number within the command. This could be a channel number, or a channel value, and is a floating point number.


The command is processed by the LOCommandProcessor which can either execute an array of Tokens, or can be passed a single token at a time, and then once all Tokens have been passed they may be executed.

The processor holds two static instances of a Direct Provider. One to hold all the values of channels modified by the command line, and the other to zero the channels that are not soloed. Because these are static it means that you can create and destroy as many processors as you need, and even use multiple ones at the same time.


The tokenisers take the user input and convert them into the tokens needed for the Processor. Although at this stage I have not written any of the tokenisers I propose to have one that will read and tokenise strings, that the user may have entered with a keyboard, and one that will tokenise button presses.

The tokeniser is responsible for rejecting commands that can not be tokenised, e.g. a mis-spelt word, but is not responsible for checking the syntax of the command.