lilypond-user
[Top][All Lists]
Advanced

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

Re: overriding voiceOne to add properties to that specific voice context


From: Maurits Lamers
Subject: Re: overriding voiceOne to add properties to that specific voice context
Date: Thu, 20 Aug 2020 17:13:00 +0200

Hi all,

@David: No, I haven't attempted to run convert-ly and I am very hesitant to do 
so because I have no clue exactly where to start. That is because it is a 
songbook with over 1000 songs, with choir arrangments and organ parts for each 
of those songs, with many complex includes and external music definitions. 
Wilfried Berendsen should be very familiar with it, as IIRC he supervised its 
creation. He might know a way of upgrading it to a more recent Lilypond version.

Also, the songbook is so 2.14 specific that I also cannot compile it using 
2.18. So, my assumption is that trying to run convert-ly on this system will 
have a huge chance of breaking things. As it is the main source for my testing 
material at the moment, i rather not break it as I am dependent on it to work.

To complicate matters I was only granted access to this songbook with the 
limitation (at the moment of me writing this) that we cannot use it for any 
other purpose than to create the music braille system. So @Lukas, I need to 
talk with the other people of the project whether we can do this, and such an 
attempt would have to be on a private git tree somewhere, because of those 
limitations.

I would definitely love to bring the entire system to the most recent version 
of Lilypond, or at least 2.18.2 (which is the version installed by default 
under Ubuntu 18.04LTS and all derivatives), but at the moment I think it could 
cause problems that would stand in the way of the main objective, which is a 
working music braille output for Lilypond.

cheers

Maurits


> Op 20 aug. 2020, om 15:42 heeft Lukas-Fabian Moser <lfm@gmx.de> het volgende 
> geschreven:
> 
> Hi,
> 
>>> Nevertheless, I'd urge you to try and make sure that everything you
>>> develop will work with current LilyPond versions. Not only in order to
>>> lower the barrier for developers to help you (or others to make use of
>>> your additions), but also because LilyPond simply has evolved a great
>>> deal in the in the nine (!!) years since 2.14.2 was released, and is
>>> now at the same time much more feature-rich _and_ easier to use.
>> Well, that's not much of a motivation to upgrade existing documents
>> (unless you want to add to them).  But the typesetting has become quite
>> a bit better, too.
> 
> My understanding was that the issue was not the upgrading of existing 
> documents, but of the codebase used in a newly-developed framework (for 
> Braille support/export). But of course it's also very true that, if I have to 
> go back to an archaic version of LilyPond in order to use a specific 
> framework, I lose not only features and ease-of-use, but also pay the price 
> of an inferior typesetting quality.
> 
> Maurits, I think the situation seems to be perfectly suited to a 
> collaborative approach using a git tree, where one person can work on 
> extending a framework, and the other could work in a separate branch on 
> making the codebase usable with recent versions of LilyPond. The latter might 
> be a task that I could try my hands on.
> 
> Lukas
> 




reply via email to

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