This should definitely be changed. It's not backward compatibility, it's they got it wrong in the first place.

The same goes for the constants. They should be stated to the maximum possible precision.

There are probably other relics of the days when computers had 1/1000th the memory and 1/1000th the speed that we now have.

Regards,
Mike

-----Original Message-----
>From: Anthony Kozar 
>Sent: Aug 22, 2007 3:54 PM
>To: New Csound Developer list 
>Subject: [Cs-dev] Inaccuracies in cpspch and cpsoct
>
>I noticed that cpspch and cpsoct use a lookup table for converting to cps.
>This table only allows 8192 divisions per octave and it truncates the index
>to the table instead of rounding the index or interpolating the table
>values.  This can lead to some small but possibly significant inaccuracies
>in common pitches (especially since 8192 is not divisible by 12).
>
>For example, the difference between cpspch(11.07) and
>cpspch(11.00)*(2^(7/12)) is .176 Hz resulting in one beat almost every 5
>seconds when played together.  The example below illustrates the effects on
>sine tones and a more complex tone that should have a static timbre.
>
>Small imprecisions are also present in pitch and other calculations for
>MYFLT == double due to certain constants being defined with too few digits:
>
>#define ONEPT           1.02197486              /* A440 tuning factor */
>#define LOG10D20        0.11512925              /* for db to ampfac   */
>#define LOGTWO      (0.69314718056)
>
>
>Does anyone think this should be changed ?
>
>Anthony
>
>
>
>
>instr 1
>    ifreq  =        cpspch(11.07)
>           print    ifreq
>      
>    aosc   poscil3  4000, ifreq, p4
>           out      aosc
>endin
>
>instr 2
>    ifreq  =        cpspch(11.00) * 1.49830707688  ; 2 ^ (7/12)
>           print    ifreq
>      
>    aosc   poscil3  4000, ifreq, p4
>           out      aosc
>endin
>
>
>
>f1 0 65536 10 1
>f2 0 65536 10 1 1 1 1 1 1
>
>i1 0 10 1
>i2 0 10 1
>
>i1 12 10 2
>i2 12 10 2
>e
>
>
>
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm not comfortable with this idea.  We're talking about making changes to a
large body of legacy compositions and instruments.  Yes, these changes will
be minor.  However, it is often the subtle nuances that give art character. 
Another way to look at this is to think of these "inaccuracies" as micro
temperaments inherent in classic computer music technology.

Instead, I recommend adding new high precision opcodes, that will always opt
for the highest precision available at the time.  For example, pcpspch -
Precision CPS to pitch.

Best,
Jake

---- 
The Csound Blog 
http://www.thumbuki.com/csound/blog  





Michael Gogins wrote:
> 
> This should definitely be changed. It's not backward compatibility, it's
> they got it wrong in the first place.
> 
> The same goes for the constants. They should be stated to the maximum
> possible precision.
> 
> There are probably other relics of the days when computers had 1/1000th
> the memory and 1/1000th the speed that we now have.
> 
> Regards,
> Mike
> 

-- 
View this message in context: http://www.nabble.com/Inaccuracies-in-cpspch-and-cpsoct-tf4313733.html#a12283922
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

While this situation has been around for awhile (I don't know exactly how
long), it appears from a comment in the manual entry for cpsoct that it
originally did the exponential calculation without a lookup table.

I agree that changing the calculation may introduce subtle differences in
some existing works -- most likely in the perceived timbres of sustained
tones -- but in most cases the pitch differences will be imperceptible
because they are less than one cent.  I am worried that if we keep it as is,
the inaccuracies may affect pieces that rely on precise pitch relationships
(although it may not be much of a concern to people working in just
intonation, like myself, since in this case using cpspch and cpsoct does not
make much sense).  It could be very frustrating for a user to spend days
trying to figure out why tones generated by Csound are slightly out-of-tune
with some other software synth ...

One other problem with the table lookup implementation is that pitch
modulation involving these opcodes is always in discrete, fixed-size steps.

My vote is for changing it to be as accurate as possible, or at least
providing a compile-time or run-time flag for switching on greater accuracy
and precision.

Anthony

Steven Yi wrote on 8/22/07 6:18 PM:

> I'm with Jake on this one; while I consider this a flaw, it's also
> been around too long that I think it'd ruin backwards compatibility.
> 
> On 8/22/07, Jacob Joaquin  wrote:
>> 
>> I'm not comfortable with this idea.  We're talking about making changes to a
>> large body of legacy compositions and instruments.  Yes, these changes will
>> be minor.  However, it is often the subtle nuances that give art character.
>> Another way to look at this is to think of these "inaccuracies" as micro
>> temperaments inherent in classic computer music technology.
>> 
>> Instead, I recommend adding new high precision opcodes, that will always opt
>> for the highest precision available at the time.  For example, pcpspch -
>> Precision CPS to pitch.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Of course the cps2pch is not table driven,and uses log/exp directly
==John ffitch

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree completely.  This should be changed.

-dB

On Aug 22, 2007, at 5:25 PM, Michael Gogins wrote:

> This should definitely be changed. It's not backward compatibility,  
> it's they got it wrong in the first place.
>
> The same goes for the constants. They should be stated to the  
> maximum possible precision.
>
> There are probably other relics of the days when computers had  
> 1/1000th the memory and 1/1000th the speed that we now have.
>
> Regards,
> Mike
>
> -----Original Message-----
>> From: Anthony Kozar 
>> Sent: Aug 22, 2007 3:54 PM
>> To: New Csound Developer list 
>> Subject: [Cs-dev] Inaccuracies in cpspch and cpsoct
>>
>> I noticed that cpspch and cpsoct use a lookup table for converting  
>> to cps.
>> This table only allows 8192 divisions per octave and it truncates  
>> the index
>> to the table instead of rounding the index or interpolating the table
>> values.  This can lead to some small but possibly significant  
>> inaccuracies
>> in common pitches (especially since 8192 is not divisible by 12).
>>
>> For example, the difference between cpspch(11.07) and
>> cpspch(11.00)*(2^(7/12)) is .176 Hz resulting in one beat almost  
>> every 5
>> seconds when played together.  The example below illustrates the  
>> effects on
>> sine tones and a more complex tone that should have a static timbre.
>>
>> Small imprecisions are also present in pitch and other  
>> calculations for
>> MYFLT == double due to certain constants being defined with too  
>> few digits:
>>
>> #define ONEPT           1.02197486              /* A440 tuning  
>> factor */
>> #define LOG10D20        0.11512925              /* for db to  
>> ampfac   */
>> #define LOGTWO      (0.69314718056)
>>
>>
>> Does anyone think this should be changed ?
>>
>> Anthony
>>
>> 
>> 
>>
>> instr 1
>>    ifreq  =        cpspch(11.07)
>>           print    ifreq
>>
>>    aosc   poscil3  4000, ifreq, p4
>>           out      aosc
>> endin
>>
>> instr 2
>>    ifreq  =        cpspch(11.00) * 1.49830707688  ; 2 ^ (7/12)
>>           print    ifreq
>>
>>    aosc   poscil3  4000, ifreq, p4
>>           out      aosc
>> endin
>>
>> 
>> 
>> f1 0 65536 10 1
>> f2 0 65536 10 1 1 1 1 1 1
>>
>> i1 0 10 1
>> i2 0 10 1
>>
>> i1 12 10 2
>> i2 12 10 2
>> e
>>
>> 
>> 
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Jake's ideas would work, but in these cases, I don't think that the  
changes will affect the compositions in particularly
noticeable ways, we are not breaking them and they are still running  
as composed (just in slightly better tune) - but rather,
as we are moving to do more micro-tonal work with csound (especially  
on the OLPC), I think we should fix this in the sources.

It's amazing that it took 30 years to catch this bug!

I would like and expect Csound to play in tune.

-dB

On Aug 22, 2007, at 6:11 PM, Jacob Joaquin wrote:

>
> I'm not comfortable with this idea.  We're talking about making  
> changes to a
> large body of legacy compositions and instruments.  Yes, these  
> changes will
> be minor.  However, it is often the subtle nuances that give art  
> character.
> Another way to look at this is to think of these "inaccuracies" as  
> micro
> temperaments inherent in classic computer music technology.
>
> Instead, I recommend adding new high precision opcodes, that will  
> always opt
> for the highest precision available at the time.  For example,  
> pcpspch -
> Precision CPS to pitch.
>
> Best,
> Jake
>
> ----
> The Csound Blog
> http://www.thumbuki.com/csound/blog
>
>
>
>
>
> Michael Gogins wrote:
>>
>> This should definitely be changed. It's not backward  
>> compatibility, it's
>> they got it wrong in the first place.
>>
>> The same goes for the constants. They should be stated to the maximum
>> possible precision.
>>
>> There are probably other relics of the days when computers had  
>> 1/1000th
>> the memory and 1/1000th the speed that we now have.
>>
>> Regards,
>> Mike
>>
>
> -- 
> View this message in context: http://www.nabble.com/Inaccuracies-in- 
> cpspch-and-cpsoct-tf4313733.html#a12283922
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

not sure it would ruin backward compatibility to have the unit play  
in tune and essentially increase the fidelity
of things.

-dB

On Aug 22, 2007, at 6:18 PM, Steven Yi wrote:

> I'm with Jake on this one; while I consider this a flaw, it's also
> been around too long that I think it'd ruin backwards compatibility.
>
> On 8/22/07, Jacob Joaquin  wrote:
>>
>> I'm not comfortable with this idea.  We're talking about making  
>> changes to a
>> large body of legacy compositions and instruments.  Yes, these  
>> changes will
>> be minor.  However, it is often the subtle nuances that give art  
>> character.
>> Another way to look at this is to think of these "inaccuracies" as  
>> micro
>> temperaments inherent in classic computer music technology.
>>
>> Instead, I recommend adding new high precision opcodes, that will  
>> always opt
>> for the highest precision available at the time.  For example,  
>> pcpspch -
>> Precision CPS to pitch.
>>
>> Best,
>> Jake
>>
>> ----
>> The Csound Blog
>> http://www.thumbuki.com/csound/blog
>>
>>
>>
>>
>>
>> Michael Gogins wrote:
>>>
>>> This should definitely be changed. It's not backward  
>>> compatibility, it's
>>> they got it wrong in the first place.
>>>
>>> The same goes for the constants. They should be stated to the  
>>> maximum
>>> possible precision.
>>>
>>> There are probably other relics of the days when computers had  
>>> 1/1000th
>>> the memory and 1/1000th the speed that we now have.
>>>
>>> Regards,
>>> Mike
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Inaccuracies- 
>> in-cpspch-and-cpsoct-tf4313733.html#a12283922
>> Sent from the Csound - Dev mailing list archive at Nabble.com.
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am with Anthony.

On Aug 22, 2007, at 8:12 PM, Anthony Kozar wrote:

> While this situation has been around for awhile (I don't know  
> exactly how
> long), it appears from a comment in the manual entry for cpsoct  
> that it
> originally did the exponential calculation without a lookup table.
>
> I agree that changing the calculation may introduce subtle  
> differences in
> some existing works -- most likely in the perceived timbres of  
> sustained
> tones -- but in most cases the pitch differences will be imperceptible
> because they are less than one cent.  I am worried that if we keep  
> it as is,
> the inaccuracies may affect pieces that rely on precise pitch  
> relationships
> (although it may not be much of a concern to people working in just
> intonation, like myself, since in this case using cpspch and cpsoct  
> does not
> make much sense).  It could be very frustrating for a user to spend  
> days
> trying to figure out why tones generated by Csound are slightly out- 
> of-tune
> with some other software synth ...
>
> One other problem with the table lookup implementation is that pitch
> modulation involving these opcodes is always in discrete, fixed- 
> size steps.
>
> My vote is for changing it to be as accurate as possible, or at least
> providing a compile-time or run-time flag for switching on greater  
> accuracy
> and precision.
>
> Anthony
>
> Steven Yi wrote on 8/22/07 6:18 PM:
>
>> I'm with Jake on this one; while I consider this a flaw, it's also
>> been around too long that I think it'd ruin backwards compatibility.
>>
>> On 8/22/07, Jacob Joaquin  wrote:
>>>
>>> I'm not comfortable with this idea.  We're talking about making  
>>> changes to a
>>> large body of legacy compositions and instruments.  Yes, these  
>>> changes will
>>> be minor.  However, it is often the subtle nuances that give art  
>>> character.
>>> Another way to look at this is to think of these "inaccuracies"  
>>> as micro
>>> temperaments inherent in classic computer music technology.
>>>
>>> Instead, I recommend adding new high precision opcodes, that will  
>>> always opt
>>> for the highest precision available at the time.  For example,  
>>> pcpspch -
>>> Precision CPS to pitch.
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:
> This should definitely be changed. It's not backward compatibility, it's they got it wrong in the first place.

Not that either.
An old aops.c version (dated Oct 1986, in a distro zip file from 1988) has this:

cpsoct(p)
 register EVAL *p;
{
	*p->r = pow((double)2.,(double)*p->a) * onept;
}

- so the switch to table lookup has already changed performance at some later time.

The cpsoctinit table existed in 4.10 from 2001 and in "unofficial" csound 3.50 from 1999.
Anyone who has intermediate versions can look up exactly when it happened,
but perhaps you can decide on the issue anyway.

	re

 
> -----Original Message-----
>> From: Anthony Kozar 
>> Sent: Aug 22, 2007 3:54 PM
>> Subject: [Cs-dev] Inaccuracies in cpspch and cpsoct
>>
>> I noticed that cpspch and cpsoct use a lookup table for converting to cps.
>> This table only allows 8192 divisions per octave and it truncates the index
>> to the table instead of rounding the index or interpolating the table
>> values. 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net