[MEI-L] Introduction and engraving/typesetting considerations

[Urs Liska]

Hi Christopher,

Am 06.07.2014 00:20, schrieb Christopher Antila:
> On Sat, 2014-07-05 at 13:21 +0200, Urs Liska wrote:
>> thanks for these thoughts!
>> I can't instantly judge all the implications but it seems there are many
>> common aspects and intersections with my ideas. You are right that it
>> seems like a *big* project, and there should be thorough discussion
>> beforehand.
> We would also probably learn a lot by trying out a variety of
> approaches, then choosing between them. Between the three of us (Klaus,
> you, and myself), we already envision three different strategies for an
> mei2ly program, and that's a good thing.

Yes, and I suggest to try first to discuss as much as possible and make 
the trials not too extensive. Usually one tends to want to stick to an 
approach once one has invested considerable amounts of work into it ;-)

Two links as a start:
https://github.com/wbsoft/frescobaldi/wiki/Notes-about-ly.music
which is IMO the best way to approach programmatic handling of LilyPond 
files available.

http://pyxb.sourceforge.net/
I don't know that package but I think something like this could be very 
handy to create a broker between two different DOMs as I suggested.

>
>> For example one should think about where such a thing could be placed
>> best: as a standalone script, a module in Frescobaldi, a kind of
>> "service" etc. (a cool interface could for example be a virtual file
>> system, but that's just an un-educated shot in the dark).
> No surprise, but I was thinking something along the lines of Git or
> Mercurial.[1][2] In fact, because versions and versioning will certainly
> play a central role in how this set of tool will work, we might consider
> strong integration with one of those.

As it happens I only know Git so that's what I'm usually thinking about. 
But there are some important points that could speak for using Mercurial 
in such a context (please object if I'm wrong here). To integrate Git 
functionality in a program you have to invoke it as a shell command and 
interpret its output. This is tricky because a) Git's output isn't 
completely intended to be machine-readable, b) you can't rely on it 
being consistent over Git program versions and c) sometimes it's an 
issue which information are output to the standard and which to the 
error channel.
If I see correctly Mercurial can be integrated in the program itself, 
which should make it significantly easier to handle if using version 
control is a central task for the program.

>
>> But most importantly it has to be thought through how what you described
>> with the example of score and parts can be made generic enough to
>> accomodate the other MEI-related ideas of providing different views on
>> an edition.
> For LilyPond's purposes, the "broker" program could use git branches or
> mercurial branches or bookmarks to negotiate changes between different
> editions or versions encoded in the same MEI file. For example, a single
> MEI file can hold both the 1915 and 1919 versions of Sibelius' fifth
> symphony; the corresponding LilyPond files might be stored in different
> branches.
>
> In fact, these branches could be used to maintain the files
> corresponding to all sorts of different "views." The "broker" could also
> manage the files of other programs like MuseScore or an MEI-to-MusicXML
> converter.

Sounds very reasonable. Again, I don't claim to fully grasp the 
implications yet, so this should be elaborated somewhat more (but 
somewhere else than this thread).

>
>> I've taken the trigger to create a stub repository on Github
>> (https://github.com/openlilylib/mei2ly) - you'll have been notified
>> about that already, I suppose.
> Thanks for pushing me in the deep end---it's the best way to get
> started! I like your description of the four goals. At the moment it
> seems we could target three of them: continuing development of Klaus's
> mei2ly; starting an ly2mei program; and developing a simple "broker."
> I'm particularly interested in the last program, since it's not like
> anything I've done before. I'll start thinking about it and maybe post a
> simple sample program to the repository.

OK, I'm looking forward to that.

Best
Urs

>
>
> Christopher
>
> [1] http://www.aosabook.org/en/git.html
> [2] http://www.aosabook.org/en/mercurial.html
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>