Re: Beaming over a rest before a subdivision

2016-01-13 Thread Urs Liska


Am 13.01.2016 um 10:08 schrieb Mark Knoop:
> At 22:57 on 12 Jan 2016, Urs Liska wrote:
>> Am 12.01.2016 um 20:59 schrieb Werner LEMBERG:
 What should the behavior of the *last* one be here?  
>>> No beams over the rest.  
>> Well, default behaviour is to break the beam at all rests here (see
>> attached).
> Not sure if this is relevant to your current work on this, but it would
> be great to have a global override to create beams over rests WITHOUT
> having to manually enter them. The implementation would need quite some
> thought as to the kind of parameters needed, e.g. maximum-rest-value,
> minimum-beam-count, etc.
>

This is conceptually relevant but practically a different issue. Not
only because of the mentioned complexity (which I'd rather *not* touch
in addition to everything else) but also because it's a different place
in the code as well. The code I am working on takes a given beam for
granted. Deciding what to beam automatically has already been done by
that time. And for the beaming pattern it doesn't make a difference
whether the beam has been created manually or automatically.

So I suggest you post a feature request to bug-lilypond.

Urs

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


Re: Beaming over a rest before a subdivision

2016-01-13 Thread Mark Knoop
At 22:57 on 12 Jan 2016, Urs Liska wrote:
>Am 12.01.2016 um 20:59 schrieb Werner LEMBERG:
>>> What should the behavior of the *last* one be here?  
>> No beams over the rest.  
>
>Well, default behaviour is to break the beam at all rests here (see
>attached).

Not sure if this is relevant to your current work on this, but it would
be great to have a global override to create beams over rests WITHOUT
having to manually enter them. The implementation would need quite some
thought as to the kind of parameters needed, e.g. maximum-rest-value,
minimum-beam-count, etc.

-- 
Mark Knoop

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


Re: startGraceMusic

2016-01-13 Thread Simon Albrecht

On 13.01.2016 07:27, Andrew Bernard wrote:
There are startGraceMusic and stopGraceMusic functions that are 
helpful for adjusting the appearance of grace notes. Are there 
startAfterGraceMusic etc functions for \afterGrace? Currently I have 
to manually adjust afterGrace notes to be the same as that in the 
startGraceMusic function I have. Works fine, but it is tedious and 
error prone.


\afterGrace is a music function, defined in ly/music-functions-init.ly 
as follows:


%% keep these two together
afterGraceFraction = #(cons 6 8)
afterGrace =
#(define-music-function (main grace) (ly:music? ly:music?)
   (_i "Create @var{grace} note(s) after a @var{main} music expression.")
   (let ((main-length (ly:music-length main))
 (fraction  (ly:parser-lookup 'afterGraceFraction)))
 (make-simultaneous-music
  (list
   main
   (make-sequential-music
(list

 (make-music 'SkipMusic
 'duration (ly:make-duration
0 0
(* (ly:moment-main-numerator main-length)
   (car fraction))
(* (ly:moment-main-denominator main-length)
   (cdr fraction
 (make-music 'GraceMusic
 'element grace)))

Just adjust to taste and redefine it.

Best, Simon

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


Re: Outliner markup command

2016-01-13 Thread Pierre Perol-Schneider
Hi Harm,

2016-01-13 0:09 GMT+01:00 Thomas Morley :


> You can't hope a markup-command will accept an override for a
> property, if said property isn't declared in any way.
>

Well, I thought it *was *declared since the code description says :
"This function works by creating a series of white or @var{color}
stencils"

Anyway, I'm far from fully understanding Paul's (?) coding.

...
> First one is ok.
> But in the second one the color from the stencil is taken (green) and
> the specified (red) is ignored.
> Will investigate more detailed the upcoming days.
>

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


Re: Outliner markup command

2016-01-13 Thread Pierre Perol-Schneider
OK thanks David.

2016-01-13 13:45 GMT+01:00 David Kastrup :

> Pierre Perol-Schneider  writes:
>
> > Hi David,
> >
> > 2016-01-12 23:52 GMT+01:00 David Kastrup :
> >
> >
> >> \override #`(color . ,red)
> >>
> >> And yes, I use a backward tick here.  The forward tick will not
> >> cooperate with the comma later.
> >>
> >
> > I'm not sure to clearly understand what I can do here but i'll
> > investigate anyhow.
>
> This is the correct version of the \override #'(color . red) you wrote
> which does not work.  Whether the above works depends on whether the
> following markup actually uses the color property, of course.  But your
> version would not have worked with any command.
>
> --
> David Kastrup
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Outliner markup command

2016-01-13 Thread Pierre Perol-Schneider
Hi David,

2016-01-12 23:52 GMT+01:00 David Kastrup :


> \override #`(color . ,red)
>
> And yes, I use a backward tick here.  The forward tick will not
> cooperate with the comma later.
>

I'm not sure to clearly understand what I can do here but i'll investigate
anyhow.
Thanks for the tip.
Pierre
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Outliner markup command

2016-01-13 Thread David Kastrup
Pierre Perol-Schneider  writes:

> Hi David,
>
> 2016-01-12 23:52 GMT+01:00 David Kastrup :
>
>
>> \override #`(color . ,red)
>>
>> And yes, I use a backward tick here.  The forward tick will not
>> cooperate with the comma later.
>>
>
> I'm not sure to clearly understand what I can do here but i'll
> investigate anyhow.

This is the correct version of the \override #'(color . red) you wrote
which does not work.  Whether the above works depends on whether the
following markup actually uses the color property, of course.  But your
version would not have worked with any command.

-- 
David Kastrup

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


Re: Repeat 8va

2016-01-13 Thread John Gourlay
Using \unfoldRepeats in a separate \score for the midi output works. Thank you, 
Malte.

I’m still puzzled by the lack of documentation for \transposition, however. How 
have you all learned to use it, by word of mouth?

John Gourlay


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


Re: Overriding tie-configuration & \shape breaks custom Scheme function since 2.19.24

2016-01-13 Thread David Kastrup
David Kastrup  writes:

> Malte Meyn  writes:
>
>> Am 10.01.2016 um 02:50 schrieb Peter Crighton:
>>>   (if (or (music-is-of-type? mus 'rest-event)
>>>   (music-is-of-type? mus 'multi-measure-rest))
>>
>> The overrides fall into the ‘else’ case and then the tweaks are applied.
>> I’m not sure why this is changing all of the following note heads (bug?)
>
> Intentional.  It's

[...]

> Now that only \propertyTweak does that, maybe \tweak should not do
> this kind of chaining but leave it to \propertyTweak.

Tracker issue: 4742 (https://sourceforge.net/p/testlilyissues/issues/4742/)
Rietveld issue: 285840043 (https://codereview.appspot.com/285840043)
Issue description:
  Only \propertyTweak rather than \tweak can be applied to overrides
  \tweak should only tweak music as of issue 4533, so move the action
  of issue 4500 into \propertyTweak's definition instead.   Also
  contains commit:  tweaks-as-overrides regtest: fix oversight from
  issue 4533


-- 
David Kastrup

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


Re: Outliner markup command

2016-01-13 Thread Thomas Morley
2016-01-13 16:17 GMT+01:00 Paul Morris :
>> On Jan 12, 2016, at 6:09 PM, Thomas Morley  wrote:
>>
>> Though, there might be a bug in `stencil-whiteout-outline', Paul cc-ed.
>>
>> Look at:
>>
>> \markup \stencil
>> #(stencil-whiteout-outline
>>  (make-filled-box-stencil '(-1 . 1) '(-1 . 1))
>>  0.5
>>  red
>>  16
>>  1)
>>
>> \markup \stencil
>> #(stencil-whiteout-outline
>>  (stencil-with-color (make-filled-box-stencil '(-1 . 1) '(-1 . 1)) green)
>>  0.5
>>  red
>>  16
>>  1)
>>
>> First one is ok.
>> But in the second one the color from the stencil is taken (green) and
>> the specified (red) is ignored.
>> Will investigate more detailed the upcoming days.
>
> Huh, that’s odd…  stencil-whiteout-box works as expected (see below), so the 
> problem must indeed be in stencil-whiteout-outline.
>
> -Paul

Yep.

In this part of the code for stencil-whiteout-outline you try to apply
a color to a stencil, which is derived from the original one,

(ly:stencil-expr
 (stencil-with-color
  (radial-plot thickness stil empty-stencil)
  color))

Though, if this original stencil is colored already, it will fail.
See:

#(define my-box-stil (make-filled-box-stencil '(-1 . 1) '(-1 . 1)))

\markup {
  \stencil #my-box-stil
  \stencil #(stencil-with-color my-box-stil green)
  \stencil #(stencil-with-color (stencil-with-color my-box-stil green) red)
 }

Thinking about it, I came to the conclusion it's desired behaviour.
Otherwise the following wouldn't work:

\markup \with-color #red { foo \with-color #green bar buzz }

So far the reason, now looking forward to make it work anyway.


Cheers,
  Harm

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


Re: Outliner markup command

2016-01-13 Thread Simon Albrecht

On 13.01.2016 13:24, Pierre Perol-Schneider wrote:

Hi David,

2016-01-12 23:52 GMT+01:00 David Kastrup >:


\override #`(color . ,red)

And yes, I use a backward tick here.  The forward tick will not
cooperate with the comma later.


I'm not sure to clearly understand


A little background info: The ` and , are abbreviations, spelt out the 
above example reads \override #(quasiquote (color . (unquote red))). 
Quoting (i.e. '()) means that an expression is not evaluated; 
quasi-quoting means that an expression is not evaluated except for those 
parts which are unquoted explicitly. #red needs to be evaluated to a 
color, so you need to unquote it, and use a quasi-quotation instead of a 
quotation.


HTH, Simon

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


Re: Behavior of non-flag side with strictBeatBeaming

2016-01-13 Thread Pierre Perol-Schneider
The second is simply the easiest to read.
HTH
Pierre

2016-01-13 18:59 GMT+01:00 Kieren MacMillan :

> Hi Urs,
>
> > which of the attached engravings do you prefer, LilyPond's current or
> the modified?
>
> The second.
> And Gould agrees.  =)
>
> Hope this helps!
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Outliner markup command

2016-01-13 Thread Pierre Perol-Schneider
Thank you Simon for this clear explanation.
Pierre

2016-01-13 20:17 GMT+01:00 Simon Albrecht :

> On 13.01.2016 13:24, Pierre Perol-Schneider wrote:
>
>> Hi David,
>>
>> 2016-01-12 23:52 GMT+01:00 David Kastrup > >>:
>>
>> \override #`(color . ,red)
>>
>> And yes, I use a backward tick here.  The forward tick will not
>> cooperate with the comma later.
>>
>>
>> I'm not sure to clearly understand
>>
>
> A little background info: The ` and , are abbreviations, spelt out the
> above example reads \override #(quasiquote (color . (unquote red))).
> Quoting (i.e. '()) means that an expression is not evaluated; quasi-quoting
> means that an expression is not evaluated except for those parts which are
> unquoted explicitly. #red needs to be evaluated to a color, so you need to
> unquote it, and use a quasi-quotation instead of a quotation.
>
> HTH, Simon
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Repeat 8va

2016-01-13 Thread Trevor Daniels

John, you wrote Wednesday, January 13, 2016 6:18 PM

> I’m still puzzled by the lack of documentation for \transposition, however. 
> How have you all learned to use it, by word of mouth?

No :), you'll find it here:

http://www.lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#instrument-transpositions

It _is_ in the command index, but I see there is no entry in the general index 
in the Notation Reference for "transposition", so we ought to fix that.

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


Re: Repeat 8va

2016-01-13 Thread John Gourlay
There it is! I don’t know why I missed it the first time. I”m sorry to be a 
bother.

> On Jan 13, 2016, at 1:50 PM, Trevor Daniels  wrote:
> 
> 
> John, you wrote Wednesday, January 13, 2016 6:18 PM
> 
>> I’m still puzzled by the lack of documentation for \transposition, however. 
>> How have you all learned to use it, by word of mouth?
> 
> No :), you'll find it here:
> 
> http://www.lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#instrument-transpositions
> 
> It _is_ in the command index, but I see there is no entry in the general 
> index in the Notation Reference for "transposition", so we ought to fix that.
> 
> Trevor


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


Re: Repeat 8va

2016-01-13 Thread Simon Albrecht

On 13.01.2016 20:02, John Gourlay wrote:

There it is! I don’t know why I missed it the first time. I”m sorry to be a 
bother.


Never mind, the docs _are_ difficult to penetrate sometimes…

Yours, Simon

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


Good style sheet for hymnal?

2016-01-13 Thread Joshua Nichols
I'm possibly going to be taking on a hymnal project, and would like to know
if anyone has come up with a good style-sheet for lilypond engraving at
small sizes in hymnals!

Thanks!

​Sincerely,

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


Re: Making notes have no presence at all (horizontal brackets)

2016-01-13 Thread Kieren MacMillan
Hi Kevin,

> I need to add a voice with notes that are a) invisible and b) have no effect 
> on the spacing of other music on the staff. I haven't found a way to do this

What about:

\score {
  \new Staff <<
\mark \markup "rests, omitted"
\global
\new Voice \relative {
  bes,8-\tweak direction #1 \startGroup
  ees4\stopGroup c\startGroup
  bes8\startGroup aes\grace { g16[ aes] } g4\stopGroup \stopGroup
}
\new Voice \relative {
  \omit Rest
  s8
  r2*1/2 -\tweak direction #1 \startGroup \startGroup r\stopGroup
  r8\stopGroup
}
  >>
}

The only oddity I saw was that r1 made that bracket drop vertically (though I 
don’t know why).

Hope this helps in some way!
Kieren.


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


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


Making notes have no presence at all (horizontal brackets)

2016-01-13 Thread Kevin Barry
Dear All,

I frequently need to have overlapping horizontal brackets. This means that
I have to add hidden notes to my scores to attach them to. (Brackets won't
attach to spacer rests unless they live in a Staff context, in which case
you can't have more than one at a time. Adding brackets to both contexts
creates two brackets at a time.)

This means I need to add a voice with notes that are a) invisible and b)
have no effect on the spacing of other music on the staff. I haven't found
a way to do this, or even figured out how to predict what will happen when
I try. My main options are a) \hideNotes, b) stencil=##f, c)
stencil=#point-stencil, or d) same as previous, but with rests.

So far I have found that every option has /some/ effect on the surrounding
music. In some cases option a) is best, and sometimes another option. In a
complex score it's hard to even know which is best unless you make a small
example to test.

It's hard to create a minimal example that demonstrates this, so I have
attached an image and accompanying code to illustrate. I'm only concerned
about the notes (brackets always require tweaking in these situations). In
this case option c) looks best, but there are other times when
#point-stencil produces crazy output. Normally a) is best, but as you can
see it sometimes causes long stems and such, meaning I have to choose the
pitches of invisible notes carefully...

I have battled with this for a long time, so any help would be much
appreciated.

Kevin


test.pdf
Description: Adobe PDF document
\version "2.19.34"

global = {
  \key aes \major
  \partial 8
  \clef bass
}

\score {
  \new Voice \relative {
\mark \markup "normal"
\global
bes,8 ees4 c bes8 aes \grace { g16[ aes] } g4
  }
}

\score {
  \new Staff <<
\mark \markup "transparent"
\global
\new Voice \relative {
  bes,8-\tweak direction #1 \startGroup
  ees4\stopGroup c\startGroup
  bes8\startGroup aes\grace { g16[ aes] } g4\stopGroup \stopGroup
}
\new Voice \relative {
  \hideNotes
  \override NoteColumn.ignore-collision = ##t
  s8
  ees4 -\tweak direction #1 \startGroup \startGroup c\stopGroup
  bes8\stopGroup
}
  >>
}

\score {
  \new Staff <<
\mark \markup "no stencil"
\global
\new Voice \relative {
  bes,8-\tweak direction #1 \startGroup
  ees4\stopGroup c\startGroup
  bes8\startGroup aes\grace { g16[ aes] } g4\stopGroup \stopGroup
}
\new Voice \relative {
  \omit NoteHead
  \omit Beam
  \omit Flag
  \omit Stem
  \override NoteColumn.ignore-collision = ##t
  s8
  ees4 -\tweak direction #1 \startGroup \startGroup c\stopGroup
  bes8\stopGroup
}
  >>
}

\score {
  \new Staff <<
\mark \markup "point-stencil"
\global
\new Voice \relative {
  bes,8-\tweak direction #1 \startGroup
  ees4\stopGroup c\startGroup
  bes8\startGroup aes\grace { g16[ aes] } g4\stopGroup \stopGroup
}
\new Voice \relative {
  \override NoteHead.stencil = #point-stencil
  \override Beam.stencil = #point-stencil
  \override Flag.stencil = #point-stencil
  \override Stem.stencil = #point-stencil
  \override NoteColumn.ignore-collision = ##t
  s8
  ees4 -\tweak direction #1 \startGroup \startGroup c\stopGroup
  bes8\stopGroup
}
  >>
}

\score {
  \new Staff <<
\mark \markup "rests"
\global
\new Voice \relative {
  bes,8-\tweak direction #1 \startGroup
  ees4\stopGroup c\startGroup
  bes8\startGroup aes\grace { g16[ aes] } g4\stopGroup \stopGroup
}
\new Voice \relative {
  \hideNotes
  \override NoteColumn.ignore-collision = ##t
  s8
  r4 -\tweak direction #1 \startGroup \startGroup r\stopGroup
  r8\stopGroup
}
  >>
}

\layout {
  \context {
\Voice
\consists "Horizontal_bracket_engraver"
\override HorizontalBracket.bracket-flare = #'(0 . 0)
  }
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Outliner markup command

2016-01-13 Thread Paul Morris
> On Jan 13, 2016, at 7:45 AM, David Kastrup  wrote:
> 
> This is the correct version of the \override #'(color . red) you wrote
> which does not work.  Whether the above works depends on whether the
> following markup actually uses the color property, of course.

Indeed, the “\whiteout" markup command does not currently use the color 
property (although the functions it calls does, “stencil-whiteout” etc.).  No 
reason it couldn’t be enhanced to use it though.

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


Re: Outliner markup command

2016-01-13 Thread Paul Morris
> On Jan 12, 2016, at 6:09 PM, Thomas Morley  wrote:
> 
> Though, there might be a bug in `stencil-whiteout-outline', Paul cc-ed.
> 
> Look at:
> 
> \markup \stencil
> #(stencil-whiteout-outline
>  (make-filled-box-stencil '(-1 . 1) '(-1 . 1))
>  0.5
>  red
>  16
>  1)
> 
> \markup \stencil
> #(stencil-whiteout-outline
>  (stencil-with-color (make-filled-box-stencil '(-1 . 1) '(-1 . 1)) green)
>  0.5
>  red
>  16
>  1)
> 
> First one is ok.
> But in the second one the color from the stencil is taken (green) and
> the specified (red) is ignored.
> Will investigate more detailed the upcoming days.

Huh, that’s odd…  stencil-whiteout-box works as expected (see below), so the 
problem must indeed be in stencil-whiteout-outline.

-Paul


\markup \stencil
#(stencil-whiteout-box
 (make-filled-box-stencil '(-1 . 1) '(-1 . 1))
 0.5
 1
 red)

\markup \stencil
#(stencil-whiteout-box
 (stencil-with-color (make-filled-box-stencil '(-1 . 1) '(-1 . 1)) green)
 0.5
 1
 red)



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


RE: Microtonal notation - arrows up and down

2016-01-13 Thread Luca Danieli
Dear Graham,

I tried to find information on how to do it on internet, but I am unable to 
find anything.
I am sorry to continuously asking, but can you give me any hint on how to do 
it? 

(I tried to update all the software in Ubuntu, but I am already the newest 
version)

Kind regards,
Luca


> Subject: RE: Microtonal notation - arrows up and down
> To: lilypond-user@gnu.org
> From: gbr...@gmail.com
> Date: Tue, 12 Jan 2016 20:01:53 +
> 
> > Date: Mon, 11 Jan 2016 19:39:06 +0100
> > From: Luca Danieli
> 
> > It works perfectly! I understand that I need to rename ALL pitches, 
> > otherwise the building fails.The only problem now is that I have lost the 
> > default microtonal symbols.
> > So for example, how do I re-write the default symbol ceh (to have the 
> > symbol "d")?
> > In your example it is: (ceh . ,(ly:make-pitch -1 0 (/ FLAT 2))), but this 
> > doesn't show any accidental.
> > (I can't find information on internet)
> 
> The accidentals are listed in the "arrowGlyphs" object.  You need to 
> update that to match the names.
> 
> 
>Graham
> 
> ___
> 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


Behavior of non-flag side with strictBeatBeaming

2016-01-13 Thread Urs Liska
Hi all,

one more beaming question,

given the following input

\relative a' {
  \time 6/8
  \set strictBeatBeaming = ##t
  a8.. a32 a16 a
}

which of the attached engravings do you prefer, LilyPond's current or
the modified?
Would it make sense to add a beaming option (e.g.
"strictBeatBeamingNonFlagSide") so the user can choose?

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


Re: Behavior of non-flag side with strictBeatBeaming

2016-01-13 Thread Urs Liska


Am 13.01.2016 um 18:09 schrieb Urs Liska:
> Hi all,
>
> one more beaming question,
>
> given the following input
>
> \relative a' {
>   \time 6/8
>   \set strictBeatBeaming = ##t
>   a8.. a32 a16 a
> }
>
> which of the attached engravings do you prefer, LilyPond's current or
> the modified?
> Would it make sense to add a beaming option (e.g.
> "strictBeatBeamingNonFlagSide") so the user can choose?

Note that I think this is actually the difference between subdivideBeams
being ##t or ##f.
Currently LilyPond produces the second rendering from my previous post,
regardless of subdivisions or not.

So I'd say *with* strictBeatBeaming *and* subdivided beams the non-flag
side should have its stems governed by the rhythmic position of the
subdivision while with strictBeatBeaming and *no* subdivisions it should
have the beam number of the following stem.

Objections?

Urs

> Best
> Urs
>
>
> ___
> 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: Behavior of non-flag side with strictBeatBeaming

2016-01-13 Thread Urs Liska


Am 13.01.2016 um 18:23 schrieb Urs Liska:
>
>
> Am 13.01.2016 um 18:09 schrieb Urs Liska:
>> Hi all,
>>
>> one more beaming question,
>>
>> given the following input
>>
>> \relative a' {
>>   \time 6/8
>>   \set strictBeatBeaming = ##t
>>   a8.. a32 a16 a
>> }
>>
>> which of the attached engravings do you prefer, LilyPond's current or
>> the modified?
>> Would it make sense to add a beaming option (e.g.
>> "strictBeatBeamingNonFlagSide") so the user can choose?
>
> Note that I think this is actually the difference between
> subdivideBeams being ##t or ##f.
> Currently LilyPond produces the second rendering from my previous
> post, regardless of subdivisions or not.
>
> So I'd say *with* strictBeatBeaming *and* subdivided beams the
> non-flag side should have its stems governed by the rhythmic position
> of the subdivision while with strictBeatBeaming and *no* subdivisions
> it should have the beam number of the following stem.
>
> Objections?
>

OK, last one before shutting down for now.

Attached is what I think should be the behavior for the following input:

\version "2.19.36"

notes = \relative a' { a8.. a32 a16 a }
\relative a' {
  \time 6/8

  \notes
 
  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1/16)
  \notes

  \set strictBeatBeaming = ##t
 
  \set subdivideBeams = ##f
  \notes

  \set subdivideBeams = ##t
  \notes
}

Two measures with two beams each, the first beam without, the second
with subdivisions.
First measure with regular beat beaming, the second with
"strictBeatBeaming".

It's obvious that subdivided beams implicitly cause "strictBeatBeaming"
while at the subdivision.

Urs
> Urs
>
>> Best
>> Urs
>>
>>
>> ___
>> 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: Behavior of non-flag side with strictBeatBeaming

2016-01-13 Thread Werner LEMBERG
> given the following input
> 
> \relative a' {
>   \time 6/8
>   \set strictBeatBeaming = ##t
>   a8.. a32 a16 a
> }
> 
> which of the attached engravings do you prefer, LilyPond's current or
> the modified?

[Both images are called `document.png', which is not optimal :-)]

I prefer the second one.  Beamlets that are connected with ordinary
beams look very unnatural to me.


Werner

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


Re: Behavior of non-flag side with strictBeatBeaming

2016-01-13 Thread Kieren MacMillan
Hi Urs,

> which of the attached engravings do you prefer, LilyPond's current or the 
> modified?

The second.
And Gould agrees.  =)

Hope this helps!
Kieren.


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


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