Re: preliminary GLISS discussions

[Jan Nieuwenhuizen]

Han-Wen Nienhuys writes:

> On Mon, Sep 3, 2012 at 7:20 PM, Janek Warchoł <address@hidden> wrote:
>>> Well, one simple consequence would be that one can't define music
>>> functions in a document (their definition is interpretation, their use
>>> is parsing).  The use of Scheme would be quite constrained, as reading
>>> it is parsing, evaluating it interpretation.
>>
>> Ouch.  Sound like something we seriously don't want at all.
>
> Right - this means that we seriously don't want to be a music
> interchange/storage format.

Okay...this is going somewhere; getting close to the point of having
value being documented.

On constraining scheme to be a MISF Janek says: "Sounds like we
don't want" and Han-Wen makes that into "Right - we seriously don't
want to be a MISF".

I can appreciate not trying to pretend .ly into an acceptible
Interchange format, it is not.  But dropping the ball on being a
dependable Storage format may not be so nice.  Also, this ignores
another big effort we make, the Human Readable bit.

It would be a win if we could decide that we drop the ball on being a
MISF (for now/...) However

   1 some users may not be too happy with this idea
   2 is there any value in a MISF over our proprietary .ly?
   3 we are one of the players in this field, what kind of MISF
     would we suggest, how /should/ music be stored?

1. I expect that the major use case for LilyPond is to print a score.
Still, if we say: we'll probably provide a half-baked convert-ly but you
may have to do most manual work again in 3 years, people may not be
so eager to supply mutopia with large symphonic works, or even not
choose to use LilyPond at all.  And possibly for the wrong reasons?

2. It seems just great to be able to digitalize a music library,
however, a MISF is useless without a way to edit it.  MusicXML is not a
human readable format, so a music software is required.  This still ties
a particular MusicXML score to a particular software, which makes its
value as a proper Interchange and Storage format over .ly dubious at
best.

3. If we don't decide on this issue, the default choice will be
MusicXML.  If that's not good advise, how can we do better?

Should we seek to support/improve MusicXML or add another input format?
Restricted .ly?  Use full .ly as input and then store the internal music
tree?

We could possibly do with some input from our user base.  If we want to
target publishing houses or music libraries, we might have to change our
ideas or priorities about creating or dumping to a [supported .ly subset
suitable as a] MISF.

Jan
-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl