Choosing a GUI

Writing Sculptor was supposed to be an exercise in efficient signal processing rather than sophisticated GUI design, and the library eventually selected was xview. This is a rather aged library now, although dynamic and static versions are still available for Red Hat's 5.0 release based on glibc2, so it is not quite dead yet. The reason for this choice was primarily that the author was familiar with it. The principal requirements of the application, which are for a few simple menus, sliders and the detection of mouse events over a performance canvas, are satisfied by practically any widget set from the oldest Athena to the latest GTK+, so the wide availability of the library in an open form is of more concern that its technical sophistication. The Linux Journal has already published an article[7] demonstrating the use of xview, demonstrating the ease with which simple applications can be constructed using variable argument-list calls, and there is little to add to that here with the exception (forgive the pun!) of how to use signals within in an XWidows system.

When the prism application is invoked by the name xprism, the xview GUI is enabled. Most of the data-flow in xprism is mono-directional: the GUI process produces control data; the synthesiser consumes this and produces audio samples. However, when the specification for xprism was conceived, it became evident that there was a need for asynchronous flow in the opposite direction.

  
Figure 3: The Shared Control Block Structure.

When xprism runs, the following sequence of events takes place:

• The analysis file is opened and the size of memory required to contain the spectra calculated. An additional allowance is made for spectral workspace, as in interactive mode, a mouse action might be responsible for setting the synthesiser parameters rather than relying on simply incrementing through the spectrograph automatically.
• The shared control block (Figure 3) is set up with appropriate initial values.
• The whole spectral file is read into the shared memory block.
• The process forks a child responsible for audio resynthesis.
• The parent xview widget hierarchy is intialised and the spectrograph drawn.
• The parent informs the child it may generate audio samples by setting the xv_ready field in the shared contol block.
• The parent and the child run concurrently, using the shared memory area for data transfer (Figure 4).

  
Figure 4: Data Flow in the Shared Memory Block.

  
Figure 5: Application Screenshot.

This process is fine for simple gestural control, but as it stands there is no feedback from the synthesiser process about whence in the spectrogram the resynthesiser is taking its data. Refer to the screenshot of the application running in Figure 5 and it is obvious that there are two fundamentally different ways of getting sound out of the program. The user can either select a playback speed from the speed slider, in which case the rate of advance through the spectrogram is under control of the resynthesis process, or click or drag on the spectrogram itself, in which case the spectrum to be resynthesised is under control of the parent, controlling process.

In the latter case, there is no problem in positioning the green line on the spectrogram canvas: it is simply dictated by the position parameter from the serviced mouse-motion event. In the former case, however, it is necessary to update the green line when the resynthesis source is moved automatically by the resynthesiser, and of course, this happens asynchronously with the GUI events. The solution is to arrange for the resynthesiser to signal the parent when an update is required.