Re: musicxml2ly: import chordnames attached to empty measures or whole rests?
Much appreciated! On Wed, Oct 13, 2021 at 12:41 PM Jean Abou Samra wrote: > Le 11/10/2021 à 22:37, leonardlthomp...@gmail.com a écrit : > > Hello! > > It seems that musicxml2ly won't create a chordname if the corresponding > > harmony element in the musicxml file is attached to an empty whole rest > > measure. Works just fine with a chord symbol attached to a single quarter > > rest, for example, even in a measure of only quarter rests. Would a > simple > > modification to the musicxml2ly python file fix this? I've modified other > > things successfully in that file so I don't mind trying on my own if > anyone > > has a hint. Attached are the two different cases I've mentioned. > > Thanks very much. > > Leonard > > Thanks for your report. This is now > > https://gitlab.com/lilypond/lilypond/-/issues/6195 > > Note that xml2ly (living at https://github.com/jacques-menu/musicformats) > converts your example just fine. > > Best regards, > Jean >
Re: musicxml2ly: import chordnames attached to empty measures or whole rests?
Le 11/10/2021 à 22:37, leonardlthomp...@gmail.com a écrit : Hello! It seems that musicxml2ly won't create a chordname if the corresponding harmony element in the musicxml file is attached to an empty whole rest measure. Works just fine with a chord symbol attached to a single quarter rest, for example, even in a measure of only quarter rests. Would a simple modification to the musicxml2ly python file fix this? I've modified other things successfully in that file so I don't mind trying on my own if anyone has a hint. Attached are the two different cases I've mentioned. Thanks very much. Leonard Thanks for your report. This is now https://gitlab.com/lilypond/lilypond/-/issues/6195 Note that xml2ly (living at https://github.com/jacques-menu/musicformats) converts your example just fine. Best regards, Jean
musicxml2ly: import chordnames attached to empty measures or whole rests?
Hello! It seems that musicxml2ly won't create a chordname if the corresponding harmony element in the musicxml file is attached to an empty whole rest measure. Works just fine with a chord symbol attached to a single quarter rest, for example, even in a measure of only quarter rests. Would a simple modification to the musicxml2ly python file fix this? I've modified other things successfully in that file so I don't mind trying on my own if anyone has a hint. Attached are the two different cases I've mentioned. Thanks very much. Leonard chordname attached to quarter rest is fine.musicxml Description: Binary data fails to import chordname attached to empty measure.musicxml Description: Binary data
Re: How to adjust space between ChordNames and Staff?
On 14 January 2017 at 21:12, Trevor Daniels wrote:
>
> Thomas Morley wrote Friday, January 13, 2017 9:05 PM
>
>
> > 2017-01-13 17:05 GMT+01:00 Trevor Daniels :
> >>
> >> Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM
> >>
> >>> On 13 January 2017 at 01:20, Trevor Daniels
> wrote:
> >>>
> >>>> Interesting. Does that mean the ChordNames and Lyrics contexts behave
> >>>> differently wrt the vertical spacing controls when these are placed
> within a
> >>>> \with { } block, since Lyrics can be spaced out that way?
> >>>>
> >>>> If so, is this intended for some reason ... or a bug?
> >>>
> >>> Thanks Harm. That did the trick. However, I concur with Trevor about
> the
> >>> confusing difference compared to Lyrics. I assumed that they'd work the
> >>> same way so I did not occur to me to try the \layout block. If it /is/
> an
> >>> intended behaviour, there should probably be a note that the settings
> >>> won't work with \with { }.
> >>
> >> Exactly, but I think we need to understand exactly what the problem is
> before
> >> we can decide (a) whether this _is_ a bug and if so (b) whether it is a
> coding or
> >> a documentation problem.
> >>
> >> Copying to bug list so this doesn't get forgotten.
> >
> > No bug.
> > It's \chords vs \chordmode.
> >
> > \chords (as a shortcut) already created a ChordNames-context, see:
> >
> > chordStuff = \chords { c1 d:m }
> > \void \displayLilyMusic \chordStuff
> >
> > So if you really want to use \chords you need to put overrides, etc
> > into \layout or use
> > \chords \with { ... }
> > at least with newer devel-versions.
> >
> > If you use \chordmode you can do
> > \new ChordNames \with { ... } \chordmode
>
> Excellent explanation! Many thanks!
>
> So no bug, but we should add a paragraph somewhere in the NR to make this
> clear. I'll start on that in a day or two.
>
> Trevor
>
>
Thanks for the explanation. And thanks to Trevor for the NR part.
I had to move from \chords to \chordmode anyway because concatenating two
set of chords did not work ( e.g. \new ChordNames { \chordsPartI
\chordsPartII } ). The second part was thrown under the whole system.
However, at that point I had already moved the padding in the \layout block.
The \chords mechanism might also explain why combining did not work—a
second ChordNames was created and ...
-Risto
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to adjust space between ChordNames and Staff?
Thomas Morley wrote Friday, January 13, 2017 9:05 PM
> 2017-01-13 17:05 GMT+01:00 Trevor Daniels :
>>
>> Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM
>>
>>> On 13 January 2017 at 01:20, Trevor Daniels wrote:
>>>
>>>> Interesting. Does that mean the ChordNames and Lyrics contexts behave
>>>> differently wrt the vertical spacing controls when these are placed within
>>>> a
>>>> \with { } block, since Lyrics can be spaced out that way?
>>>>
>>>> If so, is this intended for some reason ... or a bug?
>>>
>>> Thanks Harm. That did the trick. However, I concur with Trevor about the
>>> confusing difference compared to Lyrics. I assumed that they'd work the
>>> same way so I did not occur to me to try the \layout block. If it /is/ an
>>> intended behaviour, there should probably be a note that the settings
>>> won't work with \with { }.
>>
>> Exactly, but I think we need to understand exactly what the problem is before
>> we can decide (a) whether this _is_ a bug and if so (b) whether it is a
>> coding or
>> a documentation problem.
>>
>> Copying to bug list so this doesn't get forgotten.
>
> No bug.
> It's \chords vs \chordmode.
>
> \chords (as a shortcut) already created a ChordNames-context, see:
>
> chordStuff = \chords { c1 d:m }
> \void \displayLilyMusic \chordStuff
>
> So if you really want to use \chords you need to put overrides, etc
> into \layout or use
> \chords \with { ... }
> at least with newer devel-versions.
>
> If you use \chordmode you can do
> \new ChordNames \with { ... } \chordmode
Excellent explanation! Many thanks!
So no bug, but we should add a paragraph somewhere in the NR to make this
clear. I'll start on that in a day or two.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to adjust space between ChordNames and Staff?
2017-01-13 17:05 GMT+01:00 Trevor Daniels :
>
> Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM
>
>> On 13 January 2017 at 01:20, Trevor Daniels wrote:
>>
>>> Thomas Morley wrote Thursday, January 12, 2017 10:26 PM
>>>
>>>> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi :
>>>>
>>>>> The spacing between ChordNames and Staff seems a bit tight by default.
>>>>> I've
>>>>> been trying to adjust it but I haven't figured out the right magic words
>>>>
>>>> Do it in \layout
>>>>
>>>> chordStuff = \chords { c1 d:m }
>>>> melody = \relative c'' { c4 c c c | d d d d }
>>>> \score {
>>>> <<
>>>>\new ChordNames { \chordStuff }
>>>>\new Staff { \melody }
>>>> >>
>>>> \layout {
>>>> \context {
>>>>\ChordNames
>>>>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding =
>>>> #10
>>>> }
>>>> }
>>>> }
>>>
>>> Interesting. Does that mean the ChordNames and Lyrics contexts behave
>>> differently wrt the vertical spacing controls when these are placed within a
>>> \with { } block, since Lyrics can be spaced out that way?
>>>
>>> If so, is this intended for some reason ... or a bug?
>>
>> Thanks Harm. That did the trick. However, I concur with Trevor about the
>> confusing difference compared to Lyrics. I assumed that they'd work the
>> same way so I did not occur to me to try the \layout block. If it /is/ an
>> intended behaviour, there should probably be a note that the settings
>> won't work with \with { }.
>
> Exactly, but I think we need to understand exactly what the problem is before
> we can decide (a) whether this _is_ a bug and if so (b) whether it is a
> coding or
> a documentation problem.
>
> Copying to bug list so this doesn't get forgotten.
>
> Trevor
>
No bug.
It's \chords vs \chordmode.
\chords (as a shortcut) already created a ChordNames-context, see:
chordStuff = \chords { c1 d:m }
\void \displayLilyMusic \chordStuff
So if you really want to use \chords you need to put overrides, etc
into \layout or use
\chords \with { ... }
at least with newer devel-versions.
If you use \chordmode you can do
\new ChordNames \with { ... } \chordmode
Additional Examples:
melody = \relative c'' { c4 c c c | d d d d }
\score {
<<
\chords
\with {
\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #10
}
{ c1 d:m }
\new Staff \melody
>>
}
\score {
<<
\new ChordNames
\with {
\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #10
}
\chordmode { c1 d:m }
\new Staff \melody
>>
}
Sorry for late reply, the job ...
Cheers,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to adjust space between ChordNames and Staff?
Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM
> On 13 January 2017 at 01:20, Trevor Daniels wrote:
>
>> Thomas Morley wrote Thursday, January 12, 2017 10:26 PM
>>
>>> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi :
>>>
>>>> The spacing between ChordNames and Staff seems a bit tight by default. I've
>>>> been trying to adjust it but I haven't figured out the right magic words
>>>
>>> Do it in \layout
>>>
>>> chordStuff = \chords { c1 d:m }
>>> melody = \relative c'' { c4 c c c | d d d d }
>>> \score {
>>> <<
>>>\new ChordNames { \chordStuff }
>>>\new Staff { \melody }
>>> >>
>>> \layout {
>>> \context {
>>>\ChordNames
>>>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding =
>>> #10
>>> }
>>> }
>>> }
>>
>> Interesting. Does that mean the ChordNames and Lyrics contexts behave
>> differently wrt the vertical spacing controls when these are placed within a
>> \with { } block, since Lyrics can be spaced out that way?
>>
>> If so, is this intended for some reason ... or a bug?
>
> Thanks Harm. That did the trick. However, I concur with Trevor about the
> confusing difference compared to Lyrics. I assumed that they'd work the
> same way so I did not occur to me to try the \layout block. If it /is/ an
> intended behaviour, there should probably be a note that the settings
> won't work with \with { }.
Exactly, but I think we need to understand exactly what the problem is before
we can decide (a) whether this _is_ a bug and if so (b) whether it is a coding
or
a documentation problem.
Copying to bug list so this doesn't get forgotten.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to adjust space between ChordNames and Staff?
On 13 January 2017 at 01:20, Trevor Daniels wrote:
>
> Thomas Morley wrote Thursday, January 12, 2017 10:26 PM
>
>
> > 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi :
> >
> >> The spacing between ChordNames and Staff seems a bit tight by default.
> I've
> >> been trying to adjust it but I haven't figured out the right magic words
> >
> > Do it in \layout
> >
> > chordStuff = \chords { c1 d:m }
> >
> > melody = \relative c'' { c4 c c c | d d d d }
> >
> > \score {
> > <<
> > \new ChordNames { \chordStuff }
> >\new Staff { \melody }
> > >>
> > \layout {
> > \context {
> >\ChordNames
> >\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding
> = #10
> > }
> > }
> > }
>
> Interesting. Does that mean the ChordNames and Lyrics contexts behave
> differently wrt the vertical spacing controls when these are placed within
> a
> \with { } block, since Lyrics can be spaced out that way?
>
> If so, is this intended for some reason ... or a bug?
>
> Trevor
>
Thanks Harm. That did the trick. However, I concur with Trevor about the
confusing difference compared to Lyrics. I assumed that they'd work the
same way so I did not occur to me to try the \layout block. If it /is/ an
intended behaviour, there should probably be a note that the settings won't
work with \with { }.
-Risto
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to adjust space between ChordNames and Staff?
Thomas Morley wrote Thursday, January 12, 2017 10:26 PM
> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi :
>
>> The spacing between ChordNames and Staff seems a bit tight by default. I've
>> been trying to adjust it but I haven't figured out the right magic words
>
> Do it in \layout
>
> chordStuff = \chords { c1 d:m }
>
> melody = \relative c'' { c4 c c c | d d d d }
>
> \score {
> <<
>\new ChordNames { \chordStuff }
>\new Staff { \melody }
> >>
> \layout {
> \context {
>\ChordNames
>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #10
> }
> }
> }
Interesting. Does that mean the ChordNames and Lyrics contexts behave
differently wrt the vertical spacing controls when these are placed within a
\with { } block, since Lyrics can be spaced out that way?
If so, is this intended for some reason ... or a bug?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 4460 in lilypond: Parentheses in ChordNames should have the same size as the chord symbols
Am 23.06.2015 um 11:31 schrieb lilyp...@googlecode.com: Comment #5 on issue 4460 by thomasmo...@gmail.com: Parentheses in ChordNames should have the same size as the chord symbols https://code.google.com/p/lilypond/issues/detail?id=4460 Is this issue a duplicate of https://code.google.com/p/lilypond/issues/detail?id=1451 ? I am not sure, I think that at least the description may be interpreted more globally, but since the example covers chord names only, this is probably a duplicate. Other opinions? > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 4460 in lilypond: Parentheses in ChordNames should have the same size as the chord symbols
Am 23.06.2015 um 11:03 schrieb James: Marc On 23/06/15 09:25, Marc Hohl wrote: Am 23.06.2015 um 10:15 schrieb lilyp...@googlecode.com: Updates: Labels: -Patch-review Patch-needs_work Comment #3 on issue 4460 by pkx1...@gmail.com: Parentheses in ChordNames should have the same size as the chord symbols https://code.google.com/p/lilypond/issues/detail?id=4460 This looks like it still needs work. Why? It passes all tests IIRC. I am not a programmer and can only go on what the discussion 'looks like' to me when I go through the list. I think you refer to the comments David made, but as he mentioned, his proposals claim for separate issues (namely the size of parentheses in TabStaff and FiguredBass). I always defer to the developers' though, so if you think I have made a mistake or inferred the thread incorrectly, then set it to 'countdown' (with a comment in the tracker reflecting my error) and that will be fine. Ok, will do. Thanks, Marc James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 4460 in lilypond: Parentheses in ChordNames should have the same size as the chord symbols
Marc On 23/06/15 09:25, Marc Hohl wrote: > Am 23.06.2015 um 10:15 schrieb lilyp...@googlecode.com: >> Updates: >> Labels: -Patch-review Patch-needs_work >> >> Comment #3 on issue 4460 by pkx1...@gmail.com: Parentheses in ChordNames >> should have the same size as the chord symbols >> https://code.google.com/p/lilypond/issues/detail?id=4460 >> >> This looks like it still needs work. > > Why? It passes all tests IIRC. I am not a programmer and can only go on what the discussion 'looks like' to me when I go through the list. I always defer to the developers' though, so if you think I have made a mistake or inferred the thread incorrectly, then set it to 'countdown' (with a comment in the tracker reflecting my error) and that will be fine. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 4460 in lilypond: Parentheses in ChordNames should have the same size as the chord symbols
Am 23.06.2015 um 10:15 schrieb lilyp...@googlecode.com: Updates: Labels: -Patch-review Patch-needs_work Comment #3 on issue 4460 by pkx1...@gmail.com: Parentheses in ChordNames should have the same size as the chord symbols https://code.google.com/p/lilypond/issues/detail?id=4460 This looks like it still needs work. Why? It passes all tests IIRC. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parentheses in ChordNames have the same size as the Chord symbols. (issue 245430043 by m...@hohlart.de)
Am 21.06.2015 um 10:43 schrieb d...@gnu.org: https://codereview.appspot.com/245430043/diff/1/ly/engraver-init.ly File ly/engraver-init.ly (right): https://codereview.appspot.com/245430043/diff/1/ly/engraver-init.ly#newcode517 ly/engraver-init.ly:517: \override ParenthesesItem.font-size = #1.5 Well, it's awkward to have parentheses sized independently from their content. The default size is probably intended to fit between staff lines. In that case, it might make sense to increase the size for TabStaff with its larger staffline spacing as well? Well, the tablature/parentheses stuff is in a inconsistent state anyway. Tied notes (fret numbers) have whiteout, \parenthesize'd notes don't. In a ChordNames context, I could not think of stuff that is easily parenthesized other than the chord names themselves. While it is perfectly conceivable to write something like C(7), I don't see any way where one would have a reasonable chance to use a working parenthesize property on anything but the main chord name. So increasing the size here seems without tangible drawbacks. Ok. No idea about the nicest size for FiguredBass though. Executive summary: this change is likely a good idea, some others might independently be nice. If time allows, I'll have a look. Thanks, Marc https://codereview.appspot.com/245430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Parentheses in ChordNames have the same size as the Chord symbols. (issue 245430043 by m...@hohlart.de)
https://codereview.appspot.com/245430043/diff/1/ly/engraver-init.ly File ly/engraver-init.ly (right): https://codereview.appspot.com/245430043/diff/1/ly/engraver-init.ly#newcode517 ly/engraver-init.ly:517: \override ParenthesesItem.font-size = #1.5 Well, it's awkward to have parentheses sized independently from their content. The default size is probably intended to fit between staff lines. In that case, it might make sense to increase the size for TabStaff with its larger staffline spacing as well? In a ChordNames context, I could not think of stuff that is easily parenthesized other than the chord names themselves. While it is perfectly conceivable to write something like C(7), I don't see any way where one would have a reasonable chance to use a working parenthesize property on anything but the main chord name. So increasing the size here seems without tangible drawbacks. No idea about the nicest size for FiguredBass though. Executive summary: this change is likely a good idea, some others might independently be nice. https://codereview.appspot.com/245430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parentheses in ChordNames
Marc Hohl writes:
> Am 20.06.2015 um 19:47 schrieb David Kastrup:
>> Marc Hohl writes:
>>
>>> Hi list,
>>>
>>> in my latest project, I found out that
>>>
>>> \score {
>>>\new ChordNames { \chordmode { \parenthesize c } }
>>> }
>>>
>>> yields in way too tiny parentheses. The following patch
>>> resolves that problem.
>>>
>>> I recall vaguely that 'git cl upload' does not work anymore.
>>
>> It started working for me again (the Google Code part). Maybe Google
>> decided that making stuff more complicated for people now when they are
>> going to switch everything off in a few months was not worth the trouble
>> after all.
>>
>>> How can I upload that patch to Rietveld?
>>
>> What you do need to do is to replace your upload.py with the current
>> one. Perhaps apply the appended patch to your git-cl using git am.
>
> Thanks for the patch, but I get
>
> marc@olivia ~/git/git-cl (master)$ git am
> ../0001-Replace-upload.py-also-let-it-use-auth2-by-default.patch
> Patch-Formaterkennung fehlgeschlagen.
>
> What can I do?
Absolutely no idea. I formatted this patch with git 2.1.4 but I don't
see anything in it that looks like it would be different from older
versions.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parentheses in ChordNames
Am 20.06.2015 um 19:47 schrieb David Kastrup:
Marc Hohl writes:
Hi list,
in my latest project, I found out that
\score {
\new ChordNames { \chordmode { \parenthesize c } }
}
yields in way too tiny parentheses. The following patch
resolves that problem.
I recall vaguely that 'git cl upload' does not work anymore.
It started working for me again (the Google Code part). Maybe Google
decided that making stuff more complicated for people now when they are
going to switch everything off in a few months was not worth the trouble
after all.
How can I upload that patch to Rietveld?
What you do need to do is to replace your upload.py with the current
one. Perhaps apply the appended patch to your git-cl using git am.
Thanks for the patch, but I get
marc@olivia ~/git/git-cl (master)$ git am
../0001-Replace-upload.py-also-let-it-use-auth2-by-default.patch
Patch-Formaterkennung fehlgeschlagen.
What can I do?
Marc
When that is done, git-cl (and the other scripts) work for me again.
I've not tried Rietveld without it recently, but since Rietveld is not
going to get switched off, it may be that it continues to require auth2.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parentheses in ChordNames
Marc Hohl writes:
> Hi list,
>
> in my latest project, I found out that
>
> \score {
> \new ChordNames { \chordmode { \parenthesize c } }
> }
>
> yields in way too tiny parentheses. The following patch
> resolves that problem.
>
> I recall vaguely that 'git cl upload' does not work anymore.
It started working for me again (the Google Code part). Maybe Google
decided that making stuff more complicated for people now when they are
going to switch everything off in a few months was not worth the trouble
after all.
> How can I upload that patch to Rietveld?
What you do need to do is to replace your upload.py with the current
one. Perhaps apply the appended patch to your git-cl using git am.
When that is done, git-cl (and the other scripts) work for me again.
I've not tried Rietveld without it recently, but since Rietveld is not
going to get switched off, it may be that it continues to require auth2.
--
David Kastrup
>From a17eb9c48b6ad5f6144f4f6b4f96d2a3892dc46c Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Sat, 20 Jun 2015 19:44:09 +0200
Subject: [PATCH] Replace upload.py, also let it use auth2 by default
---
upload.py | 489 +++---
1 file changed, 407 insertions(+), 82 deletions(-)
mode change 100755 => 100644 upload.py
diff --git a/upload.py b/upload.py
old mode 100755
new mode 100644
index 3a7f238..071fbee
--- a/upload.py
+++ b/upload.py
@@ -34,6 +34,7 @@ against by using the '--rev' option.
# This code is derived from appcfg.py in the App Engine SDK (open source),
# and from ASPN recipe #146306.
+import BaseHTTPServer
import ConfigParser
import cookielib
import errno
@@ -51,6 +52,9 @@ import sys
import urllib
import urllib2
import urlparse
+import webbrowser
+
+from multiprocessing.pool import ThreadPool
# The md5 module was deprecated in Python 2.5.
try:
@@ -74,6 +78,7 @@ except ImportError:
# 2: Info logs.
# 3: Debug logs.
verbosity = 1
+LOGGER = logging.getLogger('upload')
# The account type used for authentication.
# This line could be changed by the review server (see handler for
@@ -87,6 +92,7 @@ DEFAULT_REVIEW_SERVER = "codereview.appspot.com"
# Max size of patch or base file.
MAX_UPLOAD_SIZE = 900 * 1024
+
# Constants for version control names. Used by GuessVCSName.
VCS_GIT = "Git"
VCS_MERCURIAL = "Mercurial"
@@ -95,16 +101,72 @@ VCS_PERFORCE = "Perforce"
VCS_CVS = "CVS"
VCS_UNKNOWN = "Unknown"
-VCS_ABBREVIATIONS = {
- VCS_MERCURIAL.lower(): VCS_MERCURIAL,
- "hg": VCS_MERCURIAL,
- VCS_SUBVERSION.lower(): VCS_SUBVERSION,
- "svn": VCS_SUBVERSION,
- VCS_PERFORCE.lower(): VCS_PERFORCE,
- "p4": VCS_PERFORCE,
- VCS_GIT.lower(): VCS_GIT,
- VCS_CVS.lower(): VCS_CVS,
-}
+VCS = [
+{
+'name': VCS_MERCURIAL,
+'aliases': ['hg', 'mercurial'],
+}, {
+'name': VCS_SUBVERSION,
+'aliases': ['svn', 'subversion'],
+}, {
+'name': VCS_PERFORCE,
+'aliases': ['p4', 'perforce'],
+}, {
+'name': VCS_GIT,
+'aliases': ['git'],
+}, {
+'name': VCS_CVS,
+'aliases': ['cvs'],
+}]
+
+VCS_SHORT_NAMES = []# hg, svn, ...
+VCS_ABBREVIATIONS = {} # alias: name, ...
+for vcs in VCS:
+ VCS_SHORT_NAMES.append(min(vcs['aliases'], key=len))
+ VCS_ABBREVIATIONS.update((alias, vcs['name']) for alias in vcs['aliases'])
+
+
+# OAuth 2.0-Related Constants
+LOCALHOST_IP = '127.0.0.1'
+DEFAULT_OAUTH2_PORT = 8001
+ACCESS_TOKEN_PARAM = 'access_token'
+ERROR_PARAM = 'error'
+OAUTH_DEFAULT_ERROR_MESSAGE = 'OAuth 2.0 error occurred.'
+OAUTH_PATH = '/get-access-token'
+OAUTH_PATH_PORT_TEMPLATE = OAUTH_PATH + '?port=%(port)d'
+AUTH_HANDLER_RESPONSE = """\
+
+
+Authentication Status
+
+window.onload = function() {
+ window.close();
+}
+
+
+
+The authentication flow has completed.
+
+
+"""
+# Borrowed from google-api-python-client
+OPEN_LOCAL_MESSAGE_TEMPLATE = """\
+Your browser has been opened to visit:
+
+%s
+
+If your browser is on a different machine then exit and re-run
+upload.py with the command-line parameter
+
+ --no_oauth2_webbrowser
+"""
+NO_OPEN_LOCAL_MESSAGE_TEMPLATE = """\
+Go to the following link in your browser:
+
+%s
+
+and copy the access token.
+"""
# The result of parsing Subversion's [auto-props] setting.
svn_auto_props_map = None
@@ -179,8 +241,9 @@ class ClientLoginError(urllib2.HTTPError):
class AbstractRpcServer(object):
"""Provides a common interface for a simple RPC s
Parentheses in ChordNames
Hi list,
in my latest project, I found out that
\score {
\new ChordNames { \chordmode { \parenthesize c } }
}
yields in way too tiny parentheses. The following patch
resolves that problem.
I recall vaguely that 'git cl upload' does not work anymore.
How can I upload that patch to Rietveld?
Cheers,
Marc
From 360d89c13713be692db3a6fc557eda0f7557a288 Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Sat, 20 Jun 2015 19:19:03 +0200
Subject: [PATCH] Parentheses in ChordNames have the same size as the Chord
symbols.
---
ly/engraver-init.ly | 1 +
1 file changed, 1 insertion(+)
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index 5d695eb..7fd1d80 100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -512,6 +512,7 @@ printing of a single line of lyrics."
\override VerticalAxisGroup.staff-affinity = #DOWN
\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #0.5
\override VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = #0.5
+ \override ParenthesesItem.font-size = #0
}
\context {
--
1.9.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Although, this is not the final patch for this topic, James, may I ask you to run patchy against it? https://codereview.appspot.com/223420043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
On 2015/04/13 02:22:15, Carl wrote:
I think that this is a great start. You're working in a really
complex area,
and trying to sort it out. Good for you!
I've made some specific comments below. I think the separation
between list
creation and markup creation needs to be made stronger and more
explicit;
probably we need to change the property names.
https://codereview.appspot.com/223420043/diff/20001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
https://codereview.appspot.com/223420043/diff/20001/ly/engraver-init.ly#newcode689
ly/engraver-init.ly:689: chordRootNamer = #note-name->list
Perhaps we should rename chordRootNamer to something like
chordAnalyzer. That
would show the meaning much more clearly.
Or perhaps more importantly, we should have a chordAnalyzer that takes
a chord
and returns a list, and a chordNamer that takes a list an returns a
markup. At
that point, we'd really have a clear separation of the two functions,
and if you
were happy with the Analyzer, you would only need to change the Namer.
https://codereview.appspot.com/223420043/diff/20001/ly/property-init.ly
File ly/property-init.ly (right):
https://codereview.appspot.com/223420043/diff/20001/ly/property-init.ly#newcode134
ly/property-init.ly:134: \set chordRootNamer =
#(chord-name->italian-list #t)
In scm/chord-generic-names.scm you are saying that a namer returns a
markup, not
a list. I think that is probably a pretty good use.
Perhaps we should think of two different kinds of things: "analyzers"
that
convert chord names to lists, and "namers" that convert lists to
markups. And
we should hold strong to that convention.
I think it's a mistake to have a "namer" return a list, since the
thing that is
printed as a ChordName is a markup. A namer should produce a markup,
in my
opinion.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-generic-names.scm
File scm/chord-generic-names.scm (right):
https://codereview.appspot.com/223420043/diff/20001/scm/chord-generic-names.scm#newcode33
scm/chord-generic-names.scm:33: "Return a markup for @var{pitch}, with
name of
@var{pitch} and a (possible)
I think the name of this function should change to something like
note-markup
https://codereview.appspot.com/223420043/diff/20001/scm/chord-generic-names.scm#newcode35
scm/chord-generic-names.scm:35: (let* ((note-namer (note-name->list
pitch #f))
I don't like the name note-namer here; it sounds like a function,
rather than an
alist.
Perhaps note-alist or note-name-alist or structure-alist or even
namer-alist.
Or you could eliminate the alist part and call it
note-structure or note-elements (although elements has a specific
lilypond
meaning that probably makes this name undesirable) or note-parts.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm
File scm/chord-ignatzek-names.scm (right):
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode288
scm/chord-ignatzek-names.scm:288: ;; Build the list for the chord-data
from
'root-info, 'slash-chord-separato,
Isn't slash-chord-separator part of the display, rather than part of
the chord
structure?
It seems to me that this patch is mostly maintaining the mix of
parsing and
display; it's just putting the stuff into a list first.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode395
scm/chord-ignatzek-names.scm:395: Step 2: Define formatter for
the
chord-elements using this list
I'm not sure how this separation between step 1 and step 2 really
accomplishes
the stated goal of the patch. Can you give an example of how this
makes it
easier to define a new display style for a chord?
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode427
scm/chord-ignatzek-names.scm:427: (make-hspace-markup (if (=
alteration FLAT)
0.57285385 0.5))
Magic numbers are of concern, both here and later. At the least,
there should
be a TODO comment.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-name.scm
File scm/chord-name.scm (right):
https://codereview.appspot.com/223420043/diff/20001/scm/chord-name.scm#newcode53
scm/chord-name.scm:53: (define-safe-public ((chord-name->german-list
B-instead-of-Bb)
Shouldn't all these functions be combined into one
(define-safe-public ((chord-name->note-alteration-list language-name
options)
... )
It seems like to really separate it out, we need to do more than just
return a
list instead of a markup. We should create a real logical structure
that will
separate things out cleanly.
Hi Carl,
most of the above comments needs still to be adressed, especially the
ones about namings.
Though, with the recent patchset I try to do a much deeper
disentangeling of structure and output.
Cheers,
Harm
https://codereview.appspot.com/223420043/
__
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
On 4/16/15 4:39 PM, "Thomas Morley" wrote: > >I really hope I didn't offend you in any way! >Your input is very helpful and highly apreciated! You didn't offend me in any way. I am practically un-offendable. The problem comes that I tend to sometimes offend others. I was trying to avoid giving offense to you. I will take a better look at your patch. I think I did not understand it correctly. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
2015-04-16 4:55 GMT+02:00 Carl Sorensen :
> Hi Harm,
>
> On 4/15/15 4:30 PM, "Thomas Morley" wrote:
>
>>Hi Carl,
>>
>>before going into details, let us decide how to proceed.
>>
>>The current patch was intended to be not more than maintaining the
>>stuff different.
>>First step seemed to me putting the needed data into an alist.
>>
>>2015-04-13 4:22 GMT+02:00 :
>>
>>> It seems to me that this patch is mostly maintaining the mix of parsing
>>> and display; it's just putting the stuff into a list first.
>>
>>So you are absolutely right.
>>
>>I think you would prefer to dig in deeper, though.
>
> My impression (although I haven't studied it carefully as recently as you
> have, so I might be wrong) is that the current system goes through the
> chord and creates a bunch of markup information that it puts together into
> a markup.
>
> Changing it to put the markup information in an alist seems to still mix
> the markup and the parsing. The stuff that seems to me should go in the
> alist is structural information about the chord, rather than markup
> information.
You wrote about a chord-analyzer on Rietveld.
Seems I have difficulties to fully understand what you think.
The chord-info-procedure was intended to put out an analysis of the
chord representing it in an alist.
Let's have a look at an example:
\new ChordNames
\chordmode {
fis1:m5-.7+.9-.11+.13-/ces
}
chord-info would return:
(list (list 'root-info
(cons (quote note-name) "F")
(list 'alteration-info
(cons (quote alteration) 1/2)
(cons 'accidental-glyph
"accidentals.sharp")))
(cons (quote chord-prefix-spacer) 0)
(list 'prefixes
(list 'minor-chord-modifier
simple-markup
"m"))
(list 'chord-name-separator
hspace-markup
0.5)
(list 'main-info
(list 'major-seven-symbol
line-markup
(list (markup #:triangle #f
(list 'alterations
(list (list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))
(cons (quote number) "5"))
(list (list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))
(cons (quote number) "9"))
(list (list 'alteration-info
(cons (quote alteration) 1/2)
(cons 'accidental-glyph
"accidentals.sharp"))
(cons (quote number) "11"))
(list (list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"))
(cons (quote number) "13")))
(list (quote suffixes))
(list (quote addings))
(list 'bass-info
(list 'slash-chord-separator
simple-markup
"/")
(cons (quote note-name) "C")
(list 'alteration-info
(cons (quote alteration) -1/2)
(cons 'accidental-glyph
"accidentals.flat"
The entries for 'minor-chord-modifier, 'chord-name-separator and a few
others contain markups. If I didn't overlook something they all are
coming from the relevant context-properties.
Those could be called later when putting together the markup.
The entries for 'accidental-glyph could be found later as well.
Is that like you'd prefer?
What about the 'note-name for root and bass?
Thea are simple strings.
>
> So for me, the alist you are creating doesn't even really pave the way for
> the kind of separation I envision.
>>>
>>>
>>>https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-na
>>>mes.scm#newcode395
>>> scm/chord-ignatzek-names.scm:395: Step 2: Define formatter for the
>>> chord-elements using this list
>>> I'm not sure how this separation between step 1 and step 2 really
>>> accomplishes the stated goal of the patch. Can you give an example of
>>> how this makes it easier to define a new display style for a chord?
>>
>>This patch doesn't pretend to provide a user-inte
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Hi Harm, On 4/15/15 4:30 PM, "Thomas Morley" wrote: >Hi Carl, > >before going into details, let us decide how to proceed. > >The current patch was intended to be not more than maintaining the >stuff different. >First step seemed to me putting the needed data into an alist. > >2015-04-13 4:22 GMT+02:00 : > >> It seems to me that this patch is mostly maintaining the mix of parsing >> and display; it's just putting the stuff into a list first. > >So you are absolutely right. > >I think you would prefer to dig in deeper, though. My impression (although I haven't studied it carefully as recently as you have, so I might be wrong) is that the current system goes through the chord and creates a bunch of markup information that it puts together into a markup. Changing it to put the markup information in an alist seems to still mix the markup and the parsing. The stuff that seems to me should go in the alist is structural information about the chord, rather than markup information. So for me, the alist you are creating doesn't even really pave the way for the kind of separation I envision. >> >> >>https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-na >>mes.scm#newcode395 >> scm/chord-ignatzek-names.scm:395: Step 2: Define formatter for the >> chord-elements using this list >> I'm not sure how this separation between step 1 and step 2 really >> accomplishes the stated goal of the patch. Can you give an example of >> how this makes it easier to define a new display style for a chord? > >This patch doesn't pretend to provide a user-interface for it. I wasn't asking for a user interface. I was more just asking for a logical sketch of how it would work. >Already possible is the following, though. I couldn't make the following code work. I don't have chord-info, or format-alterations, or any of the other format-*. Are you proposing this as a potential way to work with the things in your patch, and that chord-info would result from a call to ChordNamer? Or am I totally missing things here? And I have no desire to stand in the way of your patch, if it's moving things forward in a way that you have found useful. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Hi Carl,
before going into details, let us decide how to proceed.
The current patch was intended to be not more than maintaining the
stuff different.
First step seemed to me putting the needed data into an alist.
2015-04-13 4:22 GMT+02:00 :
> It seems to me that this patch is mostly maintaining the mix of parsing
> and display; it's just putting the stuff into a list first.
So you are absolutely right.
I think you would prefer to dig in deeper, though.
I tend to prefer letting it as is and push a polished version as a _first_ step.
And then tackle next step.
Doing all in one go might result in a too big patch, not feasable for
thorough revision anymore.
What do you think?
>
> https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode395
> scm/chord-ignatzek-names.scm:395: Step 2: Define formatter for the
> chord-elements using this list
> I'm not sure how this separation between step 1 and step 2 really
> accomplishes the stated goal of the patch. Can you give an example of
> how this makes it easier to define a new display style for a chord?
This patch doesn't pretend to provide a user-interface for it.
Already possible is the following, though.
#(define-public (my-chord-formatter
pitches bass inversion
context)
(let* ((chrd (chord-info pitches bass inversion context))
(exception-markup (assoc-get 'exception-markup chrd)))
#{
\markup {
\override #'(baseline-skip . 1)
\column {
#(format-root chrd)
#(let ((bass (format-bass chrd)))
(if (not (equal? bass ""))
#{
\markup
\column {
%% TODO adjust line automagically
%% I've a markup-command doing this
%% (but it's not really relevant for the example)
\draw-line #'(3.5 . 0)
\vspace #0.1
\small #(format-bass chrd)
}
#}
""))
}
#(if exception-markup
exception-markup
#{
\markup {
\raise #2
\teeny
\override #'(baseline-skip . 2)
\column {
\smaller
\line {
#(format-alteration chrd)
#(format-suffixes chrd)
#(format-additions chrd)
}
\override #'(baseline-skip . 3)
#(format-main-name chrd)
}
}
#})
}
#}))
\layout {
\context {
\Score
chordNameFunction = #my-chord-formatter
%additionalPitchPrefix = #"add"
%majorSevenSymbol = #whiteTriangleMarkup
%chordNameSeparator = ""
%minorChordModifier = "m"
slashChordSeparator = ""
%chordPrefixSpacer = #5
%#(make-hspace-markup 0.5)
chordNameLowercaseMinor = ##t
%chordNoteNamer = #note-name->german-list
%chordRootNamer = #(chord-name->german-list #f)
}
}
\new ChordNames
\chordmode {
fis1:m5-.7+.9-.11+.13-/ces
f:m5-.7+.9-.11+.13-/ces
fis:m5-.9+.11+.13-/+ces
\once \set Score.additionalPitchPrefix = #"add"
c1:9^7 % Cadd9 root-3-5-9
}
Any formatting procedure could be replaced by a custom procedure ofcourse
> https://codereview.appspot.com/223420043/
Thanks,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
On 4/14/15 9:51 AM, "David Kastrup" wrote: >Carl Sorensen writes: > >> On 4/13/15 6:06 PM, "Thomas Morley" wrote: >> >>>Hi Carl, >>> >>>thanks for review. >>> >>>Pity to say my vacations ended :( >>>I'll have much less time now, so work on this will be slowed down. >>>I'll hope I can answer more thoroughly the upcoming days ... >> >> My summer time will be starting in a couple of weeks. Maybe I can help >> with this, now you've started it. > >I have to admit to not even having looked at the code yet. But I still >want to point out one real area of operation that would be nice to >cover. > >Accordion standard bass... > >Basically, they lean towards being alternating chord accompaniment: > >\clef bass \time 3/4 c q | g q q | g q | d q q > >Namely, a pattern of alternating bass notes and chords, with the chord >inversions determined by picking all the notes from a fixed octave. The >chord repertoire is x (major), x:m (minor), x:7^5 (major seventh missing >the fifth) and x:dim7^5 (full diminuished missing the fifth), all of >those picking an inversion in a single octave. Chords get additionally >_labelled_ in the score (accordion players are not too good at actually >reading anything but the rhythm in bass clef) as x, xm, x7, and xv (the >latter being the German naming; it may be xdim in other languages), >while the bass notes are marked with uppercase letters. There may be >_combined_ chords by pressing more than one button: for example, a:m7 >can be represented as "c+am", and a:m6 can be represented as "am+av". > >So we have, basically, an inversion-ignoring chord pattern recognition >problem, in a similar vein as guitar chord diagrams have a mostly >inversion-ignoring chord pattern recognition problem. > >So it would be nice to have the chord recognition, the naming >(upper/lowercase), particular pattern recognition/exceptions all sort of >independent so that one may plug them together in different manners. I think that this should be totally doable. I envision that the chord pattern alist will have an entry for inversion; the accordion chord name print out routine can just ignore the inversion. I think that Harm's current patch already carves out the naming part of the chord (upper/lower case root, alterations) separately; ultimately I think that will become part of the chord pattern alist. Thanks for your input. As we get further along, we'll see if the structure works right. The current patch is just a start at separating the recognition from the markup. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Carl Sorensen writes: > On 4/13/15 6:06 PM, "Thomas Morley" wrote: > >>Hi Carl, >> >>thanks for review. >> >>Pity to say my vacations ended :( >>I'll have much less time now, so work on this will be slowed down. >>I'll hope I can answer more thoroughly the upcoming days ... > > My summer time will be starting in a couple of weeks. Maybe I can help > with this, now you've started it. I have to admit to not even having looked at the code yet. But I still want to point out one real area of operation that would be nice to cover. Accordion standard bass... Basically, they lean towards being alternating chord accompaniment: \clef bass \time 3/4 c q | g q q | g q | d q q Namely, a pattern of alternating bass notes and chords, with the chord inversions determined by picking all the notes from a fixed octave. The chord repertoire is x (major), x:m (minor), x:7^5 (major seventh missing the fifth) and x:dim7^5 (full diminuished missing the fifth), all of those picking an inversion in a single octave. Chords get additionally _labelled_ in the score (accordion players are not too good at actually reading anything but the rhythm in bass clef) as x, xm, x7, and xv (the latter being the German naming; it may be xdim in other languages), while the bass notes are marked with uppercase letters. There may be _combined_ chords by pressing more than one button: for example, a:m7 can be represented as "c+am", and a:m6 can be represented as "am+av". So we have, basically, an inversion-ignoring chord pattern recognition problem, in a similar vein as guitar chord diagrams have a mostly inversion-ignoring chord pattern recognition problem. So it would be nice to have the chord recognition, the naming (upper/lowercase), particular pattern recognition/exceptions all sort of independent so that one may plug them together in different manners. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
On 4/13/15 6:06 PM, "Thomas Morley" wrote: >Hi Carl, > >thanks for review. > >Pity to say my vacations ended :( >I'll have much less time now, so work on this will be slowed down. >I'll hope I can answer more thoroughly the upcoming days ... My summer time will be starting in a couple of weeks. Maybe I can help with this, now you've started it. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Hi Carl, thanks for review. Pity to say my vacations ended :( I'll have much less time now, so work on this will be slowed down. I'll hope I can answer more thoroughly the upcoming days ... Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
I think that this is a great start. You're working in a really complex
area, and trying to sort it out. Good for you!
I've made some specific comments below. I think the separation between
list creation and markup creation needs to be made stronger and more
explicit; probably we need to change the property names.
https://codereview.appspot.com/223420043/diff/20001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
https://codereview.appspot.com/223420043/diff/20001/ly/engraver-init.ly#newcode689
ly/engraver-init.ly:689: chordRootNamer = #note-name->list
Perhaps we should rename chordRootNamer to something like chordAnalyzer.
That would show the meaning much more clearly.
Or perhaps more importantly, we should have a chordAnalyzer that takes a
chord and returns a list, and a chordNamer that takes a list an returns
a markup. At that point, we'd really have a clear separation of the two
functions, and if you were happy with the Analyzer, you would only need
to change the Namer.
https://codereview.appspot.com/223420043/diff/20001/ly/property-init.ly
File ly/property-init.ly (right):
https://codereview.appspot.com/223420043/diff/20001/ly/property-init.ly#newcode134
ly/property-init.ly:134: \set chordRootNamer =
#(chord-name->italian-list #t)
In scm/chord-generic-names.scm you are saying that a namer returns a
markup, not a list. I think that is probably a pretty good use.
Perhaps we should think of two different kinds of things: "analyzers"
that convert chord names to lists, and "namers" that convert lists to
markups. And we should hold strong to that convention.
I think it's a mistake to have a "namer" return a list, since the thing
that is printed as a ChordName is a markup. A namer should produce a
markup, in my opinion.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-generic-names.scm
File scm/chord-generic-names.scm (right):
https://codereview.appspot.com/223420043/diff/20001/scm/chord-generic-names.scm#newcode33
scm/chord-generic-names.scm:33: "Return a markup for @var{pitch}, with
name of @var{pitch} and a (possible)
I think the name of this function should change to something like
note-markup
https://codereview.appspot.com/223420043/diff/20001/scm/chord-generic-names.scm#newcode35
scm/chord-generic-names.scm:35: (let* ((note-namer (note-name->list
pitch #f))
I don't like the name note-namer here; it sounds like a function, rather
than an alist.
Perhaps note-alist or note-name-alist or structure-alist or even
namer-alist.
Or you could eliminate the alist part and call it
note-structure or note-elements (although elements has a specific
lilypond meaning that probably makes this name undesirable) or
note-parts.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm
File scm/chord-ignatzek-names.scm (right):
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode288
scm/chord-ignatzek-names.scm:288: ;; Build the list for the chord-data
from 'root-info, 'slash-chord-separato,
Isn't slash-chord-separator part of the display, rather than part of the
chord structure?
It seems to me that this patch is mostly maintaining the mix of parsing
and display; it's just putting the stuff into a list first.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode395
scm/chord-ignatzek-names.scm:395: Step 2: Define formatter for the
chord-elements using this list
I'm not sure how this separation between step 1 and step 2 really
accomplishes the stated goal of the patch. Can you give an example of
how this makes it easier to define a new display style for a chord?
https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode427
scm/chord-ignatzek-names.scm:427: (make-hspace-markup (if (= alteration
FLAT) 0.57285385 0.5))
Magic numbers are of concern, both here and later. At the least, there
should be a TODO comment.
https://codereview.appspot.com/223420043/diff/20001/scm/chord-name.scm
File scm/chord-name.scm (right):
https://codereview.appspot.com/223420043/diff/20001/scm/chord-name.scm#newcode53
scm/chord-name.scm:53: (define-safe-public ((chord-name->german-list
B-instead-of-Bb)
Shouldn't all these functions be combined into one
(define-safe-public ((chord-name->note-alteration-list language-name
options) ... )
It seems like to really separate it out, we need to do more than just
return a list instead of a markup. We should create a real logical
structure that will separate things out cleanly.
https://codereview.appspot.com/223420043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Hi Harm, I cannot comment much on the code, but I like the general approach of separating chord information and chord markup very much! Two tiny remarks below. https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm File scm/chord-ignatzek-names.scm (right): https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode167 scm/chord-ignatzek-names.scm:167: (glue-word-to-step "huh" mod))) ;; What does "huh" mean?? 'huh' is meant to appear in cases where (pitch-step mod) returns strange values and has no musical meaning ;-) I don't know if/when this is triggered, but an error message would be more appropriate IMHO. https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-names.scm#newcode288 scm/chord-ignatzek-names.scm:288: ;; Build the list for the chord-data from 'root-info, 'slash-chord-separato, s/separato/separator/ https://codereview.appspot.com/223420043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by thomasmorle...@gmail.com)
Please review. Intended is a pure maintaining change. Maybe a first step for more flexibility, easier customizing etc. If I sorted it correctly, no change in visible output should occur. Apart from the Banter-style (see commit-message) no bug-fixing happens, although I noticed one (see FIXME in ignatzek-chord-names.scm). Some other TODOs, maybe worth other issues. https://codereview.appspot.com/223420043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
No midi with ChordNames (issue 217450043 by thomasmorle...@gmail.com)
Reviewers: ,
Message:
please review
Description:
No midi with ChordNames
Issue 4330
Restore the behaviour for ChordNames and ChordNameVoice in
performer-init.ly
which was changed by the patch for issue 4281
Please review this at https://codereview.appspot.com/217450043/
Affected files (+7, -0 lines):
M ly/performer-init.ly
Index: ly/performer-init.ly
diff --git a/ly/performer-init.ly b/ly/performer-init.ly
index
0942116dcef34cfc47a3d05c42cf537c78697c99..09abc727ba7da9dfdf392cbd396af1d68e4de3e7
100644
--- a/ly/performer-init.ly
+++ b/ly/performer-init.ly
@@ -319,10 +319,17 @@
\context {
\type "Performer_group"
\consists "Staff_performer"
+ \accepts ChordNameVoice
+ \defaultchild ChordNameVoice
\name ChordNames
}
\context {
+ \Voice
+ \name ChordNameVoice
+}
+
+\context {
\type "Performer_group"
\name StaffGroup
\accepts ChoirStaff
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
new Score in "rests passed to a ChordNames"
Hi Carl,
Line 480 in chords.itely has a weird example:
@lilypond[verbatim, quote, relative=1]
<<
\new ChordNames \chordmode {
c1
r1
g1
c1
}
\new Score \chordmode {
c1
r1
g1
c1
}
>>
@end lilypond
As far as I can tell, the \new Score bit has no effect whatsoever on the output.
1) did you mean to omit the relative=1 ?
2) more generally, what were you trying to show in this example? The
difference between a rest in ChordNames vs. non-ChordNames ?
You don't need to fix it yourself; just tell us what you intended, and
James will figure out a way of displaying it without \new Score.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add N.C. entry to ChordNames context.
Thanks, Neil!
All changes made, and pushed after verifying it worked OK.
Regards,
Carl
On 5/13/09 3:36 PM, "n.putt...@gmail.com" wrote:
>
>
> http://codereview.appspot.com/62076/diff/2001/1016
> File lily/chord-name-engraver.cc (right):
>
> http://codereview.appspot.com/62076/diff/2001/1016#newcode20
> Line 20: #include "text-interface.hh"
> Goes above #include "warn.hh"
>
> http://codereview.appspot.com/62076/diff/2001/1016#newcode63
> Line 63: SCM chord_changes = get_property("chordChanges");
> Move this back to its former position?
>
> http://codereview.appspot.com/62076/diff/2001/1016#newcode75
> Line 75: markup = scm_from_locale_string("");
> Better to return if no markup found.
>
> http://codereview.appspot.com/62076/diff/2001/1016#newcode149
> Line 149: ASSIGN_EVENT_ONCE(rest_event_ , ev);
> ASSIGN_EVENT_ONCE (rest_event_, ev);
>
> http://codereview.appspot.com/62076/diff/2001/1016#newcode150
> Line 150:
> remove blank line
>
> http://codereview.appspot.com/62076
>
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add N.C. entry to ChordNames context.
2009/5/12 Carl D. Sorensen :
> I think I need to create chord_name_ in two different places, because in one
> place the event is notes_[0] (if I have a chord), and in the other it's
> rest_event_ (if I have a rest). But all the other stuff can avoid
> duplication, I think.
You could use the conditional operator:
chord_name_ = make_item ("ChordName", rest_ ? rest_->self_scm () :
notes_[0]->self_scm ());
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add N.C. entry to ChordNames context.
http://codereview.appspot.com/62076/diff/2001/1016
File lily/chord-name-engraver.cc (right):
http://codereview.appspot.com/62076/diff/2001/1016#newcode20
Line 20: #include "text-interface.hh"
Goes above #include "warn.hh"
http://codereview.appspot.com/62076/diff/2001/1016#newcode63
Line 63: SCM chord_changes = get_property("chordChanges");
Move this back to its former position?
http://codereview.appspot.com/62076/diff/2001/1016#newcode75
Line 75: markup = scm_from_locale_string("");
Better to return if no markup found.
http://codereview.appspot.com/62076/diff/2001/1016#newcode149
Line 149: ASSIGN_EVENT_ONCE(rest_event_ , ev);
ASSIGN_EVENT_ONCE (rest_event_, ev);
http://codereview.appspot.com/62076/diff/2001/1016#newcode150
Line 150:
remove blank line
http://codereview.appspot.com/62076
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add N.C. entry to ChordNames context.
Neil,
Thanks for the review. I've put my responses below.
On 5/10/09 5:17 PM, "n.putt...@gmail.com" wrote:
> http://codereview.appspot.com/62076/diff/7/1008#newcode65
> Line 65: SCM no_chord_markup = get_property ("noChordSymbol");
> \set noChordSymbol = ##f will cause (harmless but annoying) errors here.
> You could check whether the markup's valid using
> Text_interface::is_markup ().
Thanks for the pointer. I added text-interface.hh to the includes in order
to be able to call this.
>
> http://codereview.appspot.com/62076/diff/7/1008#newcode70
> Line 70: chord_name_->set_property ("begin-of-line-visible",
> SCM_BOOL_T);
> If you just retrieved the markup instead and used the existing code
> below, you wouldn't need all this duplication.
I think I need to create chord_name_ in two different places, because in one
place the event is notes_[0] (if I have a chord), and in the other it's
rest_event_ (if I have a rest). But all the other stuff can avoid
duplication, I think.
>
> http://codereview.appspot.com/62076/diff/7/1008#newcode72
> Line 72: rest_event_ = 0;
> You don't need this, since you're clearing it in
> stop_translation_timestep ().
>
> http://codereview.appspot.com/62076/diff/7/1008#newcode73
> Line 73: return;
> You'd normally only return from process_music () if there's an error, so
> it would make sense to check for rests after checking for noteheads.
> This would allow you to use the same code below to create the grob, set
> the markup and calculate last_chord_.
I've modified the code so that now I have
if (rest_event_)
{
create chord_name_ with rest_event_
}
else
{
create chord_name_ with notes_[0]
}
set markup
store last_chord_
set begin-of-line-visible
As you mentioned, this eliminated duplication. Thanks for the pointers.
With these changes, I've put a new patch on rietveld. I'd appreciate it if
you'd see if I responded properly to your comments.
Thanks,
Carl
>
> http://codereview.appspot.com/62076
>
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Add N.C. entry to ChordNames context.
http://codereview.appspot.com/62076/diff/7/1008
File lily/chord-name-engraver.cc (right):
http://codereview.appspot.com/62076/diff/7/1008#newcode65
Line 65: SCM no_chord_markup = get_property ("noChordSymbol");
\set noChordSymbol = ##f will cause (harmless but annoying) errors here.
You could check whether the markup's valid using
Text_interface::is_markup ().
http://codereview.appspot.com/62076/diff/7/1008#newcode70
Line 70: chord_name_->set_property ("begin-of-line-visible",
SCM_BOOL_T);
If you just retrieved the markup instead and used the existing code
below, you wouldn't need all this duplication.
http://codereview.appspot.com/62076/diff/7/1008#newcode72
Line 72: rest_event_ = 0;
You don't need this, since you're clearing it in
stop_translation_timestep ().
http://codereview.appspot.com/62076/diff/7/1008#newcode73
Line 73: return;
You'd normally only return from process_music () if there's an error, so
it would make sense to check for rests after checking for noteheads.
This would allow you to use the same code below to create the grob, set
the markup and calculate last_chord_.
http://codereview.appspot.com/62076
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH]: Add N.C. to ChordNames when rest is in music
Please review this patch that adds N.C. notations to the ChordNames context. Patch set 2 is the current patch set. http://codereview.appspot.com/62076 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
proposed predefined for ChordNames context
I would like to propose the following predefined commands for the ChordNames
context:
hideRepeatedChordNames = {
\set chordChanges = ##t
}
showRepeatedChordNames = {
\set chordChanges = ##f
}
Here is an example of their use.
hideRepeatedChordNames = { \set chordChanges = ##t }
showRepeatedChordNames = { \set chordChanges = ##f }
harmonies = \chordmode {
c1:m c:m \break c:m c:m d
}
<<
\new ChordNames {
\hideRepeatedChordNames
%set chordChanges = ##t
\harmonies
}
\new Staff {
\relative c' { \harmonies }
}
>>
<<
\new ChordNames {
\showRepeatedChordNames
%set chordChanges = ##t
\harmonies
}
\new Staff {
\relative c' { \harmonies }
}
>>
Please give me your comments.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
AW: AW: ChordNames
Thank you very much :) I will inspect the code, but it looks very good so far. We may only need to add 6 and 7 chords for our needs, but I will have a try on that and if I don't succeed I will come back ;-) Regards, Philip > -Ursprüngliche Nachricht- > Von: Johannes Schindelin [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 29. November 2006 21:32 > An: Philip Chinery > Cc: lilypond-devel@gnu.org > Betreff: Re: AW: ChordNames > > Hi, > > On Wed, 29 Nov 2006, Philip Chinery wrote: > > > > Have you tried \germanChords? > > > > Yes, I have, but it only changes B to H and such things, > but our Goal > > ist to display "Am" as "a" while "A" remains "A". > > Correct. And you cannot just override chordRootNamer, since > that function is only passed a single pitch (not enough information). > > Attached is my attempt at it. It is dirt simple, in that it > only displays alower case letter for minor chords, and an > upper case letter for all others. No triangles, numbers or > symbols. But it's a start... > > Ciao, > Dscho > > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AW: ChordNames
Hi,
On Wed, 29 Nov 2006, Philip Chinery wrote:
> > Have you tried \germanChords?
>
> Yes, I have, but it only changes B to H and such things, but our Goal ist to
> display "Am" as "a" while "A" remains "A".
Correct. And you cannot just override chordRootNamer, since that function
is only passed a single pitch (not enough information).
Attached is my attempt at it. It is dirt simple, in that it only displays
alower case letter for minor chords, and an upper case letter for all
others. No triangles, numbers or symbols. But it's a start...
Ciao,
Dscho
\version "2.10.0"
\header {
texidoc = "Demonstrate German chord names"
}
chs = \transpose c' c'
{
1
% m = minor triad
\break
\transpose c' d' {
% triangle = maj
}
\break
\transpose c' es' {
}
\break
% 6 = major triad with added sixth
% m6 = minor triad with added sixth
\break
\break
\break
\break
\break
\break
\break
% add9
}
#(define (simple-german-chord-name pitches bass inversion context)
"Return simple chord markup for PITCH, using german note names.
Use lower case for minor, otherwise upper case. Does not do any fancy
sub or superscripts.
"
(let* ((pitch (car pitches))
(pitch2 (cadr pitches))
(diff (if (null? pitch2) (ly:make-pitch 0 0 0)
(ly:pitch-diff pitch2 pitch)))
(minor? (and (= (ly:pitch-notename diff) 2)
(= (ly:pitch-alteration diff) -2)))
(name (ly:pitch-notename pitch))
(short-alt? (or (= name 2) (= name 5)))
(alt (ly:pitch-alteration pitch))
(n-a (if (member (cons name alt) `((6 . ,FLAT) (6 . ,DOUBLE-FLAT)))
(cons 7 (+ SEMI-TONE alt))
(cons name alt
(markup #:line
((string-append
(vector-ref
(if minor?
#("c" "d" "e" "f" "g" "a" "h" "b")
#("C" "D" "E" "F" "G" "A" "H" "B"))
(car n-a))
(list-ref
(if short-alt?
'("ses" "s" "" "is" "isis")
'("eses" "es" "" "is" "isis"))
(+ 2 (/ alt 2
germanChordProperties = \sequential {
\set chordNameFunction = #simple-german-chord-name
}
\score{
<<
\new ChordNames {
\set instrumentName = #"Ignatzek (default)"
\set shortInstrumentName = #"Def"
\chs
}
\new ChordNames {
\germanChordProperties
\set instrumentName = #"Deutsch"
\set shortInstrumentName = #"dt"
\chs
}
\new Staff \transpose c c' { \chs }
>>
\layout {
indent = 3.\cm
\context {
\ChordNames
\consists Instrument_name_engraver
}
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
AW: ChordNames
> Have you tried \germanChords? Yes, I have, but it only changes B to H and such things, but our Goal ist to display "Am" as "a" while "A" remains "A". Regards, Philip ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ChordNames
Hi, On Wed, 29 Nov 2006, Philip Chinery wrote: > We have a problem (or rather an optical preference) with the chord names > that are deisplayed. Moll chords are displayed like "Am", but we want to > have it another way (maybe it is a german thing...), to have moll chords > displayed lowercase. So "A" remains "A" and "Am" will become "a". Have you tried \germanChords? > Is this documented somewhere? I looked at http://lilypond.org/doc/v2.10/Documentation/user/lilypond/Printing-chord-names.html Hth, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
ChordNames
Hello, We have a problem (or rather an optical preference) with the chord names that are deisplayed. Moll chords are displayed like "Am", but we want to have it another way (maybe it is a german thing...), to have moll chords displayed lowercase. So "A" remains "A" and "Am" will become "a". I have posted to the user list but got no respone on that - is it possible at all at the moment? I have discovered these properties in the documentation: - chordRootNamer - chordNoteNamer The documentations says: "The chordNoteNamer property can be set to a specialized function to change this behavior. For example, the base can be printed in lower case." Now the only problem for me is to know how to write and set such a function, then I would probably be able to make moll chords lowercase :) Is this documented somewhere? Regards, Philip ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Enlarge superscript for chordnames?
Is there a way to enlarge the font for the superscripts for chord names? I figured out how to enlarge the font for the chords \property ChordNames . ChordName \override #'font-relative-size = #+3 Which makes a nice large readable font, but the numbers are still really small. I'm making jazz charts, just chords and melody, and the bigger the chords the easier it is to use them. I'm using Lilypond 2.0.1 on OS X. Haven't been able to get 2.3 installed from the package for Fink. I'll probably have to build it by hand. Is the ChordName support any better in 2.3? Thanks, JD ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch to fix extra space in ChordNames (for 1.6.4)
[EMAIL PROTECTED] writes: > I have found that the ChordNames context includes a space between the > chord name the inversion or bass note like this "Am /G". I have traced > it to the chord::inner-chord-banter function in chord-name.scm: Ok, applied this. Hope it doesn't break anything else. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Patch to fix extra space in ChordNames (for 1.7.0)
This is the patch that was described in my previous message for 1.7.0. chord-name-1.7.0-patch.diff Description: Binary data
Patch to fix extra space in ChordNames (for 1.6.4)
I have found that the ChordNames context includes a space between the chord name the inversion or bass note like this "Am /G". I have traced it to the chord::inner-chord-banter function in chord-name.scm: (define (chord::inner-name-banter tonic exception-part additions subtractions bass-and-inversion steps) (let* ((tonic-text (pitch->chord-name-text-banter tonic steps)) (except-text exception-part) (sep-text (if (and (string-match "super" (format "~s" except-text)) (or (pair? additions) (pair? subtractions))) (list simple-super "/"))) (adds-text (chord::additions->text-banter additions subtractions)) (subs-text (chord::subtractions->text-banter subtractions)) (b+i-text (chord::bass-and-inversion->text-banter bass-and-inversion))) (text-append HERE-| tonic-text except-text " " sep-text HERE-^ ;;(list (list simple-super) adds-text subs-text) (list (list '((raise . 1) (font-relative-size . -1))) adds-text subs-text) b+i-text))) Changing [" "] to [""] removes the space in the chord name and does not appears to break anything in the process. I have run all the regression test examples that contain the ChordNames context and have not found any strange results. The patch is attached. I will send a patch for 1.7.0 separately. Scott Ainsworth chord-name-1.6.4-patch.diff Description: Binary data
