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.
Cheers,
Ian Hulin
Carl Sorensen wrote:
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!
______________________________________________
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
|