Thanks for the clarification. I do non-real-time music and am not as
concerned for rendering speed as real-time users. If you say most Csound
users are real-time users, it makes sense to set the default MYFLT type
back to float, and I will do that. I am certainly not prepared at this time
for the work it would take to proceed opcode by opcode.

Original Message:
-----------------
From: Richard Dobson richarddobson@blueyonder.co.uk
Date: Mon, 23 Feb 2004 11:57:58 +0000
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4108] Re: Major commits to Csound 5


The current MYFLT code makes no distinction here. If you build the doubles 
version of Csound, ~everything~ becomes double - both asigs and internal 
computations, unless explicitly marked "float". Similarly, in the floats
build, 
asigs are floats, but so is any internal processing not explicitly marked
as 
"double". The MYFLT symbol make Csound  easy to compile, but I question
whther 
it is the best engineering solution.

There is no single "ultimate criterion". We have both aesthetic and
engineering 
issues. Either may dominate at one time or another. Quality of sound is one 
requirement, efficiency and processing speed is certainly another. No doubt
the 
user would like maximum flexibility to make their own choices.  My argument
is 
that floats are sufficient for asigs and ftables (as Gabriel notes, even
floats 
may be too memory-intensive in some cases), but that internally opcodes, 
especially recursive ones, may well need to use doubles. Relying so much on
a 
single ubiquitous MYFLT has confused the issue somewhat.

The engineering criterion requires us to find the most inexpensive solution
that 
is musically acceptable to the user. This has become a much more priority
issue 
now that users expect to use Csound in real-time, most of the time.

Many in the Pro-Audio worlds still claim that software plugins, even in
double 
precision, offer lower audio quality than equivalent hardware based systems 
using 48bit internal precision, on 24bit words. Just using double precision
may 
hide a problem, rather than solve it, at the cost of a much greater memory 
overhead, where not also CPU overhead. So where there is an audio quality 
problem, I suggest that we look to fix the opcode in question, not the
whole system.

Note that with proper headers, analysis files, like soundfiles, can be
floats or 
doubles independently of Csound itself. It is perfectly possihble to have a 
double PVOC_EX file, for example, though I have never got around to
implementing 
it yet.



Richard Dobson


Michael Gogins wrote:

> When I said sample format, I meant the internal sample format for
> processing, not the soundfile sample format. In other words, the "double"
> version of Csound versus the "float" version.
> 
> I haven't used pvoc extensively, and not at all in comparisons between
> double and float versions of Csound; my tests concerned my own scos and
orcs
> and things like Trapped and Xanadu.
> 
> Shouldn't the ultimate criterion be the musical ear?
> 
> 



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .