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

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 9/18/09 12:13 PM, "Neil Puttock" <n.puttock@xxxxxxxxx> wrote:

> 2009/9/17 Ian Hulin <ian@xxxxxxxxxxxx>:
> 
>> 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
engraver.

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?

Thanks,

Carl


---

----
Join the Frogs!