Hi, On 2025-03-17 at 12:43 -0400, Saul Tobin <saul.james.to...@gmail.com> wrote: > I haven't had a chance to look at your code. Your project sounds > interesting – I'll try to make some time.
It is in very early stages of development. I need to get LilyPond import working first and then see how I will represent music expressions. > 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." Yes, I use a custom book handler. > > 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. Thank you! I got inclusion of the original init file working with the following code. IMHO it feels like a very crude hack. Is there a scheme function that would include a LilyPond file in the current context? Code: $(ly:parser-include-string (format #f "\\include \"~a\"" (string-append (ly:effective-prefix) "/ly/init.ly"))) > 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. OK, I'll use a file descriptor. Unfortunately Haskell's portable libraries do not support working with raw file descriptors, so I'll use the `unix` library. > When you say the Scheme printer, are you talking about \displayMusic or > about Guile's built-in printer? I was talking about \displayMusic, as my experience with Guile's `write` has been that it only prints "#<Book>" or "#<Score>" which I considered to be of not much use. > I believe that simply (write foo) where foo > is a ly:music? captures all the available information, including input > locations. It actually does. I was not awareof this. Simple Scheme lists are likely easier to parse. This format produced by write probably is not meant to be machine-readable (for example source file name strings are not quoted). > 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. I see, and this is not the intention of my exporter. I specifically want to inhibit all other output generation. I would actually want to develop this towards a REPL, where a user can interactively enter music expressions and LilyPond would process them in its current context and return a machine-readable representation. This probably is already possible without any changes to LilyPond (using top-repl). Is there a Scheme function that takes an arbitrary LilyPond expression as a string, parses it and returns a music/score/book object? > 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. As I don't understand LilyPond internals very well, I don't know if there is anything else missing in the output of \displayMusic except the source locations, maybe not. -- Aura
