Re: staffSize music function unreliable at LP v2.19.16
Simon Albrecht mail.de> writes: > > Well, there’s reason enough to redirect this to bug-lilypond, isn’t > it? Thanks for finding the bug, and confirming that it is a bug and not just a misunderstanding, and narrowing down the cause, and posting to bug-lilypond. The relevant code did not change, but the version of GCC used as a cross- operating-system compiler did change. Some very useful programming languages, including C,have details where behavior is allowed to vary between systems, and here it seems LilyPond inadvertently depended on one of those details. There will probably be a couple more of these strange bugs in 2.19.16 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
On Tue, Mar 3, 2015 at 4:35 PM, Simon Albrecht wrote: > Well, there’s reason enough to redirect this to bug-lilypond, isn’t it? > Somehow, Mozilla Thunderbird messes up the code examples, so I can’t do so > well. Perhaps the OP’s and Harm’s first mails in the thread, respectively, > should suffice for illustration. > > ~Simon > You might add that it appears to be a problem related to the calculation of Stem.default-direction which appears when staff-space is changed. --David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
Well, there’s reason enough to redirect this to bug-lilypond, isn’t it? Somehow, Mozilla Thunderbird messes up the code examples, so I can’t do so well. Perhaps the OP’s and Harm’s first mails in the thread, respectively, should suffice for illustration. ~Simon Am 03.03.2015 um 23:01 schrieb David Nalesnik: On Tue, Mar 3, 2015 at 3:59 PM, David Nalesnik mailto:david.nales...@gmail.com>> wrote: On Tue, Mar 3, 2015 at 3:44 PM, David Nalesnik mailto:david.nales...@gmail.com>> wrote: Harm, On Tue, Mar 3, 2015 at 3:30 PM, Thomas Morley mailto:thomasmorle...@gmail.com>> wrote: thanks for testing. So this function may use as a test-case. No idea whats causing this bug, though. And because I'm not able to reproduce it, I can't help furthermore :( I don't think I could do anything either. I wouldn't know how to build LilyPond for Windows to verify any fix... An observation. In the following snippet, you'll note in the log output that the default-direction of the downstemmed F and B is 0--CENTER. This means that Stem::calc-direction (in lily/stem.cc) will take the property 'neutral-direction. This property is supposed to specify the direction of a note on the midline--B only in our case. F should have a default-direction of 1. Note that adding \override Stem.neutral-direction = #1 fixes the problem for the bad stems. David ___ 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: staffSize music function unreliable at LP v2.19.16
On Tue, Mar 3, 2015 at 3:59 PM, David Nalesnik wrote: > > > On Tue, Mar 3, 2015 at 3:44 PM, David Nalesnik > wrote: > >> Harm, >> >> On Tue, Mar 3, 2015 at 3:30 PM, Thomas Morley >> wrote: >>> >>> >>> thanks for testing. So this function may use as a test-case. >>> >>> No idea whats causing this bug, though. And because I'm not able to >>> reproduce it, I can't help furthermore :( >>> >> >> I don't think I could do anything either. I wouldn't know how to build >> LilyPond for Windows to verify any fix... >> >> > An observation. In the following snippet, you'll note in the log output > that the default-direction of the downstemmed F and B is 0--CENTER. This > means that Stem::calc-direction (in lily/stem.cc) will take the property > 'neutral-direction. This property is supposed to specify the direction of > a note on the midline--B only in our case. F should have a > default-direction of 1. > > Note that adding \override Stem.neutral-direction = #1 fixes the problem for the bad stems. David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
On Tue, Mar 3, 2015 at 3:44 PM, David Nalesnik
wrote:
> Harm,
>
> On Tue, Mar 3, 2015 at 3:30 PM, Thomas Morley
> wrote:
>>
>>
>> thanks for testing. So this function may use as a test-case.
>>
>> No idea whats causing this bug, though. And because I'm not able to
>> reproduce it, I can't help furthermore :(
>>
>
> I don't think I could do anything either. I wouldn't know how to build
> LilyPond for Windows to verify any fix...
>
>
An observation. In the following snippet, you'll note in the log output
that the default-direction of the downstemmed F and B is 0--CENTER. This
means that Stem::calc-direction (in lily/stem.cc) will take the property
'neutral-direction. This property is supposed to specify the direction of
a note on the midline--B only in our case. F should have a
default-direction of 1.
\version "2.19.16"
staffSize = #(define-music-function (parser location new-size)
(number?)
#{
\set fontSize = #new-size
\override StaffSymbol.staff-space = #(magstep new-size)
\override StaffSymbol.thickness = #(magstep new-size)
#})
Ab = \relative c' { f4 g a b c d e f }
\score {
\new Staff \with { \staffSize #2 }
{
\override Stem.after-line-breaking =
#(lambda (grob)
(format #t "~a default-direction: ~a~%"
grob
(ly:grob-property grob 'default-direction)))
\Ab
}
\layout { }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
Harm, On Tue, Mar 3, 2015 at 3:30 PM, Thomas Morley wrote: > > > thanks for testing. So this function may use as a test-case. > > No idea whats causing this bug, though. And because I'm not able to > reproduce it, I can't help furthermore :( > I don't think I could do anything either. I wouldn't know how to build LilyPond for Windows to verify any fix... --David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
2015-03-03 22:15 GMT+01:00 David Nalesnik : > Harm, > > On Tue, Mar 3, 2015 at 2:59 PM, Thomas Morley > wrote: >> >> >> >> 2015-03-03 17:34 GMT+01:00 Kevin Barry : >>> >>> The problem also exists on OSX (10.9.5) with 2.19.16. >>> >>> 2.18.2 still does it correctly. >>> >>> I will test my linux machine later. >>> >>> I'd say this constitutes a regression? The staffSize function doesn't >>> seem to do anything fancy or unusual. >>> >>> On Tue, Mar 3, 2015 at 3:47 PM, Phil Holmes wrote: I can confirm the problem on windows. Using a greater range of notes produces some "interesting" output... -- Phil Holmes >> >> >> Can't confirm on my Linux-machine. > > > Nor on my VM. > >> >> >> I tried to write some test-function, though. >> It puts out a StaffGroup with 81 Staves with different sizes on a huge >> paper. >> View with zoom. ;) >> >> Can someone on windows/OSX confirm buggy output at certain sizes? >> > > Yes, under Windows 7 64-bit, I get the flipped F at the following sizes: > > 3.9, 2.0, 1.4, 1.1, 0.7, 0.5, -0.1, -0.2, -0.3, -0.6, -1.3, -1.4, -3.9. -4.0 > > --David > James, David, thanks for testing. So this function may use as a test-case. No idea whats causing this bug, though. And because I'm not able to reproduce it, I can't help furthermore :( -Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
Cynthia Karl wrote
> The following snippet:
>
> \version "2.19.15"
>
> staffSize = #(define-music-function (parser location new-size) (number?)
> #{
> \set fontSize = #new-size
> \override StaffSymbol #'staff-space = #(magstep new-size)
> \override StaffSymbol #'thickness = #(magstep new-size)
> #})
>
> Ab = \relative c' { f4 g a b }
>
> \score {
> \new Staff \with { \staffSize #2 { \Ab }
> \layout { }
> }
>
> produces at LP v2.19.15:
>
>
>
> but at LP v2.19.16 produces:
>
>
>
> Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13), this
> causes many scores to require an additional page.
>
> Applying convert-ly to the above snippet changes only the \version number.
>
> I tried all values for new-size between -8 and +8; the only ones that
> failed were -4 and 2.
>
> (The staffSize music-function was kindly contributed by Eluze in 2013 on
> this list to overcome limitations of layout-set-staff-size.)
>
>
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> Screen Shot 2015-03-03 at 8.24.10 AM.png (12K)
> ;
> Screen Shot 2015-03-03 at 8.24.24 AM.png (12K)
> ;
Hi all,
I'm not able to reproduce this on my Debian (KDE) machine using Frescobaldi
2.17.2 and LilyPond 2.19.16.
I'm trying...maybe I'm missing something? Sorry, trying to help!
Ben
-
composer | sound designer
LilyPond Tutorials (for beginners) --> http://bit.ly/bcl-lilypond
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/staffSize-music-function-unreliable-at-LP-v2-19-16-tp172534p172550.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: staffSize music function unreliable at LP v2.19.16
Harm, On Tue, Mar 3, 2015 at 2:59 PM, Thomas Morley wrote: > > > 2015-03-03 17:34 GMT+01:00 Kevin Barry : > >> The problem also exists on OSX (10.9.5) with 2.19.16. >> >> 2.18.2 still does it correctly. >> >> I will test my linux machine later. >> >> I'd say this constitutes a regression? The staffSize function doesn't >> seem to do anything fancy or unusual. >> >> On Tue, Mar 3, 2015 at 3:47 PM, Phil Holmes wrote: >> >>> I can confirm the problem on windows. Using a greater range of notes >>> produces some "interesting" output... >>> >>> -- >>> Phil Holmes >>> >> > Can't confirm on my Linux-machine. > Nor on my VM. > > I tried to write some test-function, though. > It puts out a StaffGroup with 81 Staves with different sizes on a huge > paper. > View with zoom. ;) > > Can someone on windows/OSX confirm buggy output at certain sizes? > > Yes, under Windows 7 64-bit, I get the flipped F at the following sizes: 3.9, 2.0, 1.4, 1.1, 0.7, 0.5, -0.1, -0.2, -0.3, -0.6, -1.3, -1.4, -3.9. -4.0 --David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
I've attached the PDF output of your code, as run on my machine: Windows 7,
Frescobaldi 2.17.2, Lily 2.19.16.
James Worlton
On Tue, Mar 3, 2015 at 2:59 PM, Thomas Morley
wrote:
>
>
> 2015-03-03 17:34 GMT+01:00 Kevin Barry :
>
>> The problem also exists on OSX (10.9.5) with 2.19.16.
>>
>> 2.18.2 still does it correctly.
>>
>> I will test my linux machine later.
>>
>> I'd say this constitutes a regression? The staffSize function doesn't
>> seem to do anything fancy or unusual.
>>
>> On Tue, Mar 3, 2015 at 3:47 PM, Phil Holmes wrote:
>>
>>> I can confirm the problem on windows. Using a greater range of notes
>>> produces some "interesting" output...
>>>
>>> --
>>> Phil Holmes
>>>
>>
> Can't confirm on my Linux-machine.
>
> I tried to write some test-function, though.
> It puts out a StaffGroup with 81 Staves with different sizes on a huge
> paper.
> View with zoom. ;)
>
> Can someone on windows/OSX confirm buggy output at certain sizes?
>
>
> \version "2.19.16"
>
> #(set-default-paper-size "b0")
>
> staffSize = #(define-music-function (parser location new-size) (number?)
> #{
> \set fontSize = #new-size
> \override StaffSymbol #'staff-space = #(magstep new-size)
> \override StaffSymbol #'thickness = #(magstep new-size)
> #})
>
> mus = \relative c' { f4 g a b }
>
> \new StaffGroup <<
> $@(map
> (lambda (size nmbr)
>#{
> \new Staff
> \with {
> instrumentName =
> \markup
> \abs-fontsize #10
> #(format #f "Staff Nr. ~a, with staffSize: ~a" nmbr size)
> \staffSize $size
> }
> \mus
>#})
> (iota 81 4 -0.1)
> (iota 81 1))
> >>
>
>
> Cheers,
> Harm
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
stembug.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
2015-03-03 17:34 GMT+01:00 Kevin Barry :
> The problem also exists on OSX (10.9.5) with 2.19.16.
>
> 2.18.2 still does it correctly.
>
> I will test my linux machine later.
>
> I'd say this constitutes a regression? The staffSize function doesn't seem
> to do anything fancy or unusual.
>
> On Tue, Mar 3, 2015 at 3:47 PM, Phil Holmes wrote:
>
>> I can confirm the problem on windows. Using a greater range of notes
>> produces some "interesting" output...
>>
>> --
>> Phil Holmes
>>
>
Can't confirm on my Linux-machine.
I tried to write some test-function, though.
It puts out a StaffGroup with 81 Staves with different sizes on a huge
paper.
View with zoom. ;)
Can someone on windows/OSX confirm buggy output at certain sizes?
\version "2.19.16"
#(set-default-paper-size "b0")
staffSize = #(define-music-function (parser location new-size) (number?)
#{
\set fontSize = #new-size
\override StaffSymbol #'staff-space = #(magstep new-size)
\override StaffSymbol #'thickness = #(magstep new-size)
#})
mus = \relative c' { f4 g a b }
\new StaffGroup <<
$@(map
(lambda (size nmbr)
#{
\new Staff
\with {
instrumentName =
\markup
\abs-fontsize #10
#(format #f "Staff Nr. ~a, with staffSize: ~a" nmbr size)
\staffSize $size
}
\mus
#})
(iota 81 4 -0.1)
(iota 81 1))
>>
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Non-printing score-wide dynamics
On Tue, Mar 03, 2015 at 04:12:23PM +, David Sumbler wrote:
> The first 2 bars of a score are as follows:
>
> invP = \tweak stencil ##f \p
>
> \parallelMusic #'(mid Vone Vtwo Va Vc) {
> % bar 0
> \tempo 4 = 152 \partial 2 r2 |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r8 a\f a a |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
> % bar 1
> r1 |
> r2 r8 a\f a a |
> r8 a\f a a b4-> a |
> bf4-> a g8 f e d |
> d8\f a' d f a f d a\invP |
>
> The "mid" item is a dummy staff (there is no actual staff) which I use
> for tweaking tempi for the midi output: using this I can simulate
> rits, fermatas etc. For the printed score and parts it is not
> referenced at all.
>
> Also in bar 1 I have \invP, which as can be seen produces an invisible
> 'piano' marking: this is simply to avoid the articulate script's
> annoying warnings about ambiguous dynamics (which would be less
> annoying if they told you exactly where in the music the problem
> arose!)
This is a very nice idea! You just solved a problem that I've been
pulling out my hair over, and that is, when you have a <<...\\...>>
section inside a staff (common in piano music, where the number of
logical voices in a single staff change frequently), the midi output
doesn't understand that the dynamics inside the <<...>> should inherit
from the surrounding context. Instead, it defaults to \mf, which
produces horribly jarring output when the surrounding passage is \p. By
inserting invisible dynamics inside the <<...>> to match the surrounding
context, finally I can get some sane output!!
Thanks!!
> However, I have another dynamic problem which it would be nice to get
> around. Later in the music there is a passage marked "dim."; in
> addition, each bar has hairpins < and >. The interpretation of these
> up and down dynamics within a more general diminuendo is easy for
> musicians, but understandably opaque for articulate.ly.
>
> I can get rid of the warnings about this by putting the "dim." into
> the parts as a markup, rather than as a dynamic. But, although it is
> not of vital importance, I wondered if there is some way I could mimic
> the effect of the diminuendo (perhaps by using \f, \mf, \mp etc.
> successively) in much the same way as I can mimic a rallentando by
> using successive \tempo markings in the 'mid' context.
One idea I have that might help, is to define your own volume control
dynamic markings, e.g., "dyn10", "dyn20", "dyn30", ... "dyn100", and
override the Score.dynamicAbsoluteVolumeFunction to assign actual values
to these custom dynamics. Of course, these would be rendered invisible
so that they don't appear in your score. (See below for some actual code
snippets.)
> Actually, I am not really sure what kind of context 'mid' is anyway.
> I do not define it anywhere else: I simply include it with the four
> actual staves (which are defined with \new Staff etc.) in the \score
> block which precedes the \midi command.
>
> How might I add dynamics to 'mid' which would affect all the voices,
> in the same way as \tempo changes do?
[...]
You could just "merge" the 'mid' context into each staff in your midi
score (I include the dynamicAbsoluteVolumeFunction override below, as
illustration):
% This is the score for typesetting: don't use 'mid' at all
\score {
\new Staff { ... }
\new Staff { ... }
... % and so on
% This makes this score generate the typeset output.
\layout{ }
}
% This defines a new Scheme function called 'customDyn' that
% interprets new custom dynamics that we can use to control midi
% dynamics beyond what the default set of dynamics give us.
% Well, the below code doesn't actually give us anything more
% than what we already have, but this is just to illustrate how
% you can define your own arbitrary dynamic markings to refer to
% whatever midi volume levels you want in the output.
#(define (customDyn dynamic)
(cond
((equal? dynamic "dyn10") 0.1)
((equal? dynamic "dyn20") 0.2)
((equal? dynamic "dyn30") 0.3)
((equal? dynamic "dyn40") 0.4)
((equal? dynamic "dyn50") 0.5)
((equal? dynamic "dyn60") 0.6)
((equal? dynamic "dyn70") 0.7)
((equal? dynamic "dyn80") 0.8)
((equal? dynamic "dyn90") 0.9)
(else (default-dynamic-absolute-volume dynamic))
)
)
% This is the score for midi output: it does *not* appear in the
% output.
\score {
% Make the midi performer understand our new custom
% dynamics
\set Score.dynamicAbsoluteVolum
Re: Non-printing score-wide dynamics
Hi David,
I wasn't really able to make sense of everything you said. Have you
considered using a global variable that is in every staff? That can be
useful for adding things (you could put your invisible dynamics in it for
instance).
As for your question about the mid context I'm not sure exactly what you
have done, but it sounds like it's just a standalone music expression? I
would need to see more code to be sure.
Kevin
On Tue, Mar 3, 2015 at 4:12 PM, David Sumbler wrote:
> The first 2 bars of a score are as follows:
>
> invP = \tweak stencil ##f \p
>
> \parallelMusic #'(mid Vone Vtwo Va Vc) {
> % bar 0
> \tempo 4 = 152 \partial 2 r2 |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r8 a\f a a |
> \tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
> % bar 1
> r1 |
> r2 r8 a\f a a |
> r8 a\f a a b4-> a |
> bf4-> a g8 f e d |
> d8\f a' d f a f d a\invP |
>
> The "mid" item is a dummy staff (there is no actual staff) which I use
> for tweaking tempi for the midi output: using this I can simulate rits,
> fermatas etc. For the printed score and parts it is not referenced at
> all.
>
> Also in bar 1 I have \invP, which as can be seen produces an invisible
> 'piano' marking: this is simply to avoid the articulate script's
> annoying warnings about ambiguous dynamics (which would be less annoying
> if they told you exactly where in the music the problem arose!)
>
> However, I have another dynamic problem which it would be nice to get
> around. Later in the music there is a passage marked "dim."; in
> addition, each bar has hairpins < and >. The interpretation of these up
> and down dynamics within a more general diminuendo is easy for
> musicians, but understandably opaque for articulate.ly.
>
> I can get rid of the warnings about this by putting the "dim." into the
> parts as a markup, rather than as a dynamic. But, although it is not of
> vital importance, I wondered if there is some way I could mimic the
> effect of the diminuendo (perhaps by using \f, \mf, \mp etc.
> successively) in much the same way as I can mimic a rallentando by using
> successive \tempo markings in the 'mid' context.
>
> Actually, I am not really sure what kind of context 'mid' is anyway. I
> do not define it anywhere else: I simply include it with the four actual
> staves (which are defined with \new Staff etc.) in the \score block
> which precedes the \midi command.
>
> How might I add dynamics to 'mid' which would affect all the voices, in
> the same way as \tempo changes do?
>
> David
>
>
> ___
> 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: staffSize music function unreliable at LP v2.19.16
The problem also exists on OSX (10.9.5) with 2.19.16.
2.18.2 still does it correctly.
I will test my linux machine later.
I'd say this constitutes a regression? The staffSize function doesn't seem
to do anything fancy or unusual.
On Tue, Mar 3, 2015 at 3:47 PM, Phil Holmes wrote:
> I can confirm the problem on windows. Using a greater range of notes
> produces some "interesting" output...
>
> --
> Phil Holmes
>
>
>
> - Original Message -
> *From:* Pierre Perol-Schneider
> *To:* James Worlton
> *Cc:* Cynthia Karl ; lilypond-user
>
> *Sent:* Tuesday, March 03, 2015 3:26 PM
> *Subject:* Re: staffSize music function unreliable at LP v2.19.16
>
>No problem on my side (see attached).
> OS : Ubuntu 14.10
> Frescobaldi 2.13
> LP 2.19.16
>
> Here's a compilable code:
>
> \version "2.19.16"
>
> staffSize = #(define-music-function (parser location new-size)
>(number?)
> #{
> \set fontSize = #new-size
> \override StaffSymbol.staff-space = #(magstep new-size)
> \override StaffSymbol.thickness = #(magstep new-size)
> #})
>
> Ab = \relative c' { f4 g a b }
>
> \score {
> \new Staff \with { \staffSize #2 } { \Ab }
> \layout { }
> }
>
> Cheers,
> Pierre
>
>
>
> 2015-03-03 16:19 GMT+01:00 James Worlton :
>
>> On Tue, Mar 3, 2015 at 8:37 AM, Cynthia Karl wrote:
>>
>>> The following snippet:
>>>
>>> \version "2.19.15"
>>>
>>> staffSize = #(define-music-function (parser location new-size) (number?)
>>> #{
>>> \set fontSize = #new-size
>>> \override StaffSymbol #'staff-space = #(magstep new-size)
>>> \override StaffSymbol #'thickness = #(magstep new-size)
>>> #})
>>>
>>> Ab = \relative c' { f4 g a b }
>>>
>>> \score {
>>> \new Staff \with { \staffSize #2 { \Ab }
>>> \layout { }
>>> }
>>>
>>> produces at LP v2.19.15:
>>>
>>>
>>> but at LP v2.19.16 produces:
>>>
>>>
>>> Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13),
>>> this causes many scores to require an additional page.
>>>
>>> Applying convert-ly to the above snippet changes only the \version
>>> number.
>>>
>>> I tried all values for new-size between -8 and +8; the only ones that
>>> failed were -4 and 2.
>>>
>>> (The staffSize music-function was kindly contributed by Eluze in 2013 on
>>> this list to overcome limitations of layout-set-staff-size.)
>>>
>>>
>> I have been able to reproduce the problem on Windows 7 with Frescobaldi
>> 2.17.2.
>>
>> Additionally I found that sizes of 2.1, 1.4, 1.1, 0.7, 0.5, -0.2, -0.3,
>> -0.6, -1.3, -1.4, -2.1 also created the down stem on the F. (I only tested
>> 2.1 to -2.1).
>>
>> James Worlton
>>
>>
>>
>> ___
>> 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
>
>
> ___
> 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
Non-printing score-wide dynamics
The first 2 bars of a score are as follows:
invP = \tweak stencil ##f \p
\parallelMusic #'(mid Vone Vtwo Va Vc) {
% bar 0
\tempo 4 = 152 \partial 2 r2 |
\tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
\tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
\tempo "Allegro non troppo" 4 = 152 \partial 2 r8 a\f a a |
\tempo "Allegro non troppo" 4 = 152 \partial 2 r2 |
% bar 1
r1 |
r2 r8 a\f a a |
r8 a\f a a b4-> a |
bf4-> a g8 f e d |
d8\f a' d f a f d a\invP |
The "mid" item is a dummy staff (there is no actual staff) which I use
for tweaking tempi for the midi output: using this I can simulate rits,
fermatas etc. For the printed score and parts it is not referenced at
all.
Also in bar 1 I have \invP, which as can be seen produces an invisible
'piano' marking: this is simply to avoid the articulate script's
annoying warnings about ambiguous dynamics (which would be less annoying
if they told you exactly where in the music the problem arose!)
However, I have another dynamic problem which it would be nice to get
around. Later in the music there is a passage marked "dim."; in
addition, each bar has hairpins < and >. The interpretation of these up
and down dynamics within a more general diminuendo is easy for
musicians, but understandably opaque for articulate.ly.
I can get rid of the warnings about this by putting the "dim." into the
parts as a markup, rather than as a dynamic. But, although it is not of
vital importance, I wondered if there is some way I could mimic the
effect of the diminuendo (perhaps by using \f, \mf, \mp etc.
successively) in much the same way as I can mimic a rallentando by using
successive \tempo markings in the 'mid' context.
Actually, I am not really sure what kind of context 'mid' is anyway. I
do not define it anywhere else: I simply include it with the four actual
staves (which are defined with \new Staff etc.) in the \score block
which precedes the \midi command.
How might I add dynamics to 'mid' which would affect all the voices, in
the same way as \tempo changes do?
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
I can confirm the problem on windows. Using a greater range of notes produces
some "interesting" output...
--
Phil Holmes
- Original Message -
From: Pierre Perol-Schneider
To: James Worlton
Cc: Cynthia Karl ; lilypond-user
Sent: Tuesday, March 03, 2015 3:26 PM
Subject: Re: staffSize music function unreliable at LP v2.19.16
No problem on my side (see attached).
OS : Ubuntu 14.10
Frescobaldi 2.13
LP 2.19.16
Here's a compilable code:
\version "2.19.16"
staffSize = #(define-music-function (parser location new-size)
(number?)
#{
\set fontSize = #new-size
\override StaffSymbol.staff-space = #(magstep new-size)
\override StaffSymbol.thickness = #(magstep new-size)
#})
Ab = \relative c' { f4 g a b }
\score {
\new Staff \with { \staffSize #2 } { \Ab }
\layout { }
}
Cheers,
Pierre
2015-03-03 16:19 GMT+01:00 James Worlton :
On Tue, Mar 3, 2015 at 8:37 AM, Cynthia Karl wrote:
The following snippet:
\version "2.19.15"
staffSize = #(define-music-function (parser location new-size) (number?)
#{
\set fontSize = #new-size
\override StaffSymbol #'staff-space = #(magstep new-size)
\override StaffSymbol #'thickness = #(magstep new-size)
#})
Ab = \relative c' { f4 g a b }
\score {
\new Staff \with { \staffSize #2 { \Ab }
\layout { }
}
produces at LP v2.19.15:
but at LP v2.19.16 produces:
Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13),
this causes many scores to require an additional page.
Applying convert-ly to the above snippet changes only the \version number.
I tried all values for new-size between -8 and +8; the only ones that
failed were -4 and 2.
(The staffSize music-function was kindly contributed by Eluze in 2013 on
this list to overcome limitations of layout-set-staff-size.)
I have been able to reproduce the problem on Windows 7 with Frescobaldi
2.17.2.
Additionally I found that sizes of 2.1, 1.4, 1.1, 0.7, 0.5, -0.2, -0.3,
-0.6, -1.3, -1.4, -2.1 also created the down stem on the F. (I only tested 2.1
to -2.1).
James Worlton
___
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
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
No problem on my side (see attached).
OS : Ubuntu 14.10
Frescobaldi 2.13
LP 2.19.16
Here's a compilable code:
\version "2.19.16"
staffSize = #(define-music-function (parser location new-size)
(number?)
#{
\set fontSize = #new-size
\override StaffSymbol.staff-space = #(magstep new-size)
\override StaffSymbol.thickness = #(magstep new-size)
#})
Ab = \relative c' { f4 g a b }
\score {
\new Staff \with { \staffSize #2 } { \Ab }
\layout { }
}
Cheers,
Pierre
2015-03-03 16:19 GMT+01:00 James Worlton :
> On Tue, Mar 3, 2015 at 8:37 AM, Cynthia Karl wrote:
>
>> The following snippet:
>>
>> \version "2.19.15"
>>
>> staffSize = #(define-music-function (parser location new-size) (number?)
>> #{
>> \set fontSize = #new-size
>> \override StaffSymbol #'staff-space = #(magstep new-size)
>> \override StaffSymbol #'thickness = #(magstep new-size)
>> #})
>>
>> Ab = \relative c' { f4 g a b }
>>
>> \score {
>> \new Staff \with { \staffSize #2 { \Ab }
>> \layout { }
>> }
>>
>> produces at LP v2.19.15:
>>
>>
>> but at LP v2.19.16 produces:
>>
>>
>> Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13),
>> this causes many scores to require an additional page.
>>
>> Applying convert-ly to the above snippet changes only the \version number.
>>
>> I tried all values for new-size between -8 and +8; the only ones that
>> failed were -4 and 2.
>>
>> (The staffSize music-function was kindly contributed by Eluze in 2013 on
>> this list to overcome limitations of layout-set-staff-size.)
>>
>>
> I have been able to reproduce the problem on Windows 7 with Frescobaldi
> 2.17.2.
>
> Additionally I found that sizes of 2.1, 1.4, 1.1, 0.7, 0.5, -0.2, -0.3,
> -0.6, -1.3, -1.4, -2.1 also created the down stem on the F. (I only tested
> 2.1 to -2.1).
>
> James Worlton
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
CK.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
I should add that the original code was missing a right closing brace after
\staffSize #2 to close off the \with block.
James Worlton
On Tue, Mar 3, 2015 at 9:19 AM, James Worlton wrote:
> On Tue, Mar 3, 2015 at 8:37 AM, Cynthia Karl wrote:
>
>> The following snippet:
>>
>> \version "2.19.15"
>>
>> staffSize = #(define-music-function (parser location new-size) (number?)
>> #{
>> \set fontSize = #new-size
>> \override StaffSymbol #'staff-space = #(magstep new-size)
>> \override StaffSymbol #'thickness = #(magstep new-size)
>> #})
>>
>> Ab = \relative c' { f4 g a b }
>>
>> \score {
>> \new Staff \with { \staffSize #2 { \Ab }
>> \layout { }
>> }
>>
>> produces at LP v2.19.15:
>>
>>
>> but at LP v2.19.16 produces:
>>
>>
>> Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13),
>> this causes many scores to require an additional page.
>>
>> Applying convert-ly to the above snippet changes only the \version number.
>>
>> I tried all values for new-size between -8 and +8; the only ones that
>> failed were -4 and 2.
>>
>> (The staffSize music-function was kindly contributed by Eluze in 2013 on
>> this list to overcome limitations of layout-set-staff-size.)
>>
>>
> I have been able to reproduce the problem on Windows 7 with Frescobaldi
> 2.17.2.
>
> Additionally I found that sizes of 2.1, 1.4, 1.1, 0.7, 0.5, -0.2, -0.3,
> -0.6, -1.3, -1.4, -2.1 also created the down stem on the F. (I only tested
> 2.1 to -2.1).
>
> James Worlton
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
On Tue, Mar 3, 2015 at 8:37 AM, Cynthia Karl wrote:
> The following snippet:
>
> \version "2.19.15"
>
> staffSize = #(define-music-function (parser location new-size) (number?)
> #{
> \set fontSize = #new-size
> \override StaffSymbol #'staff-space = #(magstep new-size)
> \override StaffSymbol #'thickness = #(magstep new-size)
> #})
>
> Ab = \relative c' { f4 g a b }
>
> \score {
> \new Staff \with { \staffSize #2 { \Ab }
> \layout { }
> }
>
> produces at LP v2.19.15:
>
>
> but at LP v2.19.16 produces:
>
>
> Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13), this
> causes many scores to require an additional page.
>
> Applying convert-ly to the above snippet changes only the \version number.
>
> I tried all values for new-size between -8 and +8; the only ones that
> failed were -4 and 2.
>
> (The staffSize music-function was kindly contributed by Eluze in 2013 on
> this list to overcome limitations of layout-set-staff-size.)
>
>
I have been able to reproduce the problem on Windows 7 with Frescobaldi
2.17.2.
Additionally I found that sizes of 2.1, 1.4, 1.1, 0.7, 0.5, -0.2, -0.3,
-0.6, -1.3, -1.4, -2.1 also created the down stem on the F. (I only tested
2.1 to -2.1).
James Worlton
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
staffSize music function unreliable at LP v2.19.16
The following snippet:
\version "2.19.15"
staffSize = #(define-music-function (parser location new-size) (number?)
#{
\set fontSize = #new-size
\override StaffSymbol #'staff-space = #(magstep new-size)
\override StaffSymbol #'thickness = #(magstep new-size)
#})
Ab = \relative c' { f4 g a b }
\score {
\new Staff \with { \staffSize #2 { \Ab }
\layout { }
}
produces at LP v2.19.15:
but at LP v2.19.16 produces:
Besides being wrong (see, e.g., "Behind Bars" by Elaine Gould, p.13), this
causes many scores to require an additional page.
Applying convert-ly to the above snippet changes only the \version number.
I tried all values for new-size between -8 and +8; the only ones that failed
were -4 and 2.
(The staffSize music-function was kindly contributed by Eluze in 2013 on this
list to overcome limitations of layout-set-staff-size.)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Getting to grips with ly:parser-include-string
Hi all, I'm feeling more and more stupid by the minute, so I desperately hope to get some help and enlightenment here. I have a function that basically includes a LilyPond file, and it does so quite well. This is the working version of the file: https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/module-handling.ily However, I started to rewrite the file (for some extensibility considerations), and now it doesn't work anymore :-( Here's the work-in-progress file: https://github.com/openlilylib/openlilylib/blob/oll/module-handling/ly/_internal/module-handling.ily (To test: - get the latest version from openLilyLib - ensure you (also) have the ly directory in the include path - open any .ly files in any 'usage-examples' directory below 'ly' - compile them while on the master or while on the oll/module-handling branch ) The file is still included (which can be seen from the diverse debug messages), but - somewhat different with the various main files - it seems definitions in the included files are either ignored or cause errors. I assume it is somehow related to some scoping issue, or that the definitions in the included file somehow don't find their way in the actually used parser. But then I don't see where the _significant_ difference is between the two file versions.. Why does the older version work, after all? The change in the actual include code is based on this discussion: https://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00061.html but I'm quite sure this doesn't have any negative impact on my problem. Any advice would be _greatly_ appreciated. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Subject: String Concatenation, and Use of Unicode characters [sic]
Michael,
Sorry to pipe in so late in this conversation, but have you seen what's
going on at http://fonts.openlilylib.org? Your LilyJAZZ code, etc. is
from the original files, but I've taken them a step further, making it
easier to change music fonts.You might want to update your LilyJAZZ
stuff from there.
Let me know if I can help in any other way.
Happy Engraving,
Abraham
On Mon, Mar 2, 2015 at 11:57 PM, Michael Hendry [via Lilypond]
wrote:
>
>> On 3 Mar 2015, at 05:58, Flaming Hakama by Elaine <[hidden email]>
>> wrote:
>>
>> %{
>>
>> > Date: Mon, 2 Mar 2015 16:40:27 +
>> > From: Michael Hendry <[hidden email]>
>> > Subject: String Concatenation, and Use of Unicode characters
>> >
>> > Typically, I want PDF output in three files, (Concert pitch, Bb
>> and Eb), and I would like to modularise this as much as possible.
>>
>> You will enjoy
>> #(define output-suffix "Instrument”)
>
> Certainly did! Thanks.
>
>>
>>
>> > 2. The LilyJazzText font uses small capitals instead of lower case
>> > letters, so using ?Eb? produces a capital E followed by a small
>> > capital B. On my Mac I know how to produce a flat sign, and
>> LilyPond
>> > will use the flat sign from another font, but I?d like to be able
>> to
>> > define a flat sign as a variable, and append it to the piece
>> markup
>> > when creating the books for trumpet and alto.
>>
>> There is something called \flat. I took out the references to
>> LilyJAZZ just to demonstrate, it should work regardless of font and
>> I didn't have the .ily file handy.
>
> That certainly helped. I’m being fussy now, but there’s
> unnecessary white-space between the “E” and the “b”. Also, I
> want the “Alto Sax in Eb” in a smaller font, and the \flat is
> bigger than I want it.
>
>>
>>
>>
>> Forgive me for suggesting, but I suggest it improves mental health
>> to think of transpose in the form:
>>
>> \transpose "to" "from" \musicExpression
>
> I used to think of the transposition in this way until I found a need
> to transpose the whole piece to a different key (to accommodate a
> singer’s range, for example), and I found the two ways of looking
> at transposition tied my brain in knots.
>
> Ideally, I’d like to define the whole-piece transposition at the
> top of the file, rather than editing the per-instrument transposition
> at the point of book production.
>
>>
>> So, Bb and Eb parts would be:
>>
>> \transpose bes, c \trumpetPartConcert
>> \transpose es, c \altoPartConcert
>>
>> instead of the cryptic:
>>
>> \transpose c d' \trumpetPartConcert
>> \transpose c a' \altoPartConcert
>>
>>
>> Also, I took out references to \jazzOn since it didn't compile.
>>
>>
>> >
>> > Thanks in advance,
>> >
>> > Michael Hendry
>>
>> Sure, I hope this helps.
>
> Very much so.
>
> I’ve attached my modified version of your code, along with the
> necessary include files and an example of the output. I like the
> informal look of the Jazz fonts, but I can still be obsessional about
> font-size mismatches!
>
> Michael
>
>
>
>
>
>
>
> ___
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> Trial.ly (1K) Download Attachment
> LilyJAZZ.ily (27K) Download Attachment
> AccordsJazzDefs.ly (9K) Download Attachment
> Trial-trumpet-Bb.pdf (38K) Download Attachment
>
>
> If you reply to this email, your message will be added to the
> discussion below:
> http://lilypond.1069038.n5.nabble.com/Subject-String-Concatenation-and-Use-of-Unicode-characters-sic-tp172522p172524.html
> To start a new topic under User, email
> ml-node+s1069038n...@n5.nabble.com
> To unsubscribe from Lilypond, click here.
> NAML
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Subject-String-Concatenation-and-Use-of-Unicode-characters-sic-tp172522p172531.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: ugly default output
On Sat, 28 Feb 2015, Martin Tarenskeen wrote: I am typesetting a simple Beethoven 4-mains. I am in the very first stage of entering the notes - without additional tweaks to optimize the output. Having entered one line of music it occurred to me that the spacing looks quite sub-optimal. Not to say plain ugly. Just to close this thread: my current version already looks much better. The solution I choose was to use a4 landscape papersize/mode. Not uncommon for quatre mains repertoire. See attachment. My Lilypond sourcecode makes it quite easy for me to produce separate pages for Primo and Secundo also. -- MT Beethoven-Dans-I-All.pdf Description: Adobe PDF document ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
