FW: [frogs] Re: Patching the output file naming code (Was: thanks to whomever put this in the LSR...)

[Carl D. Sorensen]

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 <address@hidden>
Reply-To: <address@hidden>
Date: Sat, 20 Jun 2009 17:25:42 -0600
To: Reinhold Kainhofer <address@hidden>, <address@hidden>
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, address@hidden, 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