Hi Istvan, On 8/29/05, Istvan Varga wrote: > Do you mean something like INCDIR (although INCDIR can already also be a > list of directories, not just a single directory), but unconditionally > #including all files with .udo extension ? I do not know, though, how > the parser should automatically find the place in the orchestra where > the .udo files need to be included (most likely just before the first > instrument or opcode definition). Perhaps a new preprocessor symbol > can be added that requests #including all .udo's at that place in an > undefined order, but that is not really elegant. 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: 1) grab a listing of the directory contents 2) one by one, open the .udo file and parse any UDO's 3) if an #include is found for another udo, go to that one and start step 2 from there 4) after finishing loading a UDO, mark as loaded so as to skip if encountered again We could start simply by loading any UDO regardless of order with the assumption that UDO's don't depend on each other, then move on to resolving dependencies. I don't think a new preprocessor symbol would be necessary for all of this. If an orchestra uses a UDO that isn't defined either in an #include or is within the UDODIR, then they'll get the standard message that the opcode doesn't exist, which I think would be enough for someone to figure out what is wrong and to ask where to get a UDO file. Users could always package a .udo file with their CSD's if they release it to be sure, and perhaps UDO's #included in a CSD can override any UDO already loaded (is that what happens now, or is there an error for redefining a UDO?) steven ------------------------------------------------------- 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