Vertical alignment - programming error

[Andrew Bernard]

Using a grace note set that spans two staves, reduced from a vastly more 
complex real score to a more minimal example, if I use a hairpin between the 
sfz and the p indications, I get a programming error related to vertical 
alignment that I am unable to understand, or eliminate. Can folks explain this?

Andrew

— compilation log

Starting lilypond 2.19.29 [exp-k-p11-simpler.ly]...
Processing `/home/andro/work/lilypond/proportion/exp-k-p11-simpler.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
programming error: bounds of this piece aren't breakable.
continuing, cross fingers
Layout output to `/tmp/lilypond-40hIxW'...
Converting to `exp-k-p11-simpler.pdf'...
Deleting `/tmp/lilypond-40hIxW'...
Success: compilation successfully completed
Completed successfully in 0.7”.

— compilation log

— snip
\version "2.19.29"

treble = {
  \clef treble
  \time 1/4

  c''16_\sfz
  \grace {
\bar ""
ees'''8^>]_\sfz\> g''^> f' a' d''
\change Staff = middle
b fis_\p
  }
  \change Staff = top
  \bar "!"
}

bass = {
  \clef bass
  \time 1/4
  c16
}

\score {
  \new PianoStaff
  <<
\new Staff = "top" \with {
}
{ \treble }
\new Staff = "middle" \with {
}
{ \bass }
  >>
  \layout { }
}

— snip


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

Re: Hiding bars and crescendo on last bar of a piece

[Karl Husum]

Brilliant Simon! 
And why would I need to hide a bar full of entries?
In improv pieces I often write all the material out sequencial in a score. Then 
I choose what materiel the different players should use, and I hide the rest of 
the bars.
That way I can have one score a piece, and the individual parts becomes bars 
scattered over the paper.
It looks nice! 

-Karl

Sendt fra min iPhone

> Den 24. okt. 2015 kl. 22.21 skrev Simon Albrecht :
> 
>> On 24.10.2015 15:25, Karl Husum wrote:
>> { c1\mp\<\fermata \bar ":|."| %16
>>   \break
>>   r1\! | %17 }
> 
> The easiest way is using an empty chord <> to attach the \!. It has no 
> duration, so you can just insert it before or after the \bar command:
> 
> {
>  c1\mp\<\fermata <>\! \bar ":|." | %16
> }
> 
> Yours, Simon

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

Trying to displace note heads from stem

[Ryan Michael]

I know there are ways in lilypond to not display the stem. I would
like to do something slightly different, which is to position the note head
associated with a stem at varying distances away from the stem to denote a
relative rhythmic placement which can be seen in Xenakis' Mists
https://www.youtube.com/watch?v=ZH4j70KU-RQ at 3:42 so you can see what I
am trying to achieve.
Thanks!
Ryan.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Trying to displace note heads from stem

[Andrew Bernard]

Use X-offset for the stems.

For example:

  \once \override Stem.X-offset = #n

where n is positive or negative.

Andrew



On 25 Oct 2015, at 17:48, Ryan Michael  wrote:

I know there are ways in lilypond to not display the stem. I would 
like to do something slightly different, which is to position the note head
associated with a stem at varying distances away from the stem to denote a 
relative rhythmic placement which can be seen in Xenakis' Mists 
https://www.youtube.com/watch?v=ZH4j70KU-RQ 
 at 3:42 so you can see what I am 
trying to achieve. 

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

Re: quarter-tone tablatures notation

[David Kastrup]

Thomas Morley  writes:

> Hi Bernardo,
>
> please see attached. Does it fit your needs?

What's the essential difference to the current code?

-- 
David Kastrup

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

Re: quarter-tone tablatures notation

[Thomas Morley]

2015-10-25 8:34 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> Hi Bernardo,
>>
>> please see attached. Does it fit your needs?
>
> What's the essential difference to the current code?
>
> --
> David Kastrup

Current `determine-frets' from scm/translation-functions.scm checks
whether the calculated fret is an integer. If not, it throws a warning
and doesn't print it.
At first glance this makes sense, because there are no frets for
quarter-tones on a fretted instrument like guitar (in standad-tuning).
Though, ofcourse you can produce the quarter-tone pitch via bending,
which then is not represented in the tab.

Basically I changed it to check for (truncate fret) and removed the
according warning (letting the warning for negative frets in place).

This will result in frets like 5/2. Not that nice... So I added a
drawing-routine, `my-format-tab-note-head' to use with
`TabNoteHead.before-line-breaking', printing 2½ in this case. (This
routine has some TODOs, I'm not really happy with it currently)

If we implement it in the source, we could
a)
simply change current code
b)
add an optional argument like `quarter-tones?' to `determine-frets'

Cheers,
  Harm

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

Re: My finances for working on LilyPond

[Chris Yate]

Yes, naturally PayPal takes commission. So does your bank, any credit card
provider, WorldPay or Moneygram or any other similar service. However,
PayPal is secure and reliable enough for Amazon and a huge number of online
stores to be happy using it, not to mention charitable organizations that
benefit from it being so convenient for spur-of-the-moment donations!

As I understand it, there are some differences in the commission payable
for sending money to a friend vs buying a thing, but I've not looked into
it for a couple of years. We were investigating it for managing our
orchestra subs - I think it was about £1.30 for a £40 subscription payment.

Sure they do probably evade/avoid tax. I've given up worrying too much
about that, because I don't want to live my life completely off the grid ;-)

I don't work for them or anything, I just don't understand the paranoia.
Your choice as ever whether you use them.

Anyway, this is probably OT.

Cheers, Chris
On 24 Oct 2015 07:21, "Michael Gerdau"  wrote:

> > I suggest David, or one of the other project owners set up a Paypal
> > account that we can easily fire money off to from anywhere in the world,
> > anonymously.
>
> Paypal ?
>
> I would NEVER pay via Paypal unless it would be absolutely crucial for
> me and there were no other options.
>
> For once to my knowledge Paypal does take a huge amount of the paid
> money. I've been told it is 1/3 on small amounts but that is only
> hearsay, albeit I've been told this by a person to whom I once tried
> to send money via Paypal. In the end we worked out something different.
>
> The other thing is payment definitely is NOT anonymously.
>
> Last not least at least in europe they try to escape normal banking
> regulations by cherry picking their business site, evading national
> legislation etc.
>
> Ever tried to sue Paypal from Germany because you felt they are doing
> you wrong ?
> Good luck - they are based in Luxembourg. You've got to sue them there.
>
> Paypal ? No, Never.
>
> Kind regards,
> Michael
> --
>  Michael Gerdau   email: m...@qata.de
>  GPG-keys available on request or at public keyserver
> ___
> 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: quarter-tone tablatures notation

[David Kastrup]

Thomas Morley  writes:

> 2015-10-25 8:34 GMT+01:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> Hi Bernardo,
>>>
>>> please see attached. Does it fit your needs?
>>
>> What's the essential difference to the current code?
>>
>> --
>> David Kastrup
>
> Current `determine-frets' from scm/translation-functions.scm checks
> whether the calculated fret is an integer. If not, it throws a warning
> and doesn't print it.
> At first glance this makes sense, because there are no frets for
> quarter-tones on a fretted instrument like guitar (in standad-tuning).

Well, "in standard-tuning" is the point.  As originally requested, the
idea was to have some strings tuned to a quartertone offset, and then
determine-frets was supposed to use those.

> Though, ofcourse you can produce the quarter-tone pitch via bending,
> which then is not represented in the tab.
>
> Basically I changed it to check for (truncate fret) and removed the
> according warning (letting the warning for negative frets in place).

But that would then _not_ pick quarter-tone tuned strings unless it
happened to find them before the others, right?

I don't think that we can solve this satisfactorily without _scoring_
found combinations and picking best score.  Or at least make separate
passes with increasingly relaxed conditions, only taking the next pass
when the previous one fails.

Issue 703 suffers from the same problem: I found a viable solution
(patch is in the issue) that would always work as opposed to the default
solution, but that was not accepted by banjo players since the default
is the better solution _iff_ it works.

The fallback solution as opposed to a finer-grained scoring solutions
would have the advantage that it is pretty much predictable, so the
danger that the unhelped fingering is given a different assignment from
one version to the next is slim.  Of course, with the disadvantage that
a scored version will usually be better.  Particularly if there is a
score for fingers retained from the last chord.

-- 
David Kastrup

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

Re: My finances for working on LilyPond

[Wols Lists]

On 25/10/15 11:08, Chris Yate wrote:
> As I understand it, there are some differences in the commission payable
> for sending money to a friend vs buying a thing, but I've not looked
> into it for a couple of years. We were investigating it for managing our
> orchestra subs - I think it was about £1.30 for a £40 subscription payment.

The BIG problem, especially in Europe, is when they flag an account for
"suspected fraud". I seriously hope they don't do it to your orchestra
account just after all the subs have come in ... good luck in getting
your money back!

The problem isn't avoiding tax, it's avoiding the regulations covering
deposit takings, which means, basically, if their computer decides to
walk off with your money, you have precious little hope of getting it back.

And of course, they don't tell you what sort of things flag their "we
think this is fraud" system.

Cheers,
Wol

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

Re: Trying to displace note heads from stem

[Pierre Perol-Schneider]

Hi Ryan,

As each note head has its proper alignment, I don't see how this can be
achieved without using markups.
Long work though...

Something like :

\version "2.19.29"
#(set-global-staff-size 15)
\paper {
  indent = 0
  ragged-right = ##f
}

\new PianoStaff \with {
\omit TimeSignature
\consists #Span_stem_engraver
  } <<
  \new Staff \with {
  \clef G
  \override VerticalAxisGroup.staff-staff-spacing =
#'((basic-distance . 15))
}  <<
\new Voice \relative {
  \voiceOne
  \override Beam.positions = #'(10 . 10)
  \override NoteHead.stencil = ##f
  c'16 16 8 8 16 16 16 8 16
  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1/8)
  \repeat unfold 5 { c16 c c c }
}
\new Voice \relative {
  \voiceTwo
  \override TextScript.padding = #'()
  s16 s
  -\tweak extra-offset #'(-2 . -11)
  ^\markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\score {
  \magnifyMusic 0.8 { a''!4 }
  \layout {
\context {
  \Score
\omit StaffSymbol
\omit Clef
\omit TimeSignature
\omit Stem
  }
}
  }
}
  -\tweak extra-offset #'(-1 . -11.5)
  ^\markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\score {
  \magnifyMusic 0.8 { b''4 }
  \layout {
\context {
  \Score
\omit StaffSymbol
\omit Clef
\omit TimeSignature
\omit Stem
  }
}
  }
}
  }
  >>
  \new Dynamics { s1-\tweak extra-offset #'(1.8 . -1.8) \p s }
  \new Staff \with { \clef F } <<
\new Voice \relative {
  \voiceOne
  \override Beam.stencil = ##f
  \override NoteHead.stencil = ##f
  \crossStaff {
e,16 16 8 8 16 16 16 8 16
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/8)
\repeat unfold 5 { e16 e e e }
  }
}
\new Voice {
  \voiceTwo
  s16
  _\tweak extra-offset #'(-1 . 1.5)
  ^\markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\score {
  \magnifyMusic 0.8 {
c''4
-\tweak extra-offset #'(-1 . -2)
_\markup\concat {
  \lower  #.2 \italic "8"
  \path #0.1 #'((lineto 7 0)(lineto 7 1))
}
  }
  \layout {
\context {
  \Score
\omit StaffSymbol
\omit Clef
\omit TimeSignature
\omit Stem
  }
}
  }
}
  _\tweak extra-offset #'(1.8 . 2)
  ^\markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\score  {
  \magnifyMusic 0.8 { gis'4 }
  \layout {
\context {
  \Score
\omit StaffSymbol
\omit Clef
\omit TimeSignature
\omit Stem
  }
}
  }
}
  _\tweak extra-offset #'(4 . 3.5)
  ^\markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\score  {
  \magnifyMusic 0.8 { fis4 }
  \layout {
\context {
  \Score
\omit StaffSymbol
\omit Clef
\omit TimeSignature
\omit Stem
  }
}
  }
}
}
\new Voice {
  \voiceThree
  s1 \bar "" s
}
  >>
>>

Just thinking,
HTH,
Pierre


2015-10-25 7:48 GMT+01:00 Ryan Michael :

> I know there are ways in lilypond to not display the stem. I would
> like to do something slightly different, which is to position the note head
> associated with a stem at varying distances away from the stem to denote a
> relative rhythmic placement which can be seen in Xenakis' Mists
> https://www.youtube.com/watch?v=ZH4j70KU-RQ at 3:42 so you can see what I
> am trying to achieve.
> Thanks!
> Ryan.
>
>
> ___
> 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

Redundant accidentals after clef changes

[Noah Fields]

Hi all,

I am working on a score for solo viola. There are measures in which I
change from alto clef to treble clef, and then back to alto clef. Each time
there is a clef change, Lilypond rewrites accidentals. I understand the
usefulness of this default, but is there a way to turn this feature off? I
have looked at the accidentalStyles and those do not seem to be applicable.

\version "2.18.2"

\relative c' {
\time 4/4

\clef "alto"
cis4

\clef "treble"
cis

\clef "alto"
cis

r4 |
}

Thank you for any advice.

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

Re: Redundant accidentals after clef changes

[Brian Barker]

At 15:19 25/10/2015 -0500, David Wright wrote:
I'm glad we singers don't meet this sort of thing in "normal" music. 
My own take is for having extra accidentals (ie clef 
changes=>forget) but also the extra cancellations (1471). (Perhaps 
written above.)


[from a position of ignorance of convention.]


For what it's worth, Elaine Gould has no doubt of the convention - 
that such accidentals are required: "An accidental holds good only in 
the clef in which it is written. A change of clef requires a further 
accidental for a note of the same pitch..." (Behind Bars, p 78).


Brian Barker 



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

Re: Using a semi-bold font

[Noeck]

Hi Abraham,

> There's not a convenient pango interface (yet) for selecting variants
> outside the Regular/Italic/Bold/Bold Italic styles. 

That's a pity. But thanks for confirming it.

> However, with the way
> you are doing it, you should be able to just add "Semibold" to the original
> font name and mostly work (i.e., you can then also select the 'italic shape
> of you want). Then you could name the font-family 'semibold or something
> like that for easier identification/differentiation.

Unfortunately I could not get this to work. It only works in the
font-name: font-name = "Linux Libertine O Semibold Italic"
Thus loosing the ability to switch font shapes/series.

Cheers,
Joram

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

Re: My finances for working on LilyPond

[Paul Morris]

> On Oct 22, 2015, at 2:55 PM, ciconia  wrote:
> 
> I'm sure many would agree with me that your hard work (and indeed that of
> all lilypond contributors) is greatly appreciated.

+1  

I hope this appeal will lead to a more financially viable situation that will 
allow you to continue with your valuable LilyPond work.

-Paul


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

Re: Extended mensural notation support for Lilypond

[Noeck]

Hi,

can somebody tell me what happend to this topic:
http://lilypond.1069038.n5.nabble.com/Draft-Extended-mensural-notation-support-td172204.html

I have seen some discussion on devel and also some issues where code
related to this seems to be included in some 2.19 versions. But I could
not find includes like in the zip and I could not include the ly files
in the zip package.

What is the current status with this?
Can I use these things in LilyPond? How?
If it works, can I name the font files differently and select this music
font in the paper block in order to be able to switch back to the normal
music font?

Cheers,
Joram

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

Re: Font shapes for different sizes

[Noeck]

Dear Abraham,

> but I have great plans to remedy this situation. Please stay tuned!

That's good to hear that you are aware of it. I will stay tuned.

> Here are some test runs of what I've done (compared to Emmentaler, using
> the example from the LilyPond essay). They are definitely NOT perfect, but
> hopefully it shows you that I'm on the right track (11pt vs 26pt):

I guess there is a lot of effort in the original Emmentaler font in this
respect. When looking at
http://lilypond.1069038.n5.nabble.com/attachment/182664/0/optical-size-test-collage.png
I see that Emmentaler (and partly Cadence) is the only font where the
time signature numbers touch the staff lines as expected in both sizes.
The same for the clef. Similarly, the note heads do not extend into
neighbouring staff spaces. So it seems this interplay between staff line
thickness and glyphs is quite tricky. — I know that this link is not the
final word as you point out above.

Another funny thing: Do you know what makes the slur having a different
curvature in staff 4, 6 and 11 of your image. IMHO, the flat one looks
better than the default.

> I hope that clarifies what's going on and shows that I'm aware of the
> situation and working on a beautiful solution :-)

I have great confidence in that considering all the beautiful things you
did so far.

Cheers,
Joram

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

Re: quarter-tone tablatures notation

[Thomas Morley]

2015-10-25 21:33 GMT+01:00 Thomas Morley :
> 2015-10-25 13:00 GMT+01:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> 2015-10-25 8:34 GMT+01:00 David Kastrup :
 Thomas Morley  writes:

> Hi Bernardo,
>
> please see attached. Does it fit your needs?

 What's the essential difference to the current code?

 --
 David Kastrup
>>>
>>> Current `determine-frets' from scm/translation-functions.scm checks
>>> whether the calculated fret is an integer. If not, it throws a warning
>>> and doesn't print it.
>>> At first glance this makes sense, because there are no frets for
>>> quarter-tones on a fretted instrument like guitar (in standad-tuning).
>>
>> Well, "in standard-tuning" is the point.  As originally requested, the
>> idea was to have some strings tuned to a quartertone offset, and then
>> determine-frets was supposed to use those.
>
> Well, I tested the following code with default `determine-frets' and
> `my-determine-frets' from my recent post, output attached.
>
> custom-tuning = \stringTuning 
>
> mus = \relative {
>   eeses'
>   eeseh
>   ees
>   eeh
>   e
>   eih
>   eis
>   eisih
>   eisis
> }
>
> tst =
> <<
>   \new Staff << \clef "G_8" \mus >>
>   \new TabStaff \with { stringTunings = \custom-tuning } \mus
>>>
>
> \score {
>   \tst
>   \header { piece = "default-determine-frets" }
> }
>
> \score {
>   \tst
>   \header { piece = "my-determine-frets" }
>   \layout {
> \context {
>   \Score
>   noteToFretFunction = #my-determine-frets
> }
> \context {
>   \TabStaff
>   \override TabNoteHead.before-line-breaking = #my-format-tab-note-head
> }
>   }
> }
>
> The second score looks nicer.
> In a local branch I ran it against our regtest, without result (maybe
> we don't have a regtest with quarter-tone-tuning, didn't check)

Ok. I found a problem: you can't bend an open string ...

>
>
> @users:
> In general, I am a professional guitarist in the classical domain
> never using tablature myself, although I'm able to read most historic
> and modern tablatures.
> (Apart from "deutsche Tabulatur" - for an image see:
> http://www.lautenmusik.net/media/lautenmusik/dt_tab1.gif )
>
> Meaning I'm not very interested in TabStaff. I'll work on it, if users
> say what they want/prefer, where are bugs etc.
> In other words: I need feedback from users, otherwise I'll focus on other 
> stuff.
>
> So far only Federico and BB (as I first posted the code) reported back.
>
>
> Please test against real music!!
>
> Cheers,
>   Harm
>
>>
>>> Though, ofcourse you can produce the quarter-tone pitch via bending,
>>> which then is not represented in the tab.
>>>
>>> Basically I changed it to check for (truncate fret) and removed the
>>> according warning (letting the warning for negative frets in place).
>>
>> But that would then _not_ pick quarter-tone tuned strings unless it
>> happened to find them before the others, right?
>>
>> I don't think that we can solve this satisfactorily without _scoring_
>> found combinations and picking best score.  Or at least make separate
>> passes with increasingly relaxed conditions, only taking the next pass
>> when the previous one fails.
>>
>> Issue 703 suffers from the same problem: I found a viable solution
>> (patch is in the issue) that would always work as opposed to the default
>> solution, but that was not accepted by banjo players since the default
>> is the better solution _iff_ it works.
>>
>> The fallback solution as opposed to a finer-grained scoring solutions
>> would have the advantage that it is pretty much predictable, so the
>> danger that the unhelped fingering is given a different assignment from
>> one version to the next is slim.  Of course, with the disadvantage that
>> a scored version will usually be better.  Particularly if there is a
>> score for fingers retained from the last chord.
>>
>> --
>> David Kastrup

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

Re: quarter-tone tablatures notation

[Federico Bruni]

Il giorno sab 24 ott 2015 alle 20:31, Thomas Morley 
 ha scritto:
 Harm, should I enter an issue in the tracker for this? So if/when 
you have
 time to include it in LilyPond (as you said you'd like to do one 
day) we'll

 know it.


As a reminder, please do. Thanks.


Added:
https://sourceforge.net/p/testlilyissues/issues/4643/


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

Re: Trying to displace note heads from stem

[Pierre Perol-Schneider]

Or shorter :

\version "2.19.29"
#(set-global-staff-size 15)
\paper {
  indent = 0
  ragged-right = ##f
}

xen = #(define-scheme-function (parser location music)
  (ly:music?)
   #{
\markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\score {
  \magnifyMusic 0.8 { $music }
  \layout {
indent = 0
\context {
  \Score
\omit StaffSymbol
\omit Clef
\omit TimeSignature
\omit Stem
  }
}
  }
}
   #})

\new PianoStaff \with {
\omit TimeSignature
\consists #Span_stem_engraver
  } <<
  \new Staff \with {
  \clef G
  \override VerticalAxisGroup.staff-staff-spacing =
#'((basic-distance . 15))
}  <<
\new Voice \relative {
  \voiceOne
  \override Beam.positions = #'(10 . 10)
  \override NoteHead.stencil = ##f
  c'16 16 8 8 16 16 16 8 16
  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1/8)
  \repeat unfold 5 { c16 c c c }
}
\new Voice \relative {
  \voiceTwo
  \override TextScript.padding = #'()
  s16 s
  -\tweak extra-offset #'(-2 . -11)
  ^\xen { a''!4 }
  -\tweak extra-offset #'(-1 . -11.5)
  ^\xen { b''4 }
  }
  >>
  \new Dynamics { s1-\tweak extra-offset #'(1.8 . -1.8) \p s }
  \new Staff \with { \clef F } <<
\new Voice \relative {
  \voiceOne
  \override Beam.stencil = ##f
  \override NoteHead.stencil = ##f
  \crossStaff {
e,16 16 8 8 16 16 16 8 16
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/8)
\repeat unfold 5 { e16 e e e }
  }
}
\new Voice {
  \voiceTwo
  s16
  -\tweak extra-offset #'(-1 . 1.5)
  _\xen {
c''4
-\tweak extra-offset #'(-1 . -2)
_\markup\concat {
  \lower  #.2 \italic "8"
  \path #0.15 #'((lineto 7 0)(lineto 7 1))
}
  }
  -\tweak extra-offset #'(1.8 . 2)
  _\xen { gis'4 }
  -\tweak extra-offset #'(4 . 3.5)
  _\xen { fis4 }
}
\new Voice {
  \voiceThree
  s1 \bar "" s
}
  >>
>>

Cheers,
Pierre

2015-10-25 13:58 GMT+01:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:

> Hi Ryan,
>
> As each note head has its proper alignment, I don't see how this can be
> achieved without using markups.
> Long work though...
>
> Something like :
>
> \version "2.19.29"
> #(set-global-staff-size 15)
> \paper {
>   indent = 0
>   ragged-right = ##f
> }
>
> \new PianoStaff \with {
> \omit TimeSignature
> \consists #Span_stem_engraver
>   } <<
>   \new Staff \with {
>   \clef G
>   \override VerticalAxisGroup.staff-staff-spacing =
> #'((basic-distance . 15))
> }  <<
> \new Voice \relative {
>   \voiceOne
>   \override Beam.positions = #'(10 . 10)
>   \override NoteHead.stencil = ##f
>   c'16 16 8 8 16 16 16 8 16
>   \set subdivideBeams = ##t
>   \set baseMoment = #(ly:make-moment 1/8)
>   \repeat unfold 5 { c16 c c c }
> }
> \new Voice \relative {
>   \voiceTwo
>   \override TextScript.padding = #'()
>   s16 s
>   -\tweak extra-offset #'(-2 . -11)
>   ^\markup {
> \with-dimensions #'(0 . 0) #'(0 . 0)
> \score {
>   \magnifyMusic 0.8 { a''!4 }
>   \layout {
> \context {
>   \Score
> \omit StaffSymbol
> \omit Clef
> \omit TimeSignature
> \omit Stem
>   }
> }
>   }
> }
>   -\tweak extra-offset #'(-1 . -11.5)
>   ^\markup {
> \with-dimensions #'(0 . 0) #'(0 . 0)
> \score {
>   \magnifyMusic 0.8 { b''4 }
>   \layout {
> \context {
>   \Score
> \omit StaffSymbol
> \omit Clef
> \omit TimeSignature
> \omit Stem
>   }
> }
>   }
> }
>   }
>   >>
>   \new Dynamics { s1-\tweak extra-offset #'(1.8 . -1.8) \p s }
>   \new Staff \with { \clef F } <<
> \new Voice \relative {
>   \voiceOne
>   \override Beam.stencil = ##f
>   \override NoteHead.stencil = ##f
>   \crossStaff {
> e,16 16 8 8 16 16 16 8 16
> \set subdivideBeams = ##t
> \set baseMoment = #(ly:make-moment 1/8)
> \repeat unfold 5 { e16 e e e }
>   }
> }
> \new Voice {
>   \voiceTwo
>   s16
>   _\tweak extra-offset #'(-1 . 1.5)
>   ^\markup {
> \with-dimensions #'(0 . 0) #'(0 . 0)
> \score {
>   \magnifyMusic 0.8 {
> c''4
> -\tweak extra-offset #'(-1 . -2)
> _\markup\concat {
>   \lower  #.2 \italic "8"
>   \path #0.1 #'((lineto 7 0)(lineto 7 1))
> }
>   }
>   \layout {
> \context {
>   

Re: My finances for working on LilyPond

[David Kastrup]

Jacques Menu  writes:

> Hello folks,
>
> I’m only an amateur musician, but I really appreciate Lilypond’s
> availability. I haven’t been creating scores any other way since I
> first encountered it at the time of version 2.12.
>
> Current example : Bach’s Magnificat, in which I partly double the
> cello with the bassoon, has many alterations changes. I’m using «
> \accidentalStyle Score.teaching » to have all of them made explicit,
> which greatly helps the bad reader I am.

Well, the current syntax of the command is due to me, and some overhaul
of the internals and making sure that accidentals are repeated after
clef changes (yes, I have read the request by someone else(?) just now
to stop that again but have not yet had the time and/or energy to reply
yet, sorry, willdo eventually).  But the functionality as such was
available from before my time...

> For the same, I transposed a flûte part one half-tone to help the
> player (she’s young and still a music school pupil) getting a better,
> more plain sound using another flute.

Well, I messed with the definition of the \transposition command to make
it somewhat less weird.  But transpositions still are not really the
most fantastic part of LilyPond, particularly with MIDI.

Like with many other things, so much remains to be done...

Probably not worse than other programs though.

> I feel guilty for not having contributed yet, since I’m much indebted
> to the people who make Lilypond alive and evolving, including those
> who provide help on this list.  I’ve been a C++ developper in a former
> life, and I have an idea of the kind of arduous work David Kastrup
> performs with such a big piece of software.  And LP doesn’t benefit
> from support by big computer science companies, as some other open
> software products do.

The OpenSSH(?) situation was remarkably bad for a long time.  Something
used everywhere, and the single core developer no longer able to support
himself.  At least that has made people attentive.  LilyPond is not an
integral part of similarly essential offerings.  Perhaps we need to work
on that in order to make wake-up calls reach bigger money than they
currently do.  It's basically all volunteers without economic dependence
on LilyPond.

> So, David, please send me your IBAN privately, and I’ll fix this
> problem on my side.

Will do.

Thanks!

-- 
David Kastrup

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

Re: My finances for working on LilyPond

[David Kastrup]

Simon Albrecht  writes:

> On 22.10.2015 19:21, David Kastrup wrote:
>> As you all know, my sole source of income are donations from happy
>> LilyPond users.  It would appear that LilyPond users have stopped being
>> happy with my work.
>
> You must know that this is not the case. I should be much surprised if
> I were the only one to appreciate the highly complicated work you do,
> of which the results sometimes are hard to grasp in their immediate
> effect. But that does not diminish their value for the project at all,
> and unless I’m much mistaken nobody currently working on LilyPond
> could rival your understanding of the internals and your ability to
> fix them.

Sounds like a liability more than an asset.  I do hope that I am moving
in a direction where acquiring such understanding will become easier but
the movement is slow as molasses.

In the backend area, I think that of the active programmers, Keith
O'Hara still has a better grasp of what is going on.  Particularly with
regard of weird dependencies so I am aiming to annihilate his advantage
in the long run by getting rid of the need for dealing with weird
dependencies manually.  Cheating, I know.

Dan has been taking up a number of C++ issues recently and also worked
on moving things to more mainstream C++.  David Nalesnik has been doing
impressive things using Scheme alone, and Thomas Morley's contributions
are not to be sneezed at either.  I am glad that there is a bit more
volume of work actually happening since, "understanding of the
internals" or not, solving individual problems is still taking a lot of
time and I am not particularly productive in that area.  Probably
age-related as I've passed 50.

> I do not think one can construe a link between the work you do and the
> sudden (?) decrease of funding;

I don't think it would be sudden.  It's been over a year since I started
procrastinating about even taking a look at my finances and/or writing
about them.  I haven't yet looked further backward yet, but the Paypal
account, usually responsible for a third or so of contributions, has
been pretty dry for at least half a year or so when making small
purchases.

Of course, I'll still have to face the music eventually, but the total
level of my bank account is roughly 4000 down from what I remember about
a year or so ago.  And I actually sold off one accordion in that time.

> indeed, you continue to make quite impressive and important changes.
> I have taken so much profit from your work that it’s about time I gave
> something back. It can’t be as much as I’d certainly like to give, but
> if I don’t remain the only one to take part, it will make a
> difference. Please tell me (privately, I assume) where to direct the
> support. (You probably know that I live in Germany.)

Via separate mail.  Thanks

-- 
David Kastrup

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

Re: Redundant accidentals after clef changes

[David Wright]

Quoting David Kastrup (d...@gnu.org):
> Noah Fields  writes:
> > I am working on a score for solo viola. There are measures in which I
> > change from alto clef to treble clef, and then back to alto clef. Each time
> > there is a clef change, Lilypond rewrites accidentals. I understand the
> > usefulness of this default, but is there a way to turn this feature off? I
> > have looked at the accidentalStyles and those do not seem to be applicable.
> >
> > \version "2.18.2"
> >
> > \relative c' {
> > \time 4/4
> >
> > \clef "alto"
> > cis4
> >
> > \clef "treble"
> > cis
> >
> > \clef "alto"
> > cis
> >
> > r4 |
> > }
> 
> I think it is automatic (and written by me).  Sorry, I don't think that
> there is a specific setting for getting rid of that behavior in
> accidental styles.  If you can make a good explanation of the situations
> where this would be really needed, one can try designing a coherent
> setting for it (not sure how this would really interact with the
> \accidentalStyle command) and change the \accidentalStyle command
> accordingly.
> 
> I _think_ that it's all Scheme anyway, so one could probably program a
> wrapper for the sort of thing that \accidentalStyle does, with the
> wrapper throwing out the respective properties used for making
> reminders.
> 
> Arguably, in your example it might even be a useful _default_ if the
> last of the three accidentals were not printed (but the second would).
> In that case, the accidental style internals would likely have to track
> more information when clefs change than they do now.

I'm guessing that this should be considered along with the related
issue 1471.

I'm glad we singers don't meet this sort of thing in "normal" music.
My own take is for having extra accidentals (ie clef changes⇨forget)
but also the extra cancellations (1471). (Perhaps written above.)

[from a position of ignorance of convention.]

Cheers,
David.

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

Re: quarter-tone tablatures notation

[Thomas Morley]

2015-10-25 13:00 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> 2015-10-25 8:34 GMT+01:00 David Kastrup :
>>> Thomas Morley  writes:
>>>
 Hi Bernardo,

 please see attached. Does it fit your needs?
>>>
>>> What's the essential difference to the current code?
>>>
>>> --
>>> David Kastrup
>>
>> Current `determine-frets' from scm/translation-functions.scm checks
>> whether the calculated fret is an integer. If not, it throws a warning
>> and doesn't print it.
>> At first glance this makes sense, because there are no frets for
>> quarter-tones on a fretted instrument like guitar (in standad-tuning).
>
> Well, "in standard-tuning" is the point.  As originally requested, the
> idea was to have some strings tuned to a quartertone offset, and then
> determine-frets was supposed to use those.

Well, I tested the following code with default `determine-frets' and
`my-determine-frets' from my recent post, output attached.

custom-tuning = \stringTuning 

mus = \relative {
  eeses'
  eeseh
  ees
  eeh
  e
  eih
  eis
  eisih
  eisis
}

tst =
<<
  \new Staff << \clef "G_8" \mus >>
  \new TabStaff \with { stringTunings = \custom-tuning } \mus
>>

\score {
  \tst
  \header { piece = "default-determine-frets" }
}

\score {
  \tst
  \header { piece = "my-determine-frets" }
  \layout {
\context {
  \Score
  noteToFretFunction = #my-determine-frets
}
\context {
  \TabStaff
  \override TabNoteHead.before-line-breaking = #my-format-tab-note-head
}
  }
}

The second score looks nicer.
In a local branch I ran it against our regtest, without result (maybe
we don't have a regtest with quarter-tone-tuning, didn't check)


@users:
In general, I am a professional guitarist in the classical domain
never using tablature myself, although I'm able to read most historic
and modern tablatures.
(Apart from "deutsche Tabulatur" - for an image see:
http://www.lautenmusik.net/media/lautenmusik/dt_tab1.gif )

Meaning I'm not very interested in TabStaff. I'll work on it, if users
say what they want/prefer, where are bugs etc.
In other words: I need feedback from users, otherwise I'll focus on other stuff.

So far only Federico and BB (as I first posted the code) reported back.


Please test against real music!!

Cheers,
  Harm

>
>> Though, ofcourse you can produce the quarter-tone pitch via bending,
>> which then is not represented in the tab.
>>
>> Basically I changed it to check for (truncate fret) and removed the
>> according warning (letting the warning for negative frets in place).
>
> But that would then _not_ pick quarter-tone tuned strings unless it
> happened to find them before the others, right?
>
> I don't think that we can solve this satisfactorily without _scoring_
> found combinations and picking best score.  Or at least make separate
> passes with increasingly relaxed conditions, only taking the next pass
> when the previous one fails.
>
> Issue 703 suffers from the same problem: I found a viable solution
> (patch is in the issue) that would always work as opposed to the default
> solution, but that was not accepted by banjo players since the default
> is the better solution _iff_ it works.
>
> The fallback solution as opposed to a finer-grained scoring solutions
> would have the advantage that it is pretty much predictable, so the
> danger that the unhelped fingering is given a different assignment from
> one version to the next is slim.  Of course, with the disadvantage that
> a scored version will usually be better.  Particularly if there is a
> score for fingers retained from the last chord.
>
> --
> David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: My finances for working on LilyPond

[David Kastrup]

Robert Schmaus  writes:

> I can only subscribe to what Simon (and all other responders) wrote. 
>
> Like Urs pointed out, that the absence of any reports about the
> financial situation on the developer side left me under the impression
> that it wasn't really problematic.

It means I don't want to think about it.  There may be a number of
reasons for that.  There is a tax declaration for 2012 I need to think
about right now, for example, because otherwise the guesses the tax buro
made about a year ago will become final.  And their guesses are way
optimistic, and the final say will be the basis for taxes (or rather for
a refund of what I already paid in order to be able to stop thinking
about it for a while) as well as health insurance payments are based on.

So, uh, "not problematic" is just not a safe guess when I am silent.

> I can understand that it's not pleasant sending out request for
> contributions - maybe someone else on the developer side who's
> familiar with the situation could do that instead on a - say -
> quarterly basis, so everyone's aware of that.

There was a three-month window where I worked very little on LilyPond
(or at least it felt like it) because I fixed the performance of the
"git blame" command which I thought would take about a week.  So I was
too embarrassed to file reports for that comparatively quiescent time
and once I had stopped could not bring myself to start again.

Yes, this is all silly.  But par for my course.

> Apart from that I'd like to contribute as well - please send me the
> relevant information (I live in Germany).

Will come presently, thanks

-- 
David Kastrup

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

Re: Redundant accidentals after clef changes

[Robert Schmaus]

Hi Noah,

I'm not really familiar with accidental styles (as the default is 
perfectly fine for me).


But there's a 'manual' solution which works. I just can't say if it's 
too much extra-input for your taste:


\version "2.18.2"

\relative c' {
\time 4/4

\clef "alto"
cis4

\clef "treble"
\once \omit Accidental cis  % <-- no #

\clef "alto"
cis  % <-- # back up

r4 |
}

Best,
Robert



Am 25/10/15 um 11:15 schrieb Noah Fields:

\version "2.18.2"

\relative c' {
 \time 4/4

 \clef "alto"
 cis4

 \clef "treble"
 cis

 \clef "alto"
 cis

 r4 |
}


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

segmentation fault from 2.19.29

[Paul Scott]

I get a segmentation fault from 2.19.29 that I don't get with
2.19.28.  I'm running 64-bit on Debian sid.  It looks to be size
related so a minimal example doesn't seem to be relevant.

I'd be happy to run any diagnostic that might help.

Paul



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

Re: segmentation fault from 2.19.29

[Paul Scott]

On Sun, Oct 25, 2015 at 08:15:49PM +0100, David Kastrup wrote:
> Paul Scott  writes:
> 
> > I get a segmentation fault from 2.19.29 that I don't get with
> > 2.19.28.  I'm running 64-bit on Debian sid.  It looks to be size
> > related so a minimal example doesn't seem to be relevant.
> 
> Garbage collection while slurs are being processed during the iteration
> stage.  Yes, size-related (due to garbage collection needing to be
> triggered), yes, very very bad.
> 
> Phil is already preparing the release of 2.19.30 right now, one week
> early, in order to fix this awful blunder of mine that unfortunately
> escaped notice until after the release.
> 
> > I'd be happy to run any diagnostic that might help.
> 
> You can hopefully do so using 2.19.30 tomorrow at the latest.

Thank you for your fast response!  2.19.28 is fine for now.  I just like
to run the latest development version.  I will get 2.19.30 when I see it.

Thank you for all you do for Lily.  As soon as I see how we can contribute 
money I will do so.

Paul



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

Re: Note names inside dots

[pls]

Thomas Morley  writes:

> 2015-10-24 23:20 GMT+02:00 Thomas Morley :
>>
>> Well, it's not related to my changes, as far as I can tell. See:
>>
>> \markup {
>>   \fret-diagram-verbose #'(
>> (place-fret 4 0)
>>   )
>> }
>>
>> I could follow this one bac to 2.14.2, the oldest I've installed atm
>>
>> Though, the syntax to enter an open string is `(open 4)', but with
>> this you can't print text inside the dot. It is currently not
>> supported.
>> Nevertheless, I'd call the additional barre a bug.
>>
>> Please file a bug report, if none exists already (didn't check). I may
>> have a look tomorrow (hopefully).
>>
>> Cheers,
>>   Harm
>
> Ok, I looked into it already.
>
> It's this line in fret-diagrams.scm:
> (set! capo-fret (1+ (- capo-fret minfret)))
> Basically, if minfret and capo-fret are both zero, capo-fret is set 1.

This inspired me to set capo to -1 and indeed the capo indication
vanishes:
\version "2.19.30"

\markup
  \override #'(size . 5)
  \override #'(fret-diagram-details . ((finger-code . in-dot)))
  \fill-line {
  \fret-diagram-verbose #`(
(capo -1)
(place-fret 3 0 "g")
  )
  }

(I know it's a dirty trick and I'll write a bug report as soon as I can.)
>
> This is present in 2.14.2 as well, I'll have to think about the reason
> for it (and the consequences changing it)

Thanks for looking into it!

Patrick

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

Re: Redundant accidentals after clef changes

[David Kastrup]

Noah Fields  writes:

> Hi all,
>
> I am working on a score for solo viola. There are measures in which I
> change from alto clef to treble clef, and then back to alto clef. Each time
> there is a clef change, Lilypond rewrites accidentals. I understand the
> usefulness of this default, but is there a way to turn this feature off? I
> have looked at the accidentalStyles and those do not seem to be applicable.
>
> \version "2.18.2"
>
> \relative c' {
> \time 4/4
>
> \clef "alto"
> cis4
>
> \clef "treble"
> cis
>
> \clef "alto"
> cis
>
> r4 |
> }

I think it is automatic (and written by me).  Sorry, I don't think that
there is a specific setting for getting rid of that behavior in
accidental styles.  If you can make a good explanation of the situations
where this would be really needed, one can try designing a coherent
setting for it (not sure how this would really interact with the
\accidentalStyle command) and change the \accidentalStyle command
accordingly.

I _think_ that it's all Scheme anyway, so one could probably program a
wrapper for the sort of thing that \accidentalStyle does, with the
wrapper throwing out the respective properties used for making
reminders.

Arguably, in your example it might even be a useful _default_ if the
last of the three accidentals were not printed (but the second would).
In that case, the accidental style internals would likely have to track
more information when clefs change than they do now.

-- 
David Kastrup

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

Re: segmentation fault from 2.19.29

[David Kastrup]

Paul Scott  writes:

> I get a segmentation fault from 2.19.29 that I don't get with
> 2.19.28.  I'm running 64-bit on Debian sid.  It looks to be size
> related so a minimal example doesn't seem to be relevant.

Garbage collection while slurs are being processed during the iteration
stage.  Yes, size-related (due to garbage collection needing to be
triggered), yes, very very bad.

Phil is already preparing the release of 2.19.30 right now, one week
early, in order to fix this awful blunder of mine that unfortunately
escaped notice until after the release.

> I'd be happy to run any diagnostic that might help.

You can hopefully do so using 2.19.30 tomorrow at the latest.

-- 
David Kastrup

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