Re: Plan for discussions

[Janek Warchoł]

On Tue, May 15, 2012 at 6:23 PM, Graham Percival
<address@hidden> wrote:
> On Mon, May 14, 2012 at 07:18:58PM +0200, Janek Warchoł wrote:
>> It's nice, but i'd go farther: what about adding an
>> "editorial" property to objects?
>
> Isn't that doable with a custom editorials.ly file, which would
> contain a bunch of scheme and tweaks?  (similar to gregorian.ly,
> except with more scheme?)
>
> I don't see this as a "core lilypond" thing.

Maybe.  It doesn't matter to me whether it should be implemented with
a .ly library or c++ engraver, i just want it to be robust and "native
to Lily", not an artificial "add-on".

> I don't think that we're in the state where we can try "central
> planning" for things like graphical notation.  Simply coming up
> with automation and policies to enable such work is already
> stretching the limits of the central planning.

On the other hand, people are more enthusiastic about working on
LilyPond features than on development administration.  If they decide
to contribute new features only, let's make sure that we can "point
them in the right direction", i.e. tell them what is "the LilyPond way
of doing this".

>> Have you read my articles in TLR #25 ("My LilyPond experience" and
>> "LilyPond’s future")?
>
> Sorry, not in detail.

They are exactly about what i'm taking here.  Or at least that was my
intention when i had been writing them.

>> some of these issues could be solved by "low-level changes in
>> architecture" (at least they seem low-level changes in architecture to
>> me) - which means that they should be discussed early, not after the
>> "basic" changes are made.
>
> I think you're mixing up code architecture with input syntax.
> There may be some cross-over, but I'd expect such problems to
> become apparent during the discussion.

maybe, i don't know.  i'm not experienced enough.  That's why i hope
for an in-person meeting with some devs before we start.

>> I think we should take a more abstract approach, for example: what a
>> music expression is and what can be done with it?  E.g. since
>> b-\staccato
>> means "b note played staccato", should we allow
>> { b b b b }-\staccato
>> meaning "four b notes played staccato"?
>
> I'm fine with this being part of the first phase.

Great!  I have more things like that.

cheers,
Janek