Another round of questions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Another round of questions

Jean ABOU SAMRA
Hi,

I know everyone on this list is focused on the GitLab transition at
present, but if you have got a few minutes...

Currently, I'm trying to dive into LilyPond's Python codebase. This
prompts me to ask a few questions. First, is there any way to run the
MusicXML test suite and other tests related to Python scripts without a
full "make check"?

Also, I've heard of projects including a MusicXML to LilyPond converter
developed at Grame that could eventually replace musicxml2ly, and more
recently, Parce and Quickly, which may eventually implement converters
too (?). So, I'm wondering: would it be worth the effort if I did a
cleanup in musicxml2ly's code or is it intended to replace it with
Grame's converter anyway? More broadly speaking, what should be
prioritized among the files under python/ ?

Best regards,

Jean Abou Samra


Reply | Threaded
Open this post in threaded view
|

Re: Another round of questions

Werner LEMBERG

> So, I'm wondering: would it be worth the effort if I did a cleanup
> in musicxml2ly's code or is it intended to replace it with Grame's
> converter anyway?

IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly`
covers much more of MusixXML (and will, AFAIK, also eventually support
its successor, MNX).


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: Another round of questions

Valentin Villenave-3
On 5/16/20, Werner LEMBERG <[hidden email]> wrote:
> IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly`
> covers much more of MusixXML (and will, AFAIK, also eventually support
> its successor, MNX).

Huh.  xml2ly has very different requirements than musicxml2ly and is
(AFAICS) unlikely to ever be integrated into LilyPond.  Anecdotally, I
have encountered several cases where musicxml2ly turned to provide
much more useful output than xml2ly (but that was a couple of years
ago, maybe its development has sped up since then).

Plus, since we’re discussing python-based tools, there are a few
useful functions being developed in python-ly (as part of
Frescobaldi), which share a bit more DNA with musicxml2ly than with
anything else.  So I wouldn’t count musicxml2ly out just yet.

Cheers,
-- V.

Reply | Threaded
Open this post in threaded view
|

Re: Another round of questions

David Kastrup
Valentin Villenave <[hidden email]> writes:

> On 5/16/20, Werner LEMBERG <[hidden email]> wrote:
>> IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly`
>> covers much more of MusixXML (and will, AFAIK, also eventually support
>> its successor, MNX).
>
> Huh.  xml2ly has very different requirements than musicxml2ly and is
> (AFAICS) unlikely to ever be integrated into LilyPond.  Anecdotally, I
> have encountered several cases where musicxml2ly turned to provide
> much more useful output than xml2ly (but that was a couple of years
> ago, maybe its development has sped up since then).
>
> Plus, since we’re discussing python-based tools, there are a few
> useful functions being developed in python-ly (as part of
> Frescobaldi), which share a bit more DNA with musicxml2ly than with
> anything else.  So I wouldn’t count musicxml2ly out just yet.

Personally, I see nothing wrong with maintaining tools while they are
used and distributed.  In a corporate setting, alloting large amounts of
resources into a part of the tool set that has a perspective to be
replaced in the course of a corporate development makes of course little
sense.

We aren't there.  We have no timetable for a replacement or its
viability, and so I don't see the point in discouraging contributors
from making fixes to what will continue for an indeterminate time to be
part of the tool set useful for achieving objectives.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Another round of questions

Jean ABOU SAMRA
Hi,
Le 16/05/2020 à 20:02, David Kastrup a écrit :

> Valentin Villenave <[hidden email]> writes:
>
>> On 5/16/20, Werner LEMBERG <[hidden email]> wrote:
>>> IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly`
>>> covers much more of MusixXML (and will, AFAIK, also eventually support
>>> its successor, MNX).
>> Huh.  xml2ly has very different requirements than musicxml2ly and is
>> (AFAICS) unlikely to ever be integrated into LilyPond.  Anecdotally, I
>> have encountered several cases where musicxml2ly turned to provide
>> much more useful output than xml2ly (but that was a couple of years
>> ago, maybe its development has sped up since then).
>>
>> Plus, since we’re discussing python-based tools, there are a few
>> useful functions being developed in python-ly (as part of
>> Frescobaldi), which share a bit more DNA with musicxml2ly than with
>> anything else.  So I wouldn’t count musicxml2ly out just yet.
> Personally, I see nothing wrong with maintaining tools while they are
> used and distributed.  In a corporate setting, alloting large amounts of
> resources into a part of the tool set that has a perspective to be
> replaced in the course of a corporate development makes of course little
> sense.
>
> We aren't there.  We have no timetable for a replacement or its
> viability, and so I don't see the point in discouraging contributors
> from making fixes to what will continue for an indeterminate time to be
> part of the tool set useful for achieving objectives.

Thank you all for your replies. Based on that information, I decide to
dive into the code, and we'll see what I can improve in it. My concern
was about the possible replacement being planned and pending (I told
myself it could have been delayed by the transition to GitLab), but if
it is still to be discussed wether a replacement is tangible, then I
will step into musicxml2ly with the rest. I'm unlikely to implement
stunning features anyway. My goal is rather to adapt it to Python 3, and
thus make it more maintainable by simplifying many parts of the code
that can be rewritten elegantly using constructs and standard modules
appeared in later versions of Python. Also, I consider it an investment
for a future when I would be done with the very exacting part of my
curriculum I'm currently in, and depending on many factors, I might
start contributing more seriously (but that's not for right now, really).

Best,

Jean Abou Samra