Re: tiny function
David Kastrup writes:
> Thomas Morley writes:
>
>> Otoh, we can store things like \paper, \layout, \midi, \with and as
>> off issue 4908 even \header in variables.
>> But when called, the variable needs to be wrapped in a proper manner,
>> sometimes not. Example:
>>
>> ppr = \paper { ragged-right = ##f }
>>
>> %% works
>> \book {
>> \paper { \ppr }
>> { ces''1 }
>> }
>>
>> %% doesn't work
>> \book {
>> \ppr
>> { cis''1 }
>> }
>>
>> %% works
>> \ppr
>> { cisis''1 }
>>
>> Admittedly, this example is about \paper not \with, more, I use always
>> fixed values no function calls and other things are coming into the
>> game.
>
> Argh!
>
> This is just a bug. It's supposed to work but apparently fails. The
> parser obviously does all of the parsing (there is no error message) but
> the processing does not quite do the right thing.
Tracker issue: 4912 (https://sourceforge.net/p/testlilyissues/issues/4912/)
Rietveld issue: 299490043 (https://codereview.appspot.com/299490043)
Issue description:
Fix output definition use in \book and \bookpart The only explicit
output definition blocks allowed in \book and \bookpart blocks were
paper blocks. Output definitions supplied with Scheme expressions
were erroneously interpreted like global output definitions,
accepting all output definition types and overriding the global
defaults with them. Now the only output definitions accepted as
Scheme expressions are paper blocks. As opposed to previously, they
actually set the paper block of the respective book or bookpart.
Sometimes a bug is just a bug.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Thomas Morley writes:
> Well, not really. As said before, my feelings were ambivalent.
>
> After reconsidering:
>
> It's more a possibility I sometimes use. Mostly because of lazyness in typing.
>
> Writing
> \new Staff \with \some-function-returning-a-context-modification ...
> instead of
> \new Staff \some-function-returning-a-context-modification ...
> is not a big deal. A few key-strokes nothing else ...
> Though, I thought it was the OP's main point.
I am not sure it was the main point. The problem is that the function
does need the \with (and scheme functions are comparatively new as
opposed to \with \identifier) indeed and cannot omit it.
> Otoh, we can store things like \paper, \layout, \midi, \with and as
> off issue 4908 even \header in variables.
> But when called, the variable needs to be wrapped in a proper manner,
> sometimes not. Example:
>
> ppr = \paper { ragged-right = ##f }
>
> %% works
> \book {
> \paper { \ppr }
> { ces''1 }
> }
>
> %% doesn't work
> \book {
> \ppr
> { cis''1 }
> }
>
> %% works
> \ppr
> { cisis''1 }
>
> Admittedly, this example is about \paper not \with, more, I use always
> fixed values no function calls and other things are coming into the
> game.
Argh!
This is just a bug. It's supposed to work but apparently fails. The
parser obviously does all of the parsing (there is no error message) but
the processing does not quite do the right thing.
> Though, I'd love to see it consistent for all of \paper, \layout,
> \midi, \with and \header, regardless if it's a function call or not,
> regardless where called.
In some respects that depends on where the parser goes. It's really
really quite at its limit concerning parsing comparatively free-form
expressions with its lookahead. So it's often give one, take one.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
2016-07-01 11:50 GMT+02:00 David Kastrup :
> David Kastrup writes:
>
>> Thomas Morley writes:
>>
>>> 2016-07-01 7:05 GMT+02:00 David Kastrup :
Thomas Morley writes:
>>>
> %% works:
> tstII =
> \with { instrumentName = "foo" shortInstrumentName = "foo" }
> \new Staff \tstII { r1 }
Issue 4911 is supposed to harmonize this by stopping the second example
from working. This makes it possible to recognize the syntax without
knowing the type of \tstII in advance (could be a music expression,
leading to completely different structure).
>>>
>>> I'm in two minds here.
>>> Hormonizing code is always preferable, but being able to spare the
>>> extra \with would be nice as well.
>>
>> Why? There are technical considerations underlying this change that are
>> also related to usability changes, like editors having a chance to
>> properly identify and indent parts of an expression.
>>
>> It is not possible to let an argument-less scheme function work in the
>> same manner/syntax as a fixed context modification works right now.
>> Fixing that comes at a high cost, basically requiring special-casing
>> scheme functions in a similar vein as now music/event functions are
>> special-cased. Which is something that makes it impossible to create
>> structures of music/event functions and other things.
>
> Sigh. I make a hash of my communication. This sounds just like a rant.
Nah, I didn't understand it like that.
> But the "Why?" was actually an honest question. A lot of the work I do
> is focused about making entry more convenient and better reflecting the
> writers' ways of thinking about music. LilyPond has sort-of a free-form
> syntax that tends to create quite a few ambiguities. So there are some
> balancing acts involved here.
>
> Now in this case I was working on some parser refactoring and it dumped
> out something like a dozen shift/reduce conflicts (meaning ambiguities
> in the resulting syntax in need of resolution) of which more than a
> third were due to the \with thing. The particular stuff I was working
> on was of the
>
> xxx = ...
> \xxx
>
> variety where xxx needs to get consulted to decide whether it is still
> part of ... or not. Now many such decisions can be made on the basis
> "anything of form \xxx cannot become part of ...". For example, if I
> allow a.b and have seen a, I only need to know whether the next token is
> . or not, and I don't need to know what value/type \xxx has, only that
> it is not a period.
>
> But to make decisions on that level, \xxx basically falls into two
> tokens, the first just saying "this is an escaped identifier" and the
> second actually looking at the type of xxx.
>
> Now the parser works only with very limited and specific lookahead. If
> I split escape sequences like \xxx into two tokens effectively, the
> parser stops being able to make some decisions timely that it currently
> still can do with a lookahead of a single token.
>
> I am still making a hash of my communication. Being able to omit \with
> comes at a cost in complexity because
>
> \new Staff \xxx
>
> causes completely different syntactical meaning depending on whether
> \xxx is a context modification or music. When writing
>
> \new Staff \with { \xxx }
>
> \xxx _still_ can be either a music expression (like \hide BarLine) or a
> context modification, but at that point it does not cause a complete
> rewiring of the parse tree: LilyPond can just evaluate, take a look at
> the resulting expression, and then decide what to do with it, namely
> _how_ to make it part of the resulting context modification. There is
> still ambiguity but it does not influence how to parse the expression.
>
> So being able to omit \with comes at a cost, and it works only with
> fixed identifiers. So how to justify the cost? And that's where "why?"
> comes into play. User friendliness is an argument.
>
> Now personally, I find it distracting to see something like
> \RemoveEmptyStaves without \with. I haven't omitted it myself, and it's
> present in most of LilyPond's documentation and examples as well (the
> convert-ly rule has very little actual impact on the code).
> Independently of just having figured out or remembered that this thing
> comes at a non-zero cost in Bison parsing complexity.
>
> Obviously, that's not how you feel about the construct.
Well, not really. As said before, my feelings were ambivalent.
After reconsidering:
It's more a possibility I sometimes use. Mostly because of lazyness in typing.
Writing
\new Staff \with \some-function-returning-a-context-modification ...
instead of
\new Staff \some-function-returning-a-context-modification ...
is not a big deal. A few key-strokes nothing else ...
Though, I thought it was the OP's main point.
Otoh, we can store things like \paper, \layout, \midi, \with and as
off issue 4908 even \header in variables.
But when called, the variable needs to be wrapped in a proper manner,
sometimes not. Example:
pp
Re: tiny function
David Kastrup writes:
> Thomas Morley writes:
>
>> 2016-07-01 7:05 GMT+02:00 David Kastrup :
>>> Thomas Morley writes:
>>
%% works:
tstII =
\with { instrumentName = "foo" shortInstrumentName = "foo" }
\new Staff \tstII { r1 }
>>>
>>> Issue 4911 is supposed to harmonize this by stopping the second example
>>> from working. This makes it possible to recognize the syntax without
>>> knowing the type of \tstII in advance (could be a music expression,
>>> leading to completely different structure).
>>
>> I'm in two minds here.
>> Hormonizing code is always preferable, but being able to spare the
>> extra \with would be nice as well.
>
> Why? There are technical considerations underlying this change that are
> also related to usability changes, like editors having a chance to
> properly identify and indent parts of an expression.
>
> It is not possible to let an argument-less scheme function work in the
> same manner/syntax as a fixed context modification works right now.
> Fixing that comes at a high cost, basically requiring special-casing
> scheme functions in a similar vein as now music/event functions are
> special-cased. Which is something that makes it impossible to create
> structures of music/event functions and other things.
Sigh. I make a hash of my communication. This sounds just like a rant.
But the "Why?" was actually an honest question. A lot of the work I do
is focused about making entry more convenient and better reflecting the
writers' ways of thinking about music. LilyPond has sort-of a free-form
syntax that tends to create quite a few ambiguities. So there are some
balancing acts involved here.
Now in this case I was working on some parser refactoring and it dumped
out something like a dozen shift/reduce conflicts (meaning ambiguities
in the resulting syntax in need of resolution) of which more than a
third were due to the \with thing. The particular stuff I was working
on was of the
xxx = ...
\xxx
variety where xxx needs to get consulted to decide whether it is still
part of ... or not. Now many such decisions can be made on the basis
"anything of form \xxx cannot become part of ...". For example, if I
allow a.b and have seen a, I only need to know whether the next token is
. or not, and I don't need to know what value/type \xxx has, only that
it is not a period.
But to make decisions on that level, \xxx basically falls into two
tokens, the first just saying "this is an escaped identifier" and the
second actually looking at the type of xxx.
Now the parser works only with very limited and specific lookahead. If
I split escape sequences like \xxx into two tokens effectively, the
parser stops being able to make some decisions timely that it currently
still can do with a lookahead of a single token.
I am still making a hash of my communication. Being able to omit \with
comes at a cost in complexity because
\new Staff \xxx
causes completely different syntactical meaning depending on whether
\xxx is a context modification or music. When writing
\new Staff \with { \xxx }
\xxx _still_ can be either a music expression (like \hide BarLine) or a
context modification, but at that point it does not cause a complete
rewiring of the parse tree: LilyPond can just evaluate, take a look at
the resulting expression, and then decide what to do with it, namely
_how_ to make it part of the resulting context modification. There is
still ambiguity but it does not influence how to parse the expression.
So being able to omit \with comes at a cost, and it works only with
fixed identifiers. So how to justify the cost? And that's where "why?"
comes into play. User friendliness is an argument.
Now personally, I find it distracting to see something like
\RemoveEmptyStaves without \with. I haven't omitted it myself, and it's
present in most of LilyPond's documentation and examples as well (the
convert-ly rule has very little actual impact on the code).
Independently of just having figured out or remembered that this thing
comes at a non-zero cost in Bison parsing complexity.
Obviously, that's not how you feel about the construct. So I have
historically already felt bad about the construct and avoided it, and
the LilyPond code base does look like particularly embracing it either
even though it's been basically available forever. It's always sort of
a bad feeling to let something stop working but I judged the cost and
said "ok, nobody seems to particularly want that anyway".
Obviously, I was wrong about that and need to reestimate the cost.
I might still end up with the same decision after considering all
available information. But right now I am obviously missing
information.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Thomas Morley writes:
> 2016-07-01 7:05 GMT+02:00 David Kastrup :
>> Thomas Morley writes:
>
>>> %% works:
>>> tstII =
>>> \with { instrumentName = "foo" shortInstrumentName = "foo" }
>>> \new Staff \tstII { r1 }
>>
>> Issue 4911 is supposed to harmonize this by stopping the second example
>> from working. This makes it possible to recognize the syntax without
>> knowing the type of \tstII in advance (could be a music expression,
>> leading to completely different structure).
>
> I'm in two minds here.
> Hormonizing code is always preferable, but being able to spare the
> extra \with would be nice as well.
Why? There are technical considerations underlying this change that are
also related to usability changes, like editors having a chance to
properly identify and indent parts of an expression.
It is not possible to let an argument-less scheme function work in the
same manner/syntax as a fixed context modification works right now.
Fixing that comes at a high cost, basically requiring special-casing
scheme functions in a similar vein as now music/event functions are
special-cased. Which is something that makes it impossible to create
structures of music/event functions and other things.
> To join both while letting it recognizable I tried:
>
> #(defmacro-public define-with-function rest
> `(define-syntax-function ly:context-mod? ,@rest))
>
> tstI =
> #(define-with-function ()() #{ \with { instrumentName = "-name-" } #})
>
> \new Staff \tstI { r1 }
>
> Doesn't work.
> A mistake somewhere or is it all rubbish?
Context mod functions are not special-cased. If you write
(define my-music? (lambda (x) (ly:music? x)))
(define-syntax-function my-music? ...)
the result will stop working as a music function. Similar for event
functions. But at the current point of time, those are the only two
special-cased function types. I want to decrease rather than increase
the number of special-cases here.
>>> %%(3)
>>> #(define (set-instrument-names-to-number-string nmbr mus)
>>> (if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic)
>>> (ly:music-set-property! mus 'property-operations
>>> (list
>>> (list
>>> 'assign
>>> 'instrumentName
>>> (format #f "~a." nmbr))
>>> (list
>>> 'assign
>>> 'shortInstrumentName
>>> (format #f "~a." nmbr
>>> mus)
>>> mus)
>>>
>>> tst =
>>> #(define-music-function (nmbr mus)(number? ly:music?)
>>> (set-instrument-names-to-number-string nmbr mus))
>>>
>>> \tst #3 \new Staff { r1 }
>>
>> Hm. At the current point of time, destructuring expression requires
>> Scheme programming. And absorbing \new Staff into \tst #3 makes things
>> much less flexible (\context Staff = "..." just becomes impossible
>> then).
>
> Wasn't aware of this problem. Thanks spotting it.
No, you misunderstand. This is not a problem with your code. It's
rather a complaint that there is no reasonably better or more readable
way to write your code while keeping it working for a similarly large
number of use cases.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
2016-07-01 7:05 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>> %% works:
>> tstII =
>> \with { instrumentName = "foo" shortInstrumentName = "foo" }
>> \new Staff \tstII { r1 }
>
> Issue 4911 is supposed to harmonize this by stopping the second example
> from working. This makes it possible to recognize the syntax without
> knowing the type of \tstII in advance (could be a music expression,
> leading to completely different structure).
I'm in two minds here.
Hormonizing code is always preferable, but being able to spare the
extra \with would be nice as well.
To join both while letting it recognizable I tried:
#(defmacro-public define-with-function rest
`(define-syntax-function ly:context-mod? ,@rest))
tstI =
#(define-with-function ()() #{ \with { instrumentName = "-name-" } #})
\new Staff \tstI { r1 }
Doesn't work.
A mistake somewhere or is it all rubbish?
>> %%(3)
>> #(define (set-instrument-names-to-number-string nmbr mus)
>> (if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic)
>> (ly:music-set-property! mus 'property-operations
>> (list
>> (list
>> 'assign
>> 'instrumentName
>> (format #f "~a." nmbr))
>> (list
>> 'assign
>> 'shortInstrumentName
>> (format #f "~a." nmbr
>> mus)
>> mus)
>>
>> tst =
>> #(define-music-function (nmbr mus)(number? ly:music?)
>> (set-instrument-names-to-number-string nmbr mus))
>>
>> \tst #3 \new Staff { r1 }
>
> Hm. At the current point of time, destructuring expression requires
> Scheme programming. And absorbing \new Staff into \tst #3 makes things
> much less flexible (\context Staff = "..." just becomes impossible
> then).
Wasn't aware of this problem. Thanks spotting it.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Thomas Morley writes:
> 2016-07-01 0:05 GMT+02:00 Br. Gabriel-Marie | SSPX :
>> Thanks, Mr. Meyn,
>>
>> That certainly does the trick.
>>
>> So you can't write macros for \with{} statements?
>> Why couldn't I do it this way, if I just want to create the \with statement?
>
> Obviously a call of a scheme-function is not allowed instead of a
> \with-expression, opposed to a static value stored in vavariable:
>
> \version "2.19.44"
>
> %% fails:
> tstI =
> #(define-scheme-function ()()
> #{ \with { instrumentName = "foo" shortInstrumentName = "foo" } #})
> \new Staff \tstI { r1 }
>
> %% works:
> tstII =
> \with { instrumentName = "foo" shortInstrumentName = "foo" }
> \new Staff \tstII { r1 }
Issue 4911 is supposed to harmonize this by stopping the second example
from working. This makes it possible to recognize the syntax without
knowing the type of \tstII in advance (could be a music expression,
leading to completely different structure).
> There are other possibilities, though:
>
> \version "2.19.44"
>
> %% (1)
> #(define (foo nmbr)
> #{
> \with {
> instrumentName = #(format #f "~a." nmbr)
> shortInstrumentName = #(format #f "~a." nmbr)
> }
> #})
>
> \new Staff $(foo 1) { r1 }
Will also stop working.
> %%(2)
> buzz =
> #(define-scheme-function (nmbr)(number?)
> #{
> \with {
> instrumentName = #(format #f "~a." nmbr)
> shortInstrumentName = #(format #f "~a." nmbr)
> }
> #})
> \new Staff \with { \buzz #2 } { r1 }
\new Staff \with \buzz #2 { r1 }
is also possible.
> %%(3)
> #(define (set-instrument-names-to-number-string nmbr mus)
> (if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic)
> (ly:music-set-property! mus 'property-operations
> (list
> (list
> 'assign
> 'instrumentName
> (format #f "~a." nmbr))
> (list
> 'assign
> 'shortInstrumentName
> (format #f "~a." nmbr
> mus)
> mus)
>
> tst =
> #(define-music-function (nmbr mus)(number? ly:music?)
> (set-instrument-names-to-number-string nmbr mus))
>
> \tst #3 \new Staff { r1 }
Hm. At the current point of time, destructuring expression requires
Scheme programming. And absorbing \new Staff into \tst #3 makes things
much less flexible (\context Staff = "..." just becomes impossible
then). Don't really like that approach, even though stuff like \once,
\temporary and a few others have been implemented in that manner.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
2016-07-01 0:05 GMT+02:00 Br. Gabriel-Marie | SSPX :
> Thanks, Mr. Meyn,
>
> That certainly does the trick.
>
> So you can't write macros for \with{} statements?
> Why couldn't I do it this way, if I just want to create the \with statement?
Obviously a call of a scheme-function is not allowed instead of a
\with-expression, opposed to a static value stored in vavariable:
\version "2.19.44"
%% fails:
tstI =
#(define-scheme-function ()()
#{ \with { instrumentName = "foo" shortInstrumentName = "foo" } #})
\new Staff \tstI { r1 }
%% works:
tstII =
\with { instrumentName = "foo" shortInstrumentName = "foo" }
\new Staff \tstII { r1 }
There are other possibilities, though:
\version "2.19.44"
%% (1)
#(define (foo nmbr)
#{
\with {
instrumentName = #(format #f "~a." nmbr)
shortInstrumentName = #(format #f "~a." nmbr)
}
#})
\new Staff $(foo 1) { r1 }
%%(2)
buzz =
#(define-scheme-function (nmbr)(number?)
#{
\with {
instrumentName = #(format #f "~a." nmbr)
shortInstrumentName = #(format #f "~a." nmbr)
}
#})
\new Staff \with { \buzz #2 } { r1 }
%%(3)
#(define (set-instrument-names-to-number-string nmbr mus)
(if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic)
(ly:music-set-property! mus 'property-operations
(list
(list
'assign
'instrumentName
(format #f "~a." nmbr))
(list
'assign
'shortInstrumentName
(format #f "~a." nmbr
mus)
mus)
tst =
#(define-music-function (nmbr mus)(number? ly:music?)
(set-instrument-names-to-number-string nmbr mus))
\tst #3 \new Staff { r1 }
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
"Br. Gabriel-Marie | SSPX" writes:
> In my music script I want to use this:
>
> \new Lyrics \with { instrumentName = "1." shortInstrumentName = "1." }
>
> However, I would like to make a function out of it. I'm looking at
> this page:
> http://lilypond.org/doc/v2.18/Documentation/learning/saving-typing-with-variables-and-functions
>
> and this is what I have come up with, but I know this isn't right. Can
> someone correct this for me?
> Basically, I want to do this:
> \new Lyrics \verseNumber #1
>
> and have it create this:
> \new Lyrics \with { instrumentName = "1." shortInstrumentName = "1." }
>
> verseNumber = #(define-music-function(parser location whatnumber)(
> number?) #{ \with { instrumentName = #whatnumber "."
> shortInstrumentName = #whatnumber "." } #}
You need define-scheme-function here, and you cannot just put numbers
and strings next to each other and hope that LilyPond will somehow make
a string from that. You could try #(format "~a." whatnumber) here.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Thanks, Mr. Meyn,
That certainly does the trick.
So you can't write macros for \with{} statements?
Why couldn't I do it this way, if I just want to create the
\with statement?
Where can I find the docs to explain how the macro works?
(I've looked all over)
verseNumber = #(define-music-function(whatnumber)(string?)#{
\with { instrumentName = whatnumber shortInstrumentName =
whatnumber } #})
On 6/30/2016 4:54 PM, lilypond-user-requ...@gnu.org wrote:
This would have to be \new Lyrics \with { \verseNumber 1 } or, easier to
type, \lyricsWithVerseNumber 1 like in the code below:
\version "2.18.2"
lyricsWithVerseNumber =
#(define-music-function
(parser location number music)
(number? ly:music?)
#{
\new Lyrics \with {
instrumentName =
#(string-append (number->string number) ".")
shortInstrumentName =
#(string-append (number->string number) ".")
}
$music
#})
\lyricsWithVerseNumber 7
\lyricmode { \repeat unfold 40 foo }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
I've also tried this, but I get a compiler error for "wrong
number of arguments", which makes me wonder if I can replace
whatnumber more than once.
verseNumber = #(define-music-function(whatnumber)(string?)#{
\with { instrumentName = whatnumber shortInstrumentName
= whatnumber }
#})
On 6/30/2016 3:59 PM, Jeffery Shivers wrote:
In my music script I want to use this:
\new Lyrics \with { instrumentName = "1."
shortInstrumentName = "1." }
However, I would like to make a function out of it. I'm
looking at this page:
http://lilypond.org/doc/v2.18/Documentation/learning/saving-typing-with-variables-and-functions
and this is what I have come up with, but I know this
isn't right. Can someone correct this for me?
Basically, I want to do this:
\new Lyrics \verseNumber #1
and have it create this:
\new Lyrics \with { instrumentName = "1."
shortInstrumentName = "1." }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
No, I *want* to use instrument names, not stanza numbers.
But my question isn't about that.
I am trying to figure out how to write a function where I
can supply the value for a variable inside it.
myfunction(somevar){
;do stuff
}
If were programming in a coding language, I would do this:
addVerseNumber(whatnumber){
return "\new Lyrics \with { instrumentName = whatnumber
. "." shortInstrumentName = whatnumber . "." }}"
}
On 6/30/2016 3:59 PM, Jeffery Shivers wrote:
Hi Gabriel-Marie,
Could you describe in context what you are trying to
achieve? Are you meaning to apply *stanza* number, rather
than instrument names? Have a look at:
http://lilypond.org/doc/v2.19/Documentation/notation/stanzas
HTH,
Jeffery
On Thu, Jun 30, 2016 at 4:37 PM, Br. Gabriel-Marie | SSPX
mailto:brgabr...@sspx.org>> wrote:
In my music script I want to use this:
\new Lyrics \with { instrumentName = "1."
shortInstrumentName = "1." }
However, I would like to make a function out of it.
I'm looking at this page:
http://lilypond.org/doc/v2.18/Documentation/learning/saving-typing-with-variables-and-functions
and this is what I have come up with, but I know this
isn't right. Can someone correct this for me?
Basically, I want to do this:
\new Lyrics \verseNumber #1
and have it create this:
\new Lyrics \with { instrumentName = "1."
shortInstrumentName = "1." }
verseNumber = #(define-music-function(parser location
whatnumber)( number?) #{ \with { instrumentName =
#whatnumber "." shortInstrumentName = #whatnumber "." } #}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Am 30.06.2016 um 22:59 schrieb Jeffery Shivers: Hi Gabriel-Marie, Could you describe in context what you are trying to achieve? Are you meaning to apply *stanza* number, rather than instrument names? Have a look at: No he doesn’t, he wants stanzas at the beginning of every line, see the thread at http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00469.html Of course, if there was a way to use stanza instead of abusing instrumentName that would be even better ;) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Am 30.06.2016 um 22:37 schrieb Br. Gabriel-Marie | SSPX:
\new Lyrics \verseNumber #1
This would have to be \new Lyrics \with { \verseNumber 1 } or, easier to
type, \lyricsWithVerseNumber 1 like in the code below:
\version "2.18.2"
lyricsWithVerseNumber =
#(define-music-function
(parser location number music)
(number? ly:music?)
#{
\new Lyrics \with {
instrumentName =
#(string-append (number->string number) ".")
shortInstrumentName =
#(string-append (number->string number) ".")
}
$music
#})
\lyricsWithVerseNumber 7
\lyricmode { \repeat unfold 40 foo }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tiny function
Hi Gabriel-Marie,
Could you describe in context what you are trying to achieve? Are you
meaning to apply *stanza* number, rather than instrument names? Have a look
at:
http://lilypond.org/doc/v2.19/Documentation/notation/stanzas
HTH,
Jeffery
On Thu, Jun 30, 2016 at 4:37 PM, Br. Gabriel-Marie | SSPX <
brgabr...@sspx.org> wrote:
> In my music script I want to use this:
>
> \new Lyrics \with { instrumentName = "1." shortInstrumentName = "1." }
>
> However, I would like to make a function out of it. I'm looking at this
> page:
>
> http://lilypond.org/doc/v2.18/Documentation/learning/saving-typing-with-variables-and-functions
>
> and this is what I have come up with, but I know this isn't right. Can
> someone correct this for me?
> Basically, I want to do this:
> \new Lyrics \verseNumber #1
>
> and have it create this:
> \new Lyrics \with { instrumentName = "1." shortInstrumentName = "1." }
>
> verseNumber = #(define-music-function(parser location whatnumber)(
> number?) #{ \with { instrumentName = #whatnumber "." shortInstrumentName =
> #whatnumber "." } #}
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
