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:
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:
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
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
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.
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
2.3 Graph window