Hi Istvan, Maybe I am misunderstanding then what you are proposing, but let me state how I understand it and please correct me if I have misinterpreted. It seems that you believe that UDO's as implemented, both in internal code and in the context of user coding, needs to be reworked, and would like to see the old UDO system replaced with something newer and cleaner but possibly less expandable. The idea of having a legacy compilation mode with the old parser for compiling older orchestras but not to offer the UDO system in the new parser would mean a break in compatibility on the user-level. That means a loss of time invested in writing UDO's and systems dependent on them and would require rewrites for users to work with whatever system is proposed to replace UDO type functionality. Having the old parser around for older projects seems to not make very much sense to me at a release stage except for during the period of working on the new parser and the time in transition. Otherwise, for older projects, one can simiply use an older version of Csound if there's going to be such a break, and development could be focused on the new parser. >From a user standpoint, I have grown to find the opcode-endop syntax to be fine in usage and fairly easy to understand. Am I mistaken in understanding that you have ideas for a different syntax to do UDO type functionality? As for internal code, I think refactoring the underlying code makes sense always as long as the interface is maintained, but I'm hesitant about changes to the system that would break existing orchestra and pedagogy. Would it be possible to find a solution that could satisfy the UDO internal code being rewritten while maintaining the public interface of using opcode-endop and all that, or are there technical limitations to the opcode-endop syntax which prevents that in your opinion? Thanks, steven On 5/16/06, Istvan Varga wrote: > On Tuesday 16 May 2006 19:30, Steven Yi wrote: > > > I can understand not wanting to work on it considering the latest > > emails, but I would think that UDO code shouldn't be labeled > > deprecated as I believe it has become a core part of the Csound > > experience and I think should absolutely be supported for any new > > parser. > > I do not think it is necessary to support them in a new parser if the > old one is still kept as an option for use with legacy orchestra code. > I also like the idea of reworking the current UDO code to be simpler > even if at the expense of worse performance and closing the way for > future improvements. In any case, I think warning messages about the > use of these opcodes not being recommended should be added that are > printed at initialization time. > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net