What I would suggest in cases like this, is creating new names for the 
existing opcodes, and using the old names for the newer more precise or 
improved opcodes. Then if you are still actively using your patches and need 
them to sound as they do, you can edit them to sound the same as they did 
before. But those who are getting started with Csound, or were not aware 
that there were problems, will experience better sound with the documented 
opcodes.

Regards,
Mike

----- Original Message ----- 
From: "Jacob Joaquin" 
To: 
Sent: Wednesday, August 22, 2007 10:44 PM
Subject: Re: [Cs-dev] Inaccuracies in cpspch and cpsoct


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

Now that John has reminded us of cps2pch, we now know there already exists a
high precision alternative in Csound. Leaving things the way they are might
be the least confusing option for users of Csound. Perhaps a note about
higher precision properties of cps2pch can be added to the entry for cpspch
in the manual.

There is still the issue of cpsoct.  I've never used it myself.  However, I
would still like to be able to render the works of others as accurately as
possible.

It would be interesting to know exactly when these opcodes were converted to
use lookup tables.

Best,
Jake

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





Steven Yi wrote:
> 
> I really dislike breaking backwards incompatibility for something like
> this but I'm also a bit split now on this issue.  I find it very
> important to me that projects render as created originally; I know I'd
> like to render my own projects years from now and have the work render
> as it was created. I often use cpspch as a start to get into a
> frequency area and sometimes tweak by ear, so I imagine it possible to
> hear differences, especially on glissandi between pitches where rates
> of beats are changing.
> 
> However, the opcode is certainly flawed but there may be many pieces
> which were created with this in the ear as the music was written.  If
> we're going to make a non backwards compatible change like this, then
> I would strongly recommend we have a very clear strategy on how to
> reproduce exactly the previous behavior.  In this case though it is
> not a simple answer as a UDO can not be the replacement as this is a
> function we are changing and there are no user-defined functions.  (A
> simple find and replace is not possible as cpspch can often be found
> in a ternary expression such as:
> 
> ipch = (p4 > 16) : p4 : cpspch(p4)
> 
> ).
> 
> So there's not a simple way for this.  Perhaps we should do like
> Michael mentioned and give the old opcode a new name.  We could create
> a legacy opcode library that has exact copies of the old versions of
> opcodes but with clear names, something like "legacy_cpspch".  That
> then would be easy to do a find/replace and can be instructed to users
> to use.  I still dislike that basically all pieces in the first 20
> years of Csound's history may potentially sound different than
> rendered originally though, but perhaps I'm overly worried and the
> difference really won't be noticeable or pleasantly so.
> 
> steven
> 

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

I have been looking at old sources and I think the table-driven cpspch
is not that old.  I think the evidence points to a Gabriel change
(group A1), but not sure of a date.
==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

This discussion seems to have brought up a much larger issue than the
original post intended. I don't often post but there's a first time to
everything.
I am with Steve and Jake on this. The idea of breaking backward
compatibility is a very unpleasant one to my mind. It is very important to
me, and many other composers I'm sure, that my pieces render exactly as they
did when first written.  I also think it is one of the aspects that makes
csound such a powerful tool. Of course Csound needs to evolve and improve,
as it has, thanks to the wonderful work that many on this list have done
over the years and continue to do. However I don't believe that caring about
backward compatibility means living in the past. On the contrary, I believe
it is about ensuring its future.


Jean-Luc



Steven Yi wrote:
> 
> I really dislike breaking backwards incompatibility for something like
> this but I'm also a bit split now on this issue.  I find it very
> important to me that projects render as created originally; I know I'd
> like to render my own projects years from now and have the work render
> as it was created. I often use cpspch as a start to get into a
> frequency area and sometimes tweak by ear, so I imagine it possible to
> hear differences, especially on glissandi between pitches where rates
> of beats are changing.
> 

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