Csound Csound-dev Csound-tekno Search About

Mac Csound PPC 3.484(beta)

Date1998-08-03 23:34
From"Matt J. Ingalls"
SubjectMac Csound PPC 3.484(beta)
BETA RELEASE		aug3.98
	Csound for Power Macintosh
=======================================
This Version: 
	fFitch code base	3.484
	Perf "engine"		3.484 beta(0)
	Csound "front end"  	1.0 beta(0)
	
Available From:
	ftp://mills.edu/ccm/csound.ppc

=======================================
This needs testing!  No doubt things will not
work.  When you find a potential bug don't
hesitate to email csound-dev@mills.edu
so we can fix the problem. (however, you may
first want to read the "known bugs" below)

If this "beta" version proves stable enough,
we will put out source
NOTE:  You do NOT need to remove old versions
from your hard disk anymore.  Csound/Perf now just
looks for the most recent(ly created) version of
its partner and talks to that one.  If this beta 
version is not working properly for you, you will 
need to remove both "CSound" and "Perf" applications
from your computer to use older Csound versions.

Thank you and enjoy.

=======================================
WHAT'S HERE
=======================================
Csound3.484beta.sit
	- new beta versions of Csound and Perf
Docs_csRef_&_Examples
	- new Csound Manual PPC (word)
	- csRef 3.47
	- Csound Manual 3.47 (docMaker)
	- old Example orc/scos
MrTweaky.sit.hqx 
	- app to convert anal files to ASCII
csRef68k.sea.hqx
Older_Versions/
	- older Perf and Csound versions
source/ 
	Mr Tweaky source
=======================================
KNOWN BUGS/INCOMPLETE FEATURES
=======================================
Documentation and Examples:
- has not yet been brought up todate.

Perf:
- Sometimes playback may cut off the last fraction of a
	second of the sound or (more likely and less serious)
	"hangs" for a moment after playback or when user hits 
	the transport then might give a slight "sputter"
	(problems with new OS -- will need work to fix)
- Transport is sometimes sluggish.
- RT Audio has not been tested!!!
- PostScript file write of graphics either does not
	work or writes only the first table???
- cant copy from listing window/Edit menu disabled
- Progress/Profile feature currently disabled

Front End:
- Sometimes Graphics submenu doesnt appear. (???)
- Reset All Options/Prefs does not update open windows
- Default Dirs by button flashes when appears, and if 
	dialog is already open stays in background.
- If Direct Rendering and you start CSound,
	project window doesnt open by default.
- "Synthesizing" output file name automatically might 
	sometimes replace a filename user already typed in.
	(could make this an option..)
	
=======================================
CHANGES FROM LAST VERSION
=======================================
Perf:
- reconciliation with canonical(fFitch) code
  (with tons of changes/bug fixes -- see his release notes)
- changed about box and version numbers
- changed default window placements
- output window makes sure it is inside current screen size
- put in a hack in sound playback to prevent cutting off the
	end of the sound.  makes transport seem sluggish. and still
	doesnt remove the bug sometimes!!!
- listing file now created and still have output window display
- added file and edit menus
- various flag letter changes to be compatible with canonical
	sources (see below)	
- Changed file creator type to SoundHack, since we like tom 
	MUCH better than Digidesign - plus seems the only other app
   	to support AIFC-floating point.
- Fixed RT MIDI crash

Front End:
- make listing file "double-click-able" to open
	with the text editor and fixed bugs with selecting
	directory to be created.
- made project window have a "zoom" mode that
	only shows orc/sco/output and generate button.
- made a small button (lower/middle left) to "zoom"
	in and out of this view mode
- added a "View Files in Text Editor" command in the
	File menu.
- updated look to smaller fonts/ rearranged
	graphic placements all around.
- fixed bug "safety" overwrite feature contaminated
	SFDIR
- changed PVANAL to Max 65536 frame size and default hopsize
	to 64
- added progress/profile window so:
- eliminated "heartbeat" option
- made 32-bit float selection and SDII and WAV selection
	enable/disable popups according to whats possible.
- chaged color
- reworded "rescale" options, "render" and "sample size"
- changed default window placement
- made UTILS, Gen Prefs, and Directory dlogs modeless
- moved options out of preference window and into general
	prefs dlog since most dealt with text editor/post
	processsor which were in the gen pref window.
- changed about box and version numbers
- Put all Graphics options in a submenu
- added unsigned char sample size
- moved "Terminate on MIDI track end" option to MIDI dlog
- removed "Scot" option as it is no longer supported
- made output soundfile extension relate to header type
	(*.aiff, *.aifc, *.snd. *.wav)
- changed some of the default options/settings
- ???  (we kind of stopped documenting 
		these things for a while)

=======================================
NOTE TO DEVELOPERS AND USERS OF
OTHER FRONT END "LAUNCHERS"
=======================================
We have completely consolidated our sources and canonical 3.484 source. 
To do this, we had to change some of our Mac-Specific command 
line flags.  If you are a developer of a front end "launcher" 
that uses "Perf" you may have to change your application to 
accommodate.  The Mac-Specific flags are now:

-X fnam		Sound File Directory
-q fnam		Sound Sample-In Directory
-Q fnam		Analysis Directory
-V N		Number of chars in screen buffer for output window
-E N		Number of tables in graphics window
-p			Play after rendering
-e			Rescaled floats as shorts to max amplitude
-w			Record and Save MIDI input to a file
-y N		Enables Progress Display at rate N seconds
				or for negative N, at -N kperiods
-Y N		Enables Profile Display at rate N in seconds
				or for negative N, at -N kperiods
-- fnam		log output to file ("listing" file)

=======================================
TO DO (short term)
=======================================
- save window locations
- save user options in pref file rather
	than the application
- enable progress/profile (get code from dave)
- progress/profile on utils
- add user able to set creator of generated files
- cancel on score generation
- make output filename extension an option
- get perf to stop w/ cmd-period
- get perf playback play/stop with space bar?
- make score optional
- compile 68k version
- add a "sndinfo" button next to outputfile
- have option to not show output window at all
	(only to listing)???
- have project/orc files differences transparant
	
=======================================
TO DO (long term)
=======================================
- separate windows for dispfft and display
- try to patch "dribble" output to a file to
	output in the front end instead




matt ingalls
mingalls@concentric.net



Date1998-08-04 20:56
From"Matt J. Ingalls"
Subjectircam
the only benefit i can see is IRCAM *supports* floating point..
AIFF doesnt - AIFC does (but is not "official" - Madole/Erbe 
just "made it so") - and im not sure what the story is behind WAV floats
(???)

but at least on the mac end, the only apps i know of that use IRCAM are
file converter ones...

matt

Date1998-08-05 12:51
Fromsombrero@sympatico.ca
SubjectRe: ircam
At 3:56 PM -0400 8/4/98, Matt J. Ingalls wrote:

>but at least on the mac end, the only apps i know of that use IRCAM are
>file converter ones...

Soundhack and, of course, Audiosculpt.

Date1998-08-05 17:56
Fromtolve
SubjectRe: ircam
in soundhack when using cross synthesis, it is recommended that file format
of Next 32 bit floating point be used to deal with extreme dynamic range of
files that are output, which incidentally can be played by soundhack on
mac. and they can of course also be converted to AIFF 16 bit or whatever.
does csound somehow prescale output to reduce the need to use a 32 bit
floating point format for output file in similar processes?

tolve

>the only benefit i can see is IRCAM *supports* floating point..
>AIFF doesnt - AIFC does (but is not "official" - Madole/Erbe
>just "made it so") - and im not sure what the story is behind WAV floats
>(???)
>
>but at least on the mac end, the only apps i know of that use IRCAM are
>file converter ones...
>
>matt





Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa18052;
          5 Aug 98 16:55 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa07686;
          5 Aug 98 16:55 BST
Received: (qmail 14229 invoked from network); 5 Aug 1998 15:55:48 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 5 Aug 1998 15:55:48 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (QAA04139); Wed, 5 Aug 1998 16:51:18 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 5 Aug 1998 16:51:07 +0100
Received: from mail.infohouse.com [206.30.88.4] by hermes via ESMTP (QAA12246); Wed, 5 Aug 1998 16:51:06 +0100 (BST)
Received: from [208.151.41.102] by milhouse.infohouse.com
          (Post.Office MTA v3.5.1 release 219 ID# 141-53521U2500L250S0V35)
          with ESMTP id com; Wed, 5 Aug 1998 11:43:05 -0400
X-Sender: ic11748@mail.infohouse.com
Message-Id: 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 5 Aug 1998 11:56:12 -0500
To: csound@maths.ex.ac.uk, jpff@maths.bath.ac.uk, 
    "Matt J. Ingalls" 
MMDF-Warning:  Parse error in original version of preceding line at UK.AC.Bath.maths.stork
From: tolve 
Subject: Re: ircam
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

in soundhack when using cross synthesis, it is recommended that file format
of Next 32 bit floating point be used to deal with extreme dynamic range of
files that are output, which incidentally can be played by soundhack on
mac. and they can of course also be converted to AIFF 16 bit or whatever.
does csound somehow prescale output to reduce the need to use a 32 bit
floating point format for output file in similar processes?

tolve

>the only benefit i can see is IRCAM *supports* floating point..
>AIFF doesnt - AIFC does (but is not "official" - Madole/Erbe
>just "made it so") - and im not sure what the story is behind WAV floats
>(???)
>
>but at least on the mac end, the only apps i know of that use IRCAM are
>file converter ones...
>
>matt





Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa18066;
          5 Aug 98 16:57 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa07794;
          5 Aug 98 16:56 BST
Received: (qmail 14317 invoked from network); 5 Aug 1998 15:57:02 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 5 Aug 1998 15:57:02 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (QAA24666); Wed, 5 Aug 1998 16:54:00 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 5 Aug 1998 16:53:48 +0100
Received: from ella.mills.edu [144.91.3.20] by hermes via SMTP (QAA24053); Wed, 5 Aug 1998 16:53:46 +0100 (BST)
Received: (qmail 26093 invoked by uid 1964); 5 Aug 1998 08:47:34 -0700
Date: Wed, 5 Aug 1998 08:47:33 -0700 (PDT)
From: "Matt J. Ingalls" 
To: Richard Dobson 
cc: csound@maths.ex.ac.uk
Subject: Re: ircam
In-Reply-To: <35C83030.89DF2485@cableinet.co.uk>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

 > has been doing this for years (We also 'made it so').In my copy of the
AIFF
>  documentation V1.2, it is stated sxplicitly that the samplesize can be
anything
> from 1 to 32, so the only ambiguity is whether that could be a 32bit int - what
> are people doing on the Mac these days?. With WAV, Microsoft recently published

	my understanding was that AIFF didnt contain a "MaxValue" chunk, 
and although this was not in AIFC either - AIFC was more "openended" where
Dave could create a one... Is the WAV implementation the same?

	i havent looked on the other platforms, but on the Mac port we
have a format-type flag that will generate sound in floats then
automatically normalize to shorts.  is this on other platforms? and if
not, - it would be easy enough to include in the source if people wanted
it...
matt



Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa18223;
          5 Aug 98 18:46 BST
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa13467;
          5 Aug 98 18:46 BST
Received: (qmail 6824 invoked from network); 5 Aug 1998 17:46:43 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by mercury.bath.ac.uk with SMTP; 5 Aug 1998 17:46:43 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (SAA02376); Wed, 5 Aug 1998 18:35:50 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 5 Aug 1998 18:35:40 +0100
Received: from mail-out-0.tiac.net [199.0.65.247] by hermes via ESMTP (SAA10671); Wed, 5 Aug 1998 18:35:39 +0100 (BST)
Received: from mail-out-4.tiac.net (mail-out-4.tiac.net [199.0.65.16])
	by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id NAA06457
	for ; Wed, 5 Aug 1998 13:35:36 -0400 (EDT)
	(envelope-from raistlin@tiac.net)
Received: from raistlin.tiac.net (p238.tc19a.metro.MA.tiac.com [207.60.68.239])
	by mail-out-4.tiac.net (8.8.7/8.8.7) with SMTP id RAA09454
	for ; Wed, 5 Aug 1998 17:35:40 GMT
	(envelope-from raistlin@tiac.net)
Message-Id: <3.0.5.32.19980805133100.007d9800@tiac.net>
X-Sender: raistlin@tiac.net
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 05 Aug 1998 13:31:00 -0400
To: csound@maths.ex.ac.uk
From: nad 
Subject: Zak opcodes on PC?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk


 I've been mucking around with the Zak opcodes, or attempting to, I've been
getting some illegal opcode errors. I was wondering if all of these opcodes
work on the PC, or if for some reason they have not been implemented.
Thanks for the help,

 Dan



Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa18673;
          5 Aug 98 21:50 BST
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa21486;
          5 Aug 98 21:50 BST
Received: (qmail 13659 invoked from network); 5 Aug 1998 20:50:48 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by mercury.bath.ac.uk with SMTP; 5 Aug 1998 20:50:48 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA11923); Wed, 5 Aug 1998 21:47:49 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 5 Aug 1998 21:47:37 +0100
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (VAA06480); Wed, 5 Aug 1998 21:47:37 +0100 (BST)
Received: (qmail 8128 invoked from network); 5 Aug 1998 19:39:15 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.143)
  by jaguars with SMTP; 5 Aug 1998 19:39:15 -0000
Message-ID: <35C8C316.1ED18350@cableinet.co.uk>
Date: Wed, 05 Aug 1998 21:39:50 +0100
From: Richard Dobson 
Organization: Composers Desktop project
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: "csound@maths.ex.ac.uk" 
Subject: floats v ints (was: Re: IRCAM format)
References:  <35C74808.5143D9E6@charlieb.com> <35C82894.7321635A@qsure.demon.co.uk> <35C7D370.815CA4E3@charlieb.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

An important distinction needs to be made between floats as a general
calculation vehicle, and floats as the storage format for a soundfile. 
In the latter case, values are expected to be normalized, i.e betweeen +1.0 and
-1.0. This makes it effectively equivalent in precision to 24bit fixed-point
ints (e.g as used in Motorola 56K dsps). The 8 bits of the exponent allow for
overflow, but this can quite quickly lead to loss of precision. Problems can
arise for example when adding a very small number to a very large number. You
have a floating point, indeed, but only 24bits of precision. Sonic Foundry, for
example, are careful to describe SoundForge as doing '24bit processing',  in
distinction to the use of 32bit ints - which if treated as fractional fixed
point gives you more precision than floats. So programmers cannot in fact
entirely afford to disregard scaling issues, whichever format they are using.

On the 32bit x86 processor, in any event, calculations are typically done in
64bit doubles, where precision is less of a problem (and the fpu in fact uses
80-bit doubles internally).

Richard Dobson



Charles Baker wrote:
> 
> Ben Jefferys wrote:
> 

> Exactly: only floating point gives you full usage of word, no matterwhat
> the absolute value of the  sample:within limits, of course, but
> *practically*
> it gives better results ! Even if we're talking short floats, no longer
> than the
> int formats, the results are often quite noticably better: if only because
> darn few
> of us make sure that all samples input and output are scaled to use all of
> the
> word. And this brings up another advantage of F.P.:  when int sounds are
> used,
> one has to be extremely careful in combining them, scaling the input
> samples
> to assure that you don't overflow. This is not a worry with float samples:
> 
> they can be combined freely & without concern over the absolute value of
> the result,
> and then scaled/converted into ints to play. CLM and jpff's WinCsound (for
> example) both
> provide this as a way to synthesize your sound, a way many experienced
> composers
> prefer. Try it , you'll like it!


Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa19351;
          6 Aug 98 2:37 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa04390;
          6 Aug 98 2:37 BST
Received: (qmail 6377 invoked from network); 6 Aug 1998 01:37:23 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 6 Aug 1998 01:37:23 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (CAA05775); Thu, 6 Aug 1998 02:33:18 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 6 Aug 1998 02:33:09 +0100
Received: from root@proxy4.ba.best.com [206.184.139.15] by hermes via ESMTP (CAA08466); Thu, 6 Aug 1998 02:33:07 +0100 (BST)
Received: from charlieb.com (IDENT:baker@baker.vip.best.com [206.86.232.121])
	by proxy4.ba.best.com (8.9.0/8.9.0/best.out) with ESMTP id SAA15072
	for ; Wed, 5 Aug 1998 18:31:50 -0700 (PDT)
Message-ID: <35C8A584.801461F9@charlieb.com>
Date: Wed, 05 Aug 1998 18:33:40 +0000
From: Charles Baker 
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.34 i586)
MIME-Version: 1.0
To: "csound@maths.ex.ac.uk" 
Subject: Re: floats v ints (was RE: IRCAM format)
Content-Type: multipart/mixed; boundary="------------D91972ACCA4D8E935452B112"
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

This is a multi-part message in MIME format.
--------------D91972ACCA4D8E935452B112
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Indeed, float as storage format gives same resolution as 24-bit fixed
point
ints....but it is just this normalzation that occurs in correctly moving

from int formats output by most A/D's and synth progs. to float that is
the great advantage. If one never examines the sounds one uses and
generates,
to assure that one is using the full word size available, each operation

that outputs int values (no matter the internal processing resolution)
can and does worsen the quantization error. This is not the case if
one outputs floats, then normalizaes the result. I have simple shells
scripts
using sox that convert to float and normalizes the result for my
soundfiles.
If disk space is a worry, *then* one can convert to int format, and
still
maintain as high a  degree of quality as one can in that particular word
size.
Such practices also make mixing a *lot* more intuitive...all files will
at least
respond to similar scaling ("mix amp") values in a similar, and more
predictable way.
And , yes, adding two *un-normalized* float values can give ridiculous
results:
but working with normalized floats is simply superior
in my experience, especially when one is working with a great many tools

...
yep 24 bit int DSP *if done correctly* is clean... but for most of us,
working with normalized floats is both a simplfication and an
improvement
in sonic quality.

Perhaps someone disagrees?
CharlieB--
*********************************************
Charlie Baker              baker@charlieb.com
"We die with the dying:
 See, they depart, and we go with them.
 We are born with the dead:
 See, they return, and bring us with them."
T.S.Eliot, Four Quartets: Little Gidding,V
*********************************************


--------------D91972ACCA4D8E935452B112
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: baker@shell11.ba.best.com
Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12])
	by shell11.ba.best.com (8.9.0/8.9.0/best.sh) with ESMTP id PAA24291
	for ; Wed, 5 Aug 1998 15:07:17 -0700 (PDT)
Received: from shell11.ba.best.com (root@shell11.ba.best.com [206.184.139.142])
	by proxy1.ba.best.com (8.9.0/8.9.0/best.in) with ESMTP id PAA22251
	for ; Wed, 5 Aug 1998 15:05:18 -0700 (PDT)
Received: (from baker@localhost)
	by shell11.ba.best.com (8.9.0/8.9.0/best.sh) id PAA23937
	for baker@charlieb.com; Wed, 5 Aug 1998 15:04:40 -0700 (PDT)
Date: Wed, 5 Aug 1998 15:04:40 -0700 (PDT)
From: Charles Baker 
Message-Id: <199808052204.PAA23937@shell11.ba.best.com>
To: baker@charlieb.com
Subject: fwd
X-Rcpt-To: baker@charlieb.com

Indeed, float as storage format gives same resolution as 24-bit fixed point
ints....but it is just this normalzation that occurs in correctly moving
from int formats output by most A/D's and synth progs. to float that is
the great advantage. If one never examines the sounds one uses and generates,
to assure that one is using the full word size available, each operation
that outputs int values (no matter the internal processing resolution)
can and does worsen the quantization error. This is not the case if
one outputs floats, then normalizaes the result. I have simple shells scripts
using sox that convert to float and normalizes the result for my soundfiles.
If disk space is a worry, *then* one can convert to int format, and still
maintain as high a  degree of quality as one can in that particular word size.
Such practices also make mixing a *lot* more intuitive...all files will at least
respond to similar scaling ("mix amp") values in a similar, and more 
predictable way.
And , yes, adding two un-normalized float values can give rediculous values:
(sp! sorry, no editor & I bet this doesn't even make the list...I'm not
on my normal isp.) but working with normalized floats is simply superior
in my experience, especially when one is working with a great many tools 
...         
yep 24 bit int DSP *if done correctly* is clean... but for most of us,
working with normalized floats is both a simplfication and an improvement
in sonic quality.
 
Perhaps someone disagrees?      
CharlieB


--------------D91972ACCA4D8E935452B112--



Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa20097;
          6 Aug 98 12:15 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa03243;
          6 Aug 98 12:15 BST
Received: (qmail 14 invoked from network); 6 Aug 1998 11:15:13 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 6 Aug 1998 11:15:13 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (MAA07948); Thu, 6 Aug 1998 12:12:16 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 6 Aug 1998 12:12:06 +0100
Received: from root@bohm.anu.edu.au [150.203.21.88] by hermes via ESMTP (MAA21513); Thu, 6 Aug 1998 12:11:59 +0100 (BST)
Received: from [150.203.14.13] (snagglepuss.anu.edu.au [150.203.14.13])
	by bohm.anu.edu.au (8.8.8/8.8.8) with SMTP id VAA17365
	for ; Thu, 6 Aug 1998 21:10:58 +1000 (EST)
Date: Thu, 6 Aug 1998 21:10:58 +1000 (EST)
Message-Id: <199808061110.VAA17365@bohm.anu.edu.au>
To: csound@maths.ex.ac.uk
From: Arne Hanna 
Subject: Another Query About The Book
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Hi there folks.  I was wondering when/if Richard Boulanger's Csound Book is
going to be available.
Cheers
Arne