Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Knute Snortum
I have run into one (but only one) problem going from 2.18 to 2.19: if you force-hshift a NoteColumn to the left, the dot no longer follows the note head and stem. You have to force-hshift the Dots grob too. --- Knute Snortum (via Gmail) On Wed, Apr 5, 2017 at 3:43 AM, Andrew Bernard

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Andrew Bernard
Greetings Shevek, There's no need to be quite so cautious I think. Use convert-ly and see how you go. It's easy enough to visually scan a hundred pages output to check for errors - I do it all the time with my current piece of double that length. I have written quite a few times on this list

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread David Kastrup
Shevek writes: > The change documentation vaguely mentions that functions defined the > old way will continue to work for some time, so I'm unclear the degree > to which this matters to me, or in what circumstances I should worry > about it. convert-ly is pretty good

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread David Kastrup
Malte Meyn writes: > Output changes: MIDI articulation, MultiMeasureRest spacing, whiteout style. > > Input changes: the omission of “parser” and “location” arguments in > music functions, convert-ly takes a good stab at that, and even then it's optional. I really think

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Shevek
That's pretty much the process I used from 2.16 to 2.18, and that I planned to use here. It would still be really helpful if I had a sense of likely situations where the graphical output could be significantly different. Obviously ultimately, I just have to try and see how it goes, but if you can

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Shevek
The change documentation vaguely mentions that functions defined the old way will continue to work for some time, so I'm unclear the degree to which this matters to me, or in what circumstances I should worry about it. -- View this message in context:

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Malte Meyn
Am 05.04.2017 um 09:15 schrieb Shevek: > In terms of Scheme changes, how does this affect compatibility with snippets > written on 2.16 or 2.18? Most notable change is the change in definition of music function changes: #(define-music-function (parser location arg1 arg2) (type1? type2?) …)

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Shevek
It appears that the glissando slope and the cross-staff dynamics bugs would be relevant to my project. If I'm reading correctly, the glissando slopes issue is already present in 2.18, so that behavior wouldn't change in 2.19 as it's not yet fixed (a good thing for me, since I'm pretty sure I used

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Urs Liska
Am 05.04.2017 um 08:56 schrieb Malte Meyn: > > Am 05.04.2017 um 08:17 schrieb Shevek: >> 1) How stable is 2.19 for end users on a demanding project? In general 2.19 is totally stable enough also for demanding and real-world projects. >> It seems like >> forever since 2.18, so I'm sort of

Re: Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Malte Meyn
Am 05.04.2017 um 08:17 schrieb Shevek: > 1) How stable is 2.19 for end users on a demanding project? It seems like > forever since 2.18, so I'm sort of surprised there hasn't been 2.20 already. > Is there some major problem I should be worried about in 2.19? See

Converting a large project from 2.18 to 2.19: what to expect?

2017-04-05 Thread Shevek
Hi, I'm currently in the process of composing a symphony in Lilypond 2.18.2. There are a few graphical bugs that are making me consider converting the project to the current 2.19 (parentheses/accidental collision, tempo mark spacing with uniform-stretching), but I'm hesitant to jump immediately