Enhancement request: Define output-suffix as a configurable context property.

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Enhancement request: Define output-suffix as a configurable context property.

Ian Hulin
This is a follow-on from trackers 404 and 714.  I'm very aware that we
haven't yet followed through on Graham's original request, but have only
fixed some bugs which were in the way.

I'd like to be able to set the output-prefix as a context property, so
we could code stuff like (in MyFile.ly):

\book
{
     \score \with {output-prefix = "VocalScore"}
     {
         << \vocalMusic >>
     }
}

\book
{
     \score \with {output-prefix = "PianoVocalScore"}
     {
         <<
             \new Staff << \vocalMusic >>
             \new PianoStaff << \pianoMusic >>
        >>
     }
}

which would generate the files MyFile-VocalScore.pdf and
MyFile-PianoVocalScore.pdf.

Valentin, could we have a tracker, please?

Also, could anyone who could give me a steer into defining a new context
property give me a pointer as to where to look in the code for examples
where this is implemented for existing properties?  I'd really like to
have access to an exemplar.

At the moment I'm struggling with issues like:
Do I need to define the property and access routines C++, i.e. add the
new property, accessor routine prototypes and code in score.hh and
score.cc, with scheme bindings in score-scheme.cc. However, looking at
the code it looks like the Score class is relatively light and only has
  properties like
music_, input_location_ header_, defs_ user_key_ and error_found_.

So lilypond properties which can be applied to \score blocks, like
autoAccidentals must use a different mechanism.

However, I'm having a hard time using git grep to discover what this is.

If anyone can shed some light on this, I'd be really grateful.

Cheers,

Ian Hulin

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Valentin Villenave
Administrator
On Thu, Sep 17, 2009 at 11:26 PM, Ian Hulin <[hidden email]> wrote:
> Valentin, could we have a tracker, please?

Here you go:
http://code.google.com/p/lilypond/issues/detail?id=836

Cheers,
Valentin

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen
In reply to this post by Ian Hulin



On 9/17/09 3:26 PM, "Ian Hulin" <[hidden email]> wrote:


>
> Also, could anyone who could give me a steer into defining a new context
> property give me a pointer as to where to look in the code for examples
> where this is implemented for existing properties?  I'd really like to
> have access to an exemplar.
>
> At the moment I'm struggling with issues like:
> Do I need to define the property and access routines C++, i.e. add the
> new property, accessor routine prototypes and code in score.hh and
> score.cc, with scheme bindings in score-scheme.cc. However, looking at
> the code it looks like the Score class is relatively light and only has
>   properties like
> music_, input_location_ header_, defs_ user_key_ and error_found_.
>
> So lilypond properties which can be applied to \score blocks, like
> autoAccidentals must use a different mechanism.

My approach was to look in the IR for context properties.  Then I picked one
(chordChanges) and did git grep for it.

It turned up

scm/define-context-properties.scm

which is where all of the context properties are defined.

Do you need more than this?

HTH,

Carl


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Neil Puttock
In reply to this post by Ian Hulin
2009/9/17 Ian Hulin <[hidden email]>:

> 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.

Regards,
Neil

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen



On 9/18/09 12:13 PM, "Neil Puttock" <[hidden email]> wrote:

> 2009/9/17 Ian Hulin <[hidden email]>:
>
>> 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.

I thought the original proposal was to set the output-prefix as a parser
variable.  Am I remembering incorrectly?

Carl


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Neil Puttock
2009/9/18 Carl Sorensen <[hidden email]>:

> I thought the original proposal was to set the output-prefix as a parser
> variable.  Am I remembering incorrectly?

No, that's exactly how it is currently defined.

Regards,
Neil

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen
In reply to this post by Neil Puttock



On 9/18/09 12:13 PM, "Neil Puttock" <[hidden email]> wrote:

> 2009/9/17 Ian Hulin <[hidden email]>:
>
>> 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!

Reply | Threaded
Open this post in threaded view
|

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

Ian Hulin
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" [hidden email] wrote:

  
2009/9/17 Ian Hulin [hidden email]:

    
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

  

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen



On 9/19/09 7:27 AM, "Ian Hulin" <[hidden email]> wrote:

> 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}
> * }.

Could one define a void music function

setOutputSuffix =
#(define-music-function (parser layout new-output-suffix) (string?)
    (define output-suffix new-output-suffix)
    (make-music 'SequentialMusic 'void #t))

then do

\book {
   \setOutputSuffix "gibbon-vole-aardvark"
   {... \score blocks and things ...}
}

I haven't tried it, but I think it may work.

Carl


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Ian Hulin
Hi Carl,
That will work, but it's still a work-around.  We'd be avoiding setting it as a context property to keep the architectural thinking clean, while at the same time duplicating the functionality of a property by hand.
What we're in effect doing here is duplicating the behaviour of a property, we're hiding the parser variable and writing a function to write to it. So why not

pvSet =
#(define-music-function (parser layout parser-variable new-value) (variable? string?)
    (set! parser-variable new-value)
    (make-music 'SequentialMusic 'void #t))

then do

\book {
   \pvset output-suffix "gibbon-vole-aardvark"
   {... \score blocks and things ...}
}
But I'm still bothered we may be re-inventing the wheel here.  We've got properties in lily already, and defined ways of setting them (\set, \override and even assigning them in the relevant block).

Could we not add a new define-parser-variable-properties.scm with
(define-public all-pv-properties '())
(define (pv-property-description symbol type? description)
  (if (not (and
        (symbol? symbol)
        (procedure? type?)
        (string? description)))
      (throw 'init-format-error))


  (if (not (equal? #f (object-property symbol 'translation-doc)))
      (ly:error (_ "symbol ~S redefined" symbol)))

  (set-object-property! symbol 'translation-type? type?)
  (set-object-property! symbol 'translation-doc description)
  (set! all-pv-properties (cons symbol all-translation-properties))
  symbol)
 (define-public all-pv-properties
    (map
        (lambda (x)
            (apply pv-property-description x))
            `(
              (output-suffix ,string? "Text to append to the output filename for the current @code{\\book} block")
;;; Maybe add all the other supported parser variables here?

)))

The above should work as I've adapted it unashamedly from define-context-properties.scm

Remaining things to do would be
  • add define-parser-variable-properties.scm to build (whimper...)
  • get the property access routines to use the new all-pv-properties list
This would be more work,  but give us a cleaner result and it would be less likely to fall foul of a fatwah from new Syntax Standardization project when it gets going.

Opinions?

Cheers,

Ian

Carl Sorensen wrote:

On 9/19/09 7:27 AM, "Ian Hulin" [hidden email] wrote:

  
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}
* }.
    

Could one define a void music function

setOutputSuffix =
#(define-music-function (parser layout new-output-suffix) (string?)
    (define output-suffix new-output-suffix)
    (make-music 'SequentialMusic 'void #t))

then do

\book {
   \setOutputSuffix "gibbon-vole-aardvark"
   {... \score blocks and things ...}
}

I haven't tried it, but I think it may work.

Carl


---

----
Join the Frogs!


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

  

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen



On 9/20/09 5:40 AM, "Ian Hulin" <[hidden email]> wrote:

> Hi Carl,
> That will work, but it's still a work-around.  We'd be avoiding setting it as
> a context property to keep the architectural thinking clean, while at the same
> time duplicating the functionality of a property by hand.

OK, I guess I agree with what you said.

> What we're in effect doing here is duplicating the behaviour of a property,
> we're hiding the parser variable and writing a function to write to it. So why
> not
>
> pvSet =
> #(define-music-function (parser layout parser-variable new-value) (variable?
> string?)
>     (set! parser-variable new-value)
>     (make-music 'SequentialMusic 'void #t))
>
> then do
>
> \book {
>    \pvset output-suffix "gibbon-vole-aardvark"
>    {... \score blocks and things ...}
> }

Yes, this is more general than my suggestion.

> But I'm still bothered we may be re-inventing the wheel here.  We've got
> properties in lily already, and defined ways of setting them (\set, \override
> and even assigning them in the relevant block).
>
> Could we not add a new define-parser-variable-properties.scm with
> (define-public all-pv-properties '())
> (define (pv-property-description symbol type? description)
>   (if (not (and
>         (symbol? symbol)
>         (procedure? type?)
>         (string? description)))
>       (throw 'init-format-error))
>
>
>   (if (not (equal? #f (object-property symbol 'translation-doc)))
>       (ly:error (_ "symbol ~S redefined" symbol)))
>
>   (set-object-property! symbol 'translation-type? type?)
>   (set-object-property! symbol 'translation-doc description)
>   (set! all-pv-properties (cons symbol all-translation-properties))
>   symbol)
>  (define-public all-pv-properties
>     (map
>         (lambda (x)
>             (apply pv-property-description x))
>             `(
>               (output-suffix ,string? "Text to append to the output filename
> for the current @code{\\book} block")
> ;;; Maybe add all the other supported parser variables here?
>
> )))
>
> The above should work as I've adapted it unashamedly from
> define-context-properties.scm

This seems like a good idea to me.  However, I'm not really strong on parser
variables.  But if this does work, I think it would be an improved way of
handling point-and-click, because, as you say, it would tie into the
existing LilyPond syntax.

>
> Remaining things to do would be
> * add define-parser-variable-properties.scm to build (whimper...)

No (whimper...) needed here; this is trivial to do.  Just add an entry to
scm/lily.scm.

 
> * get the property access routines to use the new all-pv-properties list

I'm not sure I have this vision.  How would \set know whether to set a
context property or a pv property?

Carl



---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Ian Hulin
Carl Sorensen wrote:

On 9/20/09 5:40 AM, "Ian Hulin" [hidden email] wrote:

  
Hi Carl,
That will work, but it's still a work-around.� We'd be avoiding setting it as
a context property to keep the architectural thinking clean, while at the same
time duplicating the functionality of a property by hand.
    

OK, I guess I agree with what you said.

  
What we're in effect doing here is duplicating the behaviour of a property,
we're hiding the parser variable and writing a function to write to it. So why
not 

pvSet =
#(define-music-function (parser layout parser-variable new-value) (variable?
string?)
    (set! parser-variable new-value)
    (make-music 'SequentialMusic 'void #t))

then do

\book {
   \pvset output-suffix "gibbon-vole-aardvark"
   {... \score blocks and things ...}
}
    

Yes, this is more general than my suggestion.

  
But I'm still bothered we may be re-inventing the wheel here.� We've got
properties in lily already, and defined ways of setting them (\set, \override
and even assigning them in the relevant block).

Could we not add a new define-parser-variable-properties.scm with
(define-public all-pv-properties '())
(define (pv-property-description symbol type? description)
 (if (not (and
  (symbol? symbol)
  (procedure? type?)
  (string? description)))
  (throw 'init-format-error))


 (if (not (equal? #f (object-property symbol 'translation-doc)))
 (ly:error (_ "symbol ~S redefined" symbol)))

 (set-object-property! symbol 'translation-type? type?)
 (set-object-property! symbol 'translation-doc description)
 (set! all-pv-properties (cons symbol all-translation-properties))
 symbol)
(define-public all-pv-properties
 (map
 (lambda (x)
 (apply pv-property-description x))
 `(
  (output-suffix ,string? "Text to append to the output filename
for the current @code{\\book} block")
;;; Maybe add all the other supported parser variables here?

)))

The above should work as I've adapted it unashamedly from
define-context-properties.scm
    

This seems like a good idea to me.  However, I'm not really strong on parser
variables.  But if this does work, I think it would be an improved way of
handling point-and-click, because, as you say, it would tie into the
existing LilyPond syntax.

  
Remaining things to do would be
* add define-parser-variable-properties.scm to build (whimper...)
    

No (whimper...) needed here; this is trivial to do.  Just add an entry to
scm/lily.scm.

 
  
Wouldn't I need to add a dependency to the build, too? 
* get the property access routines to use the new all-pv-properties list
    

I'm not sure I have this vision.  How would \set know whether to set a
context property or a pv property?

  
Presumably the same way it decides whether to access a context property, music property, or grob property currently. 
That's something I'll have to dig into.  I was sort of assuming the \set code did a lookup of available property lists, I'll undertake further research.

Cheers,
Ian


Reply | Threaded
Open this post in threaded view
|

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

Valentin Villenave
Administrator
In reply to this post by Carl Sorensen
On Sun, Sep 20, 2009 at 2:41 PM, Carl Sorensen <[hidden email]> wrote:
> This seems like a good idea to me.  However, I'm not really strong on parser
> variables.  But if this does work, I think it would be an improved way of
> handling point-and-click, because, as you say, it would tie into the
> existing LilyPond syntax.

I could update the tracker page accordingly... Can you guys help me? :-)

Valentin

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen
In reply to this post by Ian Hulin



On 9/20/09 9:04 AM, "Ian Hulin" <[hidden email]> wrote:

> Carl Sorensen wrote:
>>  
>>>  
>>> Remaining things to do would be
>>> * add define-parser-variable-properties.scm to build (whimper...)
>>>    
>>>  
>>  
>>
>> No (whimper...) needed here; this is trivial to do.  Just add an entry to
>> scm/lily.scm.
>>
>>  
>>  
> Wouldn't I need to add a dependency to the build, too? 

No.  The dependency for the build is determined by its presence in the scm/
directory.  That part of the build system is really quite fine and easy to
use.

>>  
>>>  
>>> * get the property access routines to use the new all-pv-properties list
>>>    
>>>  
>>  
>>
>> I'm not sure I have this vision.  How would \set know whether to set a
>> context property or a pv property?
>>
>>  
> Presumably the same way it decides whether to access a context property, music
> property, or grob property currently. 
> That's something I'll have to dig into.  I was sort of assuming the \set code
> did a lookup of available property lists, I'll undertake further research.

Please do.  If this works, I think it would be a great addition.  But we
still haven't heard what Neil thinks about it, and he has a much more
complete grasp of LilyPond internals than I do.

Thanks,

Carl



---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen
In reply to this post by Valentin Villenave



On 9/20/09 9:41 AM, "Valentin Villenave" <[hidden email]> wrote:

> On Sun, Sep 20, 2009 at 2:41 PM, Carl Sorensen <[hidden email]> wrote:
>> This seems like a good idea to me.  However, I'm not really strong on parser
>> variables.  But if this does work, I think it would be an improved way of
>> handling point-and-click, because, as you say, it would tie into the
>> existing LilyPond syntax.
>
> I could update the tracker page accordingly... Can you guys help me? :-)

I think that we shouldn't yet add a tracker for the general solution.  We're
still working on the output-suffix issues, which might have a more general
solution.

Thanks,

Carl


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Valentin Villenave
Administrator
On Mon, Sep 21, 2009 at 2:34 AM, Carl Sorensen <[hidden email]> wrote:
> I think that we shouldn't yet add a tracker for the general solution.  We're
> still working on the output-suffix issues, which might have a more general
> solution.

No problem, as long as you're still patient enough to keep track of
the whole thing. If not, please do give me a ping :-)

Cheers,
Valentin

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Neil Puttock
In reply to this post by Carl Sorensen
2009/9/19 Carl Sorensen <[hidden email]>:

> 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.

I don't think so, since the output file doesn't exist until a
Paper_book object has been finalized and sent to the appropriate
output framework.

> 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.

Seriously, I don't understand it either. :)

> 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.

I think this phase is much more complicated than the other two, since
there's a great deal of work going on after grobs have been created
(e.g., line-breaking and page-breaking) before anything is dumped to
an ouput file.

> 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.

I think this is the main stumbling block (leaving aside the issue of
whether it's appropriate to store a file suffix at this point); I
can't see any elegant (kludge-free) way of getting this information to
the file handler.

Regards,
Neil

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen



On 9/21/09 2:38 PM, "Neil Puttock" <[hidden email]> wrote:

> 2009/9/19 Carl Sorensen <[hidden email]>:
>
>> 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.
>
> I don't think so, since the output file doesn't exist until a
> Paper_book object has been finalized and sent to the appropriate
> output framework.

OK, so what sends Paper_book objects to output frameworks?

>
>> 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.
>
> Seriously, I don't understand it either. :)
>
>> 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.
>
> I think this phase is much more complicated than the other two, since
> there's a great deal of work going on after grobs have been created
> (e.g., line-breaking and page-breaking) before anything is dumped to
> an ouput file.
>

I agree.  My understanding is that first, grobs are created (and grobs are
*not* ink on paper, they are scheme objects that will eventually be
converted into ink on paper).

Once grobs are created, layout happens (line breaking, page breaking, and
collision resolution, I think).  During layout, properties of grobs are
changed, and new grobs are sometimes created.

Then, once layout happens, Paper_book objects are sent to output framework
where they are converted into output that will ultimately put ink on the
page (e.g. postscript instructions, or svg instructions).

Is this even close?


>> 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.
>
> I think this is the main stumbling block (leaving aside the issue of
> whether it's appropriate to store a file suffix at this point); I
> can't see any elegant (kludge-free) way of getting this information to
> the file handler.

What do you think of Ian's suggestion to create pv-properties for parser
variables?

Carl


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Patrick McCarty
On Mon, Sep 21, 2009 at 1:48 PM, Carl Sorensen <[hidden email]> wrote:

>
> On 9/21/09 2:38 PM, "Neil Puttock" <[hidden email]> wrote:
>
>> 2009/9/19 Carl Sorensen <[hidden email]>:
>>
>>> 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.
>>
>> I don't think so, since the output file doesn't exist until a
>> Paper_book object has been finalized and sent to the appropriate
>> output framework.
>
> OK, so what sends Paper_book objects to output frameworks?

I think this occurs in Paper_book::output(), line 183.

The self_scm() call applies to the Paper_book object, and this object
becomes the 2nd argument in the call to output-framework.  Thus the
output frameworks have access to the Paper_book object.

-Patrick

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

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

Neil Puttock
In reply to this post by Ian Hulin
2009/9/19 Ian Hulin <[hidden email]>:

> 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.

This isn't strictly true, since it's possible to set it using LilyPond
syntax; the only issue is the parser requirement that the identifier
be enclosed in quotes to prevent the hyphen being misinterpreted:

"output-suffix" = "gibbon-vole-aardvark"

> 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}
> }

This is a recipe for confusion, since the \set command is reserved for
context properties; users find it confusing enough that there are
distinct properties requiring \set and \override.

> , or
> \book \with {output-suffix = "gibbon-vole-aardvark"}
> {
>    {... \score blocks and things}
> }.

A \book block doesn't instantiate a context, so you can't use (or
extend) \with here (in any case the parser expects either \new or
\context to come before \with, so you'd also have to do some serious
parser hacking).

> If you have any ideas for an architecturally cleaner solution which would
> allow users to avoid dropping into Scheme I'm open to suggestions.

Since the main issue appears to be the situation with \midi blocks, I
think the best option would be to set a midi-output-suffix within the
\midi block, though I'm not sure whether this is feasible.

Regards,
Neil

---

----
Join the Frogs!

12