Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
不得好死 https://codereview.appspot.com/567140045/
Re: Please review Pygments lexer and style
Le 25/06/2021 01:40, Dan Eble <[1]d...@faithful.be> a écrit : On Jun 24, 2021, at 14:17, Jean Abou Samra <[2]j...@abou-samra.fr> wrote: Ok, I already simplified it, but it's still too complicated. Consider approaching from the other direction. If you had only italic, bold, and red to work with, how would you use them? Here is how far I could get it this evening. I plan on removing the draft status from the pull request somewhere in the end of the week. Cheers Jean References 1. mailto:d...@faithful.be 2. mailto:j...@abou-samra.fr example.rtf Description: RTF file
Re: Please review Pygments lexer and style
Benkő Pál writes: > Jean Abou Samra ezt írta (időpont: 2021. jún. > 24., Cs, 20:17): >> I'll style \longa in bold too. > > \longa is a duration, like 2 in c2; on the other hand 3 in \repeat > \unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is > arguably a duration, but... No, it isn't. 3/4 is a fraction and passed as such into \time . A duration cannot be something like 5 while \time 3/5 is accepted by the parser (the time signature engraver will give you a warning because that's not really something LilyPond can make a lot of sense of). If you use 5 as a duration, it's the parser that already bombs out (though admittedly the lexer will treat it like 4, but then the lexer does not distinguish durations from integers in general). -- David Kastrup
Re: Please review Pygments lexer and style
Jean Abou Samra ezt írta (időpont: 2021. jún. 24., Cs, 20:17): > I'll style \longa in bold too. \longa is a duration, like 2 in c2; on the other hand 3 in \repeat \unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is arguably a duration, but... p
Re: Please review Pygments lexer and style
On Jun 24, 2021, at 14:17, Jean Abou Samra wrote: > > Ok, I already simplified it, but it's still too complicated. Consider approaching from the other direction. If you had only italic, bold, and red to work with, how would you use them? — Dan
Re: Please review Pygments lexer and style
Le 24/06/2021 à 19:23, Jonas Hahnfeld via Discussions on LilyPond development a écrit : Am Donnerstag, dem 24.06.2021 um 18:36 +0200 schrieb Jean Abou Samra: Le 23/06/2021 à 19:03, Jean Abou Samra a écrit : Le 23/06/2021 à 18:53, Dan Eble a écrit : Not a bad idea, but -1 for the use of light colors on white: silver, yellow, sky blue, etc. What is the minimum set of distinctions that is likely to do more good than harm? The example is a little overwhelming. (All MHO.) I should probably find something else for pitches and durations. The example does look overwhelming, but it was intentionally constructed as a showcase for many pieces of syntax and builtins. A typical score mostly consists of long runs of pitches and durations interspersed with articulations and commands, so I think making many distinctions should be fine as long as the most common parts of the syntax have colors that are easy enough to read. Here is a new "patch set". - New colors for pitches, articulations and some others. - Darker colors overall. - No distinction between dynamics and other articulations, nor between \header and \paper variables, nor music functions and music shortcuts. How does this look? I've been staring at it for too long to even see if it's acceptable. I still only see text in the .html files, no formatting. From the .rtf (as far as LibreOffice Writer can read that format), it's not clear to me (I didn't look at the first proposal): * why some functions / variables are printed in bold (\staff-space and \major are not; assignment to myFunc, mySecondFunc, and myPitch are not, but their uses are), Ok, I already simplified it, but it's still too complicated. All builtin functions are in bold, and anything unknown and backslash-escaped is as well. I'll style \staff-space, \major and \longa in bold too. Assignments are not specially recognized at the moment as the lexer is very simple-minded; changing that might be feasible. * which ones have different colors (\hide and \omit are blue, \tweak and \override are black; markups seem to be purple, but \markup itself is black), and Built-in music functions and shortcuts are blue (except articulations, in green). Everything unknown and backslash-escaped is blue, assuming that it is most frequently a variable containing music or a music function. Parser keywords are in black (note that \tweak is actually a music function, but it pairs with \override and Frescobaldi sets a precedent by highlighting it like keywords). Markup functions are in purple. The word \markup is black since it's a keyword; maybe I should make it purple as a special case? * why ##t is bold (the first pound seems not?), but #5 and #'() are not despite also being constants. The lexer I wrote delegates Scheme parsing to the already existing Scheme lexer, which is responsible for this behavior. The first pound is not bold because it's the switch to Scheme; #t is the Scheme constant. '(), in spite of being a constant, is not recognized as such by the Scheme lexer; that could be a nice improvement there. Thanks for the feedback! Jean
Re: Please review Pygments lexer and style
Am Donnerstag, dem 24.06.2021 um 18:36 +0200 schrieb Jean Abou Samra: > Le 23/06/2021 à 19:03, Jean Abou Samra a écrit : > > Le 23/06/2021 à 18:53, Dan Eble a écrit : > > > Not a bad idea, but -1 for the use of light colors on white: silver, > > > yellow, sky blue, etc. > > > > > > What is the minimum set of distinctions that is likely to do more > > > good than harm? The example is a little overwhelming. > > > > > > (All MHO.) > > > > I should probably find something else for pitches and > > durations. The example does look overwhelming, but it > > was intentionally constructed as a showcase for many > > pieces of syntax and builtins. A typical score mostly > > consists of long runs of pitches and durations interspersed > > with articulations and commands, so I think making many > > distinctions should be fine as long as the most common > > parts of the syntax have colors that are easy enough > > to read. > > Here is a new "patch set". > > - New colors for pitches, articulations and some others. > - Darker colors overall. > - No distinction between dynamics and other articulations, nor between > \header and \paper variables, nor music functions and music shortcuts. > > How does this look? I've been staring at it for too long to even see if > it's acceptable. I still only see text in the .html files, no formatting. From the .rtf (as far as LibreOffice Writer can read that format), it's not clear to me (I didn't look at the first proposal): * why some functions / variables are printed in bold (\staff-space and \major are not; assignment to myFunc, mySecondFunc, and myPitch are not, but their uses are), * which ones have different colors (\hide and \omit are blue, \tweak and \override are black; markups seem to be purple, but \markup itself is black), and * why ##t is bold (the first pound seems not?), but #5 and #'() are not despite also being constants. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: Please review Pygments lexer and style
On Jun 23, 2021, at 10:33, Jean Abou Samra wrote: > > Le 23/06/2021 à 09:58, Jean Abou Samra a écrit : >> To whet your appetite, a highlighted version of the test >> file included in the PR is attached. > > Not sure why the HTML hasn't gotten through email — on > the archives and in Dan's mailbox it appears as plain > LilyPond code. Here are additional RTF and SVG versions. > > Jean > Not a bad idea, but -1 for the use of light colors on white: silver, yellow, sky blue, etc. What is the minimum set of distinctions that is likely to do more good than harm? The example is a little overwhelming. (All MHO.) — Dan
Re: Please review Pygments lexer and style
Le 23/06/2021 à 18:53, Dan Eble a écrit : On Jun 23, 2021, at 10:33, Jean Abou Samra wrote: Le 23/06/2021 à 09:58, Jean Abou Samra a écrit : To whet your appetite, a highlighted version of the test file included in the PR is attached. Not sure why the HTML hasn't gotten through email — on the archives and in Dan's mailbox it appears as plain LilyPond code. Here are additional RTF and SVG versions. Jean Not a bad idea, but -1 for the use of light colors on white: silver, yellow, sky blue, etc. What is the minimum set of distinctions that is likely to do more good than harm? The example is a little overwhelming. (All MHO.) I should probably find something else for pitches and durations. The example does look overwhelming, but it was intentionally constructed as a showcase for many pieces of syntax and builtins. A typical score mostly consists of long runs of pitches and durations interspersed with articulations and commands, so I think making many distinctions should be fine as long as the most common parts of the syntax have colors that are easy enough to read.
Re: Please review Pygments lexer and style
Le 23/06/2021 à 09:58, Jean Abou Samra a écrit :
To whet your appetite, a highlighted version of the test
file included in the PR is attached.
Not sure why the HTML hasn't gotten through email — on
the archives and in Dan's mailbox it appears as plain
LilyPond code. Here are additional RTF and SVG versions.
Jean
\version "2.23.3"
% This is a test file for Pygments' LilyPond support. To compile
% it with Guile 1 (as in official releases as of this writing),
% remove the "commented form" below.
%{
All supported constructs are covered in
this file. For example, multi-line comments.
These are non-nested. The following will
end the whole comment:
%{ %}
\header {
title = "This is an assignment to a string."
composer = \markup \smallCaps "And this is a markup"
}
% The following is just a comment.
%}
\paper {
indent = 30\staff-space
page-count = 1
}
myFunc =
# #;(This is a commented form. After it, we are still in Scheme mode.)
(define-music-function (music n) (ly:music? index?)
(let* ((repeated (make-list n music))
(copied (map ly:music-deep-copy repeated)))
; This is a Scheme comment.
(make-sequential-music copied)))
mySecondFunc =
#(define-music-function (music) (ly:music?)
#{
% LilyPond syntax here.
\compressMMRests
\shiftDurations -2 1
# ; Scheme syntax again.
(ly:music-deep-copy music)
#})
myPitch = ##{ c #}
% Here we should be back to LilyPond mode. This
% is a LilyPond comment.
<<
\new Staff \with {
\consists Duration_line_engraver
}
\relative c' {
\clef alto
\time 6/8
\key d \major
\cadenzaOn
deses'!4.~(\tweak thickness 4\( deses^\p-\signumcongruentiae_1\4
deses\longa) \myFunc { r } 4 des8 8[ 8]\)
\bar "||"
\cadenzaOff
\once \hide NoteHead
\once \override NoteHead.no-ledgers = ##t
\once \omit Dots
\once \override Staff.DurationLine.thickness = #5
c''?2.:16\-^"Some music" |
\mySecondFunc
R1*1/2^\markup \center-column {
Some
Text
In
A
\bold \italic Column!
super % not highlighted as a markup command
}
\repeat unfold 4 { c8\< c^\> c\p\! }
}
\addlyrics {
\set Score.melismaBusyProperties = #'()
My Lily -- Song
}
\chordmode {
c cis:3+ des:maj7/+e
}
\new TabVoice {
f'4\^ g'4\^ f'2
}
\drums {
hihat4 hh bassdrum bd
}
>>
\version "2.23.3"
% This is a test file for Pygments' LilyPond support. To compile
% it with Guile 1 (as in official releases as of this writing),
% remove the "commented form" below.
%{
All supported constructs are covered in
this file. For example, multi-line comments.
These are non-nested. The following will
end the whole comment:
%{ %}
\header {
title = "This is an assignment to a string."
composer = \markup \smallCaps "And this is a markup"
}
% The following is just a comment.
%}
\paper {
indent = 30\staff-space
page-count = 1
}
myFunc =
# #;(This is a commented form. After it, we are still in Scheme mode.)
(define-music-function (music n) (ly:music? index?)
(let* ((repeated (make-list n music))
(copied (map ly:music-deep-copy repeated)))
; This is a Scheme comment.
(make-sequential-music copied)))
mySecondFunc =
#(define-music-function (music) (ly:music?)
#{
% LilyPond syntax here.
\compressMMRests
\shiftDurations -2 1
# ; Scheme syntax again.
(ly:music-deep-copy music)
#})
myPitch = ##{ c #}
% Here we should be back to LilyPond mode. This
% is a LilyPond comment.
<<
\new Staff \with {
\consists Duration_line_engraver
}
\relative c' {
\clef alto
\time 6/8
\key d \major
\cadenzaOn
deses'!4.~(\tweak thickness 4\( deses^\p-\signumcongruentiae_1\4
deses\longa) \myFunc { r } 4 des8 8[ 8]\)
\bar "||"
\cadenzaOff
\once \hide NoteHead
\once \override NoteHead.no-ledgers = ##t
\once \omit Dots
\once \override Staff.DurationLine.thickness = #5
c''?2.:16\-^"Some music" |
\mySecondFunc
R1*1/2^\markup \center-column {
Some
Text
In
A
\bold \italic Column!
super % not highlighted as a markup command
}
\repeat unfold 4 { c8\< c^\> c\p\! }
}
\addlyrics {
\set Score.melismaBusyProperties = #'()
My Lily -- Song
}
\chordmode {
c cis:3+ des:maj7/+e
}
\new TabVoice {
f'4\^ g'4\^ f'2
}
\drums {
hihat4 hh bassdrum bd
}
>>
example.rtf
Description: RTF file
Please review Pygments lexer and style
Hello,
Pygments is a Python syntax highlighter supporting many
languages, used by Sphinx-documented projects, users of
the 'minted' LaTeX package, Wikipedia, and various websites.
I'd like to see Pygments supporting LilyPond. Here is my
pull request (the equivalent of a merge request, on GitHub):
https://github.com/pygments/pygments/pull/1845
(Note that there is a previous attempt,
https://github.com/pygments/pygments/pull/1371. However,
it is far less precise, does not understand Scheme, and,
above all, reuses code covered by the GPL from Frescobaldi,
making it unsuitable for inclusion in the BSD-licensed
Pygments.)
Reviews and testing would be appreciated. In particular,
if you would not like to have a later unpleasant surprise
with my aesthetic choices, please give the style a look;
the eventual goal would be to make this used in our
documentation. The setup to start testing is
(assuming Python 3 installed):
git clone https://github.com/Jean-Abou-Samra/pygments.git
cd pygments
git checkout lilypond
python3 -m venv pygments-env
source pygments-env/bin/activate
pip install -r requirements.txt
Then you can highlight file.ly, outputting to file.html,
using
python -m pygments -f html -O full,style=lilypond file.ly > file.html
(If you begin a new session of testing, don't forget
to start with 'source pygments-env/bin/activate'.)
To whet your appetite, a highlighted version of the test
file included in the PR is attached.
Cheers,
Jean
\version "2.23.3"
% This is a test file for Pygments' LilyPond support. To compile
% it with Guile 1 (as in official releases as of this writing),
% remove the "commented form" below.
%{
All supported constructs are covered in
this file. For example, multi-line comments.
These are non-nested. The following will
end the whole comment:
%{ %}
\header {
title = "This is an assignment to a string."
composer = \markup \smallCaps "And this is a markup"
}
% The following is just a comment.
%}
\paper {
indent = 30\staff-space
page-count = 1
}
myFunc =
# #;(This is a commented form. After it, we are still in Scheme mode.)
(define-music-function (music n) (ly:music? index?)
(let* ((repeated (make-list n music))
(copied (map ly:music-deep-copy repeated)))
; This is a Scheme comment.
(make-sequential-music copied)))
mySecondFunc =
#(define-music-function (music) (ly:music?)
#{
% LilyPond syntax here.
\compressMMRests
\shiftDurations -2 1
# ; Scheme syntax again.
(ly:music-deep-copy music)
#})
myPitch = ##{ c #}
% Here we should be back to LilyPond mode. This
% is a LilyPond comment.
<<
\new Staff \with {
\consists Duration_line_engraver
}
\relative c' {
\clef alto
\time 6/8
\key d \major
\cadenzaOn
deses'!4.~(\tweak thickness 4\( deses^\p-\signumcongruentiae_1\4
deses\longa) \myFunc { r } 4 des8 8[ 8]\)
\bar "||"
\cadenzaOff
\once \hide NoteHead
\once \override NoteHead.no-ledgers = ##t
\once \omit Dots
\once \override Staff.DurationLine.thickness = #5
c''?2.:16\-^"Some music" |
\mySecondFunc
R1*1/2^\markup \center-column {
Some
Text
In
A
\bold \italic Column!
super % not highlighted as a markup command
}
\repeat unfold 4 { c8\< c^\> c\p\! }
}
\addlyrics {
\set Score.melismaBusyProperties = #'()
My Lily -- Song
}
\chordmode {
c cis:3+ des:maj7/+e
}
\new TabVoice {
f'4\^ g'4\^ f'2
}
\drums {
hihat4 hh bassdrum bd
}
>>
\version "2.23.3"
% This is a test file for Pygments' LilyPond support. To compile
% it with Guile 1 (as in official releases as of this writing),
% remove the "commented form" below.
%{
All supported constructs are covered in
this file. For example, multi-line comments.
These are non-nested. The following will
end the whole comment:
%{ %}
\header {
title = "This is an assignment to a string."
composer = \markup \smallCaps "And this is a markup"
}
% The following is just a comment.
%}
\paper {
indent = 30\staff-space
page-count = 1
}
myFunc =
# #;(This is a commented form. After it, we are still in Scheme mode.)
(define-music-function (music n) (ly:music? index?)
(let* ((repeated (make-list n music))
(copied (map ly:music-deep-copy repeated)))
; This is a Scheme comment.
(make-sequential-music copied)))
mySecondFunc =
#(define-music-function (music) (ly:music?)
#{
% LilyPond syntax here.
\compressMMRests
\shiftDurations -2 1
# ; Scheme syntax again.
(ly:music-deep-copy music)
#})
myPitch = ##{ c #}
% Here we should be back to LilyPond mode. This
% is a LilyPond comment.
<<
\new Staff \with {
\consists Duration_line_engraver
Alignment and style of bar numbers
Hi all,
LilyPond currently aligns all bar numbers on their right side, like in
this example (output attached):
\layout {
\context {
\Score
\override BarNumber.break-visibility = #all-visible
}
}
\repeat unfold 10 { c'1 }
I have found this to be confusing for musicians during rehearsal, because
each number overhangs the preceding measure. Therefore, I would like to
start
a discussion about how the default alignment should be. I uploaded
https://gitlab.com/lilypond/lilypond/-/merge_requests/447 as a proof of
concept
(it centers them, since that was my original idea). Note that we are
only talking
about mid-staff bar numbers − those at the beginning of a system are a
different case and need padding to avoid system start delimiters (wether
we could
add the padding only when the delimiter requires it is an interesting, but
separate, technical question).
I wanted to let you all know that this stuff is under discussion. Note that
I do *not* want the debate to move here (since the MR is easier to find and
link afterwards, and it already started there).
Furthermore, the general style of bar numbers is under question. For
example,
should we print them in italics (which Gould recommends)?
At any rate, changes in this area shall be weighed with care, because they
will certainly have (more or less) large impact on existing scores and
affect
the overall look of LilyPond output. At some point, we may want to ask users
for feedback.
Comments are very welcome on the MR.
Regards,
Jean
Re: Python coding style
Hi, Le 02/07/2020 à 09:05, Han-Wen Nienhuys a écrit : You can also do a global cleanup. We have done this in the past, but it has the disadvantage that it makes history (eg. git-blame) harder to read. So, I did the global cleanup: https://gitlab.com/lilypond/lilypond/-/merge_requests/251 We can take it one bit at a time. In particular, if you can provide a recipe that would reformat diffs, I can integrate that in my pre-commit hook, so all new code is compliant. I don't have that in my toolbox, sorry. The issue is that tools like autopep8 and YAPF work on ASTs, so they can't cope with incomplete bits of code. I don't know a safe way to pick just the part of the generated diff that deals with what you change (if you see what I mean). On Wed, Jul 1, 2020 at 2:03 PM Jean Abou Samra wrote: to me it's a no-brainer to introduce automatic formatting. I don't really care what standard it enforces, as long as it is automated. I would consider it, but it isn't a no-brainer to me: every automatic formatting tool has its issues, and I prefer formatting my code myself to format the way I think most human-readable.Anyway, let's rather discuss this later when we come to adding a linter to CI. - Use `string` instead of `str` as an identifier − `str` being a built-in type already. This would be a good rule to follow if the Python team doesn't keep adding identifiers to the top level scope. For example, in other projects I had a lot of code become non-compliant overnight when Python decided that binary formatting of number is worthy of the toplevel identifier 'bin'. I agree that Python evolves rapidly, but I think that `str` is common enough to warrant not using as a variable since you could need it as its actual built-in value in your function. On the other hand, I didn't listen to pylint complaining that we redefined the builtin `credits`. Cheers, Jean
Re: Python coding style
On Wed, Jul 1, 2020 at 2:03 PM Jean Abou Samra wrote: > The Contributor's Guide (10.5.1) clearly states that "Python code should > use PEP 8". So, I'd like to be sure everyone agrees on the following points > which are part of applying this PEP: to me it's a no-brainer to introduce automatic formatting. I don't really care what standard it enforces, as long as it is automated. > - Use `string` instead of `str` as an identifier − `str` being a > built-in type > already. This would be a good rule to follow if the Python team doesn't keep adding identifiers to the top level scope. For example, in other projects I had a lot of code become non-compliant overnight when Python decided that binary formatting of number is worthy of the toplevel identifier 'bin'. > Any thoughts? We can take it one bit at a time. In particular, if you can provide a recipe that would reformat diffs, I can integrate that in my pre-commit hook, so all new code is compliant. You can also do a global cleanup. We have done this in the past, but it has the disadvantage that it makes history (eg. git-blame) harder to read. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Python coding style
For automatic PEP8 formatting, there is autopep8: https://pypi.org/project/autopep8/ and yapf: https://pypi.org/project/yapf/ among others. Cheers, Joram
Re: Python coding style
On Wed, Jul 1, 2020 at 10:55 AM Jean Abou Samra wrote: > Hi Carl, > > Thanks for your reply. > Le 01/07/2020 à 17:05, Carl Sorensen a écrit : > > Hi Jean, > > On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra wrote: > >> Hi everybody, >> >> There is some discussion in !212 about coding style inside our Python >> scripts. >> >> The Contributor's Guide (10.5.1) clearly states that "Python code should >> use PEP 8". So, I'd like to be sure everyone agrees on the following >> points >> which are part of applying this PEP: >> >> - Remove spaces before the opening parenthesis in function calls and >> definitions, >> e.g., f(x) instead of f (x). >> > > I believe we should definitely follow PEP here. And ideally we should > have a code formatter that does this for us, so we don't rely on people > remembering that PEP is different from GNU C standarads. > > > Indeed, that was also the subject of a discussion in !190 ( > https://gitlab.com/lilypond/lilypond/-/merge_requests/190). Since then, I > looked a very bit into available Python linters and found Pylint which > looks great. It could be an ultimate step to use it in CI. (So Han-Wen, > unlike when using Mypy, you don't need to annotate the code you write in > order to check for bare typos.) > > Running pylint on scripts/abc2ly.py outputs 1687 lines of tips. Excerpts: > pylint shows the problems, but doesn't fix them. I think that it would be much better to have an automatic formatter to fix whitespace errors than to just catch them with pylint. So I would expect the CI to do something like: RegularizeWhitespace(python.file) return(pylint(python.file)) IMO it's a waste of developer brain cells to try to make sure the whitespace rules for *any* coding standard are followed. Tools can (and should) do that. Expecting developers to make variable names follow standards is fine. I have no problem with pylint rejecting a piece of code because we have bad variable names. But that's because it's not appropriate (IMO) to have an automated tool changing variable names. In short, I think pylint is part of the solution (identifying bad python code), but is not a complete solution (ensuring whitespace is compliant with PEP8). Thanks, Carl
Re: Python coding style
Hi Carl, Thanks for your reply. Le 01/07/2020 à 17:05, Carl Sorensen a écrit : Hi Jean, On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra <mailto:j...@abou-samra.fr>> wrote: Hi everybody, There is some discussion in !212 about coding style inside our Python scripts. The Contributor's Guide (10.5.1) clearly states that "Python code should use PEP 8". So, I'd like to be sure everyone agrees on the following points which are part of applying this PEP: - Remove spaces before the opening parenthesis in function calls and definitions, e.g., f(x) instead of f (x). I believe we should definitely follow PEP here. And ideally we should have a code formatter that does this for us, so we don't rely on people remembering that PEP is different from GNU C standarads. Indeed, that was also the subject of a discussion in !190 (https://gitlab.com/lilypond/lilypond/-/merge_requests/190). Since then, I looked a very bit into available Python linters and found Pylint which looks great. It could be an ultimate step to use it in CI. (So Han-Wen, unlike when using Mypy, you don't need to annotate the code you write in order to check for bare typos.) Running pylint on scripts/abc2ly.py outputs 1687 lines of tips. Excerpts: scripts/abc2ly.py:159:0: W1401: Anomalous backslash in string: '\+'. String constant might be missing an r prefix. (anomalous-backslash-in-string) scripts/abc2ly.py:132:6: C0326: Exactly one space required around assignment DIGITS='0123456789' ^ (bad-whitespace) scripts/abc2ly.py:137:10: C0326: No space allowed before bracket def error (msg): ^ (bad-whitespace) scripts/abc2ly.py:164:0: W0301: Unnecessary semicolon (unnecessary-semicolon) scripts/abc2ly.py:167:0: W0311: Bad indentation. Found 6 spaces, expected 8 (bad-indentation) scripts/abc2ly.py:218:21: C0326: Exactly one space required after comma def dump_header (outf,hdr): ^ (bad-whitespace) scripts/abc2ly.py:228:0: C0325: Unnecessary parens after 'if' keyword (superfluous-parens) scripts/abc2ly.py:650:0: C0325: Unnecessary parens after 'return' keyword (superfluous-parens) scripts/abc2ly.py:654:15: C0326: No space allowed around bracket a = re.sub ( '_', ' _ ', a) # _ to ' _ ' ^ (bad-whitespace) scripts/abc2ly.py:655:0: C0301: Line too long (105/100) (line-too-long) scripts/abc2ly.py:1237:20: W0622: Redefining built-in 'str' (redefined-builtin) In the end, it says "Your code has been rated at 0.89/10.". (For disclosure, I'm rather proud that in the branch where my current work on abc2ly takes place, this bumps to 3.36/10.) - Use `string` instead of `str` as an identifier − `str` being a built-in type already. Also common is `s`, but the Contributor's Guide also says (10.5.4) that "Variable names should be complete words, rather than abbreviations." (which is basically concerned with C++, but that particular rule is, in my opinion, valid for Python too). In particular, this applies to python/convertrules.py. I can agree that it is wrong to use 'str', since 'str' is a built in type. In my opinion, for convertrules.py, we shoud just use 's', not 'string'. Even if we use the complete word 'string', there is no special meaning in it (it's not a special string, it's just a generic string). I believe it's analogous to using 'i' for an index in a c++ loop. Why not. I agree that `string` would be somehow superfluous for convertrules.py at least. - Use the standard naming conventions, especially CamelCase for class names (the current style being a mixture of CamelCase and sometimes First_word_capitalized_with_underscores). Write module-level constants in UPPERCASE_WITH_UNDERSCORES. Likewise, change things like class error (Exception): pass to class MIDIConversionError(Exception): pass In CamelCase names that contain acronyms, capitalize all letters of the acronym (thus, the previous example doesn't read 'MidiConversionError'). I think we should follow the standard here. There are many specific changes that could be done to improve style and readability (such as replacing `ls = list(something); ls.sort()` with `ls = sorted(something)`, etc.), but the above could be made in general commits fixing all Python files. I would be supportive of changes to improve style and readability, but might question if it's worth the time. However, I'd support anybody who wants to scratch that itch. Making things compatible with PEP8 is certainly a good idea. What I plan is to apply changes that can be done in a semi-automatical fashion to all Python files (in order to facilitate review). For other types of improvement, I don't intend to do anything apart from cleaning up a particular file if I need to touch it. Also, to be ho
Re: Python coding style
Hi Jean, On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra wrote: > Hi everybody, > > There is some discussion in !212 about coding style inside our Python > scripts. > > The Contributor's Guide (10.5.1) clearly states that "Python code should > use PEP 8". So, I'd like to be sure everyone agrees on the following points > which are part of applying this PEP: > > - Remove spaces before the opening parenthesis in function calls and > definitions, > e.g., f(x) instead of f (x). > I believe we should definitely follow PEP here. And ideally we should have a code formatter that does this for us, so we don't rely on people remembering that PEP is different from GNU C standarads. > > - Use `string` instead of `str` as an identifier − `str` being a > built-in type > already. Also common is `s`, but the Contributor's Guide also says (10.5.4) > that "Variable names should be complete words, rather than abbreviations." > (which is basically concerned with C++, but that particular rule is, in my > opinion, valid for Python too). In particular, this applies to > python/convertrules.py. > I can agree that it is wrong to use 'str', since 'str' is a built in type. In my opinion, for convertrules.py, we shoud just use 's', not 'string'. Even if we use the complete word 'string', there is no special meaning in it (it's not a special string, it's just a generic string). I believe it's analogous to using 'i' for an index in a c++ loop. > > - Use the standard naming conventions, especially CamelCase for class > names (the > current style being a mixture of CamelCase and sometimes > First_word_capitalized_with_underscores). Write module-level constants in > UPPERCASE_WITH_UNDERSCORES. Likewise, change things like >class error (Exception): pass > to >class MIDIConversionError(Exception): >pass > > In CamelCase names that contain acronyms, capitalize all letters of the > acronym > (thus, the previous example doesn't read 'MidiConversionError'). > > > I think we should follow the standard here. > There are many specific changes that could be done to improve style and > readability > (such as replacing `ls = list(something); ls.sort()` with `ls = > sorted(something)`, > etc.), but the above could be made in general commits fixing all Python > files. > I would be supportive of changes to improve style and readability, but might question if it's worth the time. However, I'd support anybody who wants to scratch that itch. Making things compatible with PEP8 is certainly a good idea. Thanks, Carl
Python coding style
Hi everybody, There is some discussion in !212 about coding style inside our Python scripts. The Contributor's Guide (10.5.1) clearly states that "Python code should use PEP 8". So, I'd like to be sure everyone agrees on the following points which are part of applying this PEP: - Remove spaces before the opening parenthesis in function calls and definitions, e.g., f(x) instead of f (x). - Use `string` instead of `str` as an identifier − `str` being a built-in type already. Also common is `s`, but the Contributor's Guide also says (10.5.4) that "Variable names should be complete words, rather than abbreviations." (which is basically concerned with C++, but that particular rule is, in my opinion, valid for Python too). In particular, this applies to python/convertrules.py. - Use the standard naming conventions, especially CamelCase for class names (the current style being a mixture of CamelCase and sometimes First_word_capitalized_with_underscores). Write module-level constants in UPPERCASE_WITH_UNDERSCORES. Likewise, change things like class error (Exception): pass to class MIDIConversionError(Exception): pass In CamelCase names that contain acronyms, capitalize all letters of the acronym (thus, the previous example doesn't read 'MidiConversionError'). There are many specific changes that could be done to improve style and readability (such as replacing `ls = list(something); ls.sort()` with `ls = sorted(something)`, etc.), but the above could be made in general commits fixing all Python files. Any thoughts? Best, Jean
Re: Rendering chords in "Danish" style
On 4/19/20, Michael Bisgaard Olesen wrote: > *(Resending because it didn't seem to go through the first time)* Greetings, if you’re subscribed to the -devel list, your messages should go through immediately. Perhaps your first message got stuck because your address was not subscribed yet and as such it had to be approved manually? > The song is in Danish and I'd like the chords to be rendered in the > traditional Danish style. I don't know if this is Danish only (could be > Scandinavian?) If you can investigate, that would be great. Alternatively, could you elaborate on what constitutes “Danish” style, and according to which sources? More generally, more contributions are always welcome and I happily encourage you to read some of our Contributor's Guide if you haven’t already done so: http://lilypond.org/doc/latest/Documentation/contributor/overview-of-work-flow > I'd like to try and add support for "D-style" in lilypond, so I made the > following patch with my change: Hm. You may have noticed the couple of TODOs and FIXMEs I added last year; the chord naming system is a bit of a mess and I’ve only started cleaning it up. (There were _three_ different, unrelated methods for turning a pitch into a text string in LilyPond; now there are only two and I’m hoping we can factorize that further.) As I said in these comments in chord-name.scm, there must be a way of making the notation more flexible and to avoid requiring large chunks of code duplication like what you did here. One possibility worth exploring is to take advantage of the note-name->lily-string function I rewrote (see at the bottom of translation-functions.scm). Actually, your suggestion might be a good occasion of pursuing the cleanup I had initiated. Feel free to take a look! As for the other tweaks you mentioned that could certainly fit into a predefined variable (see for example property-init.ly) -- but then again, some sources would be needed to document the existing engraving practices in Danish/Scandinavian printed music. Cheers, V.
Rendering chords in "Danish" style
*(Resending because it didn't seem to go through the first time)*
Hi there.
I recently stumbled upon this great project and thought I'd use it to
render the score of a little melody with chords and lyrics.
The song is in Danish and I'd like the chords to be rendered in the
traditional Danish style. I don't know if this is Danish only (could be
Scandinavian?), but I'll just refer to it as D-style. In any case, it
doesn't seem to be supported by lilypond. So I took a look at the source
and found a way to make it render (almost) like I want it.
The "D-style" is a mix between default and semi-german:
- The chord name is like semi-german.
- The note name is like default but lower case (and "h" instead of "b" like
semi-german).
I'd like to try and add support for "D-style" in lilypond, so I made the
following patch with my change:
---
scm/chord-name.scm | 12
1 file changed, 12 insertions(+)
diff --git a/scm/chord-name.scm b/scm/chord-name.scm
index 3ec61b435a..0f962d32b4 100644
--- a/scm/chord-name.scm
+++ b/scm/chord-name.scm
@@ -137,6 +137,18 @@ note names are capitalized."
(list-ref '( "ses" "s" "" "is" "isis") (+ 2 (cdr n-a)))
(list-ref '("eses" "es" "" "is" "isis") (+ 2 (cdr n-a)
+(define-safe-public (note-name->danish-markup pitch lowercase?)
+ (let* ((name (ly:pitch-notename pitch))
+ (alt-semitones (pitch-alteration-semitones pitch))
+ (n-a (if (member (cons name alt-semitones) `((6 . -1) (6 . -2)))
+ (cons 7 (+ 1 alt-semitones))
+ (cons name alt-semitones
+ (make-line-markup
+ (list
+(make-simple-markup
+ (list-ref '("c" "d" "e" "f" "g" "a" "h" "b") (car n-a)))
+(accidental->markup-italian (ly:pitch-alteration pitch))
+
(define ((chord-name->italian-markup french?) pitch lowercase?)
"Return pitch markup for @var{pitch}, using Italian/@/French note names.
If @var{re-with-eacute} is set to @code{#t}, french `ré' is returned for
--
2.20.1
This is clearly just a draft, but I'd like guidance on what it would take
to get it included. From skimming the docs, it looks like posting here is
the right way to start this discussion.
For reference, this is the melody:
melody = \relative g' {
\key g \major
\time 4/4
\partial 4
a
b d8 g, a4 c8 fis,
g4 b2 fis4
g b a e
fis2 r4 e4 \break
fis g a b8 c
d4. c8 b4 a8 b
c4 b8 a8 ~ a8 g8 fis4
g2 r4 \bar "|."
}
text = \lyricmode {
Jeg els -- ker den bro -- ge -- de ver -- den
trods al dens nød og stid;
for mig er jord - en skøn end -- nu
som i pa -- tri -- ar -- ker -- nes tid.
}
harmonies = \chordmode {
s4
g2 d/fis e1:min c2 a d1
c2 d/fis g/b c g/d d4 d:7 g2
}
\score {
<<
\new ChordNames {
\harmonies
}
\new Voice = "one" {
\melody
}
\new Lyrics \lyricsto "one" \text
>>
\layout {
\context {
\Score
chordRootNamer = #(chord-name->german-markup #f)
chordNoteNamer = #note-name->danish-markup
}
}
\midi { \tempo 2 = 60 }
}
There are other changes that I'd like to make, but might be out of scope or
the change above:
- Use a different font (in italics) for the chords.
- Render # and b as superscript with reduced size.
- Render 7 as non-superscript.
- Have "d d7" rendered as "D -7" (instead of "D D7") if it's within the
same measure. Same for "c c/g"; should be "C -/g".
Rendering chords in "Danish" style
Hi there.
I recently stumbled upon this great project and thought I'd use it to
render the score of a little melody with chords and lyrics.
The song is in Danish and I'd like the to be rendered in the traditional
Danish style. I don't know if this is Danish only (could be Scandinavian?),
but I'll just refer to it as D-style. In any case, it doesn't seem to be
supported by lilypond. So I took a look at the source and found a way to
make it render (almost) like I want it.
The "D-style" is a mix between default and semi-german:
- The chord name is like semi-german.
- The note name is like default but lower case (and "h" instead of "b" like
semi-german).
I'd like to try and add support for "D-style" in lilypond, so I made the
following patch with my change:
---
scm/chord-name.scm | 12
1 file changed, 12 insertions(+)
diff --git a/scm/chord-name.scm b/scm/chord-name.scm
index 3ec61b435a..0f962d32b4 100644
--- a/scm/chord-name.scm
+++ b/scm/chord-name.scm
@@ -137,6 +137,18 @@ note names are capitalized."
(list-ref '( "ses" "s" "" "is" "isis") (+ 2 (cdr n-a)))
(list-ref '("eses" "es" "" "is" "isis") (+ 2 (cdr n-a)
+(define-safe-public (note-name->danish-markup pitch lowercase?)
+ (let* ((name (ly:pitch-notename pitch))
+ (alt-semitones (pitch-alteration-semitones pitch))
+ (n-a (if (member (cons name alt-semitones) `((6 . -1) (6 . -2)))
+ (cons 7 (+ 1 alt-semitones))
+ (cons name alt-semitones
+ (make-line-markup
+ (list
+(make-simple-markup
+ (list-ref '("c" "d" "e" "f" "g" "a" "h" "b") (car n-a)))
+(accidental->markup-italian (ly:pitch-alteration pitch))
+
(define ((chord-name->italian-markup french?) pitch lowercase?)
"Return pitch markup for @var{pitch}, using Italian/@/French note names.
If @var{re-with-eacute} is set to @code{#t}, french `ré' is returned for
--
2.20.1
This is clearly just a draft, but I'd like guidance on what it would take
to get it included. From skimming the docs, it looks like posting here is
the right way to start this discussion. As I'm completely new here, I
apologize if it isn't.
For reference, this is the melody:
melody = \relative g' {
\key g \major
\time 4/4
\partial 4
a
b d8 g, a4 c8 fis,
g4 b2 fis4
g b a e
fis2 r4 e4 \break
fis g a b8 c
d4. c8 b4 a8 b
c4 b8 a8 ~ a8 g8 fis4
g2 r4 \bar "|."
}
text = \lyricmode {
Jeg els -- ker den bro -- ge -- de ver -- den
trods al dens nød og stid;
for mig er jord - en skøn end -- nu
som i pa -- tri -- ar -- ker -- nes tid.
}
harmonies = \chordmode {
s4
g2 d/fis e1:min c2 a d1
c2 d/fis g/b c g/d d4 d:7 g2
}
\score {
<<
\new ChordNames {
\harmonies
}
\new Voice = "one" {
\melody
}
\new Lyrics \lyricsto "one" \text
>>
\layout {
\context {
\Score
chordRootNamer = #(chord-name->german-markup #f)
chordNoteNamer = #note-name->danish-markup
}
}
\midi { \tempo 2 = 60 }
}
There are other changes that I'd like to make, but might be out of scope or
the change above:
- Use a different font (in italics) for the chords.
- Render # and b as superscript with reduced size.
- Render 7 as non-superscript.
- Have "d d7" rendered as "D -7" (instead of "D D7") if it's within the
same measure. Same for "c c/g"; should be "C -/g".
Re: Cast to Real in C++ style throughout (issue 547560044 by hanw...@gmail.com)
Reviewers: Dan Eble, dak,
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc
File lily/spring.cc (right):
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119
lily/spring.cc:119: avg_stretch /= static_cast (springs.size ());
On 2020/02/02 18:51:08, Dan Eble wrote:
> This is not an issue with this change, but should this function do
something
> other than divide by zero when springs is empty?
what is the average of an empty set of numbers?
the 2 callers use a fallback in case there are not springs.
Description:
Cast to Real in C++ style throughout
Please review this at https://codereview.appspot.com/547560044/
Affected files (+23, -20 lines):
M flower/cpu-timer.cc
M flower/include/drul-array.hh
M lily/bracket.cc
M lily/freetype.cc
M lily/midi-walker.cc
M lily/open-type-font.cc
M lily/pango-font.cc
M lily/pitch.cc
M lily/spring.cc
M lily/stem.cc
M lily/volta-bracket.cc
Index: flower/cpu-timer.cc
diff --git a/flower/cpu-timer.cc b/flower/cpu-timer.cc
index
1bf93e30840288fb948cc73cdfe2e60c5cf990cc..f05f30308da7c0ea627d8f6a035ef4f5cb8573e6
100644
--- a/flower/cpu-timer.cc
+++ b/flower/cpu-timer.cc
@@ -45,5 +45,6 @@ Real
Cpu_timer::read ()
{
clock_t stop = clock ();
- return Real (stop - start_clock_) / Real (CLOCKS_PER_SEC);
+ return static_cast (stop - start_clock_)
+ / static_cast (CLOCKS_PER_SEC);
}
Index: flower/include/drul-array.hh
diff --git a/flower/include/drul-array.hh b/flower/include/drul-array.hh
index
43a01d65003667f521184e10cc7a6bba74795ff3..6144a5fd38f10a7b05d10a5d5b43b311deb25d7d
100644
--- a/flower/include/drul-array.hh
+++ b/flower/include/drul-array.hh
@@ -73,8 +73,8 @@ scale_drul (Drul_array *dr, T x)
inline Real
linear_combination (Drul_array const , Real x)
{
- return ((1.0 - x) * Real (d.at (LEFT))
- + (x + 1.0) * Real (d.at (RIGHT))) * 0.5;
+ return ((1.0 - x) * static_cast (d.at (LEFT))
+ + (x + 1.0) * static_cast (d.at (RIGHT))) * 0.5;
}
#endif /* DRUL_ARRAY_HH */
Index: lily/bracket.cc
diff --git a/lily/bracket.cc b/lily/bracket.cc
index
7c6a5f6691beca5a6d45d90a9809133147290856..02bce08c51a94a5958fcd4c25fb0ab2d3e785271
100644
--- a/lily/bracket.cc
+++ b/lily/bracket.cc
@@ -104,7 +104,7 @@ Bracket::make_axis_constrained_bracket (Grob *me, Real
length, Axis a,
Interval (0, 0));
// Make sure that it points in the correct direction:
- scale_drul (_height, Real (-dir));
+ scale_drul (_height, static_cast (-dir));
Offset start;
start[a] = length;
Index: lily/freetype.cc
diff --git a/lily/freetype.cc b/lily/freetype.cc
index
339c42128450bfdf569b5ff9b01507e8ceed3abb..2c4258960d887393e5ffb5f3a15b62e968b6f34a
100644
--- a/lily/freetype.cc
+++ b/lily/freetype.cc
@@ -44,8 +44,9 @@ ly_FT_get_unscaled_indexed_char_dimensions (FT_Face const
, size_t signed_i
FT_Pos vb = m.horiBearingY;
// is this viable for all grobs?
- return Box (Interval (Real (hb), Real (hb + m.width)),
- Interval (Real (vb - m.height), Real (vb)));
+ return Box (
+ Interval (static_cast (hb), static_cast (hb + m.width)),
+ Interval (static_cast (vb - m.height), static_cast (vb)));
}
SCM
Index: lily/midi-walker.cc
diff --git a/lily/midi-walker.cc b/lily/midi-walker.cc
index
912ee265eba03d1698ad7a4bdb8854b48567d880..033116fb1a531b9f7e075940c5e9c4a32ed6652f
100644
--- a/lily/midi-walker.cc
+++ b/lily/midi-walker.cc
@@ -87,8 +87,9 @@ Midi_walker::do_start_note (Midi_note *note)
Audio_item *ptr = items_[index_];
assert (note->audio_ == ptr);
int now_ticks = ptr->audio_column_->ticks ();
- int stop_ticks = int (moment_to_real (note->audio_->length_mom_) *
-Real (384 * 4)) + now_ticks;
+ int stop_ticks = int (moment_to_real (note->audio_->length_mom_)
+* static_cast (384 * 4))
+ + now_ticks;
for (vsize i = 0; i < stop_note_queue.size (); i++)
{
/* if this pitch already in queue, and is not already ignored */
Index: lily/open-type-font.cc
diff --git a/lily/open-type-font.cc b/lily/open-type-font.cc
index
dfd21e48c71791aba1e78b83ff90cc2a1887d2e0..e4b25e39e128206e0e4cd15e046e1f02e521cb0e
100644
--- a/lily/open-type-font.cc
+++ b/lily/open-type-font.cc
@@ -350,7 +350,7 @@ Open_type_font::get_indexed_char_dimensions (size_t
signed_idx) const
Box b = get_unscaled_indexed_char_dimensions (signed_idx);
- b.scale (design_size () / Real (face_->units_per_EM));
+ b.scale (design_size () / static_cast (face_->units_per_EM));
return b;
}
@@ -420,7 +420,7 @@ Open_type_font::design_size () const
quickly. --hwn.
*/
scm_from_unsigned_integer (1));
- return scm_to_double (entry) * Real (point_constant);
+ return scm_to_double (entry) * static_cast (point_constant);
}
SCM
Re: Cast to Real in C++ style throughout (issue 547560044 by hanw...@gmail.com)
On 2020/02/02 18:51:08, Dan Eble wrote: > LGTM > > https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc > File lily/spring.cc (right): > > https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119 > lily/spring.cc:119: avg_stretch /= static_cast (springs.size ()); > This is not an issue with this change, but should this function do something > other than divide by zero when springs is empty? Possibly. We have had a few reports of combinations of forced breaks leading to failed assertions. Dividing by Real zero (which was done here before as well due to conversion rules) does not throw divide-by-zero but results in ±inf.0 (unless the numerator is also zero, then you get ±nan.0). So I won't rule out that some of the triggering cases might have come through this code path. https://codereview.appspot.com/547560044/
Cast to Real in C++ style throughout (issue 547560044 by hanw...@gmail.com)
LGTM https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc File lily/spring.cc (right): https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119 lily/spring.cc:119: avg_stretch /= static_cast (springs.size ()); This is not an issue with this change, but should this function do something other than divide by zero when springs is empty? https://codereview.appspot.com/547560044/
Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
Urs Liska writes: > Am Freitag, den 31.01.2020, 18:38 +0100 schrieb: >> Urs Liska writes: >> >> > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org: >> > > On 2020/01/29 12:20:10, mail5 wrote: >> > > > Unfortunately I haven't set up a build system on my new >> > > > computer >> > > > yet, >> > > > so this >> > > > patch is not tested locally at all, so I'm humbly waiting for >> > > > the >> > > > automated >> > > > tests to succeed or fail ... >> > > >> > > I don't like the "use-modules clauses adjusted accordingly". I >> > > don't >> > > think it makes sense readjusting use-modules clauses all the time >> > > while >> > > we are deciding on the final module organisation, so I'd strongly >> > > suggest first biting the bullet and deciding on a syntax for a >> > > user-level command able to load Scheme modules without further >> > > options, >> > > and then introduce that command. In that manner, future >> > > directory >> > > organisations (which are almost certain to come) will not affect >> > > the >> > > source of user-level documents any more. >> > > >> > > https://codereview.appspot.com/567140045/ >> > >> > Maybe I'm missing something, but AFAICS there will always be the >> > need >> > for a module path like (ice-9 regex), or (scm display-lily). We >> > will >> > have that with *any* user-facing load syntax. >> >> \loadScmPackage display-lily >> >> or even >> >> \loadPackage display-lily.scm >> >> with the last .scm getting interpreted specially. >> >> #(use-modules ...) is not a user-facing load syntax. We don't want >> people to have to change their input when an optional package >> migrates >> to the system or a local package changes hierarchy. Specific path >> components may make sense for disambiguation, but if I take a look at >> what LaTeX does, a flat hierarchy as first user-level approximation >> does >> not appear to have significant scaling problems. > > I'm not so sure about that. In the LaTeX world this means that you > have to come up with file names that are unique to the whole ecosystem Yes. > because otherwise you're relying on luck that "your" file is found > first in case of conflicts. I had this several times, mostly in the > form of requests of TeX Live maintainers to rename files which were > considered dangerously generic. So? If you put 5 logical layers before "Schenker", two different Schenker graph packages will still collide because the logical categories are still all a match. You are not even kicking the can down the road that way, you are just making it bigger. > The other thing to consider is that path components are (currently) > not only used for disambiguation but also for the lookup. LilyPond > starts searching for files at each include path, and it relies on > relative paths starting from a (any) include path. LaTeX, however, > recursively searches for files starting from the include paths. I > think going that route would have several negative impacts > (disadvantage/risk): > > * The recursive search is potentially expensive Which is why path databases ultimately exist. > * There are actual risks of loops in the search path Only for symbolic links. > * Targets are not really specified, using relative paths is > more expressive and explicit. * kpathsea is pretty complex and has > corner cases that don't work well (e.g. it doesn't always follow > symlinks when a directory does not contain at least one "real" file), > and we would knowingly have to decide creating and maintaining a > comparable tool Eventually. > So, requiring explicit paths gives clearer interfaces (although more > typing is required) and reduces searching complexity. I don't see at all that it is a clearer interface if you have to specify a detailed path with information that will either be the same for packages with potential conflicting names due to sharing functionality, or arbitrary. Take a look actually more or less at _any_ package system, be it TeX, Debian, PEP, RPM, Emacs. The namespace for requesting a package is flat. On all of them. There are search hierarchies containing them, but they don't make for unique paths in any way. > In the case of display-lily and all other built-in modules we can > reduce this by adding the scm directory to the include path. But for > external packages I am pretty sure that using explicit paths from the > include paths (like we already have it with \include) makes sense. I don't think it makes sense to have users exposed to the internal placement of packages organized in directory trees, and I don't know any package system that does. The internal scm files loaded by LilyPond don't need to be visible to the user. Those optionally loaded manually (for example, (scm accreg)) are a different game. > However, I'd like to stress that we are (or at least should be) talking > about several different things when saying "package" and "loading": > > 1) > Loading a package/module *file*, parsing its code and
Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
Am Freitag, den 31.01.2020, 18:38 +0100 schrieb David Kastrup: > Urs Liska writes: > > > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org: > > > On 2020/01/29 12:20:10, mail5 wrote: > > > > Unfortunately I haven't set up a build system on my new > > > > computer > > > > yet, > > > so this > > > > patch is not tested locally at all, so I'm humbly waiting for > > > > the > > > automated > > > > tests to succeed or fail ... > > > > > > I don't like the "use-modules clauses adjusted accordingly". I > > > don't > > > think it makes sense readjusting use-modules clauses all the time > > > while > > > we are deciding on the final module organisation, so I'd strongly > > > suggest first biting the bullet and deciding on a syntax for a > > > user-level command able to load Scheme modules without further > > > options, > > > and then introduce that command. In that manner, future > > > directory > > > organisations (which are almost certain to come) will not affect > > > the > > > source of user-level documents any more. > > > > > > https://codereview.appspot.com/567140045/ > > > > Maybe I'm missing something, but AFAICS there will always be the > > need > > for a module path like (ice-9 regex), or (scm display-lily). We > > will > > have that with *any* user-facing load syntax. > > \loadScmPackage display-lily > > or even > > \loadPackage display-lily.scm > > with the last .scm getting interpreted specially. > > #(use-modules ...) is not a user-facing load syntax. We don't want > people to have to change their input when an optional package > migrates > to the system or a local package changes hierarchy. Specific path > components may make sense for disambiguation, but if I take a look at > what LaTeX does, a flat hierarchy as first user-level approximation > does > not appear to have significant scaling problems. I'm not so sure about that. In the LaTeX world this means that you have to come up with file names that are unique to the whole ecosystem because otherwise you're relying on luck that "your" file is found first in case of conflicts. I had this several times, mostly in the form of requests of TeX Live maintainers to rename files which were considered dangerously generic. The other thing to consider is that path components are (currently) not only used for disambiguation but also for the lookup. LilyPond starts searching for files at each include path, and it relies on relative paths starting from a (any) include path. LaTeX, however, recursively searches for files starting from the include paths. I think going that route would have several negative impacts (disadvantage/risk): * The recursive search is potentially expensive * There are actual risks of loops in the search path * Targets are not really specified, using relative paths is more expressive and explicit. * kpathsea is pretty complex and has corner cases that don't work well (e.g. it doesn't always follow symlinks when a directory does not contain at least one "real" file), and we would knowingly have to decide creating and maintaining a comparable tool So, requiring explicit paths gives clearer interfaces (although more typing is required) and reduces searching complexity. In the case of display-lily and all other built-in modules we can reduce this by adding the scm directory to the include path. But for external packages I am pretty sure that using explicit paths from the include paths (like we already have it with \include) makes sense. ### However, I'd like to stress that we are (or at least should be) talking about several different things when saying "package" and "loading": 1) Loading a package/module *file*, parsing its code and making elements available to clients 1a) One question is how to address these includable files 1b) The other question is where the elements and which elements of the loaded files are visible. 2) Loading/using a package in a more conceptual sense, like "edition- engraver" or "scholarLY". Here all the stuff about option handling becomes (more) relevant, and the questions of 1) are prerequisites. ### So when talking about new commands to "load packages" we are actually talking about two different things that *both* have to be done. Urs
Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
Urs Liska writes: > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org: >> On 2020/01/29 12:20:10, mail5 wrote: >> > Unfortunately I haven't set up a build system on my new computer >> > yet, >> so this >> > patch is not tested locally at all, so I'm humbly waiting for the >> automated >> > tests to succeed or fail ... >> >> I don't like the "use-modules clauses adjusted accordingly". I don't >> think it makes sense readjusting use-modules clauses all the time >> while >> we are deciding on the final module organisation, so I'd strongly >> suggest first biting the bullet and deciding on a syntax for a >> user-level command able to load Scheme modules without further >> options, >> and then introduce that command. In that manner, future directory >> organisations (which are almost certain to come) will not affect the >> source of user-level documents any more. >> >> https://codereview.appspot.com/567140045/ > > Maybe I'm missing something, but AFAICS there will always be the need > for a module path like (ice-9 regex), or (scm display-lily). We will > have that with *any* user-facing load syntax. \loadScmPackage display-lily or even \loadPackage display-lily.scm with the last .scm getting interpreted specially. #(use-modules ...) is not a user-facing load syntax. We don't want people to have to change their input when an optional package migrates to the system or a local package changes hierarchy. Specific path components may make sense for disambiguation, but if I take a look at what LaTeX does, a flat hierarchy as first user-level approximation does not appear to have significant scaling problems. > > My thought was to separate the two different types of .scm files in > that directory, and that could of course also be achieved by moving the > *other* files, those that are loaded with ly:load from lily.scm to a > different directory. > > Or - of course - I can simply drop this and add new modules to that > same directory for now. > >> > > > -- David Kastrup
Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
On Wed, Jan 29, 2020 at 4:02 PM wrote: > > On 2020/01/29 12:20:10, mail5 wrote: > > Unfortunately I haven't set up a build system on my new computer yet, > so this > > patch is not tested locally at all, so I'm humbly waiting for the > automated > > tests to succeed or fail ... > > I don't like the "use-modules clauses adjusted accordingly". I don't > think it makes sense readjusting use-modules clauses all the time while > we are deciding on the final module organisation, so I'd strongly > suggest first biting the bullet and deciding on a syntax for a I agree with David here. Let's solve the hard problem first before we care about cosmetics. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org: > On 2020/01/29 12:20:10, mail5 wrote: > > Unfortunately I haven't set up a build system on my new computer > > yet, > so this > > patch is not tested locally at all, so I'm humbly waiting for the > automated > > tests to succeed or fail ... > > I don't like the "use-modules clauses adjusted accordingly". I don't > think it makes sense readjusting use-modules clauses all the time > while > we are deciding on the final module organisation, so I'd strongly > suggest first biting the bullet and deciding on a syntax for a > user-level command able to load Scheme modules without further > options, > and then introduce that command. In that manner, future directory > organisations (which are almost certain to come) will not affect the > source of user-level documents any more. > > https://codereview.appspot.com/567140045/ Maybe I'm missing something, but AFAICS there will always be the need for a module path like (ice-9 regex), or (scm display-lily). We will have that with *any* user-facing load syntax. My thought was to separate the two different types of .scm files in that directory, and that could of course also be achieved by moving the *other* files, those that are loaded with ly:load from lily.scm to a different directory. Or - of course - I can simply drop this and add new modules to that same directory for now. >
Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
On 2020/01/29 12:20:10, mail5 wrote: > Unfortunately I haven't set up a build system on my new computer yet, so this > patch is not tested locally at all, so I'm humbly waiting for the automated > tests to succeed or fail ... I don't like the "use-modules clauses adjusted accordingly". I don't think it makes sense readjusting use-modules clauses all the time while we are deciding on the final module organisation, so I'd strongly suggest first biting the bullet and deciding on a syntax for a user-level command able to load Scheme modules without further options, and then introduce that command. In that manner, future directory organisations (which are almost certain to come) will not affect the source of user-level documents any more. https://codereview.appspot.com/567140045/
Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)
Reviewers: , Message: Unfortunately I haven't set up a build system on my new computer yet, so this patch is not tested locally at all, so I'm humbly waiting for the automated tests to succeed or fail ... Description: Move Guile-style modules from scm to scm-modules As an initial step towards a package mechanism this patch separates .scm files in /scm that are directly loaded with ly:load from those that are explicitly loaded with (use-modules (scm ... The latter are moved to a new directory /scm-modules, and the (use-modules clauses adjusted accordingly. Load Scheme modules through scm-modules Move Scheme modules to scm-modules Please review this at https://codereview.appspot.com/567140045/ Affected files (+83, -7862 lines): M Documentation/snippets/accordion-register-symbols.ly M input/regression/display-lily-tests.ly M input/regression/scheme-book-scores.ly M input/regression/to-xml.ly M ly/articulate.ly M ly/festival.ly M ly/graphviz-init.ly M ly/guile-debugger.ly M ly/init.ly A + scm-modules/accreg.scm A + scm-modules/clip-region.scm A + scm-modules/coverage.scm A + scm-modules/display-lily.scm A + scm-modules/editor.scm A + scm-modules/framework-eps.scm A + scm-modules/framework-null.scm A + scm-modules/framework-ps.scm A + scm-modules/framework-scm.scm A + scm-modules/framework-svg.scm A + scm-modules/graphviz.scm A + scm-modules/guile-debugger.scm A + scm-modules/lily.scm A + scm-modules/ly-syntax-constructors.scm A + scm-modules/memory-trace.scm A + scm-modules/output-ps.scm A + scm-modules/output-socket.scm A + scm-modules/output-svg.scm A + scm-modules/page.scm A + scm-modules/paper-system.scm A + scm-modules/ps-to-png.scm A + scm-modules/safe-utility-defs.scm A + scm-modules/song.scm A + scm-modules/song-util.scm A + scm-modules/to-xml.scm D scm/accreg.scm M scm/backend-library.scm M scm/chord-entry.scm D scm/clip-region.scm D scm/coverage.scm M scm/define-music-display-methods.scm M scm/define-music-types.scm M scm/define-note-names.scm D scm/display-lily.scm M scm/document-markup.scm M scm/documentation-generate.scm D scm/editor.scm D scm/framework-eps.scm D scm/framework-null.scm D scm/framework-ps.scm D scm/framework-scm.scm M scm/framework-socket.scm D scm/framework-svg.scm D scm/graphviz.scm D scm/guile-debugger.scm D scm/lily.scm M scm/lily-library.scm D scm/ly-syntax-constructors.scm D scm/memory-trace.scm M scm/music-functions.scm D scm/output-ps.scm D scm/output-socket.scm D scm/output-svg.scm D scm/page.scm M scm/paper.scm D scm/paper-system.scm D scm/ps-to-png.scm D scm/safe-utility-defs.scm D scm/song.scm D scm/song-util.scm M scm/stencil.scm D scm/to-xml.scm M scripts/lilypond-invoke-editor.scm
Re: Executable options style question
Thanks Hans!
JM
> Le 11 juil. 2019 à 18:01, Hans Åberg a écrit :
>
>
>> On 11 Jul 2019, at 09:32, Jacques Menu wrote:
>>
>> I’ve wondering about command line options with multiple values.
>>
>> Which one of the following in preferable in your opinion:
>>
>> DESSUS="Cor anglais"
>> xml2ly -msr-part-rename "P1 = ${DESSUS}"
>>
>> or:
>>
>> DESSUS="Cor anglais"
>> xml2ly -msr-part-rename P1 "${DESSUS}”
>
> POSIX, Guideline 8 [1] says that they should be presented as a single
> argument to the option, separated with comma or blanks within that argument.
> GNU [2] does not mention that explicitly.
>
> 1. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
> 2. https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Executable options style question
> On 11 Jul 2019, at 09:32, Jacques Menu wrote:
>
> I’ve wondering about command line options with multiple values.
>
> Which one of the following in preferable in your opinion:
>
> DESSUS="Cor anglais"
> xml2ly -msr-part-rename "P1 = ${DESSUS}"
>
> or:
>
> DESSUS="Cor anglais"
> xml2ly -msr-part-rename P1 "${DESSUS}”
POSIX, Guideline 8 [1] says that they should be presented as a single argument
to the option, separated with comma or blanks within that argument. GNU [2]
does not mention that explicitly.
1. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
2. https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Executable options style question
Hello folks,
I’ve wondering about command line options with multiple values.
Which one of the following in preferable in your opinion:
DESSUS="Cor anglais"
xml2ly -msr-part-rename "P1 = ${DESSUS}"
or:
DESSUS="Cor anglais"
xml2ly -msr-part-rename P1 "${DESSUS}"
Thanks for your advice!
JM
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 2018/04/10 17:21:43, Malte Meyn wrote: > make slashturn 4% thinner at the center (instead of 10% thicker) IMHO that’s an improvement. Yes, I agree. > haydnturn 0% > thicker (instead of 10% thicker) I’m not sure whether this is, the glyph shouldn’t be too slim to match the overall style of the Feta font. You're probably right. I am a little confused as to my eye-sight - even after I checked that the glyph is completely symmetric, I "feel" that the \haydnturn's right part is "steeper". At one point I thought it might be an optical illusion triggered by the note head below, but that's not the case (as can be seen by deleting that note head). So it's probably best to forget my remark after all. Anyway, this was not influenced by your change of thickness, so you might just as well follow your judgement about what look of the symbol matches the Feta 'flavour'. https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 2018/04/10 17:21:43, Malte Meyn wrote: make slashturn 4% thinner at the center (instead of 10% thicker) IMHO that’s an improvement. haydnturn 0% thicker (instead of 10% thicker) I’m not sure whether this is, the glyph shouldn’t be too slim to match the overall style of the Feta font. https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 2018/04/10 09:47:31, Lukas-Fabian Moser wrote:
This is gorgeous! Thanks very much!
Is the \haydnturn supposed to be symmetrical w.r.t. the stem? To me it
looks as
if it weighs slightly more on the left, but maybe I'm wrong? (And I'm
also not
sure if this would be a problem if I were right.)
The symbol is 100% symmetrical as I tested with the following code:
\markup \fill-line {
\fontsize #20 \overlay {
\rotate #180 \with-color #red \musicglyph "scripts.haydnturn"
\musicglyph "scripts.haydnturn"
}
}
But maybe it’s not well-balanced nethertheless?
(The Henle score that prompted me to ask in the first place - Haydn
Symphony Nr.
13 in Haydn, Werke, Reihe I, Band 3, ed. Braun/Gerlach - has a less
curly
version of the \haydnturn, but I like your design better.)
Yes, I don’t like the Henle (1972) version as well. I copied the fact
that it’s less bold than the turn and mordent but I made it a little but
more curly and centered the stem vertically (Henle makes the upper half
of the stem longer than the lower).
As for the \slashturn: I think the lenght of the stem is okay. But I
started to
wonder if the \slashturn should really be as "thick" at its waist as
the usual
\turn. Maybe there is a slight disbalance between the two parts (turn
vs.
slash).
You’re right. \turn and \reverseturn are 10% thicker at the very center
than at the “outer” thick parts. Making the \slashturn 4% thinner
instead looks good to me.
Maybe that’s also the reason for imbalance in the \haydnturn. Same
thickness instead of 10% thicker might look better.
I’ll make a patch set for slimmer center parts and attach the resulting
PDF to the sourceforge issue.
https://codereview.appspot.com/340660043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
This is gorgeous! Thanks very much! Is the \haydnturn supposed to be symmetrical w.r.t. the stem? To me it looks as if it weighs slightly more on the left, but maybe I'm wrong? (And I'm also not sure if this would be a problem if I were right.) (The Henle score that prompted me to ask in the first place - Haydn Symphony Nr. 13 in Haydn, Werke, Reihe I, Band 3, ed. Braun/Gerlach - has a less curly version of the \haydnturn, but I like your design better.) As for the \slashturn: I think the lenght of the stem is okay. But I started to wonder if the \slashturn should really be as "thick" at its waist as the usual \turn. Maybe there is a slight disbalance between the two parts (turn vs. slash). Best Lukas https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 2018/04/08 18:05:49, Dan Eble wrote: Having two symbols available does not necessarily require having unique commands for them. For example, LilyPond supports different styles of multi-measure rests, but they're all represented with R. I'm trying to understand whether these scripts are semantically distinct or just stylistically distinct. How would one make a single command that can use both styles? Maybe something like \override Script.haydnturn-style = #'turn % default #'wiggle ? It sounds like you're saying we don't know if they are semantically distinct, therefore we should implement commands as if they are. I have no objection to that; I just want to understand the intent and encourage an implementation that suits it. We don’t exactly know if \slashturn and \turn are semantically distinct either … As stated in my last post above it looks like many of these prall/mordent/turn/XXXturn symbols can replace each other in different editions. https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 2018/04/08 17:43:36, simon.albrecht wrote: I’m not sure what exactly the difference in performing is, but that’s not for us to consider; it’s important for scholarly editing (of mid-to-late 18th century music, especially Haydn) to have this symbol available. Having two symbols available does not necessarily require having unique commands for them. For example, LilyPond supports different styles of multi-measure rests, but they're all represented with R. I'm trying to understand whether these scripts are semantically distinct or just stylistically distinct. It sounds like you're saying we don't know if they are semantically distinct, therefore we should implement commands as if they are. I have no objection to that; I just want to understand the intent and encourage an implementation that suits it. Regards, Dan https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 2018/04/08 17:08:42, Dan Eble wrote: Is there a performance difference between these two scripts? I read quickly through the thread referenced in the ticket, but I couldn't find the answer. I don’t know; I’m not even sure whether \haydnturn should be played as \mordent or as \turn. The 1972 Henle edition of the piano sonatas writes “The sign [\haydnturn] usually signifies [d32 c b c4]. In an appropriate musical context, however, it can be performed as a mordent [c16 b c4]”. After looking through different editions of some piano sonatas on IMSLP I’ve got the impression that nobody knows exactly. I’ve seen \trill and \prall in the same place, \prall and \mordent, \mordent and \haydnturn, \mordent and \turn, \prall and \reverseturn, \turn and \reverseturn, … But no \slashturn. I added the latter because it’s a form seen in SMuFL and here: http://lilypond.1069038.n5.nabble.com/Requesting-an-addition-tp139819p139974.html https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
On 08.04.2018 19:08, nine.fierce.ball...@gmail.com wrote: Is there a performance difference between these two scripts? I read quickly through the thread referenced in the ticket, but I couldn't find the answer. I’m not sure what exactly the difference in performing is, but that’s not for us to consider; it’s important for scholarly editing (of mid-to-late 18th century music, especially Haydn) to have this symbol available. Best, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
Is there a performance difference between these two scripts? I read quickly through the thread referenced in the ticket, but I couldn't find the answer. https://codereview.appspot.com/340660043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)
Very nice! LGTM.
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf#newcode757
mf/feta-scripts.mf:757: set_char_box (wd# / 2, wd# / 2, ht# / 2 *
height_factor, ht# / 2 * height_factor);
Please avoid lines longer than 78 characters.
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf#newcode840
mf/feta-scripts.mf:840: set_char_box (wd# / 2, wd# / 2, ht# / 2 *
height_factor, ht# / 2 * height_factor);
Ditto.
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf#newcode861
mf/feta-scripts.mf:861: .. z3l{dir(60)}
Please use a space after `dir' to be in sync with the remaining code.
https://codereview.appspot.com/340660043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make emacs C++ style setting work for me (issue 333600043 by nine.fierce.ball...@gmail.com)
Reviewers: Malte Meyn, Message: On 2018/02/07 07:41:09, Malte Meyn wrote: “Make […] work for *me*” sounds as if this isn’t a general problem? I don’t know *anything* about emacs (except that vim is superior :P) but googling c-default-style makes me wonder whether this isn’t only a problem of your emacs config. I am using Emacs 25.3.1. My experience was that when c-default-style was set in the dir-locals, when I would open a lily/*.cc file, c-default-style would indeed change locally to the value in dir-locals, but the indentation mode of the buffer was set according to the original value of c-default-style in my emacs configuration. The documentation for c-indentation-style says this: Name of the currently installed style. Don’t change this directly; call ‘c-set-style’ instead, or set the variable ‘c-file-style’ in the file’s Local Variable list. Therefore, I tried setting c-file-style, and now the indentation mode is correct. Description: Make emacs C++ style setting work for me In the .dir-locals.el file for emacs, instead of setting c-default-style, set c-file-style. The former was not setting the style for the files I opened. Please review this at https://codereview.appspot.com/333600043/ Affected files (+1, -1 lines): M .dir-locals.el Index: .dir-locals.el diff --git a/.dir-locals.el b/.dir-locals.el index 72472a6055d9deeb7eac214bb61e06e9cb8c74cc..69bd6cae380de8a31252ad45f33e78bcaa11dbbe 100644 --- a/.dir-locals.el +++ b/.dir-locals.el @@ -2,7 +2,7 @@ ;;; See Info node `(emacs) Directory Variables' for more information. ((c++-mode - (c-default-style . "gnu") + (c-file-style . "gnu") (indent-tabs-mode)) (scheme-mode (indent-tabs-mode)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make emacs C++ style setting work for me (issue 333600043 by nine.fierce.ball...@gmail.com)
“Make […] work for *me*” sounds as if this isn’t a general problem? I don’t know *anything* about emacs (except that vim is superior :P) but googling c-default-style makes me wonder whether this isn’t only a problem of your emacs config. Is it possible that this patch breaks the behaviour for someone else? https://codereview.appspot.com/333600043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: GSoC: Add Style Sheets project (issue 340140043 by g...@ursliska.de)
LGTM https://codereview.appspot.com/340140043/diff/1/Documentation/included/gsoc.itexi File Documentation/included/gsoc.itexi (right): https://codereview.appspot.com/340140043/diff/1/Documentation/included/gsoc.itexi#newcode172 Documentation/included/gsoc.itexi:172: (this would involve working on Lilypond's C++ code) support for notation Lilypond's -> LilyPond's https://codereview.appspot.com/340140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4983 Let crossStaff hide non-default-style flags (issue 315330043 by thomasmorle...@gmail.com)
Reviewers: ,
Message:
Please review
Description:
Issue 4983 Let crossStaff hide non-default-style flags
Return empty-stencil for all flags using the code provided in
flag-styles.scm, if the style property is 'no-flag as set by
the crossStaff-function.
Please review this at https://codereview.appspot.com/315330043/
Affected files (+18, -21 lines):
M scm/flag-styles.scm
Index: scm/flag-styles.scm
diff --git a/scm/flag-styles.scm b/scm/flag-styles.scm
index
a2ddf3a9dd0bd8d728b2352c5ea7d03dbcc2b324..b17b3fc2abd62d3ed45e0d6853a44f126916590c
100644
--- a/scm/flag-styles.scm
+++ b/scm/flag-styles.scm
@@ -20,11 +20,6 @@
styles.
-(define-public (no-flag grob)
- "No flag: Simply return empty stencil."
- empty-stencil)
-
-
;;
Straight flags
;;
@@ -97,14 +92,16 @@ All lengths are scaled according to the font size of
the note."
;; Log for 1/8 is 3, so we need to subtract 3
(flag-stencil (buildflag stencil (- log 3) stencil spacing))
(stroke-style (ly:grob-property grob 'stroke-style)))
- (if (equal? stroke-style "grace")
- (add-stroke-straight flag-stencil grob
- dir log
- stroke-style
- flag-end flag-length
- thickness
- (* half-stem-thickness 2))
- flag-stencil
+ (cond ((eq? (ly:grob-property grob 'style) 'no-flag)
+ empty-stencil)
+ ((equal? stroke-style "grace")
+ (add-stroke-straight flag-stencil grob
+ dir log
+ stroke-style
+ flag-end flag-length
+ thickness
+ (* half-stem-thickness 2)))
+(else flag-stencil)
(define-public (modern-straight-flag grob)
"Modern straight flag style (for composers like Stockhausen, Boulez,
etc.).
@@ -174,10 +171,12 @@ flag stencil."
(dir (if (eqv? (ly:grob-property stem-grob 'direction)
UP) "u" "d"))
(flag (retrieve-glyph-flag flag-style dir dir-modifier grob))
(stroke-style (ly:grob-property grob 'stroke-style)))
-(if (null? stroke-style)
- flag
-(add-stroke-glyph flag grob dir stroke-style flag-style
-
+(cond ((eq? (ly:grob-property grob 'style) 'no-flag)
+ empty-stencil)
+ ((null? stroke-style)
+ flag)
+ (else
+ (add-stroke-glyph flag grob dir stroke-style flag-style)
(define-public (mensural-flag grob)
@@ -205,7 +204,6 @@ a flag always touches a staff line."
(create-glyph-flag "mensural" modifier grob)))
-
(define ((glyph-flag flag-style) grob)
"Simulatesthe default way of generating flags: Look up glyphs
@code{flags.style[ud][1234]} from the feta font and use it for the flag
@@ -214,13 +212,11 @@ stencil."
(export glyph-flag)
-
(define-public (normal-flag grob)
"Create a default flag."
(create-glyph-flag "" "" grob))
-
(define-public (default-flag grob)
"Create a flag stencil for the stem. Its style will be derived from the
@code{'style} Flag property. By default, @code{lilypond} uses a
@@ -242,5 +238,6 @@ at will. The correct way to do this is:
(cond
((equal? flag-style "") (normal-flag grob))
((equal? flag-style "mensural") (mensural-flag grob))
- ((equal? flag-style "no-flag") (no-flag grob))
+ ((equal? flag-style "no-flag") empty-stencil)
(else ((glyph-flag flag-style) grob)
+
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
LGTM https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
New patch set is online that includes an entry in changes.tely and changes the wording of the two places in question. Cheers, Alexander https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)
Alexander, you wrote Thursday, December 15, 2016 3:51 PM > On 2016-12-15 13:34, Trevor Daniels wrote: > >> Adding you to the dev list is very little work, but you do have to >> get a SourceForge id and tell me what it is for me to do that. >> >> James probably is willing to undertake the work of creating an >> issue and servicing it on your behalf, but if you yourself are not >> known to Allura you will not be able to contribute to any discussion >> on _any_ issue - including those James has created on your behalf. > > Okay, makes sense. In this case, I guess it's reasonable to add me no > matter how much (or little) I will participate. I created an SF account > with username akobel. Added, giving you Developer status. Now you can update and create issues as well as read them. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)
On 2016-12-15 13:34, Trevor Daniels wrote: Alexander, you wrote Wednesday, December 14, 2016 11:49 PM yes, I guess I never asked to be on that list. My last commit was pre-Rietveld and pre-Allura, I think; and it's unlikely that contributions from my side will come more often in the foreseeable future (except for one more patch "in the pipeline", waiting for a cleanup and documentation). So I guess it's not really worth to give me any other status than other occasional users. On the other hand, do whatever is the most convenient for you - handling a lonesome patch every other year manually or adding me. Adding you to the dev list is very little work, but you do have to get a SourceForge id and tell me what it is for me to do that. James probably is willing to undertake the work of creating an issue and servicing it on your behalf, but if you yourself are not known to Allura you will not be able to contribute to any discussion on _any_ issue - including those James has created on your behalf. Okay, makes sense. In this case, I guess it's reasonable to add me no matter how much (or little) I will participate. I created an SF account with username akobel. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)
Alexander, you wrote Wednesday, December 14, 2016 11:49 PM > yes, I guess I never asked to be on that list. My last commit was > pre-Rietveld and pre-Allura, I think; and it's unlikely that > contributions from my side will come more often in the foreseeable > future (except for one more patch "in the pipeline", waiting for a > cleanup and documentation). > So I guess it's not really worth to give me any other status than other > occasional users. On the other hand, do whatever is the most convenient > for you - handling a lonesome patch every other year manually or adding me. Adding you to the dev list is very little work, but you do have to get a SourceForge id and tell me what it is for me to do that. James probably is willing to undertake the work of creating an issue and servicing it on your behalf, but if you yourself are not known to Allura you will not be able to contribute to any discussion on _any_ issue - including those James has created on your behalf. Trevor > On 2016-12-14 16:28, Trevor Daniels wrote: >> >> Alexander, you wrote Wednesday, December 14, 2016 12:32 PM >> >>> On 2016-12-14 13:15, James wrote: >>> >>>> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: >>>>> Reviewers: , >>>>> >>>>> Message: >>>>> add choral and choral-cautionary accidental style >>>> ... >>>>> >>>>> Please review this at https://codereview.appspot.com/311430043/ >>>>> >>>>> Affected files (+151, -1 lines): >>>>> M Documentation/notation/pitches.itely >>>>> M ly/engraver-init.ly >>>>> M scm/music-functions.scm >>>>> >>>>> ___ >>>> >>>> Does this have an associated tracker item or do we need to create one >>>> for you? >>>> >>>> https://sourceforge.net/p/testlilyissues/issues/?source=navbar >>> >>> I don't think git-cl created one; I received some error message but I >>> thought it related to the known and documented "no automatic >>> notification" after patch upload. But obviously, I mis-configured >>> git-cl's Allura bearer token... >>> Please create one if you don't mind; I will have a look at the >>> configuration for my next upload. >> >> AFAICS you don't have developer status at SourceForge. Have you >> ever asked to be added as a developer? That would explain >> the failure. >> >> To fix it please send me (or post to the list) your SourceForge >> identifier and I'll add you. >> >> Trevor >> > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
On 2016-12-14 23:13, thomasmorle...@gmail.com wrote: Worth an entry in changes? Maybe. Doesn't need a lot, I guess; something like "Accidental rules can now be defined across ChoirStaff contexts. Two new rules choral and choral-cautionary are available that combine the characteristics of modern-voice and piano or their equivalents with cautionary accidentals." Some wording-nitpicks, otherwise LGTM Thanks. https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely#newcode2210 Documentation/notation/pitches.itely:2210: style. It is intended for editions that are used both by singers that only The wording feels not very elegant. Though, I'm a non-native speaker... Not a native speaker here, either, so I'm open to proposals. https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm#newcode1847 scm/music-functions.scm:1847: ;; that the first alteration within a voice (as opposed to on the wording again, maybe: Similar to piano, except that the first alteration within a voice is always printed (as opposed to within a staff). Agreed, that sounds better. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043 by perpeduumimmob...@gmail.com)
Hi Trevor, yes, I guess I never asked to be on that list. My last commit was pre-Rietveld and pre-Allura, I think; and it's unlikely that contributions from my side will come more often in the foreseeable future (except for one more patch "in the pipeline", waiting for a cleanup and documentation). So I guess it's not really worth to give me any other status than other occasional users. On the other hand, do whatever is the most convenient for you - handling a lonesome patch every other year manually or adding me. Cheers, Alexander On 2016-12-14 16:28, Trevor Daniels wrote: Alexander, you wrote Wednesday, December 14, 2016 12:32 PM On 2016-12-14 13:15, James wrote: On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar I don't think git-cl created one; I received some error message but I thought it related to the known and documented "no automatic notification" after patch upload. But obviously, I mis-configured git-cl's Allura bearer token... Please create one if you don't mind; I will have a look at the configuration for my next upload. AFAICS you don't have developer status at SourceForge. Have you ever asked to be added as a developer? That would explain the failure. To fix it please send me (or post to the list) your SourceForge identifier and I'll add you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Worth an entry in changes? Some wording-nitpicks, otherwise LGTM https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely File Documentation/notation/pitches.itely (right): https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely#newcode2210 Documentation/notation/pitches.itely:2210: style. It is intended for editions that are used both by singers that only The wording feels not very elegant. Though, I'm a non-native speaker... https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm File scm/music-functions.scm (right): https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm#newcode1847 scm/music-functions.scm:1847: ;; that the first alteration within a voice (as opposed to on the wording again, maybe: Similar to piano, except that the first alteration within a voice is always printed (as opposed to within a staff). But again: non-native-speaker https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue311430043 by perpeduumimmob...@gmail.com)
Alexander, you wrote Wednesday, December 14, 2016 12:32 PM > On 2016-12-14 13:15, James wrote: > >> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: >>> Reviewers: , >>> >>> Message: >>> add choral and choral-cautionary accidental style >> ... >>> >>> Please review this at https://codereview.appspot.com/311430043/ >>> >>> Affected files (+151, -1 lines): >>> M Documentation/notation/pitches.itely >>> M ly/engraver-init.ly >>> M scm/music-functions.scm >>> >>> ___ >> >> Does this have an associated tracker item or do we need to create one >> for you? >> >> https://sourceforge.net/p/testlilyissues/issues/?source=navbar > > I don't think git-cl created one; I received some error message but I > thought it related to the known and documented "no automatic > notification" after patch upload. But obviously, I mis-configured > git-cl's Allura bearer token... > Please create one if you don't mind; I will have a look at the > configuration for my next upload. AFAICS you don't have developer status at SourceForge. Have you ever asked to be added as a developer? That would explain the failure. To fix it please send me (or post to the list) your SourceForge identifier and I'll add you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Passes make, make check and a full make doc https://codereview.appspot.com/311430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
On 14/12/16 12:32, Alexander Kobel wrote: Hi James, thanks for taking care of that one. On 2016-12-14 13:15, James wrote: Hello, On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar I don't think git-cl created one; I received some error message but I thought it related to the known and documented "no automatic notification" after patch upload. But obviously, I mis-configured git-cl's Allura bearer token... Please create one if you don't mind; I will have a look at the configuration for my next upload. Actually I cannot see you (or an appropriate email) for you in the list of people able to create tickets so that may be why. https://sourceforge.net/p/testlilyissues/issues/5010/ has been created. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Hi James, thanks for taking care of that one. On 2016-12-14 13:15, James wrote: Hello, On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar I don't think git-cl created one; I received some error message but I thought it related to the known and documented "no automatic notification" after patch upload. But obviously, I mis-configured git-cl's Allura bearer token... Please create one if you don't mind; I will have a look at the configuration for my next upload. Thanks, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Hello, On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote: Reviewers: , Message: add choral and choral-cautionary accidental style ... Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ Does this have an associated tracker item or do we need to create one for you? https://sourceforge.net/p/testlilyissues/issues/?source=navbar Thanks James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)
Reviewers: , Message: add choral and choral-cautionary accidental style This solves the issues mentioned in https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00201.html that accidental style could not apply to ChoirStaves in the same way as they did for PianoStaves, StaffGroups or GrandStaves. No impact on existing functionality, but now ChoirStaves are equal siblings w.r.t. accidental styles. In addition, a reasonable mix of the modern-voice and piano cautionary style is defined, which caters to both all-observant and egocentric readers. Description: add choral and choral-cautionary accidental style This solves the issues mentioned in https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00201.html that accidental style could not apply to ChoirStaves in the same way as they did for PianoStaves, StaffGroups or GrandStaves. No impact on existing functionality, but now ChoirStaves are equal siblings w.r.t. accidental styles. In addition, a reasonable mix of the modern-voice and piano cautionary style is defined, which caters to both all-observant and egocentric readers. Please review this at https://codereview.appspot.com/311430043/ Affected files (+151, -1 lines): M Documentation/notation/pitches.itely M ly/engraver-init.ly M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement rounded-box whiteout style (issue 274590043 by paulwmor...@gmail.com)
On 2015/11/26 16:29:59, Trevor Daniels wrote: LGTM When this is pushed we ought to raise an issue to document whiteout properly in the NR. https://sourceforge.net/p/testlilyissues/issues/4681/ James https://codereview.appspot.com/274590043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement rounded-box whiteout style (issue 274590043 by paulwmor...@gmail.com)
Reviewers: ,
Message:
Please review, thanks,
-Paul
Description:
Implement rounded-box whiteout style
As suggested in issue 4504.
Includes edits to regression tests and
changes entry.
Please review this at https://codereview.appspot.com/274590043/
Affected files (+65, -25 lines):
M Documentation/changes.tely
M input/regression/whiteout.ly
M input/regression/whiteout-lower-layers.ly
M scm/define-grob-properties.scm
M scm/define-markup-commands.scm
M scm/stencil.scm
Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index
bc0807624b36f11ceefc38ec9f3f99a3f94f8bc8..24e973e4fd4c89d5ac438acf377c8376593eb5c0
100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -96,21 +96,30 @@ mus = \relative { c'4 cih d dih }
@end lilypond
@item
-A new style of whiteout that approximates the contours of a glyph's
-outline is now available using @code{whiteout-style}. The shape of the
-white background is produced from multiple displaced copies of the
-glyph. The @code{thickness} of both the new @code{outline} style and
-the default @code{box} style, as a multiple of staff-line thickness, can
-be customized.
+Two new styles of whiteout are now available. The @code{outline} style
+approximates the contours of a glyph's outline, and its shape is
+produced from multiple displaced copies of the glyph. The
+@code{rounded-box} style produces a rounded rectangle shape. For all
+three styles, including the default @code{box} style, the whiteout
+shape's @code{thickness}, as a multiple of staff-line thickness, can be
+customized.
+
@lilypond[verbatim,quote]
\markup {
\combine
\filled-box #'(-1 . 15) #'(-3 . 4) #1
-\override #'(thickness . 2)
+\override #'(thickness . 3)
\whiteout whiteout-box
}
\markup {
\combine
+\filled-box #'(-1 . 24) #'(-3 . 4) #1
+\override #'(style . rounded-box)
+\override #'(thickness . 3)
+\whiteout whiteout-rounded-box
+}
+\markup {
+ \combine
\filled-box #'(-1 . 18) #'(-3 . 4) #1
\override #'(style . outline)
\override #'(thickness . 3)
Index: input/regression/whiteout-lower-layers.ly
diff --git a/input/regression/whiteout-lower-layers.ly
b/input/regression/whiteout-lower-layers.ly
index
8549cbc783cde5c2ded54ea5550cc04749ca04ab..15c59e5770b04eee6afea06de97cfcbfec19078b
100644
--- a/input/regression/whiteout-lower-layers.ly
+++ b/input/regression/whiteout-lower-layers.ly
@@ -10,23 +10,35 @@ TimeSignature whites out the Tie but not the
StaffSymbol.
\relative {
\time 3/4
- \override Staff.StaffSymbol.layer = #4
- \once \override Tie.layer = #2
+ \override Staff.StaffSymbol.layer = 4
+ \once \override Tie.layer = 2
b'2.~
\once \override Staff.TimeSignature.whiteout = ##t
- \once \override Staff.TimeSignature.layer = #3
+ \once \override Staff.TimeSignature.layer = 3
\time 5/4
b4
}
\relative c' {
\time 3/4
- \override Staff.StaffSymbol.layer = #4
- \once \override Tie.layer = #2
+ \override Staff.StaffSymbol.layer = 4
+ \once \override Tie.layer = 2
+ b'2.~
+ \once \override Staff.TimeSignature.whiteout-style = #'rounded-box
+ \once \override Staff.TimeSignature.whiteout = 3
+ \once \override Staff.TimeSignature.layer = 3
+ \time 5/4
+ b4
+}
+
+\relative c' {
+ \time 3/4
+ \override Staff.StaffSymbol.layer = 4
+ \once \override Tie.layer = 2
b'2.~
\once \override Staff.TimeSignature.whiteout-style = #'outline
- \once \override Staff.TimeSignature.whiteout = #3
- \once \override Staff.TimeSignature.layer = #3
+ \once \override Staff.TimeSignature.whiteout = 3
+ \once \override Staff.TimeSignature.layer = 3
\time 5/4
b4
}
Index: input/regression/whiteout.ly
diff --git a/input/regression/whiteout.ly b/input/regression/whiteout.ly
index
7e10de9727be00498a693859cd563d77fe025808..543d94f369da04536a8fc13c3a88a0466871fac4
100644
--- a/input/regression/whiteout.ly
+++ b/input/regression/whiteout.ly
@@ -2,8 +2,9 @@
texidoc = "The whiteout command underlays a white background under a
markup. The shape is determined by @code{whiteout-style}. The default
-is @code{box} which produces a white rectangle. @code{outline}
-approximates the outline of the markup."
+is @code{box} which produces a rectangle. @code{rounded-box} produces
+a rounded rectangle. @code{outline} approximates the outline of the
+markup."
}
\version "2.19.32"
@@ -25,7 +26,13 @@ approximates the outline of the markup."
c
c-\markup {
\override #'(thickness . 3)
- \override #'(whiteout-style . outline)
+\override #'(style . rounded-box)
+\whiteout foo
+ }
+ c
+ c-\markup {
+\override #'(thickness . 3)
+\override #'(style . outline)
\whiteout foo
}
c
Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index
b387da206ea8bfeb304950075fe779f009b7e395..c50260d6c9672a29501338e777087e
Re: Implement rounded-box whiteout style (issue 274590043 by paulwmor...@gmail.com)
LGTM When this is pushed we ought to raise an issue to document whiteout properly in the NR. https://codereview.appspot.com/274590043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4504 whiteout-style
Hi Simon, > On Oct 25, 2015, at 6:02 PM, Simon Albrecht <simon.albre...@mail.de> wrote: > > I think this is not the best possible setting: If I want to apply > whiteout-outline now, I have to use two overrides. IMO it would be easier to > use if we had the two properties > – whiteout [possibly whiteout-style], with options 'none, 'box, and 'outline > – and whiteout-padding (a number). > What do you think? Hmmm… that seems worth considering. (And a good reminder for me to propose changes and hash out the best plan first before doing the full work of implementation...) I’ll give it some thought. Lets move this discussion to the issue tracker, to keep it all in one place: https://sourceforge.net/p/testlilyissues/issues/4504/ Also, the issues will be easier to discuss once the proposed changes are up on Rietveld... Thanks, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4504 whiteout-style
Hello Paul, On 25.10.2015 20:39, Paul Morris wrote: Introduce whiteout-style, with options of 'box and 'outline, as a grob property to be used with the whiteout grob property, and as an optional property of the whiteout markup command. Remove the whiteout-box grob property and markup command, and use whiteout-style instead. Make the box style of whiteout the default style again, as it was before issue 4418. I think this is not the best possible setting: If I want to apply whiteout-outline now, I have to use two overrides. IMO it would be easier to use if we had the two properties – whiteout [possibly whiteout-style], with options 'none, 'box, and 'outline – and whiteout-padding (a number). What do you think? Yours, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4504 whiteout-style
Greetings LilyPond devs,
I’m attaching patches for review for issue 4504 – implementing the
whiteout-style approach instead of separate whiteout and whiteout-box commands.
I tried to upload to Rietveld using Phil's new git-cl (from Federico's new
LilyDev4) but so far no luck. So I thought I’d go ahead and email it, if only
for my own sense of having reached some milestone. I’ll send a separate
message about the git-cl error.
-Paul
Includes commits:
Issue 4504/6 update changes.tely
Issue 4504/5 edits to docs
Issue 4504/4 edits to tests
Issue 4504/3 run scripts/auxiliar/update-with-convert-ly.sh
Issue 4504/2 convert-ly rule: whiteout-box --> whiteout
Issue 4504/1 whiteout-box --> whiteout-style
Introduce whiteout-style, with options of
'box and 'outline, as a grob property to be
used with the whiteout grob property, and as
an optional property of the whiteout markup
command.
Remove the whiteout-box grob property and
markup command, and use whiteout-style
instead.
Make the box style of whiteout the default
style again, as it was before issue 4418.
0001-Issue-4504-1-whiteout-box-whiteout-style.patch
Description: Binary data
0002-Issue-4504-2-convert-ly-rule-whiteout-box-whiteout.patch
Description: Binary data
0003-Issue-4504-3-run-scripts-auxiliar-update-with-conver.patch
Description: Binary data
0004-Issue-4504-4-edits-to-tests.patch
Description: Binary data
0005-Issue-4504-5-edits-to-docs.patch
Description: Binary data
0006-Issue-4504-6-update-changes.tely.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
On 5/29/15 4:00 PM, David Kastrup d...@gnu.org wrote: I also don't quite get what it never got officially adopted means in light of commits like commit cf137655b7aee9988ef536d6fa5e38d279ee73cf Author: David Kastrup d...@gnu.org Date: Mon Jun 10 17:28:51 2013 +0200 Run scripts/auxiliar/fixscm.sh scm/*.scm I'm sorry. That happened while I was not actively participating. Some years earlier I modified a scheme source-code formatter to allow those who didn't have Emacs to automatically indent their code. But it was never accepted. I stand corrected. Thanks for getting out the right information, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
Carl Sorensen c_soren...@byu.edu writes:
On 5/29/15 1:25 PM, Simon Albrecht simon.albre...@mail.de wrote:
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it very useful
and it seems to be altogether uncontroversial while warranting good
legibility.
Do we also accept these guidelines in our use of scheme?
Yes, we accept these guidelines. But outside of .scm files, we don't
enforce them.
Last time I checked, our official standard of Scheme style was whatever
Emacs creates.
Emacs does not create line breaks. It will happily indent ) as the
first non-blank line character even if no Scheme style wants them.
We have a script that gets close in creating approved style, but it
never got officially adopted.
The script actually gets whatever Emacs creates rather well which is
not surprising as scripts/auxiliar/fixscm.sh is all of
#!/bin/sh
#
# Indent and untabify source files (given by their
# filenames in the command line), according to
# LilyPond source style standards.
elisp_expression='(progn
(delete-trailing-whitespace)
(indent-region (point-min) (point-max) nil)
(untabify (point-min) (point-max))
(save-buffer))'
for f in $@; do
emacs -batch $f --eval ${elisp_expression}
done
I also don't quite get what it never got officially adopted means in
light of commits like
commit cf137655b7aee9988ef536d6fa5e38d279ee73cf
Author: David Kastrup d...@gnu.org
Date: Mon Jun 10 17:28:51 2013 +0200
Run scripts/auxiliar/fixscm.sh scm/*.scm
as part of
URL:https://code.google.com/p/lilypond/issues/detail?id=3404. Is
there something more official than applying it to all Scheme files?
the Learning Manual would be best for propagating their use, but
that doesn¹t actually introduce scheme, does it? (thinking aloudŠ)
I don't think we need to propagate their use in .ly files. I also
think we should *not* introduce Scheme in the Learning Manual.
It already is there.
URL:http://lilypond.org/doc/v2.18/Documentation/learning/advanced-tweaks-with-scheme.
Lilypond is hard enough without the scheme layer.
It's actually going to be pretty tricky to write a LilyPond source file
that does not once make use of # or $.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Scheme coding style
Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? If yes, we should consider documenting them, or rather, referencing them in our docs. This could be – in the usage manual http://lilypond.org/doc/v2.19/Documentation/usage/general-suggestions, where the corresponding Lilypond coding recommendations are found. – in the scheme tutorial http://lilypond.org/doc/v2.19/Documentation/extending/scheme-tutorial, but where? Someone who is completely new to scheme will not make much use of style instructions. – the Learning Manual would be best for propagating their use, but that doesn’t actually introduce scheme, does it? (thinking aloud…) What do you prefer? I could elaborate the change also. Yours, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
Am 29.05.2015 um 22:30 schrieb Thomas Morley: 2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de: Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? If yes, we should consider documenting them, or rather, referencing them in our docs. It's already mentioned in: CG 10.3.2 Desired file formatting http://lilypond.org/doc/v2.19/Documentation/contributor/programming-without-compiling So that’s where I got the hint… :-) Yours, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
On 5/29/15 1:25 PM, Simon Albrecht simon.albre...@mail.de wrote: Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? Yes, we accept these guidelines. But outside of .scm files, we don't enforce them. Last time I checked, our official standard of Scheme style was whatever Emacs creates. We have a script that gets close in creating approved style, but it never got officially adopted. If yes, we should consider documenting them, or rather, referencing them in our docs. This could be in the usage manual http://lilypond.org/doc/v2.19/Documentation/usage/general-suggestions, where the corresponding Lilypond coding recommendations are found. I would be happy with a reference there. in the scheme tutorial http://lilypond.org/doc/v2.19/Documentation/extending/scheme-tutorial, but where? Someone who is completely new to scheme will not make much use of style instructions. It seems like a reference in the Scheme tutorial would also be appropriate. (Perhaps a reference to the usage manual, rather than a restatement of whatever is in Usage. the Learning Manual would be best for propagating their use, but that doesn¹t actually introduce scheme, does it? (thinking aloudŠ) I don't think we need to propagate their use in .ly files. I also think we should *not* introduce Scheme in the Learning Manual. Lilypond is hard enough without the scheme layer. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de: Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? If yes, we should consider documenting them, or rather, referencing them in our docs. It's already mentioned in: CG 10.3.2 Desired file formatting http://lilypond.org/doc/v2.19/Documentation/contributor/programming-without-compiling This could be – in the usage manual http://lilypond.org/doc/v2.19/Documentation/usage/general-suggestions, where the corresponding Lilypond coding recommendations are found. – in the scheme tutorial http://lilypond.org/doc/v2.19/Documentation/extending/scheme-tutorial, but where? Someone who is completely new to scheme will not make much use of style instructions. – the Learning Manual would be best for propagating their use, but that doesn’t actually introduce scheme, does it? (thinking aloud…) What do you prefer? I could elaborate the change also. Yours, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
Am 29.05.2015 um 22:25 schrieb Carl Sorensen: On 5/29/15 1:25 PM, Simon Albrecht simon.albre...@mail.de wrote: Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? Yes, we accept these guidelines. But outside of .scm files, we don't enforce them. Last time I checked, our official standard of Scheme style was whatever Emacs creates. Which is pretty much the same as suggested in the above-linked document, except for the line breaks, which aren’t automatically inflected, are they? I don’t use Emacs. We have a script that gets close in creating approved style, but it never got officially adopted. If yes, we should consider documenting them, or rather, referencing them in our docs. This could be in the usage manual http://lilypond.org/doc/v2.19/Documentation/usage/general-suggestions, where the corresponding Lilypond coding recommendations are found. I would be happy with a reference there. in the scheme tutorial http://lilypond.org/doc/v2.19/Documentation/extending/scheme-tutorial, but where? Someone who is completely new to scheme will not make much use of style instructions. It seems like a reference in the Scheme tutorial would also be appropriate. (Perhaps a reference to the usage manual, rather than a restatement of whatever is in Usage. the Learning Manual would be best for propagating their use, but that doesn¹t actually introduce scheme, does it? (thinking aloudŠ) I don't think we need to propagate their use in .ly files. I also think we should *not* introduce Scheme in the Learning Manual. Lilypond is hard enough without the scheme layer. Of course. My reason to raise the topic is the amount of badly formatted, hard-to-read code out there. So I think we should find a prominent place where _every_ Lilypond user will come across style guidelines for both Lilypond and Scheme code. But IIRC a restructuring of the manuals overview page is in the making or planned anyway? It’s a different issue with Lilypond code, since it is much more complicated and diverse (on the surface) than Scheme code and some things will always depend on the music and on individual taste. So prior to the GLISS there won’t be a definitive solution for documenting guidelines, but as a start it’s good to have references for scheme style in Usage and Extending. Regards, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
On 5/29/15 2:30 PM, Thomas Morley thomasmorle...@gmail.com wrote: 2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de: Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? If yes, we should consider documenting them, or rather, referencing them in our docs. It's already mentioned in: CG 10.3.2 Desired file formatting http://lilypond.org/doc/v2.19/Documentation/contributor/programming-withou t-compiling I was sure we had put that reference in the CG (I'm pretty sure I found it and put it there). But when I looked in the CG I couldn't find it. A cross-reference in Usage would probably be a good idea (as would a cross-reference from the CG to the .ly file guidelines in Usage. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme coding style
I’ll come up with some text suggestions, or a patch, but not tonight. Greetings, Simon Am 29.05.2015 um 23:10 schrieb Carl Sorensen: On 5/29/15 2:30 PM, Thomas Morley thomasmorle...@gmail.com wrote: 2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de: Hello, a while ago I found this document on what appear to be very widely accepted standards for formatting scheme code: http://community.schemewiki.org/?scheme-style. I find it very useful and it seems to be altogether uncontroversial while warranting good legibility. Do we also accept these guidelines in our use of scheme? If yes, we should consider documenting them, or rather, referencing them in our docs. It's already mentioned in: CG 10.3.2 Desired file formatting http://lilypond.org/doc/v2.19/Documentation/contributor/programming-withou t-compiling I was sure we had put that reference in the CG (I'm pretty sure I found it and put it there). But when I looked in the CG I couldn't find it. A cross-reference in Usage would probably be a good idea (as would a cross-reference from the CG to the .ly file guidelines in Usage. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
Thomas Morley thomasmorle...@gmail.com writes: 2015-04-08 12:04 GMT+02:00 David Kastrup d...@gnu.org: [...] (display (eqv? -1 DOUBLE-FLAT)) - #t (display (case -1 ((DOUBLE-FLAT) --) ((FLAT) -) ((NATURAL) ) ((SHARP) +) ((DOUBLE-SHARP) ++))) - #unspecified That one's easy. As may be expected from the case-tag being in the form of an unquoted list, there is no evaluation involved. So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc as opposed to the values stored in the variables associated with the symbols. The guile manual says: — syntax: case key clause1 clause2 ... key may be any expression, the clauses must have the form ((datum1 ...) expr1 expr2 ...) and the last clause may have the form (else expr1 expr2 ...) All datums must be distinct. [...] distinct is not really meaningful ... It also says: All DATUMs must be distinct. First, KEY is evaluated. The the result of this evaluation is compared against all DATUMs using `eqv?'. When this comparison succeeds, the expression(s) following the DATUM are evaluated from left to right, returning the value of the last expression as the result of the `case' expression. So the description explicitly points out whenever something is evaluated. It does not explicitly point out that the DATUMs are *not* evaluated. Given the frequency with which people are surprised at `case' behavior (one frequent surprise is that it doesn't work for strings, for example), it might be worth pointing out explicitly what kind of things *won't* work with case. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
2015-04-08 12:04 GMT+02:00 David Kastrup d...@gnu.org: Thomas Morley thomasmorle...@gmail.com writes: 2015-04-08 11:45 GMT+02:00 Thomas Morley thomasmorle...@gmail.com: I started to rewrite chord-namings and stumbled over a problem in chord-generic-names.ly /Documentation/included/chord-names-jazz.ly with uncommented Banter-style is broken. At least since 2.12.3 The problem is in 'step-markup-plusminus' Here you see the old code commented and a possible patch inserted: (define (step-markup-plusminus pitch) (make-line-markup (list (make-simple-markup (number-string (step-nr pitch))) (make-simple-markup ;(case (step-alteration pitch) ; ((DOUBLE-FLAT) --) ; ((FLAT) -) ; ((NATURAL) ) ; ((SHARP) +) ; ((DOUBLE-SHARP) ++)) (case (step-alteration pitch) ((-1) --) ((-1/2) -) ((0) ) ((1/2) +) ((1) ++)) case uses eqv? to compare. (guile-manual) (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 (display (eqv? -1/2 FLAT), etc returns #t boiled down: (display DOUBLE-FLAT) - -1 (display (eqv? -1 DOUBLE-FLAT)) - #t (display (case -1 ((DOUBLE-FLAT) --) ((FLAT) -) ((NATURAL) ) ((SHARP) +) ((DOUBLE-SHARP) ++))) - #unspecified ?? Thus I've no clue why the old code fails. Any hint? That one's easy. As may be expected from the case-tag being in the form of an unquoted list, there is no evaluation involved. So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc as opposed to the values stored in the variables associated with the symbols. The guile manual says: — syntax: case key clause1 clause2 ... key may be any expression, the clauses must have the form ((datum1 ...) expr1 expr2 ...) and the last clause may have the form (else expr1 expr2 ...) All datums must be distinct. [...] distinct is not really meaningful ... It would probably make more sense to define an association list for this lookup, or convert into a cond. -- David Kastrup Thanks for the hint. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
2015-04-08 11:45 GMT+02:00 Thomas Morley thomasmorle...@gmail.com: Hi. I started to rewrite chord-namings and stumbled over a problem in chord-generic-names.ly /Documentation/included/chord-names-jazz.ly with uncommented Banter-style is broken. At least since 2.12.3 The problem is in 'step-markup-plusminus' Here you see the old code commented and a possible patch inserted: (define (step-markup-plusminus pitch) (make-line-markup (list (make-simple-markup (number-string (step-nr pitch))) (make-simple-markup ;(case (step-alteration pitch) ; ((DOUBLE-FLAT) --) ; ((FLAT) -) ; ((NATURAL) ) ; ((SHARP) +) ; ((DOUBLE-SHARP) ++)) (case (step-alteration pitch) ((-1) --) ((-1/2) -) ((0) ) ((1/2) +) ((1) ++)) case uses eqv? to compare. (guile-manual) (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 (display (eqv? -1/2 FLAT), etc returns #t boiled down: (display DOUBLE-FLAT) - -1 (display (eqv? -1 DOUBLE-FLAT)) - #t (display (case -1 ((DOUBLE-FLAT) --) ((FLAT) -) ((NATURAL) ) ((SHARP) +) ((DOUBLE-SHARP) ++))) - #unspecified ?? Thus I've no clue why the old code fails. Any hint? Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
Thomas Morley thomasmorle...@gmail.com writes: 2015-04-08 11:45 GMT+02:00 Thomas Morley thomasmorle...@gmail.com: I started to rewrite chord-namings and stumbled over a problem in chord-generic-names.ly /Documentation/included/chord-names-jazz.ly with uncommented Banter-style is broken. At least since 2.12.3 The problem is in 'step-markup-plusminus' Here you see the old code commented and a possible patch inserted: (define (step-markup-plusminus pitch) (make-line-markup (list (make-simple-markup (number-string (step-nr pitch))) (make-simple-markup ;(case (step-alteration pitch) ; ((DOUBLE-FLAT) --) ; ((FLAT) -) ; ((NATURAL) ) ; ((SHARP) +) ; ((DOUBLE-SHARP) ++)) (case (step-alteration pitch) ((-1) --) ((-1/2) -) ((0) ) ((1/2) +) ((1) ++)) case uses eqv? to compare. (guile-manual) (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 (display (eqv? -1/2 FLAT), etc returns #t boiled down: (display DOUBLE-FLAT) - -1 (display (eqv? -1 DOUBLE-FLAT)) - #t (display (case -1 ((DOUBLE-FLAT) --) ((FLAT) -) ((NATURAL) ) ((SHARP) +) ((DOUBLE-SHARP) ++))) - #unspecified ?? Thus I've no clue why the old code fails. Any hint? That one's easy. As may be expected from the case-tag being in the form of an unquoted list, there is no evaluation involved. So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc as opposed to the values stored in the variables associated with the symbols. It would probably make more sense to define an association list for this lookup, or convert into a cond. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
banter-style from chord-names-jazz.ly broken, 'case'-problem
Hi. I started to rewrite chord-namings and stumbled over a problem in chord-generic-names.ly /Documentation/included/chord-names-jazz.ly with uncommented Banter-style is broken. At least since 2.12.3 The problem is in 'step-markup-plusminus' Here you see the old code commented and a possible patch inserted: (define (step-markup-plusminus pitch) (make-line-markup (list (make-simple-markup (number-string (step-nr pitch))) (make-simple-markup ;(case (step-alteration pitch) ; ((DOUBLE-FLAT) --) ; ((FLAT) -) ; ((NATURAL) ) ; ((SHARP) +) ; ((DOUBLE-SHARP) ++)) (case (step-alteration pitch) ((-1) --) ((-1/2) -) ((0) ) ((1/2) +) ((1) ++)) case uses eqv? to compare. (guile-manual) (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 (display (eqv? -1/2 FLAT), etc returns #t Thus I've no clue why the old code fails. Any hint? Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Add rest style 'z for mirrored-z quarter rests. (issue 200300043 by nine.fierce.ball...@gmail.com)
Reviewers: ,
Description:
Add rest style 'z for mirrored-z quarter rests.
The glyph was added in e3c51326b986bb56f068f70d9c5e999c5fcfc36d.
Please review this at https://codereview.appspot.com/200300043/
Affected files (+2, -3 lines):
M lily/rest.cc
Index: lily/rest.cc
diff --git a/lily/rest.cc b/lily/rest.cc
index
9e5dc046e14821fdced4de7ee10707c02f08b956..4f05764296c4faf61df85f892c9327293ca4d2fb
100644
--- a/lily/rest.cc
+++ b/lily/rest.cc
@@ -199,11 +199,10 @@ Rest::glyph_name (Grob *me, int durlog, const string
style, bool try_ledgers,
actual_style = ;
}
- if ((style == classical) (durlog != 2))
+ if (((style == classical) || (style == z)) (durlog != 2))
{
/*
-classical style: revert back to default style for any rest other
-than quarter rest
+these styles differ from the default in quarter rests only
*/
actual_style = ;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4186: Remove the single-C time signature style (issue 186630043 by nine.fierce.ball...@gmail.com)
Reviewers: ,
Description:
Issue 4186: Remove the single-C time signature style
Remove the single-C time signature style that was added in commit
40b0982cb4f00317c3d50c7f1d4e26fde912f3cd to address Issue 3286.
The later commit 145389636e81237d560aba4d04abcb89fa60cd9c allows
the user to define new time signature styles, which is a more
flexible solution.
Please review this at https://codereview.appspot.com/186630043/
Affected files (+0, -29 lines):
D input/regression/time-signature-single-c.ly
M scm/time-signature-settings.scm
Index: input/regression/time-signature-single-c.ly
diff --git a/input/regression/time-signature-single-c.ly
b/input/regression/time-signature-single-c.ly
deleted file mode 100644
index
5e115e4070e6f2e11dece52717e6c1b9ca4c4867..
--- a/input/regression/time-signature-single-c.ly
+++ /dev/null
@@ -1,20 +0,0 @@
-\version 2.19.16
-
-\header {
- texidoc = The single-C time signature style prints a C for any time
signature with 4 in the numerator and prints a cut-C for any time signature
with 2 in the numerator.
-}
-
-\layout { indent = 0 }
-
-\new Staff {
- \relative f' {
-\override Staff.TimeSignature.style = #'single-C
-\time 1/2 f2^1/2
-\time 2/2 f2^2/2 f
-\time 2/1 f1^2/1 f
-\time 3/4 f4^3/4 f f
-\time 4/4 f4^4/4 f f f
-\time 4/2 f2^4/2 f f f
-\time 4/1 f1^4/1 f f f
- }
-}
Index: scm/time-signature-settings.scm
diff --git a/scm/time-signature-settings.scm
b/scm/time-signature-settings.scm
index
bee620eb9fc7e1fe20adbf0a5e948d5bdc5aeb6a..f55c76c0b687e2d28c742c77508278b16d5253d0
100644
--- a/scm/time-signature-settings.scm
+++ b/scm/time-signature-settings.scm
@@ -394,15 +394,6 @@ a fresh copy of the list-head is made.
(add-simple-time-signature-style 'C make-c-time-signature-markup)
(add-simple-time-signature-style 'default make-c-time-signature-markup)
-(define-public (make-single-c-time-signature-markup fraction)
- Make markup for the `single-C' time signature style.
- (let ((n (car fraction)))
-(if (or (= n 2) (= n 4)) ; numerator only
-(make-glyph-time-signature-markup 'C (cons n n))
-(make-compound-meter-markup n
-
-(add-simple-time-signature-style 'single-C
make-single-c-time-signature-markup)
-
;;;
;;; Measure length calculation of (possibly complex) compound time
signatures
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Hans Aberg haber...@telia.com writes: On 6 Nov 2014, at 21:42, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: You wanted \compoundMeter to be numeric, so I gave a possible algorithmic structure, reiterating discussions of the past on LilyPond lists. Once one has that, the time signature derives from that, the question you are asking about. I guess I am just too far below the intelligence of your target audience to understand even a single sentence of what you are saying. It seems like we need an interpreter between mathematician and engineer. Is there a physicist around? Carl Sorensen worked on this stuff back in 2012, and implemented \set beatStructure = #'(4 3 4) Before one had to write something like \set beatGrouping = #'(4 3 4) #(override-auto-beam-setting '(end * * 11 16) 4 16) #(override-auto-beam-setting '(end * * 11 16) 7 16) The new beatStructure is simpler, but it fails capturing the hierarchy of subaccents. So this is the question one ends up with when trying to implement automated forms of compound meter time signatures. The question was when to use 4/4 and when to use C in a time signature. This is not related to the accent structure of the music as much as it is to the century of its origin and the conventions used in its respective music field. Math does not provide answers to the particular distinction this thread is about since the math behind C and 4/4 is quite the same. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 7 Nov 2014, at 10:08, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: On 6 Nov 2014, at 21:42, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: You wanted \compoundMeter to be numeric, so I gave a possible algorithmic structure, reiterating discussions of the past on LilyPond lists. Once one has that, the time signature derives from that, the question you are asking about. I guess I am just too far below the intelligence of your target audience to understand even a single sentence of what you are saying. It seems like we need an interpreter between mathematician and engineer. Is there a physicist around? Carl Sorensen worked on this stuff back in 2012, and implemented \set beatStructure = #'(4 3 4) Before one had to write something like \set beatGrouping = #'(4 3 4) #(override-auto-beam-setting '(end * * 11 16) 4 16) #(override-auto-beam-setting '(end * * 11 16) 7 16) The new beatStructure is simpler, but it fails capturing the hierarchy of subaccents. So this is the question one ends up with when trying to implement automated forms of compound meter time signatures. The question was when to use 4/4 and when to use C in a time signature. This is not related to the accent structure of the music as much as it is to the century of its origin and the conventions used in its respective music field. Math does not provide answers to the particular distinction this thread is about since the math behind C and 4/4 is quite the same. The “+” notation I think is quite recent, possibly invented by Béla Bartók and Vinko Žganec for the description of Balkan meters. So the use of anything else than numerals is a modernity. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 7 Nov 2014, at 00:37, Dan Eble d...@faithful.be wrote: On Nov 6, 2014, at 08:46 , David Kastrup d...@gnu.org wrote: I lean towards not consulting the style here. \compoundMeter to me feels like it should just be numeric. Of course, to allow for full laziness, it might make sense to interpret \compoundMeter #'(4 . 4) properly as 4/4 then because one can then cheat one's way around writing \compoundMeter 4/4 for a numeric time signature. My gut feeling is that formatting a compound meter should encompass formatting a simple meter, and I’ve been trying to understand where to draw the line. If both \compoundMeter #(2 3 8) and \compoundMeter 4/4 could be made to work, why bother keeping both \compoundMeter and \time? Why not just let \time do all the work? It is normal to write a different time signature than the meter. For example, \compoundMeter #(3 2 2 8) might have time signature \time 7/8. I write for example \time 11/16 \set beatStructure = #'(4 3 4) It would nice to have \compoundMeter #((2 2) 3 (2 2) 16), indicating subbeaming (2 2) for the 4s, while still writing \time 11/16 (typical for notating a kopanitsa). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Hans Aberg haber...@telia.com writes: On 7 Nov 2014, at 10:08, David Kastrup d...@gnu.org wrote: The question was when to use 4/4 and when to use C in a time signature. This is not related to the accent structure of the music as much as it is to the century of its origin and the conventions used in its respective music field. Math does not provide answers to the particular distinction this thread is about since the math behind C and 4/4 is quite the same. The “+” notation I think is quite recent, possibly invented by Béla Bartók and Vinko Žganec for the description of Balkan meters. So the use of anything else than numerals is a modernity. We are talking about the use of C for 4/4. I doubt many people consider that a modernity. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 7 Nov 2014, at 11:38, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: On 7 Nov 2014, at 10:08, David Kastrup d...@gnu.org wrote: The question was when to use 4/4 and when to use C in a time signature. This is not related to the accent structure of the music as much as it is to the century of its origin and the conventions used in its respective music field. Math does not provide answers to the particular distinction this thread is about since the math behind C and 4/4 is quite the same. The “+” notation I think is quite recent, possibly invented by Béla Bartók and Vinko Žganec for the description of Balkan meters. So the use of anything else than numerals is a modernity. We are talking about the use of C for 4/4. I doubt many people consider that a modernity. In the compound time signatures “+” notation, that would be. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Hans Aberg haber...@telia.com writes: On 7 Nov 2014, at 11:38, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: On 7 Nov 2014, at 10:08, David Kastrup d...@gnu.org wrote: The question was when to use 4/4 and when to use C in a time signature. This is not related to the accent structure of the music as much as it is to the century of its origin and the conventions used in its respective music field. Math does not provide answers to the particular distinction this thread is about since the math behind C and 4/4 is quite the same. The “+” notation I think is quite recent, possibly invented by Béla Bartók and Vinko Žganec for the description of Balkan meters. So the use of anything else than numerals is a modernity. We are talking about the use of C for 4/4. I doubt many people consider that a modernity. In the compound time signatures “+” notation, that would be. I quote what the current discussion is about (cf URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/59535): One more case: \compoundMeter #’(n d). The current implementation prints this as a fraction (n/d), but I plan to change it to honor the style unless somebody objects. There is no + involved in that topic at all. You quote this and my reply to it in URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/59538 before adding a complex treatise not at all related to that particular problem. It takes considerable work going through those mathematical elaborations, and if one finds at the end that it is not even relevant to the question, that's mostly a wasted effort, likely affecting the willingness of the reader to read through further similar postings. The end result then is that everybody's effort, including your own, is wasted. Making sure that a reply applies to the question before investing a lot of work saves everyone disappointment. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On Nov 7, 2014, at 01:46 , David Kastrup d...@gnu.org wrote: Dan Eble d...@faithful.be writes: If both \compoundMeter #(2 3 8) and \compoundMeter 4/4 could be made to work, why bother keeping both \compoundMeter and \time? Why not just let \time do all the work? Because of \time #'(2 3 2) #'(8 8) Is it \time (2 + 3)/2 followed by #'(8 8) or is it \time 8/8 with a beat structure of 2+3+2 ? Shame on me for not reading the code for \time; but if one were serious about creating a more uniform interface, one could write a conversion rule rather than sticking with the old syntax exactly, right? (Hans just said he uses a separate command to set the beat structure anyway.) It doesn’t matter right now, though. I’ll keep \compoundMeter numeric. Thanks for your help. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 7 Nov 2014, at 13:45, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: On 7 Nov 2014, at 11:38, David Kastrup d...@gnu.org wrote: Hans Aberg haber...@telia.com writes: On 7 Nov 2014, at 10:08, David Kastrup d...@gnu.org wrote: The question was when to use 4/4 and when to use C in a time signature. This is not related to the accent structure of the music as much as it is to the century of its origin and the conventions used in its respective music field. Math does not provide answers to the particular distinction this thread is about since the math behind C and 4/4 is quite the same. The “+” notation I think is quite recent, possibly invented by Béla Bartók and Vinko Žganec for the description of Balkan meters. So the use of anything else than numerals is a modernity. We are talking about the use of C for 4/4. I doubt many people consider that a modernity. In the compound time signatures “+” notation, that would be. I quote what the current discussion is about (cf URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/59535): One more case: \compoundMeter #’(n d). The current implementation prints this as a fraction (n/d), but I plan to change it to honor the style unless somebody objects. From what I can see in some books, one normally writes 4/4, but if one so likes, one may write C instead. Particularly popular music may refer the latter, since this meter is very common. There is no + involved in that topic at all. You quote this and my reply to it in URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/59538 before adding a complex treatise not at all related to that particular problem. I believe that the original intent of \compundMeter was to eventually capture what I described. It takes considerable work going through those mathematical elaborations, and if one finds at the end that it is not even relevant to the question, that's mostly a wasted effort, likely affecting the willingness of the reader to read through further similar postings. The end result then is that everybody's effort, including your own, is wasted. Making sure that a reply applies to the question before investing a lot of work saves everyone disappointment. Now you are intent of taking it in another direction. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 7 Nov 2014, at 13:55, Dan Eble d...@faithful.be wrote: On Nov 7, 2014, at 01:46 , David Kastrup d...@gnu.org wrote: Dan Eble d...@faithful.be writes: If both \compoundMeter #(2 3 8) and \compoundMeter 4/4 could be made to work, why bother keeping both \compoundMeter and \time? Why not just let \time do all the work? Because of \time #'(2 3 2) #'(8 8) Is it \time (2 + 3)/2 followed by #'(8 8) or is it \time 8/8 with a beat structure of 2+3+2 ? Shame on me for not reading the code for \time; but if one were serious about creating a more uniform interface, one could write a conversion rule rather than sticking with the old syntax exactly, right? (Hans just said he uses a separate command to set the beat structure anyway.) The way I remember it, \compoundMeter should have been able to capture the kind of subaccent structures I described and display it in the subbeaming, but it proved difficult to implement. The question is not difficult to understand conceptually, but hard to pin down algorithmically. Since \compoundMeter does not capture this kind of subbeaming, I decided to use '\set beatStructure’ instead. In oriental music, one normally just sums it up as in \time, and the subbeaming practises vary, even in the same score. So from the practical point of view, it is not a big deal, but it would still be nice to be able to typeset it. It doesn’t matter right now, though. I’ll keep \compoundMeter numeric. Thanks for your help. I think, too this is best: the books I have looked into speak about the meter 4/4 numerically, but note that one can write C, too, as an option. The latter is though common in some quarters. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Dan Eble d...@faithful.be writes:
On Nov 7, 2014, at 01:46 , David Kastrup d...@gnu.org wrote:
Dan Eble d...@faithful.be writes:
If both \compoundMeter #(2 3 8) and \compoundMeter 4/4 could be made
to work, why bother keeping both \compoundMeter and \time? Why not
just let \time do all the work?
Because of
\time #'(2 3 2) #'(8 8)
Is it \time (2 + 3)/2 followed by #'(8 8) or is it \time 8/8 with a beat
structure of 2+3+2 ?
Shame on me for not reading the code for \time; but if one were
serious about creating a more uniform interface, one could write a
conversion rule rather than sticking with the old syntax exactly,
right?
Right. I don't currently see an approach that would provide a
significant amount of increase in usability/convenience making it worth
the trouble. If optional arguments and stuff would have been available
at the time \compoundMeter was designed, it is quite imaginable that its
syntax would have been folded into \time in some manner.
\compoundMeter was added in version 2.13.47 as
commit a2eb9d0a93abab905d4d88c33921ee1b8b8cb67c
Author: Reinhold Kainhofer reinh...@kainhofer.com
Date: Fri Jan 14 21:09:57 2011 +0100
Implement compound time signatures
\compoundMeter is a replacement for \time, allowing complex time
signatures (like (1+3)/8 or 3/8+(2+5)/16, etc.).
The argument to the music function is a list of lists, each
describing one fraction in the signature.
and optional function arguments came quite later.
\time was redefined as a music function in version 2.15.17
commit 5ecf990d2bf528e34d73a9d9fcb2e12c31ca4470
Author: David Kastrup d...@gnu.org
Date: Sat Oct 29 23:13:31 2011 +0200
parser.yy et al: make \time and \times musicfunctions.
but indeed the beat grouping argument was only added in version 2.15.19
commit a512132fed73a94068b91fb0bab473319e477b6e
Author: David Kastrup d...@gnu.org
Date: Wed Nov 9 11:37:39 2011 +0100
Fold set-time-signature into \time
So I am responsible for that historic decision that was getting us rid
of $(set-time-signature ...). I probably did not even have
\compoundMeter on my radar at the time.
But at the current point of time, I don't really see a convincing way of
unifying both that would provide users with enough net benefit to make
it worth the trouble.
Maybe an optional context mod?
\time \with { beatGrouping = #'(2 3 2)
beamExceptions = \beamExceptions { 4[ 4 4] 4[ 4 4 4 4] }
} 8/8
Or one scheme function that gets a rhythmic expression along the lines
of \beamExceptions but derives _all_ of the Timing context mod from it?
(Hans just said he uses a separate command to set the beat structure
anyway.)
That would likely still work as
\time \with { \hans-s-personal-command ... } 3/4
then since context mods can contain arbitrary music commands these days.
It doesn’t matter right now, though. I’ll keep \compoundMeter
numeric. Thanks for your help.
As long as we have separate commands, that makes the most sense to me.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 7 Nov 2014, at 14:39, David Kastrup d...@gnu.org wrote:
Dan Eble d...@faithful.be writes:
On Nov 7, 2014, at 01:46 , David Kastrup d...@gnu.org wrote:
Dan Eble d...@faithful.be writes:
If both \compoundMeter #(2 3 8) and \compoundMeter 4/4 could be made
to work, why bother keeping both \compoundMeter and \time? Why not
just let \time do all the work?
Because of
\time #'(2 3 2) #'(8 8)
Is it \time (2 + 3)/2 followed by #'(8 8) or is it \time 8/8 with a beat
structure of 2+3+2 ?
Shame on me for not reading the code for \time; but if one were
serious about creating a more uniform interface, one could write a
conversion rule rather than sticking with the old syntax exactly,
right?
Right. I don't currently see an approach that would provide a
significant amount of increase in usability/convenience making it worth
the trouble. If optional arguments and stuff would have been available
at the time \compoundMeter was designed, it is quite imaginable that its
syntax would have been folded into \time in some manner.
\compoundMeter was added in version 2.13.47 as
commit a2eb9d0a93abab905d4d88c33921ee1b8b8cb67c
Author: Reinhold Kainhofer reinh...@kainhofer.com
Date: Fri Jan 14 21:09:57 2011 +0100
Implement compound time signatures
\compoundMeter is a replacement for \time, allowing complex time
signatures (like (1+3)/8 or 3/8+(2+5)/16, etc.).
The argument to the music function is a list of lists, each
describing one fraction in the signature.
and optional function arguments came quite later.
\time was redefined as a music function in version 2.15.17
commit 5ecf990d2bf528e34d73a9d9fcb2e12c31ca4470
Author: David Kastrup d...@gnu.org
Date: Sat Oct 29 23:13:31 2011 +0200
parser.yy et al: make \time and \times musicfunctions.
but indeed the beat grouping argument was only added in version 2.15.19
commit a512132fed73a94068b91fb0bab473319e477b6e
Author: David Kastrup d...@gnu.org
Date: Wed Nov 9 11:37:39 2011 +0100
Fold set-time-signature into \time
So I am responsible for that historic decision that was getting us rid
of $(set-time-signature ...). I probably did not even have
\compoundMeter on my radar at the time.
But at the current point of time, I don't really see a convincing way of
unifying both that would provide users with enough net benefit to make
it worth the trouble.
Maybe an optional context mod?
\time \with { beatGrouping = #'(2 3 2)
beamExceptions = \beamExceptions { 4[ 4 4] 4[ 4 4 4 4] }
} 8/8
Or one scheme function that gets a rhythmic expression along the lines
of \beamExceptions but derives _all_ of the Timing context mod from it?
(Hans just said he uses a separate command to set the beat structure
anyway.)
That would likely still work as
\time \with { \hans-s-personal-command ... } 3/4
then since context mods can contain arbitrary music commands these days.
I just write
\time 11/16
\set beatStructure = #'(4 3 4)
Here, the 4s have 2+2 subaccents, which might be reflected in the subbeaming.
In pseudocode, this might be
\compoundMeter #’(((2 2) 3 (2 2) 16))
When writing a time signature, one combines som subparts. Denote that with
brackets [...]. Then what I write is
\compoundMeter #’(([(2 2) 3 (2 2)] 16))
Sometimes one see the use of a +. For example,
\compoundMeter #’(([(3 2 3)] [(2 3)] 16))
which would be displayed as 8/16+5/16, contrasting against
\compoundMeter #’(([(3 (2 2) 2 3)] 16))
which is 13/16.
It is possible to combine these, like the Sedi Donka
\compoundMeter #’([(3 2 2)] [(3 2 2)] [((2 2) 3 (2 2)] 16))
which is a 7/16+7/16+11/16, though it may also be written
\compoundMeter #’([(3 2 2) (3 2 2) ((2 2) 3 (2 2)] 16))
a 25/16.
Here, one may differ on the the display of these groups of 7 and 11: they are
more like a sequence of different measures, so different styles might be \bar
;, bar !, or \bar |.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Am 04.11.2014 um 07:48 schrieb David Kastrup: Dan Eble d...@faithful.be writes: If the simple-fraction components of a compound time signature respected the time signature style, would that qualify as useful or as undesirable? For example, 2 + 32 + 3 4 - + C vs.- + - 44 4 Undesirable in my book. It seems everyone agrees for once. :) One more case: \compoundMeter #’(n d). The current implementation prints this as a fraction (n/d), but I plan to change it to honor the style unless somebody objects. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Dan Eble d...@faithful.be writes: Am 04.11.2014 um 07:48 schrieb David Kastrup: Dan Eble d...@faithful.be writes: If the simple-fraction components of a compound time signature respected the time signature style, would that qualify as useful or as undesirable? For example, 2 + 32 + 3 4 - + C vs.- + - 44 4 Undesirable in my book. It seems everyone agrees for once. :) One more case: \compoundMeter #’(n d). The current implementation prints this as a fraction (n/d), but I plan to change it to honor the style unless somebody objects. I lean towards not consulting the style here. \compoundMeter to me feels like it should just be numeric. Of course, to allow for full laziness, it might make sense to interpret \compoundMeter #'(4 . 4) properly as 4/4 then because one can then cheat one's way around writing \compoundMeter 4/4 for a numeric time signature. But that's tangential to the question at best. I think that \compoundMeter should employ the same way of creating its markup for all argument kinds. At least by default. Since I cannot offer a better rationale than gut feeling for it, this likely calls for getting a vote. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
On 6 Nov 2014, at 14:46, David Kastrup d...@gnu.org wrote: Dan Eble d...@faithful.be writes: Am 04.11.2014 um 07:48 schrieb David Kastrup: Dan Eble d...@faithful.be writes: If the simple-fraction components of a compound time signature respected the time signature style, would that qualify as useful or as undesirable? For example, 2 + 32 + 3 4 - + C vs.- + - 44 4 Undesirable in my book. It seems everyone agrees for once. :) One more case: \compoundMeter #’(n d). The current implementation prints this as a fraction (n/d), but I plan to change it to honor the style unless somebody objects. I lean towards not consulting the style here. \compoundMeter to me feels like it should just be numeric. A compound meter can have the same iterated subaccent structure as otherwise indicated in the staff by beaming, only that it occurs metrically. In practise, though, one prefers exceptions. So one idea to implement it would be to have a sequence of patterns recognizing metric rhythms, each assigning a formal compound metric structures, the latter is what is used to typeset the beaming structure. A brief description of this compound metric structure: The smallest structure is in one”: only an accent at the beginning. Write that as I2, I3, I4, ... (For example, Beethoven’s 5th symphony is normally played in one, though written in 2.) Then one can combine these using + and “(...): a_1 + a_2 + … + a_k means that there is a stronger accent in the beginning of a_1 than on the other a_i, but otherwise, the relative strength of the accents beginning the other a_i is unspecified. And a_1 + ... + (b_1 + ... + b_l) + ... + a_k (b’s in i-th position) means that b_1 + ... + b_l starts with an accent as in b_1 = a_i above, and the other accents b_j, j 1, are subordinate to that, as above. When one writes 3, that is ambiguous: at lower speeds, it would be 1+1+1, and at higher speeds I3. 4 can be 1+1+1+1 or (1+1)+(1+1). Tuplets p:q start a new “(...)” structure. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compound time signature style
Hans Aberg haber...@telia.com writes: On 6 Nov 2014, at 14:46, David Kastrup d...@gnu.org wrote: Dan Eble d...@faithful.be writes: Am 04.11.2014 um 07:48 schrieb David Kastrup: Dan Eble d...@faithful.be writes: If the simple-fraction components of a compound time signature respected the time signature style, would that qualify as useful or as undesirable? For example, 2 + 32 + 3 4 - + C vs.- + - 44 4 Undesirable in my book. It seems everyone agrees for once. :) One more case: \compoundMeter #’(n d). The current implementation prints this as a fraction (n/d), but I plan to change it to honor the style unless somebody objects. I lean towards not consulting the style here. \compoundMeter to me feels like it should just be numeric. A compound meter can have the same iterated subaccent structure as otherwise indicated in the staff by beaming, only that it occurs metrically. In practise, though, one prefers exceptions. So one idea to implement it would be to have a sequence of patterns recognizing metric rhythms, each assigning a formal compound metric structures, the latter is what is used to typeset the beaming structure. A brief description of this compound metric structure: The smallest structure is in one”: only an accent at the beginning. Write that as I2, I3, I4, ... (For example, Beethoven’s 5th symphony is normally played in one, though written in 2.) Then one can combine these using + and “(...): a_1 + a_2 + … + a_k means that there is a stronger accent in the beginning of a_1 than on Hans, I happen to be an engineer. Disciplines like Theoretical Electrical Engineering work somewhat like telling a mathematician what you are currently working with, have him explode into generalized sets of equations, work through the notation, reconvert into engineer math and figure out how it may be applied to your actual problem. This feels somewhat similar. In this particular case, I fail to reconnect the dots, however. I just don't see how your math is supposed to relate to figuring out whether to typeset C or 4/4 when writing \compoundMeter #'(4 4). Can you spell out what question your reply is supposed to be an answer to? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
