Previous Next        Current Page: NeXtMidas User's Guide / Basic Concepts / System Overview / Key Components
FAQs   
Release Information   
Getting Help   
Basic Concepts   
   - Summary of Capabilities   
   - System Overview   
      - Key Components   
      - Directory Structure   
   + Shell   
   + Option Trees   
   + Commands   
Result Parameters   
XML Support   
Files   
System Operation   
Macros   
Applets and WebStart   
Graphics   
X-Midas Interoperability   
Third-Party Compatibility   
Installation and Customization   
Running NeXtMidas Independently   
Glossary   


Key Components

NeXtMidas is a command-driven system, which means its primary mode of operation is responding to typed commands. A command comprises a verb, which tells NeXtMidas what action to perform, and zero or more parameters, which further define the action and identify the data to be acted on. NeXtMidas commands are entered at the operating system prompt or through the NeXtMidas shell, which offers additional command handling features.

NeXtMidas data is most commonly read from and written to binary-format disk files having what is called the BLUE format in honor of this format's signature characters. A BLUE file begins with a header that contains descriptive information. Signal data follows the header. Often, a BLUE file ends with an extended header that houses keywords (tag=value pairs) to provide additional information about the signal data.

Signal data need not be stored in a disk file. NeXtMidas is also capable of performing interprocess data transfer via sockets and pipes to speed processing in cases where permanent storage of (typically intermediate) data is required. A powerful facility called RMIF enables interprocess control and status reporting.

Another form of NeXtMidas data is results parameters, which are labeled numeric and string values that are stored in a results table. As the name suggests, results parameters are often the outcome of some calculation that NeXtMidas performs.

NeXtMidas is an open-architecture system, which means its command set is designed never to be completed. NeXtMidas recognizes three types of commands: intrinsics, primitives, and macros.

  • Intrinsics are the core commands that perform fundamental system control functions and provide highly efficient implementations of common operations. Intrinsic programming is the province of those who understand the NeXtMidas infrastructure.
  • Primitives are application-dependent programs that use NeXtMidas library facilities to do work. Primitive programming requires familiarity with Java and the public NeXtMidas programming interface.
  • Macros are sequences of commands already known to NeXtMidas. Any user who understands NeXtMidas operating concepts and its command set can define a new macro.

Although NeXtMidas is a command-driven system, its most important use is to implement graphical front ends for distributed signal processing systems that use X-Midas or other third-party software as the computational back end. NeXtMidas provides the widgets associated with conventional graphical controls, and its macro language supports control definition, layout, initialization, and real-time interaction.

To eliminate the tedium of entering long commands that include absolute paths, NeXtMidas maintains a list of source directories that are automatically searched for input files. This so-called AUX list also names a single directory to which output files are normally written. Absolute paths can be included on commands, if desired; however, reliance on the aux list facilitates creation of portable macros.

Because new commands are added to NeXtMidas so easily, it is desirable to have a packaging scheme that enables different NeXtMidas installations to share their command sets without worrying about command name conflicts. NeXtMidas calls a command package an option tree. An option tree provides executable code for all the commands it includes, a dictionary that defines command parameters, and online command documentation. Commands within an option tree must have unique names, but there is no problem if the same command name exists among different option trees.