Re: Making two functions into one
Jean Abou Samra writes: > There is also > > https://extending-lilypond.readthedocs.io/en/latest/lily-and-scheme.html#hash-vs-dollar > > (This is an instance where the official extending manual seems > much too technical and example-less to me ...) Well, as developer I tend to write up basic descriptions of functionality, in the expectation that somebody™ will take it up and translate it into something more digestible. It's more "documentation" of what I did than hands-on instructions. Writing examples is way more arbitrary than writing functionality, so it's a comparatively painful mental effort I tend not to end up vigourously embracing. Sorry for that. -- David Kastrup
Re: Making two functions into one
Le 16/01/2023 à 22:58, David Kastrup a écrit : From the Lilypond-Extending manual: 1.2.1 LilyPond Scheme syntax The Guile interpreter is part of LilyPond, which means that Scheme can be included in LilyPond input files. There are several methods for including Scheme in LilyPond. The simplest way is to use a hash mark ‘#’ before a Scheme expression. Now LilyPond’s input is structured into tokens and expressions, much like human language is structured into words and sentences. LilyPond has a lexer that recognizes tokens (literal numbers, strings, Scheme elements, pitches and so on), and a parser that understands the syntax, *note (lilypond-contributor)LilyPond grammar::. Once it knows that a particular syntax rule applies, it executes actions associated with it. The hash mark ‘#’ method of embedding Scheme is a natural fit for this system. Once the lexer sees a hash mark, it calls the Scheme reader to read one full Scheme expression (this can be an identifier, an expression enclosed in parentheses, or several other things). After the Scheme expression is read, it is stored away as the value for an ‘SCM_TOKEN’ in the grammar. Once the parser knows how to make use of this token, it calls Guile for evaluating the Scheme expression. Since the parser usually requires a bit of lookahead from the lexer to make its parsing decisions, this separation of reading and evaluation between lexer and parser is exactly what is needed to keep the execution of LilyPond and Scheme expressions in sync. For this reason, you should use the hash mark ‘#’ for calling Scheme whenever this is feasible. Another way to call the Scheme interpreter from LilyPond is the use of dollar ‘$’ instead of a hash mark for introducing Scheme expressions. In this case, LilyPond evaluates the code right after the lexer has read it. It checks the resulting type of the Scheme expression and then picks a token type (one of several ‘xxx_IDENTIFIER’ in the syntax) for it. It creates a _copy_ of the value and uses that for the value of the token. If the value of the expression is void (Guile’s value of ‘*unspecified*’), nothing at all is passed to the parser. This is, in fact, exactly the same mechanism that LilyPond employs when you call any variable or music function by name, as ‘\name’, with the only difference that the name is determined by the LilyPond lexer without consulting the Scheme reader, and thus only variable names consistent with the current LilyPond mode are accepted. The immediate action of ‘$’ can lead to surprises, see *note Importing Scheme in LilyPond::. Using ‘#’ where the parser supports it is usually preferable. Inside of music expressions, expressions created using ‘#’ _are_ interpreted as music. However, they are _not_ copied before use. If they are part of some structure that might still get used, you may need to use ‘ly:music-deep-copy’ explicitly. There are also ‘list splicing’ operators ‘$@’ and ‘#@’ that insert all elements of a list in the surrounding context. There is also https://extending-lilypond.readthedocs.io/en/latest/lily-and-scheme.html#hash-vs-dollar (This is an instance where the official extending manual seems much too technical and example-less to me ...) OpenPGP_signature Description: OpenPGP digital signature
Re: Making two functions into one
| || | | writes: > Thank you Valentin, > > That was simpler than I thought. Of curse I tried first with lily code > blocks, but have been struggling with > > \time #number/8 (which doesn't work because it needs pair but gets > int). It gets an undefined symbol called number/8 . What you could write here is \time #(cons number 8) It turns out that fractions cannot be assembled piecemeal in LilyPond syntax. > There is some kind of coding convention? Both # and $ seems to work > the same. >From the Lilypond-Extending manual: 1.2.1 LilyPond Scheme syntax The Guile interpreter is part of LilyPond, which means that Scheme can be included in LilyPond input files. There are several methods for including Scheme in LilyPond. The simplest way is to use a hash mark ‘#’ before a Scheme expression. Now LilyPond’s input is structured into tokens and expressions, much like human language is structured into words and sentences. LilyPond has a lexer that recognizes tokens (literal numbers, strings, Scheme elements, pitches and so on), and a parser that understands the syntax, *note (lilypond-contributor)LilyPond grammar::. Once it knows that a particular syntax rule applies, it executes actions associated with it. The hash mark ‘#’ method of embedding Scheme is a natural fit for this system. Once the lexer sees a hash mark, it calls the Scheme reader to read one full Scheme expression (this can be an identifier, an expression enclosed in parentheses, or several other things). After the Scheme expression is read, it is stored away as the value for an ‘SCM_TOKEN’ in the grammar. Once the parser knows how to make use of this token, it calls Guile for evaluating the Scheme expression. Since the parser usually requires a bit of lookahead from the lexer to make its parsing decisions, this separation of reading and evaluation between lexer and parser is exactly what is needed to keep the execution of LilyPond and Scheme expressions in sync. For this reason, you should use the hash mark ‘#’ for calling Scheme whenever this is feasible. Another way to call the Scheme interpreter from LilyPond is the use of dollar ‘$’ instead of a hash mark for introducing Scheme expressions. In this case, LilyPond evaluates the code right after the lexer has read it. It checks the resulting type of the Scheme expression and then picks a token type (one of several ‘xxx_IDENTIFIER’ in the syntax) for it. It creates a _copy_ of the value and uses that for the value of the token. If the value of the expression is void (Guile’s value of ‘*unspecified*’), nothing at all is passed to the parser. This is, in fact, exactly the same mechanism that LilyPond employs when you call any variable or music function by name, as ‘\name’, with the only difference that the name is determined by the LilyPond lexer without consulting the Scheme reader, and thus only variable names consistent with the current LilyPond mode are accepted. The immediate action of ‘$’ can lead to surprises, see *note Importing Scheme in LilyPond::. Using ‘#’ where the parser supports it is usually preferable. Inside of music expressions, expressions created using ‘#’ _are_ interpreted as music. However, they are _not_ copied before use. If they are part of some structure that might still get used, you may need to use ‘ly:music-deep-copy’ explicitly. There are also ‘list splicing’ operators ‘$@’ and ‘#@’ that insert all elements of a list in the surrounding context. -- David Kastrup
Re: Making two functions into one
Thank you Valentin,
That was simpler than I thought. Of curse I tried first with lily code
blocks, but have been struggling with
\time #number/8 (which doesn't work because it needs pair but gets int).
Would you like to short explain difference between usage of $ and # or
point me to place when I can understand it?
There is some kind of coding convention? Both # and $ seems to work the
same.
Cheers!
W dniu 16.01.2023 o 15:32, Valentin Petzel pisze:
Hello,
not sure about that one, but this seems to work:
\version "2.24.0"
nd = #(define-music-function (number) (integer?)
#{
#(time (cons number 8))
s8 * $number
#})
\score {
\new Staff {
\nd 8
\nd 7
}
}
Cheers,
Valentin
Re: Making two functions into one
Le 16/01/2023 à 15:12, | || | | a écrit : So I thought about delete one nested (list) and try it: nd = #(define-music-function (number) (integer?) (make-music 'TimeSignatureMusic 'numerator 8 'denominator 8 'beat-structure '()) (make-music 'UnfoldedRepeatedMusic 'elements '() 'repeat-count 8 'element (make-music 'SequentialMusic 'elements (list (make-music 'SkipEvent 'duration (ly:make-duration 3)) But the problem is, when I don't use (list) for two adjacent (make-music) functions, one of them doesn't run, so depending on the kind of second (make-music) code, one od them goes, another don't. David already explained the missing 'origin. I just want to explain why this drops the first expression: it has nothing to do with LilyPond, it's just the way Scheme works. When you have a sequence of expressions like this in the body of a function, they are evaluated in turn, and the value of the last one is returned. The others are discarded. They can only be useful if they have "side effects", like (display ...) for example. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Spontini-Editor 1.20 released
Il lun 16 gen 2023, 19:04 Knute Snortum ha scritto: > On Mon, Jan 16, 2023 at 4:59 AM Paolo Prete wrote: > > > > Hi, > > > > A new release (1.20-alpha) of Spontini-Editor is available at: > > > > https://github.com/paopre/Spontini/releases/tag/1.20_alfa > > > > It includes two important features: > > > > 1) The application is now _totally_ no-install. > > Not quite for me. I'm on Ubuntu 22.04.1 and I needed to add three > dependencies before the server would start: > > $ python SpontiniServer.py > Traceback (most recent call last): > File "/home/knute/git-repos/Spontini/SpontiniServer.py", line 22, in > > You just have to run the executable, not the .py file.
Re: Spontini-Editor 1.20 released
On Mon, Jan 16, 2023 at 4:59 AM Paolo Prete wrote: > > Hi, > > A new release (1.20-alpha) of Spontini-Editor is available at: > > https://github.com/paopre/Spontini/releases/tag/1.20_alfa > > It includes two important features: > > 1) The application is now _totally_ no-install. Not quite for me. I'm on Ubuntu 22.04.1 and I needed to add three dependencies before the server would start: $ python SpontiniServer.py Traceback (most recent call last): File "/home/knute/git-repos/Spontini/SpontiniServer.py", line 22, in from lib.python.spontini_server_utils import * File "/home/knute/git-repos/Spontini/lib/python/spontini_server_utils.py", line 40, in import colorlog ModuleNotFoundError: No module named 'colorlog' $ python SpontiniServer.py Traceback (most recent call last): File "/home/knute/git-repos/Spontini/SpontiniServer.py", line 25, in import uvicorn ModuleNotFoundError: No module named 'uvicorn' $ python SpontiniServer.py Traceback (most recent call last): File "/home/knute/git-repos/Spontini/SpontiniServer.py", line 31, in import httpx ModuleNotFoundError: No module named 'httpx' -- Knute Snortum
Re: Unicode accidentals vs. Markup accidentals
On Sun 15 Jan 2023 at 22:52:50 (-0800), Saul Tobin wrote: > Lilypond ships with a text font as well as a music font. I agree that I > suspect that currently Lilypond's text font does not actually define these > Unicode music characters, so it falls back on the OS to find them. Why not > just add copies of Emmentaler glyphs to the Lilypond text fonts for > characters within the Unicode spec? That seems like a pretty reasonable > suggestion to me... It might be worth thinking about where you would draw the line between glyphs you would replace and those you wouldn't. After all, your original post, and the Subject line, only dealt with accidentals, but should you replace the entire Music Symbols Unicode Block, including the combining forms, and fine tune them all so that the Emmentaler would match LP's text font? (Some glyphs in the Block are also accidentals.) Cheers, David.
Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals
Le 16/01/2023 à 16:57, Kieren MacMillan a écrit :
Hi all,
In any case, please submit this to the LSR!
I was *just* going to look at this to see if it could be improved viz-a-viz
Jean’s suggestion that callbacks using after-line-breaking are often better
done with grob-transformer. [Yes, I know this is *before*-line-breaking…] If
so, that should happen before LSR submission, I would think!
Maybe Someone™ can just tell me if it’s worth investigating or not…?
In this case, you cannot use \override TextScript.text =
#(grob-transformer 'text ...)
because Text_engraver sets the property on the TextScript, so this
overwrites
any overrides you might have done. However, you could do
\version "2.24.0"
tsharp = \markup \fontsize #-2 \number "♯"
tflat = \markup \fontsize #-2 \number "♭"
tnatural = \markup \fontsize #-2 \number "♮"
\new Staff {
\override TextScript.stencil =
#(lambda (grob)
(let ((text (ly:grob-property grob 'text)))
(grob-interpret-markup
grob
#{ \markup \replace #`(("♭" . ,#{ \markup \tflat #})
("♯" . ,#{ \markup \tsharp #})
("♮" . ,#{ \markup \tnatural #}))
#text #})))
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
}
Although it's probably simplest to do
\version "2.24.0"
\paper {
#(add-text-replacements!
`(("♯" . ,#{ \markup \fontsize #-2 \number "♯" #})
("♭" . ,#{ \markup \fontsize #-2 \number "♭" #})
("♮" . ,#{ \markup \fontsize #-2 \number "♮" #})))
}
\markup { A♯ B♭ C♮ }
\score {
\header {
piece = "Prelude in C♯"
}
{
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
}
}
As you can see, add-text-replacements! install the replacements
for all places markup can be used, not just for TextScript.
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: Unicode accidentals vs. Markup accidentals
>>> Is there a possibility to register this or a similar function globally >>> so that all markup strings can use it? > > It is the same mechanism, and add-text-replacements! answers > Werner’s question. Thanks. I only did a quick index search for 'replace' in the NR, and there was no hit. This is now https://gitlab.com/lilypond/lilypond/-/merge_requests/1814 Werner
Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals
Hi all, > In any case, please submit this to the LSR! I was *just* going to look at this to see if it could be improved viz-a-viz Jean’s suggestion that callbacks using after-line-breaking are often better done with grob-transformer. [Yes, I know this is *before*-line-breaking…] If so, that should happen before LSR submission, I would think! Maybe Someone™ can just tell me if it’s worth investigating or not…? Thanks Kieren.
Re: Spontini-Editor 1.20 released
Thanks for your feedback! BTW: the editor is ready to be used as an alternative to LilyBin, which is currently down and not updated, I always hope that in some way we can obtain free hosting and storage for it... On Mon, Jan 16, 2023 at 2:59 PM Karlin High wrote: > On Mon, Jan 16, 2023 at 6:59 AM Paolo Prete wrote: > > A new release (1.20-alpha) of Spontini-Editor is available > > Looks very nice so far! I have it running on Windows 10, will explore > further. > -- > Karlin High > Missouri, USA >
Re: Repeat segno weirdness
Your first assessment solved the problem...it was all in how I looked at
what I was trying to accomplish. The example in the wiki/docs implied that
I needed the \volta statements, and that the first alternate was where the
bulk of the song was supposed to be.
Thanks, Valentin!
On Mon, Jan 16, 2023 at 7:42 AM Valentin Petzel wrote:
> Hello Jeff,
>
> If I were to reduce what you are doing we’d have something like this
>
> \relative c'' {
> R1*4 \bar "||"
> \repeat segno 2 {
> \alternative {
> { R1*4 }
> {
> \section
> \sectionLabel "Coda"
> }
> }
> }
>
> % Coda
> R1*4
> }
>
> So you are basically telling Lilypond: After some measures we have a
> segno,
> then the first time we play this part, then we jump back to the segno, but
> skipt the whole repeat part and directly jump to the coda, which Lilypond
> correctly indicates by putting a volta bracket over the whole thing
> (actually
> you are almost asking for the volta bracket by manually specifying \volta
> 1).
> I suppose what you actually want to say is:
>
> After some measures we have a segno, then we have the repeat part, at the
> end
> we jump back to segno, repeat the repeat part and then jump to coda, which
> would be done like this:
>
> \relative c'' {
> R1*4 \bar "||"
> \repeat segno 2 {
> R1*4
> \alternative {
> { }
> {
> \section
> \sectionLabel "Coda"
> % Coda
> R1*4
> }
> }
> }
> }
>
> Alternatively if you want to have: After some measures put a segno, play
> the
> repeat part, jump back to segno, play only part of the repeat part and
> jump to
> coda you’d do:
>
> \relative c'' {
> R1*4 \bar "||"
> \repeat segno 2 {
> R1*2
> \alternative {
> { R1*2 }
> {
> \section
> \sectionLabel "Coda"
> % Coda
> R1*4
> }
> }
> }
> }
>
> The marks used for the segnos and codas and dal segnos and poi la codas
> and
> stuff can be set to whatever you want.
>
> Cheers,
> Valentin
>
> Am Montag, 16. Jänner 2023, 07:50:04 CET schrieb Jeff Kopmanis:
> > I'm using lilypond 2.24.0, and am having a problem that I can't identify
> > with a \repeat segno structure. I've enclosed the .ly and .pdf files.
> It
> > compiles cleanly, and displays mostly correct, but there's a curious "1st
> > ending" (a volta spanner?) that appears, and I can't figure out where
> it's
> > coming from. I've run the \repeat segno sample code from the docs and it
> > doesn't behave this way, but with my score, it does it without fail.
> I've
> > attached the resultant PDF to illustrate this 1st ending that lasts until
> > the coda. I found the example big band score code online and it seemed
> > pretty straight-forward, and without the \repeat segno structures, it
> works
> > fine, so there's some option that's defaulting, or something extra that's
> > missing to produce this odd behavior.
> >
> > I'm at a loss at what's causing this. Help!
> >
> > -Jeff. :)
>
>
--
*Jeff Kopmanis*
Medium: https://kopmanis.medium.com
GLAAC: https://www.glaac.org/
University Lowbrow Astronomers: http://umich.edu/~lowbrows
Orange Can Astronomy: https://www.facebook.com/orangecanastronomy/
** Go Green and leave this email on the Screen! **
Re: Making two functions into one
Valentin Petzel writes:
> Hello,
>
> not sure about that one, but this seems to work:
>
> \version "2.24.0"
>
> nd = #(define-music-function (number) (integer?)
> #{
>#(time (cons number 8))
>s8 * $number
> #})
LilyPond syntax expressions, like in #{ ... #}, attach origin
information automatically. If you want things to happen automatically,
Scheme is not the way to go...
--
David Kastrup
Re: Making two functions into one
| || | | writes:
> I would like to make a function which will be responsible for two things:
>
> 1. Change time signature
>
> 2. Fill empty bar with 's8'
>
> I made this one, but there is a problem with point'n'click function,
> so I can't click on time signature to go to correspondent place in
> code:
>
> \version "2.24.0"
>
> nd = #(define-music-function (number) (integer?)
> (list (make-music
> 'SequentialMusic
> 'elements
> (list (make-music
> 'TimeSignatureMusic
> 'numerator
> number
> 'denominator
> 8
> 'beat-structure
> '(
[...]
> So I thought about delete one nested (list) and try it:
> Honestly, I don't understand why it's like that, because when I run
> displayScheme{}, it display it properly without (list) and
> SquentialMusic for this two events. I suspect it could be something
> wrong with my definition.
You need to look closer at the difference of your displayScheme results.
Your above definition is missing the element
'origin (*location*)
in the make-music function arguments. A music function automatically
tacks them onto the top music expression but not on everything below.
Without origin information, point-and-click has no way to know where to
go. I am not sure what magic you imagine to be doing that job for
you...
--
David Kastrup
Re: Making two functions into one
Hello,
not sure about that one, but this seems to work:
\version "2.24.0"
nd = #(define-music-function (number) (integer?)
#{
#(time (cons number 8))
s8 * $number
#})
\score {
\new Staff {
\nd 8
\nd 7
}
}
Cheers,
Valentin
Am Montag, 16. Jänner 2023, 15:12:15 CET schrieb | || | |:
> Hi,
>
> I would like to make a function which will be responsible for two things:
>
> 1. Change time signature
>
> 2. Fill empty bar with 's8'
>
> I made this one, but there is a problem with point'n'click function, so
> I can't click on time signature to go to correspondent place in code:
>
> \version "2.24.0"
>
> nd = #(define-music-function (number) (integer?)
> (make-music
>'SequentialMusic
>'elements
>(list (make-music
>'SequentialMusic
>'elements
>(list (make-music
>'TimeSignatureMusic
>'numerator
>number
>'denominator
>8
>'beat-structure
>'(
> (make-music
>'UnfoldedRepeatedMusic
>'elements
>'()
>'repeat-count
>number
>'element
>(make-music
> 'SequentialMusic
> 'elements
> (list (make-music
> 'SkipEvent
> 'duration
> (ly:make-duration 3)))
>)
>
> \score {
>\new Staff {
>
> \nd 8
> \nd 7
>}
> }
>
>
> So I thought about delete one nested (list) and try it:
>
> nd = #(define-music-function (number) (integer?)
>(make-music
>'TimeSignatureMusic
>'numerator
>8
>'denominator
>8
>'beat-structure
>'())
> (make-music
>'UnfoldedRepeatedMusic
>'elements
>'()
>'repeat-count
>8
>'element
>(make-music
> 'SequentialMusic
> 'elements
> (list (make-music
> 'SkipEvent
> 'duration
> (ly:make-duration 3))
>
>
> But the problem is, when I don't use (list) for two adjacent
> (make-music) functions, one of them doesn't run, so depending on the
> kind of second (make-music) code, one od them goes, another don't.
>
> Honestly, I don't understand why it's like that, because when I run
> displayScheme{}, it display it properly without (list) and
> SquentialMusic for this two events. I suspect it could be something
> wrong with my definition.
>
>
> Thank you :)
signature.asc
Description: This is a digitally signed message part.
Re: Unicode accidentals vs. Markup accidentals, Re: Unicode accidentals vs. Markup accidentals
> Le 16 janv. 2023 à 15:07, Mark Knoop a écrit :
>
>
> At 12:51 on 16 Jan 2023, Werner LEMBERG wrote:
>>> \new Staff {
>>> \override TextScript.before-line-breaking =
>>> #(lambda (grob)
>>> (ly:grob-set-property! grob 'text
>>>(markup #:replace
>>>`(("♭" . ,#{ \markup{ \tflat} #})
>>> ("♯" . ,#{ \markup{ \tsharp} #})
>>> ("♮" . ,#{ \markup{ \tnatural} #}))
>>>(ly:grob-property grob 'text
>>> c'1^"B♭"
>>> c'1^"C♯"
>>> c'1^"D♮"
>>> }
>
>> *This* is nice! It sort-of corresponds to 'active characters' in TeX.
>> Is there a possibility to register this or a similar function globally
>> so that all markup strings can use it?
>
> How does this differ from the current mechanism using
> add-text-replacements! and replacement-alist?
It is the same mechanism, and add-text-replacements! answers Werner’s question.
> Could these be extended to
> allow the replacement string to include \markup?
Already done by me at some point in the 2.23 series (or the code above wouldn’t
work).
Making two functions into one
Hi,
I would like to make a function which will be responsible for two things:
1. Change time signature
2. Fill empty bar with 's8'
I made this one, but there is a problem with point'n'click function, so
I can't click on time signature to go to correspondent place in code:
\version "2.24.0"
nd = #(define-music-function (number) (integer?)
(make-music
'SequentialMusic
'elements
(list (make-music
'SequentialMusic
'elements
(list (make-music
'TimeSignatureMusic
'numerator
number
'denominator
8
'beat-structure
'(
(make-music
'UnfoldedRepeatedMusic
'elements
'()
'repeat-count
number
'element
(make-music
'SequentialMusic
'elements
(list (make-music
'SkipEvent
'duration
(ly:make-duration 3)))
)
\score {
\new Staff {
\nd 8
\nd 7
}
}
So I thought about delete one nested (list) and try it:
nd = #(define-music-function (number) (integer?)
(make-music
'TimeSignatureMusic
'numerator
8
'denominator
8
'beat-structure
'())
(make-music
'UnfoldedRepeatedMusic
'elements
'()
'repeat-count
8
'element
(make-music
'SequentialMusic
'elements
(list (make-music
'SkipEvent
'duration
(ly:make-duration 3))
But the problem is, when I don't use (list) for two adjacent
(make-music) functions, one of them doesn't run, so depending on the
kind of second (make-music) code, one od them goes, another don't.
Honestly, I don't understand why it's like that, because when I run
displayScheme{}, it display it properly without (list) and
SquentialMusic for this two events. I suspect it could be something
wrong with my definition.
Thank you :)
Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals
At 12:51 on 16 Jan 2023, Werner LEMBERG wrote:
>> \new Staff {
>> \override TextScript.before-line-breaking =
>> #(lambda (grob)
>> (ly:grob-set-property! grob 'text
>> (markup #:replace
>> `(("♭" . ,#{ \markup{ \tflat} #})
>> ("♯" . ,#{ \markup{ \tsharp} #})
>> ("♮" . ,#{ \markup{ \tnatural} #}))
>> (ly:grob-property grob 'text
>> c'1^"B♭"
>> c'1^"C♯"
>> c'1^"D♮"
>> }
> *This* is nice! It sort-of corresponds to 'active characters' in TeX.
> Is there a possibility to register this or a similar function globally
> so that all markup strings can use it?
How does this differ from the current mechanism using
add-text-replacements! and replacement-alist? Could these be extended to
allow the replacement string to include \markup?
--
Mark Knoop
Re: Spontini-Editor 1.20 released
On Mon, Jan 16, 2023 at 6:59 AM Paolo Prete wrote: > A new release (1.20-alpha) of Spontini-Editor is available Looks very nice so far! I have it running on Windows 10, will explore further. -- Karlin High Missouri, USA
Spontini-Editor 1.20 released
Hi, A new release (1.20-alpha) of Spontini-Editor is available at: https://github.com/paopre/Spontini/releases/tag/1.20_alfa It includes two important features: 1) The application is now _totally_ no-install. This means that you just need to unzip the downloaded release for the desired operating system (Linux, Windows or MacOS) and click on the executable to launch the editor, which now starts very quickly (I applied the same method used by LilyPond). Furthermore, there is no need to download and install LilyPond either: Spontini-Editor will automatically download and bundle, inside its tree, one or more versions of LilyPond, at the user's choice. By default, it will use LilyPond 2.24.0 2) (For readers with knowledge of software development) A big set of CI/CD tests has been added. These tests ensure strong stability to the program. One of the tests, for example, compiles all the included examples for numerous versions of LilyPond, on all three supported operating systems: this also catches LilyPond regressions (and in fact with this tool I identified the one reported in the following issue: https://gitlab.com/lilypond/lilypond/-/issues/6482 ). The tests really involve all the parts of the program, from the GUI (via Cypress) to the backend and _all_ the included libraries are automatically tested. There are also tests made with ImageMagick to verify that scores' output is perceptually correct (and this is useful also for catching LilyPond's regressions). The creation of releases with executables has also been automated. Thanks to these features, I will do very easy and fast updates in the future months for all the supported platforms and included tools. The current release is labeled as alfa, but it should work. I'll put it as non-alfa in the next few days, depending on feedback and further tests done. Therefore, any feedback is _greatly_ appreciated (please report any issue on the GitHub page)! Visit the homepage of the project for more infos: https://github.com/paopre/Spontini HTH Paolo
Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals
> I quite like this, but incorporating this into my previous code I
> found going down TWO steps to be optically more pleasing.
OK :-)
> \new Staff {
> \override TextScript.before-line-breaking =
> #(lambda (grob)
> (ly:grob-set-property! grob 'text
> (markup #:replace
> `(("♭" . ,#{ \markup{ \tflat} #})
> ("♯" . ,#{ \markup{ \tsharp} #})
> ("♮" . ,#{ \markup{ \tnatural} #}))
> (ly:grob-property grob 'text
> c'1^"B♭"
> c'1^"C♯"
> c'1^"D♮"
> }
*This* is nice! It sort-of corresponds to 'active characters' in TeX.
Is there a possibility to register this or a similar function globally
so that all markup strings can use it?
In any case, please submit this to the LSR!
Werner
Re: Repeat segno weirdness
Hello Jeff,
If I were to reduce what you are doing we’d have something like this
\relative c'' {
R1*4 \bar "||"
\repeat segno 2 {
\alternative {
{ R1*4 }
{
\section
\sectionLabel "Coda"
}
}
}
% Coda
R1*4
}
So you are basically telling Lilypond: After some measures we have a segno,
then the first time we play this part, then we jump back to the segno, but
skipt the whole repeat part and directly jump to the coda, which Lilypond
correctly indicates by putting a volta bracket over the whole thing (actually
you are almost asking for the volta bracket by manually specifying \volta 1).
I suppose what you actually want to say is:
After some measures we have a segno, then we have the repeat part, at the end
we jump back to segno, repeat the repeat part and then jump to coda, which
would be done like this:
\relative c'' {
R1*4 \bar "||"
\repeat segno 2 {
R1*4
\alternative {
{ }
{
\section
\sectionLabel "Coda"
% Coda
R1*4
}
}
}
}
Alternatively if you want to have: After some measures put a segno, play the
repeat part, jump back to segno, play only part of the repeat part and jump to
coda you’d do:
\relative c'' {
R1*4 \bar "||"
\repeat segno 2 {
R1*2
\alternative {
{ R1*2 }
{
\section
\sectionLabel "Coda"
% Coda
R1*4
}
}
}
}
The marks used for the segnos and codas and dal segnos and poi la codas and
stuff can be set to whatever you want.
Cheers,
Valentin
Am Montag, 16. Jänner 2023, 07:50:04 CET schrieb Jeff Kopmanis:
> I'm using lilypond 2.24.0, and am having a problem that I can't identify
> with a \repeat segno structure. I've enclosed the .ly and .pdf files. It
> compiles cleanly, and displays mostly correct, but there's a curious "1st
> ending" (a volta spanner?) that appears, and I can't figure out where it's
> coming from. I've run the \repeat segno sample code from the docs and it
> doesn't behave this way, but with my score, it does it without fail. I've
> attached the resultant PDF to illustrate this 1st ending that lasts until
> the coda. I found the example big band score code online and it seemed
> pretty straight-forward, and without the \repeat segno structures, it works
> fine, so there's some option that's defaulting, or something extra that's
> missing to produce this odd behavior.
>
> I'm at a loss at what's causing this. Help!
>
> -Jeff. :)
signature.asc
Description: This is a digitally signed message part.
Re: Unicode accidentals vs. Markup accidentals
Hi Werner,
> I rather suggest the following
>
> ```
> F = \markup { \smaller \number ♭ }
> S = \markup { \smaller \number ♯ }
> N = \markup { \smaller \number ♮ }
>
> \new Staff {
> c'1^\markup \concat { B \F }
> c'1^\markup \concat { C \S }
> c'1^\markup \concat { D \N }
> }
> ```
>
> If you look more closely, the accidentals produced by `\number` are
> different from the ones produced by `\flat` and friends. The former
> are mainly for text markup and thus have more reasonable metric
> values, while the latter are suited mainly for non-text markup.
Very nice! Definitely superior.
Kieren.
Re: Unicode accidentals vs. Markup accidentals
Hello Werner,
I quite like this, but incorporating this into my previous code I found going
down TWO steps to be optically more pleasing. This probably because the
\number accidentals are designed for use with with numbers, which are slightly
higher than regular text and very bold faced. So in your example the
accidentals just look quite chunky and big. Going down two font sizes looks
much more elegant in my opinion:
#(define-markup-command (tsharp layout props) ()
(interpret-markup layout props (markup #:fontsize -2 #:number "♯")))
#(define-markup-command (tflat layout props) ()
(interpret-markup layout props (markup #:fontsize -2 #:number "♭")))
#(define-markup-command (tnatural layout props) ()
(interpret-markup layout props (markup #:fontsize -2 #:number "♮")))
#(define-markup-command (with-sharp layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:tsharp
#(define-markup-command (with-flat layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:tflat
#(define-markup-command (with-natural layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:tnatural
#(define-markup-command (with-sharp-between layout props m1 m2) (markup?
markup?)
(interpret-markup layout props (markup #:concat (m1 #:tsharp m2
#(define-markup-command (with-flat-between layout props m1 m2) (markup? markup?)
(interpret-markup layout props (markup #:concat (m1 #:tflat m2
#(define-markup-command (with-natural-between layout props m1 m2) (markup?
markup?)
(interpret-markup layout props (markup #:concat (m1 #:tnatural m2
\markup { A C with a \tsharp can be written \with-sharp-between C ,
a C with a \tnatural can be written \with-natural C and
a C with a \tflat can be written \with-flat-between C . }
\new Staff {
\override TextScript.before-line-breaking =
#(lambda (grob)
(ly:grob-set-property! grob 'text
(markup #:replace
`(("♭" . ,#{ \markup{ \tflat} #})
("♯" . ,#{ \markup{ \tsharp} #})
("♮" . ,#{ \markup{ \tnatural} #}))
(ly:grob-property grob 'text
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
}
Cheers, Valentin
Am Montag, 16. Jänner 2023, 09:31:54 CET schrieb Werner LEMBERG:
> > Lilypond ships with a text font as well as a music font. I agree
> > that I suspect that currently Lilypond's text font does not actually
> > define these Unicode music characters, so it falls back on the OS to
> > find them. Why not just add copies of Emmentaler glyphs to the
> > Lilypond text fonts for characters within the Unicode spec?
>
>
> IMHO, there is zero benefit of doing that. I guess one of the first
> action a slightly more advanced user does is to change the default
> fonts to something else, because the default is not 'sexy' enough to
> most people. Irrespective of that it would be an additional burden to
> us to maintain such modifications.
>
>
> > I also don't think it's unreasonable to suggest that the default
> > typography should look good.
>
>
> No question – I think the default *does* look good, as demonstrated in
> my previous e-mail.
>
>
> > I hope we can agree that the output on staves 1 & 2 is significantly
> > worse than the output on staff 3 (attached picture if it doesn't
> > display inline for you).
>
>
> Yes, but you are using the wrong commands. Have you actually noticed
> the example I've sent in my last e-mail?
>
>
> > Staves 1&2 are Unicode and default markup glyphs as in my original
> > post (compiled on Windows). To get staff 3 the following is
> > required:
> >
> > \new Staff {
> >
> > c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> > c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> > c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural
> > }
> >
> > }
> >
> >
> > IMO Staff 3 should be the default output, not something that
> > requires so much tweaking.
>
>
> I rather suggest the following
>
> ```
> F = \markup { \smaller \number ♭ }
> S = \markup { \smaller \number ♯ }
> N = \markup { \smaller \number ♮ }
>
> \new Staff {
> c'1^\markup \concat { B \F }
> c'1^\markup \concat { C \S }
> c'1^\markup \concat { D \N }
> }
> ```
>
> If you look more closely, the accidentals produced by `\number` are
> different from the ones produced by `\flat` and friends. The former
> are mainly for text markup and thus have more reasonable metric
> values, while the latter are suited mainly for non-text markup.
>
> BTW, the new text accidentals are new in version 2.24.
>
>
> Werner
signature.asc
Description: This is a digitally signed message part.
Re: Unicode accidentals vs. Markup accidentals
Hello Saul,
I do not find this much surprising at all. Yes, Lilypond could do lots of
automagic, automatically replacing such signs by the respective music font
version. But it does not and rather gives you (the user) the control and the
responsibility. But typesetting in Lilypond is neither particularly easy to
work with nor particularly powerful. The design choice of having all markups
be separated by space requires a lot of \concat. This does show that lilypond
was not mainly conceived as a typesetting program, but as a notation program.
Now, the problem we have here is as already discussed that Lilypond does by
default use a font that does not provide these glyphs. A simple solution could
be using a different font. MuseScore provides a font "Edwin", which is a fork
of the font used by Lilypond with a few added symbols. The team of Dorico does
provide an OFL font "Academico", which reproduces the same typeface, and
provides a few added symbols. The downsides of this is that these fonts simply
use the accidental glyphs from MuseScore’s notation font Leland and Dorico’s
notation font Bravura. This means they do not optically match the font that
well and they most certainly do not match Lilypond’s notation glyphs.
If you can live with such a thing, changing the text font to Dorico’s
Academico will produce quite nice results.
On the other hand to make life easier and code easier to read you may alwas
define your own markup commands like this:
#(define-markup-command (tsharp layout props) ()
(interpret-markup layout props (markup #:raise 0.8 #:fontsize -3 #:sharp)))
#(define-markup-command (tflat layout props) ()
(interpret-markup layout props (markup #:raise 0.4 #:fontsize -1.7 #:flat)))
#(define-markup-command (tnatural layout props) ()
(interpret-markup layout props (markup #:raise 0.67 #:fontsize -2.5
#:natural)))
#(define-markup-command (with-sharp layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:hspace 0.15
#:tsharp
#(define-markup-command (with-flat layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:hspace 0.2 #:tflat
#(define-markup-command (with-natural layout props m) (markup?)
(interpret-markup layout props (markup #:concat (m #:hspace 0.2
#:tnatural
#(define-markup-command (with-sharp-between layout props m1 m2) (markup?
markup?)
(interpret-markup layout props (markup #:concat (m1 #:hspace 0.15 #:tsharp
m2
#(define-markup-command (with-flat-between layout props m1 m2) (markup? markup?)
(interpret-markup layout props (markup #:concat (m1 #:hspace 0.2 #:tflat
m2
#(define-markup-command (with-natural-between layout props m1 m2) (markup?
markup?)
(interpret-markup layout props (markup #:concat (m1 #:hspace 0.2 #:tnatural
m2
\markup { A C with a \tsharp can be written \with-sharp-between C ,
a C with a \tnatural can be written \with-natural C and
a C with a \tflat can be written \with-flat-between C . }
Also while Lilypond will not automatically replace Unicode characters, you can
tell it to do so manually:
\new Staff {
\override TextScript.before-line-breaking =
#(lambda (grob)
(ly:grob-set-property! grob 'text
(markup #:replace
`(("♭" . ,#{ \markup{\hspace #0.2 \tflat}
#})
("♯" . ,#{ \markup{\hspace #0.15
\tsharp} #})
("♮" . ,#{ \markup{\hspace #0.2
\tnatural} #}))
(ly:grob-property grob 'text
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
}
Cheers,
Valentin
Am Montag, 16. Jänner 2023, 07:52:50 CET schrieb Saul Tobin:
> Lilypond ships with a text font as well as a music font. I agree that I
> suspect that currently Lilypond's text font does not actually define these
> Unicode music characters, so it falls back on the OS to find them. Why not
> just add copies of Emmentaler glyphs to the Lilypond text fonts for
> characters within the Unicode spec? That seems like a pretty reasonable
> suggestion to me...
>
> I also don't think it's unreasonable to suggest that the default typography
> should look good. I hope we can agree that the output on staves 1 & 2 is
> significantly worse than the output on staff 3 (attached picture if it
> doesn't display inline for you).
> [image: image.png]
> Staves 1&2 are Unicode and default markup glyphs as in my original post
> (compiled on Windows). To get staff 3 the following is required:
>
> \new Staff {
> c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural }
> }
>
> IMO Staff 3 should be the default output, not something that requires so
> much tweaking.
>
> On Sun, Jan 15, 2023 at 9:56 PM Werner LEMBERG wrote:
> > > IMO Lilypond should render musical
Re: Unicode accidentals vs. Markup accidentals
> Lilypond ships with a text font as well as a music font. I agree
> that I suspect that currently Lilypond's text font does not actually
> define these Unicode music characters, so it falls back on the OS to
> find them. Why not just add copies of Emmentaler glyphs to the
> Lilypond text fonts for characters within the Unicode spec?
IMHO, there is zero benefit of doing that. I guess one of the first
action a slightly more advanced user does is to change the default
fonts to something else, because the default is not 'sexy' enough to
most people. Irrespective of that it would be an additional burden to
us to maintain such modifications.
> I also don't think it's unreasonable to suggest that the default
> typography should look good.
No question – I think the default *does* look good, as demonstrated in
my previous e-mail.
> I hope we can agree that the output on staves 1 & 2 is significantly
> worse than the output on staff 3 (attached picture if it doesn't
> display inline for you).
Yes, but you are using the wrong commands. Have you actually noticed
the example I've sent in my last e-mail?
> Staves 1&2 are Unicode and default markup glyphs as in my original
> post (compiled on Windows). To get staff 3 the following is
> required:
>
> \new Staff {
> c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural }
> }
>
> IMO Staff 3 should be the default output, not something that
> requires so much tweaking.
I rather suggest the following
```
F = \markup { \smaller \number ♭ }
S = \markup { \smaller \number ♯ }
N = \markup { \smaller \number ♮ }
\new Staff {
c'1^\markup \concat { B \F }
c'1^\markup \concat { C \S }
c'1^\markup \concat { D \N }
}
```
If you look more closely, the accidentals produced by `\number` are
different from the ones produced by `\flat` and friends. The former
are mainly for text markup and thus have more reasonable metric
values, while the latter are suited mainly for non-text markup.
BTW, the new text accidentals are new in version 2.24.
Werner
