Vocal scores with extra staves

2017-02-26 Thread Andrew Bromage 

G'day.

I'm trying to typeset a work where one of the outputs is a vocal score.
One of the pieces involves the chorus singing in unison and then in
parts.

This is a cut-down version of my current attempt. There are two problems
here: First, the new staff isn't where I expect it to be; I'd like it to 
be part of
the ChoirStaff. Second, the lyrics for verse 2 don't start on the 
correct beat.


Any ideas?

The real example is much more complicated than this, obviously, but this
illustrates the problems.

Thanks,
Andrew Bromage

\version "2.18.2"

timeline = {
 \time 4/4
 { s1*2 } \bar "||"
 { s1*2 } \bar "|."
}

choirVerseI = { \relative c'' { c4 c c c c c c c } }
sopranoVerseII = { \relative c'' { c4 c c c c c c c } }
altoVerseII = { \relative e' { e4 e e e e e e e } }
tenorVerseII = { \relative g { g4 g g g g g g g } }
bassVerseII = { \relative c { c4 c c c c c c c } }
pianoRH = { \relative c' { 1} }
pianoLH = { \relative c { 1} }
lyricsVerseI = \lyricmode { la la la la la la la la }
lyricsVerseII = \lyricmode { lu lu lu lu lu lu lu lu }

\book {
  <<
 \new ChoirStaff {
 \clef treble \key c \major
 <<
   \timeline
   {
   \new Voice = "chorus" { \choirVerseI }
   <<
 \new Voice = "sopranoChorus" { \voiceOne \sopranoVerseII }
 \new Voice = "altoChorus" { \voiceTwo \altoVerseII }

 \new Staff {
   \clef bass \key c \major
   <<
   \new Voice = "tenorChorus" { \voiceOne \tenorVerseII }
   \new Voice = "bassChorus" { \voiceTwo \bassVerseII }
   >>
 }
   >>
  }
   >>
 }

 \new Lyrics = "chorusLyrics"

 \context Lyrics = "chorusLyrics" {
 \lyricsto "chorus" { \lyricsVerseI }
 \lyricsto "altoChorus" { \lyricsVerseII }
 }

 \new PianoStaff <<
   \new Staff { \clef treble \key c \major << \timeline \new Voice 
{ \pianoRH } >> }
   \new Staff { \clef bass \key c \major << \timeline \new Voice { 
\pianoLH } >> }

 >>
  >>
}


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

Re: "alt" notation for chords

2017-02-26 Thread Simon Albrecht 

Am 26.02.2017 um 16:32 schrieb Rob Torop:
I realize that this would pose a problem for midi generation since (I 
think) such a chord is non-deterministic. That is, the person comping 
has a choice between (sharp 5, sharp 9), (sharp 5, flat 9), and two 
others. I know I could just pick on and write, e.g., g:7.5-.9+, but 
I'd rather not.


I guess I’d suggest something like
\chords {
\once\override ChordName.Text = \markup { G \super { 7 alt } }
g:7^5
}

HTH, Simon

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

Re: 13th chord?

2017-02-26 Thread Wols Lists 
On 26/02/17 16:04, msk...@ansuz.sooke.bc.ca wrote:
> I've said it clearly enough times already, but I'll say it again:  I think
> there should be a feature to print what was typed, in the visual format of
> chord names, without interpreting it as music.  No more or less.  And this
> is proposed as a new feature, without deleting the existing features.

That's fine.

But imho it should not look like the current chord/chordname stuff.
Something like

\markup { \chordnametext "C13" }

would be perfect. That way, it's clearly markup, and not chords. My
worry is that if it looks like a chord, you're simply moving the
confusion elsewhere.

(And it should still work with things like

\markup { \chordnametext "C13(A13)" }

)

Cheers,
Wol

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

Re: 13th chord?

2017-02-26 Thread mskala 
On Sun, 26 Feb 2017, Wols Lists wrote:
> The OP complained that when he asked for "C13" he got "C 9 13". Sounds
> to me like now, if he asks for "C13" that's what he'll get, but if he
> asks for "C13 (A13)" he's going to get "C 9 13 (A 9 13)". That's almost
> worse!!!

What do you mean by "now"?  That certainly doesn't describe current
LilyPond, nor my proposal.

I've said it clearly enough times already, but I'll say it again:  I think
there should be a feature to print what was typed, in the visual format of
chord names, without interpreting it as music.  No more or less.  And this
is proposed as a new feature, without deleting the existing features.

Would it support transposition?  No, but it wouldn't harm users who want
to do transposition with the currently-existing features.

Would it directly support MIDI, automatic fingering charts, or any other
features that require LilyPond to interpret the input as music?  No,
because the point is to NOT interpret the input as music, only as stuff to
be printed.  But, again, it wouldn't harm users who want to use or extend
the currently-existing features for those things.

Would it stem the relentless stream of new users asking for help with
chord names on this mailing list?  Yes, if properly implemented and
documented as a first-class feature and not a "poor cousin," because what
those users really want is to have the chord names they typed, printed,
and only that.

But the clear consensus of the list seems to be that nothing suitable for
the 99% use case can be allowed to exist if it isn't also all things to
everyone, so I'll bow out of the discussion now.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: 13th chord?

2017-02-26 Thread Wols Lists 
On 26/02/17 14:47, msk...@ansuz.sooke.bc.ca wrote:
> On Sun, 26 Feb 2017, Wols Lists wrote:
>>> I don't know what that refers to.  Are you confusing me with someone else?
>>>
>> "I imagine it would make sense for most of its code to derive from the
>> code currently used for lyrics, but that fact would preferably NOT be
>> visible to users."
> 
> The difference between the new feature coming from lyrics code and the
> new feature being implemented in some other way should not be visible
> to users.
> 
> The difference between using the new feature at all, and not using it,
> should absolutely be visible to users.  That is the purpose of having it.
> 
The OP complained that when he asked for "C13" he got "C 9 13". Sounds
to me like now, if he asks for "C13" that's what he'll get, but if he
asks for "C13 (A13)" he's going to get "C 9 13 (A 9 13)". That's almost
worse!!!

Cheers,
Wol

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

"alt" notation for chords

2017-02-26 Thread Rob Torop 
I found some old threads where people were talking about supporting a
modifier for chords so that g:7alt would be rendered as in this example:

[image: Inline image 2]

I realize that this would pose a problem for midi generation since (I
think) such a chord is non-deterministic.  That is, the person comping has
a choice between (sharp 5, sharp 9), (sharp 5, flat 9), and two others. I
know I could just pick on and write, e.g., g:7.5-.9+, but I'd rather not.

However it's pretty common usage in jazz.

Was it decided not to do it, or is there a way?

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

Re: 13th chord?

2017-02-26 Thread Wols Lists 
On 26/02/17 14:05, Thomas Morley wrote:
> 2017-02-26 14:34 GMT+01:00 Anthony Youngman :
>>
>>
>> On 26/02/17 11:32, Thomas Morley wrote:
>>>
>>> 2017-02-26 12:12 GMT+01:00 Anthony Youngman :
> 
 I wrote some code which I submitted to lilypond to handle guitar capos.
> 
>>> Do we have a tracker-issue for it?
> 
>> I don't know. But I'm attaching the patches.
> 
> Thanks for the patches, I may have a look
> 
> I think it's
> https://sourceforge.net/p/testlilyissues/issues/1742/
> Rietveld:
> https://codereview.appspot.com/4800051/
> 
I'm sure I should have more stuff around than this, I'm looking for it.
But this is a minimal example of an input file and the output.

I know what I wanted was for the user to be able to put "\capo 3" at the
start of their .ly file, and it would print the capo setting and also
set the chordmode property so the chords were printed correctly.

Cheers,
Wol

\version "2.14.0"

\header{
  texidoc="Properties capoPitch, capoVertical: display chordnames, suitably 
transposed for a guitar capo, either in a line or one above the other.
"
}

<<
  \new ChordNames \chordmode {
c1
g1
c1
g1
c1
g1
  }
  \chordmode {
c1
g1
\set ChordNames.capoPitch = #(ly:make-pitch 0 -2 -1/2)
c1
g1
\set ChordNames.capoVertical = ##t
c1
g1
  }
>>


sample.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

2017-02-26 Thread mskala 
On Sun, 26 Feb 2017, Wols Lists wrote:
> > I don't know what that refers to.  Are you confusing me with someone else?
> >
> "I imagine it would make sense for most of its code to derive from the
> code currently used for lyrics, but that fact would preferably NOT be
> visible to users."

The difference between the new feature coming from lyrics code and the
new feature being implemented in some other way should not be visible
to users.

The difference between using the new feature at all, and not using it,
should absolutely be visible to users.  That is the purpose of having it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: 13th chord?

2017-02-26 Thread Wols Lists 
On 26/02/17 14:21, msk...@ansuz.sooke.bc.ca wrote:
> On Sun, 26 Feb 2017, Anthony Youngman wrote:
>> Replying to myself - remember, you said the user shouldn't notice any
>> difference. With my code, if you want to change the capo key, it's a
> 
> I don't know what that refers to.  Are you confusing me with someone else?
> 
"I imagine it would make sense for most of its code to derive from the
code currently used for lyrics, but that fact would preferably NOT be
visible to users."

And this - "Then they can use the existing code."

You did write that? The behaviour would be VERY different - and visible
- if the user was using capos, depending on whether they used the
current code, or your new lyrics-based code.

Cheers,
Wol

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

Re: 13th chord?

2017-02-26 Thread mskala 
On Sun, 26 Feb 2017, Anthony Youngman wrote:
> Replying to myself - remember, you said the user shouldn't notice any
> difference. With my code, if you want to change the capo key, it's a

I don't know what that refers to.  Are you confusing me with someone else?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: Making the Dedication field align left

2017-02-26 Thread Anthony Youngman 



On 26/02/17 00:38, Simon Albrecht wrote:

Am 26.02.2017 um 00:47 schrieb Wols Lists:

I've stuck that definition
in its own .ily file, and I just %include that file at the start of my
\paper definition.


I think it would be slightly cleaner to write an entire \paper{} block
in the .ily file and include the file on top level. Multiple paper
blocks will be combined as you’d expect them to.

I'll have to try that. I know I tried that with \header and it blew up 
me, which may be why I didn't try it with \paper.


Cheers,
Wol

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

Re: 13th chord?

2017-02-26 Thread Anthony Youngman 

On 26/02/17 13:55, Anthony Youngman wrote:

On 26/02/17 13:38, msk...@ansuz.sooke.bc.ca wrote:

On Sun, 26 Feb 2017, Anthony Youngman wrote:

EXCEPT.

This is *exactly* the scenario in which you will want my chord
transposition
code, and that doesn't make sense in a lyrics scenario.


Then they can use the existing code.


In which case, won't they get the existing problem? ie if they ask for
"C13" they will get "C 9 13 (A 9 13)" ?

It's a long time ago, but as far as I remember my code simply takes the
root of the chord, drops it by the capo setting, and then redoes the
chord name to put it after the correct pitch chord name. So if the
current code messes up, my capo code is going mess up, and mskala's
lyrics-based code just won't work, without him putting in a load of
extra stuff in to handle it.

Replying to myself - remember, you said the user shouldn't notice any 
difference. With my code, if you want to change the capo key, it's a 
one-character change at the start of the lily input file. With your 
lyrics-based code, I'm guessing you'll have to manually enter every 
single transposition in the first place, and then if you want to change 
the capo you'll have to go through them all again.


The reason I use lily is that I find it is very good at automating stuff 
that is difficult to do manually - like transposition! It feels to me 
like your code is asking for trouble.


Cheers,
Wol

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

Re: 13th chord?

2017-02-26 Thread Thomas Morley 
2017-02-26 14:34 GMT+01:00 Anthony Youngman :
>
>
> On 26/02/17 11:32, Thomas Morley wrote:
>>
>> 2017-02-26 12:12 GMT+01:00 Anthony Youngman :

>>> I wrote some code which I submitted to lilypond to handle guitar capos.

>> Do we have a tracker-issue for it?

> I don't know. But I'm attaching the patches.

Thanks for the patches, I may have a look

I think it's
https://sourceforge.net/p/testlilyissues/issues/1742/
Rietveld:
https://codereview.appspot.com/4800051/

Thanks,
  Harm

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

Re: 13th chord?

2017-02-26 Thread Anthony Youngman 

On 26/02/17 13:38, msk...@ansuz.sooke.bc.ca wrote:

On Sun, 26 Feb 2017, Anthony Youngman wrote:

EXCEPT.

This is *exactly* the scenario in which you will want my chord transposition
code, and that doesn't make sense in a lyrics scenario.


Then they can use the existing code.

In which case, won't they get the existing problem? ie if they ask for 
"C13" they will get "C 9 13 (A 9 13)" ?


It's a long time ago, but as far as I remember my code simply takes the 
root of the chord, drops it by the capo setting, and then redoes the 
chord name to put it after the correct pitch chord name. So if the 
current code messes up, my capo code is going mess up, and mskala's 
lyrics-based code just won't work, without him putting in a load of 
extra stuff in to handle it.


Cheers,
Wol

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

Re: 13th chord?

2017-02-26 Thread mskala 
On Sun, 26 Feb 2017, Anthony Youngman wrote:
> EXCEPT.
>
> This is *exactly* the scenario in which you will want my chord transposition
> code, and that doesn't make sense in a lyrics scenario.

Then they can use the existing code.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: 13th chord?

2017-02-26 Thread Anthony Youngman 



On 26/02/17 11:32, Thomas Morley wrote:

2017-02-26 12:12 GMT+01:00 Anthony Youngman :

On 26/02/17 10:52, Thomas Morley wrote:



If the chordNameFunction (ignatzek-chord-names) does not do what we
want, we should improve it, but not drop a plethora of
lily-functionality.

And yes, ignatzek-chord-names is insufficient in the sense that it's
hard up to impossible to tweak ChordName-printing sufficiently without
rewriting major parts of it.


Just to throw another big spanner into the works ...

I wrote some code which I submitted to lilypond to handle guitar capos. So,
for example, if you said something like "\capo 3", when you entered a chord
of C, it printed the chord name as "C(A)". This is *normal* practice when
printing music to accompany singers - the piano score has the guitar chords
on it.

My code didn't get into lilypond proper (I was asked to make a load of
changes, and I couldn't cope - my scheme-fu wasn't up to it), BUT. You need
to be careful that any changes you make don't break that use case - even if
I didn't get it in, I'm sure somebody else will want it in future.

Cheers,
Wol


Do we have a tracker-issue for it?

I don't know. But I'm attaching the patches. I could dig in to it, but I 
suspect you just want the patches date-stamped 1st August (the others 
are probably draft versions).


I had it working on my system, so the code does run successfully, at 
least with the version of lilypond that was current at the time.


Cheers,
Wol
>From a3ecdace013082f319987bd7aa98aa54d9decd0b Mon Sep 17 00:00:00 2001
From: Wol 
Date: Wed, 20 Jul 2011 18:49:43 +0100
Subject: [PATCH 1/3] Add capo-handler function for guitar chords

---
 scm/chord-name.scm |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/scm/chord-name.scm b/scm/chord-name.scm
index 79b0189..6910044 100644
--- a/scm/chord-name.scm
+++ b/scm/chord-name.scm
@@ -170,3 +170,27 @@ FOOBAR-MARKUP) if OMIT-ROOT is given and non-false.
 	 (alist (map chord-to-exception-entry elts)))
 (filter (lambda (x) (cdr x)) alist)))
 
+(define-public (capo-handler pitches bass inversion context)
+  (let (chord-function (ly:context-property context 'chordNameFunction #f))
+(capo-pitch (ly:context-property context 'capoPitch #f))
+(if  (not (capo-pitch)) ;; if there's no capo pitch or no chord
+  (chord-function pitches bass inversion context) ;; call the chordNameFunction as of old
+  (let ((new-pitches   ;; else transpose the pitches and do the chord twice
+(map (lambda (p)
+  (ly:pitch-transpose p capo-pitch))
+  pitches))
+  (new-bass
+(and (ly:pitch? bass)
+  (ly:pitch-transpose bass capo-pitch)))
+  (new-inversion
+(and (ly:pitch? inversion)
+  (ly:pitch-transpose inversion
+  capo-pitch)))
+
+  (capo-markup (make-parenthesize-markup (chord-function new-pitches new-bass new-inversion context)))
+  (markup (chord-function pitches bass  inversion context))
+
+  (capo-vertical (ly:context-property context 'capoVertical #f))
+  (if (capo-vertical)
+(make-column-markup (list markup capo-markup))
+(make-line-markup (list markup (make-hspace-markup 1) capo-markup
-- 
1.7.3.4

>From 355b7eda2d9de45e355d60831bb7851731a4de36 Mon Sep 17 00:00:00 2001
From: Wol 
Date: Sat, 30 Jul 2011 23:36:17 +0100
Subject: [PATCH 1/5] final commit I hope

---
 lily/chord-name-engraver.cc   |4 ++--
 scm/chord-name.scm|   28 
 scm/define-context-properties.scm |2 ++
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/lily/chord-name-engraver.cc b/lily/chord-name-engraver.cc
index d0ced5a..2442cdb 100644
--- a/lily/chord-name-engraver.cc
+++ b/lily/chord-name-engraver.cc
@@ -124,8 +124,8 @@ Chord_name_engraver::process_music ()
 
   pitches = scm_sort_list (pitches, Pitch::less_p_proc);
 
-  SCM name_proc = get_property ("chordNameFunction");
-  markup = scm_call_4 (name_proc, pitches, bass, inversion,
+  SCM capo_proc = ly_lily_module_constant ("capo-handler");
+  markup = scm_call_4 (capo_proc, pitches, bass, inversion,
   context ()->self_scm ());
 }
   /*
diff --git a/scm/chord-name.scm b/scm/chord-name.scm
index 79b0189..035b213 100644
--- a/scm/chord-name.scm
+++ b/scm/chord-name.scm
@@ -170,3 +170,31 @@ FOOBAR-MARKUP) if OMIT-ROOT is given and non-false.
 	 (alist (map chord-to-exception-entry elts)))
 (filter (lambda (x) (cdr x)) alist)))
 
+(define-public (capo-handler pitches bass inversion context)
+  (let ((chord-function
+  (ly:context-property context 'chordNameFunction 'jazz-chord-names))
+(capo-pitch (ly:context-property context 'capoPitch '(
+(if (not capo-pitch)
+

Re: 13th chord?

2017-02-26 Thread Anthony Youngman 

On 26/02/17 12:24, msk...@ansuz.sooke.bc.ca wrote:

On Sun, 26 Feb 2017, Thomas Morley wrote:

If the chordNameFunction (ignatzek-chord-names) does not do what we
want, we should improve it, but not drop a plethora of
lily-functionality.


I'm not proposing to "drop a plethora of lily-functionality" but only to
provide something that will be useful in the very common case of people
wanting to print chord names and wanting the output to match the input.
The proposed new feature would not be a modification of chord mode nor of
ChordNames, but a third thing separate from either of those two.  I
imagine it would make sense for most of its code to derive from the code
currently used for lyrics, but that fact would preferably NOT be visible
to users.


EXCEPT.

This is *exactly* the scenario in which you will want my chord 
transposition code, and that doesn't make sense in a lyrics scenario.


Cheers,
Wol

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

Re: [ANN] LilyQuick 0.9beta - fast accurate Lilypond MIDI note entry for Linux

2017-02-26 Thread Vaughan McAlley 
On 25 February 2017 at 20:45, Johan Vromans  wrote:
>
> On Sat, 25 Feb 2017 10:33:11 +1100, Vaughan McAlley
>  wrote:
>
> > Maybe your keyboard is interpreting F8 as something else rather than
> > the function key proper.
>
> It seems that lq isn't intercepting keystrokes at all. After uncommenting
> line 341 nothing is printed:
>
> $ sudo ./lq
> Password:
> Welcome to LilyQuick version 0.9β
> Press F8 and a key on the MIDI keyboard to exit.
> [1] 12613
> ^[[19~^[[19~^[[19~^[[19~^C
>
> F8 generates ^[[19~ which is just echoed.
>
> -- Johan
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

It seems a while ago, but I remember ioctl & EVIOCGRAB were difficult
to get working (though it is robust on my system now). I've tried the
other keyboard that came with my computer and it worked fine.

One possibility: LilyQuick is trying to grab the wrong keyboard
(though I'm sure you know what you are doing).

I tried to install Fedora on a spare partition, but ran into a
problem. If I succeed I'll be interested to try installing and
testing.

-Vaughan

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

Re: 13th chord?

2017-02-26 Thread mskala 
On Sun, 26 Feb 2017, Thomas Morley wrote:
> If the chordNameFunction (ignatzek-chord-names) does not do what we
> want, we should improve it, but not drop a plethora of
> lily-functionality.

I'm not proposing to "drop a plethora of lily-functionality" but only to
provide something that will be useful in the very common case of people
wanting to print chord names and wanting the output to match the input.
The proposed new feature would not be a modification of chord mode nor of
ChordNames, but a third thing separate from either of those two.  I
imagine it would make sense for most of its code to derive from the code
currently used for lyrics, but that fact would preferably NOT be visible
to users.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: 13th chord?

2017-02-26 Thread Thomas Morley 
2017-02-26 12:12 GMT+01:00 Anthony Youngman :
> On 26/02/17 10:52, Thomas Morley wrote:

>> If the chordNameFunction (ignatzek-chord-names) does not do what we
>> want, we should improve it, but not drop a plethora of
>> lily-functionality.
>>
>> And yes, ignatzek-chord-names is insufficient in the sense that it's
>> hard up to impossible to tweak ChordName-printing sufficiently without
>> rewriting major parts of it.
>>
> Just to throw another big spanner into the works ...
>
> I wrote some code which I submitted to lilypond to handle guitar capos. So,
> for example, if you said something like "\capo 3", when you entered a chord
> of C, it printed the chord name as "C(A)". This is *normal* practice when
> printing music to accompany singers - the piano score has the guitar chords
> on it.
>
> My code didn't get into lilypond proper (I was asked to make a load of
> changes, and I couldn't cope - my scheme-fu wasn't up to it), BUT. You need
> to be careful that any changes you make don't break that use case - even if
> I didn't get it in, I'm sure somebody else will want it in future.
>
> Cheers,
> Wol

Do we have a tracker-issue for it?

Cheers,
  Harm

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

Re: 13th chord?

2017-02-26 Thread Anthony Youngman 

On 26/02/17 10:52, Thomas Morley wrote:

2017-02-26 2:16 GMT+01:00  :

On Sun, 26 Feb 2017, David Kastrup wrote:

To me it would seem that the default mode of operation should be for
them to have matched rules where feasible, in order to have least
element of surprise.


I agree, but A. it may not be feasible in some important cases, and
B. even matched rules wouldn't really solve the problem, because users
would still have to explain to both the input and output systems their
own preferred conversion between note sets and displayed chord symbols.
(It doesn't help that the standard and traditional musical rules are
*screwy* and the nonstandard rules many people want to use are even
screwier.)

Users want what they type to match what is displayed, even when it doesn't
follow the default rules and possibly even when it doesn't follow any
rules.  For the common use case of chord mode being used solely to
generate notes for ChordNames, and ChordNames getting its notes solely
from chord mode, we don't really need the notes at all.  Just turning the
user's input directly into markup would make all the common problems with
chords disappear.

I've actually used lyrics to print chord names sometimes when I just
couldn't get "proper" ChordNames contexts to do what I wanted.  It seems
like lyrics are 80% of the way to the markup idea I'm describing.

--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/


I strongly disagree.

\chordmode is an input mode.
It can be used for printing notes (Staff), chord-names (ChordNames)
and fret-diagrams (FretBoards) and for midi, as David already pointed
out.

If the chordNameFunction (ignatzek-chord-names) does not do what we
want, we should improve it, but not drop a plethora of
lily-functionality.

And yes, ignatzek-chord-names is insufficient in the sense that it's
hard up to impossible to tweak ChordName-printing sufficiently without
rewriting major parts of it.


Just to throw another big spanner into the works ...

I wrote some code which I submitted to lilypond to handle guitar capos. 
So, for example, if you said something like "\capo 3", when you entered 
a chord of C, it printed the chord name as "C(A)". This is *normal* 
practice when printing music to accompany singers - the piano score has 
the guitar chords on it.


My code didn't get into lilypond proper (I was asked to make a load of 
changes, and I couldn't cope - my scheme-fu wasn't up to it), BUT. You 
need to be careful that any changes you make don't break that use case - 
even if I didn't get it in, I'm sure somebody else will want it in future.


Cheers,
Wol

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

Re: 13th chord?

2017-02-26 Thread Thomas Morley 
2017-02-26 2:16 GMT+01:00  :
> On Sun, 26 Feb 2017, David Kastrup wrote:
>> To me it would seem that the default mode of operation should be for
>> them to have matched rules where feasible, in order to have least
>> element of surprise.
>
> I agree, but A. it may not be feasible in some important cases, and
> B. even matched rules wouldn't really solve the problem, because users
> would still have to explain to both the input and output systems their
> own preferred conversion between note sets and displayed chord symbols.
> (It doesn't help that the standard and traditional musical rules are
> *screwy* and the nonstandard rules many people want to use are even
> screwier.)
>
> Users want what they type to match what is displayed, even when it doesn't
> follow the default rules and possibly even when it doesn't follow any
> rules.  For the common use case of chord mode being used solely to
> generate notes for ChordNames, and ChordNames getting its notes solely
> from chord mode, we don't really need the notes at all.  Just turning the
> user's input directly into markup would make all the common problems with
> chords disappear.
>
> I've actually used lyrics to print chord names sometimes when I just
> couldn't get "proper" ChordNames contexts to do what I wanted.  It seems
> like lyrics are 80% of the way to the markup idea I'm describing.
>
> --
> Matthew Skala
> msk...@ansuz.sooke.bc.ca People before principles.
> http://ansuz.sooke.bc.ca/

I strongly disagree.

\chordmode is an input mode.
It can be used for printing notes (Staff), chord-names (ChordNames)
and fret-diagrams (FretBoards) and for midi, as David already pointed
out.

If the chordNameFunction (ignatzek-chord-names) does not do what we
want, we should improve it, but not drop a plethora of
lily-functionality.

And yes, ignatzek-chord-names is insufficient in the sense that it's
hard up to impossible to tweak ChordName-printing sufficiently without
rewriting major parts of it.


Cheers,
  Harm

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

Re: Fermata above and below bar line generates warnings

2017-02-26 Thread Thomas Morley 
2017-02-26 2:15 GMT+01:00 Knute Snortum :
> On Sat, Feb 25, 2017 at 2:07 PM, Thomas Morley 
> wrote:
>>
>> 2017-02-25 22:42 GMT+01:00 Knute Snortum :
>> > The following code produces the correct output of fermatas above and
>> > below
>> > the bar line, but it also emits warnings.  Is there another way to do
>> > this
>> > without warnings, or can the warnings be suppressed?  I got this code
>> > from:
>> >
>> > http://lsr.di.unimi.it/LSR/Snippet?id=10
>> >
>> > \version "2.19.55"
>> >
>> > \score {
>> >   \new GrandStaff <<
>> > \context Staff = one {
>> >   c'1 \bar "|."
>> >   \override Score.RehearsalMark.break-visibility =
>> > #begin-of-line-invisible
>> >   \mark \markup { \musicglyph #"scripts.ufermata" }
>> > }
>> > \context Staff = two \with { \consists "Mark_engraver" } {
>> >   c'1
>> >   \override Staff.RehearsalMark.direction = #DOWN
>> >   \mark \markup { \musicglyph #"scripts.dfermata" }
>> > }
>> >   >>
>> > }
>> >
>> > ---
>> > Knute Snortum
>> > (via Gmail)
>>
>>
>> Hi,
>>
>> the warning happens because two different RehearsalMarks are read by
>> the Mark_engraver in Score-context, one of them is dropped, again: in
>> Score-context!!
>> But the Mark_engraver is in the Staff-context of the lower Staff as
>> well. So this engraver prints the fermata below.
>>
>> A naughty coding, not working around but using this behaviour would be:
>>
>> \version "2.19.52"
>>
>> \score {
>>   \new GrandStaff <<
>> \context Staff = one {
>>   c'1 \bar "|."
>> }
>> \context Staff = two \with { \consists "Mark_engraver" } {
>>   c'1
>>   \override Score.RehearsalMark.break-visibility =
>> #begin-of-line-invisible
>>   \override Staff.RehearsalMark.direction = #DOWN
>>   \override Staff.RehearsalMark.rotation = #'(180 0 0)
>>   \mark \markup { \musicglyph #"scripts.ufermata" }
>> }
>>   >>
>> }
>>
>>
>>
>> Cheers,
>>   Harm
>
>
> Wow, that code confuses me, I admit it!  Is the Mark_engraver printing the
> upper *and* lower fermata in context "two"?

Be aware there are two(!) Mark_engravers present.
One in score, the default.
And the second in the lower Staff.

The Score-Mark_engraver prints the RehearsalMark as usual above the
topmost Staff

<<
  \new Staff { c'1 }
  \new Staff {
c'1
\override Score.RehearsalMark.break-visibility = ##(#t #f #f)
\mark "X"
  }
>>

Any override for RehearsalMark in _Staff_-context will do nothing.

<<
  \new Staff { c'1 }
  \new Staff {
c'1
\override Score.RehearsalMark.break-visibility = ##(#t #f #f)
\override Staff.RehearsalMark.color = #red
\mark "X"
  }
>>

So far the default.

Adding the Mark_engraver to the lower _Staff_ will print he
RehearsalMark again, but at Staff-level.

<<
  \new Staff { c'1 }
  \new Staff \with { \consists "Mark_engraver" } {
c'1
\override Score.RehearsalMark.break-visibility = ##(#t #f #f)
\mark "X"
  }
>>

Now you can override the appearance of the Staff-level-RehearsalMark
_without_ disturbing the Score-level-RehearsalMark.

Other example:

<<
  \new Staff { c'1 }
  \new Staff \with { \consists "Mark_engraver" } {
c'1
\override Score.RehearsalMark.break-visibility = ##(#t #f #f)
\override Staff.RehearsalMark.direction = #DOWN
\override Staff.RehearsalMark.stencil =
#(lambda (grob) (grob-interpret-markup grob "I'm below"))
\mark "I'm above"
  }
>>

Cheers,
  Harm

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