On Fri, Oct 24, 2008 at 3:23 AM, Trevor Daniels [EMAIL PROTECTED]wrote:
Trevor, you wrote Thursday, October 23, 2008 11:26 PM
On Thu, Oct 23, 2008 at 4:27 PM, Werner LEMBERG [EMAIL PROTECTED] wrote:
Please don't change c[ ]!
Do you really mean that you've used, say,
a b[] c
On Fri, Oct 24, 2008 at 9:20 AM, Werner LEMBERG [EMAIL PROTECTED] wrote:
The two snippets attached here come from the commission I just
finished up in February ...
OK, so this feature has to be documented, and I withdraw my
suggestion.
OK, super. Maybe the examples I just sent over to
On 10/25/08 5:23 PM, Trevor Bača [EMAIL PROTECTED] wrote:
On Fri, Oct 24, 2008 at 3:23 AM, Trevor Daniels [EMAIL PROTECTED] wrote:
Trevor, you wrote Thursday, October 23, 2008 11:26 PM
On Thu, Oct 23, 2008 at 4:27 PM, Werner LEMBERG [EMAIL PROTECTED] wrote:
Maybe a quick mention of
Trevor, this is cool! I think in your first example, though, where you
want to illustrate right-pointing flags on a lone note, you mean to say
set stemLeftBeamCount to zero? Or do I misunderstand the example?
Otherwise the first and second examples display the same thing.
Jon
Trevor Bača
2008/10/25 Carl D. Sorensen [EMAIL PROTECTED]
On 10/25/08 5:23 PM, Trevor Bača [EMAIL PROTECTED] wrote:
On Fri, Oct 24, 2008 at 3:23 AM, Trevor Daniels [EMAIL PROTECTED]
wrote:
Trevor, you wrote Thursday, October 23, 2008 11:26 PM
On Thu, Oct 23, 2008 at 4:27 PM, Werner
On Sat, Oct 25, 2008 at 9:43 PM, Jonathan Kulp [EMAIL PROTECTED]wrote:
Trevor, this is cool! I think in your first example, though, where you
want to illustrate right-pointing flags on a lone note, you mean to say set
stemLeftBeamCount to zero? Or do I misunderstand the example? Otherwise
Trevor, you wrote Thursday, October 23, 2008 11:26 PM
On Thu, Oct 23, 2008 at 4:27 PM, Werner LEMBERG [EMAIL PROTECTED] wrote:
Please don't change c[ ]!
Do you really mean that you've used, say,
a b[] c
within your score? Currently, this is an undocumented feature, so you
are use
The two snippets attached here come from the commission I just
finished up in February ...
OK, so this feature has to be documented, and I withdraw my
suggestion.
Werner
PS: I really hope to never have to play such complicated rhythms in
real life :-)
On Sun, Sep 7, 2008 at 6:15 AM, Werner LEMBERG [EMAIL PROTECTED] wrote:
Yes. What I really would like to write is
c4 c c \times 2/3 { r8 c16[] } c8
and I just demonstrated a case where my proposed notation would be
helpful.
My point is that is it not helpful in this case
Please don't change c[ ]!
Do you really mean that you've used, say,
a b[] c
within your score? Currently, this is an undocumented feature, so you
are use something from the darker corners of lilypond...
Werner
___
lilypond-devel mailing
On Thu, Oct 23, 2008 at 4:27 PM, Werner LEMBERG [EMAIL PROTECTED] wrote:
Please don't change c[ ]!
Do you really mean that you've used, say,
a b[] c
within your score? Currently, this is an undocumented feature, so you
are use something from the darker corners of lilypond...
Darker
My special example is this where such a shorthand would be quite
convenient:
c4 c c \times 2/3 { r8 c16 } c8
This may have nothing to do with your proposal/question but as a
reader I would find your example much harder to read/sightread than
c4 c c \times 2/3 { r8[ c16] } c8
I don't think [] should even compile.
This is another possibility, yes. However, `c[]' is much easier to
type than `c\noBeam'. Additionally, it's not that an absurd notation
IMHO.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Werner LEMBERG wrote:
My special example is this where such a shorthand would be quite
convenient:
c4 c c \times 2/3 { r8 c16 } c8
This may have nothing to do with your proposal/question but as a
reader I would find your example much harder to read/sightread than
c4 c c
Yes. What I really would like to write is
c4 c c \times 2/3 { r8 c16[] } c8
and I just demonstrated a case where my proposed notation would be
helpful.
My point is that is it not helpful in this case because it produces
a notation which is IMO harder to read than the two
On Sun, Sep 7, 2008 at 3:21 AM, Werner LEMBERG [EMAIL PROTECTED] wrote:
This may have nothing to do with your proposal/question but as a
reader I would find your example much harder to read/sightread than
c4 c c \times 2/3 { r8[ c16] } c8
or
c4 c c \times 2/3 { r8[ c16 } c8]
Yes.
Werner LEMBERG wrote:
I'm not sure whether this has been discussed before: What do you think
of using `c[]' as a shorthand for `\autoBeamOff c \autoBeamOn'?
Currently, `c[]' produces
_
|
|
O
(a note with a beamlet to the left and
Werner LEMBERG wrote:
I'm not sure whether this has been discussed before: What do you think
of using `c[]' as a shorthand for `\autoBeamOff c \autoBeamOn'?
Currently, `c[]' produces
_
|
|
O
(a note with a beamlet to the left and right), which
I'm not sure whether this has been discussed before: What do you think
of using `c[]' as a shorthand for `\autoBeamOff c \autoBeamOn'?
Currently, `c[]' produces
_
|
|
O
(a note with a beamlet to the left and right), which is neither
We already have the predefined macro \noBeam. Do we really need yet another
more or less obscure special case of the syntax?
/Mats
Werner LEMBERG wrote:
I'm not sure whether this has been discussed before: What do you think
of using `c[]' as a shorthand for `\autoBeamOff c \autoBeamOn'?
We already have the predefined macro \noBeam.
Ah, I wasn't aware of that! I overlooked it in the docs.
Do we really need yet another more or less obscure special case of
the syntax?
No.
Werner
___
lilypond-devel mailing list
Mats Bengtsson mats.bengtsson at ee.kth.se writes:
We already have the predefined macro \noBeam. Do we really need yet another
more or less obscure special case of the syntax?
/Mats
Werner LEMBERG wrote:
I'm not sure whether this has been discussed before: What do you think
of
I'm not sure whether this has been discussed before: What do you
think of using `c[]' as a shorthand for `\autoBeamOff c
\autoBeamOn'?
When I was first learning lilypond I remember trying this exact
syntax to get an unbeamed note. I think it would be useful if it
worked. It's a big win
23 matches
Mail list logo
