Kieren MacMillan writes:
> 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
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
part
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 pa
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 just
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. Inc
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
_
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 2.19.52
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)
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 GMT+
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
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
wrote:
>
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 -dDEVICEWIDT
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 "tr
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 place
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 succ
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
//
__
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
> s
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 =
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 =
> #'((b
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
>
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 system at 26mm.
>
> top
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 . 0))
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 abou
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 wit
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 "/home/malte
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 on?
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
l
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 at this conversion and the "
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 that convert-ly should h
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
t
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:
http://lilypond.1069038.n5.nabble.com/Conve
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?) …)
bec
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 a
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 surpr
34 matches
Mail list logo
