I would just like us to give some thought as to which of these alternatives

-- replace opcode names

-- use legacy opcode library

-- replace up to date names with legacy names

is actually LEAST LIKELY TO GET MESSED UP and EASIEST TO MAINTAIN and EASIEST TO USE.

I think the last alternative is the least likely to get messed up and the easiest to maintain, but it is not quite the easiest to use.

Regards,
Mike

-----Original Message-----
>From: Steven Yi 
>Sent: Aug 23, 2007 3:07 PM
>To: Michael Gogins , Developer discussions 
>Subject: Re: [Cs-dev] Inaccuracies in cpspch and cpsoct
>
>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
>
>On 8/23/07, Michael Gogins  wrote:
>> 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
>> 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

This is all beginning to sound to me like more work, more complexity, and
more confusion for a what amounts to a HYPOTHETICAL possibility that making
cpsoct/pch more accurate will actual cause somebody's existing music to
sound different.

I know that I am the one who suggested the possibility, but we are talking
about differences in pitch of about 0.14 cents.  This difference is
certainly not detectable in sequences of notes.  It MAY cause small
differences in beating and timbres when notes (especially with many
overtones) are sounded together, but equal temperament already causes
significant beats to occur in most chords and this small change is likely to
go unnoticed too.

The change is most likely to be noticeable only in combinations of long
sustained tones where the old pitches just happened to create a more lively
sound with stronger beats.  (My example CSD exploited this possibility to
show how much of a problem I think the lookup table is; it is a pretty
unlikely scenario though ...)

I believe the best solution is to make the pitch more accurate, and to
provide no backwards "compatibility" kludges.  I now believe that to provide
such a mechanism complicates Csound unnecessarily and sets a bad precedent.
Some of the other recent changes to Csound (the new random number generator
or the filter changes) are MUCH more likely to produce noticeably different
results (especially the RNG).  We cannot provide alternate sets of opcodes,
extra flags or orchestra syntax, etc. to turn these old versions off and on
without greatly increasing the complexity and manageability of the entire
system.  Already, we have lots of users who have trouble getting the
existing opcode libraries to work and many people cannot compile or install
the system.

The simplest solution for everyone is to keep the version of Csound that you
use to create a piece if you are concerned about future changes.  All recent
versions of Csound will remain publicly available for a long time and John
has kept archives going back a lot further at the Bath site.

Anthony

Michael Gogins wrote on 8/23/07 4:15 PM:

> I would just like us to give some thought as to which of these alternatives
> 
> -- replace opcode names
> 
> -- use legacy opcode library
> 
> -- replace up to date names with legacy names
> 
> is actually LEAST LIKELY TO GET MESSED UP and EASIEST TO MAINTAIN and EASIEST
> TO USE.
> 
> I think the last alternative is the least likely to get messed up and the
> easiest to maintain, but it is not quite the easiest to use.


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

At this point, perhaps the easiest theoretical solution to preserve Csound's
accidental micro temperament is to dump the numbers from the tables to text
files, use gen 23 to read them into a user tables, and then use an UDO for
converting pitch.  A few extra modifications would still be required to the
.orcs from the "detune" generation, which in the grand scheme of things,
isn't that big of a deal.

Is there by any chance that user-defined functions (UDF) are on the table
for future versions of Csound?  From a users standpoint, it would be really
easy if one could just override the builtin functions cpspch/oct with UDFs.

Getting away from cpspch/oct for a moment.  The advantages UDFs would bring
to Csound greatly exceed that particular issue.

I'm just thinking out loud.


Best, 
Jake 

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





Anthony Kozar wrote:
> 
> This is all beginning to sound to me like more work, more complexity, and
> more confusion for a what amounts to a HYPOTHETICAL possibility that
> making
> cpsoct/pch more accurate will actual cause somebody's existing music to
> sound different.
> 

-- 
View this message in context: http://www.nabble.com/Inaccuracies-in-cpspch-and-cpsoct-tf4313733.html#a12312943
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've started the process of preserving the "detuned" version of cpspch.  It's
been awhile since I've done any C programming, so hopefully I'm not missing
a data cast or anything like that.  Here's what I have so far:

http://www.thumbuki.com/csound/files/mailinglist/preserveCPSv0.01.zip


It contains cpspchTable.c, which was built from source code borrowed from
csound 5.06.   I used this to generate multiple lists of data, including the
data stored in cpsocfrc[], and some other files to check frequencies
outputted by cpspch.

Hopefully by the end of the weekend, I'll have an UDO ready for the
soon-to-be alternative tuning system.  From there, I'll start working on the
other opcodes / functions in question.


Best, 
Jake 

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







Jacob Joaquin wrote:
> 
> At this point, perhaps the easiest theoretical solution to preserve
> Csound's accidental micro temperament is to dump the numbers from the
> tables to text files, use gen 23 to read them into a user tables, and then
> use an UDO for converting pitch.  A few extra modifications would still be
> required to the .orcs from the "detune" generation, which in the grand
> scheme of things, isn't that big of a deal.
> 

-- 
View this message in context: http://www.nabble.com/Inaccuracies-in-cpspch-and-cpsoct-tf4313733.html#a12318277
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 do like the idea of UDF's too.  Steven... it would be cool if you  
could make it happen.

-dB

On Aug 24, 2007, at 10:57 AM, Steven Yi wrote:

> I brought up this issue about a year ago when I working on the new
> parser.  I won't go into all the detail now as it's probably archived
> on this mailing list, but currently functions really are just single
> arg/single output opcodes.  There's a limitation on what gets counted
> as a function but that could be changed, and it could be made that any
> opcode that satisfies the one in/one out rule could be called as a
> function.  Eventually the limit on args could change as well.
>
> On 8/24/07, Jacob Joaquin  wrote:
>>
>> I agree.
>>
>> At this point, perhaps the easiest theoretical solution to  
>> preserve Csound's
>> accidental micro temperament is to dump the numbers from the  
>> tables to text
>> files, use gen 23 to read them into a user tables, and then use an  
>> UDO for
>> converting pitch.  A few extra modifications would still be  
>> required to the
>> .orcs from the "detune" generation, which in the grand scheme of  
>> things,
>> isn't that big of a deal.
>>
>> Is there by any chance that user-defined functions (UDF) are on  
>> the table
>> for future versions of Csound?  From a users standpoint, it would  
>> be really
>> easy if one could just override the builtin functions cpspch/oct  
>> with UDFs.
>>
>> Getting away from cpspch/oct for a moment.  The advantages UDFs  
>> would bring
>> to Csound greatly exceed that particular issue.
>>
>> I'm just thinking out loud.
>>
>>
>> Best,
>> Jake
>>
>> ----
>> The Csound Blog
>> http://www.thumbuki.com/csound/blog
>>
>>
>>
>>
>>
>> Anthony Kozar wrote:
>>>
>>> This is all beginning to sound to me like more work, more  
>>> complexity, and
>>> more confusion for a what amounts to a HYPOTHETICAL possibility that
>>> making
>>> cpsoct/pch more accurate will actual cause somebody's existing  
>>> music to
>>> sound different.
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Inaccuracies- 
>> in-cpspch-and-cpsoct-tf4313733.html#a12312943
>> 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

Sounds great Jake.  Can't wait.

-dB

On Aug 24, 2007, at 3:20 PM, Jacob Joaquin wrote:

>
> I've started the process of preserving the "detuned" version of  
> cpspch.  It's
> been awhile since I've done any C programming, so hopefully I'm not  
> missing
> a data cast or anything like that.  Here's what I have so far:
>
> http://www.thumbuki.com/csound/files/mailinglist/preserveCPSv0.01.zip
>
>
> It contains cpspchTable.c, which was built from source code  
> borrowed from
> csound 5.06.   I used this to generate multiple lists of data,  
> including the
> data stored in cpsocfrc[], and some other files to check frequencies
> outputted by cpspch.
>
> Hopefully by the end of the weekend, I'll have an UDO ready for the
> soon-to-be alternative tuning system.  From there, I'll start  
> working on the
> other opcodes / functions in question.
>
>
> Best,
> Jake
>
> ----
> The Csound Blog
> http://www.thumbuki.com/csound/blog
>
>
>
>
>
>
>
> Jacob Joaquin wrote:
>>
>> At this point, perhaps the easiest theoretical solution to preserve
>> Csound's accidental micro temperament is to dump the numbers from the
>> tables to text files, use gen 23 to read them into a user tables,  
>> and then
>> use an UDO for converting pitch.  A few extra modifications would  
>> still be
>> required to the .orcs from the "detune" generation, which in the  
>> grand
>> scheme of things, isn't that big of a deal.
>>
>
> -- 
> View this message in context: http://www.nabble.com/Inaccuracies-in- 
> cpspch-and-cpsoct-tf4313733.html#a12318277
> 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