Re: [GLISS] differentiating pre/post/neutral commands

[David Kastrup]

Jan Nieuwenhuizen <address@hidden> writes:

> David Kastrup writes:
>
>> Users like to save keystrokes, and they bemoan the demise of Mutopia,
>> and the rise of MusicXML over LilyPond as a music presentation format.
>>
>> Nobody wants to see the connections.
>
> I'm glad you do.

It's not that it helps much with the underlying problem.  LilyPond is
designed to be friendly to humans rather than computers.  The mere
existence of a full-scale general-purpose extension language is a killer
criterion for music presentation in a computer-accessible way.

Probably the best we can hope for is for LilyPond becoming the workhorse
of music publishing and printing while the LilyPond language itself
becomes a well-pampered side effect, similar to the role Ghostscript has
in text publishing and printing: nobody(TM) actually uses PostScript
anymore(TM).

Of course, the roles are not entirely comparable since the PDF format as
well as PostScript itself are well-defined and correspond to one
_particular_ placement of ink on paper, while this is not the case for
either MusicXML or LilyPond input.

Regarding the processing of "symbolic" XML input, TeX/LaTeX also has
some side role: nobody(TM) actually uses TeX/LaTeX anymore(TM), but it
is still secretly or openly being used in the XML workflows of
publishers like <URL:http://river-valley.com/>.

In the medium time range, keeping something like Mutopia updated from
bitrot might be achievable using intelligent crowd sourcing, but crowd
sourcing always implies limits/costs in quality, coverage, reliability.

> That's why I suggested the investigation of truly supporting full
> future compatibility, using [an old] lilypond for parsing and [the
> current] for dumping .ly.

\displayLilyMusic has been available for quite some time, and writing an
extended version of it running under 2.10+ would be feasible as long as
the primitives for getting at the required information are available.
But the 2.10 corpus is finite, so there is no point in investing more
work for automatic conversion of it than a manual conversion would cost.

The most important consideration is to arrive at processes that will
continue to work as use of LilyPond expands.  Namely our "business
model" should be able to deal with the possibility of success.

> Until we can guarantee that .ly will not bitrot (or even better:
> backwards supporting v2.14, v2.12,...), noone in her right mind will
> want to use LilyPond for storing large music libraries.  That's a big
> loss for everyone, as musixcml does not preserve printability

Neither does LilyPond, and it won't while we improve its capacities of
placing things where they belong.

> and arguably also not full musical meaning/content.

Neither does LilyPond.  So one consideration for future development is
to provide the means to extend LilyPond regarding content.

That means, if we want to implement a feature, we have to tell LilyPond
how to put this into music, how to get it from music back to LilyPond
source, out to MusicXML, out to Midi, and out to paper.  Without needing
to write 15 different files in 10 directories and changing half a dozen
existing files.

> There is currently no solution for preserving content as well as fine
> engraving, at least not with a relation between the two.  Providing
> that would be a major win.

Still a long road ahead.

-- 
David Kastrup