Re: Changing voice order...

[Paul]

On 11/01/2016 09:50 PM, Paul wrote:

so I'm not sure how or even whether this kind of thing can be done in 
user space (at least not with existing functions like map-some-music).


Well, here's a start on something, but still not sure how to pull it off 
fully:


\version "2.19.49"

split =
#(define-music-function (directions music) (list? ly:music?)

   (let* ((elts (ly:music-property music 'elements))
  (elts2 (map (lambda (el dir)

(display dir)(newline)
(display el)(newline)

;; do something with each sequential music 
element...

(if (equal? dir 'up)
#{ \voiceOne #el #}
#{ \voiceTwo #el #}))

   elts directions)))

 (make-music 'SequentialMusic 'elements elts2)))


m = { { a4 b } { c'4 d' } { e'4 f' } }

\displayMusic \m

% \new Staff
% \displayMusic
\split up,down,up \m




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

Re: Changing voice order...

[Paul]

Hi Kieren,

On 11/01/2016 08:32 PM, Kieren MacMillan wrote:


I'm not sure how to write a function that accepts an arbitrary
number of music expressions.

Couldn’t the function “look forward” the number of entries in the udududud list?


I don't think that can work, because the function has to be called (with 
however many arguments it takes) before it has access to its first 
argument, which is the udud list or string.  So a chicken and egg thing.



that seems to call for a "list of music expressions”,
but I'm not sure to what extent that would make the syntax unwieldy.

How does \alternative do it? Can something be learned from that?


So \alternative takes just one argument, a single music expression 
wrapped in {}, with one or more music expressions nested inside.  So 
that approach might work, say with a function that took two arguments:


  \split udd {{...} {...} {...}}

Although, I don't know how \alternative gets the sub-expressions out of 
the top-level one...  and after a brief cursory look at the source code 
it looks like \alternative is handled by the parser (as opposed to being 
just a scheme/music/etc function)...  so I'm not sure how or even 
whether this kind of thing can be done in user space (at least not with 
existing functions like map-some-music).


Cheers,
-Paul



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

Re: Changing voice order...

[Kieren MacMillan]

Hi Urs,

> I'm not sure how to write a function that accepts an arbitrary
> number of music expressions.

Couldn’t the function “look forward” the number of entries in the udududud list?

> that seems to call for a "list of music expressions”,
> but I'm not sure to what extent that would make the syntax unwieldy.

How does \alternative do it? Can something be learned from that?

Thanks,
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...

[Kieren MacMillan]

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...

[Urs Liska]

Am 01.11.2016 um 23:40 schrieb Kieren MacMillan:
> Hi all,
> 
>>   [pseudocode:]
>>   \splitUD { topmusic \with UP } { bottommusic \with DOWN }
>>   \splitUUD { topmusic \with UP } { middlemusic \with UP } { bottommusic 
>> \with DOWN }
>>   \splitUDD { topmusic \with UP } { middlemusic \with DOWN } { bottommusic 
>> \with DOWN }
>>   etc.
> 
> If I was better with Scheme, I would try to whip up a function that accepted 
> an arbitrary number of musical expressions, with the up/down dictated by the 
> first parameter, e.g.
> 
> \split u,d,u,u,d,d { 1st,up [= top] } { 2nd,down } { 3rd,up } { 4th,up } 
> { 5th,down } { 6th,down [= bottom] }
> 
> Seems like smarter-than-me people could make this (or similar) work, no sweat.

Something like

\split "uduudd"

should be easily parseable. Well, it wouldn't even need the quotation
marks around.

But I'm not sure how to write a function that accepts an arbitrary
number of music expressions. Basically that seems to call for a "list of
music expressions", but I'm not sure to what extent that would make the
syntax unwieldy.

Urs

> 
> 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
> 


-- 
Urs Liska
www.openlilylib.org

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

Re: Changing voice order...

[Kieren MacMillan]

Hi all,

>   [pseudocode:]
>   \splitUD { topmusic \with UP } { bottommusic \with DOWN }
>   \splitUUD { topmusic \with UP } { middlemusic \with UP } { bottommusic 
> \with DOWN }
>   \splitUDD { topmusic \with UP } { middlemusic \with DOWN } { bottommusic 
> \with DOWN }
>   etc.

If I was better with Scheme, I would try to whip up a function that accepted an 
arbitrary number of musical expressions, with the up/down dictated by the first 
parameter, e.g.

\split u,d,u,u,d,d { 1st,up [= top] } { 2nd,down } { 3rd,up } { 4th,up } { 
5th,down } { 6th,down [= bottom] }

Seems like smarter-than-me people could make this (or similar) work, no sweat.

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

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

[Gianmaria Lari]

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?

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?

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

Re: Making a Hairpin end close to the end of a Score

[Simon Albrecht]

Hi Chris,

we use to always keep communication on-list, except in special 
circumstances. Thus everybody will be able to follow and see whether 
there has been a solution, or look it up in the archives. So ‘reply all’.



On 01.11.2016 23:02, Christopher Heckman wrote:

On Tue, Nov 1, 2016 at 2:55 PM, Simon Albrecht  wrote:

On 31.10.2016 06:10, Jay Anderson wrote:

On Sun, Oct 30, 2016 at 5:35 PM, Christopher Heckman
 wrote:

I stumbled on this hack, and it doesn't appear to be anywhere online.

As is, you can't have a hairpin run until the very end of a score; it
will stop before the last note. You also can't add \! to a \bar;
Lilypond complains that it is not a musical event.

The idea is to use \afterGrace, with an invisible grace note.

\absolute {
  c'2\> \afterGrace d' { s16\! } |
  }

MIDI translates this as you would expect, without an extra note at the
end.

However, this will not work if the hairpin starts on the last printed
note.

I tend to use this:

c1\> s1*0\! |

Or you can use an empty chord:
c1 <>\!

Best, Simon

I haven't tried these yet, but it looks like the hairpin would extend
to the end of the bar; in my fix, it ends about 3/4 of the way there.


In that case, another opportunity to step forward with the now much-used 
\after function, here to be applied as

\after 3/4 \! c1\>

See attachment.
Best, Simon
\version "2.18.2"

% Thanks to David Kastrup for the inspiration!
after =
#(define-music-function (parser location t e m) (ly:duration? ly:music? ly:music?)
   #{
 \context Bottom <<
   #m
   { \skip $t <> -\tweak extra-spacing-width #empty-interval $e }
 >>
   #})

{ \after 4 \< \after 2 \> \after 2. \! c'1 }___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: compound time signature with non duple denominator

[Simon Albrecht]

On 28.10.2016 21:50, Noeck wrote:

Btw, having the new list syntax in mind I wondered whether this would
work in recent development versions:

\compoundMeter 4/4,1/3

But it does not the 4/4 translates to (4 . 4) and not (4 4).
\compoundMeter (4,4),(1,3) does not work either. Can this list syntax be
grouped somehow? I mean in a way that is nicer to write than the scheme
syntax, otherwise nothing is gained.


Such a feature is not yet implemented. And I don’t think there is any 
obvious way of extending the current syntax to allow such nested lists, 
since it doesn’t have any delimiters for start and end of the list 
except for the spaces. We certainly can’t do

\compoundMeter  4,4 , 1,3
since spaces are not supposed to make such a difference in LilyPond code.

Best, Simon

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

Re: Making a Hairpin end close to the end of a Score

[Simon Albrecht]

On 31.10.2016 06:10, Jay Anderson wrote:

On Sun, Oct 30, 2016 at 5:35 PM, Christopher Heckman
 wrote:

I stumbled on this hack, and it doesn't appear to be anywhere online.

As is, you can't have a hairpin run until the very end of a score; it
will stop before the last note. You also can't add \! to a \bar;
Lilypond complains that it is not a musical event.

The idea is to use \afterGrace, with an invisible grace note.

\absolute {
 c'2\> \afterGrace d' { s16\! } |
 }

MIDI translates this as you would expect, without an extra note at the end.

However, this will not work if the hairpin starts on the last printed note.

I tend to use this:

c1\> s1*0\! |


Or you can use an empty chord:
c1 <>\!

Best, Simon

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

Re: Changing voice order...

[Trevor Daniels]

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.  
Changing the way the << .. \\ .. >> construct works is one thing, 
one I could perhaps be persuaded to accept, but renaming the \voicexxx 
constructs would be a major change which is far from justified by the
current rather minor issue - one that has hardly, if ever, figured in
user queries, probably because anyone needing more than two voices
would almost certainly code them explicitly, as 1,3,5 .. 6,4,2 - the
way clearly set out in the manuals, with the numbers corresponding to
the rank of the shifts.

"Kieren MacMillan"  wrote Tuesday, November 01, 2016 8:52 PM

> Regardless of how the individual functions are ultimately named, 
> might I recommend we add a *lot* of syntactic sugar? I have 
> custom functions called "splitX" (workhorses in my code), which 
> remove the need for me to remember how to code such things:

   [pseudocode:]
   \splitUD { topmusic \with UP } { bottommusic \with DOWN }
   \splitUUD { topmusic \with UP } { middlemusic \with UP } { bottommusic \with 
DOWN }
   \splitUDD { topmusic \with UP } { middlemusic \with DOWN } { bottommusic 
\with DOWN }
   etc.

This approach looks much less invasive and quite intuitive.  Worth
exploring further, I think.

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

Re: Changing voice order...

[Kieren MacMillan]

Hi all,

A fascinating thread, for a number of reasons…

Regardless of how the individual functions are ultimately named, might I 
recommend we add a *lot* of syntactic sugar? I have custom functions called 
“splitX” (workhorses in my code), which remove the need for me to remember how 
to code such things:

   [pseudocode:]
   \splitUD { topmusic \with UP } { bottommusic \with DOWN }
   \splitUUD { topmusic \with UP } { middlemusic \with UP } { bottommusic \with 
DOWN }
   \splitUDD { topmusic \with UP } { middlemusic \with DOWN } { bottommusic 
\with DOWN }
   etc.

One the rest of the syntax settles, it might be nice to have two-, three-, 
four-, five-, and maybe more-voice versions of these functions in the standard 
distro, so that people don’t have to use << \\ \\ \\ \\ \\ \\ \\ \\ >> and so 
forth.

Just a thought,
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...

[Thomas Morley]

2016-10-28 1:46 GMT+02:00 Thomas Morley :
> 2016-10-27 13:40 GMT+02:00 David Kastrup :
>>
>> This concerns << ... \\ ... \\ ... ... >>
>>
>> If we have more than one voice, voices are assigned in order:
>>
>> 1/2, 1/2/3, 1/2/3/4, 1/2/3/4/5, 1/2/3/4/5/6 ...
>>
>> while the documentation is quite explicit that, ordered from top to
>> bottom, assignments should be more like
>>
>> 1/2, 3/1/2, 3/1/2/4, 5/3/1/2/4, 5/3/1/2/4/6 ...
>>
>> namely keeping the small voice numbers for the inner voices.  Now I am
>> sort of afraid that changing this is likely to end pretty disruptive to
>> existing scores.  Even though I don't know how many really use the
>> original ordering unchanged as well as intentionally.
>>
>> Thoughts?
>>
>> --
>> David Kastrup
>
>
> I remember the time I was a lilypond-starter, I was pretty confused
> about the order...
>
> I'd vote for doing it better even if it breaks previous user codes.
> Ofcourse we should document all thoroughly and ofcourse there will be
> some complaints on the list, which needs to be adressed.
> We did things like that before, I remember the change with the bar-lines ...
>
> my 2 cents,
>   Harm

I'd wish more users would participate in this discussion.

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

Output attached.
I attach the coding as well, if someone is interested, though be aware
it's not fully elaborated, just enough for purpose.

HTH,
  Harm


atest-46.pdf
Description: Adobe PDF document
\version "2.19.49"

%% creates a StringNumber-grob, which then prints info about context/voiceXxx
annotateVoiceInfo =
#(lambda (ctx)
   (make-engraver
 (acknowledgers
   ((note-column-interface engraver grob source-engraver)
 (let ((nhds (ly:grob-array->list (ly:grob-object grob 'note-heads)))
   (stem (ly:grob-object grob 'stem))
   (stem-dir-shift-list
 ;; obviously incomplete..
 '(((1 . 0) "One")
   ((-1 . 0) "Two")
   ((1 . 1) "Three")
   ((-1 . 1) "Four")
   ((1 . 2) "Five")
   ((-1 . 2) "Six")
   ((1 . 3) "Seven")
   ((-1 . 3) "Eight"
   (for-each
 (lambda (nh)
   (let ((new-grob 
   (ly:engraver-make-grob engraver 'StringNumber '(
 (ly:grob-set-parent! new-grob Y nh)
 (ly:grob-set-property! new-grob 'side-axis Y)
 (ly:grob-set-property! new-grob 'direction UP)
 (ly:grob-set-property! new-grob 'X-offset 7)
 (ly:grob-set-property! new-grob 'stencil
   (grob-interpret-markup new-grob
 (markup 
   #:fontsize -3
   #:vcenter
   #:normal-text 
   (format #f 
" This context has the id: \"~a\",  with settings equal to: \\voice~a" 
 (ly:context-id ctx)
 (car
   (assoc-get 
 (cons (ly:grob-property stem 'direction) 
   (ly:grob-property grob 'horizontal-shift))
 stem-dir-shift-list '("-none" . "")
 nhds))


\layout {
  \context {
\Voice
stringNumberOrientations = #'(right)
\consists \annotateVoiceInfo
  }
}

%% needed for third example, see NR
voiceFive = #(context-spec-music (make-voice-props-set 4)  'Voice)
voiceSix = #(context-spec-music (make-voice-props-set 5)  'Voice)
voiceSeven = #(context-spec-music (make-voice-props-set 6)  'Voice)

{
	
  <>^"In the order the Docs advice, iiuc"
  << c'''2 \\ c' \\ g'' \\ e' \\ e'' \\ g' \\ c''  >>
  
  <>^"Ordered as descending pitches"
  << c'''2 \\ g'' \\ e'' \\ c'' \\ g' \\ e' \\ c' >>
  
  <>^"Ordered as descending pitches with custom voiceXxx-settings"
  << 
  	c'''2 
\\ 
{ \voiceThree g'' } 
\\ 
{ \voiceFive e'' }
\\ 
{ \voiceSeven c'' }
\\ 
{ \voiceSix g' }
\\ 
{ \voiceFour e' }
\\ 
{ \voiceTwo c' } 
  >>
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Exited with return code -1073741819.

[Andrew Bernard]

HI Folks,

I am not sure for whom you mean error prone - the user, or the compiler.

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. This style of coding in indeed obfuscated,
unnecessary, and time consuming to study and fix. Heavy going at the very
least.

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?


Andrew


-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.



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

Re: Changing voice order...

[David Kastrup]

David Wright  writes:

>
>> Now the Voice contexts are still going to be assigned sequentially as
>> "1"/"2", "1"/"2"/"3", "1"/"2"/"3"/"4" (nothing else makes sense really).
>> So in order not to cause confusion by having "1"/"2"/"3"/"4" correspond
>> to "One"/"Three"/"Four"/"Two", 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 ...  Those names are
>> still accurate when more than two voices are involved while the relation
>> between name and behavior for \voiceTwo becomes tenuous as soon as more
>> than two voices are involved.
>
> I would hate   \inner \voiceUp   and would suggest
>
> \voiceTop \voiceHigh \voiceLow \voiceBottom instead¹.

Well, the naming is not something I am particularly enamored with.
\inner has the advantage that it stacks, and that you don't need to
remember whether the default pair was \voiceTop/\voiceBottom or
\voiceHigh/\voiceLow.  Both could also be served by a postfix operator
just incrementing horizontal-shift, so you'd have

<< \voiceUp { \voiceUp \nudge } { \voiceUp \nudge \nudge }
   { \voiceDown \nudge \nudge } { \voiceDown \nudge } \voiceDown >>

The postfix addition has the disadvantage that it no longer forms a
single expression together with \voiceUp/\\voiceDown and the advantage
that it is much simpler to write.  Independently the name \nudge has the
disadvantage of describing not where the voice is located with the
respect to the original, but what is to be done to it.  Which is
typesetting knowledge rather than input structure knowledge and requires
the user to have a clue.  Strictly speaking, this holds for
\voiceUp/\voiceDown as well (the naming is more typical in LilyPond for
describing what to do with stems et al rather than where the voices are
located: in that respect \voiceTop/\voiceBottom might be better).

> It is unfortunate that you have to look ahead so much with << \\ \\ \\ >>

It is not "so much", really, if you take a look how LilyPond does it.
It is one postprocessing phase in the music.

> but that comes with the territory. One more tentative suggestion I
> would make, to keep things slightly simpler, is to ban << \\ \\ >>
> so that you have to explicitly put << \\ {} \\ \\ >> or << \\ \\ {} \\ >>
> for three voices, which at least means there are only two structures
> to deal with.

Don't really see the point.  It's straightforward enough, and if you
don't like it, you need not use it.

> ¹ why not \voiceTop \voiceUp \voiceDown \voiceBottom ? Well, you could
> end up with \voiceUp having stems pointing down,

Uh no?  \voiceUp will always have stems pointing up, and \voiceDown will
have them pointing down.  \inner (or whatever you want to use instead)
just increases the horizontal-shift value and does nothing else.

The whole point of the renaming exercise was that the voice type
commands retain a fixed and predictable meaning.  It's only the << \\ \\
... >> construct which becomes smarter.

-- 
David Kastrup

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

Re: Changing voice order...

[David Wright]

On Tue 01 Nov 2016 at 17:11:30 (+0100), David Kastrup wrote:
> "Phil Holmes"  writes:
> 
> > - Original Message - 
> > From: "David Kastrup" 
> > To: "Trevor Daniels" 
> > Cc: 
> > Sent: Tuesday, November 01, 2016 2:42 PM
> > Subject: Re: Changing voice order...
> >
> >> There are by now two components to my proposal: fading out \voiceOne
> >> ... \voiceFour since they _never_ correspond to voices 1/2/3/4 in a
> >> four-voiced context but to voices 1/4/2/3.  And changing the meaning of
> >> << \\ \\ \\ >>.
> >
> > I'm concerned by this.  I don't believe I have ever used more than 2
> > voices in choral music: typically the sops/tenors get voice one, and
> > the alto/basses get voice two.  If any of these is doubled (e.g. sop1
> > and sop2) then they are shown as chorded notes, still in their normal
> > voice.  If it gets more complex than this, then current vocal music
> > almost always resorts to a stave per vocal group.  It looks to me like
> > the proposal would end up with voiceTwo having upstems.
> 
> Nope.  What is now called \voiceTwo would be renamed to \voiceDown or
> something of that kind.
> 
> > I am very much against that.  It would mean I would have to update a
> > lot of music to make it usable.  I don't use concert-ly 'cos I find it
> > a pain on Windows.
> >
> > Who uses four voices on one stave in vocal setting?
> 
> Using the current meanings of \voiceOne...\voiceFour, you'd get the
> following assignments:
> 
> << \voiceOne \\ \voiceTwo >>
> << \voiceOne \\ \voiceThree \\ \voiceTwo >>
> << \voiceOne \\ \voiceThree \\ \voiceFour \\ \voiceTwo >>
> 
> So the assignment of the \voiceXXX-like settings depends on the number
> of \\ and you cannot deduce the settings before you actually know how
> many \\ constructs are present.  For two voices, your main use case, the
> behavior will be absolutely identical.
> 
> Now the Voice contexts are still going to be assigned sequentially as
> "1"/"2", "1"/"2"/"3", "1"/"2"/"3"/"4" (nothing else makes sense really).
> So in order not to cause confusion by having "1"/"2"/"3"/"4" correspond
> to "One"/"Three"/"Four"/"Two", 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 ...  Those names are
> still accurate when more than two voices are involved while the relation
> between name and behavior for \voiceTwo becomes tenuous as soon as more
> than two voices are involved.

I would hate   \inner \voiceUp   and would suggest

\voiceTop \voiceHigh \voiceLow \voiceBottom instead¹.

It is unfortunate that you have to look ahead so much with << \\ \\ \\ >>
but that comes with the territory. One more tentative suggestion I
would make, to keep things slightly simpler, is to ban << \\ \\ >>
so that you have to explicitly put << \\ {} \\ \\ >> or << \\ \\ {} \\ >>
for three voices, which at least means there are only two structures
to deal with.

¹ why not \voiceTop \voiceUp \voiceDown \voiceBottom ? Well, you could
end up with \voiceUp having stems pointing down, which would be confusing;
ie Up/Down are overloaded, whereas Top/High/Low/Bottom only convey their
(unambigous) position in the staff.

Cheers,
David.

___
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:

> "Br. Samuel Springuel"  writes:
>
>> I'd default the flag to the old behavior while the new one is being
>> worked on and then default it to the new behavior once a stable state
>> has been reached.
>
> I don't see that "the new one" will be worked on for any significant
> amount of time.  The change is not involved.  Its implications aren't.

Its implications _are_.  What an awful "typo" to make.

> Without a rather good track record of convert-ly on LilyPond's code
> base, this change is not going to go through.  Most convert-ly rules are
> "robust" in that you can run them multiple times and only the first
> application will cause a change.  Also the syntax without convert-ly run
> tends to be bad, causing errors.
>
> Neither will be the case here, so that is going to end up a bit of a
> support headache for a while.  On the plus side, \\ is rarely used for
> more than two voices, or if it is, the voice settings tend to get
> overridden manually.  In which case a conversion does not need to do
> much.  I think that a convert-ly rule should likely not change the order
> of entered voices but should just add a command for "flipping the flag"
> instead if more than two \\-separated voices are detected without
> explicit voice setting commands.

-- 
David Kastrup

___
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 Tue 01 Nov 2016 at 15:23:21 (+0100), David Kastrup wrote:
> "Andrew Bernard"  writes:
> > Hi Ming,
> > We have been through this before, I am sorry to say. You write
> > lilypond code in a way that compiles, yes, but it is pathological in
> > the extreme, to put it mildly. You set each and every bar as a
> > variable, and when there are several voices, introduce new parallel
> > voices in every bar. As an example for the others, this is what you
> > do:
> >
> > lft.46 = { <<{g2 f2}\\{d1}>> |}
> >
> > lft.47 = { <<{r4 ef4~ 2}\\{g,1}>> |}
> 
> Those are not "new parallel voices": they still connect.  See:
> 
> {
>   << c''1~ \\ e'1~ >>
>   << c''1 \\ e'1 >>
> }
> 
> << ... \\ ... >> translates to
> << \context Voice = "1" ... \context Voice = "2" ... >>
> 
> so when the parallel voices line up perfectly in time, they still happen
> to connect.  It still makes a hash of understanding the code and
> debugging it and may well trigger rare problems in our context handling.
> 
> Without very good reason, choosing such a non-structure definitely looks
> like creating more problems than it solves.

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.

Anyway, with a few global edits, the source compiles just fine.
Last page attached.

Cheers,
David.


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

Re: Changing voice order...

[David Kastrup]

"Br. Samuel Springuel"  writes:

> I'm not a heavy user, so take my thoughts with whatever grain of salt
> you want, but this is how I would naively expect these constructs to
> work:
>
> << \\ \\ \\ >>
> The voices would be entered in order from top to bottom.  In this way
> the physical structure of the code would resemble the structure of the
> music I'm entering (thanks to line breaks in the code between the
> voices).
>
> \voiceOne \voiceTwo \voiceThree \voiceFour
> The numbers here are confusing.  They could be a top-down enumeration
> of the voices or a more musical outside to inside pattern.  Further,
> the fact that they don't match up with the 1/2/3/4 numbers of the
> implicit code above is even more confusing.  If we stick with numbers,
> then numbers should match.  However it would probably better if we got
> away from numbers altogether here.  Kieren's suggestion of \voiceUp.1
> and \voiceDown.1 seems somewhat more natural, but the numbers still
> have the potential for confusion.  I do not know how to solve this (if
> it's solvable).

That's why I wanted to use something more akin to directions.

> Finally, as a coder I always favor a phased process for changes to the
> user interface so that people have time to adapt to the change.  A
> flag which can flip between the new and old behavior is definitely in
> order until 3.0.0 comes out.

Yes, something like this will be provided for << \\ \\ \\ >> but there
is nothing that can help with \voiceOne/\voiceTwo/\voiceThree/\voiceFour
since those work without context.  So I'd rather phase out those name
choices for something nicer.

> I'd default the flag to the old behavior while the new one is being
> worked on and then default it to the new behavior once a stable state
> has been reached.

I don't see that "the new one" will be worked on for any significant
amount of time.  The change is not involved.  Its implications aren't.
Without a rather good track record of convert-ly on LilyPond's code
base, this change is not going to go through.  Most convert-ly rules are
"robust" in that you can run them multiple times and only the first
application will cause a change.  Also the syntax without convert-ly run
tends to be bad, causing errors.

Neither will be the case here, so that is going to end up a bit of a
support headache for a while.  On the plus side, \\ is rarely used for
more than two voices, or if it is, the voice settings tend to get
overridden manually.  In which case a conversion does not need to do
much.  I think that a convert-ly rule should likely not change the order
of entered voices but should just add a command for "flipping the flag"
instead if more than two \\-separated voices are detected without
explicit voice setting commands.

-- 
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:

> - Original Message - 
> From: "David Kastrup" 
> To: "Trevor Daniels" 
> Cc: 
> Sent: Tuesday, November 01, 2016 2:42 PM
> Subject: Re: Changing voice order...
>
>
>
>> There are by now two components to my proposal: fading out \voiceOne
>> ... \voiceFour since they _never_ correspond to voices 1/2/3/4 in a
>> four-voiced context but to voices 1/4/2/3.  And changing the meaning of
>> << \\ \\ \\ >>.
>
>
> I'm concerned by this.  I don't believe I have ever used more than 2
> voices in choral music: typically the sops/tenors get voice one, and
> the alto/basses get voice two.  If any of these is doubled (e.g. sop1
> and sop2) then they are shown as chorded notes, still in their normal
> voice.  If it gets more complex than this, then current vocal music
> almost always resorts to a stave per vocal group.  It looks to me like
> the proposal would end up with voiceTwo having upstems.

Nope.  What is now called \voiceTwo would be renamed to \voiceDown or
something of that kind.

> I am very much against that.  It would mean I would have to update a
> lot of music to make it usable.  I don't use concert-ly 'cos I find it
> a pain on Windows.
>
> Who uses four voices on one stave in vocal setting?

Using the current meanings of \voiceOne...\voiceFour, you'd get the
following assignments:

<< \voiceOne \\ \voiceTwo >>
<< \voiceOne \\ \voiceThree \\ \voiceTwo >>
<< \voiceOne \\ \voiceThree \\ \voiceFour \\ \voiceTwo >>

So the assignment of the \voiceXXX-like settings depends on the number
of \\ and you cannot deduce the settings before you actually know how
many \\ constructs are present.  For two voices, your main use case, the
behavior will be absolutely identical.

Now the Voice contexts are still going to be assigned sequentially as
"1"/"2", "1"/"2"/"3", "1"/"2"/"3"/"4" (nothing else makes sense really).
So in order not to cause confusion by having "1"/"2"/"3"/"4" correspond
to "One"/"Three"/"Four"/"Two", 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 ...  Those names are
still accurate when more than two voices are involved while the relation
between name and behavior for \voiceTwo becomes tenuous as soon as more
than two voices are involved.

So your objections are to something different than what I propose.
I mean, it could perfectly well be that you still object.  I'd just like
you to object to the actual proposal when you do.  It gives me a better
picture.

-- 
David Kastrup

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

Re: BendSpanner-engraver

[Federico Bruni]

Il giorno mar 1 nov 2016 alle 16:02, Thomas Morley 
 ha scritto:

Federico,

in a private mail you asked about Ties in interplay with bends.
General excluding tied notes from being bend is possible but not a
good idea (see some of the examples in bend-issues-02-excerpt.ly)


These examples are different.
In your example there's an already bent note which is then tied and 
this is made explicitly using \bendHold.
In my example there's a pitch in a chord tied to the same pitch in the 
next chord. There's no intention to bend these notes, but they are bent 
because they are in a chord where there's a bending note.


I think that excluding tied notes would be a good default.
Just a user point of view, no idea about the complexity of 
implementation.




Instead you could use
(1)
\tweak bend-me ##f
which would need to be applied to both bounding NoteHeads of the Tie.
(2)
\override Tie.bend-me = ##f
which is newly implemented


Great, thank you


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

Re: Changing voice order...

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Trevor Daniels" 
Cc: 
Sent: Tuesday, November 01, 2016 2:42 PM
Subject: Re: Changing voice order...




There are by now two components to my proposal: fading out \voiceOne
... \voiceFour since they _never_ correspond to voices 1/2/3/4 in a
four-voiced context but to voices 1/4/2/3.  And changing the meaning of
<< \\ \\ \\ >>.



I'm concerned by this.  I don't believe I have ever used more than 2 voices 
in choral music: typically the sops/tenors get voice one, and the 
alto/basses get voice two.  If any of these is doubled (e.g. sop1 and sop2) 
then they are shown as chorded notes, still in their normal voice.  If it 
gets more complex than this, then current vocal music almost always resorts 
to a stave per vocal group.  It looks to me like the proposal would end up 
with voiceTwo having upstems.  I am very much against that.  It would mean I 
would have to update a lot of music to make it usable.  I don't use 
concert-ly 'cos I find it a pain on Windows.


Who uses four voices on one stave in vocal setting?

--
Phil Holmes 



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

Re: Changing voice order...

[Br. Samuel Springuel]

I'm not a heavy user, so take my thoughts with whatever grain of salt 
you want, but this is how I would naively expect these constructs to work:


<< \\ \\ \\ >>
The voices would be entered in order from top to bottom.  In this way 
the physical structure of the code would resemble the structure of the 
music I'm entering (thanks to line breaks in the code between the voices).


\voiceOne \voiceTwo \voiceThree \voiceFour
The numbers here are confusing.  They could be a top-down enumeration of 
the voices or a more musical outside to inside pattern.  Further, the 
fact that they don't match up with the 1/2/3/4 numbers of the implicit 
code above is even more confusing.  If we stick with numbers, then 
numbers should match.  However it would probably better if we got away 
from numbers altogether here.  Kieren's suggestion of \voiceUp.1 and 
\voiceDown.1 seems somewhat more natural, but the numbers still have the 
potential for confusion.  I do not know how to solve this (if it's 
solvable).


Finally, as a coder I always favor a phased process for changes to the 
user interface so that people have time to adapt to the change.  A flag 
which can flip between the new and old behavior is definitely in order 
until 3.0.0 comes out.  I'd default the flag to the old behavior while 
the new one is being worked on and then default it to the new behavior 
once a stable state has been reached.

--
✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)

PAX ☧ ΧΡΙΣΤΟΣ

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

Re: BendSpanner-engraver

[Thomas Morley]

2016-10-20 12:11 GMT+02:00 Marc Hohl :
> Am 13.09.2016 um 22:41 schrieb Thomas Morley:
> [...]
>>
>> 2016-09-13 8:33 GMT+02:00 Marc Hohl :
>
>
>>> I hope to find the source somewhere to provide you a scan of how it
>>> should
>>> look like.
>>
>>
>> Would be great.
>>
>
> I finally found some examples, but the bend arrows are not quite
> "convincing" ...
>
>
> Marc

Marc,

thanks for the examples.
In the attached bend-issues-02-excerpt.ly you'll find my attempt to
recode them (among others)

Federico,

in a private mail you asked about Ties in interplay with bends.
General excluding tied notes from being bend is possible but not a
good idea (see some of the examples in bend-issues-02-excerpt.ly)
Instead you could use
(1)
\tweak bend-me ##f
which would need to be applied to both bounding NoteHeads of the Tie.
(2)
\override Tie.bend-me = ##f
which is newly implemented

Thus a new release, see attached.


HTH,
  Harm


bend-engraver-03.tar.gz
Description: GNU Zip compressed data
\version "2.19.49"


%%
%% include bend-files
%%
\include "../bend-helpers.ly"
\include "../bend-stencils.ly"
\include "../bend-grob-defs.ly"
\include "../bend-music-functions.ly"

%%
%% layout
%%

\layout {
  indent = 0
  \context {
\Score
\override RehearsalMark.self-alignment-X = #LEFT
  }
  \context {
\Voice
\omit StringNumber
  }
  \context {
\TabVoice
%% next three lines only for better viewing/debugging
\override BendSpanner.color = #red
\override BendSpanner.layer = #20
\override TabNoteHead.whiteout = ##f
\override BendSpanner.details.target-visibility = ##f
  }
}

%%%
%% Examples with two Voices for rare cases
%%%


% 1


\markup \rounded-box \fill-line { "bend to different amounts - two Voices" }

\new TabStaff <<
  \new TabVoice {
  	  \override BendSpanner.details.y-distance-from-tabstaff-to-arrow-tip = 3.3
  	  g'1\preBendHold \startBend a'1~ a'\stopBend\startBend g'\stopBend 
  }
  \new TabVoice { 
  	  \override BendSpanner.details.y-distance-from-tabstaff-to-arrow-tip = 0.7
  	  r1 g,1\startBend a,2\6\stopBend \startBend g,\stopBend r1 
  }
>>


% 2


mI = {
  \grace f'4 \startBend g'4\stopBend \startBend 
  \once \override TabNoteHead.transparent = ##t
  f'8\stopBend
}

mII = {
  \grace d'4 \startBend 
  \once \override NoteColumn.X-offset = 1.5
  ees'4\stopBend\startBend 
  \once \override TabNoteHead.transparent = ##t
  d'8\stopBend
}	
  	
<<
  \new Staff <<
\new Voice { \key bes \major \voiceOne \clef "G_8" \mI }
\new Voice { \voiceTwo \clef "G_8" \mII }
  >>
  \new TabStaff <<
\new TabVoice {
  \override BendSpanner.details.y-distance-from-tabstaff-to-arrow-tip = 3.5
  \mI
}
\new TabVoice { 
  \override BendSpanner.details.y-distance-from-tabstaff-to-arrow-tip = 0.7
  { \voiceTwo \mII }
}
  >>
>>


% 3


\markup \rounded-box \fill-line { 
 "bend to different amounts - two Voices with added articulations" 
}

">." =
\tweak BendSpanner.after-line-breaking 
  #(lambda (grob)
  (ly:grob-set-property! grob 'text
#{
  \markup
\override #'(direction . 1)
\override #'(baseline-skip . 2.5)
\dir-column \halign #CENTER {
  #(ly:grob-property grob 'text) 
  \override #'(baseline-skip . 0.8)
  \center-column {
\musicglyph #"scripts.sforzato"
\musicglyph #"dots.dot"
  }
}
#}))
\etc

musUp = {
  s2. 
  \grace b'!4-\">." \startBend c''8->-.\stopBend b'16( a')~ a'1
}

musDown = {
  s2. 
  \grace g'4\2-\">."\startBend 
  \once \override NoteColumn.X-offset = 1.5
  a'8->-.\2\stopBend g'16(\2 f')\2~ f'1\2
}

<<
  \new Staff <<
  	  \new Voice { \voiceOne \clef "G_8" \musUp }
  	  \new Voice { \voiceTwo \clef "G_8" \musDown }
  >>
  \new TabStaff <<
\new TabVoice
  \musUp
\new TabVoice 
  { \voiceTwo \musDown }
  >>
>>

%%%
%% Example with Ties
%%%

\markup \rounded-box \fill-line { 
  "bend up, no release, bent note is tied"
  "and"
  "bend up, bent note is tied, release"
}
	
\new TabVoice {
  %% use \bendHold to ensure the tied note appears bent
  c'\3\startBend d'\3\stopBend\bendHold\startBend~ d'\3\stopBend
  %% bend up, no release, bent note is tied
  
  c'\3\startBend d'\3\stopBend\bendHold\startBend ~ d'\3~ 
d'\3\stopBend\startBend c'\3\stopBend
 % % bend up, bent note is tied, release
}

%%%
%% Example with Ties, excluding NoteHeads, example by Federico

Re: Question for a FLOSS licensing session

[David Kastrup]

Edward Ardzinski  writes:

> After reading these replies I may not be wiser...but it did occur to
> me that there might be a flaw in my thinking as I do the "programming"
> with Frescobaldi.  Does that have an impact on any of these issues?
> Would have been changed looking back to the "old days" when I used my
> own editor I wrote in Visual C++?

Inasmuch as you start some documents from a Frescobaldi template, there
is a bit of an issue.  However, Frescobaldi templates tend to be
"functional" programming in the legal sense (the most direct expression
with a given functionality without significant leeway for creativity)
and thus are pretty uncontentious anyway.  It does make sense to give an
explicit clarification for the licensing of the template material (does
Frescobaldi do that?) but any attempt to use restrictive licensing on
those skeletons would likely be counterproductive since it would not
encourage significant works licensed differently than intended and
copyright claims are not likely to hold up in court anyway.

-- 
David Kastrup

___
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:

> Simon Albrecht wrote Tuesday, November 01, 2016 10:42 AM
>
>>On 27.10.2016 13:40, David Kastrup wrote:
>>> This concerns << ... \\ ... \\ ... ... >>
>>>
>>> If we have more than one voice, voices are assigned in order:
>>>
>>> 1/2, 1/2/3, 1/2/3/4, 1/2/3/4/5, 1/2/3/4/5/6 ...
>>>
>>> while the documentation is quite explicit that, ordered from top to
>>> bottom, assignments should be more like
>>>
>>> 1/2, 3/1/2, 3/1/2/4, 5/3/1/2/4, 5/3/1/2/4/6 ...
>>
>> That should rather be
>>
>> 1/2, 1/3/2, 1/3/4/2, 1/3/5/4/2, 1/3/5/6/4/2.

See?  Even I get confused by what we have currently.

>> The current mechanism at least provides consistency between the 
>> \voiceOne, \voiceTwo… command names and the order in << \\ \\ >>. And I 
>> don’t see how strict top-down numbering would be less confusing in 
>> general. Indeed, I think that the current rules make a lot of sense, 
>> once one has gotten the idea.
>
> I agree with Simon.  I don't agree the proposed change would be
> clearer.

There are by now two components to my proposal: fading out \voiceOne
... \voiceFour since they _never_ correspond to voices 1/2/3/4 in a
four-voiced context but to voices 1/4/2/3.  And changing the meaning of
<< \\ \\ \\ >>.

> Definitely not worth the hassle.  Far better would be to concentrate
> on improving the documentation, if it is thought that is not clear
> enough.

I think that most work should be accomplished without having to consult
the documentation: vaguely remembering << \\ \\ \\ >> should be enough
to use it again since for a lot of non-trivial tasks there is already
enough documentation that you'll need to consult.  The more stuff works
just like you seem to remember it, the better.  The documentation is no
excuse for a confusing interface.  I'm going to do a LilyPond talk this
weekend: stuff like that is really embarrassing to show and explain.  It
turns people off and establishes the impression that LilyPond is obscure
software for specialists.  I want people to have a great return of value
from reading the documentation: learn about something, and be able to
use it with confidence.

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.  Simply because I have a hard time getting it right myself.

We want our users to be successful musicians, not successful manual
students.  Of course they are related and that relation is a justified
cause of pride to the people maintaining the manuals, but we still
should take care that when in doubt we are putting the horse before the
cart.

-- 
David Kastrup

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

Re: Exited with return code -1073741819.

[David Kastrup]

"Andrew Bernard"  writes:

> Hi Ming,
>
>  
>
> We have been through this before, I am sorry to say. You write
> lilypond code in a way that compiles, yes, but it is pathological in
> the extreme, to put it mildly. You set each and every bar as a
> variable, and when there are several voices, introduce new parallel
> voices in every bar. As an example for the others, this is what you
> do:
>
>  
>
> lft.46 = { <<{g2 f2}\\{d1}>> |}
>
> lft.47 = { <<{r4 ef4~ 2}\\{g,1}>> |}

Those are not "new parallel voices": they still connect.  See:

{
  << c''1~ \\ e'1~ >>
  << c''1 \\ e'1 >>
}

<< ... \\ ... >> translates to
<< \context Voice = "1" ... \context Voice = "2" ... >>

so when the parallel voices line up perfectly in time, they still happen
to connect.  It still makes a hash of understanding the code and
debugging it and may well trigger rare problems in our context handling.

Without very good reason, choosing such a non-structure definitely looks
like creating more problems than it solves.

-- 
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

[Edward Ardzinski]

After reading these replies I may not be wiser...but it did occur to me that
there might be a flaw in my thinking as I do the "programming" with
Frescobaldi.  Does that have an impact on any of these issues?  Would have
been changed looking back to the "old days" when I used my own editor I
wrote in Visual C++?



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Question-for-a-FLOSS-licensing-session-tp195867p195932.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...

[Trevor Daniels]

Simon Albrecht wrote Tuesday, November 01, 2016 10:42 AM

>On 27.10.2016 13:40, David Kastrup wrote:
>> This concerns << ... \\ ... \\ ... ... >>
>>
>> If we have more than one voice, voices are assigned in order:
>>
>> 1/2, 1/2/3, 1/2/3/4, 1/2/3/4/5, 1/2/3/4/5/6 ...
>>
>> while the documentation is quite explicit that, ordered from top to
>> bottom, assignments should be more like
>>
>> 1/2, 3/1/2, 3/1/2/4, 5/3/1/2/4, 5/3/1/2/4/6 ...
>
> That should rather be
>
> 1/2, 1/3/2, 1/3/4/2, 1/3/5/4/2, 1/3/5/6/4/2.
>
> VoiceOne is almost the topmost, and the innermost get the highest numbering.
  always?

>> namely keeping the small voice numbers for the inner voices.  Now I am
>> sort of afraid that changing this is likely to end pretty disruptive to
>> existing scores.  Even though I don't know how many really use the
>> original ordering unchanged as well as intentionally.
>>
>> Thoughts?
>
> The current mechanism at least provides consistency between the 
> \voiceOne, \voiceTwo… command names and the order in << \\ \\ >>. And I 
> don’t see how strict top-down numbering would be less confusing in 
> general. Indeed, I think that the current rules make a lot of sense, 
> once one has gotten the idea.

I agree with Simon.  I don't agree the proposed change would be clearer.

> And as you said: this is a hugely disruptive change. How could backward 
> compatibility be achieved? Maybe using something like
>
> #(use-oldstyle-voice-numbering)
>
> on top level at the beginning of the file.
> IMO it’s definitely not worth the enormous hassle.

Definitely not worth the hassle.  Far better would be to concentrate
on improving the documentation, if it is thought that is not clear
enough.

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

RE: Slur too long

[Andrew Bernard]

Hi Simon,

Strangely no, although perhaps I need to look more closely now that you say
so. But no obvious vertical spacing errors arise from my extensive usage,
and I am pretty sure I would be quick to complain! :-) Odd, this, then.

Andrew


-Original Message-
From: Simon Albrecht 
Sent: Tuesday, 1 November 2016 10:19 PM

I have made several attempts to use it, and each time using the (head x
y) version screws up the whole vertical spacing, certainly linked to the
bugs listed in the openlilylib issue tracker. Which makes me curious - don't
you ever encounter these?



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

RE: Exited with return code -1073741819.

[Andrew Bernard]

Hi Ming,

 

We have been through this before, I am sorry to say. You write lilypond code in 
a way that compiles, yes, but it is pathological in the extreme, to put it 
mildly. You set each and every bar as a variable, and when there are several 
voices, introduce new parallel voices in every bar. As an example for the 
others, this is what you do:

 

lft.46 = { <<{g2 f2}\\{d1}>> |}

lft.47 = { <<{r4 ef4~ 2}\\{g,1}>> |}

lft.48 = \lft.47

lft.49 = { <<{r4 f4~ 2}\\{a,1}>> |}

lft.50 = { <<{r4 e!4 g2}\\{a,2. 4}>> |}

lft.51 = { <<{r4 2.}\\{1}>> |}

lft.52 = { <<{r4 2.}\\{cs'1}>> |}

lft.53 = { <<{r4 2.}\\{c'!1}>> |}

lft.54 = { <<{r4 2.}\\{b1}>> |}

lft.55 = { <<{r4 a4~ 2}\\{d1}>> |}

lft.56 = { <<{r4 c4 a2}\\{f,1}>> |}

lft.57 = { <<{r4 g2.}\\{c1}>> |}

 

 

There is no earthly reason for doing this, and I have no idea where you got 
this idea from. The problem with being idiosyncratic and uniquely individual in 
programming is that it makes it very hard nad needlessly time consuming for 
other people to help you, having to wade through all this non standard 
weirdness. I am not surprised the error keeps shifting around. We had the same 
thing last time if you care to consult your notes. I imagine lilypond sees all 
these needless constructs, and because they are just strange and nobody codes 
like that, latent obscure bugs are triggered with out of resource type errors, 
or who knows what, because nobody would test code that looks like this.

 

Everybody here is prepared to give their time and skill to helping out the 
community, but I am afraid you will have to learn to code in a more normal 
style for piano and SATB with several voices. Do you lack examples? I am sure 
we can find you some.

 

I am sorry if this sounds harsh. It not intended to be a personal criticism nor 
is it an attack, it’s just that a) if you write normal scores I am sure your 
continual issues will evaporate and b) we can really only help when your scores 
are of a more normal form. I hope you understand. I also need to write this 
email to deter others in the future from coming up with strange solutions such 
as the way you encode your work.

 

Andrew

 

 

From: MING TSANG [mailto:tsan...@rogers.com] 
Sent: Tuesday, 1 November 2016 10:22 PM
To: Andrew Bernard 
Cc: Lilypond-usermailinglist 
Subject: Re: Exited with return code -1073741819.

 

Andrew,

Here is the .ly file.

 

I did further compile, now the error appear on left piano bar 54.

 

Thank you for your help.

 

Immanuel,

Ming

 

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

Re: Exited with return code -1073741819.

[MING TSANG]

Andrew,Here is the .ly file.
I did further compile, now the error appear on left piano bar 54.
Thank you for your help.
Immanuel,Ming

  From: Andrew Bernard 
 To: MING TSANG  
Cc: Lilypond-usermailinglist 
 Sent: Tuesday, November 1, 2016 12:21 AM
 Subject: Re: Exited with return code -1073741819.
   
Can you send me the file to examine?
You have had problems like this before I have helped you with. I will wager it 
is the same thing.
Happy to help.
Andrew

On 30 October 2016 at 19:49, MING TSANG  wrote:

hi, lilyponders:
(1).  What is the meaning of the following error message?I have SATB + piano 
score of 100 bars. Each SATB+pianoRH coded with 100 bars. I started to code 
piano-LH and it was all compilable upto bar  45 (no error). But after coded bar 
46, I got the error.
(2)  Window 10 generate the Chinese character onto the file naming, why the 
error message cannot display the UTF-8 Chinese character? 
Thank for the help.



   \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
}
sop.1 = { R1 |}
sop.2 = \sop.1
sop.3 = \sop.1
sop.4 = \sop.1
sop.5 = { \sop.1 \break }
sop.6 = \sop.1
sop.7 = \sop.1
sop.8 = \sop.1
sop.9 = \sop.1
sop.10 = \sop.1
sop.11 = \sop.5
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
sop.22 = { d'4^\markup"Tenderly"^\markup"S.A." a'4 4 4 |}
sop.23 = { a'1 |}
sop.24 = { c'4 g'4 4 4 |}
sop.25 = { g'2( f'2) |\break }
sop.26 = { d'4 a'4 4 b' |}
sop.27 = { c''2 d''4 c''4 |}
sop.28 = { b'4 c'' b' g' |}
sop.29 = { a'1 |\break }
sop.30 = { d'4 a'4 4 4 |}
sop.31 = { a'1 |}
sop.32 = { c'4 g'4 4 4 |}
sop.33 = { g'2( f') |\break }
sop.34 = { f'4 d''4 4 4 |}
sop.35 = { c''4. f'8 4 a' |}
sop.36 = { bf'4 a' g' f' |}
sop.37 = { a'1~ |}
sop.38 = { a'1 |\break }
sop.39 = { a'2 4 4 |}
sop.40 = { g'2 2 |}
sop.41 = { bf'2 4 4 |}
sop.42 = { a'2 2 |\break }
sop.43 = { d''2 4 4 |}
sop.44 = { c''2 a'4 c'' |}
sop.45 = { c''2 bf'4 4 |}
sop.46 = { a'1 |\break }
sop.47 = { g'2 4 a' |}
sop.48 = { bf'4 a' g' bf' |}
sop.49 = { a'1 |}
sop.50 = { a'2 2 |\break }
sop.51 = { d'1 |}
sop.52 = \sop.1
sop.53 = \sop.1
sop.54 = \sop.1
sop.55 = \sop.5
sop.56 = { c'4 f' a' c'' |}
sop.57 = { c''2 r2 |}
sop.58 = { r4 e'8 8 f'4( g') |}
sop.59 = { a'2~ 2 |\break }
sop.60 = { r2 f'8( g') a'( c'') |}
sop.61 = { d''4( c'' b' g') |}
sop.62 = { a'1 |}
sop.63 = { d'4 a'4 4 4 |\break }
sop.64 = { a'1 |}
sop.65 = { c'4 g'4 4 4 |}
sop.66 = { g'2( f'2) |}
sop.67 = { f'4 d''4 4 4 |\break }
sop.68 = { c''4. f'8 4 a' |}
sop.69 = { bf'4 a' g' f' |}
sop.70 = { a'1~ |}
sop.71 = { a'1 |}
sop.72 = { a'2 4 4 |\break }
sop.73 = { g'2 2 |}
sop.74 = { bf'2 4 4 |}
sop.75 = { a'2 2 |}
sop.76 = { d''2 4 4 |\break }
sop.77 = { c''2 a'4 c'' |}
sop.78 = { c''2 bf'4 4 |}
sop.79 = { a'1 |}
sop.80 = { g'2 4 a' |\break }
sop.81 = { bf'4 a' g' bf' |}
sop.82 = { a'1 |}
sop.83 = { a'2 2 |}
sop.84 = { d'1 |}
sop.85 = { \sop.5 \break }
sop.86 = { d'4 a'4 4 4 |}
sop.87 = { a'2( g') |}
sop.88 = \sop.1
sop.89 = \sop.1
sop.90 = { d'4 a'4 4 4 |\break }
sop.91 = { c''4 bf'8( a') g'2 |}
sop.92 = { bf'4 a'8 g' f'2 |}
sop.93 = { a'4 g'8( f') e'4 f'8 e' |}
sop.94 = { d'1 |\break }
sop.95 = \sop.1
sop.96 = \sop.1
sop.97 = \sop.1
sop.98 = \sop.1
sop.99 = { a'1 |}
sop.100 = { a'1 |\bar"|." }
soprano =   {
  \global
  \expandVar \sop 1 100
}
alt.1 = { R1 |}
alt.22 = { d'4 a'4 4 4 |}
alt.39 = { f'2 4 4 |}
alt.40 = { f'2 e' |}
alt.41 = { g'2 4 4 |}
alt.42 = { g'2 f' |}
alt.43 = { f'2 4 g' |}
alt.44 = { g'4( f') 4 4 |}
alt.45 = { e'2 4 4 |}
alt.46 = { e'2( d') |}
alt.47 = { ef'2 4 f' |}
alt.48 = { g'4 f' ef' g' |}
alt.49 = { f'1 |}
alt.50 = { e'!2 2 |}
alt.67 = { f'4 bf'4 4 4 |}
alt.68 = { a'4. f'8 4 a' |}
alt.69 = \sop.69
alt.70 = \sop.70
alt.71 = \sop.71
alt.72 = { f'2 4 4 |}
alt.73 = { f'2 e' |}
alt.74 = { g'2 4 4 |}
alt.75 = { g'2 f' |}
alt.76 = { f'2 4 g' |}
alt.77 = { g'4( f') 4 4 |}
alt.78 = { e'2 4 4 |}
alt.79 = { e'2( d') |}
alt.80 = { ef'2 4 f' |}
alt.81 = { g'4 f' ef' g' |}
alt.82 = { f'1 |}
alt.83 = { a2 2 |}
alt.84 = { d'1 |}
alt.85 = \sop.85
alt.99 = { 1 }
alt.100 = { 1 |}
alto =  {
  \global
  \alt.1
  \expandVar \sop 2 21 %38
  \alt.22
  \expandVar \sop 23 38
  \expandVar \alt 39 50
  \expandVar \sop 51 66
  \expandVar \alt 67 85
  \expandVar \sop 86 98
  \alt.99 \alt.100
}
ten.1 = { R1 |}
ten.22 = \ten.1
ten.23 = \ten.1
ten.24 = \ten.1
ten.25 = \ten.1
ten.26 = 

Re: Slur too long

[Simon Albrecht]

On 01.11.2016 00:30, Andrew Bernard wrote:


Hi Ilja,

Like Harm, I do not think the slur is too long in this case. That is 
right that it extends past the stem and over the flag.


There is a very powerful slur shape function called \shapeII in the 
openlilylib project. You may want to look into this. It gives an easy 
way to attain a high degree of control over the shape of slurs and 
phrasing slurs, and is easier to use than the baseline \shape. It’s 
indispensable – I use it continuously in my scores.




I have made several attempts to use it, and each time using the (head x 
y) version screws up the whole vertical spacing, certainly linked to the 
bugs listed in the openlilylib issue tracker. Which makes me curious – 
don’t you ever encounter these?


Best, Simon

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

Re: Changing voice order...

[Simon Albrecht]

Now I’ve read up the whole thread, I might add some clarification on my 
thoughts.


On 01.11.2016 11:42, Simon Albrecht wrote:
The current mechanism at least provides consistency between the 
\voiceOne, \voiceTwo… command names and the order in << \\ \\ >>. And 
I don’t see how strict top-down numbering would be less confusing in 
general. Indeed, I think that the current rules make a lot of sense, 
once one has gotten the idea.


Perhaps some ASCII art is a nice way of advertising the current logic:

X
  \   X
   \ / \   X
\   /   \ / X
 \ / X
  X

To my mind this makes a lot of sense. Another way to frame this virtue 
of the current way:


<< …voiceOne… \\ …voiceTwo >>
<< …voiceOne… \\ …voiceTwo… \\ …voiceThree… >>
<< …voiceOne… \\ …voiceTwo… \\ …voiceThree… \\ …voiceFour… >>

Adding more voices doesn’t turn everything else up. The progression from 
a two voice layout to a six voice layout is pretty logical, whereas with 
the new proposal of top-bottom-numbering something like this would be 
going back and forth in a way that is at least no better than the 
current snaky alternating between top and bottom.


One would almost never use something like
<< \sopranoI \\ \altoII \\ \sopranoII \\ \altoI >>
anyway – there would be lyrics involved and it very quickly becomes 
necessary to use two staves. For piano music however the alternating 
layout now used is quite sensible. Also, users already have the freedom 
to do things like


<<
  \new Voice { \voiceOne \sopranoI }
  \new Voice { \voiceThree \sopranoII }
  \new Voice { \voiceFour \altoI }
  \new Voice { \voiceTwo \altoII }
>>

There is great versatility available, and many possibilities to adapt to 
different situations.


And as you said: this is a hugely disruptive change. How could 
backward compatibility be achieved? Maybe using something like


#(use-oldstyle-voice-numbering)

on top level at the beginning of the file.
IMO it’s definitely not worth the enormous hassle.

Best, Simon

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



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

Re: Changing voice order...

[Simon Albrecht]

On 27.10.2016 13:40, David Kastrup wrote:

This concerns << ... \\ ... \\ ... ... >>

If we have more than one voice, voices are assigned in order:

1/2, 1/2/3, 1/2/3/4, 1/2/3/4/5, 1/2/3/4/5/6 ...

while the documentation is quite explicit that, ordered from top to
bottom, assignments should be more like

1/2, 3/1/2, 3/1/2/4, 5/3/1/2/4, 5/3/1/2/4/6 ...


That should rather be

1/2, 1/3/2, 1/3/4/2, 1/3/5/4/2, 1/3/5/6/4/2.

VoiceOne is almost the topmost, and the innermost get the highest numbering.


namely keeping the small voice numbers for the inner voices.  Now I am
sort of afraid that changing this is likely to end pretty disruptive to
existing scores.  Even though I don't know how many really use the
original ordering unchanged as well as intentionally.

Thoughts?


The current mechanism at least provides consistency between the 
\voiceOne, \voiceTwo… command names and the order in << \\ \\ >>. And I 
don’t see how strict top-down numbering would be less confusing in 
general. Indeed, I think that the current rules make a lot of sense, 
once one has gotten the idea.


And as you said: this is a hugely disruptive change. How could backward 
compatibility be achieved? Maybe using something like


#(use-oldstyle-voice-numbering)

on top level at the beginning of the file.
IMO it’s definitely not worth the enormous hassle.

Best, Simon

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