Problem with glissandi in 2.15.15
I'm using glissandi to indicate slides in fingering. The following code
should give me a glissando between the fingering digits (it did in older
versions), but on 2.15.15 I get no glissando at all:
\version "2.15.15"
\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
4\glissando
}
Nick
<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problem with glissandi in 2.15.15
On Oct 28, 2011, at 10:57 AM, Nick Payne wrote:
> I'm using glissandi to indicate slides in fingering. The following code
> should give me a glissando between the fingering digits (it did in older
> versions), but on 2.15.15 I get no glissando at all:
>
> \version "2.15.15"
>
> \relative c'' {
>\override Fingering #'staff-padding = #'()
>\once \override Glissando #'extra-offset = #'(0 . 1.4)
> 4\glissando
> }
>
You have to tell it not to end on the accidental.
\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
\once \override Glissando #'bound-details #'right #'end-on-accidental = ##f
4\glissando
}
There are more accurate & automated ways of doing this, though. If you create
a Scheme engraver that acknowledges fingerings and glissandi and then override
the Y positions to match up with these fingerings, you don't need to use the
extra offset. Check out scheme-engraver-instance.ly and scheme-engraver.ly in
input/regression.
Cheers,
MS
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problem with glissandi in 2.15.15
On 28/10/11 20:16, m...@apollinemike.com wrote:
On Oct 28, 2011, at 10:57 AM, Nick Payne wrote:
I'm using glissandi to indicate slides in fingering. The following code should
give me a glissando between the fingering digits (it did in older versions),
but on 2.15.15 I get no glissando at all:
\version "2.15.15"
\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
4\glissando
}
You have to tell it not to end on the accidental.
\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
\once \override Glissando #'bound-details #'right #'end-on-accidental = ##f
4\glissando
}
There are more accurate& automated ways of doing this, though. If you create
a Scheme engraver that acknowledges fingerings and glissandi and then override the
Y positions to match up with these fingerings, you don't need to use the extra
offset. Check out scheme-engraver-instance.ly and scheme-engraver.ly in
input/regression.
Thanks. That does fix it.
Where do I find scheme-engraver-instance.ly and scheme-engraver.ly. They
aren't anywhere under /usr/local/lilypond in my installation...
Nick
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problem with glissandi in 2.15.15
- Original Message -
From: "Nick Payne"
To:
Cc:
Sent: Friday, October 28, 2011 11:36 AM
Subject: Re: Problem with glissandi in 2.15.15
On 28/10/11 20:16, m...@apollinemike.com wrote:
On Oct 28, 2011, at 10:57 AM, Nick Payne wrote:
I'm using glissandi to indicate slides in fingering. The following code
should give me a glissando between the fingering digits (it did in older
versions), but on 2.15.15 I get no glissando at all:
\version "2.15.15"
\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
4\glissando
}
You have to tell it not to end on the accidental.
\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
\once \override Glissando #'bound-details #'right #'end-on-accidental
= ##f
4\glissando
}
There are more accurate& automated ways of doing this, though. If you
create a Scheme engraver that acknowledges fingerings and glissandi and
then override the Y positions to match up with these fingerings, you
don't need to use the extra offset. Check out
scheme-engraver-instance.ly and scheme-engraver.ly in input/regression.
Thanks. That does fix it.
Where do I find scheme-engraver-instance.ly and scheme-engraver.ly. They
aren't anywhere under /usr/local/lilypond in my installation...
Nick
They'll be in the source code, in the directory Mike has mentioned.
--
Phil Holmes
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Making feathered beams more variable
Hi David,
2011/10/28 David Nalesnik
> Hi Harm,
>
> On Tue, Oct 25, 2011 at 12:05 PM, harm6 wrote:
>
>>
>> Hi David,
>>
>> David Nalesnik-2 wrote:
>> >
>> > Hi Harm,
>> >
>> > On Mon, Oct 24, 2011 at 4:09 PM, Thomas Morley <
>> > thomasmorle...@googlemail.com> wrote:
>>
>> I'm looking for a method to integrate something like:
>>
>> (if (= number 0)
>> use: \override Beam #'grow-direction = #LEFT
>> (if (>= number stem-count)
>> use: \override Beam #'grow-direction = #RIGHT
>> otherwise use: \override Beam #'stencil = (grow-beam-var arg)
>>
>> into the Beam-stencil-override.
>>
>> I'm aware of the possibility to create a function to do that, but this is
>> not intended.
>>
>> So, is it possible to program (grob-property-set! grob 'grow-direction
>> LEFT)
>> somewhere in a stencil-override?
>>
>>
> I'm not sure I understand what you want here. Would you like to duplicate
> the effect of these overrides in the function (say by adding in null
> stencils), or actually call them when certain conditions are met? The
> attached file does the latter.
>
Sorry, if I wasn't clear, but you did understand what I wanted! :)
Now it works fine.
(...)
There are two problems left.
>> First tiny problem:
>> The output with kneed-beams is ugly in some cases:
>> This example gives a overlooking stem at beam-end (test-code only)
>>
>> xy = \once\override Stem #'french-beaming = ##t
>>
>> \relative c {
>>\once\override Beam #'stencil = #(grow-beam-var 5)
>>f32 [ \xy f''' f,,, \xy f''' f,,, \xy f''' f,,, \xy f''' f,,, \xy
>> f''']
>> }
>>
>> I'm not sure how to fix. 'french-beaming only works with the inner stems.
>> Is there a default-command I can't find? Should I integrate something into
>> the definition of grow-beam-var? Or create a separate override for this
>> stem?
>>
>>
> I don't know if there's a setting to allow 'french-beaming to work with
> outer stems of a beam group. (I checked some Durand scores of Messiaen, and
> sure enough, the outer stems span the entire beam.) I tried various
> overrides to adjust the length of the final stem only, and the solution I
> got to work is this:
>
> xy = \once\override Stem #'french-beaming = ##t
>
> \relative c {
> \once \override Beam #'stencil = #(grow-beam-var 5)
> f32 [ \xy f''' f,,, \xy f''' f,,, \xy f''' f,,, \xy f''' f,,, \xy
> \once \override Stem #'stencil = #(lambda (grob) (ly:grob-set-property!
> grob 'length 11)
> (ly:stem::print grob))
> f''']
> }
>
I changed your suggestion to a function (I've no problems using a function
in this case) and tested both:
1. It doesn't works with "2.14.2", but with "2.15.13" there are no problems.
Does it work with "2.14.2" for you?
2. Using it with \change Staff doesn't work! Maybe an issue with \change
Staff?
\version "2.15.13"
xy = \once\override Stem #'french-beaming = ##t
#(define ((stem-length y) grob)
(ly:grob-set-property! grob 'length y)
(ly:stem::print grob))
xyOut =
#(define-music-function (parser location y-length)(number?)
#{
\once \override Stem #'stencil = #(stem-length $y-length)
#})
% This works
\relative c {
\once \override Beam #'stencil = #(grow-beam-var 5)
f32 [ \xy f''' f,,, \xy f''' f,,, \xy f''' f,,, \xy f''' f,,,
\xyOut #11
f''']
}
% This not. Issue in \change Staff ?
top = \change Staff = "1"
bottom = \change Staff = "2"
music = \relative c {
\override Beam #'auto-knee-gap = #0
\override Beam #'stencil = #(grow-beam-var 1)
\bottom cis32[
f
%\xyOut #0
\once \override Stem #'stencil = #(lambda (grob) (ly:grob-set-property!
grob 'length 0)
(ly:stem::print grob))
\top f'']
}
\score {
\new PianoStaff <<
\new Staff = "1" {
s16.
}
\new Staff = "2" {
\clef bass
\music
}
>>
}
>
>
>> Regarding the following example I'm not sure: should the peak point up or
>> down? What do you think?
>>
>> \relative c' {
>>\override Beam #'auto-knee-gap = #4
>>\override Beam #'stencil = #(grow-beam-var 16)
>>c''32 [b a g
>>f g a b
>>c b a g
>>f g a b
>>e,,, c''' b a
>>g a b c
>>d c b a
>>g a b c]
>>c1
>> }
>>
>
> Well, with the current position of the beam, what you have is the only
> option. Otherwise the beam will cover the ledger lines.
>
To avoid covering the ledger lines I used a 'positions-override and changed
the function a little to get the possibility to turn the peak up or down, if
I use negative values. But only if the beam is kneed and level. I'm afraid
it would be too much work to generalize this feature, needed only in very
special cases.
See attached file.
>
>> Second problem.
>> I tried to use \featherDuration with my Definition, but it doesn't work as
>> expected (seems it works only once a beam):
>>
>> (...)
>>
>
> There's a "known warning" about \featherDurations which applies here, I
> think. You have too many notes in the group. Your beams work with this
> short example:
>
Re: Making feathered beams more variable
Hi Harm, On Fri, Oct 28, 2011 at 8:18 AM, Thomas Morley < thomasmorle...@googlemail.com> wrote: > Hi David, > > 2011/10/28 David Nalesnik > >> [ . . . ] > > >> Maybe you could think of some artful way to modify the function in >> music-functions-init.ly to incorporate the increase/decrease. That way >> you could handle the peak smoothly. >> > I worked on this a bit, and I came up with something which will handle the accel./rit. pattern which you've been using with your feathered beam function. It works just like \featherDurations, except you add two additional arguments, a number representing the number of notes it takes to get to the fastest value and another number representing the number of notes left over. Sort of :) It's a bit unclear what the numbers mean, so I left a line in the function which displays the pattern to the log so you can see what's going on. (What do you think each number should represent? Also, is there an easy way to determine the number of notes in the pattern automatically?) I'm sure there's a lot of room for improvement here. (For one thing, how about starting fast, getting slower, then faster again?) But this seems to work . . . so far :) -David feather-test01.ly Description: Binary data <>___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Making feathered beams more variable
Hi again, On Fri, Oct 28, 2011 at 4:31 PM, David Nalesnik wrote: > > I worked on this a bit, and I came up with something which will handle the > accel./rit. pattern which you've been using with your feathered beam > function. It works just like \featherDurations, except you add two > additional arguments, a number representing the number of notes it takes to > get to the fastest value and another number representing the number of notes > left over. Sort of :) It's a bit unclear what the numbers mean, so I left > a line in the function which displays the pattern to the log so you can see > what's going on. (What do you think each number should represent? Also, is > there an easy way to determine the number of notes in the pattern > automatically?) > > I'm sure there's a lot of room for improvement here. (For one thing, how > about starting fast, getting slower, then faster again?) But this seems to > work . . . so far :) > > The attached should work with accel./rit. and rit./accel. There is only one extra argument now, which represents the position of the "turnaround". This can't be larger than the number of notes in the group. If you notice any problems or think of a way to make this more effective/less tangled please let me know! -David feather-test01.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
