Re: looking for help debugging a "return code 1 error"

A little more that might help: 1. My skeleton score has a bunch of partcombine-d staves (all empty), and a single vocal staff (with music). 2. The vocal staff uses David Nalesnik’s text-spanner-inner-texts. This works perfectly in the piano-vocal score of the same piece (i.e., without the

Re: Equalizing the lines on two text spanners

Hi MIchiel, As an aside, as a player myself, I find it easier on the eyes to read the out of phase version - it is perceived as two separate entities rather than a single double line, if you see what I mean. As to how to do it, if you used \draw-dashed-line in a markup you can specify the dash

Equalizing the lines on two text spanners

Hi there, I'm working on a Lilypond version of Beethoven's Op.111, and it has a section with two text spanners: http://i.imgur.com/prSXEGL.png I would like it if the two striped lines could be totally in sync with one another, making it more like this: http://i.imgur.com/M8frBJp.png - this is

looking for help debugging a "return code 1 error"

Hello all, In 2.19.58, I’m getting a “return code 1” error for some reason, in an essentially blank score (though there are lots of include files, context tweaks, etc.). Can anyone look at the following log output and tell me roughly what I should be looking for in order to fix this? (n.b.

Re: Shortened extender problem 2.19.57

Hi Simon, This looks fine on Mac OS X, Lilypond 2.19.58. Maybe try upgrading to .58, and report back. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info

Re: Shortened extender problem 2.19.57

Simon, you wrote Wednesday, April 05, 2017 10:58 PM > only now did I encounter this problem – I’m on Windows 7, x64. What am I > doing wrong/am I doing anything wrong/has this to do with recent Lyric > extender changes? > > \version "2.19.57" [snip] This looks correct in

Shortened extender problem 2.19.57

Hello everybody, only now did I encounter this problem – I’m on Windows 7, x64. What am I doing wrong/am I doing anything wrong/has this to do with recent Lyric extender changes? \version "2.19.57" quintus = \relative { r4 f'' f e } tenor = \relative { b'4.( a16 g f8 g a4)

Re: Rootless slash chords, 2017 edition

Thomas, thanks a lot for the solution! If you have a SF account, could I ask you please to add a link to this discussion to the SF issue? The only solution mentioned there doesn't work with modern Lilypond. Thx, Dmitry В Thu, 30/03/2017 в 00:06 +0200, Thomas Morley пишет: > 2017-03-28 19:49

Re: Rootless slash chords, 2017 edition

Kieren, thanks for the info, I'm eager to volunteer as a tester (from the end-user perspective). I'm a bit new to all that GSoC process, so I guess I should wait for a mentor and a student to be assigned, and try getting in touch with them, right? Thx, Dmitry > Hello Dmitry, > > > There's been

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

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

Ghostscipt failure 256

Dear people, With one file that i wanted to reedit today gives now a failure, it worked fine in june, 2016. Will not post it here because it is 1274 lines long. The log says this: Layout output to `120-Arpeggios.ps'... Converting to `./120-Arpeggios.pdf'... warning: `(gs -q -dSAFER

Re: Incipit default notehead.style

Hi Simon, sorry, you are right - unfortunately its working fine in the minimal example: \version "2.19.58" \score { \new Staff << \new Voice = Tenor { \set Staff.instrumentName = #"Tenor" \incipit { \override NoteHead.style = #'default \clef "soprano" c'2 } \clef

Re: Incipit default notehead.style

Am 05.04.2017 um 20:06 schrieb Johannes Roeßler: > Hi, > > I'd like to have an incipit with modern notation styles in 2.19 - but > what ever I do - I get neomensural noteheads./ > /I tried to place \override NoteHead.style = #'default or \override > Staff.NoteHead.style = #'default several

Re: Incipit default notehead.style

Am 05.04.2017 um 20:06 schrieb Johannes Roeßler: I'd like to have an incipit with modern notation styles in 2.19 - but what ever I do - I get neomensural noteheads./ /I tried to place \override NoteHead.style = #'default or \override Staff.NoteHead.style = #'default several places, without

Incipit default notehead.style

Hi, I'd like to have an incipit with modern notation styles in 2.19 - but what ever I do - I get neomensural noteheads./ /I tried to place \override NoteHead.style = #'default or \override Staff.NoteHead.style = #'default several places, without success. Any hints? Cheers, Joei //

Re: vertical distance variables

On Wed, Apr 5, 2017 at 8:09 AM, Urs Liska [via Lilypond] < ml-node+s1069038n201962...@n5.nabble.com> wrote: > > > The attached diagram might be helpful for understanding vertical spacing > variables. > > > Yes, very helpful. > But I don't see how I can then create a fixed distance for the first >

Re: vertical distance variables

Am 05.04.2017 um 16:04 schrieb tisimst: > Hi, Urs! > > On Wed, Apr 5, 2017 at 7:02 AM, Urs Liska [via Lilypond] <[hidden > email] > wrote: > > Hi, > > naively I expected this to have the title (one line) start 16 mm into > the page and the first system at 26mm. > > top-margin =

Re: vertical distance variables

Hi, Urs! On Wed, Apr 5, 2017 at 7:02 AM, Urs Liska [via Lilypond] < ml-node+s1069038n201957...@n5.nabble.com> wrote: > Hi, > > naively I expected this to have the title (one line) start 16 mm into > the page and the first system at 26mm. > > top-margin = 16\mm > top-markup-spacing = >

Re: vertical distance variables

Am 05.04.2017 um 15:07 schrieb Andrew Bernard: > Hi Urs, > > Is the spacing alist really capable of taking millimetre values and > interpreting them as such? I am surprised. It seems. But originally I had calculated the value from the calculated staff distance and got to the same result. Urs >

Re: vertical distance variables

Hi Urs, Is the spacing alist really capable of taking millimetre values and interpreting them as such? I am surprised. Andrew On 5 April 2017 at 23:01, Urs Liska wrote: > > naively I expected this to have the title (one line) start 16 mm into > the page and the first

vertical distance variables

Hi, naively I expected this to have the title (one line) start 16 mm into the page and the first system at 26mm. top-margin = 16\mm top-markup-spacing = #'((basic-distance . 0) (stretchability . 0)) top-system-spacing = #`((basic-distance . ,#{ 10 \mm #}) (stretchability .

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

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: Specify output directory *in* the file

Am 05.04.2017 um 11:32 schrieb Malte Meyn: > > Am 05.04.2017 um 11:19 schrieb Urs Liska: >> Hi all, >> >> is it possible to specify an output directory from within the LilyPond >> file without going through the hoops of ly:book-process? >> >> TIA >> Urs > How about \bookOutputName? This works

Re: Specify output directory *in* the file

Am 05.04.2017 um 11:19 schrieb Urs Liska: > Hi all, > > is it possible to specify an output directory from within the LilyPond > file without going through the hoops of ly:book-process? > > TIA > Urs How about \bookOutputName? This works with absolute paths like \bookOutputName

Re: Set a property in before-line-breaking

Hi Andrew, Am 05.04.2017 um 04:17 schrieb Andrew Bernard: > Hi Urs, > > I am fascinated by your recent deep questions about lilypond internals > programming. I'm fascinated as well, although I must say my excitement is pretty ambiguous ;-) > Can you tell us about the project you are working

Specify output directory *in* the file

Hi all, is it possible to specify an output directory from within the LilyPond file without going through the hoops of ly:book-process? TIA Urs -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-user mailing list

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

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?

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?

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?

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?

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?

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?

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?

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?

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