Hi Aura, I haven't had a chance to look at your code. Your project sounds interesting – I'll try to make some time.
The exporter writes output to stdout. > > I have a few questions/problems: > > 1) First of all, is this a good strategy at all or would there be a better > way > to make LilyPond run a custom export code and prevent it from generating > any > output files itself? I would like my solution to be forwards-compatible > from > LilyPond 2.24 onwards to some extent at least.. At a glance, I think a custom init file is a good approach, assuming you're defining a custom book handler. Check my reply in the recent thread "Generating dependencies for Lilypond." > 2) My init code includes "init.ly" with \include in order to also run > LilyPond's normal initialization logic. But this might fail, if somebody > has > put a file named init.ly in the same directory where the importer is run > (or > where the score file is) (which is very much possible). How could I get the > absolute path of the original LilyPond init file so that I can inlude it > directly? ly:effective-prefix is what you're looking for I believe. 4) If some LilyPond score which I try to import, prints something to stdout, > my export routine will fail. Is there any better way to work around this > except to write my exporter's output to a temporary file (which I'd rather > avoid). IMHO stdout is not a great strategy, because while LilyPond writes its log output to stderr, Guile writes to stdout by default. Personally, I would write instead to a file. If your use case wants to use this for inter-process communication, you can always have the user code specify a file descriptor instead of a persistent file. This is what LilyPond's own outputter does. 5) Would there be any chance to get this functionality to stock LilyPond > (maybe as a separate backend)? This differs from LilyPond's already > existing > Scheme printer mostly in that my solution tries to export every possible > detail from the LilyPond source (including source locations). > When you say the Scheme printer, are you talking about \displayMusic or about Guile's built-in printer? I believe that simply (write foo) where foo is a ly:music? captures all the available information, including input locations. If this were going to be included in LilyPond, you would want a design other than an alternate init file, in order to support generating this auxiliary output in parallel with print and/or MIDI, similar to the way lilypond-book aux files are generated. But I'm mildly skeptical whether it's a good idea to introduce yet another data serialization format. If Guile's default write format and LilyPond's displayMusic format aren't adequate, it might be better to see if there are enhancements to the existing displayMusic code that would serve your purposes. Saul
