Well, I was thinking of not using the #include functionality at all, and to do the UDODIR parsing after loading the dynamic opcode libraries. My thought was that whatever code is tokenizing and the ORC and translating to templates could simply be called on each file in the UDODIR, with a modification to mark what #includes are processed so as to not process twice (as mentioned in previous email). I don't know if that is easily doable, but that was what I was thinking at least. steven On 8/29/05, Istvan Varga wrote: > Steven Yi wrote: > > > What I was implying was not that the parser should have to parse the > > orchestra and upon finding an unkown opcode to try to load it, but > > rather to automatically load everything in the UDODIR at startup. The > > order of loading is something that I didn't think about, but I think > > would be possible to resolve. I recently built a ClassLoader in Java > > that has to do similar operation of resolving included classes. For > > loading UDO's, it could work in this way: > > I did assume you meant loading all files. > The problem is that parsing the orchestra is done in two separate steps: > the first one is preprocessing (creating a single orchestra in memory as > an array of lines, expanding all #includes and macros, removing ; style > comments, converting CR/CR-LF/LF line endings, etc.), and only after that > is complete, the second stage is tokenization, and converting expressions, > if/then/else/endif, and other high level language features so that in the > end the entire orchestra can be represented as a stream of simple opcodes > (rather like assembly instructions) from which otran() builds instrument > templates. The preprocessor code knows nothing about instruments, opcodes, > or any of the high level syntax in general, but at the same time it is the > only place where including files is possible. Now the question is when and > how the .udo files are to be loaded ? > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net