1.  Introduction
 

The benchmark implements a user interface for the Nyquist language. Nyquist is a LISP based language for sound synthesis and music composition. Nyquist requires interactivity from the user, similarly to a simple command line based LISP interpreter. The user can produce sounds, instruments, orchestras etc. by combining functions into more and more sophisticated ones. Nyquist produces sounds files, and ultimately audio as an output.

The interface is going to provide basically two services for the user. The first is an environment in which the interaction with the system (the construction of new simple musical structures, sophisticated ones through grouping, the execution of repetitive tasks, etc.) becomes easy for the user. The second service to implement is to provide feedback, information about the already established musical context. This is necessary in an interactive environment, where the composition is a step-by-step process, building complex structures based on simpler ones.

The interface consists of three different types of windows, and so represents several different user interface styles. These window-types are:

• Console window
• Edit window
• Graph window

There exists always only one Console window, and this window can be considered as the main window of the interface. The one important feature that underlines this fact is that closing the Console window exits the application, meanwhile closing an Edit or a Graph window only closes that window itself. There can exist several Edit and also several Graph windows at the same time.

The functions of these windows are as follows:
The name of the Console window is quite self-explanatory. This is the place where basically the interaction takes place between the user and the system, more precisely, the LISP command line interpreter. The user types in instructions in forms of commands, and the responses of the interpreter are also displayed here. The finalized instructions are sent to the interpreter, that is, when the user hits enter after constructing a new instruction. Typing in new characters (to construct new command) is only possible at the current command line, however, the content of previous lines can be used via copy/paste.
The edit window behaves like a simple text editor. Several LISP files can be opened in separate edit windows, the content of them can be edited, and can be passed to the interpreter to process it. It happens via the console window, that is the lines of the text in the Edit window are first sent to the Console window and from there to the LISP interpreter.
The Graph window displays the time-domain structure of (a certain part of) a certain Nyquist-sound. This visual information can be quite useful in the process of developing new sounds. For the time being, Nyquist itself does not make it possible to implement this functionality. (For example: the displayed time-structure can change as the user defines or changes LISP primitives, and there is no way to inform the displaying window about a change like this.) This means that this functionality can probably be only partially implemented.

To communicate with Nyquist, the interface has to set up a “pipe”-like structure through the OS, and implement PutToNy and GetFromNy instructions to put and get characters into and from the pipe. This communication can be simulated in the interface code, so it is not absolutely necessary to actually set up the connection to test the interface. (As to the Graph window, it is an open issue how the communication with Nyquist would look like, how the interface would get the computed waveform data from Nyquist, in what way should be Nyquist extended to support that functionality.)
 

Some user interface styles, which are represented by this interface, are:

• command language
• direct manipulation
• graphical display
• flying menu, hot keys, function keys

As we can see from the above-described list, this interface represents a special type, or at least special combination of interfaces, and so I can not solicit one well-known user interface with which a one-to-one parallelism could be drawn. The windows themselves are representatives of command line windows (like UNIX shells), simple text editors (like Windows Notepad), and special graphical data displays (like several freeware programs under UNIX).

The implementation of this user interface is motivated by real-life need and frustration of not having a flexible and easily usable interface for Nyquist. Given this, the interface will be used in every-day practice, by several different users, which gives the great opportunity of comprehensive and long-term testing of the interface. The possible number of new features to implement would be infinite (parenthesis balancing, sophisticated graphical, and text editing features, etc.) This benchmark reduces the number of implemented features to keep the complexity of the problem at a manageable level, meantime it provides the features that we really needed and missed so far.
The benchmark also provides a good opportunity to test how well certain tool-kits support the creation of a user interface built up of different subparts of different interface styles.

2.  Detailed description
 

As I described, the interface consists of several types of windows. Those windows share one top-level menu bar. The following functions can be accessed through this menu:

File:

• Open
• Save
• Save As
• Close
• Exit

Edit

• Cut
• Copy
• Paste
• Attach Selection To Button
 
Window
• New Edit Window
• New Graph Window
• Regular window arranging functions
 

Most functions also can be invoked by a hot-key combination, which combination appears in the menu list. (The hot-key combinations should be the same as in the native environment, like ctrl+X,C,V for cut/copy/paste under Microsoft Windows).
Open/Save/SaveAs functions are enabled only when an Edit window is active, their functions are the usual.
Close closes the active window; it is disabled when the Console window is active, as there must be always at least and at most one Console window.
The specific behavior of the cut/copy/paste functions is described at the description of the different windows, if it is different from the regular cut/copy/paste.
The functionality of the Attach Selection To Button is described below, at the description of the Console window.
 

2.1  Console window
 
The Console window consists of a more or less traditional command line window, and a row of assigneable buttons at the top of that window. The behavior of the command line part:

• Provides cut, copy, paste functionality. They behave in the traditional way. In addition to this, if one of the assignable Buttons is selected, Paste attaches the content of the clipboard to that Button. (If a Button is selected, the previously selected and highlighted text becomes de-selected and so not highlighted again.)
• The commands typed by the user appear with bold character style, the answers of the system with normal character style.

 

The window contains a row of assigneable Buttons at the top, for each of which a string can be assigned (including “new-line” characters). Pushing a button behaves exactly as if the user typed in the same character string at the command line.
The menu item Edit/Attach Selection To Button attaches the selected text in the active window to the appropriate Button. There is one menu item for each Button (in the form of Attach Selection To Button1 for example). The string can be selected from the content of the text field of any of the windows.

 

2.2  Edit window
 

This window can be used to collect and edit cooperative chunks of code together, and apply them (send them to the interpreter) in one step. These chunks can be saved into files for later usage, but it is not necessary.
The window implements a simple text editor window, with traditional Cut/Copy/Paste functionality.  There is an “Apply” button at the top of the window, which send the code in the window to the interpreter, through the console. The answers from the interpreter also appear in the console window, as if the user typed the code in there. For the time being, Nyquist does not provide explicit feedback as to when its messages end, so interspersing the input and output string streams can not be implemented precisely now. (However, as it is probably not difficult to extend Nyquist to provide this in the future, the functionality of interspersing should also be implemented then.)
 

2.3  Graph window
 

This window displays a sound in the time domain. The window consists of the display part itself, which takes up most of the space, and one simple command line area at the top of the window, into which the user can type any Nyquist/LISP expression. The sound, which corresponds to the expression, will be shown on the display.
In a graph window, the Cut/Copy/Paste functions act on this simple command line.
In addition to the general scroll bar (with which the waveform can be moved within the window back and forth), zoom functionality is also provided.
For convenience, the Graph Window also contains a Play button, with which the displayed sound can be played back.