I continue to point out that having float and double for Csound is a waste
of our time and effort when double sounds better than float, and float
computes no faster than double in most cases. 

Original Message:
-----------------
From: steven yi stevenyi@csounds.com
Date: Wed, 10 Nov 2004 09:16:32 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:5428] Re: Loadable fgens


I'd also vote for putting the values with ENVIRON rather than the other 
options as it seems the logical place to find the information.  I'm 
curious though if we'll need another environment variable for loading 
dynamic fgens ("FGEN_DIR" ?) or if we should rename OPCODE_DIR to 
CSLIBDIR or something along those lines, as perhaps we'll have other 
loadable objects in the future.

I think I remember Istvan doing something like CSLIBDIR and also a 
CSLIBDIR64, one for opcode libs compiled for floats and the other for 
opcode libs compiled with doubles.  I think that would be something to 
implement in csound5 as well, or at least would be interested to discuss 
other alternatives here.

steven

gogins@pipeline.com wrote:

>I suggest you make ftp and e members of ENVIRON as this will hasten the
>work of making Csound multiply instantiable.
>
>Original Message:
>-----------------
>From:  jpff@codemist.co.uk
>Date: Wed, 10 Nov 2004 11:54:58 +0000
>To: csound-dev@eartha.mills.edu
>Subject: [CSOUND-DEV:5426] Re: Loadable fgens
>
>
>I have committed the code to ftest.c which defines a totally dull fgen
>and it seems to work.  Currently I am using option 2 (Add ftp and e as
>arguments to all loaded fgens).  Still open to improvements.
>==John ffitch
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>
>
>  
>


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

Well, let's make a case for either staying with the two or moving 
forward in cs5 with only doubles.  And it's perhaps something we should 
get feedback from the users list as well.  I remember discussing this 
before but without any resolution, and I think we should figure out what 
is going to address all of our concerns in the best way and commit to that.

Some concerns I can think of:

-speed differences - need a metric of some sort (Would most likely 
affect those doing realtime)

-compatibility - older pieces may not sound exactly as before without 
changes, especially if using direct amplitude values (i.e. "aout oscil 
20000, 440, 1"), besides the precision difference affecting the sound;

	-possible resolutions

		-can reset 0dbfs to 32768 when compiling with Doubles (to cover the 
amplitude differences)

		-can use CS4 (which source should then be kept around specifically for 
maintaining older csound projects)

	
-Analysis Files: I know that for Convolution, different sets of files 
are needed if using floats vs. doubles, Richard Dobson mentioned that 
all utilities probably need a look over to be used with doubles and 
doubles for convolution, while works, wasn't planned

-external opcodes: are there any concerns in using external libraries 
that may only support floats?  or is it enough to just cast to double in 
the plugin?

Any other possible conflicts and resolution proposals?

gogins@pipeline.com wrote:
> I continue to point out that having float and double for Csound is a waste
> of our time and effort when double sounds better than float, and float
> computes no faster than double in most cases. 
> 
> Original Message:
> -----------------
> From: steven yi stevenyi@csounds.com
> Date: Wed, 10 Nov 2004 09:16:32 -0800
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:5428] Re: Loadable fgens
> 
> 
> I'd also vote for putting the values with ENVIRON rather than the other 
> options as it seems the logical place to find the information.  I'm 
> curious though if we'll need another environment variable for loading 
> dynamic fgens ("FGEN_DIR" ?) or if we should rename OPCODE_DIR to 
> CSLIBDIR or something along those lines, as perhaps we'll have other 
> loadable objects in the future.
> 
> I think I remember Istvan doing something like CSLIBDIR and also a 
> CSLIBDIR64, one for opcode libs compiled for floats and the other for 
> opcode libs compiled with doubles.  I think that would be something to 
> implement in csound5 as well, or at least would be interested to discuss 
> other alternatives here.
> 
> steven
> 
> gogins@pipeline.com wrote:
> 
> 
>>I suggest you make ftp and e members of ENVIRON as this will hasten the
>>work of making Csound multiply instantiable.
>>
>>Original Message:
>>-----------------
>>From:  jpff@codemist.co.uk
>>Date: Wed, 10 Nov 2004 11:54:58 +0000
>>To: csound-dev@eartha.mills.edu
>>Subject: [CSOUND-DEV:5426] Re: Loadable fgens
>>
>>
>>I have committed the code to ftest.c which defines a totally dull fgen
>>and it seems to work.  Currently I am using option 2 (Add ftp and e as
>>arguments to all loaded fgens).  Still open to improvements.
>>==John ffitch
>>
>>
>>--------------------------------------------------------------------
>>mail2web - Check your email from the web at
>>http://mail2web.com/ .
>>
>>
>>
>>
>> 
>>
> 
> 
> 
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> 

I really think that this depends on the CPU architecture.  On my PowerPC G3,
I was pleasantly surprised to see that Csound 64 took only about 25% longer
to compute Trapped in Convert than normal Csound.  But 25% is not
insignificant in all circumstances.

Reasons that I see to keep both versions:

1.  People with lots of old analysis files lying around might be frustrated
by the lack of compatibility.

2.  Being able to use 32-bit floats while developing a piece and testing
various iterations is likely to save some time, and Csound 64 can generally
be used then for the "final" output.

3.  There are still some users with old machines for which double-precision
performance is likely to be a problem.

4.  Real-time.  (Need I say more about this?)

5.  Pardon the heresy, but I am not sure that I can really hear a
difference.


The only significant reasons that I can see against keeping both are the
effort needed to maintain and opcode plugins.  The maintenance issue seems
negligible as long as people continue to not make assumptions in the code.
And I think it would be OK to distribute a double version as standard if you
wish, as long as those who want to can still compile a float version.

The real problem that I anticipate being a headache is that opcode plugins
must be compiled for one version or the other and that is sure to cause
confusion.  I have already decided to adopt a convention of naming all of
the float libraries that I compile, somethinglib, and all of the double
libraries, somethinglib64.  (Of course, this nomenclature may become more
confusing as 64-bit (integer) CPUs become more commonplace).  Maybe we
should agree upon and publish some standards for all platforms.


Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

On 11/10/04 1:10 PM, gogins@pipeline.com etched in
stone:

> I continue to point out that having float and double for Csound is a waste
> of our time and effort when double sounds better than float, and float
> computes no faster than double in most cases. 

agreed  - processor seed is only getting faster -- if doubles are indeed 
better might as well do this all now rather than later...

> gogins@pipeline.com wrote:
>> I continue to point out that having float and double for Csound is a waste
>> of our time and effort when double sounds better than float, and float
>> computes no faster than double in most cases. 
>> Original Message:
>> -----------------
>> From: steven yi stevenyi@csounds.com
>> Date: Wed, 10 Nov 2004 09:16:32 -0800
>> To: csound-dev@eartha.mills.edu
>> Subject: [CSOUND-DEV:5428] Re: Loadable fgens
>> 
>> 
>> I'd also vote for putting the values with ENVIRON rather than the other 
>> options as it seems the logical place to find the information.  I'm 
>> curious though if we'll need another environment variable for loading 
>> dynamic fgens ("FGEN_DIR" ?) or if we should rename OPCODE_DIR to CSLIBDIR 
>> or something along those lines, as perhaps we'll have other loadable 
>> objects in the future.
>> 
>> I think I remember Istvan doing something like CSLIBDIR and also a 
>> CSLIBDIR64, one for opcode libs compiled for floats and the other for 
>> opcode libs compiled with doubles.  I think that would be something to 
>> implement in csound5 as well, or at least would be interested to discuss 
>> other alternatives here.
>> 
>> steven
>> 
>> gogins@pipeline.com wrote:
>> 
>> 
>>> I suggest you make ftp and e members of ENVIRON as this will hasten the
>>> work of making Csound multiply instantiable.
>>> 
>>> Original Message:
>>> -----------------
>>> From:  jpff@codemist.co.uk
>>> Date: Wed, 10 Nov 2004 11:54:58 +0000
>>> To: csound-dev@eartha.mills.edu
>>> Subject: [CSOUND-DEV:5426] Re: Loadable fgens
>>> 
>>> 
>>> I have committed the code to ftest.c which defines a totally dull fgen
>>> and it seems to work.  Currently I am using option 2 (Add ftp and e as
>>> arguments to all loaded fgens).  Still open to improvements.
>>> ==John ffitch
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> mail2web - Check your email from the web at
>>> http://mail2web.com/ .
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --------------------------------------------------------------------
>> mail2web - Check your email from the web at
>> http://mail2web.com/ .
>> 
>> 
>> 
>> 
>
>