What I have in mind is a large box which sits in the middle of the circle of players. On the top of the box is a large pointer (say 2 ft long), like a weather vane, which swings (driven by a motor) to point to the offending player. At the end of the pointer is a display which indicates to the second oboe whether he or she is flat or sharp.
An arm, say 3 ft long and perpendicular to the pointer, carries a microphone at each end. When the pointer is pointing at the second oboe, the sound signals from that instrument arrive simultaneously from each microphone. By measuring the Doppler shift of signals from the two microphones while the pointer is swinging, and carrying out some clever digital signal processing, one can isolate the contributions of each instrument, and so tell whether each is in tune.
The software will be written in C and will run on a Silicon Graphics Indy workstation, whose stereo audio input facilities would be used. The ``weather vane'' device will be designed by me and built by the Department's hardware technicians. It will be controlled by the Indy via an RS-232 port.
Alan Wood has pointed out that, from a theoretical point of view, tuning a chord is a fixed-point problem: one takes a chord and makes an adjustment to it; that gives a second slightly different chord, to which one makes a further adjustment; and one hopes to converge eventually to a solution at which (fixed) point ``improvement'' is the identity operation.
Before the academic year 1998-99, students built hardware from scratch using a Z-80 chip and support ICs (e.g. RAM, EPROM, I/O ports and timers), which they wired up themselves on blue-board. From 1998-99 onwards, students used a specially-designed ready-made system, the ``MCP 64180 development board'', as the basis of their designs. This board uses the Hitachi 64180 chip, a close relative of the Z80. The use of the development board certainly made the job of constructing a finished MCP system easier, and ensured that all students began the module from the same starting-point, but from an educational point of view it's possible that the course has suffered: students are presented with a finished board design, their options are to some extent chosen for them, and originality is stifled and the scope for ``learning through doing'' is reduced.
The main problem with the old style of course, which the MCP development boards solve, is the tedium of wiring up a 40-pin chip and several 40- and 28-pin support chips. This was certainly not educationally worthwhile! There is however a very interesting and widely-used family of CPUs, called ``PICs'', made by Microchip Technology Inc. (formerly Arizona Microchip). These are very powerful devices, some of which come in an 8-pin package. All PICs contain a RISC CPU, program memory (flash EPROM, UV-eraseable EPROM or ROM) and a small amount of RAM on-chip, and are very well suited to embedded applications - in short, an ideal device on which to base an MCP design.
If you attempt this project, you will first carry out one of the previous years' MCP projects, but using a PIC instead of a Z80 or the MCP 64180 board. Instead of the usual MCP-style report, you will write a longer report which will critically assess the suitability of PICs for the course, from both a technical and a pedagogic standpoint. I would expect the report to be of sufficient quality to help me to plan the evolution and future direction of the course.
I propose the construction of a program for analysing these event logs. The program will be interactive, with a graphical interface. It will allow detailed study and analysis of event logs, e.g. of the standard deviation of fixes, the dynamic behaviour of the filtering algorithms, and the behaviour when error events occur. It will allow the log of selected parts of the trip to be converted to PostScript and printed.
My usual practice is to print the path on OHP (transparent) film, which I lay on top of an Ordnance Survey map to see where I've been. If the project runs ahead of schedule, it would be possible to extend it by allowing the path to be aligned interactively - or even automatically - with a digitized O.S. map, such as are available through the Computing Service. There is however plenty of scope even without there extensions to the project.
For a general introduction to Loran-C, see the bibliography.
This project addresses a related, but simpler, problem, for which (so far as I know) there is no currently available automated solution: that of designing a PCB layout for circuits built on Veroboard. Veroboard is a form of PCB which carries parallel copper strips 0.1 inch apart. Each strip has holes down its centre, also on a pitch of 0.1 inch, so the board is covered by a uniform grid of holes. To build a circuit, you place the leads of the components through the holes and solder them to the copper. You then define the connections by cutting the strips at the location of a hole, using a ``Vero Spot Face Cutter'', a tool rather like a drill bit with a handle. It's a ``low-tech'', but effective and widely used, method of building circuits. In the golden days before computing took over from electronics as the thinking person's hobby, each of the many hobby electronics magazines would include full- or half-size diagrams showing exactly where to cut the strips to make Veroboard layouts for their projects.
You could base the graphical interface on my web-based circuit diagram editor (which uses the Java AWT), or on the X-Windows toolkit ; or you could use OpenGL .
Information about the CAD algorithms themselves is harder to come by, because so much of the development of these algorithms is protected by commercial secrecy. A literature search will form an important early stage of the project, but for a ``taster'' see Reference .
It has been suggested that the Smalltalk user interface components might be a good starting point for your design.
This is a design project. You are not expected to implement the interface you design, although clearly you will discuss implementation issues in your report. Because of this limitation of scope, the design is expected to be very thorough indeed.
One of the novel unifying features of Alpha is the transliteration. One writes, e.g.,
<tr +- fSx1 ... >trwhere ``fSx1'' is a ``magic'' sequence which identifies the plus-or-minus symbol ``±''. Between the <tr and >tr brackets, one can then use the string ``+-'' to stand for the symbol ``±''.
The invention and fairly wide acceptance of Unicode  has made this convention unnecessary, at least for specifying unusual (non-Ascii) characters. Unicode is a 16-bit character set which includes the plus-or-minus symbol, as well as many others for scripts such as Arabic, Devanagari and Cyrillic.
The aim of this project is to adapt Alpha to use Unicode throughout instead of Ascii. Most industrial software development entails the modification of existing programs rather than the writing of new ones, so this project will appeal to the student who wants a ``taster'' of this type of work; however the scope for creative original programming in this project is substantial. The Unicode standard contains information on the basic formatting algorithms necessary for working with Unicode text, but there are many further design issues which the student will have to resolve.
Alpha is written in C++. A working knowledge of C, and a willingness to learn the necessary modicum of C++, will be required. The source code is here.
Although Handel-C is a powerful and well-designed language, it has its limitations, e.g. the lack of a ``parallel PAR'' (to use CSP/Occam terminology). The central aim of this project is to write a compiler which, by compiling Java into Handel-C, circumvents these restrictions. This could be done either by modifying an existing compiler (e.g. Fisher's Java Compiler), or by writing a translator which converts Java byte code into Handel-C. Secondary aims will include an appraisal of Handel-C and an investigation into the correspondence between a Java object and a set of interconnected gates, i.e. a piece of hardware. The attribution of a sensible semantics to the Java construct ``new X'', where X identifies a piece of hardware, is an interesting research problem.
PICs are usually programmed in assembly language. The aim of this project is to investigate the programming of multi-PIC processor arrays in the concurrent programming language Occam . This will entail the modification of an existing Occam compiler to generate PIC assembly language. Occam presupposes a simple CSP-style data transfer protocol, and part of the project will address the efficient implementation of this protocol on a PIC.
The project will conclude with the implementation of a simple real-world multi-processor embedded application, programmed in Occam.