[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can you give a sample ETF file? and other questions

From: Jean Abou Samra
Subject: Re: Can you give a sample ETF file? and other questions
Date: Sun, 14 Jun 2020 21:47:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


Le 14/06/2020 à 20:30, Valentin Villenave a écrit :
On 6/14/20, Jean Abou Samra<>  wrote:
That's how I stumbled on etf2ly. There are no regression tests and I
couldn't find a single ETF file across the Net to see how the script's
output looks like. Can anyone provide one?
You can find a bunch of those online, for example here:
Thanks for that link! I had been searching for hours!
ETF is still one of the valid formats on WIMA and IMSLP, and it was
quite readable until 2005 or so.  That may seem like ages ago to you
and me, but have a chat with a librarian and you’ll hear otherwise.
ETF is Finale's former exchange format, which they deprecated in favor
of MusicXML. Finale can no longer export to ETF starting from Finale
2007. It's still able to import ETF though. Perhaps etf2ly could go to
the trash...
Why? It hardly costs us any resources (the most activity it has seen
in a dozen years is when Jonas got it Python3-compatible a few weeks
As part of MR !157, I even found a link that’s still alive to replace
the one in the current header:

  From a general point fo view, it would be helpful to have some context
about the scripts. Which of them do you think are the most widely used?
Among those, musicxml2ly is obviously the most helpful, but I don't
quite know about the others. The ABC format looks still active, and the
Score extension in Wikipedia supports it through abc2ly, but I'm unsure
wether it's frequently used.
Not being free, ETF may reach a point where it’ll be _only_ readable
through etf2ly.  That would be unfortunate as we’ll obviously never
actively support etf2ly again, but that would still be considerably
better than nothing.
If you want to remove any part of LilyPond that isn’t actively
supported or used, you’ll find a *lot* of outdated cruft we could do
without.  (Hell, we could even export our fonts once and for all in
OTF and get rid of MetaFont/MetaPost altogether!) But that’s one of
the upsides of Free Software: not having a commercial target to meet
or shareholders to answer to, we can bear with things on a much longer
timescale (which is how I’m writing this very message with a recent
Firefox build on a 1999 laptop, btw).

That’d be my point of view, at any rate.

-- V.

The question here was rather "Should I try to make this work too if I tried
to renew abc2ly?" than "Hey, this isn't used, it must die!". Your argumentation is very convincing; no problem, let's keep etf2ly. (Although it doesn't work right now because of encoding problems... perhaps I'll have a look at it, if and only if I have time for that). My main problem right now is to know wether I should consider enhancing abc2ly and midi2ly. They would need substantial work to be made in line with modern LilyPond syntax and Python 3, so now that I have become at least a very little bit familiar with these files, I'd like to know wether that's old cruft too
or not before putting lots of effort into them.

The other question could be the extent to which we support that kind of cruft,
for example, should we add regression tests? That's not a priority however.

Jean Abou Samra

reply via email to

[Prev in Thread] Current Thread [Next in Thread]