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

[Jean Abou Samra]

Hi,

Le 14/06/2020 à 20:30, Valentin Villenave a écrit :
> On 6/14/20, Jean Abou Samra<jean@abou-samra.fr>  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:
> http://www.igracemusic.com/hymnbook/hymns.html
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
> ago).
> As part of MR !157, I even found a link that’s still alive to replace
> the one in the current header:
> https://www.gnu.org/software/lilypond/src/Developers/Details/etfformat.html
>
> >   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.
>
> Cheers,
> -- 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.

Best,
Jean Abou Samra