Computing Resources

Computer Systems

You should have an account on the Department of Computer Science's Unix/Linux systems, which gives you access to the Linux PCs in the Ryerson Linux Lab. If you don't have a CS account, get one by filling out the form. The PCs in this lab run Linux, which for our purposes is just Unix. The PCs are named after famous trains. They are accessible by remote login from outside with ssh. If you are accustomed to using rlogin or telnet, start using ssh instead. These PCs are configured for interactive sound output, using your own headphones. Plug your headphones into the outlet on the left-hand side of the base of the monitor.

You may work wherever you like, but I will only take responsibility for software on the Computer Science systems. For the demonstrations in your final interview, I will provide a Linux PC with all of the software that is on a PC from the lab.

Software and Data

Utility Software

In order to work effectively, you need to use a fair variety of UNIX utility software. If you are not familiar with much of this already, or able to pick it up very quickly, you may have trouble with the course. I recommend:

UNIX shell:

You can't do UNIX without a shell --- the interactive system that processes your commands. I prefer bash, but if you are accustomed to another shell, stick with it.

XWindows:

In order to co-ordinate your work with a number of different pieces of utility and sound-processing software, you need to work in the XWindows system. classes, the Macintosh X terminals in Ryerson Annex 175, and the Linux PCs all run XWindows. XWindows is a protocol for managing graphics displays, but it does not provide any particular style of display on its own.

Window manager:

The particular style of graphical interaction in XWindows is controlled by a window manager of your choice, plus your customization of that window manager. My favorite is fvwm2. With the right choice of window manager and the right customization, you can simulate the look and feel of Microsoft Windows or Macintosh.

Editor:

To prepare programs and supporting documents, an editor that uses the graphics capabilities of the PCs is a big help. I strongly recommend Emacs. Some people violently prefer vi. Use what you already know.

Web browser:

To read the documents that I've prepared for you, and participate in the online discussion. I recommend NetScape on graphics stations, Lynx on character terminals.

Mail:

mm seems to be the usual thing for processing mail on Q/E/K/W. I use mh. Use whatever you like.

Online manual:

Of course, you can type the man command to the shell, but I recommend Xman, running in its own window, whenever you are on a graphics terminal. A lot of documentation is presented through the info command instead of man.

Document processing:

Textual materials that you want to share online will be most useful if you can provide them in HTML format, or LaTeX if they have significant mathematics. I do not insist that you learn LaTeX just for this course, but it is an extremely useful facility for typesetting mathematical and technical material, so if you find time to learn it you will get a lot of value over the years.

Version control:

I strongly recommend that you keep track of all your work other than soundfiles (e.g., CSound orchestra and score files) with RCS (Revision Control System). In each working directory, create a subdirectory named RCS. When you create a file, check it in with the command

ci -l <filename>

From time to time as you are working on a file, repeat the command. ci will prompt you for a desription of the changes, but the description is not nearly as important as just keeping track of the changes themselves. Most of the time you won't care about the series of versions stored for you by RCS. Occasionally, you will want to find out what changes you made recently, and you'll give the command

rcsdiff <filename>

To view the sequence of versions, use

rlog <filename>

When you get all screwed up, and wish you could get back to an earlier version, you can. At that point, read the documentation

man rcs

and

man co

to figure out how to use co and other features of RCS to back out of your errors.

Sound Data

Audio samples:

A number of sound files have been installed on CS machines. Each of these files contains a recording of one note played by an acoustic instrument. All sounds are sampled mono, at 44.1 kHz, 16 bit. They are in NeXT format (readable by MixViews), and can be found in ~ilia/Samples.

University of Iowa Electronic Music Studios

The studios provide a database, under construction, of recordings of orchestral instruments in an anechoic chamber.

SHARC:

A database of Fourier analyses for notes played on various orchestral instruments. The Web interface appears to be broken. I have a local mirror of the data. Watch out---the amplitude values are stored in decibel logarithmic units. I found the SSHARC data at Universität Hannover. Hannover's copy appears to have come from Sussex University.

Sound Software

CSound:

This is a computer music system that we will use for most of our project work. It performs very well for the sort of additive synthesis and filtering that we need, but as a language it is very obtuse. I have some examples that you can edit. Read the CSound manual for more information.

Cecilia:

A GUI front end for Csound, with a lot of stuff added. It looks fairly polished, but most of the interesting features aren't covered in the manual.

• I cooked up a slightly improved additive synthesis module for classwork: AdditiveSynth_OD. Load it with the Open item in the File menu.
  
  
• When the additive synthesis graphics window comes up, it will be a mere horizontal stripe. Stretch it out vertically until you see buttons for 16 harrmonics followed by Envelope on the left side.
  
  
• Save your work in snapshots (Save Snapshot as ... in the File menu).
  
  
• Here is a snapshot of a crude clarinet sound: crude_clarinet_1.snp. If you are using a local copy of the AdditiveSynth_OD module file, you need to edit the second line of the crude_clarinet_1.snp snapshot file to point to the module file. This is not intended to be a good example. It is only intended to suggest possibilities.
  
  
• To get sound out of Cecilia, we need to retarget its CSound binary. I will post instructions soon.
  
  
• I'm still trying to figure out how to produce a sound file from Cecilia.
  
  

snd:

A graphical sound-file editor. It is installed on the linux machines; the command to run it is snd.

Ceres3:

A spectral sound-file editor. It allows the user to graphically creare and or edit a spectrum, transform it in a variety of ways and listen to the results. Ceres is an ongoing project, contains a large set of features (and some bugs). It is currently installed on the linux machines; the command to run it is ceres3.

MiXViews:

A graphical sound-file editor, with some analysis tools. The command to run MiXViews is mxv.

DAP:

Another sound-file editor with processing features. Allows one to add effects, such as reverb, delay, flanger, etc. to the sound-files. Has a useful looping feature. To run it, type DAP (all CAPS).

Nyquist:

A sound synthesis tool built on top of XLISP. Nyquist is a much cleaner language than CSound, but it doesn't perform nearly as well.

MATLAB:

A software package providing a variety of tools for manipulating and representing numerical data. It is oriented particularly toward vector and matrix operations. It will play a vector of samples as a sound. MATLAB is found on most platforms at UC.

Octave:

Free software similar to MATLAB.

Scilab:

Free software providing similar functionality to MATLAB and Octave, but in a very different style.

Sndan:

A software package that provides musical sound spectral analysis, graphics, spectral modification, and additive synthesis. The Sndan applications are in /opt/sndan/default/bin. You may run them by typing /opt/sndan/default/bin/gopvan, etc. Or, you may add /opt/sndan/default/bin to your Unix PATH variable, and then you only need to type gopvan, etc. Read the documentation files in /opt/sndan/default/doc.

Copyright Michael J. O'Donnell <michael_odonnell@acm.org>. Licensed for free use.
This page is generated from PHP source code, with supporting files.