This question ultimately devolves to, Does it sound good? since we are (I
hope) ultimately about music here.

Two pieces of anecdotal evidence:

I bought cables from Radio Shack to run sound from my Korg M1 to my mixer.
The synthesizer sounded fine. A little later I got some similar cables from
a musical instrument store and tried them also. Believe it or not, there was
an immediately perceptible muting of the highs with the Radio Shack cables.
The synthesizer didn't sound fine with the Radio Shack cables any more. I
couldn't believe it myself.

I used to record all my Csound pieces using CD quality soundfiles (44.1 KHz
16 bit samples). I have only the sound card that came with my PC, and it
only goes up to 48 KHz 16-bit samples. When Csound and Cool Edit became able
to handle float samples, I recorded some of my favorites Csound pieces with
float samples at 48 KHz. Again, there was an immediately perceptible
increase in detail and transparency in the sound, in spite of the fact that
the sound card driver is converting the floats back to 16 bit ints.

I know, as a programmer, that 64 or 80 bit double-precision floats will
incur fewer rounding errors than 32 bit floats. As a result of the above
experiences, I am prepared to hope, or even believe, that doing all DSP
multiplications in Csound with 64 or 80 bit floats instead of 32 bit floats
will result in an immediately perceptible increase in detail and
transparency, and a clear lowering of the noise floor.

As a musician, I must tell you that in Csound patches I hear noise and
harmonic distortion that impart a slightly metallic quality to the sound in
comparison with some other synthesis code that I have used or written. (This
is not to say that Csound sounds bad - this is a very slight difference).

I also know, as a programmer, that using fewer and more standard data types
in a large body of code makes it easier to build and to maintain.

Finally, on some platforms, 64 or 80 bit floating-point operations are
faster than 32-bit operations, which may be translated to and from the
larger format anyway.

The cache hit of larger data is a real problem, but I do not think it
outweighs the above.



-----Original Message-----
From: Ross Bencina 
To: csound@maths.ex.ac.uk 
Date: Saturday, June 05, 1999 9:47 AM
Subject: Re: Higher numerical precission in Csound


>Michael Gogins writes:
>
>>I again move for the canonical Csound build to use double-precision
>floating
>>point numbers for all real numbers. I would add also to use 32-bit signed
>>ints for all integers (unless there is a need for 64 bits).
>
>
>
>The usual way to do this would be to typedef a custom type which would be
>used in all code where precision is critical. e.g.
>
>#ifdef CS_DOUBLE_PRECISION
>
>typedef double real_t;
>
>#else
>
>typedef float real_t;
>
>#endif
>
>I can imagine situations where wholesale replacement of floats with real_ts
>would probably break the code ( scanf() parameters for instance ). So even
>if the canonical build moved to doubles, someone would have to work out
>where this was safe or not - which means you may as well make it work both
>ways with a typedef.
>
>Ross.
>
>[ Of course you could use templates :) ]
>

In message <002701beaf6b$04f9e500$79d496c0@Realizer.ngt.sungard.com>you write:
>This question ultimately devolves to, Does it sound good? since we are (I
>hope) ultimately about music here.
>
>Two pieces of anecdotal evidence:

     [ ... evidence elided ... ]

did you try a double blind test for this ? i was talking to a guy from
Analog Devices at MIT a couple of weeks ago, and he had lots of great
stories about anecdotal evidence like this that mysteriously
evaporated when subjected to double blind testing. He was quite bitter
about various "audiophiles" who reject such testing.

>The cache hit of larger data is a real problem, but I do not think it
>outweighs the above.

actually, it might depending on your use of Csound. if you use it
primarily for real-time synthesis, the cache hit will turn into a real
problem, by limiting what can be done in a given control cycle.  if
you use it for non-RT synthesis, it isn't so much of a problem.

however, it was partly for these reasons that I use a typedef
throughout Quasimodo called "Number", and also try to avoid the
*printf() and *scanf() functions. I have aimed to be able to recompile
to use double precision by just redefining Number to be a double
rather than a float.

--p

> This question ultimately devolves to, Does it sound good? since we are (I
> hope) ultimately about music here.

I agree. If speed is the main issue, one really should consider some other
program.


> Finally, on some platforms, 64 or 80 bit floating-point operations are
> faster than 32-bit operations, which may be translated to and from the
> larger format anyway.

Atleast in the (VERY OLD) MC68881/882 series, all calculations are performed
using the 80-bit format anyway, so on my computer with very small caches,
it won't be any slower with doubles! =)

But then again.. If one really cares about speed to sacrify fidelity, then
one should upgrade their computer or move to another program to render
sounds.





My vote is then:

 If it's possible, the best thing would probably be to have a compile-time
 variable to select dobules or floats.

 If it's NOT possible, I vote for using doubles instead of floats.


// Anders











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05706;
          6 Jun 99 17:24 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qfiM-0002Cx-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 17:24:02 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA17993); Sun, 6 Jun 1999 17:21:49 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 17:21:38 +0100
Received: from usamail.texasonline.net [208.207.16.31] by hermes via ESMTP (RAA14517); Sun, 6 Jun 1999 17:21:37 +0100 (BST)
Received: from nmol.com (unverified [208.221.109.22]) by usamail.texasonline.net
 (Vircom SMTPRS 4.0.179) with ESMTP id ;
 Sun, 6 Jun 1999 11:22:39 -0500
Message-ID: <375A9FEB.ED0B2C7@nmol.com>
Date: Sun, 06 Jun 1999 10:21:01 -0600
From: Mike Berry 
X-Mailer: Mozilla 4.5 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: paul winkler 
CC: Csound 
Subject: Re: Higher numerical precission in Csound
References: <199906050227.TAA15674@screech.weirdnoise.com> <37594939.A062C5D3@intercom.es> <375976C4.95BE31B2@seanet.com> <3759900D.A13EF973@intercom.es> <37599550.B173A200@ulster.net> <3759E122.25250928@nmol.com> <375A070E.927B590D@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

	Of course I should have specified software.  Also, for many DSP's 24
bit is a native format (e.g. Motorola).
paul winkler wrote:
> 
> 
> "No one" as long as you're talking about computer software only; I
> wasn't. Sorry if that wasn't clear. It's my understanding that quite a
> lot of digital audio hardware, such as Yamaha's digital mixers, uses
> 24-bit integer calculations for most (all?) of the signal path. The
> results are generally considered to be quite good.

-- 
Mike Berry
mikeb@nmol.com
http://www.nmol.com/users/mikeb










Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05738;
          6 Jun 99 17:53 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qgBK-00031u-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 17:53:58 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA11961); Sun, 6 Jun 1999 17:52:00 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 17:51:48 +0100
Received: from front5.grolier.fr [194.158.96.55] by hermes via ESMTP (RAA09888); Sun, 6 Jun 1999 17:51:47 +0100 (BST)
Received: from club-internet.fr (ppp-171-71.villette.club-internet.fr [195.36.171.71])
	by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA11630
	for ; Sun, 6 Jun 1999 18:51:45 +0200 (MET DST)
Message-ID: <375AA840.34BC441A@club-internet.fr>
Date: Sun, 06 Jun 1999 18:56:34 +0200
From: KH 
Reply-To: karmha@club-internet.fr
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: "csound@maths.ex.ac.uk" 
Subject: midi-real time
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Hello
    I'm new to the list
I'm a composer, and 'been working with Csound about one year.
Using OpenMusic to write scores. OpenMusic is a CommonLisp interactive
environement for computer assisted composition
developed at IRCAM,  I've written & ported a library for this purpose.
I'm also working on another lib for writing orchestras. (The libraries
are a collection of functions).
   I would like to ask if it is possible to "patch" a midi keyboard  and
have Csound playing in realtime. Can somebody please send an example of
orc&score which is able to do that.
    Thank you very much.
    1 good Csounding

        Karim











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05750;
          6 Jun 99 17:57 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qgEl-00031z-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 17:57:31 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA10444); Sun, 6 Jun 1999 17:55:27 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 17:55:16 +0100
Received: from smtp1.mindspring.com [207.69.200.31] by hermes via ESMTP (RAA18307); Sun, 6 Jun 1999 17:55:15 +0100 (BST)
Received: from Realizer (user-2ive262.dialup.mindspring.com [165.247.8.194])
	by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id MAA12221;
	Sun, 6 Jun 1999 12:55:07 -0400 (EDT)
Message-ID: <001201beb03d$8a27a460$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: paul winkler , Csound 
Cc: Josep M Comajuncosas , 
    Sean Costello 
Subject: Re: Higher numerical precission in Csound
Date: Sun, 6 Jun 1999 12:56:01 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Let's introduce some evidence to this discussion.

It is simply not true that Csound's internal precision equals or exceeds
that of professional audio gear. This may be true of some semi-professional
gear, but it is not at all true of really high-end gear.

At the high end, the Otari Advanta system, to pick one off the Web, uses 40
bit samples internally for 24-bit input and output. The Studer mixing
consoles such as the D950 do the same. To pick another off the Web, the Sony
DPSV55 signal processing unit offers 20 bit inputs and outputs but uses 52
bit samples internally. Note too that Microsoft's DirectSound software
explicitly allows for 64-bit sample sizes.

In other words, professional audio practice is to use at least 40 bit
samples internally, which is far better than Csound.

At the semi-professional level, the Yamaha 01V mixer has 20 bit inputs and
outputs but uses 32 bit samples internally. Similarly, the Mackie Digital
8-Buss mixer uses 24 bit inputs and outputs but 32 bit samples internally.

As the above evidence indicates, it has been a common practice for decades
in professional digital audio hardware and software to use internal sample
sizes far in excess of the input and output sample sizes. Even the
semi-professional gear follows this practice, only at a lower level of
precision.

The human ear has a precision of somewhere between 24 and 32 bits. Assume
that the digital audio samples coming into a system are 32 bits. Only a few
arithmetic operations are required to introduce audible noise and blurring
into the signal. If, however, 64 or 80 bit samples are used, dozens of
operations can be performed without the noise floor cutting into the 32 bits
of the input signal. As a result, there will be no audible degradation of
the signal by round-off errors. Even if only 24 bits of precision are coming
into the system, it will only take a dozen or so operations to raise the
noise floor. This is not a great deal of filtering or mixing, and makes it
very clear why professional gear tends to shoot for at least 40 bits.

If Csound were to follow standard professional audio engineering practice,
it would support its 32 bit inputs and outputs with 64 or 80 bit internal
samples.

-----Original Message-----
From: paul winkler 
To: Csound 
Cc: Josep M Comajuncosas ; Sean Costello

Date: Saturday, June 05, 1999 5:25 PM
Subject: Re: Higher numerical precission in Csound


>I would like to throw my hat in as one of those who DON'T want
>double-precision computation to be the default. It's worth noting that
>Csound's internal precision equals or exceeds that of extraordinarily
>expensive "pro audio" software and hardware (a signal path that
>maintains at least 24 bits of integer precision from start to end is
>considered quite good; speed is always a concern, so probably most
>commercial software systems don't use doubles except for rare cases that
>really require it, and maybe not even then).
>
>I understand that some folks want more precision for some purposes, and
>they should have it, but not at the expense of everything running slower
>on most of the hardware in existence. I think a compile-time type
>selection would get us all what we want.
>
>--Paul Winkler











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05763;
          6 Jun 99 18:02 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qgJq-0002DO-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 18:02:46 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (SAA02741); Sun, 6 Jun 1999 18:00:48 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 18:00:37 +0100
Received: from smtp1.mindspring.com [207.69.200.31] by hermes via ESMTP (SAA15635); Sun, 6 Jun 1999 18:00:36 +0100 (BST)
Received: from Realizer (user-2ive262.dialup.mindspring.com [165.247.8.194])
	by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id NAA30325;
	Sun, 6 Jun 1999 13:00:22 -0400 (EDT)
Message-ID: <002b01beb03e$47b41e00$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: Nathan Day , csound@maths.ex.ac.uk
MMDF-Warning:  Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Subject: Re: Higher numerical precission in Csound
Date: Sun, 6 Jun 1999 13:01:46 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Actually, casting floats to doubles and back is just another place for
round-off errors. The universal practice in DSP software engineering is to
get into the largest sample size that you need at the very beginning, and
stay there until you are done.

-----Original Message-----
From: Nathan Day 
To: csound@maths.ex.ac.uk 
Date: Sunday, June 06, 1999 3:20 AM
Subject: Re: Higher numerical precission in Csound


>I haven't really even looked at the csound code, but from what I understand
>it is only the signal varibles (a-type, k-type, i-type) which are set as
>single precision floats. There is nothing to stop ugens from using doubles
>internally with inputs and output as singles, in fact I asumed that doubles
>were used for filter coefficiants. What advantage would there be in double
>precision signal varibles. The disadvantages would be slower code both from
>the actually precision as well as more (2x) cache misses, and a whole lot
of
>work.
>
>nathand@senet.com.au











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05779;
          6 Jun 99 18:12 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qgSw-000329-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 18:12:10 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (SAA06011); Sun, 6 Jun 1999 18:08:43 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 18:08:32 +0100
Received: from smtp1.mindspring.com [207.69.200.31] by hermes via ESMTP (SAA02265); Sun, 6 Jun 1999 18:08:31 +0100 (BST)
Received: from Realizer (user-2ive3ha.dialup.mindspring.com [165.247.14.42])
	by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id NAA23436;
	Sun, 6 Jun 1999 13:08:27 -0400 (EDT)
Message-ID: <001001beb03f$66b02280$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: karmha@club-internet.fr, csound@maths.ex.ac.uk
MMDF-Warning:  Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Subject: Re: midi-real time
Date: Sun, 6 Jun 1999 13:09:54 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_000D_01BEB01D.DEB38640"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01BEB01D.DEB38640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Here's one. It's for AXCsound and you'll have to edit the command section of
the file to get it work with regular Csound.

-----Original Message-----
From: KH 
To: csound@maths.ex.ac.uk 
Date: Sunday, June 06, 1999 12:54 PM
Subject: midi-real time


>Hello
>    I'm new to the list
>I'm a composer, and 'been working with Csound about one year.
>Using OpenMusic to write scores. OpenMusic is a CommonLisp interactive
>environement for computer assisted composition
>developed at IRCAM,  I've written & ported a library for this purpose.
>I'm also working on another lib for writing orchestras. (The libraries
>are a collection of functions).
>   I would like to ask if it is possible to "patch" a midi keyboard  and
>have Csound playing in realtime. Can somebody please send an example of
>orc&score which is able to do that.
>    Thank you very much.
>    1 good Csounding
>
>        Karim
>

------=_NextPart_000_000D_01BEB01D.DEB38640
Content-Type: application/octet-stream;
	name="RTMidi.csd"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="RTMidi.csd"

PENzb3VuZFN5bnRoZXNpemVyPgo8Q3NPcHRpb25zPgpjc291bmQgLW9kZXZhdWRpbyAtcyAtaCAt
K1gxIC0rSzAgLWIxNTAgLUIxNTAgYzpcUlRNaWRpLm9yYyBjOlxSVE1pZGkuc2NvCjwvQ3NPcHRp
b25zPgo8Q3NJbnN0cnVtZW50cz4Kc3IgPSAyMjA1MAprciA9IDQ0MQprc21wcyA9IDUwCm5jaG5s
cyA9IDIKDQpnYXJ2YnNpZ2wgaW5pdCAwICAKZ2FydmJzaWdyIGluaXQgMAoNCmluc3RyIDE7IHBs
dWNrbWlkaS5vcmMKDQppYW1wICAgICBhbXBtaWRpICAzMjAwMCwgNgppbm90ZSAgICBvY3RtaWRp
CmljcHMgICAgIGNwc21pZGkKaWxmb2RlbCAgPSAuMgppbGZvZGVwdGggPSAuMDA1CmlsZm9mdW5j
ID0gMQppbGZvZnJlcSA9IDIuMDAwCg0Ka2FtcCAgbGluc2VnICAgMCwuMDEsMSwuNSwxLDQsMCwu
MDEsMCAgIAprYW1wMiBsaW5lbnIgICBrYW1wKmlhbXAsIC4wMSwgLjMzMywgLjA1Cg0KdGltb3V0
IDAsIGlsZm9kZWwsIG91dHB1dAogICBrbGZvY3RsIGxpbmVuciAxLC4wNSwuNSwuMDEKICAga3Ju
ZHogcmFuZGkgLjAwNSwxNQogICBrbGZvIG9zY2lsIGtsZm9jdGwqaWxmb2RlcHRoK2tybmR6LGls
Zm9mcmVxKmtsZm9jdGwsaWxmb2Z1bmMKb3V0cHV0OgoNCiAgIGFzaWcxIHBsdWNrIGthbXAyLCBj
cHNvY3QoaW5vdGUgKyBrbGZvKSwgaWNwcywgMCwgMQogICBhc2lnMiBwbHVjayBrYW1wMiwgY3Bz
b2N0KGlub3RlICsga2xmbyAtIC4wMDA4KSwgaWNwcywgMCwgMQogICBhc2lnMyBwbHVjayBrYW1w
MiwgY3Bzb2N0KGlub3RlICsga2xmbyArIC4wMDA4KSwgaWNwcywgMCwgMQogICAKICAgYXNpZzQg
cGx1Y2sgICAga2FtcDIsIGljcHMqMywgaWNwcyozLCAwLCAyLDIKICAgCiAgIGFmbHQxIHJlc29u
IGFzaWcxICsgYXNpZzIgKyBhc2lnMywgMTEwLCA4MAogICBhZmx0MiByZXNvbiBhc2lnMSArIGFz
aWcyICsgYXNpZzMsIDIyMCwgMTAwCiAgIGFmbHQzIHJlc29uIGFzaWcxICsgYXNpZzIgKyBhc2ln
MywgNDQwLCA4MAoNCiAgIGFtaXhsIGJhbGFuY2UgLjUqYWZsdDEgKyBhZmx0MiArIDEuNSphZmx0
MyArIGFzaWcxICsgYXNpZzIgKyAuNSphc2lnNCwgYXNpZzEgCiAgIGFtaXhyIGJhbGFuY2UgLjUq
YWZsdDEgKyBhZmx0MiArIDEuNSphZmx0MyArIGFzaWcxICsgYXNpZzMgKyAuNSphc2lnNCwgYXNp
ZzEKICAgCiAgICAgIAogICBvdXRzICBhbWl4bCxhbWl4cgplbmRpbgo8L0NzSW5zdHJ1bWVudHM+
CjxDc1Njb3JlPgpmMSAwIDEwMjQgMTAgMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBTaW5l
CmYyIDAgMTAyNCAxMCAxIC41IC4zIC4yNSAuMiAuMTY3IC4xNCAuMTI1IC4xMTEgICAgICAgICAg
OyBTYXd0b290aApmMyAwIDEwMjQgMTAgMSAwICAuMyAwIC4yIDAgLjE0IDAgLjExMSAgICAgICAg
ICAgICAgICAgIDsgU3F1YXJlCmY0IDAgMTAyNCAxMCAxIDEgMSAxIC43IC41IC4zIC4xICAgICAg
ICAgICAgICAgICAgICAgICAgOyBQdWxzZQpmNSAwIDEwMjQgMTAgMSAwIC4xMTEgMCAuMDQgMCAu
MDIgMCAuMDEyICAgICAgICAgICAgICAgIDsgVHJpYW5nbGUgCmY2IDAgMTI4IDUgMSAxMjggOCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBmb3IgdmVsb2MgdG8gbm9uLWxp
bmVhciBhbXAKZjAgMTAwMAoNCjwvQ3NTY29yZT4KPC9Dc291bmRTeW50aGVzaXplcj4K

------=_NextPart_000_000D_01BEB01D.DEB38640--











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05793;
          6 Jun 99 18:14 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qgVI-0002DR-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 18:14:36 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (SAA06061); Sun, 6 Jun 1999 18:12:37 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 18:12:26 +0100
Received: from front6.grolier.fr [194.158.96.56] by hermes via ESMTP (SAA17536); Sun, 6 Jun 1999 18:12:24 +0100 (BST)
Received: from club-internet.fr (ppp-170-199.villette.club-internet.fr [195.36.170.199])
	by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA28962
	for ; Sun, 6 Jun 1999 19:12:23 +0200 (MET DST)
Message-ID: <375AAD31.C0EBACF4@club-internet.fr>
Date: Sun, 06 Jun 1999 19:17:38 +0200
From: KH 
Reply-To: karmha@club-internet.fr
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: "csound@maths.ex.ac.uk" 
Subject: Re:mid real time
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Thank you very much
But apparently it's a pc file. And i forgot to say that i'm on a mac
(hope it's possible on this platform?)
Anyhow thank you very much











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05822;
          6 Jun 99 18:20 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qgbI-00032N-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 18:20:48 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (SAA17943); Sun, 6 Jun 1999 18:18:35 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 18:18:24 +0100
Received: from sparticus.bright.net [205.212.123.5] by hermes via ESMTP (SAA10358); Sun, 6 Jun 1999 18:18:23 +0100 (BST)
Received: from bright.net (find4-cs-14.dial.bright.net [209.143.26.66])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id NAA03454;
	Sun, 6 Jun 1999 13:18:20 -0400 (EDT)
Message-ID: <375AAE81.268B8343@bright.net>
Date: Sun, 06 Jun 1999 13:23:13 -0400
From: Dave Phillips 
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: karmha@club-internet.fr
CC: "csound@maths.ex.ac.uk" 
Subject: Re: midi-real time
References: <375AA840.34BC441A@club-internet.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

KH wrote:

>    I would like to ask if it is possible to "patch" a midi keyboard  and
> have Csound playing in realtime. Can somebody please send an example of
> orc&score which is able to do that.

Very simple orc/sco for MIDI control:

;;; midi-in.orc

        instr 1

;;; get a MIDI note-number
inum    notnum		  

;;; derive amp value from velocity (?), then scale it
iamp    ampmidi 100*inum  

;;; convert MIDI note number to cps
icps    cpsmidi		  

ifn     =       1
aosc    oscil   iamp,icps*.5,ifn

;;; linenr is often used in MIDI-controlled instruments
;;; since duration is arbitrary at p-time
iris    =       .07
idec    =       .11
iatdec  =       .01
kenv    linenr  1,iris,idec,iatdec

        out     aosc*kenv
        endin

;;; midin000.sco

f1 0 1024 10 1

;;; keep Csound active for 95000 seconds
;;; should be long enough to find whether it works...
f0 95000

e


Under Linux you would use a command-line looking something like this:

    csound -o devaudio -M/dev/midi midi-in.*

assuming you have an already working MIDI and audio system. jpff or
another of the gurus can tell you how to do it on other platforms (SGI,
Windows, Mac, ?).

Btw, you could also drive the instrument with a MIDI file like so:

    csound -o devaudio -F my_foo.mid midi-in.*

Tons of fun await you...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html










Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05911;
          6 Jun 99 19:39 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qhpV-0002EW-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 19:39:34 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA05771); Sun, 6 Jun 1999 19:37:04 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 19:36:52 +0100
Received: from adsl-209-78-185-158.dsl.lsan03.pacbell.net [209.78.185.158] by hermes via ESMTP (TAA08719); Sun, 6 Jun 1999 19:36:51 +0100 (BST)
Received: from screech.weirdnoise.com (localhost [127.0.0.1])
	by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id LAA03933
	for ; Sun, 6 Jun 1999 11:37:32 -0700
Message-Id: <199906061837.LAA03933@screech.weirdnoise.com>
X-Mailer: exmh version 2.0.2
To: Csound 
Subject: Re: Higher numerical precission in Csound 
In-Reply-To: Your message of "Sat, 05 Jun 1999 11:47:54 EDT."
             <002701beaf6b$04f9e500$79d496c0@Realizer.ngt.sungard.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 Jun 1999 11:37:32 -0700
From: Ed Hall 
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Much of the "work" performed by Csound consists of buffering samples
(as tables, delays, A-rate variables, ins and outs, etc.); the 24-bit
mantissa of a float is plenty of resolution for this purpose.  Of the
rest, most calculations aren't precision-sensitive enough to see any
advantage from doubles vs. floats.  A few (e.g. filter coefficients,
long exponential curves) will gain useful accuracy with doubles.  And
there is no doubt a need for doubles in Csound instruments, since much
of applied mathematics is grist for the creative mill when using Csound.
In these cases, doubles should be an option.

But when the question is "whither canonical Csound," I can't see making
such an all-encompassing change with so few proven benefits--and with a
significant performance impact.  The case made for mandating the use of
doubles throughout Csound just hasn't been that strong.

Some respondents here claim that run time speed is only important in live
performance.  I disagree.   I don't know what your working methods are, but
I typically run a given proto-score and orchestra dozens of times in the
process of writing them.  So live, real-time playback is hardly the only
situation where running time is important.  Taking even a 10% hit in run
time is hardly insignificant when a score is already running 5-10 times
slower than real-time.  Perhaps for some of you the first playback is the
last.  I'm just not that good, and there must be at least a few other
Csounders who are similarly ungifted and impatient.

As for the claim that doubles are as fast, or faster, than floats: show
us the numbers--for Csound, compiled with a modern compiler.  Use the
Xanadu benchmark, or similar.

		-Ed













Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05994;
          6 Jun 99 20:47 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qitQ-0002FY-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 20:47:40 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (UAA16904); Sun, 6 Jun 1999 20:45:33 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 20:45:22 +0100
Received: from smtp1.mindspring.com [207.69.200.31] by hermes via ESMTP (UAA11839); Sun, 6 Jun 1999 20:45:21 +0100 (BST)
Received: from Realizer (user-2ive2de.dialup.mindspring.com [165.247.9.174])
	by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id PAA27605;
	Sun, 6 Jun 1999 15:45:19 -0400 (EDT)
Message-ID: <000801beb055$4f855740$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: Csound , Ed Hall 
Subject: Re: Higher numerical precission in Csound 
Date: Sun, 6 Jun 1999 15:46:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

More reasoning based on evidence...

...or the lack of it:

It is known that rounding errors raise the noise floor and blur details in
sounds (pretty STRONG point, if you want to listen to music).

It is known that professional DSP hardware and software immediately get the
signal into a word size significantly larger than the input/output word
size, operate in that domain throughout, and only at the end convert back to
the input/output word size. This is the practice recommended by Microsoft's
DirectX SDK, by the Sound Forge plugin SDK, by Adrian Freed, and by other
experts (pretty STRONG point, if you ever pay any attention to people with
lots of experience in the domain).

To my knowledge, our information about performance degradation in Csound
compiled all double is purely inferential and anecdotal. Such hits as are
reported seem relatively small. It is purely conjectural (i.e. a WEAK point)
at this time that there would be a significant performance degradation.

As a composer, I too work in the way described below, running files over and
over and over and over... to tweak them, and some of them run hours for mere
minutes of music. I want it to go fast too, but the people who end up
listening to music don't give a damn how long it took me to make. So, I end
up taking as much time as it takes... until I just can't improve the sound
any more.

I used to sometimes run files for literally DAYS. Now it never seems to be
more than a few hours. And as time as has gone on, the computer has been
able to run more and more of my thick scores in real time.

I think we all agree that the argument is inconclusive without more
evidence, which in the nature of the case can only come from some sort of
controlled test, which in turn can only come from an all-double Csound.
Since musical quality is more important to me than speed, and I know it is
also more important to many other musicians, I move that Csound be built
(optionally) all double. That helps us sound quality freaks and hurts no
speed freaks.

At that point, we will do tests on various platforms and find out what the
performance picture actually is.

-----Original Message-----
From: Ed Hall 
To: Csound 
Date: Sunday, June 06, 1999 2:40 PM
Subject: Re: Higher numerical precission in Csound


>Much of the "work" performed by Csound consists of buffering samples
>(as tables, delays, A-rate variables, ins and outs, etc.); the 24-bit
>mantissa of a float is plenty of resolution for this purpose.  Of the
>rest, most calculations aren't precision-sensitive enough to see any
>advantage from doubles vs. floats.  A few (e.g. filter coefficients,
>long exponential curves) will gain useful accuracy with doubles.  And
>there is no doubt a need for doubles in Csound instruments, since much
>of applied mathematics is grist for the creative mill when using Csound.
>In these cases, doubles should be an option.
>
>But when the question is "whither canonical Csound," I can't see making
>such an all-encompassing change with so few proven benefits--and with a
>significant performance impact.  The case made for mandating the use of
>doubles throughout Csound just hasn't been that strong.
>
>Some respondents here claim that run time speed is only important in live
>performance.  I disagree.   I don't know what your working methods are, but
>I typically run a given proto-score and orchestra dozens of times in the
>process of writing them.  So live, real-time playback is hardly the only
>situation where running time is important.  Taking even a 10% hit in run
>time is hardly insignificant when a score is already running 5-10 times
>slower than real-time.  Perhaps for some of you the first playback is the
>last.  I'm just not that good, and there must be at least a few other
>Csounders who are similarly ungifted and impatient.
>
>As for the claim that doubles are as fast, or faster, than floats: show
>us the numbers--for Csound, compiled with a modern compiler.  Use the
>Xanadu benchmark, or similar.
>
> -Ed
>
>
>











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06011;
          6 Jun 99 20:55 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qj0v-0002Fg-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 20:55:25 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (UAA03890); Sun, 6 Jun 1999 20:53:20 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 20:53:09 +0100
Received: from vcn.bc.ca [207.102.64.2] by hermes via ESMTP (UAA14115); Sun, 6 Jun 1999 20:53:08 +0100 (BST)
Received: from localhost (philip@localhost)
	by vcn.bc.ca (8.9.2/8.9.2) with ESMTP id MAA17492
	for ; Sun, 6 Jun 1999 12:53:07 -0700 (PDT)
Date: Sun, 6 Jun 1999 12:53:07 -0700 (PDT)
From: Philip Aker 
To: csound@maths.ex.ac.uk
Subject: Re: Higher numerical precission in Csound
Message-ID: 
Composer: Philip Aker
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk


Mike Berry (on floats vs doubles) writes:

} As for which to use, it depends on and should be chosen to 
} match the situation.

} A few years ago I did a bulk search and replace in the csound 
} code for floats and changed them to doubles. I then compiled on 
} a PPC and found that things ran slower, not faster as I 
} expected. I expect that the memory access hit for the cache 
} outweighed the precision-conversion speed increase.


I don't know much about cache factors, but for my money it 
doesn't seem to be as simple as the mass replace described 
above and if one was to do it these days, additional 
considerations like the newer compilers, header files, the 
ordering of function variables, and the Motorola math library 
might yield a different result. I would guess that you compiled 
without CodeWarrior error checking.

Floats versus doubles aside for a moment, I worked extensively 
with the code for Perf a few months ago with the aim of 
providing a 'clean' environment for the Macintosh. I compiled 
with all error checking turned on except for "arithmetic 
conversion" and resolved every compiler error for both C and 
C++ with ANSI strict and require protos (about 5000 errors 
total came up in CodeWarrior). The net result was that the 
sound file generation time from the same orc/sco decreased from 
~16.9 seconds to ~13.9 seconds.

Replacing all instances of 'float' with 'double' would 
additionally require flagging errors for arithmetic conversion 
in order to ascertain where the code would have to be changed 
(or some values cast) to take advantage of the speed edge using 
doubles would give.

Compiling without error checking lets one get away with this 
kind of thing but when looking to shave microseconds off of 
function performance, it's not the best approach.

Unfortunately, there's only one way to check if this is indeed 
the case. Wanna make a guess as to how many arithmetic 
conversion errors will come up? Each one of those contributes 
to sluggish performance.


Basically though, I would agree with your remark from above: 
"As for which to use, it depends on and should be chosen to 
match the situation.", as being especially considerate in 
cross-platform code and would suggest that any such 
implementation be able to be redefined on a case by case basis. 
Which sort of brings up the previously discussed side issue of 
macros being evil.



Philip

...who would spell it 'precision' if he had started the thread.


Philip Aker
Composer, Pianist,
Finale Plugins

Suite 13
1405 West 11 Avenue
Vancouver BC
Canada V6H 1K9

philip@vcn.bc.ca












Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06103;
          6 Jun 99 21:38 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qjgB-0002G9-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 21:38:03 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (VAA12854); Sun, 6 Jun 1999 21:35:29 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 21:35:17 +0100
Received: from out4.ibm.net [165.87.194.239] by hermes via ESMTP (VAA07073); Sun, 6 Jun 1999 21:35:16 +0100 (BST)
Received: from ibm.net (slip-32-101-208-168.dc.us.ibm.net [32.101.208.168]) by out4.ibm.net (8.8.5/8.6.9) with ESMTP id UAA100634 for ; Sun, 6 Jun 1999 20:35:15 GMT
Message-ID: <375ADCA7.8212E4D5@ibm.net>
Date: Sun, 06 Jun 1999 16:40:07 -0400
From: "Job M. van Zuijlen" 
Reply-To: zuijlen@ibm.net
Organization: electona
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound 
Subject: Re: Higher numerical precis[s]ion in Csound
References: <199906061837.LAA03933@screech.weirdnoise.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I would agree that you don't want to make Csound unnecessarily slow,
whether you are working real-time or not.  Apart from speed, I would
like to know what the differences in signal-to-noise ratio are when
using different precisions.  For example, I find reverb far too noisy to
be useful and I wonder if improved precision would improve the noise
floor as well.

Job van Zuijlen










Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06152;
          6 Jun 99 22:15 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qkGk-00035y-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 22:15:50 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (WAA14253); Sun, 6 Jun 1999 22:13:35 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 22:13:24 +0100
Received: from front1.grolier.fr [194.158.96.51] by hermes via ESMTP (WAA16428); Sun, 6 Jun 1999 22:13:20 +0100 (BST)
Received: from club-internet.fr (ppp-163-108.villette.club-internet.fr [195.36.163.108])
	by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA09201
	for ; Sun, 6 Jun 1999 23:13:14 +0200 (MET DST)
Message-ID: <375AE5A4.8E26A7A0@club-internet.fr>
Date: Sun, 06 Jun 1999 23:18:31 +0200
From: KH 
Reply-To: karmha@club-internet.fr
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: "csound@maths.ex.ac.uk" 
Subject: Re: real-time midi
Content-Type: multipart/alternative; boundary="------------806C4159B556AE90243C4637"
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk


--------------806C4159B556AE90243C4637
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Many Thanks
for the help. I have succeded in running real-time midi from a keyboard,

but had some clipping. I beleive it's my machine which is slow (it's a
604 ppc at 120mhz without any soundcard) In fact it's the mac's sound
manager who is managing it all.
  Is it the processor, or the mac's default sound card??
    Anyhow it'sq good to know that you can do lots & lots of stuff
with Csound on any platform with wathever background you have (I mean
experience!)
So long life to Csound!
    Thanks again all of you
    Karim

http://perso.club-internet.fr/karmha/

--------------806C4159B556AE90243C4637
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


Many Thanks

for the help. I have succeded in running real-time midi from a keyboard,

but had some clipping. I beleive it's my machine which is slow (it's
a 604 ppc at 120mhz without any soundcard) In fact it's the mac's sound
manager who is managing it all.

  Is it the processor, or the mac's default sound card??

    Anyhow it'sq good to know that you can do lots &
lots of stuff

with Csound on any platform with wathever background you have (I mean
experience!)

So long life to Csound!

    Thanks again all of you

    Karim

http://perso.club-internet.fr/karmha/

--------------806C4159B556AE90243C4637--











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06178;
          6 Jun 99 22:37 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qkbU-00036B-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 22:37:16 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (WAA01598); Sun, 6 Jun 1999 22:34:36 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 22:34:25 +0100
Received: from adsl-209-78-185-158.dsl.lsan03.pacbell.net [209.78.185.158] by hermes via ESMTP (WAA06742); Sun, 6 Jun 1999 22:34:23 +0100 (BST)
Received: from screech.weirdnoise.com (localhost [127.0.0.1])
	by screech.weirdnoise.com (8.8.7/8.8.7) with ESMTP id OAA04422
	for ; Sun, 6 Jun 1999 14:35:09 -0700
Message-Id: <199906062135.OAA04422@screech.weirdnoise.com>
X-Mailer: exmh version 2.0.2
To: Csound 
Subject: Re: Higher numerical precission in Csound 
In-Reply-To: Your message of "Sun, 06 Jun 1999 12:56:01 EDT."
             <001201beb03d$8a27a460$79d496c0@Realizer.ngt.sungard.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 Jun 1999 14:35:09 -0700
From: Ed Hall 
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Michael Gogins wrote:
> It is simply not true that Csound's internal precision equals or exceeds
> that of professional audio gear. This may be true of some semi-professional
> gear, but it is not at all true of really high-end gear.

Great!  So if you believe that 24-bit, 96Ks/s audio is essential and that
every LSB is sacred, compile Csound with doubles, set sr=96000 and kr=96000,
output in floats or 32-bit ints, and be happy.  But why force this on the
rest of us?

I can easily see why audio gear using fixed-point computation would need
at least 48-bit internal data to avoid overload.  (16-bit level X 24-bit
sample is 40 bits; summing 64 channels of these would need 8 more bits
of overhead; scale only on output.)  Floating point has some real
advantages--a 32-bit float has 254 bits of dynamic range.  And given how
much DSP power a few dollars buys these days, if the chip your mixer is
built on supports 64-bit floating point, why not use it?  In a mixing application, you have cycles to burn.  It looks good on the spec sheet,
anyway.  But is it audibly better than 32-bit floating point?  IMHO, no.

> The human ear has a precision of somewhere between 24 and 32 bits.

Where does this number come from?  And doesn't it conflate resolution
and dynamic range?  The 96dB dynamic range of 16-bit samples is arguably
too small, but that's different than saying that 16-bit resolution is too
small.  There is much less evidence of the latter, and the arguments
I've heard for adding more than a bit or two of resolution have amounted
to hand-waving, at best.

> Assume
> that the digital audio samples coming into a system are 32 bits. Only a few
> arithmetic operations are required to introduce audible noise and blurring
> into the signal.

Where in the (real) world are you going to get 32-bit samples?  Even pro
A/D's only give you 20 bits or so above noise floor (120dB s/n ratio).

> If, however, 64 or 80 bit samples are used, dozens of
> operations can be performed without the noise floor cutting into the 32 bits
> of the input signal.

That's a 192dB noise floor you're talking about, there.

> As a result, there will be no audible degradation of
> the signal by round-off errors. Even if only 24 bits of precision are coming
> into the system, it will only take a dozen or so operations to raise the
> noise floor.

Well, actually, only one, since 32-bit floats have 24-bit mantissas.  But
24 bits represents a 144dB noise floor.  Error estimation for floating-
point calculation is notoriously difficult (dissertations are written on
it), but in the cases of scaling (multiplication) and mixing (addition),
we gain about 1/2 LSB of noise for each operation.  Thus we've lost a bit
less than 6 bits (log2 (100 * 1/2)) after 100 operations.  Our noise floor
is now around 110dB--for any musical purpose, still inaudible; it's way below
the 96dB maximum of a CD (a figure rarely achieved in practice).  And
we've assumed that we're mixing samples of roughly the same level--the
effective noise floor increases if a few signal sources predominate.

> This is not a great deal of filtering or mixing, and makes it
> very clear why professional gear tends to shoot for at least 40 bits.

See my first paragraph--there are other reasons for this.

> If Csound were to follow standard professional audio engineering practice,
> it would support its 32 bit inputs and outputs with 64 or 80 bit internal
> samples.

"Support," yes.  Mandate, no.

I've no more free time for this (or any) discussion at this point.  It's
only my opinion, but I'll let it stand or fall on its merits: there are
few musically justifiable reasons for the general use of 64-bit floating
point in Csound.  On most, if not all, platforms it increases performance
times with little justification.  A few opcodes might be usefully improved
by using it internally, but this should be decided on a case-by-case basis.
Run-time performance matters, for very practical reasons.

And one final opinion: The ultimate test of any feature or change in Csound
should be its utility to the composer, period.

		-Ed












Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06226;
          6 Jun 99 23:18 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qlFi-00036O-00
	for jpff@maths.bath.ac.uk; Sun, 6 Jun 1999 23:18:50 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (XAA08600); Sun, 6 Jun 1999 23:15:24 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 6 Jun 1999 23:15:13 +0100
Received: from smtp4.mindspring.com [207.69.200.64] by hermes via ESMTP (XAA07143); Sun, 6 Jun 1999 23:15:12 +0100 (BST)
Received: from Realizer (user-2ive24u.dialup.mindspring.com [165.247.8.158])
	by smtp4.mindspring.com (8.8.5/8.8.5) with SMTP id SAA06748;
	Sun, 6 Jun 1999 18:15:10 -0400 (EDT)
Message-ID: <001001beb06a$3da380a0$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: Csound , Ed Hall 
Subject: Re: Higher numerical precission in Csound 
Date: Sun, 6 Jun 1999 18:16:34 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

-----Original Message-----
From: Ed Hall 
To: Csound 
Date: Sunday, June 06, 1999 5:37 PM
Subject: Re: Higher numerical precission in Csound


>Michael Gogins wrote:
>> It is simply not true that Csound's internal precision equals or exceeds
>> that of professional audio gear. This may be true of some
semi-professional
>> gear, but it is not at all true of really high-end gear.
>
>Great!  So if you believe that 24-bit, 96Ks/s audio is essential and that
>every LSB is sacred, compile Csound with doubles, set sr=96000 and
kr=96000,
>output in floats or 32-bit ints, and be happy.  But why force this on the
>rest of us?


By asking for a compilation flag, I am not forcing anything on anybody. I am
asking that I and others like me be given the ability to make sounds at
least as precisely as pro gear can. Others will remain free to sacrifice
sound quality, perhaps a degree of sound quality that they are not using,
for working speed.

>I can easily see why audio gear using fixed-point computation would need
>at least 48-bit internal data to avoid overload.  (16-bit level X 24-bit
>sample is 40 bits; summing 64 channels of these would need 8 more bits
>of overhead; scale only on output.)  Floating point has some real
>advantages--a 32-bit float has 254 bits of dynamic range.  And given how
>much DSP power a few dollars buys these days, if the chip your mixer is
>built on supports 64-bit floating point, why not use it?  In a mixing
application, you have cycles to burn.  It looks good on the spec sheet,
>anyway.  But is it audibly better than 32-bit floating point?  IMHO, no.

For Studer, at any rate, the reason for more bits is not to avoid overload -
it's to avoid round-off errors (documentation for 950 mixer).

Some of the pro grear chips are floating point, some are fixed point; some
are in-house custom chips, some are Motorola, TI, or ADI.

>The 96dB dynamic range of 16-bit samples is arguably
>too small, but that's different than saying that 16-bit resolution is too
>small.  There is much less evidence of the latter, and the arguments
>I've heard for adding more than a bit or two of resolution have amounted
>to hand-waving, at best.

I don't think the pro audio business is basing its investment and
engineering decisions on hand-waving. 24 bits at 96 KHz is the emerging pro
standard. It is also the emerging audiophile digital audio standard.


>> Assume
>> that the digital audio samples coming into a system are 32 bits. Only a
few
>> arithmetic operations are required to introduce audible noise and
blurring
>> into the signal.
>
>Where in the (real) world are you going to get 32-bit samples?  Even pro
>A/D's only give you 20 bits or so above noise floor (120dB s/n ratio).


I am hoping to get 32 bit samples that mean something out of Csound. As a
musician, I look forward to being able to compute sounds that even the best
pro gear can't supply. And if my suggestion were followed, I would be able
to do it.

>> If, however, 64 or 80 bit samples are used, dozens of
>> operations can be performed without the noise floor cutting into the 32
bits
>> of the input signal.
>
>That's a 192dB noise floor you're talking about, there.
>
>> As a result, there will be no audible degradation of
>> the signal by round-off errors. Even if only 24 bits of precision are
coming
>> into the system, it will only take a dozen or so operations to raise the
>> noise floor.
>
>Well, actually, only one, since 32-bit floats have 24-bit mantissas.  But
>24 bits represents a 144dB noise floor.  Error estimation for floating-
>point calculation is notoriously difficult (dissertations are written on
>it), but in the cases of scaling (multiplication) and mixing (addition),
>we gain about 1/2 LSB of noise for each operation.  Thus we've lost a bit
>less than 6 bits (log2 (100 * 1/2)) after 100 operations.  Our noise floor
>is now around 110dB--for any musical purpose, still inaudible; it's way
below
>the 96dB maximum of a CD (a figure rarely achieved in practice).

It is well above the audible maximum of a 24 x 96 audiophile DVD.

>> If Csound were to follow standard professional audio engineering
practice,
>> it would support its 32 bit inputs and outputs with 64 or 80 bit internal
>> samples.
>
>"Support," yes.  Mandate, no.


Fine - all I need is support.













Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06280;
          7 Jun 99 0:03 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qlwd-0002HE-00
	for jpff@maths.bath.ac.uk; Mon, 7 Jun 1999 00:03:12 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (AAA13998); Mon, 7 Jun 1999 00:01:15 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 7 Jun 1999 00:01:03 +0100
Received: from out4.ibm.net [165.87.194.239] by hermes via ESMTP (AAA05208); Mon, 7 Jun 1999 00:01:02 +0100 (BST)
Received: from ibm.net (slip-32-101-208-168.dc.us.ibm.net [32.101.208.168]) by out4.ibm.net (8.8.5/8.6.9) with ESMTP id XAA158144 for ; Sun, 6 Jun 1999 23:01:01 GMT
Message-ID: <375AFED1.8523842A@ibm.net>
Date: Sun, 06 Jun 1999 19:05:53 -0400
From: "Job M. van Zuijlen" 
Reply-To: zuijlen@ibm.net
Organization: electona
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound 
Subject: Re: Higher numerical precission in Csound
References: <001001beb06a$3da380a0$79d496c0@Realizer.ngt.sungard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I have been following the professional audio industry for 30 years and
there is hype, occasionally.  I read an interesting analysis about the
24-bit/96-kHz issue the other day (I just have to remember where) in
which it was pointed out that this "improvement" is not addressing one
of the main problems with converting between the digital and the analog
domain.  In order to work with a sample frequency of 44.1 or 48 kHz you
need a steep filter at around 20 kHz.  A steep filter gives you all
kinds of problems with impulse responses, delays, etc.  By using 96 KHz
you could employ a filter that is less steep, but unfortunately that is
not done according to the article, everything is just scaled up.  So you
have a bandwidth up to 40 Khz, but still a lousy filter.

Dynamic range is another issue.  There is a debate among digital
recorder manufacturers about 20 versus 24 bits.  The reason is simple,
and has to do with the thermal stability of your AD converters, in the
same way as there is a limit for audio (pre-)amplifiers, which can
achieve a S/N ration between 120 and 130 dB.  120 dB is around 20 bits,
24 would theoretically give you 144 dB, but you will never achieve that
in the analog domain, unless you remove the last DA stage.

Job van Zuijlen










Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07182;
          7 Jun 99 9:32 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10qupq-0002SM-00
	for jpff@maths.bath.ac.uk; Mon, 7 Jun 1999 09:32:46 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (JAA17870); Mon, 7 Jun 1999 09:29:58 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 7 Jun 1999 09:29:48 +0100
Received: from root@lix.intercom.es [194.179.21.2] by hermes via ESMTP (JAA09319); Mon, 7 Jun 1999 09:29:46 +0100 (BST)
Received: from intercom.es (iv2-235.intercom.es [195.76.206.235]) by lix.intercom.es (8.7.3/8.6.12) with ESMTP id KAA29352; Mon, 7 Jun 1999 10:32:38 +0100
Message-ID: <375B821A.DA8B67CB@intercom.es>
Date: Mon, 07 Jun 1999 10:26:02 +0200
From: Josep M Comajuncosas 
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Sean Costello 
CC: Csound 
Subject: Re: Higher numerical preciSion in Csound
References: <199906050227.TAA15674@screech.weirdnoise.com> <37594939.A062C5D3@intercom.es> <375976C4.95BE31B2@seanet.com> <3759900D.A13EF973@intercom.es> <37599C09.15AF7A9F@seanet.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by exeter.ac.uk id JAA09319
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Thanks all the programmers for enlighting me in this topic. I enjoy seein=
g how passionate can be a
discussion beetween Csounders with a DSP, a programmers or a composers po=
int of view.
When it comes to develop new DSP algorithms, I am rather devoted to Csoun=
d because I am used to it.
Using Matlab would be more powerful but my ultimate goal is to make some =
music of all that.
Anyway my ask for higher precision was not a matter of snobism but motiva=
ted for some real needs. It=B4s
not a question of how it sounds only ... sometimes it may even not work. =
Say exploring the sound
potential of a chaotic system by zooming. The more precision in the numbe=
rs the more zoom precision you
will get. Of course not only in this or that opcode, but in *all* the int=
ernal computations needed.
I use filter2 rather often. Some folks wanted to remove it because it was=
 not immediately useful for
musicians (musicians only need lowpass resonant filters?). I mean, Csound=
 is thought to be a serious
tool for timbral research, as well as a funny sot synth for realtime synt=
hesis. I think higher precision
is enough reasonably necessary sometimes to be implemented in the canonic=
al versions.
It is funny by the other hand to work with 16 bit floats (or they are 32 =
bit?). I remember writing a
compander which, taking advantage of that, could easily degrade a signal =
in interesting ways. Finaly I
got square waves ;-)

My suggestion would be to make high precision optional as a command flag.=
 I also suggest an opcode to
truncate the precision to an arbitrary bit size, it must be quite easy.
Speed? you can always make quick tests with floats and the final renderin=
g at 64bit floats.



Sean Costello wrote:

> What filter types? reson, 1st order, 2nd order? What sorts of coefficie=
nts are needed - calculated
> at i-time, k-time, or a-rate?

Specifically, I=B4m trying to implement a TIIR filter (truncater IIR) whi=
ch involves the use of onepole
unstable filters to get growing exponentials. They are used by Smith to m=
odel flaring ends in wind
instruments. Those filters are extremely sensitive to the numerical preci=
ssion of course. This is why I
started the topic.

> I wonder if higher numerical precision is absolutely essential for phys=
ical modelling.

No it is not of course. But it turns to be necessary for a number of spec=
ific computations. I developed
a doublereed model and I was quite dissapointed with the results in Csoun=
d, because as the reed closes
the dynamic system to be integrated must perform divisions by *very* smal=
l numbers and I though higher
precision could help things to sound (yes ... sound) better!

> the rounding off helped the unstable
> filter design to achieve a steady state.

We talked months ago about the artistic benefits of pseudorandom generato=
rs with a short cycle. This
seems to be a similar topic. But at least as an option high precission se=
ems to me already necessary.

> P.S. You had mentioned buzz in your email; it is worth noting that the =
quadrature oscillator I
> describe could be used to implement buzz without using table lookup. I =
will actually try converting
> the relevant floats to double, just to see what happens.

Hey that sounds cool, keep on working on it!

--
Josep M Comajuncosas
C/ Circumval.lacio 75  08790 Gelida - Penedes
Catalunya - SPAIN
home phone : 93 7792243 / 00 34 3 7792243

Csound page at http://members.tripod.com/csound/

Much of the "work" performed by Csound consists of buffering samples
(as tables, delays, A-rate variables, ins and outs, etc.); the 24-bit
mantissa of a float is plenty of resolution for this purpose.  Of the
rest, most calculations aren't precision-sensitive enough to see any
advantage from doubles vs. floats.  A few (e.g. filter coefficients,
long exponential curves) will gain useful accuracy with doubles.  And
there is no doubt a need for doubles in Csound instruments, since much
of applied mathematics is grist for the creative mill when using Csound.
In these cases, doubles should be an option.

But when the question is "whither canonical Csound," I can't see making
such an all-encompassing change with so few proven benefits--and with a
significant performance impact.  The case made for mandating the use of
doubles throughout Csound just hasn't been that strong.

Some respondents here claim that run time speed is only important in live
performance.  I disagree.   I don't know what your working methods are, but
I typically run a given proto-score and orchestra dozens of times in the
process of writing them.  So live, real-time playback is hardly the only
situation where running time is important.  Taking even a 10% hit in run
time is hardly insignificant when a score is already running 5-10 times
slower than real-time.  Perhaps for some of you the first playback is the
last.  I'm just not that good, and there must be at least a few other
Csounders who are similarly ungifted and impatient.

As for the claim that doubles are as fast, or faster, than floats: show
us the numbers--for Csound, compiled with a modern compiler.  Use the
Xanadu benchmark, or similar.

		-Ed