Re: GOP2-3 - GLISS (final)

[Janek Warchoł]

Dear Team,

sorry for a late answer - it took some time to formulate my thoughts.

First, a quite obvious remark: keeping old binaries isn't a solution
to syntax problems at all, because they may not run on new platforms
and don't contain new features and bugfixes.

As for convert-ly, i'm not opposed to it by any means - but it cannot
solve all our problems, neither.  It's not only because of things like
spacing changes, which are impossible to write down as convert-ly
rules (even if it was possible, it would be unwise to do so, since new
spacing is usually better than the old).  I'm talking about things
that are currently impossible to express directly in Lily syntax.
Take fermatas for example.  To add a fermata to a note, you write
\fermata.  This doesn't affect MIDI playback, but otherwise it's ok.
Now, to add a fermata to a barline, you have to write \mark \markup {
\musicglyph #"scripts.ufermata" }.  This isn't just ugly to write -
it's meaningless.  It just says "print some glyph".  If we improve
\fermata (e.g. adding better MIDI performance), it won't affect
fermatas over barlines, because they are just some shapes tucked in a
rehearsal mark.
This is a real problem: convert-ly cannot handle things like that.
Because there are many things that cannot be "natively" expressed in
Lily syntax, people write their own functions and hacks - i think that
these functions, as well as corrections necessary for achieving
correct output, are causing most trouble wrt/ syntax changes.

Looking another way round: if i write some music using a
straightforward score structure and without overrides (i.e. only
musical content), i don't expect that much of compatibility issues
arising.  The problem is that there's not much music that can be
written w/o overrides.
Maybe i lack experience and things don't look this way, but this is
what i feel: one of our main goals should be to define efficient
syntax rules that can be extended to as much of the
"not-implemented-yet" functionality as possible, so that we know how
to design it when we finally do.

This is not to say that we need to do these things right now - just
keep them in mind.


On Wed, Jul 25, 2012 at 12:33 PM, Francisco Vila <address@hidden> wrote:
> Speaking of, another stupid idea I once had, was to establish big
> "ranges of music Lily can do", for example "All J.S.Bach" and try to
> find counter-examples that break this set. If we find them, _that_
> would be a good source of ideas for improving LilyPond. If we don't
> find any, we go for the next level, say "All Bach' sons" or "All
> Salieri" and so on. Of course we could (should) go backwards as well,
> e.g. "All Lully". Eventually we'll reach a certificate or seal of
> compatibility for a range of composers

That's a good idea!  I suggest that we extend this to "ranges of music
Lily can do good", i.e. music that Lily can engrave without noticeable
flaws by default (no overrides).
(in my opinion this set is currently empty :P)


On Fri, Jul 27, 2012 at 5:56 PM, Han-Wen Nienhuys <address@hidden> wrote:
> Rather than "defining" some stable subset (and then getting into a lot
> of discussion on what that subset should look like), I think we should
> just take the overall decision on intent, that is: what are we trying
> to do? My suggestion is:
>
> * big changes: not OK

I don't agree! In my opinion there are some big changes that should be
made.  I think the point of GLISS is to do them once and for all.
Scores created before GLISS /might/ get somewhat screwed (wrt/ new
syntax), but there won't be any more problems of such magnitude for
many years.


>> PLEASE DO NOT DISCUSS THESE RIGHT NOW.
>>
>>     - do we keep dutch as the default language, or switch to
>> english?
>>     - do we finally make that \times -> \tuplet change that’s been
>> discussed for years?
>>     - \score \staff vs. \new score \new staff.
>
> I understand the desire of each of these changes, but I don't see any
> of them either:
>
> * expand on what people can do with LilyPond
> * dramatically simplify our parser/lexer code in a way that brings
> future rewards.
> * dramatically expand our user-base

Sorting these things out will make Lily easier to understand to
non-programmers.  I'm sure this will expand our user-base, be it a
dramatic expansion or not.
I'd prefer to have these sorted out myself.

> I also think that there are very few changes that could meet these
> standard because:
>
> * what people can do is very often limited by the typesetting
> infratstructure rather than syntax
> * the lexer/parser is complex, but it is sunk cost. Cleaning it up is
> only worthwhile if you intend to do further work (ie. more syntax
> changes) on it.
> * people that don't use Lily now probably do for lack of a graphical 
> interface.

I'm not sure about this.  I'd rather say that they don't seriously
*try* it because there's no GUI.
Example: i'm a librarian in a semi-professional [1] church choir
Epifania, and i'm currently introducing "distributed engraving" to our
workflow (i.e. many people create fragments of a score-to-be-copied in
Lily code and i glue them together).  Neither the conductor nor choir
members were particularly fascinated by Lily's text input.  Still, i
don't know of anyone who /tried/ to help with typesetting and got
discouraged by lack of GUI.

[1] = repertoire includes Mozart's Requiem and Coronation Mass,
Dvorak's Stabat Mater and similar pieces

On Mon, Jul 30, 2012 at 8:07 PM, David Kastrup <address@hidden> wrote:
> Graham Percival <address@hidden> writes:
>
>> In general, yes.  But some aspects of our syntax haven't been
>> around for a long time -- footnotes, woodwind fingering, compound
>> meters, etc.  Do we have the best syntax for those?  I mean,
>> maybe David can figure out a way to allow us to write
>>   \compoundMeter (3+2)/8
>> or simply
>>   \time (3+2)/8
>> instead of
>>   \compoundMeter #(3 2 8)
>
> I'd have done so already, but \time takes an optional beatstructure
> argument that is indistinguishable from a compound meter, being a number
> list.

Sorry, i don't understand.  You mean that you know how to do this, but
there's something else blocking you from implementing it?
Anyway, from my point of view (user-friendliness obsession) this would
be fantastic!  I'm ready to pay 25 euro for being able to use \time
(3+2)/8 (without any additional hashes, quotes etc) as a legitimate,
fully-supported meter command.

cheers,
Janek