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
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
Am 12.01.2016 um 18:16 schrieb Urs Liska:
>>> What should the behavior of the *last* one be here?
>> > Stemlet, for sure. (IMO)
> Unfortunately producing stemlets is a completely different business
> which I haven't discovered yet (don't even know where this might take
> place).
>
> Urs
>
Ah
Am 12.01.2016 um 19:57 schrieb Kieren MacMillan:
> Hi Urs,
>
>> Ah well, producing stemlets is the responsibility of user input code.
> Indeed. =)
> I have some syntactic sugar for just such efforts.
>
>> Find attached a solution *with* stemlets (\override
>> Staff.Stem.stemlet-length = 1)
>
>> No beams over the rest.
>
> But if the user manually enters the beam enclosing the rest there
> should be *something*.
Ah, ok, I missed this.
> And I think a single beam is better here than a number of steamlets.
I agree.
Werner
___
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).
But if the user manually enters the beam enclosing the rest there should
be *something*.
Hi Urs,
> Well, default behaviour is to break the beam at all rests here (see attached).
ew
> But if the user manually enters the beam enclosing the rest there should
> be *something*.
+1
> What would be nice too […] is adding a stemlet,
> but without implicitly adding beamlets.
Yes.
n.b.
> What should the behavior of the *last* one be here?
No beams over the rest.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Hi,
there is an issue with rests under beams.
The comment in the source code says
"Invisible stems should be treated as though they have the same
number of beams as their least-beamed neighbour."
I think this is intended for cases like
\relative c'' {
a32 [ a a r a16 a]
}
(first
Hi Urs,
> I see two approaches to this:
>
> a) have the number of beams correspond to the actual duration of the
> note (third attachment)
> b) have *no* beamlets at all and let the subdivision be calculated as
> usual (fourth attachment)
>
> Any opinions (or references to what the books say)?
Am 12.01.2016 um 16:47 schrieb Urs Liska:
> Hi Kieren,
>
> thanks for info and opinion. (I really have to get hold of Gould's book
> finally ...).
>
> If I'd implement that
>
> \relative c'' {
> a32 [ a a r a16 a ]
> \set subdivideBeams = ##t
> \set baseMoment = #(ly:make-moment 1/8)
>
Am 12.01.2016 um 16:37 schrieb Kieren MacMillan:
> Hi Urs,
>
>> I see two approaches to this:
>>
>> a) have the number of beams correspond to the actual duration of the
>> note (third attachment)
>> b) have *no* beamlets at all and let the subdivision be calculated as
>> usual (fourth
Hi Urs,
> Ah well, producing stemlets is the responsibility of user input code.
Indeed. =)
I have some syntactic sugar for just such efforts.
> Find attached a solution *with* stemlets (\override Staff.Stem.stemlet-length
> = 1)
From the standpoint of clarity [of beat division/subdivision],
Am 12.01.2016 um 17:49 schrieb Urs Liska:
>
> Am 12.01.2016 um 17:28 schrieb Mark Knoop:
>> At 17:15 on 12 Jan 2016, Werner LEMBERG wrote:
b) have *no* beamlets at all and let the subdivision be calculated
as usual (fourth attachment)
>>> This is what I prefer.
>>>
>> +1. Gould
Hi Urs,
> I must say I find the attached image (with 1/16 subdivision and rests
> before each division) pretty clear.
“Pretty clear”? Yes.
Could it be clearer? Definitely.
I can’t tell if, for example, the 64ths should be phrased 3+5 or 4+4; beamlets
and/or stemlets would definitely help make
Am 12.01.2016 um 18:11 schrieb Kieren MacMillan:
> Hi Urs,
>
>> I must say I find the attached image (with 1/16 subdivision and rests
>> before each division) pretty clear.
> “Pretty clear”? Yes.
>
> Could it be clearer? Definitely.
> I can’t tell if, for example, the 64ths should be phrased 3+5
> b) have *no* beamlets at all and let the subdivision be calculated
>as usual (fourth attachment)
This is what I prefer.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
At 17:15 on 12 Jan 2016, Werner LEMBERG wrote:
>> b) have *no* beamlets at all and let the subdivision be calculated
>>as usual (fourth attachment)
>
>This is what I prefer.
>
+1. Gould seems to always use stemlets with beamlets when the beam
count > 2.
--
Mark Knoop
Am 12.01.2016 um 17:28 schrieb Mark Knoop:
> At 17:15 on 12 Jan 2016, Werner LEMBERG wrote:
>>> b) have *no* beamlets at all and let the subdivision be calculated
>>>as usual (fourth attachment)
>> This is what I prefer.
>>
> +1. Gould seems to always use stemlets with beamlets when the
19 matches
Mail list logo
