Le jeudi 30 mars 2023 à 18:31 -0600, Jeff Olson a écrit : > Understood, but, like midi, the first file could (should) still have > been un-suffixed. > And the current mismatch between layout files and midi files is a > good reason for the opposite: > Consider this MWE named MidiMismatch.ly that generates pairs of svg > and midi files: > \version "2.24.1" > #(ly:set-option 'backend 'cairo) > #(ly:set-option 'separate-page-formats 'svg) > #(ly:set-option 'use-paper-size-for-page #f) > #(ly:set-option 'point-and-click #f) > \header { tagline = ##f } > \paper { print-page-number = ##f } > \score { { f' } \layout { } \midi { } } > \pageBreak > \score { { a' } \layout { } \midi { } } > \pageBreak > \score { { b' } \layout { } \midi { } } > The suffices of its generated svg files are **off by one** from the > midi files: > 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch.mid* > 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-1.mid* > 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-2.mid* > 8 -rwxrwxrwx+ 1 J None 6496 Mar 30 17:15 MidiMismatch-1.svg* > 8 -rwxrwxrwx+ 1 J None 6502 Mar 30 17:15 MidiMismatch-2.svg* > 8 -rwxrwxrwx+ 1 J None 6510 Mar 30 17:15 MidiMismatch-3.svg*
I disagree that this can be considered "off by one", for two reasons. * It only happens if you have a sequence of scores that are all separated by a `\pageBreak`, and you separate-page-output. Namely, you are close to trying to generate one SVG and one MIDI file per score. Then why not just make separate \books? * As soon as one of the scores takes more than one page, it breaks the pairing anyway. Comparing a sequence of scores with a sequence of pages when each score may result in several pages is comparing apples with oranges. > > By the way, in addition to simplifying automation (like lilypond- > > book), > The above example shows how this creates an automation nightmare. That's not what I would call a nightmare. What would be a real nightmare would be making it impossible to have separate-page and tall-page output in the same run, doubling the compilation time required to get all the desired outputs. Or adding the -1.svg suffix only for the first page of separate-page output only there is also tall-page output, which would mean you could write a working script using separate-page output, then add tall-page output, and it would break your previous work. > > having -1.svg even on the first page makes it possible to use both > > separate-page-formats and tall-page-formats at the same time. > So I added "#(ly:set-option 'tall-page-formats 'svg)" to the example > above > and it produced MidiMismatch.svg (with three scores) which is what I > assume you mean. > It had no effect on the off-by-one between midi and svg, of course. > Nevertheless, couldn't the suffixing algorithm in all cases still > start with > the un-suffixed named and add suffices only to resolve actual > collisions? > Removing the tall-page-formats line would then have begun with > MidiMismatch.svg > matching MidiMismatch.mid (the note f') and all subsequent files > would also match. See above for why this is not desirable in my book. > And that would also have enabled bookOutputName in my original > example to have > complete control over the whole file name (with only one file per > book). > As it stands, it seems I'd have to use techniques outside of > lilypond, > as David W suggests, in order to correct the filenames. Is that > what you're implying? I don't understand the problem you're having. Is my suggestion of using -dtall-page-formats not sufficient for your use case? If you expect a 1-to-1 mapping between SVG files and MIDI files, you can just put each piece into its own \book, with the \bookOutputName of your choice, and compile it with -dtall-page-formats=svg, and that should give you your desired output files without suffixes. The resulting SVGs will be concatenations of pages (each with its page number for example, just all pages squashed together in the same output file), but you can also use ly:one-page-breaking if you want only one continuous page.
signature.asc
Description: This is a digitally signed message part