Re: Accessing Context Properties

[tisimst]

On Thu, Feb 25, 2016 at 2:34 PM, David Kastrup [via Lilypond] <
ml-node+s1069038n187741...@n5.nabble.com> wrote:

> tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=187741=0>> writes:
>
> > Shows an example of a "kind of music expression you'd want the music
> > function to create." If that's too broad a request, don't worry about
> > it. I just learn lots better when I have a concrete example to
> > dissect. That's all I meant.
>
> git grep ly:context-property
>
> in the top LilyPond directory will dig up a number of "concrete
> examples", partly in the documentation, partly in snippets, partly in
> code.
>

Thanks, David! Not sure why I didn't think of that before. I'll look
through those search results and see if I can make sense of things.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Accessing-Context-Properties-tp187719p187742.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[David Kastrup]

tisimst  writes:

> On Thu, Feb 25, 2016 at 11:03 AM, David Kastrup [via Lilypond] <
> ml-node+s1069038n187726...@n5.nabble.com> wrote:
>
>> tisimst <[hidden email]
>> > writes:
>>
>> > David,
>> >
>> >> All of that cannot be done from within a music function.  I repeat:
>> >> All they can do is create music expressions (typically overrides or
>> >> applyContext calls, possibly as context modifications) that contain
>> >> callbacks of some form that, when ultimately called during iteration
>> >> of the music expression, will be able to access actual properties.
>> >>
>> >> That has nothing to do with music functions at all but rather with
>> >> the kind of music expressions you'd want the music function to
>> >> create.
>> >
>> > I got that from your first message. I promise. I just am not sure what
>> > this means. Can you point me to a snippet (in the LSR?) that shows
>> > this?
>>
>> Shows _what_?
>
>
> Shows an example of a "kind of music expression you'd want the music
> function to create." If that's too broad a request, don't worry about
> it. I just learn lots better when I have a concrete example to
> dissect. That's all I meant.

git grep ly:context-property

in the top LilyPond directory will dig up a number of "concrete
examples", partly in the documentation, partly in snippets, partly in
code.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[tisimst]

Paul,

On Thu, Feb 25, 2016 at 11:08 AM, Paul Morris [via Lilypond] <
ml-node+s1069038n187727...@n5.nabble.com> wrote:

> Hi Abraham,
>
> On Feb 25, 2016, at 12:28 PM, tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=187727=0>> wrote:
>
> I'm asking this because I know that if I can get my hands on a grob, I
> know how to access its properties (with ly:grob-property) and use that
> property's value to make a change if I want (e.g., with
> ly:grob-set-property!). I just don't know the equivalent process for
> getting my hands on a context to access its properties. I know there's
> ly:context-property, but I just don't have as much experience with it as
> normal grobs.
>
>
> You may want a custom engraver, as they have access to contexts and
> context properties.
>
> As I understand it there are three main ways of intervening:
>
> 1. music functions (and scheme, void, and markup functions)
> 2. custom engravers
> 3. grob property callback procedures
>
> 1: let you do fancy things with the input, early on, before LilyPond
> processes it
> 3: let you do things with graphical output very late in the game
> 2: are earlier than 3, exist within contexts and thus have access to
> context properties (and can do things with grobs as well like with 3)
>
> As far as I know context properties can’t be accessed from a grob callback
> and not from music functions as David has said.  So that leaves custom
> engravers (although I don’t really know how \applyContext fits into this).
>
> Maybe that helps?
>

Very much! Thank you.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Accessing-Context-Properties-tp187719p187730.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[tisimst]

On Thu, Feb 25, 2016 at 11:03 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n187726...@n5.nabble.com> wrote:

> tisimst <[hidden email]
> <http:///user/SendEmail.jtp?type=node=187726=0>> writes:
>
> > David,
> >
> >> All of that cannot be done from within a music function.  I repeat:
> >> All they can do is create music expressions (typically overrides or
> >> applyContext calls, possibly as context modifications) that contain
> >> callbacks of some form that, when ultimately called during iteration
> >> of the music expression, will be able to access actual properties.
> >>
> >> That has nothing to do with music functions at all but rather with
> >> the kind of music expressions you'd want the music function to
> >> create.
> >
> > I got that from your first message. I promise. I just am not sure what
> > this means. Can you point me to a snippet (in the LSR?) that shows
> > this?
>
> Shows _what_?


Shows an example of a "kind of music expression you'd want the music
function to create." If that's too broad a request, don't worry about it. I
just learn lots better when I have a concrete example to dissect. That's
all I meant.


> > That would help a lot.
> >
> >> > These are just examples and I'm not even asking for specifics on
> >> > how to do these (as they've partially been discussed in other
> >> > threads). What approach would I want to follow in order to access
> >> > the properties so I could make a change elsewhere?
> >>
> >> Have you read what I wrote?  Music functions are not able to access
> >> properties.  Various music expressions (possibly created by music
> >> functions) may contain callbacks that might be used for such
> >> purposes.
> >>
> >
> > Thanks you for your reply. Yes, I definitely read what you wrote. I
> > realize that music functions aren't the way to go and you've made that
> > perfectly clear. I didn't even mean to imply in my previous response
> > that I wanted to do those things with music functions. I don't care
> > what the mechanism is. I just want to know what it is!
>
> So do you or don't you care to know?
>

What I meant is that it doesn't matter to me what it contains, what it's
called, etc. I'd just like to see what one looks like so I know what I have
to do when I the need arises.


> At any rate, there are a number of different mechanisms where accessing
> context properties make sense.
>
> Basically all of the _user_-accessible mechanisms occur in the context
> of engravers, as event listeners, acknowledgers, end acknowledgers.
> Iterators are not user-definable, so there is little opportunity to
> access context properties from within them, but they may call callbacks
> like the elements-callback of sequential expressions.  There is also
> \applyContext.
>
> > That is exactly why I asked "what approach would I follow in order to
> > access the properties so I could make a change elsewhere?".
>
> It depends on what you want to do.  There is no general answer.
>

That is helpful to know. Thank you.


> > I have no idea where your statements are supposed to be leading me.
> > I'd really like to know, though.
>
> Shrug.  Without a specific question, there will be no specific answer.
>
> > Would you be kind enough to show how YOU would access a context
> > property and use its value in an grob override?
>
> Actually, one usually wouldn't (sorry for having mentioned them in that
> context).  Grob callbacks are usually called on-demand, at a time where
> iteration has already completed and contexts are no longer available.
>
> > Perhaps it's too dependent on what I'd actually like to do.
>
> It very much depends on what you want to do.
>

So, are there general categories of when you'd need to do it one way over
another?


> > I'm asking this because I know that if I can get my hands on a grob,
>
> But you can't.  Not in a music expression.  Only in various other
> contexts.
>
> > I know how to access its properties (with ly:grob-property) and use
> > that property's value to make a change if I want (e.g., with
> > ly:grob-set-property!). I just don't know the equivalent process for
> > getting my hands on a context to access its properties.
>
> The equivalent process to _what_?  You did not specify _how_ you are
> getting your hands on a grob, so how can one answer with an "equivalent"
> process for getting your hands on a context?
>

For example:
  \override TimeSignature.stencil = #(lambda (grob) ... )
  \override Arpeggio.before-line-breaking = #(lambda 

Re: Accessing Context Properties

[Paul Morris]

Hi Abraham,

> On Feb 25, 2016, at 12:28 PM, tisimst  wrote:
> 
> I'm asking this because I know that if I can get my hands on a grob, I know 
> how to access its properties (with ly:grob-property) and use that property's 
> value to make a change if I want (e.g., with ly:grob-set-property!). I just 
> don't know the equivalent process for getting my hands on a context to access 
> its properties. I know there's ly:context-property, but I just don't have as 
> much experience with it as normal grobs.

You may want a custom engraver, as they have access to contexts and context 
properties.

As I understand it there are three main ways of intervening:

1. music functions (and scheme, void, and markup functions)
2. custom engravers
3. grob property callback procedures

1: let you do fancy things with the input, early on, before LilyPond processes 
it
3: let you do things with graphical output very late in the game
2: are earlier than 3, exist within contexts and thus have access to context 
properties (and can do things with grobs as well like with 3)

As far as I know context properties can’t be accessed from a grob callback and 
not from music functions as David has said.  So that leaves custom engravers 
(although I don’t really know how \applyContext fits into this).

Maybe that helps?
-Paul

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[David Kastrup]

tisimst <tisimst.lilyp...@gmail.com> writes:

> David,
>
>> All of that cannot be done from within a music function.  I repeat:
>> All they can do is create music expressions (typically overrides or
>> applyContext calls, possibly as context modifications) that contain
>> callbacks of some form that, when ultimately called during iteration
>> of the music expression, will be able to access actual properties.
>>
>> That has nothing to do with music functions at all but rather with
>> the kind of music expressions you'd want the music function to
>> create.
>
> I got that from your first message. I promise. I just am not sure what
> this means. Can you point me to a snippet (in the LSR?) that shows
> this?

Shows _what_?

> That would help a lot.
>
>> > These are just examples and I'm not even asking for specifics on
>> > how to do these (as they've partially been discussed in other
>> > threads). What approach would I want to follow in order to access
>> > the properties so I could make a change elsewhere?
>>
>> Have you read what I wrote?  Music functions are not able to access
>> properties.  Various music expressions (possibly created by music
>> functions) may contain callbacks that might be used for such
>> purposes.
>>
>
> Thanks you for your reply. Yes, I definitely read what you wrote. I
> realize that music functions aren't the way to go and you've made that
> perfectly clear. I didn't even mean to imply in my previous response
> that I wanted to do those things with music functions. I don't care
> what the mechanism is. I just want to know what it is!

So do you or don't you care to know?

At any rate, there are a number of different mechanisms where accessing
context properties make sense.

Basically all of the _user_-accessible mechanisms occur in the context
of engravers, as event listeners, acknowledgers, end acknowledgers.
Iterators are not user-definable, so there is little opportunity to
access context properties from within them, but they may call callbacks
like the elements-callback of sequential expressions.  There is also
\applyContext.

> That is exactly why I asked "what approach would I follow in order to
> access the properties so I could make a change elsewhere?".

It depends on what you want to do.  There is no general answer.

> I have no idea where your statements are supposed to be leading me.
> I'd really like to know, though.

Shrug.  Without a specific question, there will be no specific answer.

> Would you be kind enough to show how YOU would access a context
> property and use its value in an grob override?

Actually, one usually wouldn't (sorry for having mentioned them in that
context).  Grob callbacks are usually called on-demand, at a time where
iteration has already completed and contexts are no longer available.

> Perhaps it's too dependent on what I'd actually like to do.

It very much depends on what you want to do.

> I'm asking this because I know that if I can get my hands on a grob,

But you can't.  Not in a music expression.  Only in various other
contexts.

> I know how to access its properties (with ly:grob-property) and use
> that property's value to make a change if I want (e.g., with
> ly:grob-set-property!). I just don't know the equivalent process for
> getting my hands on a context to access its properties.

The equivalent process to _what_?  You did not specify _how_ you are
getting your hands on a grob, so how can one answer with an "equivalent"
process for getting your hands on a context?

> Now, when you say a music expression that contains callbacks might be used,
> do you mean like this (Warning: made-up, non-functional pseudo-code ahead):
>
> %%%
>
> test = { \applyContext ... (get currentBarNumber, change MMR stencil using
> currentBarNumber set bar number visibility, etc.) ... }
>
> { c1 \test R1*2 d2 e }

That's probably the most straightforward mechanism through which a music
expression can trigger accesses to context properties.  It's actually
not used all that often, but it's there too.  Yes.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[Ben Strecker]

that helps, too.
> 
> I'm asking this because I know that if I can get my hands on a grob, I know 
> how to access its properties (with ly:grob-property) and use that property's 
> value to make a change if I want (e.g., with ly:grob-set-property!). I just 
> don't know the equivalent process for getting my hands on a context to access 
> its properties. I know there's ly:context-property, but I just don't have as 
> much experience with it as normal grobs.
> 
> Now, when you say a music expression that contains callbacks might be used, 
> do you mean like this (Warning: made-up, non-functional pseudo-code ahead):
> 
> %%%
> 
> test = { \applyContext ... (get currentBarNumber, change MMR stencil using 
> currentBarNumber set bar number visibility, etc.) ... }
> 
> { c1 \test R1*2 d2 e }
> 
> %%%
> 
> Best,
> Abraham
> 
> View this message in context: Re: Accessing Context Properties 
> <http://lilypond.1069038.n5.nabble.com/Accessing-Context-Properties-tp187719p187724.html>
> Sent from the User mailing list archive 
> <http://lilypond.1069038.n5.nabble.com/User-f3.html> at Nabble.com.
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

Abraham,
Is this the sort of thing you’re looking for?

http://www.lilypond.org/doc/v2.18/Documentation/extending/callback-functions 
<http://www.lilypond.org/doc/v2.18/Documentation/extending/callback-functions>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[tisimst]

ing my hands on a context to access its properties. I know there's
ly:context-property, but I just don't have as much experience with it as
normal grobs.

Now, when you say a music expression that contains callbacks might be used,
do you mean like this (Warning: made-up, non-functional pseudo-code ahead):

%%%

test = { \applyContext ... (get currentBarNumber, change MMR stencil using
currentBarNumber set bar number visibility, etc.) ... }

{ c1 \test R1*2 d2 e }

%%%

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Accessing-Context-Properties-tp187719p187724.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[David Kastrup]

tisimst  writes:

> David,
>
> On Thu, Feb 25, 2016 at 9:28 AM, David Kastrup [via Lilypond] <
> ml-node+s1069038n187720...@n5.nabble.com> wrote:
>
>> Abraham Lee <[hidden email]
>> > writes:
>>
>> > All,
>> >
>> > In the docs are numerous sections that discuss how to modify context
>> > properties. This is not complicated. However, a handful of recent
>> threads
>> > on the user list have got me wondering about the correct way(s) of
>> > _accessing_ these properties within, for example, a music function. The
>> > music function may or may not modify the same or another context
>> property.
>> > If music functions are NOT the way to go, then what is preferred?
>> >
>> > Thanks, in advance, for all insights and instruction.
>>
>> I have no idea what you want.  Music functions are called when parsing
>> LilyPond source code.  At that time, there are no contexts and no
>> context properties.  Consequently, music functions have no way
>> whatsoever to read or modify context properties.  All they can do is
>> create music expressions (typically overrides or applyContext calls,
>> possibly as context modifications) that contain callbacks of some form
>> that, when ultimately called during iteration of the music expression,
>> will be able to access actual properties.
>>
>> So for your actual question, there is little insight and instruction to
>> be had.
>
>
> Thanks for your response. That helps knowing that music functions cannot
> read or modify context properties.
>
> Let me give some examples of what I might want to do:
>
> 1. Determine the currentBarNumber in order to print a custom stencil
> 2. Access the System or Staff's vertical position on the page in order to
> change it
> 3. Determine which page I'm on so I can print a particular stencil on that
> page only
> 4. Determine the current time signature so I can create a MMR of the exact
> size needed to fill a measure
> etc.

All of that cannot be done from within a music function.  I repeat: All
they can do is create music expressions (typically overrides or
applyContext calls, possibly as context modifications) that contain
callbacks of some form that, when ultimately called during iteration of
the music expression, will be able to access actual properties.

That has nothing to do with music functions at all but rather with the
kind of music expressions you'd want the music function to create.

> These are just examples and I'm not even asking for specifics on how
> to do these (as they've partially been discussed in other
> threads). What approach would I want to follow in order to access the
> properties so I could make a change elsewhere?

Have you read what I wrote?  Music functions are not able to access
properties.  Various music expressions (possibly created by music
functions) may contain callbacks that might be used for such purposes.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[tisimst]

David,

On Thu, Feb 25, 2016 at 9:28 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n187720...@n5.nabble.com> wrote:

> Abraham Lee <[hidden email]
> <http:///user/SendEmail.jtp?type=node=187720=0>> writes:
>
> > All,
> >
> > In the docs are numerous sections that discuss how to modify context
> > properties. This is not complicated. However, a handful of recent
> threads
> > on the user list have got me wondering about the correct way(s) of
> > _accessing_ these properties within, for example, a music function. The
> > music function may or may not modify the same or another context
> property.
> > If music functions are NOT the way to go, then what is preferred?
> >
> > Thanks, in advance, for all insights and instruction.
>
> I have no idea what you want.  Music functions are called when parsing
> LilyPond source code.  At that time, there are no contexts and no
> context properties.  Consequently, music functions have no way
> whatsoever to read or modify context properties.  All they can do is
> create music expressions (typically overrides or applyContext calls,
> possibly as context modifications) that contain callbacks of some form
> that, when ultimately called during iteration of the music expression,
> will be able to access actual properties.
>
> So for your actual question, there is little insight and instruction to
> be had.


Thanks for your response. That helps knowing that music functions cannot
read or modify context properties.

Let me give some examples of what I might want to do:

1. Determine the currentBarNumber in order to print a custom stencil
2. Access the System or Staff's vertical position on the page in order to
change it
3. Determine which page I'm on so I can print a particular stencil on that
page only
4. Determine the current time signature so I can create a MMR of the exact
size needed to fill a measure
etc.

These are just examples and I'm not even asking for specifics on how to do
these (as they've partially been discussed in other threads). What approach
would I want to follow in order to access the properties so I could make a
change elsewhere?

Thanks,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Accessing-Context-Properties-tp187719p187721.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing Context Properties

[David Kastrup]

Abraham Lee  writes:

> All,
>
> In the docs are numerous sections that discuss how to modify context
> properties. This is not complicated. However, a handful of recent threads
> on the user list have got me wondering about the correct way(s) of
> _accessing_ these properties within, for example, a music function. The
> music function may or may not modify the same or another context property.
> If music functions are NOT the way to go, then what is preferred?
>
> Thanks, in advance, for all insights and instruction.

I have no idea what you want.  Music functions are called when parsing
LilyPond source code.  At that time, there are no contexts and no
context properties.  Consequently, music functions have no way
whatsoever to read or modify context properties.  All they can do is
create music expressions (typically overrides or applyContext calls,
possibly as context modifications) that contain callbacks of some form
that, when ultimately called during iteration of the music expression,
will be able to access actual properties.

So for your actual question, there is little insight and instruction to
be had.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Accessing Context Properties

[Abraham Lee]

All,

In the docs are numerous sections that discuss how to modify context
properties. This is not complicated. However, a handful of recent threads
on the user list have got me wondering about the correct way(s) of
_accessing_ these properties within, for example, a music function. The
music function may or may not modify the same or another context property.
If music functions are NOT the way to go, then what is preferred?

Thanks, in advance, for all insights and instruction.

Best,
Abraham
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[Leah Velleman]

 The problem arises because \applyContext is evaluated later than
 \transpose.  When music functions do their work, contexts have not been
 created yet,

 The output shows that the original binding of k is in effect when
 \transpose is called.


Aha! Thank you — that makes sense.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[David Nalesnik]

Hi Leah,

On Thu, Apr 30, 2015 at 7:28 PM, Leah Velleman leah.velle...@gmail.com
wrote:

 To do something like you want, you really would need access to context
 properties


 Ok — good to know I haven't missed some simple solution.

 It seems like there ought to be some way of smuggling information out of
 an \applyContext. But I guess there's a variable scope issue that keeps you
 from doing it straightforwardly:

 k = OOPS

 text = #(define-music-function (parser location music) (ly:music?)
   #{
 \applyContext

   #(lambda (context)
 (set! k
  (ly:context-property context 'tonic))
   (display k)
 )
 \transpose #(ly:make-pitch 0 0) #k #music
   #}
 )
   \score {

 \new Staff {
 \key a \major

 \test { Fa So La fa so }
   }

 }

 In that code, the (display k) works fine, displaying #Pitch a. But then the
 \transpose #(ly:make-pitch 0 0) #k #music gets ahold of the global
 definition of #k rather than the local one and so you end up with a type
 error: expecting pitch, found OOPS.

 So maybe the question is, does Lilypond Scheme have anything like global
 variables?


Sure.  But even defining the function with a local variable gives the same
results:

test =
#(define-music-function (parser location music) (ly:music?)
   (let ((k ERROR))
 #{

   \applyContext

   #(lambda (context)

  (set! k  (ly:context-property context 'tonic))

  (display k)

  )

   \transpose #(ly:make-pitch 0 0) #k #music
   #(display k)
   #(newline)
 #}

 ))

\score {

  \new Staff {

\key a \major
\test { a b cis d e }

  }

}

The problem arises because \applyContext is evaluated later than
\transpose.  When music functions do their work, contexts have not been
created yet,

The output shows that the original binding of k is in effect when
\transpose is called.

Possibly you could just write a music function that firsts sets the key and
then transposes everything.  Here's a sketch:

\version 2.19

test =
#(define-music-function (parser location pitch music) (ly:pitch? ly:music?)
   #{

 \key #pitch \major
 \transpose #(ly:make-pitch 0 0) #pitch #music
   #})

\score {

  \new Staff {
\test a { c' d' e' f' g' a' b' c'' }

  }

}

David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[David Nalesnik]

On Fri, May 1, 2015 at 7:48 AM, David Nalesnik david.nales...@gmail.com
wrote:

test =
 #(define-music-function (parser location music) (ly:music?)
(let ((k ERROR))
  #{

\applyContext

#(lambda (context)

   (set! k  (ly:context-property context 'tonic))

   (display k)

   )

\transpose #(ly:make-pitch 0 0) #k #music


\transpose c #k #music


#(display k)
#(newline)
  #}

  ))

 \score {

   \new Staff {

 \key a \major
 \test { a b cis d e }

   }

 }


DN
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Accessing context properties (e.g. the current key) from a music function?

[Leah Velleman]

I'm looking to write a \transpose-like music function that will need to be
able to find out what the current key is.

(In case it matters: The reason I'm doing this is to make it possible to
enter music using movable-do solfege. The idea is to have a function
\movableDo that will transpose from C (i.e. do in a fixed-do system) to
the tonic of the current key, so that

\key a \major
\movableDo { do re mi fa so }


will produce the same output as

\key a \major

a b cs d e


Of course, it would be possible to require the user to repeat the key
information, by writing this:

\key a \major

\movableDo a { do re mi fa so }

But this is inconveniently redundant, and makes errors more likely in large
source files, since the key must now be written in many different places.
So I'm trying to avoid doing it this way if possible.)

In any case, I'm having a very difficult time figuring out how a music
function can get access to the key. It seems that the issue is that the key
is a context property; music functions do not take a context as an
argument, and thus can't get access to context properties the way a
function written with make-apply-context could. But I can't see how to get
around that limitation, or indeed whether it would be possible to get
around it at all.

Suggestions?

-Leah
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[David Nalesnik]

On Thu, Apr 30, 2015 at 6:41 PM, David Nalesnik david.nales...@gmail.com
wrote:



 P.S.  Now I'm going to set out to break it...


Well, with simultaneous music you do end up having to repeat the key.

 \test
\new PianoStaff 
  \new Staff 
\new Voice {
  \key re \major
  \voiceOne
  do''4 mi'' sol'' do''' do''' mi''' sol'''1
  \key fa \major
  do''4 mi'' sol'' do''' do''' mi''' sol'''1

}
\new Voice {
  \voiceTwo
  \key re \major
  do'4 mi' sol' do'' do' mi' sol'1
  \key fa \major
  do'4 mi' sol' do'' do'' mi'' sol''1
}
  
  \new Staff 

\new Voice {
  \voiceOne
  \key fa \major
  do''4 mi'' sol'' do''' do''' mi''' sol'''1
  \key re \major
  do''4 mi'' sol'' do''' do''' mi''' sol'''1
}
\new Voice {
  \voiceTwo
  \key fa \major
  do'4 mi' sol' do'' do' mi' sol'1
  \key re \major
  do'4 mi' sol' do'' do' mi' sol'1
}
  


And the ottavation needs rationalization.

DN
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[Leah Velleman]

Oh goodness, something heinous happened to the formatting there. Let me try
that again.

k = ERROR

test = #(define-music-function (parser location music) (ly:music?)

  #{

\applyContext

#(lambda (context)

  (set! k  (ly:context-property context 'tonic))

  (display k)

)

\transpose #(ly:make-pitch 0 0) #k #music

  #}

)

\score {

  \new Staff {

\key a \major
\test { Fa So La fa so }

   }

}


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[Leah Velleman]

Ah! I hadn't even gotten as far as thinking about key-change events
*within* the scope of the music function, though you're right that those
would be an issue too (and your suggestion looks like a sensible way of
dealing with them).

What I was trying to get at was the key that was current before the music
function was called. That is, the test case I was thinking about would look
like this:

\new Staff {
  \new Voice {
\key re \major
\test {
  do'4 mi' sol' do'' do' mi' sol'1
}
  }
}





On Thu, Apr 30, 2015 at 7:23 PM, David Nalesnik david.nales...@gmail.com
wrote:

 Hi Leah,

 On Thu, Apr 30, 2015 at 3:16 PM, Leah Velleman leah.velle...@gmail.com
 wrote:

 I'm looking to write a \transpose-like music function that will need to
 be able to find out what the current key is.

 (In case it matters: The reason I'm doing this is to make it possible to
 enter music using movable-do solfege. The idea is to have a function
 \movableDo that will transpose from C (i.e. do in a fixed-do system) to
 the tonic of the current key, so that

 \key a \major
 \movableDo { do re mi fa so }


 will produce the same output as

 \key a \major

 a b cs d e


 Of course, it would be possible to require the user to repeat the key
 information, by writing this:

 \key a \major

 \movableDo a { do re mi fa so }

 But this is inconveniently redundant, and makes errors more likely in
 large source files, since the key must now be written in many different
 places. So I'm trying to avoid doing it this way if possible.)

 In any case, I'm having a very difficult time figuring out how a music
 function can get access to the key. It seems that the issue is that the key
 is a context property; music functions do not take a context as an
 argument, and thus can't get access to context properties the way a
 function written with make-apply-context could. But I can't see how to get
 around that limitation, or indeed whether it would be possible to get
 around it at all.


 I think the only way you'll be able to get access to the key from a music
 function is actually to parse the music expression, looking for the
 relevant music events.

 Here's something that's pretty limited, but it show that such a thing is
 possible.

 Note that in this sketch, you have to apply the function to each key area
 individually.  It would be nice if you could apply the function to the
 whole music expression, but first things first :)

 Hope this gets you started--

 David

 %%

 \version 2.18

 \language italiano % the closest preset :)

 test =
 #(define-music-function (parser location music)
(ly:music?)
(let ((t (ly:make-pitch 0 0))) ; C is the default tonic
  (music-map
   (lambda (mus)
 (if (music-is-of-type? mus 'key-change-event)
 (set! t (ly:music-property mus 'tonic)))
 (if (music-is-of-type? mus 'note-event)
 #{
   \transpose #(ly:make-pitch 0 0) #t #mus
 #})
 mus)
   music)
  music))


 \new Staff {
   \new Voice {
 \test {
   \key re \major
   do'4 mi' sol' do'' do' mi' sol'1
 }
 \test {
   \key fa \major
do'4 mi' sol' do'' do' mi' sol'1
 }
 \test {
   \key sol \minor
do'4 mib' sol' do'' do' mib' sol'1
 }
   }
 }


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[David Nalesnik]

Leah,

On Thu, Apr 30, 2015 at 6:34 PM, Leah Velleman leah.velle...@gmail.com
wrote:

 Ah! I hadn't even gotten as far as thinking about key-change events
 *within* the scope of the music function, though you're right that those
 would be an issue too (and your suggestion looks like a sensible way of
 dealing with them).

 What I was trying to get at was the key that was current before the music
 function was called. That is, the test case I was thinking about would look
 like this:

 \new Staff {
   \new Voice {
 \key re \major
 \test {
   do'4 mi' sol' do'' do' mi' sol'1
 }
   }
 }


Unfortunately, that won't be possible.  The function won't see the key
change that happened before it was called, and will assume C major.

To do something like you want, you really would need access to context
properties

David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[David Nalesnik]

Hi Leah,

On Thu, Apr 30, 2015 at 3:16 PM, Leah Velleman leah.velle...@gmail.com
wrote:

 I'm looking to write a \transpose-like music function that will need to be
 able to find out what the current key is.

 (In case it matters: The reason I'm doing this is to make it possible to
 enter music using movable-do solfege. The idea is to have a function
 \movableDo that will transpose from C (i.e. do in a fixed-do system) to
 the tonic of the current key, so that

 \key a \major
 \movableDo { do re mi fa so }


 will produce the same output as

 \key a \major

 a b cs d e


 Of course, it would be possible to require the user to repeat the key
 information, by writing this:

 \key a \major

 \movableDo a { do re mi fa so }

 But this is inconveniently redundant, and makes errors more likely in
 large source files, since the key must now be written in many different
 places. So I'm trying to avoid doing it this way if possible.)

 In any case, I'm having a very difficult time figuring out how a music
 function can get access to the key. It seems that the issue is that the key
 is a context property; music functions do not take a context as an
 argument, and thus can't get access to context properties the way a
 function written with make-apply-context could. But I can't see how to get
 around that limitation, or indeed whether it would be possible to get
 around it at all.


I think the only way you'll be able to get access to the key from a music
function is actually to parse the music expression, looking for the
relevant music events.

Here's something that's pretty limited, but it show that such a thing is
possible.

Note that in this sketch, you have to apply the function to each key area
individually.  It would be nice if you could apply the function to the
whole music expression, but first things first :)

Hope this gets you started--

David

%%

\version 2.18

\language italiano % the closest preset :)

test =
#(define-music-function (parser location music)
   (ly:music?)
   (let ((t (ly:make-pitch 0 0))) ; C is the default tonic
 (music-map
  (lambda (mus)
(if (music-is-of-type? mus 'key-change-event)
(set! t (ly:music-property mus 'tonic)))
(if (music-is-of-type? mus 'note-event)
#{
  \transpose #(ly:make-pitch 0 0) #t #mus
#})
mus)
  music)
 music))


\new Staff {
  \new Voice {
\test {
  \key re \major
  do'4 mi' sol' do'' do' mi' sol'1
}
\test {
  \key fa \major
   do'4 mi' sol' do'' do' mi' sol'1
}
\test {
  \key sol \minor
   do'4 mib' sol' do'' do' mib' sol'1
}
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[David Nalesnik]

Hi Harm,

On Thu, Apr 30, 2015 at 6:36 PM, Thomas Morley thomasmorle...@gmail.com
wrote:

 2015-05-01 1:23 GMT+02:00 David Nalesnik david.nales...@gmail.com:



  %%
 
  \version 2.18
 
  \language italiano % the closest preset :)
 
  test =
  #(define-music-function (parser location music)
 (ly:music?)
 (let ((t (ly:make-pitch 0 0))) ; C is the default tonic
   (music-map
(lambda (mus)
  (if (music-is-of-type? mus 'key-change-event)
  (set! t (ly:music-property mus 'tonic)))
  (if (music-is-of-type? mus 'note-event)
  #{
\transpose #(ly:make-pitch 0 0) #t #mus
  #})
  mus)
music)
   music))
 

 This seems to work as well, or am I missing something?

 \test
 \new Staff {
   \new Voice {
  {
   \key re \major
   do'4 mi' sol' do'' do' mi' sol'1
 }
  {
   \key fa \major
do'4 mi' sol' do'' do' mi' sol'1
 }
  {
   \key sol \minor
do'4 mib' sol' do'' do' mib' sol'1
 }
   }
 }


 Cheers,
   Harm


Huh.  I tried to make it easy on myself and purposely write something that
wouldn't work like that :)

Thanks!

David

P.S.  Now I'm going to set out to break it...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[Leah Velleman]

 To do something like you want, you really would need access to context
 properties


Ok — good to know I haven't missed some simple solution.

It seems like there ought to be some way of smuggling information out of an
\applyContext. But I guess there's a variable scope issue that keeps you
from doing it straightforwardly:

k = OOPS
text = #(define-music-function (parser location music) (ly:music?)
  #{
\applyContext

  #(lambda (context)
(set! k
 (ly:context-property context 'tonic))
  (display k)
)
\transpose #(ly:make-pitch 0 0) #k #music
  #}
)
\score {

  \new Staff {
  \key a \major

  \test { Fa So La fa so }
}

  }

In that code, the (display k) works fine, displaying #Pitch a. But then the
\transpose #(ly:make-pitch 0 0) #k #music gets ahold of the global
definition of #k rather than the local one and so you end up with a type
error: expecting pitch, found OOPS.

So maybe the question is, does Lilypond Scheme have anything like global
variables?
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accessing context properties (e.g. the current key) from a music function?

[Thomas Morley]

2015-05-01 1:23 GMT+02:00 David Nalesnik david.nales...@gmail.com:
 Hi Leah,

 On Thu, Apr 30, 2015 at 3:16 PM, Leah Velleman leah.velle...@gmail.com
 wrote:

 I'm looking to write a \transpose-like music function that will need to be
 able to find out what the current key is.

 (In case it matters: The reason I'm doing this is to make it possible to
 enter music using movable-do solfege. The idea is to have a function
 \movableDo that will transpose from C (i.e. do in a fixed-do system) to
 the tonic of the current key, so that

 \key a \major
 \movableDo { do re mi fa so }


 will produce the same output as

 \key a \major

 a b cs d e


 Of course, it would be possible to require the user to repeat the key
 information, by writing this:

 \key a \major

 \movableDo a { do re mi fa so }

 But this is inconveniently redundant, and makes errors more likely in
 large source files, since the key must now be written in many different
 places. So I'm trying to avoid doing it this way if possible.)

 In any case, I'm having a very difficult time figuring out how a music
 function can get access to the key. It seems that the issue is that the key
 is a context property; music functions do not take a context as an argument,
 and thus can't get access to context properties the way a function written
 with make-apply-context could. But I can't see how to get around that
 limitation, or indeed whether it would be possible to get around it at all.


 I think the only way you'll be able to get access to the key from a music
 function is actually to parse the music expression, looking for the relevant
 music events.

 Here's something that's pretty limited, but it show that such a thing is
 possible.

 Note that in this sketch, you have to apply the function to each key area
 individually.  It would be nice if you could apply the function to the whole
 music expression, but first things first :)

 Hope this gets you started--

 David

 %%

 \version 2.18

 \language italiano % the closest preset :)

 test =
 #(define-music-function (parser location music)
(ly:music?)
(let ((t (ly:make-pitch 0 0))) ; C is the default tonic
  (music-map
   (lambda (mus)
 (if (music-is-of-type? mus 'key-change-event)
 (set! t (ly:music-property mus 'tonic)))
 (if (music-is-of-type? mus 'note-event)
 #{
   \transpose #(ly:make-pitch 0 0) #t #mus
 #})
 mus)
   music)
  music))


 \new Staff {
   \new Voice {
 \test {
   \key re \major
   do'4 mi' sol' do'' do' mi' sol'1
 }
 \test {
   \key fa \major
do'4 mi' sol' do'' do' mi' sol'1
 }
 \test {
   \key sol \minor
do'4 mib' sol' do'' do' mib' sol'1
 }
   }
 }


This seems to work as well, or am I missing something?

\test
\new Staff {
  \new Voice {
 {
  \key re \major
  do'4 mi' sol' do'' do' mi' sol'1
}
 {
  \key fa \major
   do'4 mi' sol' do'' do' mi' sol'1
}
 {
  \key sol \minor
   do'4 mib' sol' do'' do' mib' sol'1
}
  }
}


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user