Re: how to beam non-tuplets with tuplets?

[Adam James Wilson]

Hi all,

Thanks everyone for being such active participants in this community -
as a new user of Lilypond I'm finding it a great experience, both as a
tool in and of itself and as an interaction between
programmers/users/documenters/etc.

I'm just looking at this thread for the first time after sending my
initial question; thanks Valentin for adding the tip to LSR.  I didn't
mean to cause a big debate . . . but at the risk of extending the
debate, here are my thoughts (as a relatively new user to Lilypond):

1) Had the manual contained a general explanation of the syntax I
discovered by trial and error, I agree I'm sure I wouldn't have had to
pose my question . . .

2) . . . however, I don't see anything wrong with adding a snippet to
the LSR database in the meantime while the manual is being re-written;
practically speaking, it would have shaved off an hour or so of
searching and questioning for me.  Valentin's example very clearly
lays out a number of contexts in which the same syntax applies, and
thus serves as a useful way to "surmise" syntax until the manual is
updated.

3) I believe Graham mentioned that in the absence of a generalized
explanation of syntax, people who program tend to base their
intuitions on coding conventions; as a Common Lisp hacker, I'm used to
interleaved (as opposed to imbedded) parens being a big no-no, so of
course I defaulted to encapsulating the entire \times block within
brackets.

Best regards,
Adam

On 9/11/07, Mats Bengtsson <address@hidden> wrote:
>
>
> Neil Puttock wrote:
> >
> > To add a dissenting voice, I don't think this is LSR-worthy, in my
> > humble opinion.
> >
> > Surely it's clear from the postfix-style syntax for manual beaming
> > that the right square bracket should directly follow the note which is
> > to be at the end of the requested beaming, i.e. inside the tuplet section?
> I agree that it's clear if you are clear about the syntax. However,
> since there is no
> clear syntax definition in the documentation today, the tip is probably
> LSR-worthy.
> The problem is that users who experience closely related problems will
> not find
> this specific snippet and it's impossible to include examples of all
> such situations
> since they are too many and too hard to forsee.
>
>    /Mats
>