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?


============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Richard Dobson" 
To: "Csound Developers Discussion List" 
Sent: Sunday, February 22, 2004 6:14 PM
Subject: [CSOUND-DEV:4092] Re: Major commits to Csound 5


> There is a very big distinction between ~sample~ format, and internal
processing
> precision. Doubles are certainly good for the internal processing stages
of
> recursive filters and reverbs, but are arguably overkill for just about
> everything else.  pvoc (both streaming and offline) is ~measurably slower~
in
> doubles than in floats, no doubt to a great extent because of cache
problems.
> But I don't discount the necessity for carefully designed benchmark tests
to
> determine the range of differences in speed for specific tasks.
Eliminating the
> possibility of denormal problems reducing the apparent speed difference
between
> floats and doubles will be essential here.
>
> All current plugin architectures (specifically VST, DX and AudioUnits) use
> floats as the sample format for the signal stream. efficient compatibility
with
> these is a priority. What plugins use internally is entirely up to them.
But
> mandating doubles as the default sample format is IMO unnecessary, and
will
> certainly not be faster!
>
> I had thought that requiring two versions of plugin opcodes was always
going to
> be unavoidable; but there probably are several ways it could be done; e.g.
by
> plugins supporting two versions of the opcode, selected at load time.
>
> Richard Dobson
>
>
> Michael Gogins wrote:
>
> > Since Csound is a musical instrument and double sounds better than
float -- 
> > please try it and see if you agree, listen especially to filtered sounds
and
> > high-index FM sounds -- I firmly believe that Csound 5 should be double
by
> > default.
> >
> > There will be problems if people don't agree as to sample format, since
> > plugins must have the same sample size as the host. I don't want to get
into
> > a situation where we have to have plugin32.dll and plugin64.dll for
every
> > opcode.
> >
> > What's the big deal against double? I think float is sheer inertia. Last
> > time I checked the running times on Windows, they were essentially the
same.
> > I think there should be a really compelling reason to stick with float
if
> > some people with trained ears think double sounds better.
> >
>
>

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?
> 
>