On Sun, May 13, 2012 at 11:34 PM, Graham Percival
<gra...@percival-music.ca> wrote:
> On Sat, May 12, 2012 at 02:14:27PM +0200, Janek Warchoł wrote:
>> what changes in the LilyPond design should we make to make
>> LilyPond a more efficient and easy to use tool.
>
> LilyPond itself will remain as a command-line "compiler".
This one was easy :)
> So this question can be split into two separate ones:
> - what capabilities should alternate programs (i.e. frescobaldi)
> have?
> - what should the input syntax be?
These are valid questions, but i think there's more.
For example, i'm currently working on new edition of Oskar Fried's
songs with Urs Liska. Urs had created his own set of commands to mark
editorial items. 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.
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)?
Have you read my articles in TLR #25 ("My LilyPond experience" and
"LilyPond’s future")?
>> > I think last year's GOP communications guidelines were sufficient.
>>
>> Hmm? I recall only one decison: "Potentially sensitive or private
>> matters will be referred to Graham." (GOP 6) It's only partially
>> applicable to the problems we sometimes have in our discussions (in my
>> opinion).
>
> I meant the general method of me announcing a discussion, waiting
> a week, summarizing the discussion, waiting a week, then moving
> forward. For other things, there's the countdown process.
Ah, you meant "guidelines for communication during GOP" while i
understood "guidelines about communication established by GOP".
> It sounds like you want to have something in between a normal
> countdown and a GOP item.
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.
>> I have an idea about syntax that would affect bot "regular" and
>> "tweak" syntax, and it doesn't make much sense to discuss it in two
>> parts because the logical connection would be lost.
>
> Well, I'm trying to find some way of focusing discussion. So
> imagine that you want to typeset the simplest possible music that
> it still reasonable -- say, a solo cello Bach suite.
> Single-staff, (mostly) monophonic, (mostly) diatonic, etc. Can we
> finalize on input syntax to represent such pieces?
>
> Maybe that's *too* focused, so consider a slightly harder version. [...]
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.
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 :
- simultaneous rehearsal marks
- hairpins and anything else not "aligned" with notes (articifial
spacer constructs are now necessary)
- slanted spanners (currently they must be rotated by hand)
- cross-voice ties and other things
- custom dynamics
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 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"?
cheers,
Janek
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
