I'm with you and Matt Ingalls on this. In cases where Csound got screwed up, 
AND it is not crystal clear that backward compatibility is required, we 
should fix the existing opcodes.

OTHERWISE, multiple versions of opcodes will pile up, as indeed they have 
been piling up, and people will keep on using the old bad ones because those 
are the ones they see in the old example code, and the situation will stay 
murky and muffle the power of Csound.

I am a big supporter of backward compatibility -- it has given Csound all 
the power that comes from a tradition and a body of work -- but there are 
reasonable limits. In this case the additional complexity and confusion are 
not worth it.

Regards,
Mike

----- Original Message ----- 
From: "Anthony Kozar" 
To: "Csound Developer list" 
Sent: Wednesday, August 22, 2007 8:12 PM
Subject: Re: [Cs-dev] Inaccuracies in cpspch and cpsoct


> 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

I suggest before any "fixes" are implented, that someone solicit the opinions
of those on the main list.  Many of them don't subscribe to the dev list,
and some of them may or may not have strong opinions about this. 
Personally, I've been using cpspch for a decade, so I'm naturally protective
of my pitches being tampered (tempered) with.

Best,
Jake

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






Michael Gogins wrote:
> 
> I'm with you and Matt Ingalls on this. In cases where Csound got screwed
> up, 
> AND it is not crystal clear that backward compatibility is required, we 
> should fix the existing opcodes.
> 
> OTHERWISE, multiple versions of opcodes will pile up, as indeed they have 
> been piling up, and people will keep on using the old bad ones because
> those 
> are the ones they see in the old example code, and the situation will stay 
> murky and muffle the power of Csound.
> 
> I am a big supporter of backward compatibility -- it has given Csound all 
> the power that comes from a tradition and a body of work -- but there are 
> reasonable limits. In this case the additional complexity and confusion
> are 
> not worth it.
> 
> Regards,
> Mike
> 

-- 
View this message in context: http://www.nabble.com/Inaccuracies-in-cpspch-and-cpsoct-tf4313733.html#a12286616
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