Again, I completely agree with Matt. Allow me to spell out what I take to be the rationale here, which I think should be Csound policy:

1. Csound is a musical instrument more than it is a museum.

2. Like any other musical instrument, Csound benefits from stability and backward compatibility, which foster the development of a community and a tradition, which in turn increase the power of the instrument. Stability and backward compatibility should be preserved, not only in order to preserve this tradition, but also to make it always possible to re-render older compositions with newer versions of Csound.

3. Backward compatibility should not be allowed to interfere with the correctness of documented functions. If the manual says cpsoct converts linear octaves to frequencies, that is just what it should do, as accurately as possible.

4. Backward compatibility should not be implemented in a way that obscures newer, more powerful features or better implementations of old features. In other words, the "default" feature should be the most correct, and that usually will mean the newest.

5. In cases where (3) and (4) conflict with (2), there definitely needs to be a way to use the older features for the sake of backward compatibility, especially when re-rendering older pieces.

How to achieve (5)? Matt's suggestion would work. 

Another idea is to be able to substitute names in the opcode dispatch table. In other words, if my mother made a piece in 1988 using oldopcodeX which has now been more accurately implemented using newopcodeX, then I can say 'replace newopcodeX with oldopcodeX' and my mother's piece can now be re-rendered using the original oldopcodeX -- without having to change her orchestra code.

I think this would be easier to implement than Matt's suggestion, and more flexible.

It could be done on the command line like this:

--replace-opcode newopcode=oldopcode

Or in the orchestra header like this:

replace oldopcode=newopcode

This only makes sense if the signature of newopcodeX is functionally identical to the signature of oldopcodeX, but of course it would be, or there is no issue of compatibility. 

This scheme might require adding optional or default arguments to some opcodes, and it could mean renaming some opcodes, i.e. renaming the current cpsoct to cpsoctTable or something. But the scheme would work not only with built-in opcodes, but also with plugin opcodes.

Does this work?

Regards,
Mike

-----Original Message-----
>From: matt ingalls 
>Sent: Aug 23, 2007 1:48 PM
>To: Developer discussions 
>Subject: Re: [Cs-dev] Inaccuracies in cpspch and cpsoct
>
>i don't think find/replace to an old score is a great solution and do  
>not like
>making new names for new or old opcodes.   For the RARE cases when a  
>person
>wants to render an old score then there definitely should be a  
>backwards compatibility
>opcode library with the SAME names they can be installed to override  
>the new ones.
>
>i think far more important is having the better code be the most  
>immediate/accessible.
>Having many opcodes that do the same thing but named slightly  
>different (with the
>improved version always having some number tacked on to the end of  
>the name)
>is a terrible design IMO.  The recent threads on cpsmidi and this one  
>proves that
>point  -- users do not intuitively use (or even find!) the "improved"  
>versions of the original
>opcodes -- i would think in most cases you would want the improved  
>version to be
>the default!
>
>-m
>
>
>On Aug 22, 2007, at 10:17 PM, 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
>>
>>
>> On 8/22/07, Michael Gogins  wrote:
>>> 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
>>> 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
>>
>
>matt ingalls
>development@gvox.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

Some random thoughts on this.

In a .csd file, there could be an "opcode" tag where any importing,
substitution, or renaming of opcodes can take place.  Here's an example of
some pseudo code.

<opcode>
use "/legacy/5.03/*"  ; use the entire 5.03 opcode library instead of
current library
use "/legacy/5.01/cpspch"  ; use cpspch from 5.01 instead of 5.03
<\opcode>


And then there might be situations where one would want to use different
versions of the same named opcode in the same orchestra.  In those cases, it
might be helpful for users to be able to rename opcodes.  For example:


use "/legacy/4.01/butterlp" as "butterlp401"  ; use and rename butterlp from
version 4.01



It would be highly impractical to force users to have every single version
of Csound installed on their computers in order to use this system.  In
order to make this more efficient, there might be a way to organize legacy
opcodes so that only unique versions are included, rather than having
multiple copies of identical versions.  For example, let's say the opcode
"foo" was introduced in version 4.00 and had it's first upgrade in version
5.00.  If a person specifies 'use "/legacy/4.03/foo"' it would use version
4.00.

This strategy would certainly be all encompassing.  And may be completely
unnecessary, as there might only be a handful of opcodes that are worth
supporting.  Any additions to the legacy library could be made on a
per-request basis.

I'm not sure how feasible and of this is from a developer's standpoint.  So
I hope I'm not talking too much in ignorance.  :)

Best,
Jake

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





Steven Yi wrote:
> 
> As long as there's a way to get the old behavior I'm for it.  For
> something that's been around so many years I think some kind of legacy
> provision is necessary when doing this kind of fix.  I like Matt's
> idea of a legacy library with SAME opcode name versus what I proposed.
>  It'd be simple to create the lib and have it generated in a separate
> place than OPCODEDIR; I think if you include it on the commandline
> --opcode-lib it should override what's picked up in OPCODEDIR (not
> sure exactly).
> 
> We could also add a --legacy flag to csound that will enable or
> disable the liblegacyops.so.  The library could then live with the
> rest of the opcodes in OPCODEDIR. It'd give us a general strategy then
> for the longer term and we could actually do things like Matt
> suggested about moving old semi-redundant opcodes and deprecated
> opcodes to legacyops.  (For me this conversation really is about
> having a strategy for deprecation now).
> 
> steven
> 

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