Re: Reasons why a LilyPond-to-MEI conversion should be developed

> On Oct 24, 2015, at 3:02 AM, David Kastrup wrote: > > The latest is that the project is over and I have a dump of stuff I need > to integrate into LilyPond before it may be useful. My motivation to do > that is so-so as I've not yet seen a cent of the tutor's money yet (and > no

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Paul Morris writes: >> On Oct 24, 2015, at 3:02 AM, David Kastrup wrote: >> >> The latest is that the project is over and I have a dump of stuff I need >> to integrate into LilyPond before it may be useful. My motivation to do >> that is so-so as I've not

Re: Reasons why a LilyPond-to-MEI conversion should be developed

rtant to be plausible and credible in order to get the >> application accepted. >> >> mei2ly, the possibility to use LilyPond to engrave MEI encoded editions, >> is clearly the foundation of the project, so there's nothing to argue >> about that. There are technical aspects, e

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Noeck <noeck.marb...@gmx.de> writes: > Me personally, I don't see the point in creating MEI files. I like the > LilyPond input language. It is a concise and human readable > representation of the music. I can use version control (git). I don't > see what MEI would improve f

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Simon Albrecht writes: > On 24.10.2015 16:54, David Kastrup wrote: >> They are not in LilyPond. There is no tangible or recognizable thing >> like a "music stream" > […] >> chances are rather slim that parts of the code >> could be usefully adapted to work with LilyPond

Re: Reasons why a LilyPond-to-MEI conversion should be developed

On 25.10.2015 09:15, Urs Liska wrote: if LilyPond should consume >>MEI > >Interesting thought. I should be surprised if MEI were to consent in >granting LilyPond this honour (as which I’d consider it). Given the >‘universal’ intent of MEI, they might not want to ‘take sid

Re: Reasons why a LilyPond-to-MEI conversion should be developed

> quality of LilyPond. This is true, and one of the reasons why I think LilyPond should bother with this idea in the first place. But that's not what I wanted to know. I'm explicitly asking: "Why should a project to integrate LilyPond in the MEI context also develop the ly2mei dire

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Hi Urs, I totally overlooked the 'LilyPond-to-MEI' part (the central part) of your question. And I wondered why you ask that question while knowing already so many good answers to it. Sorry. > This may not be something that you, Joram, are after, but something that > could be considered a

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Simon Albrecht writes: > On 24.10.2015 03:18, Paul Morris wrote: >> LilyPond’s internal scheme data structure is a good target for >> import and export > > Or even more so the music stream internally used by LilyPond after > Erik Sandberg’s work. IIUC there is some doubt

Re: Reasons why a LilyPond-to-MEI conversion should be developed

On 24.10.2015 16:54, David Kastrup wrote: They are not in LilyPond. There is no tangible or recognizable thing like a "music stream" […] chances are rather slim that parts of the code could be usefully adapted to work with LilyPond these days. What a pity, it would have seemed a nice

Re: Reasons why a LilyPond-to-MEI conversion should be developed

. As the input is further disentangled from the output, users could use any input tool that supports MEI and still can get LilyPond output. That way we could have a GUI input method (which I presume exists for MEI) for free. That's what comes to my mind. Me personally, I don't see the point

Re: Auto-generated code, (was Re: Reasons why a LilyPond-to-MEI conversion should be developed)

Dear Richard, first I want to emphasize that this was not against you or Denemo, just a connection between my favoured workflows and the tools I use. I don't understand 'traverse the staffs' in your sentence: > It *does* provide a > default LilyPond output, but you can just as easily traverse

Re: Reasons why a LilyPond-to-MEI conversion should be developed

While MEI may be ‘universal’ in intent, it is just an open source project. Since lilypond is open source, it would make sense for the open source community to cooperate. But how many people use MEI, and how much traction has it gained? Is it universally favoured? In other words

Re: Reasons why a LilyPond-to-MEI conversion should be developed

On 24.10.2015 03:18, Paul Morris wrote: LilyPond’s internal scheme data structure is a good target for import and export Or even more so the music stream internally used by LilyPond after Erik Sandberg’s work. IIUC there is some doubt as to how complete the features he describes in his

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Paul Morris <p...@paulwmorris.com> writes: > I think the same considerations that apply for MusicXML also apply for > MEI. See the discussions about the Google summer of code project from > last spring. > > Namely, LilyPond’s internal scheme data structure is a goo

Re: Reasons why a LilyPond-to-MEI conversion should be developed

On Sat, 2015-10-24 at 01:39 +0200, Simon Albrecht wrote: > e.g. if LilyPond should consume > > MEI > > Interesting thought. I should be surprised if MEI were to consent in > granting LilyPond this honour (as which I’d consider it). I think what was meant was "the lil

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Am 24. Oktober 2015 10:05:55 MESZ, schrieb Richard Shann <rich...@rshann.plus.com>: >On Sat, 2015-10-24 at 01:39 +0200, Simon Albrecht wrote: >> e.g. if LilyPond should consume >> > MEI >> >> Interesting thought. I should be surprised if MEI were to consent

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Am 24.10.2015 um 08:04 schrieb Andrew Bernard: > While MEI may be ‘universal’ in intent, it is just an open source project. But a project backed by a very distributed, connected and publicly funded academic community. >Since lilypond is open source, it would make sense for the open

Re: Reasons why a LilyPond-to-MEI conversion should be developed

Am 24.10.2015 um 03:18 schrieb Paul Morris: > I think the same considerations that apply for MusicXML also apply for MEI. > See the discussions about the Google summer of code project from last spring. > > > Namely, LilyPond’s internal scheme data structure is a good ta

Reasons why a LilyPond-to-MEI conversion should be developed

from what we may be interested in it's important to be plausible and credible in order to get the application accepted. mei2ly, the possibility to use LiylPond to engrave MEI encoded editions, is clearly the foundation of the project, so there's nothing to argue about that. There are technical

Re: Reasons why a LilyPond-to-MEI conversion should be developed

I think the same considerations that apply for MusicXML also apply for MEI. See the discussions about the Google summer of code project from last spring. Namely, LilyPond’s internal scheme data structure is a good target for import and export (better than LilyPond’s plain text input syntax

Re: Reasons why a LilyPond-to-MEI conversion should be developed

, the possibility to use LilyPond to engrave MEI encoded editions, is clearly the foundation of the project, so there's nothing to argue about that. There are technical aspects, e.g. if LilyPond should consume MEI Interesting thought. I should be surprised if MEI were to consent in granting LilyPond

Re: Planning a MEI-to-LilyPond project

nt amounts of money (= development capacity) >> thrown at us, and one can assume a significant share of that going >> into LilyPond development itself, and a significant share of *that* >> part benefitting LilyPond users in general, without considering the >> MEI/Digital Edition

Planning a MEI-to-LilyPond project

Dear developers, most of you will know or at least have noticed that I have thought about integrating LilyPond and the XML based MEI format. If not you might consider reading my current post on http://lilypondblog.org for an introduction. Today I would like to make kind of an announcement

Re: Planning a MEI-to-LilyPond project

ignificant share of that going > into LilyPond development itself, and a significant share of *that* > part benefitting LilyPond users in general, without considering the > MEI/Digital Edition part. Well, the main question when money is about to get thrown at a project is whether ther

Re: Planning a MEI-to-LilyPond project

now or at least have noticed that I have thought about > integrating LilyPond and the XML based MEI format. If not you might > consider reading my current post on http://lilypondblog.org for an > introduction. Today I would like to make kind of an announcement and > call for discussion.

vero vio MEI to SVG

Hello list-members, this is just a short note about something, I came across these days. There is a library to convert MEI-xml to SVG: http://www.verovio.org/index.xhtml Lilypond can of course produce SVG by itself. But as mentioned on the website, the verovio-API invites to produce other

MEI

I think this is important also for us: http://www.sibeliusblog.com/news/mei-plug-in-released-for-sibelius/ MEI is an important initiative for standardizing the encoding of music, with particular interest in encoding every aspect of a composition and its sources. I think

Re: MEI

://www.sibeliusblog.com/news/mei-plug-in-released-for-sibelius/ MEI is an important initiative for standardizing the encoding of music, with particular interest in encoding every aspect of a composition and its sources. I think this will be an important foundation for future music editing, and if even