On Sun, Aug 4, 2013 at 9:18 AM, David Kastrup wrote:
> I don't think that distributing ( and ) between standalone event and
> post-event respectively is a concept that will carry the day
> sufficiently to be given a chance at a comeback. It would make
> (c (d) e)
> visually co
David Kastrup writes:
> Mathieu Huiban writes:
>
>>> On Thu, Sep 13, 2012 at 2:27 AM, David Kastrup wrote:
>>>
I don't think that distributing ( and ) between standalone event and
post-event respectively is a concept that will carry the day
sufficiently to be given a chance at a
Dear developers,
Thank you for your work on lilypond.
What about considering ( as a post-event and ) as a standalone event ?
c( )d( )e is symmetric and very clear.
best regards,
Mathieu
On Thu, Sep 13, 2012 at 2:27 AM, David Kastrup wrote:
> I don't think that distributing ( and ) betw
Mathieu Huiban writes:
>> On Thu, Sep 13, 2012 at 2:27 AM, David Kastrup wrote:
>>
>>> I don't think that distributing ( and ) between standalone event and
>>> post-event respectively is a concept that will carry the day
>>> sufficiently to be given a chance at a comeback. It would make
>>> (c
Francisco Vila writes:
> 2012/9/13 Graham Percival :
>> IIRC, the old style in lilypond was:
>> (c c)
>
> Students whish this came back, I think. No matter how many times I
> insist on it, they always ^H^H^H^H usually fail to remember the
> correct form c( c)
>
> I find funny that the solution
2012/9/13 Graham Percival :
> IIRC, the old style in lilypond was:
> (c c)
Students whish this came back, I think. No matter how many times I
insist on it, they always ^H^H^H^H usually fail to remember the
correct form c( c)
I find funny that the solution they figured out to remember it, is the
Graham Percival writes:
> On Tue, Sep 11, 2012 at 02:04:01PM +0200, David Kastrup wrote:
>> Basically every construct that we would be tempted to use <> or s1*0 for
>> occasionally is one that is not really attached to a note, but rather to
>> a moment in time.
>
> I certainly agree that it would
On Tue, Sep 11, 2012 at 02:04:01PM +0200, David Kastrup wrote:
> Basically every construct that we would be tempted to use <> or s1*0 for
> occasionally is one that is not really attached to a note, but rather to
> a moment in time.
I certainly agree that it would be good to be clear about "stuff"
On 11/09/12 14:15, David Kastrup wrote:
No. Just those commands that are not intrinsically attached to a note
within a voice, like dynamics and phrasings. Basically those things
that you'd occasionally attach to <> or s1*0 for lack of something more
suitable.
In the case of dynamics, you real
On 11/09/12 13:04, David Kastrup wrote:
Basically every construct that we would be tempted to use <> or s1*0 for
occasionally is one that is not really attached to a note, but rather to
a moment in time. You can put it in parallel music without changing
results. Most articulations with a shorth
Han-Wen Nienhuys writes:
>> But things like ( ) \( \) [ ] \p \< \! \> all happen at a moment in
>> time in a voice. Why is a tempo change a separate event, but a
>> dynamic change isn't?
>
> Specifically, I think it is because the tempo logically is an
> interpretation property, and may have bee
On Tue, Sep 11, 2012 at 9:04 AM, David Kastrup wrote:
> Joseph Rushton Wakeling writes:
>
>> On 01/09/12 17:25, Graham Percival wrote:
>>> Continuing to brainstorm on the problem of it not being obvious to
>>> which note a particular \command refers to, what if we used:
>>>
>>> \postfix: c2
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To:
> Sent: Tuesday, September 11, 2012 1:22 PM
> Subject: Re: [GLISS] differentiating pre/post/neutral commands
>
>
>> "Phil Holmes" writes:
>>
&g
- Original Message -
From: "David Kastrup"
To:
Sent: Tuesday, September 11, 2012 1:22 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands
"Phil Holmes" writes:
I've always thought that the post-event nature of lilypond is its own
worst
Xavier Scheuer writes:
> On 11 September 2012 14:04, David Kastrup wrote:
>>
>> Ok, and now for something completely different. I think there has been
>> one proposal to bring \[ \] in line with the post-event nature of [ ]
>> and ( ), but the one thing I have been thinking about recently is
>>
On 11 September 2012 14:04, David Kastrup wrote:
>
> Ok, and now for something completely different. I think there has been
> one proposal to bring \[ \] in line with the post-event nature of [ ]
> and ( ), but the one thing I have been thinking about recently is
> whether we should not actually
"Phil Holmes" writes:
> I've always thought that the post-event nature of lilypond is its own
> worst enemy. My particular pet peeve is that it means you can't
> terminate a piano pedal P with an asterisk * on the last note of a
> piece, since the \sustainOn occupies the post-event location and
- Original Message -
From: "David Kastrup"
To:
Sent: Tuesday, September 11, 2012 1:04 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Joseph Rushton Wakeling writes:
On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem
Joseph Rushton Wakeling writes:
> On 01/09/12 17:25, Graham Percival wrote:
>> Continuing to brainstorm on the problem of it not being obvious to
>> which note a particular \command refers to, what if we used:
>>
>> \postfix: c2 d\p is unchanged
>> /prefix: for music functions like c2 /pa
On Thu, Sep 6, 2012 at 1:50 PM, Joseph Rushton Wakeling
wrote:
> On 03/09/12 21:12, David Kastrup wrote:
>> "the previous element" is the same kind of thing.
>>
>> c-.=\parenthesize=\tweak #'color #red
>>
>> Now is the parenthesized . red, or is the paren red?
>
> Apologies, my own (completely ind
Joseph Rushton Wakeling writes:
> On 03/09/12 21:12, David Kastrup wrote:
>> Graham Percival writes:
>>> The hard and fast rule is "- attaches to a note; = attaches to the
>>> prevous element". I don't think that we had a chance to get into
>>> that during the big meeting.
>>
>> "the previous e
On 03/09/12 21:12, David Kastrup wrote:
Graham Percival writes:
The hard and fast rule is "- attaches to a note; = attaches to the
prevous element". I don't think that we had a chance to get into
that during the big meeting.
"the previous element" is the same kind of thing.
c-.=\parenthesiz
On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't
Reinhold Kainhofer writes:
> What makes lilypond unfeasiable as a storage format is that its
> internals change so often. In particular, we currently have the
> viewpoint that changes to \overrides are internals, so we don't have
> to care about compatibility. In other words: We care only about
>
On 2012-09-03 22:43, Werner LEMBERG wrote:
From a user's point of view who has to write a lot of piano music,
`q' is *really* valuable.
In a score editor. Like Emacs' LilyPond-mode. Or Frescobaldi.
Nobody says that you should not be able to make use of shortcuts,
but that does not mean tha
On Tue, Sep 04, 2012 at 05:43:58PM +0200, David Kastrup wrote:
> Thomas Morley writes:
> > So I'm with Graham:
> >
> > 2012/9/3 Graham Percival :
> >> I do not think that musicians have nothing valuable
> >> to say. I *especially* do not agree that documentation writers or
> >> teachers (in perso
2012/9/3 Graham Percival :
> I disagree. I do not think that musicians have nothing valuable
> to say. I *especially* do not agree that documentation writers or
> teachers (in person) have nothing valuable to say.
This is the second time I have been softly required to speak, I think.
I hate to s
2012/9/4 Werner LEMBERG :
>
>>> How come the pianists don't have it in the score then?
>>
>> Because pianists work with two dimensions on the paper, not one?
>
> Actually, after some thinking, I believe to remember that I've seen
> such a shorthand in printed scores also: It's simply a stem without
Thomas Morley writes:
> So what to do?
> Ask someone? Learn more?
> I choosed the second and decided to learn scheme (currently still
> improving it).
> Nowadays I'm able to write nearly all scheme-stuff I need, to answer
> numerous questions on the user-list, reporting bugs and work-arounds
> fo
>>> How come the pianists don't have it in the score then?
>>
>> Because pianists work with two dimensions on the paper, not one?
>
> Actually, after some thinking, I believe to remember that I've seen
> such a shorthand in printed scores also: It's simply a stem without
> the chord. At least ther
>> How come the pianists don't have it in the score then?
>
> Because pianists work with two dimensions on the paper, not one?
Actually, after some thinking, I believe to remember that I've seen
such a shorthand in printed scores also: It's simply a stem without
the chord. At least there are a
>> Chord repetition is a *central* part of piano music (and not only
>> there). It really deserves a proper syntax, and I'm glad that we
>> have it now.
>
> How come the pianists don't have it in the score then?
Because pianists work with two dimensions on the paper, not one?
> Uh, _storage_ f
2012/9/4 David Kastrup :
> David Kastrup writes:
>
>> Thomas Morley writes:
>>
>>> That said, now some thoughts ontopic:
>>> In most cases I'm quite fine with the current lily-syntax concerning
>>> the pre/post-commands.
>>> But there are cases I'd wish to be more consequent.
>>>
>>> Example:
>>>
David Kastrup writes:
> Thomas Morley writes:
>
>> That said, now some thoughts ontopic:
>> In most cases I'm quite fine with the current lily-syntax concerning
>> the pre/post-commands.
>> But there are cases I'd wish to be more consequent.
>>
>> Example:
>>
>> Sometimes backslash, sometimes d
Thomas Morley writes:
> That said, now some thoughts ontopic:
> In most cases I'm quite fine with the current lily-syntax concerning
> the pre/post-commands.
> But there are cases I'd wish to be more consequent.
>
> Example:
>
> Sometimes backslash, sometimes dash!
Dash is required for single-c
Let me drop in some remarks:
About me (you can skip this, if you want):
I'm a musician and music-teacher.
The first 35 years of my life I wouldn't have known how to switch on a
computer, but then I met my girl-friend. :) She used LilyPond and so I
discovered LilyPond for myself.
In the follwing y
Werner LEMBERG writes:
> Chord repetition is a *central* part of piano music (and not only
> there). It really deserves a proper syntax, and I'm glad that we have
> it now.
How come the pianists don't have it in the score then?
>> Editing shortcuts have a nice place in editors.
>
> `q' is cert
Graham Percival writes:
>> On the one hand I very much appreciate the ideas and proposals, because
>> they tell me that people really care about our user interface. This is
>> what people see of LilyPond and so it is easy to identify LilyPond by
>> it. On the other hand, everything that does not
On Mon, Sep 3, 2012 at 8:37 PM, Graham Percival
wrote:
> On Mon, Sep 03, 2012 at 04:10:59PM +0200, Jan Nieuwenhuizen wrote:
>> On the one hand I very much appreciate the ideas and proposals, because
>> they tell me that people really care about our user interface. This is
>> what people see of Li
>> From a user's point of view who has to write a lot of piano music,
>> `q' is *really* valuable.
>
> In a score editor. Like Emacs' LilyPond-mode. Or Frescobaldi.
> Nobody says that you should not be able to make use of shortcuts,
> but that does not mean that the LilyPond language is the rig
Graham Percival writes:
> On Mon, Sep 03, 2012 at 05:17:53PM +0200, David Kastrup wrote:
>> With things like
>>
>> c-\parenthesize-\p
>>
>> no hard and fast syntax rule will resolve the ambiguity caused by your
>> "let's stick - before things applying to the previous element" proposal.
>
> The
On Mon, Sep 03, 2012 at 05:17:53PM +0200, David Kastrup wrote:
> With things like
>
> c-\parenthesize-\p
>
> no hard and fast syntax rule will resolve the ambiguity caused by your
> "let's stick - before things applying to the previous element" proposal.
The hard and fast rule is "- attaches to
On Mon, Sep 03, 2012 at 04:10:59PM +0200, Jan Nieuwenhuizen wrote:
> On the one hand I very much appreciate the ideas and proposals, because
> they tell me that people really care about our user interface. This is
> what people see of LilyPond and so it is easy to identify LilyPond by
> it. On th
Janek Warchoł writes:
> On Sat, Sep 1, 2012 at 10:09 PM, David Kastrup wrote:
>> Well, the music function work has removed a lot of pressure of the "I
>> want my favorite construct xxx in the grammar" kind since there are
>> quite a number of things people can put in themselves if they want to.
Am 03.09.2012 15:11, schrieb Graham Percival:
[...]
other people shoot
down ideas by trapping it in a net, lowering it to the ground,
giving it a drink of hemlock, then stroking its head as it falls
asleep.
This is quite an amazing metaphor – if my ideas are supposed
to die, I hope they die like
Janek Warchoł writes:
>>c\p b <--- no space before => postfix
>>c -\p b<--- explicitely postfix, space is no problem
>>c \parenthesize b <--- verb with a space before => prefix function
>>c \mymusic b <--- a noun with a space before => a variable
>
On Mon, Sep 3, 2012 at 8:17 AM, Werner LEMBERG wrote:
> Perhaps we should start differently: Instead of making ad-hoc syntax
> suggestions, let's collect experienced user reports about the most
> annoying LilyPond syntax issues. The stress lies on *user*, not
> developer. Then parser experts can
On Sat, Sep 1, 2012 at 10:09 PM, David Kastrup wrote:
> Well, the music function work has removed a lot of pressure of the "I
> want my favorite construct xxx in the grammar" kind since there are
> quite a number of things people can put in themselves if they want to.
> Yes, the process of making
On Mon, Sep 3, 2012 at 3:34 PM, Han-Wen Nienhuys wrote:
> Part of my beef with the GOP mediated discussion here is that just me
> and David have a grasp of how things work. Get more people
> knowledgeable and there can be discussion.
Well, is there a better ways for us ("other people") to get
kno
Graham Percival writes:
> Really? In terms of the \./ pre-post-neutral idea, I found
> Werner, Xavier, Nicolas, Janek, Keith, and Valentin (private
> email) more convincing than you and Han-Wen.
Maybe I can help. Let's start with this reminder
$ git blame -e parser.yy|awk '{print $3;}'|sor
On Mon, Sep 3, 2012 at 9:00 AM, Graham Percival
wrote:
> On Mon, Sep 03, 2012 at 01:24:22AM -0300, Han-Wen Nienhuys wrote:
>> On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
>> wrote:
>>
>> > The meta-target is "after spending 5 years very publicly
>> > telling people *not* to talk about changing
On Mon, Sep 3, 2012 at 9:16 AM, Graham Percival
wrote:
> So far the discussion has gone according to my predictions.
> There's panic (and IMO overraction) from people who actually know
> the parser, which does not encourage open discussion of ideas.
> Why not hold the preliminary discussions on a
On Mon, Sep 03, 2012 at 02:39:45PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Why not hold the preliminary discussions on a separate list (to
> > which parser experts are encouraged *not* to read), then only
> > bring a proposal to -devel when it's ready?
>
> Syntax discussions
Graham Percival writes:
> So far the discussion has gone according to my predictions.
> There's panic (and IMO overraction) from people who actually know
> the parser, which does not encourage open discussion of ideas.
> Why not hold the preliminary discussions on a separate list (to
> which pars
On Mon, Sep 03, 2012 at 02:43:51AM -0300, Han-Wen Nienhuys wrote:
> On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup wrote:
> > Most of the proposals are a bad idea
> > without actually having to look at implementability because they
> > introduce ambiguities that are hard to resolve
Yes. That's wh
On Mon, Sep 03, 2012 at 01:24:22AM -0300, Han-Wen Nienhuys wrote:
> On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
> wrote:
>
> > The meta-target is "after spending 5 years very publicly
> > telling people *not* to talk about changing the syntax because
> > we would do so 'in a year or two', I t
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>> Users like to save keystrokes, and they bemoan the demise of Mutopia,
>> and the rise of MusicXML over LilyPond as a music presentation format.
>>
>> Nobody wants to see the connections.
>
> I'm glad you do.
It's not that it helps much with
David Kastrup writes:
> Users like to save keystrokes, and they bemoan the demise of Mutopia,
> and the rise of MusicXML over LilyPond as a music presentation format.
>
> Nobody wants to see the connections.
I'm glad you do. That's why I suggested the investigation of truly
supporting full futur
Werner LEMBERG writes:
>>> but IMHO it was worth the trouble.
>>
>> In my opinion, it wasn't.
>
> Thus spoke the developer. From a user's point of view who has to
> write a lot of piano music, `q' is *really* valuable.
In a score editor. Like Emacs' LilyPond-mode. Or Frescobaldi. Nobody
say
>> but IMHO it was worth the trouble.
>
> In my opinion, it wasn't.
Thus spoke the developer. From a user's point of view who has to
write a lot of piano music, `q' is *really* valuable.
Werner
___
lilypond-devel mailing list
lilypond-devel@gn
Werner LEMBERG writes:
>> Rather than proposing something by way of example, I would like to
>> see all proposals in the form of a parser patch that does not
>> introduce extra shift/reduce or reduce/reduce conflicts, and
>> maintains general backward compatibility. If a proposer manages to
>> ge
> Rather than proposing something by way of example, I would like to
> see all proposals in the form of a parser patch that does not
> introduce extra shift/reduce or reduce/reduce conflicts, and
> maintains general backward compatibility. If a proposer manages to
> get that far, I promise I will
On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup wrote:
>> I predict that a lot of discussions will be had, and we will end up
>> with virtually no changes. I guess that such is life.
>>
>>> Of course many of our ideas will not be good. That's fine!
>>> That's how creative thinking works!
>>
>> No;
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
> wrote:
>
>> The meta-target is "after spending 5 years very publicly telling
>> people *not* to talk about changing the syntax because we would do so
>> 'in a year or two', I think I should encourage such discussions.".
On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
wrote:
> The meta-target is "after spending 5 years very publicly telling
> people *not* to talk about changing the syntax because we would do
> so 'in a year or two', I think I should encourage such
> discussions.". I mean, people trusted me when
Janek Warchoł writes:
> On Sat, Sep 1, 2012 at 6:25 PM, Graham Percival
> wrote:
>> \postfix: c2 d\p is unchanged
>> /prefix: for music functions like c2 /parenthesize d
>> .neutral: for commands which aren't attached to notes
>
> there would be confusion with augmentation dots, and poss
On Sun, Sep 2, 2012 at 1:57 AM, Janek Warchoł wrote:
> - GOP-IDEA for posting food-for-thought,
> don't-discuss-yet-it's-just-to-let-you-know-what's-in-my-mind ideas,
> - GOP-DISC for discussing details in an orderly manner,
> - GOP-PROP for actual proposals (these emails should be read and voted
On Sat, Sep 1, 2012 at 9:39 PM, Graham Percival
wrote:
> On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote:
>> Frankly, the current syntax discussions are leading nowhere.
>> Brainstorming is fine, but pretty useless if there is no target or topic
>> other than "let's make things diffe
On Sat, Sep 1, 2012 at 6:25 PM, Graham Percival
wrote:
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for commands which aren't attached to notes
there would be confusion with augmentation dots, and possibly with
rational numbers.
On S
Le 1 sept. 2012 à 18:25, Graham Percival a écrit :
> Continuing to brainstorm on the problem of it not being obvious to
> which note a particular \command refers to, what if we used:
>
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for c
On 1 September 2012 18:25, Graham Percival wrote:
> Continuing to brainstorm on the problem of it not being obvious to
> which note a particular \command refers to, what if we used:
>
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for com
Graham Percival writes:
> On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Continuing to brainstorm on the problem of it not being obvious to
>> > which note a particular \command refers to, what if we used:
>> >
>> > \postfix: c2 d\p is un
Am 01.09.2012 21:39, schrieb Graham Percival:
[...]
At Waltrop, you only heard about one quarter of the ideas that Janek had.
I think that Janek has spent quite a lot of time collecting and formulating
his ideas. What about posting his ideas and use them as a discussion base
in terms of usabi
On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Continuing to brainstorm on the problem of it not being obvious to
> > which note a particular \command refers to, what if we used:
> >
> > \postfix: c2 d\p is unchanged
> > /prefix: for music fun
Graham Percival writes:
> Continuing to brainstorm on the problem of it not being obvious to
> which note a particular \command refers to, what if we used:
>
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for commands which aren't attach
> What about this: A command used as a prefix needs to enclose its
> argument in braces (or whatever). Commands like \relative already
> look similar.
>
> postfix: c2 d\p
> prefix: c2 \parenthesize { d }
Uh, oh, please forget this. It would be great if it could be that
simple :-/
We
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for commands which aren't attached to notes, such
> as .clef or .times.
I don't like that very much. What about this: A command used as a
prefix needs to enclose its argument in braces (o
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .time
78 matches
Mail list logo
