[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: preliminary GLISS discussions
From: |
David Kastrup |
Subject: |
Re: preliminary GLISS discussions |
Date: |
Sun, 02 Sep 2012 14:07:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) |
Jan Nieuwenhuizen <address@hidden> writes:
> David Kastrup writes:
>
>>> Maybe the time has finally come to drop convert-ly and implement and
>>> fully supported conversions using LilyPond on music stream level.
>>
>> You still need a parser of the appropriate version at the front end.
>
> We have perfectly fine ly parsers of each available version available in
> executable form from lilypond.org. What we do not yet have, is a handy
> or integrated way of dumping the music tree with the original binary
> [read: a nice web service -- this could possibly be integrated with a
> mutopia revival, I'll be looking into this] reading the music tree with
> the current version and a perfect ly-dump function. Eg, I think we may
> want to preserve %-comments in the music tree, or other stuff the user
> does not want to lose?
For an emergency conversion web service of an archive in case of
convert-ly failure, a Scheme-written package diverting all required
hooks like toplevel-book-handler, toplevel-bookpart-handler,
toplevel-score-handler, toplevel-music-handler, toplevel-text-handler
could likely be written. The meaning of spacing variables would need
conversion, some overrides likely as well, context definitions and stuff
would be a bit tricky to properly detect (but one could just start out
with empty context/output defs and consider every change as relevant),
but as an emergency measure, I consider the likelihood of getting at
least something useful out for a majority of scores when run on the
respective original version of LilyPond reasonably high.
It would work at the music expression level, not at the stream event
level: the latter has already lost too much information.
All the input syntax/music function folderol would not be an issue since
those have already done their work at the time of calling the handlers.
Markup functions might be more tricky.
--
David Kastrup
- Re: preliminary GLISS discussions, (continued)
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/01
- Re: preliminary GLISS discussions, Janek Warchoł, 2012/09/01
- Re: preliminary GLISS discussions, Graham Percival, 2012/09/02
- Re: preliminary GLISS discussions, Keith OHara, 2012/09/02
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/02
Re: preliminary GLISS discussions, Han-Wen Nienhuys, 2012/09/01
Re: preliminary GLISS discussions, Marc Hohl, 2012/09/01
Re: preliminary GLISS discussions, Jan Nieuwenhuizen, 2012/09/02
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/02
- Re: preliminary GLISS discussions, Jan Nieuwenhuizen, 2012/09/02
- Re: preliminary GLISS discussions,
David Kastrup <=
- Re: preliminary GLISS discussions, Han-Wen Nienhuys, 2012/09/03
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/03
- Re: preliminary GLISS discussions, Graham Percival, 2012/09/03
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/03
- Re: preliminary GLISS discussions, Han-Wen Nienhuys, 2012/09/03
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/03
- Re: preliminary GLISS discussions, Benkő Pál, 2012/09/03
Re: preliminary GLISS discussions, Janek Warchoł, 2012/09/03
Re: preliminary GLISS discussions, David Kastrup, 2012/09/03
Re: preliminary GLISS discussions, Janek Warchoł, 2012/09/03