I've forwarded Ian's message from the Frogs mailing list, because I don't
know how to answer his question. I'm sure somebody on -devel will.
Thanks,
Carl
------ Forwarded Message
From: Ian Hulin <i...@hulin.org.uk>
Reply-To: <fr...@lilynet.net>
Date: Sat, 20 Jun 2009 17:25:42 -0600
To: Reinhold Kainhofer <reinh...@kainhofer.com>, <fr...@lilynet.net>
Conversation: [frogs] Re: Patching the output file naming code (Was: thanks
to whomever put this in the LSR...)
Subject: [frogs] Re: Patching the output file naming code (Was: thanks to
whomever put this in the LSR...)
Hi Reinhold,
I've now started doing some work on this, and the big disadvantage with the
current use of #(define output-suffix "whatever") et al. is that they affect
all the files in all \score or \bookpart sections. What I would like to do
is pick up a value of the property from something like a \paper block within
the current \score or \bookpart. Is \paper the right place to put
properties relating to output filenames, or should it be property of \score
itself?
Either
\bookpart {
\header {
blah...
}
\score \with {output-suffix="Allegro"}{
blah...
}
}
Or
\bookpart {
\header {
blah...
}
\score {
\paper {
output-suffix= "Allegro}
}
blah...
}
}
Now how do I pick up a property value from a specific currently active
lilypond block in Scheme? I can pick up the results of #(define
output-suffix "Allegro") by calling ly:parser-lookup. What do I use for
lily property? Below is my latest attempt
(define (get-outfile-name parser base )
(let*
((output-suffix (ly:parser-lookup parser 'output-suffix))
(counter-alist (ly:parser-lookup parser 'counter-alist))
(alist-key '())
(result '())
(output-count (assoc-ref counter-alist output-suffix)) )
(if (string? output-suffix)
(set! alist-key (format "~a-~a" base (string-regexp-substitute
"[^a-zA-Z0-9-]" "_" output-suffix)))
(set! alist-key base))
(set! result alist-key)
;; must be careful: output-count is under user control.
(if (not (integer? output-count))
(set! output-count 0))
(if (> output-count 0)
(set! result (format #f "~a-~a" alist-key output-count)))
(ly:parser-define!
parser 'counter-alist (assoc-set! counter-alist alist-key (1+
output-count)))
result)
)
(define (print-book-with parser book process-procedure)
(let*
((paper (ly:parser-lookup parser '$defaultpaper))
(layout (ly:parser-lookup parser '$defaultlayout))
(base (ly:parser-output-name parser))
(outfile-name (get-outfile-name parser base)) )
(process-procedure book paper layout outfile-name)
))
Cheers,
Ian
}
Reinhold Kainhofer wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Dienstag, 9. Juni 2009 23:29:34 schrieb Ian Hulin:
>
>
>>
>> Hi Reinhold,
>> I'm having a look at seeing if I can pick up the work Marek Klein did on
>> -devel. It covered amending the coded generating output file suffixes
>> to allow users to code user-specified names as the suffix. It changes
>> the function print-with-book in file lily-library.scm so one of the
>> internal variables uses a Scheme alist.
>>
>> How much more work would it be to implement Patrick's suggestion below?
>>
>>
>
>
> Almost none, see below for a consistent proposal.
>
>
>
>>
>> But it would be nice to have an option to override the file-name for
>> any arbitrary book. Something like
>>
>> \book {
>> \paper {
>> output-file-name = "Blah"
>> }
>> \score {
>> ...
>> }
>> }
>> .
>> .
>> .
>>
>> As I understand it, the above would allow allow you to have a file
>> called something like "mozsym40.ly" and use
>> \paper {
>> output-file-name="SinfoniaK550"
>> }
>> to generated SinfoniaK550.pdf, .png, .mid, .midi or whatever.
>>
>>
>
>
> That would not be hard to implement (if you look at the print-with-book code,
> you'll see that currently the file name is concatenated from base and suffix.
> You'd have to add another check and not use the base name for this). However,
> it will be a little harder to make this system consistent and easy to use.
>
> Currently, we have:
> basename-suffix(-nr)
> where the number will become optional with the patch.
>
> Of course, one can add another layout variable 'output-basename, which will be
> used instead of the basename (so the suffix will still be used), however, in
> this case the numbering within suffixes will not be ideal. You can then get:
>
> mybase1-suffix
> mybase1-suffix-2
> mybase2-othersuffix
> mybase2-suffix-3
>
> I.e. the numbering will be only within each suffix, even if it is for a
> different
> basename...
>
> The alternative is to use the basename-suffix combination as the key in the
> alist to look up the naming. This would probably be the ideal way.
>
> So, if you really want to generalize the naming even further, I would propose:
> - -) A layout variable 'output-basename (default: the input file name, like
> now)
> - -) A layout varialbe 'output-suffix (default: empty)
> - -) The naming will then be: basename-suffix[-nr] (or basename[-nr] if no
> suffix is
> set), where the numbering is done like in the almost-finished patch, only that
> the key will not only be the suffix, but the complete "basename-suffix" string
> (or
> if no suffix is set, then "basename" will be the key).
>
> This way, the user has complete control over the output file naming, while the
> behavior without explicit settings stays the same as it is now.
>
> Oh, and it might be a good idea to move the code to determine the file name
> out
> of print-with-book and into a separate function, which is called from the let
> block in print-with-book.
>
> Cheers,
> Reinhold
>
> - --
> - ------------------------------------------------------------------
> Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
> * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
> * http://www.fam.tuwien.ac.at/, DVR: 0005886
> * LilyPond, Music typesetting, http://www.lilypond.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFKL+qZTqjEwhXvPN0RAgltAKDCcUb63j8uH9EWVIIW0AT9qAb27ACfUAv1
> WTVtj9dSe0MHV6VJR8JrJRk=
> =yugo
> -----END PGP SIGNATURE-----
>
> ______________________________________________
> This email has been scanned by Netintelligence
> http://www.netintelligence.com/email
>
>
>
------ End of Forwarded Message
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
