|
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 2.0.0.23 (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 ina 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" <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 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
[Prev in Thread] | Current Thread | [Next in Thread] |