Csound

7 July 1998  (Updates to links to other sites 20 Nov 1998, 17 July 1999 and 24 Nov 2000.)
 

Note: I am not keeping this page up to date.
For  more up-to-date general Csound material, please see: The introductory material here may still be of value to those wondering what Csound is, and the specific material which follows may still be of interest to Csound programmers.
 


Csound is a program for the software-only synthesis and processing of sound.  It is powerful but unforgiving programming language which was originally developed by Barry Vercoe of MIT, and is now maintained and extended by a loose-knit team of programmers.   Csound is not for the faint-heated!  Here are some introductory and deeper material.  Following that, I concentrate on some gutsy Csound issues for those who are already familiar with the program.

 
Introductory material

Down this page to material on manuals and tutorials (Last update 4 June 1998) 
Down this page further to the more in-depth material (Last update 4 June 1998) 
Down further still . . .  deeper still (Last update 4 June 1998)


  
To the MIT Press Csound Front Page 

http://mitpress.mit.edu/e-books/csound/frontpage.html

This is Richard Boulanger's site linking to Csound resources and people, as a prelude to his long awaited book on Csound, which is to be published in mid 1999. 


 
The Infamous Linux version of Csound

20 November 1998: A small team of Unix programmers lead by Nicola Bernardini <nicb@axnet.it> and Dave Philips  http://www.bright.net/~dlphilp/index.html is working on a Linux version of Csound.  I am a currently inactive member of the team.  There is a mailing list - best to contact Nicola or Dave about joining.  Nicola has established a CVS system and is doing excellent work keeping the project organised, solving tricky code problems, and keeping the source tree as in-synch as possible with the Linux version of John ffitch at Bath.  "Infamous" is a temporary name to distinguish this from John's Linux version.  One team member has Csound running on Alpha Linux too.
 


 
My "in-progress" material 

To the gutsy stuff! (Last update 7 July 1998)
This includes my work on an internal 31 bit Pseudo Random Number Generator for the x-class noise opcodes and allowing a backslash to exist in the .orc when it is not used as a line continue command. 


 

Introductory material

Csound is not a commercial program, a MIDI sequencer or a digital audio editing program.  It is for synthesis, analysis and processing of sounds entirely in software.  The source code is available and is worked on by a number of people, including myself.  The same basic source code, with ideally minor tweaks, compiles to produce executable programs for a variety of computer systems, including Linux, other flavours of Unix (SGI and Sun), Windows 95/98/NT, MSDOS and Power Mac.  It makes extensive use of floating point calculations, and for all but the smallest projects, it is best to have the most powerful computer you can afford. Fortunately, with the savage speed of Pentium-class machines at consumer prices, serious computer-based software synthesis is now highly affordable.

Csound does not have a graphic interface - it is a command-line driven text-based program.  There are several approaches to graphic user interfaces for running the program and more importantly for controlling aspects of the Orchestra and Score files which Csound executes to do its work.

Csound is basically a programming language, with "instruments" being separate programs in the Orchestra file, written in the Csound orchestra language.  Such an instrument might be a filter, a program that plays and/or processes a sample file from disc, or something which generates audio and/or control signals - perhaps to be used by other instruments.

Like the Orchestra file, the Score file is a text file - but it is not really a computer program. Each line tells a particular instrument when to start and stop operation, and gives it parameters to work with to customise what that instance of the instrument does.  This might be as simple as telling an "oboe" instrument to play a particular note for a particular time or it could be much  more complicated. Each instrument could recieve a hundred or more numeric parameters on its command line.

Having defined an instrument in the Orchestra file, the Score file can instantiate as many copies (instances) of that instrument as the computer memory allows.  So you write one "oboe" instrument, have ten thousand lines in your score that instantiate the "oboe" instrument - typically with them all playing a slightly or radically different pitch etc. at the same time, and your computer chugs away calculating the sound of these ten-thousand "oboes", and summing them together for the output.

Csound was originally conceived to support relatively independent "instruments" whose outputs would be summed together.  Communication between instruments - both of audio signals and the typically slower-changing "k" rate control signals - can be accomplished by named global variables.  This is fine for simple, relatively fixed arrangements, but if you want to have an instrument which figures out for itself which global variables to read and write, then this becomes unwieldy.  Csound lacks arrays or pointers, in the normal sense.  A way around this is my "zak" system - now a standard part of Csound - which acts like an arbitrarily long set of numbered global read/write/accumulate patch-points for both "a" and "k" rate signals.

All Csound internal calculations are in 32 bit floating point format, so no matter how big or small a number is, it is accurate to one part in 2^24 - 256 times more accurate than 16 bit digital-audio.  Csound can calculate at any sample rate.

Originally Csound worked only from its two input files - Orchestra and Score - and optionally by reading sample files - such as .WAV or .AIFF files - from disk, to produce a mono, stereo or quad output file.

With suitable hardware and CPU speed, and a relatively simple Orchestra/Score, Csound can now run in real time - reading real-time MIDI inputs or reading a MIDI file and potentially outputting MIDI too.  MIDI, however, is a very simple and limited concept compared to the great flexibility of Csound.  For instance, there is no restriction on pitch - it is all 32 bit floating point numbers so you can have any pitch you like. In some systems, real-time processing of audio is possible too.

There is a comprehensive book on Csound due for release sometime soon by the MIT Press, edited by Dr. Richard Boulanger.  This will have a CD-ROM and will be an invaluable introductory and reference book.

Richard has a much more comprehensive and up-to-date Csound Front Page:

http://mitpress.mit.edu/e-books/csound/frontpage.html
There you can find lots of links and information, including how to join and read the archives of the Csound mailing list. This site also contains the Csound FAQ by Jacob T. Joaquin.

Manual and tutorials

Dave Phillips has a tutorial at:

http://www.bright.net/~dlphilp/dp_csound.html
Allan Schindler has written an extensive tutorial on Csound:
http://www.esm.rochester.edu/onlinedocs/allan.cs/

More in-depth material

The primary site for Csound executable programs and source is John Fitch's ftp server at the University of Bath:
ftp://ftp.cs.bath.ac.uk/pub/dream/ 
In the /dream/ directory, some key things to watch regarding the latest version are:
/documentation/  Here you will find a file ChangeLog.Csound  which is John Fitch's monumental log of changes to Csound since early 1995.  As of May 1998, there have been minor version numbers such as 3.48, then 3.481, then 3.482 etc.  The release notes for the major version number are in a suitably named file in this directory.  For details of the minor version number changes, see the changelog file and John's announcements on the Csound mailing list.

/newest/  Here is where the release notes for the latest major version can be found, together with John's generic Unix sources (which I think work directly on his SGI and with which he produces the executables in the /platforms/SGI/ directory) and the executables and source for Windows and MSDOS versions. In the source, the version number can be found in version.c .

/platforms/mac/ This contains the executables for the 68k and PPC Macintosh systems.

/platforms/unix/Linux/ Contains source and binaries for Linux.  In recent times, it seems that Dave Phillips has been producing these, after working on John Fitch's source.  As you can see below (1998 June 4) there are some things to sort out in the code to make it compile and operate correctly on Linux machines, especially with glibc (the new C library).  The binaries here are for Intel Linux.  Is anyone using these sources to compile for Alpha Linux?

Dave Phillips has a good set of Csound links and resources at:
http://www.bright.net/~dlphilp/linux_csound.html
He also has a massive list of various programs which are useful for audio work under Linux, including Digital Audio Editing programs.
http://linux-sound.org
(Linux is the freely available Unix-like operating system which is ideal for intensive technical computing, Internet server and client applications and many other things.  Linux has nothing to do with Windoze - although there are emulators for Windoze and MSDOS.  Linux runs on ordinary Pentium PCs as well as on other more exotic computers such as those based on the ferocious (but in 2003 doomed . . . ) DEC (Now Compaq . . . or is it HP ?) Alpha CPU.  Don't take too much notice of the silly looking penguin mascot - this is a serious and very solid operating system with millions of users.  You don't hear a great deal about it compared to Bill Gate's products, because no-one is making such a lot of money from it.  Linus Torvalds, who originated Linux, pronounces his first name and "Linux" with a soft "i" as in "link" - not as in "line".

Gabriel Maldonado has done a lot of work getting Csound running nicely under Windows 95, in real time whilst processing sound in real time and handling MIDI In and Out.

2003 links:


http://csounds.com/maldonado/  and this is still the main web page of csoundav:  http://csounds.com/csoundav/

An important graphical interface development for Csound is Cecilia.  This runs under Intel Linux or on a Power Mac and provides a conducive environment for writing orchestra and score, executing Csound in real-time simply by clicking on a button (you don't even have to save the files - and it checks the syntax and points you to any mistakes) and most importantly the ability to set values and edit graphs with the trackball/mouse.  The graphs are translated into tables in the Csound score and can be used for waveforms, or for any time-varying purpose - such as controlling the volume or frequency of something throughout the length of the piece.  Cecilia comes with its own Csound executable program - which does the processing work.  (With release 2.02 of Cecilia, the Csound version is 3.47, but this has trouble with the longer table specifications output by Cecilia, so I suggest using 3.48 instead.)

The main Cecilia site is:

http://www.musique.umontreal.ca/electro/CEC/
The Cecilia on-line manual is very helpful:
http://www.musique.umontreal.ca/electro/CEC/man/

Quasimodo

(Roughly updated in 2003.) Paul Barton-Davis had an ambitious and promising project: Quasimodo.  This supported Csound orchestra and score files, and with minor changes, the unit generators in C.  It was planned to be a much cleaner, more open, better structured program than Csound (which dates back to the early eighties).  It is written in C++ using modern techniques such as threads, the Standard Template Library and so-on.  Quasimodo runs under Unix, and is being developed under Linux.  It can make use of multiple CPUs.  It can read and write audio and MIDI in real time and has a real-time graphic user interface.  The interface for each instrument can be configured in the .orc file.

It is early days for Quasimodo.  Paul's site no longer exists: http://www.quasimodo.org . 

 
 

Deeper still . . .

Csound is not the only software music synthesis program.  It is probably the fastest - which is important because some pieces can take hours to cook.  It is a rigorous and not particularly elegant programming language.  Don't try this for your first attempt at learning computer programming unless you are really keen!  It descends from the Music N languages of the 1960s.  There are many computer programing languages for dealing with sound, MIDI and music notation.  See the PLUM list at:  http://www.nosuch.com/tjt/plum.html  .

"Extended Csound" is what Barry Vercoe has been working on for several years - while others continued to develop his ("public") Csound.  Extended Csound is meant primarily to run on Analog Devices' SHARC DSP chips.  These are intense 32 bit floating point DSP devices.  Some recent information is here. From what little I know, it is intended as a lower-level library of functions to support various audio applications - rather than as a "computer-music compositional program".  The source code of Extended Csound is not publicly available.  One company who has plans for it is (was) , Pavo. According to the Analog Devices search engine http://www.analog.com/ they don't have a lot of information there on Csound in early June 1998. On 10 June 1998, Scotty Vercoe - who is responsible for Extended Csound at Analog Devices - posted this message to the Csound mailing list

The Csound source code is not a pretty sight.  There are many elegant processes at work in the heart of Csound - but it sure doesn't look that way on the surface - and there are some rather inelegant things too . . .  As it is said in the movie Repo-Man: "No, you don't want to look in the trunk."

Once Csound has loaded and translated the .orc and .sco files, it maintains two major kinds of linked lists in RAM.  One is a list of instrument instances - which changes as instances end and are added due to the score, MIDI file or real-time MIDI events.  Each instance is the start of a second kind of linked list - a list of unit-generators, which together make up the instrument.  This is really a list of the data areas for each instance of  unit-generator object. There remains a single piece of code for each kind of unit-generator.  The instances can be relatively small - a few hundred bytes I think - or they can be very large if there needs to be lots of space, for instance for a delay line.  For each "k" cycle - which could be one to many audio cycles - the program runs through the ugens of one instrument instance, and then runs through the list for the next - and so on.  At the end of this, a certain number of audio samples are produced. These are sent to the output file or device, the time is incremented, the score/MIDI is checked for starting and ending instruments, and any instruments which failed in the last pass are taken out of the list.  Then the whole thing happens again.  The code which traverses the instrument list and runs through each list of ugens is in insert.c :

        while ((ip = ip->nxtact) != NULL) { /*   for each instr active */
          pds = (OPDS *)ip;
          while ((pds = pds->nxtp) != NULL) {
            (*pds->opadr)(pds); /*      run each opcode    */
          }
        }
So there you have it - the throbbing heart of Csound!
 

A potentially significant and public development based in some ways on Csound is Eric Scheirer's "Structured Audio Orchestra Language" SAOL. http://sound.media.mit.edu/~eds/mpeg4/  This is part of the MPEG-4 standards - which seem to be rather wide-ranging.  I have not looked in detail at SAOL, but there is the intention that it be able to be executed in real-time on a variety of relatively low-cost user devices, taking input from a network connection and from local hardware interfaces.
 


My "in-progress" material

6 July 1998  (Note, 17 July 1999, this was "in-progress" in July 98, and is presented here as a reference.  I am becoming more interested in pusuing Quasimodo at present, rather than traditional Csound.)

Includes material on improvements, bug fixes, getting the latest version of Csound working under Linux - with glibc. Note that I am only concerned with the main Csound program, not the utilities, such as "hetro", "lpanal" etc. - which I don't at present use.

Introduction

I first started working with Csound around 1995 or so.  Now in mid 1998 I am returning to the fray after a break of 18 months or so, during which I have acquired some more serious computer power (a Pentium Pro 233 MHz machine running Linux) and some other important things, including a DAT recorder, a Zefiro ZA-2 Digital Audio Sound Card  (http://www.zefiro.com) and a Windoze 98 K6 machine networked to the Pentium-Pro for editing and for running the ZA-2.

In 1996 I wrote quite a number of additional unit generators (ugens) for my own purposes.  During 1997 many of these were incorporated into the "standard" Csound code-base by John Fitch.  For archival purposes, I have put the relevant files in a sub-directory here: rw970107/ The great majority of these are now incorporated in the standard Csound.

I made two pieces of music with Csound in 1996 which I am happy with.  Now I want to do lots more, using Csound running under Linux, and using Cecilia to help with controlling various time-varying aspects of the pieces which are better suited to graphical representation than lots of numbers in the score.

Progress since 4 June 1998 has been:

  1. Get the Linux source code for version 3.482 compiling on my Linux machine.  This runs Red Hat Linux 5.1  Both these use the new C library, which is "glibc" (AKA libc-6, libc6 and GNU libc 2 . . . ) as opposed to the old approach used by Red Hat 4.2 and earlier, which was known as libc-5 or similar.   This new approach to the C library is intended to make the library independent of the kernel and its header files.  All the info is at:  http://www.gnu.org/software/libc/libc.html

  2.  The 3.482 version was at John Fitch's ftp site, but the files are actually created by Dave Phillips 

    Csound-3.482-Linux.src.tgz

    (In 2003 I am not sure were it is.)

    This source was prepared by Dave Phillips, from John Fitch's source and with a fabulous new autoconfiguing makefile system by Nicola Bernardini.  There are a few reasons why it did not compile with glibc - and Damien Miller found them and fixed them.  Full details are available in the directory cs-linux-glibc/   Csound 3.482 runs under glibc.

    Dave Phillips and Nicola Bernardini now have source and excecutables of Linux 3.482, with these glibc patches all in one Glibc.patch file, containing a few patches of Nicolas regarding square brackets inside comments and some problems with diskin.c regarding skip-time and display of sample rate.

    Be sure to read Dave's file READM.Linux, which explains how to use Nicola's fab new Make system!

    The "Make.Variables" file is of interest to someone like me, who will be adding new .c and .h files.  There are special places up the front of this file where such files should be added.  I have never sat down and studied the innards of make files before - but to simply add files to the system that Nicola has set up, it seems you don't have to. Excellent!  In my experience, the command "make install" does not install the csound executable anywhere - so I put it in /usr/local/bin/ .

    ftp://mustec.bgsu.edu/pub/linux/

    ftp://musart.dist.unige.it/CSOUND  (Dead in 2003.)

  3. I have gone through the 3.482 version to find what changes were made since I last worked with Csound.  Virtually every enhancement I made to Csound two years ago has now been incorporated.  These include many opcodes, which you can look up from the manual manual/REFER.html  (Note this is not here any more, I didn't want this old manual floating around on the Net.  Refers to csounds.com for the latest documentation.) Note that when John incorporated my code into Csound, he reformatted the comments to make them more compact.  I think my original formatting is much clearer.  See the original files from 1997 at: rw970107/
    1. All the code in ugrw1c./h and ugrw2.c/h (and the related changes in entry.c and the new function ftfindp added to fgens.c).  This includes many new opcodes (what the programmer sees as the .orc code constructs which are provided by the new unit generators):
    2.     zakinit   zir     zkr    ziw    zkw    ziwm   zkwm
          zkmod     zamod
          zkcl      zacl
          zar       zarg
          zaw       zawm
          
          itimek    itimes
          timek     times
          instimek  instimes

          printk    printks
      These are all mine, in ugrw1, but a new, very useful, opcode by Gabriel Maldonado has been added to ugrw1.c/h as well:
          printk2
      Opcodes un ugrw2.c/h are
          kport     ktone     katone    kreson    kareson

          ilimit    limit
    3. My re-write of the table read code in ugens2.c which fixes the bugs in the normal table read code (as documented in rw970107/tabread.txt ) and include table read ugens (k and a rate, normal and interpolating) in which the function table number can be controlled at k rate:
    4.     tablekt   tableikt

      To
      To see the ugrw2.c with the originally formated comments:  rw970107/UGENS2.C
       
    5. I had added the xu
    6. niform distribution opcodes to the "x-class noise" family of random number generators (as they are called in their manual page).  Paris Smaragdis accidentally left out of the original code.  These are now part of standard Csound.  (My 31 bit random number source has not been added - see more below.)
    7. I had increased the maximum number of function tables to 1000 and the maximum instrument number to 1200, but I understand that some time ago, John Fitch recoded things to remove hard limits on both these.  There are some limits on instrument number . . . . 5000 is fine. Defining an instrument number 123456 in the .orc is fine, but trying to play it from the score leads to problems - I get an error: " - note deleted. instr 123456(123600) undefined".  The same rounding occurs with 123400.  12340 is fine.  65535 and 32768 gets rounded to 123600 too!  32767 is fine.  So it seems we can have instuments numbered between 1 and 32737 inclusive.
    8. When it comes to function tables - the limitation on number seems to be well beyond 32k!  I successfully created a table 123456.  Then I tried 12345678!  It worked, but there was a few seconds delay - no doubt Csound was creating a huge linear table for all the potential function tables, and this took it a few seconds to allocate the memory - and probably involved the swap file too.  So: There's no real limit on the number of function tables - their number can exceed 65536 and can be well into the millions.  However memory limitations for a linear list that long for all function tables in that range could be a problem.

      Excellent!
       
       

 

What I want to do to the Csound source code - 5 July 1998

  1. Add a centralised 31 bit random number generator for the "x-class noise" random number sources.
  2. Alter the printks code because it is now impossible (due to some backslash driven line-continuation functions somewhere) impossible to include a "\" in the string, so making it impossible to print new-lines.
  3. Add some kind of pink-noise ugens - for k and a rate.  This is a bigger project - leave it until later.

1 - Adding a better Random Number Generator to Csound

/* "Anyone who considers arithmetic means of producing random number is, 
 *  of course, in a state of sin" - John Von Neumann 
 */
Summary:  The "x-class noise" ugens (xunirand, xlinrand etc. where x = i, k or a) in the 3.482 version of Csound all run from the C library's "rand()" function.  This is function is very often implemented as a PRNG (Pseudo Random Number Generator) with a 16 bit state - so it replays the sequence of numbers every 65,535 calls - resulting in audible repetition for audio signals using such noise.  The question of random numbers is far too important to leave to some unspecfied C library function!! More on fixing this below.  But first, an overview of the other random number systems in Csound:
  • In ugens4.c, there is the rand, randh and randi code.

  • These are self-contained 16 bit PRNGs which can have their seed set as an option.  Each instance maintains its own state.  These are the oldest set of random number generators in Csound.
     
  • Barry's recently added irnd, ibirnd, krnd and kbirnd code in aops.c.  These are effectively a single, self-contained  PRNG, since the two functions rnd1( ) and birnd1 ( ) both have the same algorithm and share the same state - a double precision ( ie. 64 bit) floating point number .  The seed (rndfrac) is always set (to 0.5) at the start of Csound running, so these ugens would always produce the same sequence of numbers. There is no option for setting the seed.  The algorithm a simple floating  PRNG and I don't know anything about the quality of noise it produces.  The algorithm is to multiply the seed by a magic number 105.947 and to take the fractional part of the result and use that as the output of the algorithm and the new seed.  Most PRNGs work with binary numbers - but Barry's would probably run much faster than those, especially on a SHARC DSP chip.
  • Beware of the misleading manual documentation with these.  As reported to the Csound list on 5 July 1998, don't use "irnd", "krnd", "ibirnd" or "kbirnd" - use "rnd" or "birnd".  Furthemore, if you want k rate outputs, make sure their range is a k rate variable, not an number or an i rate variable!  So  kfoo = rnd ( kbar ) is fine, but kfoo = rnd ( 1 ) will only write to kfoo once, at init time.
     

  • The grain ugen uses pseudo-random numbers - by calling the library function rand( ).  I have left this alone - I don't think that 64k cycle length problems would be an issue with granular synthesis - but then I have never used it and others my be more fussy.
  • None of these random number systems is anything to get excited about.

    The "x-class noise" set is very useful, although I haven't read the references to understand what the "cauchy", "wiebull" and "beta" distributions are about.

    I am interested in a Csound piece having quite a few random elements, and there being:

    1. An even distribution of random values.
    2. A long pattern of pseudo-randomness - ie. not a short repeat pattern.
    3. The ability to start all random functions from a single seed.
    So ideally, all random functions would return a huge range of values, in a very long repeating pattern, and a single seed would start the process.  This enables me to create a piece say ten times, based on ten seeds that I choose.  Then I can listen to them and depending on which one I like the most, know that I can regenerate that version
    predictably from the same .orc and .sco file and the same seed.

    So all random numbers would arise from a single common function, working from a single variable which is updated every call.  This variable is initialised by the seed I put in.

    What is needed is a decent PRNG, within Csound, which can have its seed set, and which has a long enough repeat cycle not to be audibly noticable if, for instance between 1 and a thousand or so calls to the PRNG are in some way combined to form a single sample of audio output.

    We don't need cryptographically secure PRNGs or those whose cycle wraps around after the universe has decayed.  I believe that a PRNG with a (2^31 - 1) long cycle would be fine.  This is 2,147,483,647.  If we used a thousand calls to the PRNG (ie any call at all, to any of the x-class noise opcodes which use this single PRNG) for each audio cycle we create, then the PRNG would start its cycle again after 48 seconds.  Hmmm - not ideal - but using 1000 pseudo random numbers is rather extreme per audio cycle.

    The other thing we want is that it be relatively fast in CPU terms.

    After looking around, I found that there were some very complex PRNGs with extraordinary statistics and repeat cycles beyond the astronomical.  At the other end are 16 bit state PRNGs which are obviously not what we want.  There were many references to a paper called:  "Random Number Generators: Good Ones Are Hard to Find", S.K. Park and K.W. Miller, Communications of the ACM 31:10 (Oct 1988).  One algorithm is known widely as "Park Miller" which is reproduced on a number of web sites is a simple one which these authors regard well - as being a minimal standard.  Searching with Alta Vista, with the name of this paper and a magic number "16807" (or another "48271") leads to things including:

    There are two implementations of this algorithm, without any copyright notices, accessible via:

    http://htm4.ee.queensu.ca:8000/ling/assign868.html  (Dead in 2003.) 
    One of them has a snappy piece of coding which does not require 64 bit aritmetic.  The algorithm is pretty simple.  Some history of this algorithm, which has its roots in 1948 (Lehmer) and 1969, is in an article at:
    http://www.mactech.com/mactech/articles/mactech/Vol.08/08.03/Random-Numbers/text.html   (Dead in 2003.)
    however it is a bit tricky to read, since "2^31" or "2 to the power 31" is printed as "231"!

    These Linear Congruential Generators take the previous number, multiply it by a constant "a" and then take the mod "m" of it where "m" sets the limit of the output range.  These 31 bit PRNGs use m = (2^31 - 1) = 2,147,483647.  The choice of the "a" number needs to be made carefully, to ensure that ever number is in the sequence and to minimise (or complexify) the patterns which result in the output.  See the above link for an explanation.  a = 16,807 is widely used (= 7^5).  So is a = 48,271.  A site which lists a variety of values for "a" for these Park-Miller PRNGs (16,807, 48,271, 69,621, 45,991, 207,707, 138,556, 49,689, 40,014 and 40,962)  is:

    http://aaron.physics.lsa.umich.edu/LAB/Doc/Swarm/src/random/PMMLCG1-9gen.html  (Dead in 2003.)
    One promising approach seems to me to be the C code in:
    http://htm4.ee.queensu.ca:8000/ling/fastrng.html  (Dead in 2003.)
    This algorithm does a few tricky things which apparently make it run faster on Intel CPUs, but I don't yet undstand why.

    Another one, which looks ideal is:

    http://www.snippets.org/snippets/portable/RG_RAND+C.php3
    This is public domain code, by Ray Gardner, based on the 1988 paper and a 1990 one regarding faster implementation and using Linus Schrage's method to keep it all within 32 bit aritimetic. The multiplier is the well known 16,807, but this could obviously be changed.

    I will implement this in cmath.c/h as:

    1. A single Park-Miller-Shrage PRNG producing a 31 bit result and maintaining a single 31 bit state. Its default seed will be based on the time of day when Csound starts.
    2. Modify the seedrand( ) function to drive the above PRNG's state, such that if the input paremeter to the seed opcode is 0, then the time of day will be used, and if it is anything else, then the seed is used to three decimal places, with a range of any positive or negative number to a maximum value of +/- 2,147,483.645. Input above this is treated mod 2,147,483.645.
    But first . . . we need a benchmark of how fast the current library rand( ) based system is, so we can see what, if any performance penalty there is with the new code I cook up.  I created an .orc file with two instruments.  One does nothing and the other has 1,000 lines of "al = aunirand".  I run it at 44.1 kHz, with ksmps = 10.  The system is a Pentium Pro 233MHz 256k cache, Linux machine, with glibc 2.0.7.  The rand( ) call in the Csound code would call the rand ( ) function whose source can be found in the glibc-2.0.7/stdlib/ directory.  The call probably goes to __random( ) in file random.c, or it may go to __random_r( ) in file random_r.c.  The former calls the latter which does the work.  It is a 31 bit state linea congruential generator, borrowed from BSD.  The new state is the ((old_state * 1103515245) + 12345) & 0x7fffffff.  So this is probably quite a decent PRNG, but we should not cede control of musically significant things like random numbers to library code outside Csound!  Anyway . . . when the dummy instrument runs for a second, execution time is 0.23 seconds.  When the instrument with 1,000 aunirands in it runs, it takes 14.8 seconds.  Therefore, this process of making (44,100 * 1,000) audio rate random numbers took 14.6 seconds, or 0.331 usec per sample.

    1.30 AM Monday 6 July.  Tis done!  Apart from syntax errors, it worked first time. The new random algorithm sounds fine.  It does the test described above in 11.6 seconds, so by this measure the entire unit generator process for aunirand is sped up by 28%.  It is late now - I will check the seed setting soon, and also invent a "xbunirand" set of opcodes - which give uniformly distributed numbers in the -1 to +1 range, when using a range of 1.

    5 PM Monday 6 July 98 I completed the seed setting facility.  This was always available as the "seed" opcode - which was not in the manual.  Now the seed opcode, which runs at init time and takes a single irate parameter, will set the seed of the new PRNG.  A value of 0 sets the seed to a hashed value of the current time and date.  Any other value is made positive, and used to three decimal places (for small numbers) to set the seed of the PRNG.  Technically, the float input parameter, which is accurate to 24 bits, is made positive, mulitplied by 1000, modded with (2^31 - 1) and used as the seed.  In either the date or number mode, the input parameter and the resulting seed value are printed.  The seed can never be set to 0.  The "seed" documentation belongs on the same page as the x-class noise:

    seed
    I also added functions in cmath.c and lines in entry.c to implement three new bipolar uniform random opcodes: ibunirand, kbunirand and abunirand.
    ir    ibunirand    irange
    kr   kbunirand   krange
    ar   abunirand    krange
    These behave just like the xbunirand opcodes (erroneously called xuniform in the current manual) except that their ouput range is positive and negative, rather than positive from 0 to xrange.  For instance:
    ar   abunirand   100
    will write evenly distributed random numbers - ie white noise - in the range -100 to +100.

    This involves changes to:

    cmath.c
    cmath.h
    entry.c
    The patchfile to acheive the changes is in the directory:
    http://www.firstpr.com.au/csound/rand31/
    On a Unix machine, put this rand31.patch file in your source directory and give the command "patch -b < rand31.patch" and these three files will be changed.

    The above directory also contains the new and old versions of entry.c, cmath.c and cmath.h.  There is a Csound executable program there - linked statically to glibc.  This is binary for Intel Linux systems.

    As an added bonus, there is also an updated version of the x-class noise csound manual page in the above directory - which you can view here:   http://www.firstpr.com.au/csound/rand31/

    Note! I think there are bugs or misconception by me or Paris about what the xexprand and xbexprnd (not xbexprand) opcodes are supposed to do.  Also there is some harmless but unnecessary code in cmath.c - which I have not corrected.  For instance in most of the ikxxx functions towards the end, the output should be written to "out" not to "out++".
     

    2 - Allowing a backslash to exist in the .orc when it is not used as a line continue command

    7 July 1998

    Some of my .orc files use printks to report their progress.  This really relies on being able to have newlines as part of the output of the printks opcode.  Changes to Csound since I last used it two years ago involve interpreting a backslash character in a .orc file as a command for the current line to be logically continued on the next line.  The new code for this in rdorch.c attempts to skip over white space and comments between the backslash and the end of the line.  However this clobbers the backslash that I use in the printks string to create a newline or tab with "\n", "\N", "\t" or "\T".

    The fix is to modify rdorch.c at a point where such a situation is detected by the existing code (the rdorch.c file in version 3.482 dates from 18 May 1998 and is 35,508 bytes long) so that the backslash and the character which follows it survives.  This fix will only work if the backslash is followed by a printable character.

    Here is a new version of rdorch.c and here is a rdorch-backslash.patch file in which the changes are fully documented.

    Note that the manual gives some incorrect examples of printks usage. (Backslashes are not required before the double quotes - this may be an accident of the HTML coding of the manual.)  For instance to simply print a text message and a new line, with no variables, every ten seconds of compilation, four dummy variables must still be given:

    printks "All is well . . .  \n", 10, 1, 1, 1, 1
    To print four floats, every time this line is run during init or perf time, with different formatting:
    printks "Huey = %3.0f, Duey = %4.2f, Louey = %5.4f and Scrooge = %f \n", 0, khu, kdu, klo, ksc
    This would result in:
    Huey = 123, Duey = 1234.56, Louey = 12345.6789 and Scrooge = 9573585.99
    There are some questions about this backslash system, or was it the macro code looking for "#" inside comments . . . but I have not looked into that.
     


    My longer term things-to-do list for Csound is :

    1. Go through my source code and tidy any loose ends.
    2. Figure out exactly how I want to use Cecilia - for instance I don't want to write my main .orc or .sco code in its editor, for reasons including the tab system, which is not based on normal tab behaviour.  This means including the larger .orc and .sco files, and probably editing them with Nedit:  http://www.nedit.org  (maybe get orchestra syntax highlighting going with Nedit?).
    3. Do whatever is required, with the Open Sound System ( http://www.4front-tech.com/  ), to get my sound card working (just an ESS card - the Zefiro ZA-2 is in the Win98 machine) with audio out and MIDI In and Out.  Likewise figure out Csound's new MIDI In and Out features . . . and have some fun with my Devil Fish and a MIDI to CV converter . . . and eventually make some music!

    4.  

    Update history

    Updates in reverse date order