[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple
From: |
lilypond |
Subject: |
Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books |
Date: |
Thu, 23 Feb 2012 11:58:53 +0000 |
Updates:
Labels: Needs-design
Comment #3 on issue 2343 by address@hidden: Faulty file-naming when
outputting multiple \books
http://code.google.com/p/lilypond/issues/detail?id=2343
I just want to add some context to this issue, and maybe save David some
time investigating.
The idea is any \book block is equivalent (sort of) to an output file,
which is used for all the backend filenames (pdf, midi whatever), and the
\bookOutputName and \bookOutputSuffix work with this in mind. Internally
the C++ code adds an implicit \book declaration at top-level even if the
source code does not use \book.
\bookOutputName and \bookOutputSuffix use a parser variable to store the
values.
I suspect that the problem here may not be assigning the \book declaration
to a variable, but that the code from the OP is effectively nesting \book
declarations, e.g.
AltoBook =
\book {
\bookOutputName "alto"
\new Score { \music }
}
\book { \AltoBook }
I further suspect that doing this is itself working round a restriction, as
coding
\AltoBook without the enclosing \book will cause the parser to throw a
hissy fit.
I would steer clear of making facilities like \bookOutputName and ...suffix
part of \paper or \layout because they are properties of an instance of a
compilation session, and not a particular piece of output. For example,
\bookOutputName affects the resultant name of a midi file, why should this
be controlled by a declaration of in \paper or \layout?
The original suggestion was for these functions to be property settings,
but I couldn't find a home for them as the prevailing opinion was that
properties had to be related in some way to contexts which implied some
sort of link to the music translation process. Output file-names etc. are
a more general beast so I implemented them as functions rather than
properties.
I think you have two related issues here
1) \bookOutputName and \bookOutputSuffix in an outer \book block supersede
definitions from an inner \book block.
2) needing to nest \book blocks is a work-round to allow the parser to
accept \book definitions in a variable. Are there any black magic
incantations we could invoke in the parser to ease the restriction?
Conceptually, having to nest \book blocks is a bit of a nonsense, bearing
in mind \book's relation to output files.
Hope this helps,
Cheers,
Ian Hulin
- Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/22
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/22
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/22
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books,
lilypond <=
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/23
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/23
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/23
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/24
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/25
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/26
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/26
- Re: Issue 2343 in lilypond: Faulty file-naming when outputting multiple \books, lilypond, 2012/02/27