[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [frogs] Enhancement request: Define output-suffix as a configurable

From: Ian Hulin
Subject: Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
Date: Sat, 19 Sep 2009 14:27:31 +0100
User-agent: Thunderbird (X11/20090817)

Hi Carl, Neil,

I'm quite happy to re-think the proposal if what I have in mind contravenes existing design architecture. Put it down to relative inexperience and the fact I don't get opportunity to work on lilly as often as I'd like.

Anyhow, here are some of the reasons why I'd like to do something with this stuff:

   * Using parser variables to configure things is evil, because it
     requires users to drop into Scheme to set the parser variable. I
     feel we need to replace #(define output-suffix
     "gibbon-vole-aardvark") with something handled at the lilypond
     language level.
   * At the moment, output-suffix is /de facto/ a property of a \book
     block.  There is a design assumption (informal club rule) in
     lilypond  that we only produce one back-end output file (.pdf,
     .png whatever) per \book block.
   * However, there is as great big exception to this in the form of
     midi files, one of which one is output for every \score block with
     a \midi present. At the moment the file name generation code
     kludges its way around this but it not very clean, unclear and all
     this stuff is barely documented.
   * So what I'd like to do is to have some way of replacing the Scheme
     definition either -
     \book {
         \set output-suffix "gibbon-vole-aardvark"
         {... \score blocks and things}
     , or
     \book \with {output-suffix = "gibbon-vole-aardvark"}
        {... \score blocks and things}
     This is why I got thought about setting this as a context
     property, as the \with block looks a very slick way of passing
     parameter values to the block.
   * Having the property available for \score was to allow the user a
     may of setting a descriptive suffix for any midi files output by
     that \score.  The idea would be that that we could inherit the
     enclosing \book property during the currency of the \score,
     override it if required, and reset at the end of the \score.
   * The only remaining need for setting output-suffix from Scheme
     would be if the user insists on coding a group of \score blocks in
a file without using \book. If you have any ideas for an architecturally cleaner solution which would allow users to avoid dropping into Scheme I'm open to suggestions.

Ian Hulin

Carl Sorensen wrote:

On 9/18/09 12:13 PM, "Neil Puttock" <address@hidden> wrote:

2009/9/17 Ian Hulin <address@hidden>:

I'd like to be able to set the output-prefix as a context property, so we
could code stuff like (in MyFile.ly):
There's a problem here: what engraver would this property be
associated with?  Setting an output prefix has nothing to do with
translation, so I can't see why it should be a context property.

Well, during the translation step the translators write output to the output
file using the appropriate output calls, don't they?  So they make use of
the file that was created using the output-prefix.  So this has *something*
to do with translation, even though it's not a characteristic of an

This is part of the function of LilyPond that I don't understand.  Maybe you
can help clarify it for me.  Let me give my brief understanding.

The first phase of processing is parsing.  During this phase, the input file
is converted into a music expression.

I think the second phase is iteration.  During this phase the music
expression resulting from parsing is converted into music streams, which
include the relative timing of various events.

I think the third phase is engraving.  During this phase, the music streams
are converted into printed objects, and sent to the appropriate output file.

However, I'm not sure what the control process is for each of these phases.
It would appear that the control process would be responsible for opening
and closing the file that the engravers are sending information to.

It would be convenient if the output-prefix could be defined in the /score
or /layout block that causes the creation of a Score context.  I think
that's why Ian was wanting to make it a context property of Score.  But I
suspect (although I can't prove) that the file handler exists *outside of*,
not inside of, the Score context.  Hence, we don't want to make it a context
property of Score, because we could change the property inside of the Score,
and the file handler wouldn't know about it.

Is any of this even remotely right?




Join the Frogs!

______________________________________________ This email has been scanned by Netintelligence http://www.netintelligence.com/email

reply via email to

[Prev in Thread] Current Thread [Next in Thread]