|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 126.96.36.199 (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:
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]|