Re: thanks to whomever put this in the LSR...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: thanks to whomever put this in the LSR...

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?

.
.
.
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.

If you were using a file with multiple \bookparts or \score blocks,
1.  should output-file-name in these blocks replace the definition in
the \book \paper block (if present) to produce Allegro.pdf, .midi
or
2.  should it act like #(define output-suffix "Allegro") so you produce
a file SinfoniaK550-Allegro.pdf, .midi etc?  Or
3.  should we have a separate output-file-suffix property to do this
trick, which would be for use only in \bookpart blocks?

I'm trying to get a clear idea of what would be clearest for users
before I send myself cross-eyed looking at the code.

Any opinions/pointers to set this Frog off in the right direction are
welcome.

Cheers,

Ian Hulin


Reinhold Kainhofer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Donnerstag, 4. Juni 2009 01:01:24 schrieb Mats Bengtsson:
>> See
>> http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00833.html
>> and followups for the previous discussion on the topic. As far as I can
>> see, an implementation proposal is already available, just to commit.
>
> Hmm, it seems that this has been completely forgotten... Does anyone have the
> time to put the finishing touches on the patch?
> In particular, get rid of the global var and properly use the variable from
> the parser-lookup, also the comment is no longer valid.
>
> Cheers,
> Reinhold
> - --
> - ------------------------------------------------------------------
> Reinhold Kainhofer, [hidden email], 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)
>
> iD8DBQFKLAEsTqjEwhXvPN0RAlG1AKCEYYXJYUFeCSFTTZkARZ4zBpaHcACdGvkd
> q0WId+UluAUa48LVj+7dAVA=
> =UqgS
> -----END PGP SIGNATURE-----


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: thanks to whomever put this in the LSR...

chip-2
Ian Hulin wrote:

> 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?
>
> .
> .
> .
> 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.
I am a user very interested in the outcome of this as I use multiple
\book in all my songs. Being able to have the naming scheme work out
like this would be great -
filename - Beseme Mucho.ly
output names of separate \books -   Beseme Mucho.pdf .midi etc (the full
score)
                                                       Beseme
Mucho-Tenor.pdf .midi etc
                                                       Beseme
Mucho-Alto.pdf .midi etc
                                                       Beseme
Mucho-Trumpet1.pdf .midi etc
                                                       etc etc
Basically what the system currently does except dropping the -n from the
name and replacing it with the variable the user wants added. I don't
use \bookpart anywhere, just \book. I don't know anything about scheme,
so I won't be able to help there, but I can help with testing if need be.
Anyway, that's just my input, whatever help it may be.
Regards,
Chip W

>
> If you were using a file with multiple \bookparts or \score blocks,
> 1.  should output-file-name in these blocks replace the definition in
> the \book \paper block (if present) to produce Allegro.pdf, .midi
> or
> 2.  should it act like #(define output-suffix "Allegro") so you
> produce a file SinfoniaK550-Allegro.pdf, .midi etc?  Or
> 3.  should we have a separate output-file-suffix property to do this
> trick, which would be for use only in \bookpart blocks?
>
> I'm trying to get a clear idea of what would be clearest for users
> before I send myself cross-eyed looking at the code.
>
> Any opinions/pointers to set this Frog off in the right direction are
> welcome.
>
> Cheers,
>
> Ian Hulin
>
>
> Reinhold Kainhofer wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am Donnerstag, 4. Juni 2009 01:01:24 schrieb Mats Bengtsson:
>>> See
>>> http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00833.html
>>> and followups for the previous discussion on the topic. As far as I can
>>> see, an implementation proposal is already available, just to commit.
>>
>> Hmm, it seems that this has been completely forgotten... Does anyone
>> have the time to put the finishing touches on the patch? In
>> particular, get rid of the global var and properly use the variable
>> from the parser-lookup, also the comment is no longer valid.
>>
>> Cheers,
>> Reinhold
>> - -- -
>> ------------------------------------------------------------------
>> Reinhold Kainhofer, [hidden email],
>> 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)
>>
>> iD8DBQFKLAEsTqjEwhXvPN0RAlG1AKCEYYXJYUFeCSFTTZkARZ4zBpaHcACdGvkd
>> q0WId+UluAUa48LVj+7dAVA=
>> =UqgS
>> -----END PGP SIGNATURE-----
>
>
>
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Patching the output file naming code (Was: thanks to whomever put this in the LSR...)

reinhold
In reply to this post by Ian Hulin
-----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, [hidden email], 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-----

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: thanks to whomever put this in the LSR...

reinhold
In reply to this post by chip-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 10. Juni 2009 00:43:43 schrieb chip:

> Ian Hulin wrote:
> > 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?
> >
> > 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.
>
> I am a user very interested in the outcome of this as I use multiple
> \book in all my songs. Being able to have the naming scheme work out
> like this would be great -
[...]
> Basically what the system currently does except dropping the -n from the
> name and replacing it with the variable the user wants added.

That's exactly what 'output-suffix is about. This thread is about improving it
even further (i.e. currently, the suffix is appended, but the number is also
appended, so this patch tries to avoid unnecessary numbering...)

Cheers,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, [hidden email], 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+siTqjEwhXvPN0RAmnHAJ4uaPvF9tR3/8N/Fy4Zf7hmCXA8nwCdHe1k
acd7ypheV6Uc8lo9hWQdlto=
=Z9Ag
-----END PGP SIGNATURE-----

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Ian Hulin
In reply to this post by reinhold
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, [hidden email], 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


  

Reply | Threaded
Open this post in threaded view
|

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

Graham Percival
On Sun, Jun 21, 2009 at 12:25:42AM +0100, Ian Hulin wrote:
> Is \paper the right place to put properties relating to output
> filenames, or should it be property of \score itself?

IMO it should be in \paper, but I suppose that it could be useful
in \midi as well.  It doesn't feel right to have this in \score.

Cheers,
- Graham

---

----
Join the Frogs!