lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User-poll about lily-syntax: results - [Was: [GLISS] basics]


From: David Kastrup
Subject: Re: User-poll about lily-syntax: results - [Was: [GLISS] basics]
Date: Mon, 12 Nov 2012 12:27:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Francisco Vila <address@hidden> writes:

> I attach a text with the collected opinions. As I said, there is
> nothing "specifically syntax-specific". I would like to repeat the
> experiment next year.
>
> Sorry for the delay

> 1 Something confuse or uncoherent?
> 
>  An user found that when doing markups he usually needes to perform
>  many test and error cycles because results are were often different
>  from expected.

The design of markups and markup lists and when one is converted into
the other is rather flimsy.  That is, in my book, clearly "specifically
syntax-specific".  But I also don't see much in the way of improving
this in a mostly upward-compatible manner.  This would pretty much
require a complete redesign in order to get it to work more intuitively.

>  The fundamental question for an user (and he thinks it is for all new
>  users, too) was to realize that lilypond is a programming
>  language. Every syntax is more or less complex, and it would be
>  useless to question it without a big amount of judgement elements.

But LilyPond should rather be a music description language.  It is great
if it is easy to extend programmatically, but the purpose of those
extensions is, again, to be able to write down just "what one means" in
every instance rather than how it is done (which one needs to write down
at least once if LilyPond does not yet know it, but which should be the
exception rather than the rule).

> 2 Something especially difficult or hard to read or to write?
> 
>  Putting several voices together looks scary to use.

In what respect "putting several voices together"?

>  Handling page spacing is unclear.

Part of the problem is that our interface is too low-level to be
intuitive, I think.

>  The tie symbol ~ always produces headache and does not always work.

Well, "let ~ produce fewer headaches and make it work more often" is a
bit vague as a plan...  So it would likely be helpful if this got a bit
more specific.

> 3 Something unconvenient or cumbersome?
> 
>  Adding lyrics to a melody is in practice more tedious than what
>  appears to be from reading the manuals. Manuals do not explain this
>  point clearly enough.

I am not sure we should not show the possibility to just use lyrics with
explicit durations more prominently.  It's straightforward and more
robust than having to associate some context.

>  It would be fine to specify properties as a series of dot-separated
>  list of symbols.

I guess we are ahead on this one.

>  A better midi2ly would be welcome.
> 
> As you see, many understood the poll as a request of ideas for
> improving.

Partly.  But there were several descriptions of what people find
cumbersome also in the syntax department.

> Aside this all, users take the opportunity to thank the developers
> team and to say they are proud of their neat looking scores.

Thanks for the summary!

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]