A tricky example -- polyMETER against polyRHYTHM

[mclaren]

Took some skull sweat to figure this one out. But someone may get a kick out
of it. 
What I wanted to do was to set up two polymeters (different accent patterns)
with a shifting polymeter against 'em. 
Here's a png image of the score: http://i.imgur.com/RtYUgRR.png
  

Here's the Lilypond code:

\version "2.18.2"
\header { 
  tagline = ""  % removed 
} 
% Lilypond bug #1 -- placing the \paper command anywhere else fails to
%  produce the desired output, but placing it here generates an EXITED WITH
%  ERROR CODE 1 message even though the score output looks correct and is
%  as desired.

\layout {

   \paper  {#(set-default-paper-size "a4" 'landscape)}
indent=0

   \context {
\Score
\accepts "TimeLine"
\remove "Timing_translator"
\remove "Default_bar_line_engraver"
   
  }
  \context {
\Staff
\consists "Timing_translator"
\consists "Default_bar_line_engraver"
\consists "Time_signature_engraver"
  }
  
  % End of code.
}

{
  
  
<<


\new Staff { \clef "treble"
 \relative c'''
 
{


\time 9/8  
 { c8-> d f e-> b c d16-> f e8  b} 
\time 8/8
 {c8[-> d16 f e8 b] c16[-> d f8 e b]}
\time 9/8
{ c8[-> d f] e[-> b16 c d8] f[-> e b16 c]}
\time 8/8
{e8[-> b16 c d8 f] e[-> b16 c d8 f]}
 
 
\time 9/8  
 { d8-> b c a-> b g e16-> f g8  d} 
\time 8/8
 {c8[-> d16 f e8 f] e16[-> g a8 b a]}
\time 9/8
{ g8[-> f d'] e[-> g16 c, d8] g,[-> a b16 c]}
\time 8/8
{a8[-> b16 c d8 e] g[-> f16 e f8 d]} 
 
 
}  
}



\new Staff { \clef "treble"
 \relative c'
  
{
\time 8/8
{e8[-> b c d16 f] e8[-> b c d16 f]}
\time 9/8
{e8[-> b c16 d] f8[-> e b] c[-> d f]}
\time 8/8
{e8[-> b16 c d8 f] e[-> b16 c d8 f]}
\time 9/8
{ e16[-> b c8 d] f[-> e b] c[-> d f16 e]}



}
\relative c'
{

\time 8/8
{e8[-> b c d16 f] e8[-> b c d16 f]}
\time 9/8
{g8[-> a c16 d] e8[-> a, b] g[-> b c]}
\time 8/8
{b8[-> c16 a d8 g] f[-> c16 b a8 f]}
\time 9/8
{ e16[-> b c8 d] f[-> e b] c[-> d f16 e]}



}

}


\new Staff { \clef "bass"
 \relative c
{

 
 \time 11/8
 \once \omit TupletNumber
  \set Timing.measureLength = #(ly:make-moment 8/8)
\tuplet 11/8 {  g8[->  e' b c d f e b16 c d8 f e]}
%\scaleDurations 8/11 {  f8[->  e b c d f e b16 c d8 f e]}
|
\override TupletNumber #'text = #tuplet-number::calc-fraction-text
\set Timing.measureLength = #(ly:make-moment 9/8)
\tuplet 11/9 {  b16[-> c d8 f e16 b c8 d f e d f g]}
 

|
\once \omit TupletNumber
\set Timing.measureLength = #(ly:make-moment 8/8)
\tuplet 11/8 {  f8[->  e b c d f e b16 c d8 f e]}
\override TupletNumber #'text = #tuplet-number::calc-fraction-text

\set Timing.measureLength = #(ly:make-moment 9/8)
\tuplet 11/9 {  e8[-> b c d16 f e8 b c d16 f e8 b c16 d]}
\bar "|"
\break 

\time 11/8
 \once \omit TupletNumber
 \set Timing.measureLength = #(ly:make-moment 8/8)
\tuplet 11/8 {  c8[->  b d b a g f c16 b e8 g f]}
%\scaleDurations 8/11 {  f8[->  e b c d f e b16 c d8 f e]}
|
\override TupletNumber #'text = #tuplet-number::calc-fraction-text
\set Timing.measureLength = #(ly:make-moment 9/8)
\tuplet 11/9 {  e16[-> c e8 d a'16 b c8 e g f a g b]}
 
%\scaleDurations 11/8 {  b16[-> c d8 f e16 b c8 d f e d f g]}
|
\once \omit TupletNumber
\set Timing.measureLength = #(ly:make-moment 8/8)
\tuplet 11/8 {  c8[->  e, a f g f e c16 d b8 c g]}
\override TupletNumber #'text = #tuplet-number::calc-fraction-text
\set Timing.measureLength = #(ly:make-moment 9/8)
\tuplet 11/9 {  e8[-> b c d16 f e8 b c d16 f e8 b c16 d]}
\bar "|"
\break 
}

}
>>
 
}

===

  Incidentally, I seem to be getting a bug, and it's an odd one. If you try
to compile this Lilypond score from scratch, you get an exit with ERROR=1.
Then if you comment out the lines

\layout {

   \paper  {#(set-default-paper-size "a4" 'landscape)}
indent=0

  and recompile, the score runs fine. Here's where it gets weird... If you
then immediately uncomment out those 3 lines, you still get an exit with
ERROR=1, but this time the score gets engraved properly in landscape mode.

   Can't figure this one out. What am I doing wrong with setting landscape
mode?



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/A-tricky-example-polyMETER-against-polyRHYTHM-tp196030.html
Sent from the User mailing list archive at Nabble.com.

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

RE: Follow-up: organ pedal toe-to-heel shift

[Andrew Bernard]

Hi Joe,

 

A Baroque player myself, we only use toes. :)

 

This? [It's easy to see how to invert the symbols - I was not sure which way
up you want.]

 

Andrew

 

=== snip

 

\version "2.19.49"

 

#(define-markup-command (pedal-sub layout props)()

 (interpret-markup layout props

   #{

 \markup {

   \fontsize #-3

   \concat

   \vcenter {

 \musicglyph #"scripts.upedaltoe" "-" \hspace #0.1 \musicglyph
#"scripts.upedalheel"

   }

}

   #}))

 

pedalSub =

#(define-scheme-function ()()

   #{ \markup \pedal-sub #})

 

{

  c''^\pedalSub

  c''_\pedalSub

  \voiceOne c''-\pedalSub

 

== snip

 

 

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

Re: compound time signature with non duple denominator

[David Wright]

On Wed 02 Nov 2016 at 22:13:54 (+0100), Hans Åberg wrote:
> 
> > On 2 Nov 2016, at 21:08, David Wright  wrote:
> > 
> > On Wed 02 Nov 2016 at 20:10:39 (+0100), Hans Åberg wrote:
> >> 
> >>> On 28 Oct 2016, at 21:48, David Wright  wrote:
> >>> 
> >>> On Fri 28 Oct 2016 at 11:22:00 (-0700), Tobin Chodos wrote:
>  Forgive me if this is a too-easy issue for the list, but: is there a way 
>  to
>  define a time compound time signature such as 4/4 + 1/3?  That is, the
>  measure is four quarter notes long plus one triplet eighth note.
> >>> 
> >>> Isn't this just 13/8? Three triplet eighth notes make a quarter note.
> >>> So it's 3+3+3+3+1 all over 8, and the notes will be written out as
> >>> four dotted quarter notes and an eighth note per measure.
> >> 
> >> Indeed, 12/8 may be complicated notationally if the beats of length 3/8 
> >> are divided into twos and fours, so 4/4 might be preferred.
> > 
> > Now that would be interesting. Are the last three notes of the first
> > bar realistically performable? OTOH splitting the long notes into
> > threes would be straightforward to perform (and to write in 13/8).
> 
> It is, if the tempo is not too high, and one devices a method for counting.
> 
> > The only 13/8 I can recall off-hand is an uncomplicated 6/4+1/8.
> 
> At moderato, 1/4 = 120, 13/16 is performable counting on 2s and 3s. One 
> example is Krivo Sadovsko horo (Bulgaria), 13 = 4+5+4, 4=2+2, 5 = 2+3:
>   https://www.youtube.com/watch?v=3jCuUWnwM28
> Another is Ispayche horo, 13 = 3+2+3+2+3
>   https://www.youtube.com/watch?v=tbU2za0rbzs
> 
> At higher tempo, one may need to count on 3s, 4s, and 5s, especially when 
> clapping hands:
>   https://www.youtube.com/watch?v=aecsGYwtVJM
> This is a Leventikos, in video video, it is in 16 = 4+2+3+4+3, but the clap 
> hands 4+5+4+3.
>   https://en.wikipedia.org/wiki/Leventikos

Correct me if I'm wrong (I'm not familiar with these dances), but
these are just groupings of steady 16th notes, are they not.
My example wasn't.

> This Leventikos is also performed in 12 = 3+2+2+3+2, with quadruplets on the 
> 3s - se my other post in this thread.

OK, the quadruplets add another layer of complexity. The note
durations are now 3+3+3+3+ 4+4+ 4+4+ 3+3+3+3+ 4+4 / 48.
So taking this Leventikos pattern, I've bent the "4/4+1/3" so
that it contains similar tupleticity, to coin a nonce word.

I've broken the 13/8 time signature into the appropriate groups,
3/8+3/8+3/8+3/8+1/8. I've followed this with the 4/4/+1/12
time signature's equivalent notation for the same durations.
The actual rhythm of the individual notes in both cases is
4+4+4+ 3+3+3+3+ 4+4+4+ 3+3+3+3+ 4 / 52.

At the bottom are the versions with undivided notes, with
the 1/12 notes represented in the only way I can think of.

One interesting thing that popped out of my 3/8 notation is
that the odd quaver at the end of each bar can be linked to
the three quavers in the next bar. The upshot is that the
overall rhythm is a repeated (4-slow 4-fast 3-slow 4-fast).

The same rhythm is contained in the 4/4+1/12 notation, but
is it easy to spot? You could make it obvious by writing
   4:2⅔
┌———┐ over it, and leave people to ponder whether its
speed is the same as the triplet's. Lets' see, 2⅔ is 8/3
so 4:(8/3) is 4*3:8 is 12:8 is 3:2. Success.

Having that 1/8 quaver sitting next to the other three makes
the rhythm quite friendly. If the first beat of the bar is
an undivided dotted crochet, that last quaver is much
harder to time correctly. Of course, we have no idea what
the OP wanted to set to their "4/4+1/3" signature, how it
would be divided etc.

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

Can't login to lists.gnu..

[kmg]

Hey guys, rather unusual stuff happening..

I want to edit my list options (don't want every new thread into my
mailbox). I have my password cached in the browser and I'm getting
'authentication failed' error every time I try to login. When trying to
reset password, I'm getting info that it should be sent if I'm the list
user.. but yea, no mail about the password, checked the spam folder too.
Also tried to unsubscribe, and strangely it doesn't work. It's not possible
that if I'm really unsubbed, I'm getting messages, right?

So, is there a chance that someone could mail me new password? Not sure
what to do.

Thanks and sorry for trouble,

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

Follow-up: organ pedal toe-to-heel shift

[Joseph N. Srednicki]

Please see the original message on this subject:
http://osdir.com/ml/lilypond-user-gnu/2016-05/msg00210.html

 

Can someone please tell me how to modify the attached code so that right
toe-to-heel shift marks are not upside down? For example, the left
toe-to-heel shift appears as desired below the note; however, the right
toe-to-heel shift appears above the note as: v-u. 

 

In other words, I would like the right toe-to-heel shift to be the same as
the left toe-to-heel shift (both -) with one difference:
the right-to-heel shift appears above the note, and the left toe-to-heel
shift appears below the note. 

 

I have pasted the code in the message below.

 

If the answer is already in the email archive, I apologize for overlooking
it and would appreciate someone sending a link.

 

Thanks to anyone who can provide an answer. I am attaching the code below.

 

Joe Srednicki

 

==

\version "2.19.49"

 

#(define-markup-command (pedal-sub layout props)()

(let* ((dir (chain-assoc-get 'direction props))

(ped-toe (format #f "scripts.~apedaltoe" (if (> dir 0) "u" "d")))

(ped-heel (format #f "scripts.~apedalheel" (if (> dir 0) "u" "d"

(interpret-markup layout props

#{

\markup {

\fontsize #-3

\concat

\vcenter {

\musicglyph #ped-toe "-" \hspace #0.1 \musicglyph #ped-heel

}

}

#})))

 

pedalSub =

#(define-scheme-function ()()

#{ \markup \pedal-sub #})

 

{

c''^\pedalSub

c''_\pedalSub

\voiceOne c''-\pedalSub

\voiceTwo c''-\pedalSub

}

 

 

 

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

Re: Changing voice order...

[tisimst]

On Wed, Nov 2, 2016 at 4:00 PM, Thomas Morley-2 [via Lilypond] <
ml-node+s1069038n196021...@n5.nabble.com> wrote:

> 2016-11-02 13:04 GMT+01:00 Werner LEMBERG <[hidden email]
> >:
>
> >>>   \voiceOrder { 1, 3, 5, 7, 6, 4, 2 }
> >>>   << c'''2 \\ g'' \\ e'' \\ c'' \\ g' \\ e' \\ c' >>
> >>
> >> More like \voices 1,3,5,7,6,4,2 << ... >> if we want to keep in
> >> current syntax.  This is assuming a one-shot command taking the <<
> >> >> construct as its last argument.
> >
> > Hmm, my original idea was a global command, something similar to
> > setting up beam divisions for various meters – having a command to
> > locally override that would be certainly useful.
> >
> >>> Note that this is an idea without considering whether it can be
> >>> implemented at all.
> >>
> >> With a bit of massage it seems to work.
> >
> > Good to hear!
> >
> >
> > Werner
> Werner,
>
> I was thrilled and excited by your proposal.
> Having had some leisure time this afternoon (although without
> net-access) I played around with it.
> I've taken it as a local command, though.
>
> The result is a wrapper around simultaneous music, with and without "\\".
> You can input straight away from top to bottom voice.
> The voiceXxx-settings and context-ids are done automatically, but
> respect user-settings.
>
> The engraver to annotate info is in as well, could be deleted ofcourse.
>
> It's not tested beyond the given examples, but following this route
> would make the input much more logical and because it's a wrapper we
> would warrant backward compatibility, no need to change anything
> else...
>
> Opinions?
>

Thanks, Harm! That is seriously cool. Now to do some real-world tests to
understand the implications... I really need to get better at Scheme
programming. There is so much I'd like to do.

--
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Changing-voice-order-tp195757p196024.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing voice order...

[Thomas Morley]

2016-11-02 13:04 GMT+01:00 Werner LEMBERG :
>>>   \voiceOrder { 1, 3, 5, 7, 6, 4, 2 }
>>>   << c'''2 \\ g'' \\ e'' \\ c'' \\ g' \\ e' \\ c' >>
>>
>> More like \voices 1,3,5,7,6,4,2 << ... >> if we want to keep in
>> current syntax.  This is assuming a one-shot command taking the <<
>> >> construct as its last argument.
>
> Hmm, my original idea was a global command, something similar to
> setting up beam divisions for various meters – having a command to
> locally override that would be certainly useful.
>
>>> Note that this is an idea without considering whether it can be
>>> implemented at all.
>>
>> With a bit of massage it seems to work.
>
> Good to hear!
>
>
> Werner

Werner,

I was thrilled and excited by your proposal.
Having had some leisure time this afternoon (although without
net-access) I played around with it.
I've taken it as a local command, though.

The result is a wrapper around simultaneous music, with and without "\\".
You can input straight away from top to bottom voice.
The voiceXxx-settings and context-ids are done automatically, but
respect user-settings.

The engraver to annotate info is in as well, could be deleted ofcourse.

It's not tested beyond the given examples, but following this route
would make the input much more logical and because it's a wrapper we
would warrant backward compatibility, no need to change anything
else...

Opinions?


Cheers,
  Harm


atest-46.ly
Description: application/download


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

Re: compound time signature with non duple denominator

[Hans Åberg]

> On 2 Nov 2016, at 21:08, David Wright  wrote:
> 
> On Wed 02 Nov 2016 at 20:10:39 (+0100), Hans Åberg wrote:
>> 
>>> On 28 Oct 2016, at 21:48, David Wright  wrote:
>>> 
>>> On Fri 28 Oct 2016 at 11:22:00 (-0700), Tobin Chodos wrote:
 Forgive me if this is a too-easy issue for the list, but: is there a way to
 define a time compound time signature such as 4/4 + 1/3?  That is, the
 measure is four quarter notes long plus one triplet eighth note.
>>> 
>>> Isn't this just 13/8? Three triplet eighth notes make a quarter note.
>>> So it's 3+3+3+3+1 all over 8, and the notes will be written out as
>>> four dotted quarter notes and an eighth note per measure.
>> 
>> Indeed, 12/8 may be complicated notationally if the beats of length 3/8 are 
>> divided into twos and fours, so 4/4 might be preferred.
> 
> Now that would be interesting. Are the last three notes of the first
> bar realistically performable? OTOH splitting the long notes into
> threes would be straightforward to perform (and to write in 13/8).

It is, if the tempo is not too high, and one devices a method for counting.

> The only 13/8 I can recall off-hand is an uncomplicated 6/4+1/8.

At moderato, 1/4 = 120, 13/16 is performable counting on 2s and 3s. One example 
is Krivo Sadovsko horo (Bulgaria), 13 = 4+5+4, 4=2+2, 5 = 2+3:
  https://www.youtube.com/watch?v=3jCuUWnwM28
Another is Ispayche horo, 13 = 3+2+3+2+3
  https://www.youtube.com/watch?v=tbU2za0rbzs

At higher tempo, one may need to count on 3s, 4s, and 5s, especially when 
clapping hands:
  https://www.youtube.com/watch?v=aecsGYwtVJM
This is a Leventikos, in video video, it is in 16 = 4+2+3+4+3, but the clap 
hands 4+5+4+3.
  https://en.wikipedia.org/wiki/Leventikos
This Leventikos is also performed in 12 = 3+2+2+3+2, with quadruplets on the 3s 
- se my other post in this thread.


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

Re: compound time signature with non duple denominator

[David Wright]

On Wed 02 Nov 2016 at 20:10:39 (+0100), Hans Åberg wrote:
> 
> > On 28 Oct 2016, at 21:48, David Wright  wrote:
> > 
> > On Fri 28 Oct 2016 at 11:22:00 (-0700), Tobin Chodos wrote:
> >> Forgive me if this is a too-easy issue for the list, but: is there a way to
> >> define a time compound time signature such as 4/4 + 1/3?  That is, the
> >> measure is four quarter notes long plus one triplet eighth note.
> > 
> > Isn't this just 13/8? Three triplet eighth notes make a quarter note.
> > So it's 3+3+3+3+1 all over 8, and the notes will be written out as
> > four dotted quarter notes and an eighth note per measure.
> 
> Indeed, 12/8 may be complicated notationally if the beats of length 3/8 are 
> divided into twos and fours, so 4/4 might be preferred.

Now that would be interesting. Are the last three notes of the first
bar realistically performable? OTOH splitting the long notes into
threes would be straightforward to perform (and to write in 13/8).

The only 13/8 I can recall off-hand is an uncomplicated 6/4+1/8.

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

Re: compound time signature with non duple denominator

[Hans Åberg]

> On 2 Nov 2016, at 19:02, tisimst  wrote:
> 
> ... as Kieren and I saw on a facebook group the other day when a composer 
> started a discussion about having a bar with an "irrational" 2/6 time 
> signature. Wow, the flames that ensued! It's quite simple:
> 
> { \time 2/6 \tuplet 3/2 { c'4 c' } }
> 
> ... with or without the tuplet number/bracket.

I gave an example of a true irrational time signature [1]. The code is actually 
written in 12/8 (with a MIDI approximation in 19/8). In 12/8, as both the 3/8s 
and the 2/8s are divided into four parts, tuplets will remain. 

1. https://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00237.html



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

Re: compound time signature with non duple denominator

[Hans Åberg]

> On 28 Oct 2016, at 21:48, David Wright  wrote:
> 
> On Fri 28 Oct 2016 at 11:22:00 (-0700), Tobin Chodos wrote:
>> Forgive me if this is a too-easy issue for the list, but: is there a way to
>> define a time compound time signature such as 4/4 + 1/3?  That is, the
>> measure is four quarter notes long plus one triplet eighth note.
> 
> Isn't this just 13/8? Three triplet eighth notes make a quarter note.
> So it's 3+3+3+3+1 all over 8, and the notes will be written out as
> four dotted quarter notes and an eighth note per measure.

Indeed, 12/8 may be complicated notationally if the beats of length 3/8 are 
divided into twos and fours, so 4/4 might be preferred.



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

Re: compound time signature with non duple denominator

[Chris Yate]

On Wed, 2 Nov 2016 at 18:03 tisimst  wrote:

> On Wed, Nov 2, 2016 at 10:55 AM, Kieren MacMillan [via Lilypond] <[hidden
> email] > wrote:
>
> It's *legitimate* in all musical circles, though it's not *embraced* by
> all.
>
> ... as Kieren and I saw on a facebook group the other day when a composer
> started a discussion about having a bar with an "irrational" 2/6 time
> signature. Wow, the flames that ensued! It's quite simple:
>
> { \time 2/6 \tuplet 3/2 { c'4 c' } }
>
> ... with or without the tuplet number/bracket.
>
> -
> Abraham
>

Like so many things in life and art, just because you *can* doesn't mean
you *should* ;-)

Luckily, in Lilypond you *can* :-D

Given almost any rhythm could be expressed without the use of silly time
signatures (possibly by eliminating bar lines for a short section, or maybe
writing extra bars*). It makes sense to make life easy for your players,
rather than show off just how clever you are.

I've very occasionally had to play a bar or two of 4/3, and it
unnecessarily complicates something that's already difficult; particularly
as it utterly confuses those players that don't know how to parse it.

Chris

* yes, it could be difficult to write the same bar lines for all players.
Better I think to write partial bar lines and readable rhythms. The same
argument stands for ridiculous key signatures, whether an explicit key sig,
or written as something like a scale of F double-sharp
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: compound time signature with non duple denominator

[tisimst]

On Wed, Nov 2, 2016 at 10:55 AM, Kieren MacMillan [via Lilypond] <
ml-node+s1069038n196008...@n5.nabble.com> wrote:

> It's *legitimate* in all musical circles, though it's not *embraced* by
> all.
>
... as Kieren and I saw on a facebook group the other day when a composer
started a discussion about having a bar with an "irrational" 2/6 time
signature. Wow, the flames that ensued! It's quite simple:

{ \time 2/6 \tuplet 3/2 { c'4 c' } }

... with or without the tuplet number/bracket.

--
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/compound-time-signature-with-non-duple-denominator-tp195829p196012.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: compound time signature with non duple denominator

[David Kastrup]

David Wright  writes:

> On Wed 02 Nov 2016 at 12:49:07 (-0400), kieren_macmillan kieren_macmillan 
> wrote:
> 
>
> I guess I had expected a reference/url/scan rather than "yes".

Zere is some music notation zat makes me 'url.

-- 
David Kastrup

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

Re: compound time signature with non duple denominator

[David Wright]

On Wed 02 Nov 2016 at 12:49:07 (-0400), kieren_macmillan kieren_macmillan wrote:


I guess I had expected a reference/url/scan rather than "yes".
I realise that all sorts of "odd" notations were around in
preclassical times, But wouldn't claim to understand them.

Does the example I've given correctly express the required
relationship between the notes' durations (which is kind of what we
expect with modern music notation).

Say I write 9/6 at the start of a staff. Which glyph do I pick out of
appendix A of the NR manual to follow it with?

Cheers,
David.

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

Re: Exited with return code -1073741819.

[David Wright]

On Wed 02 Nov 2016 at 07:44:29 (+1100), Andrew Bernard wrote:
> I am not sure for whom you mean error prone - the user, or the compiler.

The user. Constructions like   seq 1 10   (eg, in bash) are designed
to avoid the need for   1 2 3 4 5 6 7 8 9 10. Computers are good at
this, humans aren't. We slip up. Compilers don't.

> It seems like after many many repetitions of the variable constructs
> representing each bar lilypond just loses the plot and runs out of
> resources. It's probably a really obscure bug. It's a use case hardly worth
> testing, it being so unusual.

That may well be the problem, but it ought to detect the fact and say so.

> I could not see what the fixes were from your email David, unless I am
> missing an attachment. What did you do to make this work?

Three or four global replacements for the RHS variables,
a few copy to fill in the "borrowed" parts like \expandVar \sop 23 38
then a macro to erase the LHS variables and their = sign.
I left the redundant braces around each bar.

> -Original Message-
> From: David Wright 
> Subject: Re: Exited with return code -1073741819.
> 
> Well, the reasons were given in
> http://lists.gnu.org/archive/html/lilypond-user/2016-03/msg00609.html
> but I can't see that a construction like
> 
> sop.12 = \sop.1
> sop.13 = \sop.1
> sop.14 = \sop.1
> sop.15 = \sop.1
> sop.16 = \sop.5
> sop.17 = \sop.1
> sop.18 = \sop.1
> sop.19 = \sop.1
> sop.20 = \sop.1
> sop.21 = \sop.5
> 
> is any less error-prone than
> 
> R1 * 5 \break
> R1 * 5 \break
> 
> nor can I imagine that it involves any less copy, unless all the sop
> sop sop stuff was actually typed in. At least the source is not obfuscated,
> which it was last time.

Cheers,
David.
\version "2.19.49"
\language "english"
expandVar =
#(define-music-function (xx start stop) (list? index? index?)
   #{ #@(map (lambda (i) #{ $xx . #i #}) (iota (- stop start -1) start)) #})

\header {
  title = "能否於今天"
  subtitle = "Could This Be The Day?"
  composer = "Joseph M. Martin"
  arranger = "編 : 劉永生"
  poet = "詞 : 劉永生"
}

\layout {
  \context {
\Voice
\consists "Melody_engraver"
\override Stem #'neutral-direction = #'()
  }
}

global = {
  \key f \major
  \numericTimeSignature
  \time 4/4
  \tempo "Freely" 4=104
}

soprano = {
  \global
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 | \break }
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 | \break }
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 | \break }
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 | \break }
 { d'4^\markup"Tenderly"^\markup"S.A." a'4 4 4 |}
 { a'1 |}
 { c'4 g'4 4 4 |}
 { g'2( f'2) |\break }
 { d'4 a'4 4 b' |}
 { c''2 d''4 c''4 |}
 { b'4 c'' b' g' |}
 { a'1 |\break }
 { d'4 a'4 4 4 |}
 { a'1 |}
 { c'4 g'4 4 4 |}
 { g'2( f') |\break }
 { f'4 d''4 4 4 |}
 { c''4. f'8 4 a' |}
 { bf'4 a' g' f' |}
 { a'1~ |}
 { a'1 |\break }
 { a'2 4 4 |}
 { g'2 2 |}
 { bf'2 4 4 |}
 { a'2 2 |\break }
 { d''2 4 4 |}
 { c''2 a'4 c'' |}
 { c''2 bf'4 4 |}
 { a'1 |\break }
 { g'2 4 a' |}
 { bf'4 a' g' bf' |}
 { a'1 |}
 { a'2 2 |\break }
 { d'1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 | \break }
 { c'4 f' a' c'' |}
 { c''2 r2 |}
 { r4 e'8 8 f'4( g') |}
 { a'2~ 2 |\break }
 { r2 f'8( g') a'( c'') |}
 { d''4( c'' b' g') |}
 { a'1 |}
 { d'4 a'4 4 4 |\break }
 { a'1 |}
 { c'4 g'4 4 4 |}
 { g'2( f'2) |}
 { f'4 d''4 4 4 |\break }
 { c''4. f'8 4 a' |}
 { bf'4 a' g' f' |}
 { a'1~ |}
 { a'1 |}
 { a'2 4 4 |\break }
 { g'2 2 |}
 { bf'2 4 4 |}
 { a'2 2 |}
 { d''2 4 4 |\break }
 { c''2 a'4 c'' |}
 { c''2 bf'4 4 |}
 { a'1 |}
 { g'2 4 a' |\break }
 { bf'4 a' g' bf' |}
 { a'1 |}
 { a'2 2 |}
 { d'1 |}
 { R1 | \break }
 { d'4 a'4 4 4 |}
 { a'2( g') |}
 { R1 |}
 { R1 |}
 { d'4 a'4 4 4 |\break }
 { c''4 bf'8( a') g'2 |}
 { bf'4 a'8 g' f'2 |}
 { a'4 g'8( f') e'4 f'8 e' |}
 { d'1 |\break }
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { a'1 |}
 { a'1 |\bar"|." }
}

alto =  {
  \global
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { d'4 a'4 4 4 |}
 { a'1 |}
 { c'4 g'4 4 4 |}
 { g'2( f'2) |\break }
 { d'4 a'4 4 b' |}
 { c''2 d''4 c''4 |}
 { b'4 c'' b' g' |}
 { a'1 |\break }
 { d'4 a'4 4 4 |}
 { a'1 |}
 { c'4 g'4 4 4 |}
 { g'2( f') |\break }
 { f'4 d''4 4 4 |}
 { c''4. f'8 4 a' |}
 { bf'4 a' g' f' |}
 { a'1~ |}
 { a'1 |\break }
 { f'2 4 4 |}
 { f'2 e' |}
 { g'2 4 4 |}
 { g'2 f' |}
 { f'2 4 g' |}
 { g'4( f') 4 4 |}
 { e'2 4 4 |}
 { e'2( d') |}
 { ef'2 4 f' |}
 { g'4 f' ef' g' |}
 { f'1 |}
 { e'!2 2 |}
 { d'1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { R1 |}
 { c'4 f' a' c'' |}
 { c''2 r2 |}
 { r4 e'8 8 f'4( g') |}
 { a'2~ 2 |\break }
 { r2 f'8( g') a'( c'') |}
 { d''4( c'' b' g') |}
 { a'1 |}
 { d'4 a'4 4 4 |\break }
 { a'1 |}
 { c'4 g'4 4 4 |}
 { g'2( f'2) |}
 { f'4 bf'4 4 4 |}
 { a'4. f'8 4 a' |}
 { bf'4 a' g' f' |}
 { a'1~ |}
 { a'1 |}
 { f'2 4 4 |}
 { f'2 e' |}
 { g'2 4 4 |}
 { g'2 f' |}
 { f'2 4 g' |}
 { g'4( f') 4 4 |}
 { e'2 4 4 |}
 { e'2( d') |}
 { ef'2 4 f' |}
 { 

Re: compound time signature with non duple denominator

[kieren_macmillan kieren_macmillan]

 
  Hi David,
  It's *legitimate* in all musical circles, though it's not *embraced* by all.
  Cheers,Kieren.
  
   -- Original Message --From: David Wright Date: November 2, 2016 at 12:45 PMOn Fri 28 Oct 2016 at 21:13:57 (+0200), Noeck wrote:> > Forgive me if this is a too-easy issue for the list, but: is there a way> > to define a time compound time signature such as 4/4 + 1/3? That is,> > the measure is four quarter notes long plus one triplet eighth note.> > this is definitely a valid question for this list!> This snippet will help you, I guess:> http://lsr.di.unimi.it/LSR/Item?id=743> > However the additional 1/3 is the length of a triplet half note:> 1/3 = 1/2 * 2/3> > \version "2.19.36"> > \relative c' {> \compoundMeter #'((4 4) (1 3))> a4 a a a \tuplet 3/2 { a2 | a a }> }> > For a 4/4 measure plus a triplet 8th note, you would need 1/12 if I am> not mistaken:> > \relative c' {> \compoundMeter #'((4 4) (1 12))> a4 a a a \tuplet 3/2 { a8 | a a }> }So is this legitimate notation in some circles nowadays?Cheers,David.___lilypond-user mailing listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
  
 


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

Re: compound time signature with non duple denominator

[David Wright]

On Fri 28 Oct 2016 at 21:13:57 (+0200), Noeck wrote:
> > Forgive me if this is a too-easy issue for the list, but: is there a way
> > to define a time compound time signature such as 4/4 + 1/3?  That is,
> > the measure is four quarter notes long plus one triplet eighth note.
> 
> this is definitely a valid question for this list!
> This snippet will help you, I guess:
> http://lsr.di.unimi.it/LSR/Item?id=743
> 
> However the additional 1/3 is the length of a triplet half note:
> 1/3 = 1/2 * 2/3
> 
> \version "2.19.36"
> 
> \relative c' {
>   \compoundMeter #'((4 4) (1 3))
>   a4 a a a \tuplet 3/2 { a2 | a a }
> }
> 
> For a 4/4 measure plus a triplet 8th note, you would need 1/12 if I am
> not mistaken:
> 
> \relative c' {
>   \compoundMeter #'((4 4) (1 12))
>   a4 a a a \tuplet 3/2 { a8 | a a }
> }

So is this legitimate notation in some circles nowadays?

Cheers,
David.
\relative c' {
  \compoundMeter #'((4 4) (1 12))
  a4 a a a \tuplet 3/2 { a8 | } a4 a a a \tuplet 3/2 { a8 | }
}

\relative c' {
  \time 13/8
  a4. a a a a8 | a4. a a a a8 |
}


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

Re: Question for a FLOSS licensing session

[David Kastrup]

Wols Lists  writes:

> On 02/11/16 15:14, David Kastrup wrote:
>
>> Wrong.  Your duty is to license the whole work you distribute under the
>> terms of the GPL, with due notices attached and the licensing obvious to
>> the downstream recipient.  If you fail to do so, you are in violation of
>> the license you received LilyPond under and can be sued to cease and
>> desist distribution by one of the original copyright holders.
>> 
>> This is not rocket science.
>
> Where does it tell me I have to licence *MY* code as GPL (if I
> distribute it as source)?

  5. Conveying Modified Source Versions.

  You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:

[...]
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy.  This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged.  This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.

> Umm ... I've just read v3 Section 5, and I don't think that's legally
> enforceable! It's claiming rights over non-derivative works!

Sigh.  It is giving you the right of producing and distributing
derivative works as long as you adhere to certain conditions.  If you
don't adhere to those conditions, your right to the original program is
constrained to whatever rights your jurisdiction gives you by default to
the content of legally obtained copies of software.

> "or the modifications to produce it from the Program" - if it doesn't
> actually contain any code lifted from the program then *that* is *not* a
> derivative work!

Good luck trying that argument in court for something that relies on the
original program to make any sense.

>> Not even reading the original is not contributing to knowledge,
>> "Wissenschaft" or science.
>> 
>> The GPL is short.  There just is no necessity to spread one's ideas what
>> might or should have been in it instead of actually taking a look.
>> 
>> It's mentioned right in the preamble:
>> 
>>   For example, if you distribute copies of such a program, whether
>> gratis or for a fee, you must pass on to the recipients the same
>> freedoms that you received.  You must make sure that they, too, receive
>> or can get the source code.  And you must show them these terms so they
>> know their rights.
>
> Firstly, the preamble is not legally binding.

Correct.  But if you cannot be bothered reading the text of the license,
how about at least acquiring a basic clue of what it contains?  That's
what the preamble is for.

> And secondly, how does distributing AS SOURCE take away any of those
> rights?

I recommend that you reread section 5c.  It spells out _your_
obligations for redistribution.  It doesn't matter what you think should
be sufficient for heeding the handwavy spirit of Free Software.  What
matters is what is written in the license.

This is not rocket science.

> I must admit, you've made me think, but I think the GPL v3 is playing
> "fast and loose" with the definition of a derivative work.

The GPL is doing absolutely no such thing.  What constitutes a
"derivative work" depends on the jurisdiction in question.  The GPL has
no influence on that.  It only spells out the conditions that it makes
on modification and distribution _when_ the lawful definition of
"derivative work" happens to apply.  If it doesn't, the GPL can and does
not apply since it is a license and not a contract and thus cannot
restrict you from any activity you would be allowed to do in its
absence.

> If I take source repository, and ADD CODE, and then distribute that AS
> SOURCE, I'm pretty certain my additions will, legally, fall under
> "mere aggregation".

That's only the case for independent stuff, like assembling a
distribution of independent software.  Adding internal components to an
application is basically never "mere aggregation".  There must be very
explicit interfaces and/or explicit legal permissions before anything
like that is even remotely tenable to survive in court.

-- 
David Kastrup

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

Re: Changing voice order...

[tisimst]

On Wed, Nov 2, 2016 at 7:49 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n195993...@n5.nabble.com> wrote:

> > By the way, the top position with 369 double backslashes is this piece:
> > https://github.com/MutopiaProject/MutopiaProject/
> blob/master/ftp/BachJS/BWV830/BWV-830/BWV-830-lys/BWV-830.ly
>
> This particular one is... horrific.
>

Wow. Amen to that.


> One thing that is obvious that \relative pitch is a real mess to keep
> track of in this kind of highest/lowest/high/low scheme.  It works quite
> more natural in high-to-low stackings.
>

Like I said before, I personally have no qualms with the format of the
current << \\ \\ \\ ... >> syntax. I use it in piano scores all the time,
but never when working with associated lyrics because I understand the what
the syntax does under the covers. You use it enough and it's not so
confusing any more.

That being said, I really like the idea of changing the order of voices so
they can be input from high-to-low and the common use of \relative mode
would suggest that is an improvement over the current form.

I'd also like to re-iterate the need to have this vertical hierarchy apply
to the rests in those respective voices so that the "inner" voices' rests
get pushed inwards as well, or at least towards the vertical position of
where their notes are. I realize this is likely no small undertaking and I
can make due without it. Maybe one day I can even get into the details
myself and implement it myself. Who knows...

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Changing-voice-order-tp195757p196004.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Question for a FLOSS licensing session

[Wols Lists]

On 02/11/16 15:14, David Kastrup wrote:
> Wols Lists  writes:
> 
>> On 31/10/16 10:08, David Kastrup wrote:
> The repository contains among others
> - encoded music
> - Scheme functions created for the project
> - Scheme functions created using included code from LilyPond and GPLed
> openLilyLib
> - Scheme functions created by modifying functions copied from LilyPond
>>> Only the very last item is relevant if by "included code" you mean
>>> "\include ...".
>>>
> Doesn't the GPL prevent me from making that repository available
> under, say, a non-free CC license or under a no-license like "you may
> read the code and use it to produce scores but you may not
> redistribute a modified version"?
>>
>>> The GPL applies only with the very last item.  All the rest is
>>> irrelevant.  Note that the principal distribution is not a modified
>>> version of LilyPond but a document and stuff particular to creating that
>>> document with the help of LilyPond, but "with the help of LilyPond" does
>>> not imply LilyPond as a component of the project, just as a tool
>>> required for it.
>>
>> To elaborate, the first three items are all your work and you can
>> licence them as you wish. If they assume the computer has a copy of
>> lilypond on it, that is the end-user's problem.
>>
>> As David says, the only problem is where you have taken and modified
>> lilypond (GPL) code.
>>
>> And imho, provided everything is in source code form, you can't breach
>> the GPL anyway.
> 
> Wrong.  Your duty is to license the whole work you distribute under the
> terms of the GPL, with due notices attached and the licensing obvious to
> the downstream recipient.  If you fail to do so, you are in violation of
> the license you received LilyPond under and can be sued to cease and
> desist distribution by one of the original copyright holders.
> 
> This is not rocket science.

Where does it tell me I have to licence *MY* code as GPL (if I
distribute it as source)?

Umm ... I've just read v3 Section 5, and I don't think that's legally
enforceable! It's claiming rights over non-derivative works!

"or the modifications to produce it from the Program" - if it doesn't
actually contain any code lifted from the program then *that* is *not* a
derivative work!
> 
> I am constantly reminded of the time where my ex proofread a philosophy
> paper about Plato's cave thingy and told the writer that she thought
> that interpretation untenable and asked her whether she had actually
> read the text she had been writing about (Schleiermacher has done an
> excellent job at translating Plato's dialogues, to the degree that quite
> a few other translations are based on Schleiermacher's German rather
> than Plato's Greek).  Turns out she hadn't, just texts written _about_
> that text.  Not even reading the original is not contributing to
> knowledge, "Wissenschaft" or science.
> 
> The GPL is short.  There just is no necessity to spread one's ideas what
> might or should have been in it instead of actually taking a look.
> 
> It's mentioned right in the preamble:
> 
>   For example, if you distribute copies of such a program, whether
> gratis or for a fee, you must pass on to the recipients the same
> freedoms that you received.  You must make sure that they, too, receive
> or can get the source code.  And you must show them these terms so they
> know their rights.
> 
Firstly, the preamble is not legally binding. And secondly, how does
distributing AS SOURCE take away any of those rights?

I must admit, you've made me think, but I think the GPL v3 is playing
"fast and loose" with the definition of a derivative work. If I take
source repository, and ADD CODE, and then distribute that AS SOURCE, I'm
pretty certain my additions will, legally, fall under "mere
aggregation". Which is why I said that doing it is legal, but would
cause problems for downstream ...

So I have to stand by what I said - if the first three are "all your own
work" there is no obligation to licence as GPL. The last one is the
problematic one because it contains other peoples' code and the GPL will
bite. But even there, your patch doesn't need to be GPL - it's just that
by combining it with the other source, the result is GPL.

Cheers,
Wol

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

Re: Changing voice order...

[Mats Bengtsson]

On 2016-11-02 14:56, Noeck wrote:

Am 02.11.2016 um 14:48 schrieb David Kastrup:

>This particular one is... horrific.

In most of the cases the author should just have used chords instead of
voices.
My guess that the intention was to stay as close to Bach's manuscripts 
as possible.
I have used similar tricks to imitate the composers layout for "chords" 
with separate stems per note, when typesetting other baroque music. The 
stem order can indeed provide hints on how the composers wanted the 
chords to be broken, which is lost if you use standard modern 
typesetting practice chords. A famous example of a modern edition trying 
to imitate the original manuscript in this respect is late Werner 
Icking's typesetting of Bach's Violin Sonatas and Partitas (though done 
using MusiXTeX, not LilyPond), see 
http://imslp.org/wiki/6_Violin_Sonatas_and_Partitas,_BWV_1001-1006_(Bach,_Johann_Sebastian), 
bottom of the page.


I clearly support the proposal to change of the voice order to a more 
logical top to bottom structure, even though it would break some of my 
LilyPond code.


/Mats

--
=
Mats Bengtsson, Prof.
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
Email: mats.bengts...@ee.kth.se
WWW: https://www.kth.se/profile/matben/
=


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

Re: midi volume: default, crescendo, dynamic context, multiple staff

[Karlin High]

On 11/1/2016 5:24 PM, Gianmaria Lari wrote:
>
> What's the default midi volume in case I don't specify an absolute 
> dynamic mark (like \p \f etc)? Is there any way to change this default 
> value?
>

If I do this...

\version "2.19.48"
{ c' }
\midi { }

...and open the resulting MIDI file in SpeedyMidi ( 
http://speedymidi.sourceforge.net/ ) it looks like LilyPond set the 
volume to 100. (MIDI allows 0 - 128, right?)

> A crescendo mark that's not ending with an absolute dynamic mark how 
> much does increase or decrease the midi volume?
>
> In case I separate the dynamics from the music using a Dynamics 
> context is there any way to reflect the dynamics it in the midi output?
>
> Is it possible to specify some dynamics just once and apply it to 
> multiple staff?

I don't know about dynamic marks affecting volume or separate dynamics 
contexts affecting output. All I can do is refer to documentation:
http://lilypond.org/doc/v2.19/Documentation/notation/controlling-midi-dynamics.en.html

But a dynamics expression can be reused anywhere.

\version "2.19.48"
% Dynamics defined here
dyn = { s4\f\> s4 s4 s4\p\! }

\score {
   \new ChoirStaff <<
 % First use of dynamics
 \new Dynamics { \dyn }
 \new Staff = "SA" \relative {
   c' d e f
 }
 \new Staff = "TB" \relative {
   \clef bass
   a, b c d
 }
 % Second use of dynamics
 \new Dynamics { \dyn }
   >>
   \midi { }
}


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

Re: Question for a FLOSS licensing session

[David Kastrup]

Wols Lists  writes:

> On 31/10/16 10:08, David Kastrup wrote:
>>> > The repository contains among others
>>> > - encoded music
>>> > - Scheme functions created for the project
>>> > - Scheme functions created using included code from LilyPond and GPLed
>>> > openLilyLib
>>> > - Scheme functions created by modifying functions copied from LilyPond
>> Only the very last item is relevant if by "included code" you mean
>> "\include ...".
>> 
>>> > Doesn't the GPL prevent me from making that repository available
>>> > under, say, a non-free CC license or under a no-license like "you may
>>> > read the code and use it to produce scores but you may not
>>> > redistribute a modified version"?
>
>> The GPL applies only with the very last item.  All the rest is
>> irrelevant.  Note that the principal distribution is not a modified
>> version of LilyPond but a document and stuff particular to creating that
>> document with the help of LilyPond, but "with the help of LilyPond" does
>> not imply LilyPond as a component of the project, just as a tool
>> required for it.
>
> To elaborate, the first three items are all your work and you can
> licence them as you wish. If they assume the computer has a copy of
> lilypond on it, that is the end-user's problem.
>
> As David says, the only problem is where you have taken and modified
> lilypond (GPL) code.
>
> And imho, provided everything is in source code form, you can't breach
> the GPL anyway.

Wrong.  Your duty is to license the whole work you distribute under the
terms of the GPL, with due notices attached and the licensing obvious to
the downstream recipient.  If you fail to do so, you are in violation of
the license you received LilyPond under and can be sued to cease and
desist distribution by one of the original copyright holders.

This is not rocket science.

I am constantly reminded of the time where my ex proofread a philosophy
paper about Plato's cave thingy and told the writer that she thought
that interpretation untenable and asked her whether she had actually
read the text she had been writing about (Schleiermacher has done an
excellent job at translating Plato's dialogues, to the degree that quite
a few other translations are based on Schleiermacher's German rather
than Plato's Greek).  Turns out she hadn't, just texts written _about_
that text.  Not even reading the original is not contributing to
knowledge, "Wissenschaft" or science.

The GPL is short.  There just is no necessity to spread one's ideas what
might or should have been in it instead of actually taking a look.

It's mentioned right in the preamble:

  For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received.  You must make sure that they, too, receive
or can get the source code.  And you must show them these terms so they
know their rights.

-- 
David Kastrup

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

Re: Question for a FLOSS licensing session

[Wols Lists]

On 31/10/16 09:04, Thomas Morley wrote:
> 2016-10-31 9:48 GMT+01:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> When entering a new snippet first thing you read is:
>>>
>>> "Important: By entering your snippet, you are placing it in the public
>>> domain. This includes also snippets taken from the Lilypond manual
>>> (the manual authors grant you their permission to do so)."
>>
>> Is that a special permission for the LSR or does it hold for everything
>> from the manual?
> 
> That I don't know.
> Iirc, this sentence is there since I started using LilyPond, so maybe
> since the LSR was set up.
> 
This sounds dangerous to me!

Firstly, do the manual authors/editors know about it? This is the first
I've heard of it, and while my contributions probably (a) aren't
copyrightable anyway (too small), and (b) have probably been edited away
over the years, I don't remember ever giving a permission like that.

And secondly, anybody who puts manual material into the LSR is
relicencing it. Per "firstly" above, do they actually have the authority
to be able to do so?

(As always, I can't see anybody caring, but someone could decide to
cause trouble ...)

Cheers,
Wol


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

Re: Question for a FLOSS licensing session

[Wols Lists]

On 31/10/16 10:08, David Kastrup wrote:
>> > The repository contains among others
>> > - encoded music
>> > - Scheme functions created for the project
>> > - Scheme functions created using included code from LilyPond and GPLed
>> > openLilyLib
>> > - Scheme functions created by modifying functions copied from LilyPond
> Only the very last item is relevant if by "included code" you mean
> "\include ...".
> 
>> > Doesn't the GPL prevent me from making that repository available
>> > under, say, a non-free CC license or under a no-license like "you may
>> > read the code and use it to produce scores but you may not
>> > redistribute a modified version"?

> The GPL applies only with the very last item.  All the rest is
> irrelevant.  Note that the principal distribution is not a modified
> version of LilyPond but a document and stuff particular to creating that
> document with the help of LilyPond, but "with the help of LilyPond" does
> not imply LilyPond as a component of the project, just as a tool
> required for it.

To elaborate, the first three items are all your work and you can
licence them as you wish. If they assume the computer has a copy of
lilypond on it, that is the end-user's problem.

As David says, the only problem is where you have taken and modified
lilypond (GPL) code.

And imho, provided everything is in source code form, you can't breach
the GPL anyway. Even if you have mixed incompatible licences with it.
You may give your downstream a headache, but you're in the clear.

Cheers,
Wol

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

Re: Changing voice order...

[Noeck]

Am 02.11.2016 um 15:03 schrieb David Kastrup:
> I have no issue with following the Urtext (assuming that this is what
> the author did).  

Ah ok, that's possible. The copy I found does have chords in those places.

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

Re: Changing voice order...

[David Kastrup]

Noeck  writes:

> Am 02.11.2016 um 14:48 schrieb David Kastrup:
>> This particular one is... horrific.
>
> In most of the cases the author should just have used chords instead of
> voices.

I have no issue with following the Urtext (assuming that this is what
the author did).  But the way this has been mapped to <<\\>> is awkward.

-- 
David Kastrup

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

Re: Changing voice order...

[Noeck]

Am 02.11.2016 um 14:48 schrieb David Kastrup:
> This particular one is... horrific.

In most of the cases the author should just have used chords instead of
voices.

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

Re: Changing voice order...

[David Kastrup]

Noeck  writes:

> A bit more of Mutopia statistics:
>
> 4157 .ly files on Mutopia don't use << \\ >>
> 1130 .ly files on Mutopia do
>  307 of the latter have only one \\, so the can't be affected by a change
> The other 823 possible could be affected but most of them use only two
> voices in one construct but several such constructs.
>
> By the way, the top position with 369 double backslashes is this piece:
> https://github.com/MutopiaProject/MutopiaProject/blob/master/ftp/BachJS/BWV830/BWV-830/BWV-830-lys/BWV-830.ly

This particular one is... horrific.

upper = \relative e
{
  \clef treble 
  \key e \minor
  \time 2/2

  \ntbo #16.5 \times 4/7 { \bc e16[ g b e] \tc \su g[ b e] } g8. g16 << { g 4 
fs } \\
{ a,2   
 } \\
{ c 2   
 } >> | % 1

  \sn
  \ntbo #15.5 \times 4/7 { \bc ds,,16[ fs a c] \tc ds[ fs g] } a8. a16 << { a  
4 g} \\ 
  { 
  } \\
  { fs 
4 e _\mordent  } \\ 
  { 
  } \\
  { 
ds!4 s} >> | % 2


Let's take a look what conventions are employed here in the first two
<<\\>> things.  First the voices left empty (ugh) strongly suggest that
the person entering the code is aware of the up/down pattern of input.
Also the code suggest that the person is more acquainted with LilyPond's
abilities than good for the readability of their code.  Let's take a
look at the pitches (relative mode):

<< { g 4 fs } \\
   { a,2} \\
   { c 2} >> | % 1

top, bottom, middle: correct

<< { a  4 g} \\
   {   } \\
   { fs 4 e _\mordent  } \\ 
   {   } \\
   { ds!4 s} >> | % 2

Ugh what?  All of the non-empty ones are stemup.  Order:

top, middle, bottom: within the stemup stacking correct but what an
awful input.  And why everything stemup?

Let's take the next two examples:

<< { g16. \beams #2 #3 fs32 \beams #3 #3 e fs g16 cs,4 \prall } \\
   { cs,2 } \\
   { \shortStem #4.5 a'2  } \\
   {  } \\
   { e2   } >> | % 5

Order: top, bottom, high, --none--, low

One thing that is obvious that \relative pitch is a real mess to keep
track of in this kind of highest/lowest/high/low scheme.  It works quite
more natural in high-to-low stackings.

<< { fs16. \beams #2 #3 e32 \beams #3 #3 d e fs16 b,4 \prall } \\
   { d,2 } \\
   { \shortStem #5 g2} >> | % 6

Correct as far as I can see.

So this most exuberant example does not get anything wrong as far as a
first glance would suggest.  It's also ugly as hell.

At any rate, the \relative problem means that a convert-ly rule actually
reordering things would be a really, really complex feat.

-- 
David Kastrup

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

Re: Changing voice order...

[Noeck]

A bit more of Mutopia statistics:

4157 .ly files on Mutopia don't use << \\ >>
1130 .ly files on Mutopia do
 307 of the latter have only one \\, so the can't be affected by a change
The other 823 possible could be affected but most of them use only two
voices in one construct but several such constructs.

By the way, the top position with 369 double backslashes is this piece:
https://github.com/MutopiaProject/MutopiaProject/blob/master/ftp/BachJS/BWV830/BWV-830/BWV-830-lys/BWV-830.ly

Here is the full statistics:

#\\ #files
0   4157
1   307
2   178
3   87
4   72
5   54
6   51
7   30
8   40
9   29
10  28
11  14
12  19
13  14
14  21
15  4
16  17
17  10
18  8
19  8
20  12
21  12
22  4
23  3
24  4
25  10
26  7
27  5
28  4
29  5
30  1
31  5
32  3
33  3
34  2
35  3
36  6
37  2
38  1
39  1
40  2
41  1
42  1
45  1
46  1
47  5
48  1
49  1
50  1
52  2
53  2
54  3
55  1
56  1
57  1
61  1
62  3
70  1
72  1
76  1
88  1
93  1
96  1
103 1
107 1
114 1
116 1
119 1
121 1
140 1
151 1
153 1
171 1
218 1
369 1
Sum 5287

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

Re: Changing voice order...

[David Kastrup]

Alexander Kobel  writes:

> According to comment #10 on
> https://code.google.com/archive/p/lilypond/issues/4097 my example
> needs a \lyricsto Staff = "sop" instead of just \lyricsto "sop".
> (Though I don't quite get the explanation since the latter works for
> Voice contexts; but I guess that's again a semantic sugar-default for
> \lyricsto?)

Context names are no complete address but always require the context
type, usually defaulting to "Bottom".  Here possibly to "Voice".  Don't
remember.

> Anyway, I will have a look again with the advent of 2.19.50; not
> compiling staging right now.  Thanks!

Sure.  This is mostly a dormant feature since it cannot yet deal well
with melismata.

-- 
David Kastrup

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

Re: Changing voice order...

[Alexander Kobel]

On 2016-11-02 12:43, David Kastrup wrote:

David Kastrup  writes:


Alexander Kobel  writes:


On 2016-11-02 12:01, David Kastrup wrote:

Alexander Kobel  writes:

[...]

Ugh.  Maybe it's just \addlyrics then?  Or wait:




Uh, what?!?

lilypond /tmp/alex.ly
GNU LilyPond 2.19.50
Processing `/tmp/alex.ly'
Parsing.../usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
In procedure ly:music-property in expression (ly:music-property
music (quote elements)):
/usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
Wrong type argument in position 1 (expecting Prob): "sop"

Uh, this looks like the parser actually knows how to deal with the
syntax as such but it royally messes up doing something useful with the
parsed results.

Well, it has been nice talking about this.  Let's continue this
discussion in a week or so.


Sure. ;-)


This syntax was added in

commit df3457d85ebfa4bc347a4569241227449f84b901
Author: David Kastrup 
Date:   Tue Sep 9 11:14:34 2014 +0200

Allow \addlyrics to work with arbitrary contexts


No mention of \lyricsto, no mention of the issue number in the commit
message, obviously no regtest for the \lyricsto part of the syntax
change.

Wish there were somebody else to rant at.


Fixed in staging.  Still no documentation and no regtest, and obviously
it was sort of a secret anyway since nobody complained about it not
working.  I probably postponed until the "melisma translator" project
was done in order to make this really useful.  And it's still stuck
somewhere in the middle.


According to comment #10 on 
https://code.google.com/archive/p/lilypond/issues/4097 my example needs 
a \lyricsto Staff = "sop" instead of just \lyricsto "sop".  (Though I 
don't quite get the explanation since the latter works for Voice 
contexts; but I guess that's again a semantic sugar-default for \lyricsto?)


Anyway, I will have a look again with the advent of 2.19.50; not 
compiling staging right now.  Thanks!



Alexander

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

Re: Changing voice order...

[Werner LEMBERG]

>>   \voiceOrder { 1, 3, 5, 7, 6, 4, 2 }
>>   << c'''2 \\ g'' \\ e'' \\ c'' \\ g' \\ e' \\ c' >>
>
> More like \voices 1,3,5,7,6,4,2 << ... >> if we want to keep in
> current syntax.  This is assuming a one-shot command taking the <<
> >> construct as its last argument.

Hmm, my original idea was a global command, something similar to
setting up beam divisions for various meters – having a command to
locally override that would be certainly useful.

>> Note that this is an idea without considering whether it can be
>> implemented at all.
>
> With a bit of massage it seems to work.

Good to hear!


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

Re: Changing voice order...

[David Kastrup]

David Kastrup  writes:

> Alexander Kobel  writes:
>
>> On 2016-11-02 12:01, David Kastrup wrote:
>>> Alexander Kobel  writes:
[...]
>>> Ugh.  Maybe it's just \addlyrics then?  Or wait:
>>>
>>>
>>>
>>>
>>> Uh, what?!?
>>>
>>> lilypond /tmp/alex.ly
>>> GNU LilyPond 2.19.50
>>> Processing `/tmp/alex.ly'
>>> Parsing.../usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
>>> In procedure ly:music-property in expression (ly:music-property
>>> music (quote elements)):
>>> /usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
>>> Wrong type argument in position 1 (expecting Prob): "sop"
>>>
>>> Uh, this looks like the parser actually knows how to deal with the
>>> syntax as such but it royally messes up doing something useful with the
>>> parsed results.
>>>
>>> Well, it has been nice talking about this.  Let's continue this
>>> discussion in a week or so.
>>
>> Sure. ;-)
>
> This syntax was added in
>
> commit df3457d85ebfa4bc347a4569241227449f84b901
> Author: David Kastrup 
> Date:   Tue Sep 9 11:14:34 2014 +0200
>
> Allow \addlyrics to work with arbitrary contexts
>
>
> No mention of \lyricsto, no mention of the issue number in the commit
> message, obviously no regtest for the \lyricsto part of the syntax
> change.
>
> Wish there were somebody else to rant at.

Fixed in staging.  Still no documentation and no regtest, and obviously
it was sort of a secret anyway since nobody complained about it not
working.  I probably postponed until the "melisma translator" project
was done in order to make this really useful.  And it's still stuck
somewhere in the middle.

-- 
David Kastrup

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

Re: Changing voice order...

[David Kastrup]

"Phil Holmes"  writes:

> That's three voices, not four.
>
> Also - I was specifying vocal settings because a lot of the early
> discussion centred about how it's difficult to use the << \\ >> syntax
> with vocal scores, which generally are spoken about as being SATB and
> therefore there was an expectation that << S \\ A \\ T \\ B >> would
> be the natural order, which it isn't.  I've never seen any score ever
> with the four vocal lines on one staff, so whether that ordering works
> or not seems irrelevant.

It's not uncommon for me to put four-part harmony as S/A/T in the treble
staff and B in the bass staff when "arranging" for accordion.  Not
saying that this is a typical application.  For doing piano extracts, it
might be.

-- 
David Kastrup

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

Re: Changing voice order...

[Phil Holmes]

That's three voices, not four.

Also - I was specifying vocal settings because a lot of the early discussion 
centred about how it's difficult to use the << \\ >> syntax with vocal scores, 
which generally are spoken about as being SATB and therefore there was an 
expectation that << S \\ A \\ T \\ B >> would be the natural order, which it 
isn't.  I've never seen any score ever with the four vocal lines on one staff, 
so whether that ordering works or not seems irrelevant.

--
Phil Holmes


  - Original Message - 
  From: Kieren MacMillan 
  To: Phil Holmes 
  Cc: David Kastrup ; Trevor Daniels ; Lilypond-User Mailing List 
  Sent: Wednesday, November 02, 2016 12:30 AM
  Subject: Re: Changing voice order...


  Hi Phil,


Who uses four voices on one stave in vocal setting?



  Why would this functionality be limited to vocal setting? Here is a 
screenshot of a three-voice section in my Chaconne for unaccompanied violin:



  There are many uses for multiple [musical] voices that don’t involve "vocal 
setting”.


  Cheers,
  Kieren.
  

  Kieren MacMillan, composer
  ‣ website: www.kierenmacmillan.info
  ‣ email: i...@kierenmacmillan.info


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

Re: Changing voice order...

[David Kastrup]

Alexander Kobel  writes:

> On 2016-11-02 12:01, David Kastrup wrote:
>> Alexander Kobel  writes:
>>>[...]
>> Ugh.  Maybe it's just \addlyrics then?  Or wait:
>>
>>
>>
>>
>> Uh, what?!?
>>
>> lilypond /tmp/alex.ly
>> GNU LilyPond 2.19.50
>> Processing `/tmp/alex.ly'
>> Parsing.../usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
>> In procedure ly:music-property in expression (ly:music-property
>> music (quote elements)):
>> /usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
>> Wrong type argument in position 1 (expecting Prob): "sop"
>>
>> Uh, this looks like the parser actually knows how to deal with the
>> syntax as such but it royally messes up doing something useful with the
>> parsed results.
>>
>> Well, it has been nice talking about this.  Let's continue this
>> discussion in a week or so.
>
> Sure. ;-)

This syntax was added in

commit df3457d85ebfa4bc347a4569241227449f84b901
Author: David Kastrup 
Date:   Tue Sep 9 11:14:34 2014 +0200

Allow \addlyrics to work with arbitrary contexts


No mention of \lyricsto, no mention of the issue number in the commit
message, obviously no regtest for the \lyricsto part of the syntax
change.

Wish there were somebody else to rant at.

-- 
David Kastrup

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

Re: Changing voice order...

[Alexander Kobel]

On 2016-11-02 12:01, David Kastrup wrote:

Alexander Kobel  writes:

[...]

Ugh.  Maybe it's just \addlyrics then?  Or wait:




Uh, what?!?

lilypond /tmp/alex.ly
GNU LilyPond 2.19.50
Processing `/tmp/alex.ly'
Parsing.../usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
 In procedure ly:music-property in expression (ly:music-property music (quote 
elements)):
/usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12: Wrong type 
argument in position 1 (expecting Prob): "sop"

Uh, this looks like the parser actually knows how to deal with the
syntax as such but it royally messes up doing something useful with the
parsed results.

Well, it has been nice talking about this.  Let's continue this
discussion in a week or so.


Sure. ;-)


Cheers,
Alexander

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

Re: Changing voice order...

[David Kastrup]

Alexander Kobel  writes:

> On 2016-11-02 11:35, David Kastrup wrote:
>> Alexander Kobel  writes:
>>
>>> On 2016-11-02 11:20, David Kastrup wrote:
 Alexander Kobel  writes:

> I mostly set vocal music - typically clean SATB with exactly four
> voices on either two or four staves, but sometimes a voice splits to
> two or three in between.  In that case, I'll almost always have a
> four-staves situation.  This screams for << \\ >> or << \\ \\ >>.
>
> However, I attach lyrics to the voices, and that's why I give them
> sensible names - namely, "sop" (or "soprano"), "alt", etc.  The
> implicit voice naming with << \\ >> means that I have to split my
> lyrics to separate context, or I'll have to rename the voices inside
> << \\ >>.

 No, it just means that your lyrics have to follow the staff rather than
 a single voice unless your lyrics split as well.

 Can't find the issue number where this was made to work.  Still has
 problems with overlapping melismata if I remember correctly, so maybe
 that's why it's not advertised prominently.
>>>
>>> Hum.  You mean if I name the staff instead of the voices, I can create
>>> lyrics that follow all voices that are active on this staff?
>>> Doesn't seem to work, but I might not have the right syntax.
>>
>> It's a 2.19 thing.
>
> Post-2.19.49?  Because that's what I tested with (without knowing what
> syntax might be required, though):
>
> \version "2.19.49"
> sop = \relative c'' {
>   c4 c c c
>   << { c c } \\ { g4. g8 } >> c4 c
> }
> \score {
>   <<
> \new Staff = "sop" \sop
> \new Lyrics \lyricsto "sop" { a b c d e f g h }
>   >>
> }
>
> test.ly:9:17: warning: cannot find Voice `sop'
>
> \new Lyrics
> \lyricsto "sop" { a b c d e f g h }

Ugh.  Maybe it's just \addlyrics then?  Or wait:

\version "2.19.49"
sop = \relative c'' {
  c4 c c c
  << { c c } \\ { g4. g8 } >> c4 c
}
\score {
  <<
\new Staff = "sop" \sop
\new Lyrics \lyricsto Staff = "sop" { a b c d e f g h }
  >>
}

Uh, what?!?

lilypond /tmp/alex.ly
GNU LilyPond 2.19.50
Processing `/tmp/alex.ly'
Parsing.../usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12:
 In procedure ly:music-property in expression (ly:music-property music (quote 
elements)):
/usr/local/share/lilypond/2.19.50/scm/ly-syntax-constructors.scm:294:12: Wrong 
type argument in position 1 (expecting Prob): "sop"

Uh, this looks like the parser actually knows how to deal with the
syntax as such but it royally messes up doing something useful with the
parsed results.

Well, it has been nice talking about this.  Let's continue this
discussion in a week or so.

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

Re: Changing voice order...

[Alexander Kobel]

On 2016-11-02 11:35, David Kastrup wrote:

Alexander Kobel  writes:


On 2016-11-02 11:20, David Kastrup wrote:

Alexander Kobel  writes:


I mostly set vocal music - typically clean SATB with exactly four
voices on either two or four staves, but sometimes a voice splits to
two or three in between.  In that case, I'll almost always have a
four-staves situation.  This screams for << \\ >> or << \\ \\ >>.

However, I attach lyrics to the voices, and that's why I give them
sensible names - namely, "sop" (or "soprano"), "alt", etc.  The
implicit voice naming with << \\ >> means that I have to split my
lyrics to separate context, or I'll have to rename the voices inside
<< \\ >>.


No, it just means that your lyrics have to follow the staff rather than
a single voice unless your lyrics split as well.

Can't find the issue number where this was made to work.  Still has
problems with overlapping melismata if I remember correctly, so maybe
that's why it's not advertised prominently.


Hum.  You mean if I name the staff instead of the voices, I can create
lyrics that follow all voices that are active on this staff?
Doesn't seem to work, but I might not have the right syntax.


It's a 2.19 thing.


Post-2.19.49?  Because that's what I tested with (without knowing what 
syntax might be required, though):


\version "2.19.49"
sop = \relative c'' {
  c4 c c c
  << { c c } \\ { g4. g8 } >> c4 c
}
\score {
  <<
\new Staff = "sop" \sop
\new Lyrics \lyricsto "sop" { a b c d e f g h }
  >>
}

test.ly:9:17: warning: cannot find Voice `sop'

\new Lyrics
\lyricsto "sop" { a b c d e f g h }


By the way, your reply to Werner shows pretty much what I actually
would consider useful: :-)


[...]
The problem I see right away with that is that it is useful.  How is
that a problem?

<<
  \new Voice = "soprano" {
 ...
 \voices 1,soprano << ... \\ ... >>
 ...
  }
  \lyricsto "soprano" { ... }




Lo and behold, we have a solution for an old problem.
[...]


That one can actually be done sort-of right away.  It would likely
cement the "2"/\voiceTwo/2nd item relation however.  Which is sort of
the opposite of the proposal I started this discussion with.


I see, and totally agree.  It's just something to keep in mind.


Cheers,
Alexander

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

Re: Changing voice order...

[David Kastrup]

Alexander Kobel  writes:

> On 2016-11-02 11:20, David Kastrup wrote:
>> Alexander Kobel  writes:
>>
>>> I mostly set vocal music - typically clean SATB with exactly four
>>> voices on either two or four staves, but sometimes a voice splits to
>>> two or three in between.  In that case, I'll almost always have a
>>> four-staves situation.  This screams for << \\ >> or << \\ \\ >>.
>>>
>>> However, I attach lyrics to the voices, and that's why I give them
>>> sensible names - namely, "sop" (or "soprano"), "alt", etc.  The
>>> implicit voice naming with << \\ >> means that I have to split my
>>> lyrics to separate context, or I'll have to rename the voices inside
>>> << \\ >>.
>>
>> No, it just means that your lyrics have to follow the staff rather than
>> a single voice unless your lyrics split as well.
>>
>> Can't find the issue number where this was made to work.  Still has
>> problems with overlapping melismata if I remember correctly, so maybe
>> that's why it's not advertised prominently.
>
> Hum.  You mean if I name the staff instead of the voices, I can create
> lyrics that follow all voices that are active on this staff?
> Doesn't seem to work, but I might not have the right syntax.

It's a 2.19 thing.

> By the way, your reply to Werner shows pretty much what I actually
> would consider useful: :-)
>
>> [...]
>> The problem I see right away with that is that it is useful.  How is
>> that a problem?
>>
>> <<
>>   \new Voice = "soprano" {
>>  ...
>>  \voices 1,soprano << ... \\ ... >>
>>  ...
>>   }
>>   \lyricsto "soprano" { ... }
>> >>
>>
>> Lo and behold, we have a solution for an old problem.
>> [...]

That one can actually be done sort-of right away.  It would likely
cement the "2"/\voiceTwo/2nd item relation however.  Which is sort of
the opposite of the proposal I started this discussion with.

-- 
David Kastrup

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

Re: Changing voice order...

[Alexander Kobel]

On 2016-11-02 11:20, David Kastrup wrote:

Alexander Kobel  writes:


I mostly set vocal music - typically clean SATB with exactly four
voices on either two or four staves, but sometimes a voice splits to
two or three in between.  In that case, I'll almost always have a
four-staves situation.  This screams for << \\ >> or << \\ \\ >>.

However, I attach lyrics to the voices, and that's why I give them
sensible names - namely, "sop" (or "soprano"), "alt", etc.  The
implicit voice naming with << \\ >> means that I have to split my
lyrics to separate context, or I'll have to rename the voices inside
<< \\ >>.


No, it just means that your lyrics have to follow the staff rather than
a single voice unless your lyrics split as well.

Can't find the issue number where this was made to work.  Still has
problems with overlapping melismata if I remember correctly, so maybe
that's why it's not advertised prominently.


Hum.  You mean if I name the staff instead of the voices, I can create 
lyrics that follow all voices that are active on this staff?
Doesn't seem to work, but I might not have the right syntax.  The only 
thing I'm aware of is using an "aligner" NullVoice, as shown in NR 
2.1.2: Polyphony with shared lyrics, but that's kinda clumsy, too.


By the way, your reply to Werner shows pretty much what I actually would 
consider useful: :-)



[...]
The problem I see right away with that is that it is useful.  How is
that a problem?

<<
  \new Voice = "soprano" {
 ...
 \voices 1,soprano << ... \\ ... >>
 ...
  }
  \lyricsto "soprano" { ... }
>>

Lo and behold, we have a solution for an old problem.
[...]



Cheers,
Alexander

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

Re: Changing voice order...

[David Kastrup]

Alexander Kobel  writes:

> I mostly set vocal music - typically clean SATB with exactly four
> voices on either two or four staves, but sometimes a voice splits to
> two or three in between.  In that case, I'll almost always have a
> four-staves situation.  This screams for << \\ >> or << \\ \\ >>.
>
> However, I attach lyrics to the voices, and that's why I give them
> sensible names - namely, "sop" (or "soprano"), "alt", etc.  The
> implicit voice naming with << \\ >> means that I have to split my
> lyrics to separate context, or I'll have to rename the voices inside
> << \\ >>.

No, it just means that your lyrics have to follow the staff rather than
a single voice unless your lyrics split as well.

Can't find the issue number where this was made to work.  Still has
problems with overlapping melismata if I remember correctly, so maybe
that's why it's not advertised prominently.

-- 
David Kastrup

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

Re: Changing voice order...

[David Kastrup]

Werner LEMBERG  writes:

>> To make it more visible I coded a small snippet annotating some info
>> to NoteHeads in
>> << .. \\ .. \\ ... ... ... >>-constructs.
>> 
>> Output attached.
>
> Thanks!
>
> What about a two-step process: You first set up the order of the
> voices, then you input from top to bottom.
>
> Example:
>
>   % current
>   << c'''2 \\ c' \\ g'' \\ e' \\ e'' \\ g' \\ c''  >>
>
>   % suggested
>   \voiceOrder { 1, 3, 5, 7, 6, 4, 2 }
>   << c'''2 \\ g'' \\ e'' \\ c'' \\ g' \\ e' \\ c' >>
>
> Using such a command would even retain backwards compatibility.

More like \voices 1,3,5,7,6,4,2 << ... >> if we want to keep in current
syntax.  This is assuming a one-shot command taking the << >> construct
as its last argument.

The problem I see right away with that is that it is useful.  How is
that a problem?

<<
  \new Voice = "soprano" {
 ...
 \voices 1,soprano << ... \\ ... >>
 ...
  }
  \lyricsto "soprano" { ... }
>>

Lo and behold, we have a solution for an old problem.  But 1 can imply
\voiceOne as well as \context Voice = "1" while "soprano" cannot
obviously indicate "\voiceTwo".  Maybe it is a feature instead of a bug?
After all, << ... \\ ... >> also does not imply a final \oneVoice for
whatever voice continues so we are better off having to say \voiceTwo
explicitly in the non-temporary voice as well?

Also, names like "soprano1" will be quite awkward:

\voices #'(1 soprano1) << ... >>

Basically, we would want to strongly suggest people to use context names
that LilyPond also likes as symbols.

> Note that this is an idea without considering whether it can be
> implemented at all.

With a bit of massage it seems to work.

-- 
David Kastrup

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

Re: Changing voice order...

[Alexander Kobel]

On 2016-10-28 14:52, David Kastrup wrote:

Alexander Kobel  writes:

[...]
Basically you need to only fix those voices not obeying the standard
scheme (usually just one) and the rest will work out.  So I don't really
think that a special syntax is needed.


True. But isn't the point of this shortcut notation that it saves you
the trouble of specifying those directions and voice names on your
own?


Sure, but you talk about a case where one _has_ to specify a direction
and voice name after all because the default does not work.  Admittedly,
yet another shortcut saves you from figuring out what level of \inner
(or whatever) you have to use.


Coincidentally, that's why I hardly ever use it: I tend to get
lost with the automatic assignment


Well, which is why the automatic assignment should be as predictable and
brainless and useful as possible.


After some consideration, I found the reason /why/ I don't like the 
automatic assignment.  It's not that it's unpredictable (at least for 
me; I'm used to the voice order since a long time.  Rather, it's that 
there is automatic assignment going on at all:


I mostly set vocal music - typically clean SATB with exactly four voices 
on either two or four staves, but sometimes a voice splits to two or 
three in between.  In that case, I'll almost always have a four-staves 
situation.  This screams for << \\ >> or << \\ \\ >>.


However, I attach lyrics to the voices, and that's why I give them 
sensible names - namely, "sop" (or "soprano"), "alt", etc.  The implicit 
voice naming with << \\ >> means that I have to split my lyrics to 
separate context, or I'll have to rename the voices inside << \\ >>. 
The output of


sop = \relative c'' {
  c4 c c c
  << { c c } \\ { g4. g8 } >> c4 c
}

\score {
  <<
\new Staff { \new Voice = "sop" \sop }
\new Lyrics \lyricsto "sop" { a b c d e f g h }
  >>
}

is (lyrics-wise) counterintuitive enough that I mostly refrain from 
using the construct at all and resort to my own (simple) helper function 
that creates anonymous voices (above or below) and does not override the 
name of the main voice.
To change my style here, I'd need /at least/ prefixed voice names (that 
is, the voices created in line 3 would be named, e.g., "sop-1" and 
"sop-2"); some way to keep one voice in place and just add another one 
would make it a real boon.


However, this is maybe specific for this use case.  Plus, I cannot see 
an obvious way to add this functionality without cluttering the 
syntactic sugar with tons of parameters that make it no less ugly than 
simple helper functions...



Obviously, that does not have much to do with the order of voices.  It's 
just meant as an explanation that the reason for me not using << \\ >> 
is not the /way/ how automatic assignment works, but rather the /fact/ 
that automatic assignment is done at all.



Cheers,
Alexander

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

Re: Changing voice order...

[David Kastrup]

"Trevor Daniels"  writes:

> David Kastrup wrote Tuesday, November 01, 2016 4:11 PM
>
>>  I want to rename the \voiceXXX constructs
>> as well.  The old ones will be available still but no longer promoted
>> and/or documented prominently, instead using something like \voiceUp,
>> \voiceDown, \inner \voiceUp, \inner \VoiceDown ...  
>
> I definitely object to this.  The meaning and use of the \voicexxx
> predefs is engrained in the habits and memory of many, most?, of the
> long-standing LP users, as well as pretty well all existing code.

So?  "The old ones will be available still".

So do you want

<< a \\ b \\ c \\ d >>

to correspond to

<< \context Voice = "1" { \voiceOne a }
   \context Voice = "2" { \voiceThree a }
   \context Voice = "3" { \voiceFour a }
   \context Voice = "4" { \voiceTwo a }
>>

or to

<< \context Voice = "1" { \voiceOne a }
   \context Voice = "3" { \voiceThree a }
   \context Voice = "4" { \voiceFour a }
   \context Voice = "2" { \voiceTwo a }
>>

?

Either one will be a real joy to explain.  That's why I want the
documented version to make more sense than that.

And even explicit stuff like

<< \new Voice = "sopranoI" \with { \voiceOne } ...
   \new Voice = "sopranoII" \with { \voiceThree } ...
   \new Voice = "alto" \with { \voiceTwo } ...
>>

or

<< \new Voice = "soprano" \with { \voiceOne } ...
   \new Voice = "altoI" \with { \voiceFour } ...
   \new Voice = "altoII" \with { \voiceTwo } ...
>>

just reads awfully and is really embarrassing to show in talk slides.

It also has absolutely no connection to \voiceOneStyle, \voiceTwoStyle,
\voiceThreeStyle ... which you'd more likely apply from top to bottom.

Take a look at our example for voice styles:

Voice styles


Voices may be given distinct colors and shapes, allowing them to be
easily identified:

 <<
   \relative { \voiceOneStyle d''4 c2 b4 }
   \\
   \relative { \voiceTwoStyle e'2 e }
   \\
   \relative { \voiceThreeStyle b2. c4 }
   \\
   \relative { \voiceFourStyle g'2 g }
 >>

[image]

   The ‘\voiceNeutralStyle’ command is used to revert to the standard
presentation.

Order is

<< \voiceOne (1st voice from top) in \voiceOneStyle \\
   \voiceTwo (3rd voice from top) in \voiceTwoStyle \\
   \voiceThree (4th voice from top) in \voiceThreeStyle \\
   \voiceFour (2nd voice from top) in \voiceFourStyle
>>

This became a four-voice example with

commit 213025779c233a52b4b56583926d2fe3335ce06b
Author: Graham Percival 
Date:   Mon Jul 14 19:52:37 2008 -0700

Update from Francisco.

It took me some back and forth to finally come to the conclusion that
this example is indeed as correct as it gets and shows \voiceTwo as
corresponding to \voiceTwoStyle .  But do you want to explain the entry
order to a beginner?

Ah, I see Mark did:

commit a52dc416eb5264c67a8b278207f372ed527a870d
Author: Mark Polesky 
Date:   Fri Sep 24 07:51:09 2010 -0700

Doc: NR 1.5.2: Clarify voice order; \shiftOn etc.


Voice order
...

When entering multiple voices in the input file, use the following
order:

 Voice 1: highest
 Voice 2: lowest
 Voice 3: second highest
 Voice 4: second lowest
 Voice 5: third highest
 Voice 6: third lowest
 etc.

   Though this may seem counterintuitive, it simplifies the automatic
layout process.


"It simplifies the automatic layout process"?  Nope, that's absolutely
not a valid excuse.  Either we can sell this as a great user-level
feature for note entry.  Or not.  The layout process could not care less
about our decision so we should not try hiding behind it.  I am not
suggesting that Mark did this: he probably operated with the "somebody
must have had a reason for this" assumption and made a guess what it
might have been (and, well, it passed review).  If so, he apparently
ruled out "because it is a useful thing to do".

It's a valiant effort.  The Learning Manual also introduces this voice
order early on.  We also have

   The commands ‘\voiceXXXStyle’ are mainly intended for use in
educational documents such as this one.  They modify the color of the
note head, the stem and the beams, and the style of the note head, so
that the voices may be easily distinguished.  Voice one is set to red
diamonds, voice two to blue triangles, voice three to green crossed
circles, and voice four (not used here) to magenta crosses;

already in the LM.

With regard to selling this as a great user-level feature: I can see the
order of << \\ \\ \\ >> make some sense for ad-hoc polyphony where you
use just as many voices as you need for representing the current
harmonic context, and then you'll generally try making do with a top and
bottom voice and, if necessary, fill in stuff in the middle.  I think
that's more or less 

Re: Changing voice order...

[Noeck]

Am 01.11.2016 um 16:36 schrieb Phil Holmes:
> I don't use concert-ly 'cos I find it a pain on Windows.

It's very easy with Frescobaldi, if you don't like the command line:

Tools > Update with convert-ly

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

Re: Changing voice order...

[Noeck]

Am 01.11.2016 um 15:42 schrieb David Kastrup:
> How about we check out Mutopia?  It is my guess that a considerable
> number of the uses of << \\ \\ \\ >> construct with three or more voices
> are wrong.

In the Mutopia files there are 15873 double backslashes `\\`:

grep -roh "" ftp  | wc -l

I thought this would match the expression but there are "too many errors":

pcregrep -rM '<<(\n|.)*(\n|.)*>>'

That means, the << · \\ · >> construct is heavily used on Mutopia, but I
could not find out how many of them have more than 2 voices.

Best,
Joram

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

Re: Augmentation dots regtests

[Werner LEMBERG]

> Looking at these, I suspect dot-columns on voices should be the
> default.  Perhaps that would increase the motivation to fix its
> issues ;)

Hehe, good argument :-)


Werner

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

Re: Augmentation dots regtests

[Chris Yate]

On 2 Nov 2016 08:13, "Werner LEMBERG"  wrote:
>
>
> > Does moving the dot-column-engraver to voice sort out the confusing
> > horizontal spacing in these situations?  First time I've seen that
> > and it does interesting things to the positioning of dots.
>
> Alas, it doesn't work reliably in many cases (because it works locally
> only) and it sometimes produces collisions, IIRC – this was a few
> years ago, and maybe it is better now.
>
> It would help if there was an easy to use command to locally move the
> dot-column-engraver to voice context.
>
>
> Werner

Looking at these, I suspect dot-columns on voices should be the default.
Perhaps that would increase the motivation to fix its issues ;)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dots regtests

[Werner LEMBERG]

> Does moving the dot-column-engraver to voice sort out the confusing
> horizontal spacing in these situations?  First time I've seen that
> and it does interesting things to the positioning of dots.

Alas, it doesn't work reliably in many cases (because it works locally
only) and it sometimes produces collisions, IIRC – this was a few
years ago, and maybe it is better now.

It would help if there was an easy to use command to locally move the
dot-column-engraver to voice context.


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

Re: Augmentation dots regtests

[Chris Yate]

On 2 Nov 2016 06:37, "Werner LEMBERG"  wrote:
>
>
> > 1) The kievan dot for a notehead on a line moved to a space, when it
> >should have stayed on a line.
> >
> > 2) When notes are displayed without a staff, the dot should stay on
> >the same level as the notehead, but it shifts up a half space.
> >
> > I'd welcome a critical review of the regtests to see if there are
> > any situations (other than those mentioned above) that you believe
> > are worse or wrong.
>
> Looking at `dot-column-vertical-positioning', I think the f-dot is
> wrongly positioned (but the rest dot is OK).
>
> I can imagine that the old solution of chord 7 in
> `dot-column-engraver' is better than the new behaviour (but still not
> optimal – the right solution, of course, would to position the dot for
> the first note before the head of the second note).
>
> The last chord in `collision-mesh' is as bad as before, just
> differently :-)
>
>
> Werner

I agree with most of your points, other than that I think the dots in
collision-mesh 4 were on the right spaces originally.

Does moving the dot-column-engraver to  voice sort out the confusing
horizontal spacing in these situations? First time I've seen that and it
does interesting things to the positioning of dots.

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

Re: Changing voice order...

[Werner LEMBERG]

> To make it more visible I coded a small snippet annotating some info
> to NoteHeads in
> << .. \\ .. \\ ... ... ... >>-constructs.
> 
> Output attached.

Thanks!

What about a two-step process: You first set up the order of the
voices, then you input from top to bottom.

Example:

  % current
  << c'''2 \\ c' \\ g'' \\ e' \\ e'' \\ g' \\ c''  >>

  % suggested
  \voiceOrder { 1, 3, 5, 7, 6, 4, 2 }
  << c'''2 \\ g'' \\ e'' \\ c'' \\ g' \\ e' \\ c' >>

Using such a command would even retain backwards compatibility.

Note that this is an idea without considering whether it can be
implemented at all.


Werner

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

Re: Augmentation dots regtests

[Werner LEMBERG]

> 1) The kievan dot for a notehead on a line moved to a space, when it
>should have stayed on a line.
>
> 2) When notes are displayed without a staff, the dot should stay on
>the same level as the notehead, but it shifts up a half space.
>
> I'd welcome a critical review of the regtests to see if there are
> any situations (other than those mentioned above) that you believe
> are worse or wrong.

Looking at `dot-column-vertical-positioning', I think the f-dot is
wrongly positioned (but the rest dot is OK).

I can imagine that the old solution of chord 7 in
`dot-column-engraver' is better than the new behaviour (but still not
optimal – the right solution, of course, would to position the dot for
the first note before the head of the second note).

The last chord in `collision-mesh' is as bad as before, just
differently :-)


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