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