date:20170405



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 places,
> without success.
> 
> Any hints?
> 
> Cheers, Joei

The incipit isn’t printed on a Staff but a MensuralStaff context so you
should try

\override MensuralStaff.NoteHead.style = …

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Incipit default notehead.style

2017-04-05 Thread Simon Albrecht


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 success.


It’s almost always helpful to have a tiny example to start working from, 
so please supply one. :-)


Best, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Incipit default notehead.style

2017-04-05 Thread 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 places,

without success.

Any hints?

Cheers, Joei
//
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical distance variables

2017-04-05 Thread tisimst

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
> system - as I don't know how high the title markup is.
>

The only way I'm aware of (for this very first system position) is with an
explicit vertical position statement, found here:

http://lilypond.org/doc/v2.19/Documentation/notation/explicit-staff-and-system-positioning

The down-side is that it makes the system behave more like when you use
'extra-offset, so it affects that system ONLY and none others.

The alternative would be to re-write the title markup, prefaced using
something like \with-dimensions to artificially fix its vertical size so
the first system *thinks* it's supposed to start at a specific spot.

HTH,
Abraham

--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/vertical-distance-variables-tp201957p201963.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 = 16\mm
>   top-markup-spacing =
>   #'((basic-distance . 0)
>  (stretchability . 0))
>   top-system-spacing =
>   #`((basic-distance . ,#{ 10 \mm #})
>  (stretchability . 0))
>
> But while the title thing seems reasonably accurate the top of the
> first
> system sits at 28.3 mm.
>
> Am I missing something? 
>
>
> Because you know there is the title markup first, try setting
> markup-system-spacing instead of top-system-spacing.
> top-system-spacing is only effective if there isn't a markup between
> the first system and the top-margin. Likewise, top-markup-spacing is
> only effective when there isn't a system between the first markup and
> the top-margin (such as when you end one piece and have a score title
> between it and the next one).

Ah, thanks, that makes these sentences from the NR clearer.

>
> 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
system - as I don't know how high the title markup is.

?

Urs
>
> HTH,
> Abraham 
>
> *vertical-spacing-paper-variables.pdf* (88K) Download Attachment
> 
>
> 
> View this message in context: Re: vertical distance variables
> 
> Sent from the User mailing list archive
>  at Nabble.com.
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical distance variables

2017-04-05 Thread tisimst

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 =
>   #'((basic-distance . 0)
>  (stretchability . 0))
>   top-system-spacing =
>   #`((basic-distance . ,#{ 10 \mm #})
>  (stretchability . 0))
>
> But while the title thing seems reasonably accurate the top of the first
> system sits at 28.3 mm.
>
> Am I missing something?
>

Because you know there is the title markup first, try setting
markup-system-spacing instead of top-system-spacing. top-system-spacing is
only effective if there isn't a markup between the first system and the
top-margin. Likewise, top-markup-spacing is only effective when there isn't
a system between the first markup and the top-margin (such as when you end
one piece and have a score title between it and the next one).

The attached diagram might be helpful for understanding vertical spacing
variables.

HTH,
Abraham

vertical-spacing-paper-variables.pdf (88K) 

--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/vertical-distance-variables-tp201957p201961.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

>
> 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-margin = 16\mm
>   top-markup-spacing =
>   #'((basic-distance . 0)
>  (stretchability . 0))
>   top-system-spacing =
>   #`((basic-distance . ,#{ 10 \mm #})
>  (stretchability . 0))
>
> But while the title thing seems reasonably accurate the top of the
> first
> system sits at 28.3 mm.
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical distance variables

2017-04-05 Thread Andrew Bernard

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-margin = 16\mm
>   top-markup-spacing =
>   #'((basic-distance . 0)
>  (stretchability . 0))
>   top-system-spacing =
>   #`((basic-distance . ,#{ 10 \mm #})
>  (stretchability . 0))
>
> But while the title thing seems reasonably accurate the top of the first
> system sits at 28.3 mm.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 . 0))

But while the title thing seems reasonably accurate the top of the first
system sits at 28.3 mm.

Am I missing something?
Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 about this very topic. The
2.19 development line is very stable and highly to be recommended. not only
is crashing behaviour very rare, but the scads of new features make it
worthwhile if for nothing else.

I engrave scores by a colleague who is a major exponent of the New
Complexity School, and this work pushes lilypond to various limits in all
sorts of ways, and yet it holds up magnificently and produces very fine
output indeed, quite astonishingly beautiful in fact. I am currently
engraving a major piano sonata which is over 200 pages in length and well
over a hundred thousand lines of lilypond source code, and never a hiccup.
In the last few years I have only encountered in my work two small crashing
bugs and these were very rapidly addressed by the fantastic development
team.

As to version numbers, you will know that open source development projects
are generally very humble with revision numbers, and are loth to bump them
up without very good reason. 2.20 will eventually arrive, but there is no
need to deprive yourself of the advances in the 2.19 series. It is a
tribute to the maturity and skill of the developers in the lilypond
community that the development releases are so stable and well produced. I
cannot praise them highly enough.

In explicit answer to your question, there is no major problem lurking in
2.19 that you need to worry about.

On a practical note, I have the subjective impression the members of the
list are more willing to assist in solving user issues and queries with the
2.19 series than 2.18 since it is more current - but I am prepared to be
wrong about that!

Andrew

On 5 April 2017 at 16:17, Shevek  wrote:

>
> So my questions:
>
> 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?
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 with absolute paths like
>
>   \bookOutputName "/home/malte/foo" (output to /home/malte/foo.pdf)
>
> and with relative paths too. You don’t need an explicit \book {} block.

Oops, so easy?
Sorry for the noise and thank you

Urs

>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 "/home/malte/foo" (output to /home/malte/foo.pdf)

and with relative paths too. You don’t need an explicit \book {} block.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 on? It seems very grand.

Unfortunately I can't tell much more before the project is completed
(and then only partially as well). It's not *that* grand originally,
"only" a custom design for slurs and ties but one that turned into a
full-fledged formatting engine ...

But I really hope that I'll be able to write down much of my
experiences, basically writing the documentation that would have
prevented me from having to ask so many questions ...

Urs

>
> Andrew
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 at this conversion and the "old" syntax is not
likely to be gone for several stable versions (sort of like: deprecated
in 2.20, warning in 2.22, gone in 2.24).

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 that convert-ly should have most of the bases covered:
moving from 2.18 to current 2.19 should be mostly painless.

> \partial at volta repeats and time signature changes.

Well, yes.  But mostly you had to fiddle with manual workarounds
previously, and most of those workarounds are no longer necessary but
will not cause damage either.

> These are only some examples. For details and other changes see
> http://lilypond.org/doc/v2.19/Documentation/changes/

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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
think of any specific changes to spacing of particular types of objects, or
page breaking, or something like that, it would be really helpful for me to
know what to look out for when I compare versions.

Thanks so much!



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Converting-a-large-project-from-2-18-to-2-19-what-to-expect-tp201938p201944.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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: 
http://lilypond.1069038.n5.nabble.com/Converting-a-large-project-from-2-18-to-2-19-what-to-expect-tp201938p201943.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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?) …)

becomes

#(define-music-function (arg1 arg2) (type1? type2?) …)

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 a
workaround for this issue in my score). The cross staff issue would be new
from 2.18, however. Is that correct?

I've certainly read the change documentation; I was hoping for some deeper
feedback on likely trouble spots with compatibility or changed graphical
behavior. For instance, the uniform-stretching spacing issue is discussed on
Lilypondblog as being fixed in 2.19, but that isn't mentioned in the change
documentation as far as I recall. If there are other significant changes in
graphical output, it would be helpful for me to know specifically what to
look for to see if it has messed anything up. It's pretty much impossible to
efficiently proofread a 100-page orchestral score for subtle graphical
issues without knowing in advance what to look for in terms of likely
trouble spots.

In terms of Scheme changes, how does this affect compatibility with snippets
written on 2.16 or 2.18?

Thanks again for your help.

--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Converting-a-large-project-from-2-18-to-2-19-what-to-expect-tp201938p201941.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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 surprised there hasn't been 2.20 already.
>> Is there some major problem I should be worried about in 2.19?
> See
> https://sourceforge.net/p/testlilyissues/issues/search/?q=%28_type%3ACritical+OR+labels%3ARegression%29+AND+%28status%3ANew+OR+status%3AAccepted+OR+status%3AStarted%29
> for a list of critical bugs/regressions. It would be nice to have a 2.20
> soon but these have to be solved before a release.
>
> I would recommend to simply try 2.19 (install 2.19, make a copy of your
> project, run convert-ly and lilypond on this copy), I have never had
> problems with 2.19 that weren’t there in 2.18. (Of course that doesn’t
> mean that there cannot be any problems but it seems like problems are
> very rare for many use cases.)

I'd say: the more complex Scheme programming you use under the hood
(i.e. in some library files), the more you risk running into problems.

If you have any chance I would recommend to do this with version
control. You could even start tracking your project right now, but do
the following:

* create a branch for the conversion and check this out
* run convert-ly on all your files
  note if there are any "I'm not smart enough" messages
* commit these changes
* test compiling the project and see if it seems feasible to continue
* fix any problems one by one

If that works out you have two working branches and can decide whether
to continue having the two options or simply merge the conversion branch
back in and have your whole project converted to 2.19.

Good luck!
Urs

>
>> 2) What should I expect to break under 2.19? Music output changes to look
>> out for as I proofread? Things that might make snippets or Scheme behave
>> differently or not be backwards compatible?
> Output changes: MIDI articulation, MultiMeasureRest spacing, whiteout style.
>
> Input changes: the omission of “parser” and “location” arguments in
> music functions, \partial at volta repeats and time signature changes.
>
> These are only some examples. For details and other changes see
> http://lilypond.org/doc/v2.19/Documentation/changes/
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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
https://sourceforge.net/p/testlilyissues/issues/search/?q=%28_type%3ACritical+OR+labels%3ARegression%29+AND+%28status%3ANew+OR+status%3AAccepted+OR+status%3AStarted%29
for a list of critical bugs/regressions. It would be nice to have a 2.20
soon but these have to be solved before a release.

I would recommend to simply try 2.19 (install 2.19, make a copy of your
project, run convert-ly and lilypond on this copy), I have never had
problems with 2.19 that weren’t there in 2.18. (Of course that doesn’t
mean that there cannot be any problems but it seems like problems are
very rare for many use cases.)

> 2) What should I expect to break under 2.19? Music output changes to look
> out for as I proofread? Things that might make snippets or Scheme behave
> differently or not be backwards compatible?

Output changes: MIDI articulation, MultiMeasureRest spacing, whiteout style.

Input changes: the omission of “parser” and “location” arguments in
music functions, \partial at volta repeats and time signature changes.

These are only some examples. For details and other changes see
http://lilypond.org/doc/v2.19/Documentation/changes/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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