Re: Plan for discussions

[Graham Percival]

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?  User could mark some items as
> editorial and LilyPond would take care of the rest: she would put the
> editorial dynamics in brackets, make editorial slurs dashed etc. - or
> hide them altogether when user asked for a urtext edition.
> Out-of-the-box functionality.

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.  Rather, a user (or
group of users) would develop that functionality, then once they'd
used it for a while and it seemed stable, we'd include it in our
ly/ directory.  Search the mailing list archives for "ly/
directory organization" for all the previous times I've tried to
get this moving.

> In a way this boils down to the "input syntax", but not only this.  My
> question is: are we more interested in supporting more notation
> elements (ancient, regional, contemporary notations, special
> articulations, graphic notation) or in making things work more
> smoothly out-of-the-box (improving spacing - which is hard to tweak -
> as well as curve shapes, etc)?

I personally am interested in helping people to do whatever they
want with lilypond.  Somebody wants to work on ancient notation?
great!  somebody wants to add fluffy bunnies to contemporary
notation?  great!  somebody wants to reduce collisions?  great!

Simply creating an atmosphere where this is easy takes more
resources than we have available.  As has been noted a few times,
contributing is harder than it should be, yet we still have
multiple people handling admin tasks.  I think we should have more
automation, freeing up people to do more interesting/creative
tasks, allowing them to tackle the problems they want to solve.

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.

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

Sorry, not in detail.

> Maybe, i'm not sure.  I was thinking about our communication in
> general (how to avoid conflicts and/or misunderstandings), not about a
> way to formalize discussions.

IMO, a (somewhat) formalized discussion is the best way to avoid
conflicts and/or misunderstandings.

> At first look this approach seems ok, but after some thought i have
> serious concerns: i think this can result in syntax nice for simple
> notation, but not flexible enough when things become more complex.

That's why we'd discuss the more complicated stuff later?

> There are things hard to express in current syntax which i suppose
> wouldn't appear in "simple notation examples", so with your suggested
> approach we would probably postpone them - examples :
-snip-
> 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.

> 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.

- Graham