What Next?

 A number of improvements remain to be made to the CMU MIDI Toolkit. To encourage others to make these improvements, CMT is distributed with source code and documentation. If you develop a new tool or enhance an existing one, you can incorporate it into CMT by sending it to me (Roger B. Dannenberg) at the School of Computer Science at Carnegie Mellon University. Provided the changes or additions are consistent with the goals of CMT, I will integrate them into the next release and redistribute your code to other users. Thus others will benefit from your efforts as I hope you have benefited from mine.

The following sections outline changes I would like to see in the CMU MIDI Toolkit. If you decide to tackle one of these, it might be a good idea to call me at (412) 268-3827 or write to find out if anyone else is working on the same thing.

Compiler and System Conversions

There are many compilers and systems to which CMT could be ported. There is no Atari version. The Microsoft Windows multimedia extensions should facilitate a port to Windows, and Windows NT should provide realtime multitasking capabilities.

Multi-Track Recording

For long works and pieces where close synchronization of parts is important, it is essential to have some means of synchronizing Adagio output with a tape recorder. The MPU-401 has a tape-sync input and output which could be used for this purpose. Probably, a command-line switch (``-sync'') should be read by midifns.c. When the switch is present, midifns.c should tell the MPU-401 to synchronize to the tape input.

The !CLOCK command in Adagio might help here as well. When Adagio syncs to external clocks, its time is quantized to the clock rate. This should be fixed by adapting the timebase rate to the measured rate of incoming clocks.

File Output

It would be nice to have a command line switch that would copy text output to a file. This would allow MIDI Monitor (mm) output to be saved, for example.

Interacting with Moxc programs

Every Moxc program I write has a big asciievent routine that calls different routines and sets values depending upon characters that get typed at run time. It should be possible to write a routine that could read the map file produced by the linker and figure out where variables and procedures are located. Then, a user interface could be designed such that you could type 
seti foo 2006
call bar 100 572
in order to set the integer foo to 2006 and then call procedure bar with parameters 100 and 572.

The Amiga version of Moxc already has an interprocess communication facility, but it could be developed further.

Program Librarian

In Adagio, one specifies timbre by numbers that correspond to MIDI programs. It is up to the user to make sure the proper programs are loaded into the synthesizer in the right locations. It would be nice to be able to write a file like 
Channels  ProgramNumber  ProgramName  
1-8       1              marimba
1         2              harp
2         2              celeste
3-8       2              strings
which would specify a correspondence between program numbers and program names. One could write a Program Librarian that could read such a file and use it to load up a synthesizer with exactly the right programs for a particular piece. The program names would correspond to file names.

An Adagio Editor

It might be interesting to be able to extract sections of Adagio scores, stretch them, transpose them, copy them, merge them with other files, and so on. This can be done with a text editor, but a specialized editor, particularly one that could play the files as it edits them, might be more effective. Another idea for an editor is to try to use a combination of typed text and MIDI input to speed up the process of entering scores. This is a largely unexplored area that has applications in music typography systems as well as CMT.

The Canon system offers many facilities for manipulating and composing MIDI sequences and commands, but needs work before it can be released.

Interfaces to XLISP and AREX

An interpretive language like LISP can be an excellent teaching and composing tool. XLISP is a version of LISP implemented in C and is free for non-commercial use. It should be fairly simple to provide a LISP interface to midifns.c, allowing XLISP programs to make music.

The Amiga's AREX language provides a similar possibility.

Graphics

CMT is very weak on graphics because there is no system-independent graphical interface to build on. With C++ becoming a standard, portable graphics libraries based on C++ have emerged. A remaining problem is how to prevent expensive graphics computations from interfering with music processing and still maintain portability.

Streams, Sources, and Sinks

Output from Moxc is directed to the MIDI interface. It is not possible to, say, have output from Adagio behave as input to a module written with Moxc, short of running the Moxc module as an application on another computer and using MIDI to communicate.

The logical solution is hinted at by the seq structure, which has function pointers that are used to locate proper methods to perform Note On, Control Change, etc. This idea could be used for Moxc as well. Instead of there being global event handlers such as keydown and ctrlchange, there should be objects that serve as targets or sinks for event messages. For backward compatibility, there could be a default target/sink object that invokes global handlers. Similarly, seq structures and the Moxc event dispatcher should look like sources of messages, and it should be possible to patch sources to sinks in a flexible way.

There is already a fair amount of object-oriented programming in CMT. So far, CMT has avoided using an object-oriented language in order to maintain portability. The majority of Macintosh users seem to use Think C, which has not supported C++ in the past. Since this is changing, it makes sense to use C++ objects in the implementation of sources and sinks. Seq structures should then be a subclass of the source class.

Previous Section | Next Section | Table of Contents | Index | Title Page