Re: New LilyPond website

[Johan Vromans]

On Sun, 11 Dec 2016 23:54:16 +0100, Michael Gerdau  wrote:

> I'm fine with using javascript on any site as long as I who generally
> and deliberately disables javascript can still use that site.

I'd like to add: There is good value in javascript for web sites. However,
an astonishing number of websites nowadays blindly include a vast
collection of 3rd party javascript. Thats' where the risks are, since you
cannot control what the 3rd parties will do (now, and in some future) with
their code and your data. And yes, that includes WP, Google Analytics,
JQuery, and so on.

So some local javascript can be pretty safe. 3rd party scripts? No thanks.

-- Johan


pgpKN53L5IEuk.pgp
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Table of Contents - order by page

[Freddy Ouellette]

Yes... of course that works fine. But it's a workaround, not a fix. The way my 
files are laid out, I have several files with individual pieces, and each of 
their facsimile pages. I would like to keep these facsimile pages in the same 
ly file as the music, but in the final book put all the facsimile pages AFTER 
the music. Each of the variables are bookparts, which means I have to put the 
tocItem in the variable, not in the final book. 

Piece_1.ly
  Piece_1_Music *tocItem "Piece 1"
  Piece_1_Facsimile *tocItem "Facsimiles"

Piece_2.ly
  Piece_2_Music *tocItem "Piece 2"
  Piece_2_Facsimile

Final Book order:

Piece_1_Music
Piece_2_Music
Piece_1_Facsimile
Piece_2_Facsimile

The above configuration would result in the issue described, with the facsimile 
tocitem appearing BEFORE the piece 2 tocitem in the table of contents even 
though it comes after it in the book.

In general it annoys me in lilypond that variables have to be only ONE thing, 
and first of all you can't combine, say a variable and a tocitem into another 
single variable, and second of all even when you do


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

Re: Table of Contents - order by page

[Andrew Bernard]

Hi Freddy,



On 12 December 2016 at 12:20, Freddy Ouellette 
wrote:

> The table of contents seems to list its items by the order in which they
> were evaluated by the parser, and not by where they actually appear in the
> book... Is there a way to avoid this?
>
> for example, even though partB comes AFTER partA in the book, and the
> PAGES in the table of contents are right, partB comes listed first in the
> TOC which is very annoying, simply because it was evaluated first.
>
>
How about if you put part A before part B? That works fine.

partA =
\bookpart {
  \tocItem "PART A"
  \new Staff {
c4 d e f
  }
}

partB =
\bookpart {
  \tocItem "PART B"
  \new Staff {
c4 d e f
  }
}

​


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

Table of Contents - order by page

[Freddy Ouellette]

The table of contents seems to list its items by the order in which they
were evaluated by the parser, and not by where they actually appear in the
book... Is there a way to avoid this?

for example, even though partB comes AFTER partA in the book, and the PAGES
in the table of contents are right, partB comes listed first in the TOC
which is very annoying, simply because it was evaluated first.

\version "2.18.2"

partB =
\bookpart {
  \tocItem "PART B"
  \new Staff {
c4 d e f
  }
}

partA =
\bookpart {
  \tocItem "PART A"
  \new Staff {
c4 d e f
  }
}

\book {
  \bookpart {
\markuplist \table-of-contents
\paper {
  tocTitleMarkup = \markup \center-column {
\italic "Contents"
\vspace #0.3
  }
  tocItemMarkup = \markup {
\fill-with-pattern
#1 #RIGHT "  .  "
\fromproperty #'toc:text
\fromproperty #'toc:page
  }
}
  }
  \bookpart { \partA }
  \bookpart { \partB }
}

thanks for any help.

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

RE: How to typeset a voice cross over mark on a piano staff ?

[Mark Stephen Mrotek]

Harald,

 

In Lilypond it is called “staff change lines.” In 2.18 it is at

http://lilypond.org/doc/v2.18/Documentation/notation/common-notation-for-keyboards#staff_002dchange-lines

 

MRK

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of Harald Christiansen
Sent: Sunday, December 11, 2016 3:41 PM
To: lilypond-user 
Subject: How to typeset a voice cross over mark on a piano staff ?

 

Hi,

 

I would like to mark a voice cross over on a piano staff with a dotted/dashed 
line.

(I couldn't find anything related to lilypond)

 

Essentially I want to connect a note in the "upper" stave (played by the right 
hand) with the "next" note on the lower stave (played by the left hand) to mark 
that it's a "continuation" (same melodic line) (sorry, but I don't know how to 
describe this better)

 

BTW this is not a glissando, it's just a courtesy mark.

 

Thank you.

 

Cheers,

Harald

-- 

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

Re: How to typeset a voice cross over mark on a piano staff ?

[Simon Albrecht]

On 12.12.2016 00:41, Harald Christiansen wrote:

Hi,

I would like to mark a voice cross over on a piano staff with a 
dotted/dashed line.


You need to have the voice cross staves using the \change command, and 
use \showStaffSwitch for the lines (both are explained in Notation 
Reference, 2.2.1.D).


HTH, Simon

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

Re: New LilyPond website

[Shane Brandes]

I think John has accomplished a lot of useful things. Chiefly exposing
to the rest of the community the nontrivial nature of maintenance for
the LilyPond website. He also has demonstrated that we appreciate
useful progress or improvement but also are clearly interested in why
that should constitute such.

On Sun, Dec 11, 2016 at 4:35 PM, John Roper  wrote:
>>> Why this unwarranted hostility?
> ?
>
>>And my view is, if
>> you refuse to use JavaScript, or try to run a defunct browser, that's your
>> problem.
>
> That is my view too. I understand about your blind users, but you can
> view a javascript-enabled website with a text website. It is possible.
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Alexander
IIUC (I didn't compile it in), your patch inhibits extenders on a single note, correct? 


Yes.

Is that really what we want unconditionally, 


Currently we get a short extender ... that is imho of no use and should be 
killed.


or are there reasonable use cases where one might want to have an extender 
printed after a single note?


No really ... but ... yes. In a situation like << { c1 } { a8 (g f g a2 ) } >>  
it could be usefull.
Would need an override ...


Second: Did you test with broken extenders? Like
{ c1 d \break e f } \addlyrics { c de __ _ f }? Asking because there should be an extender for 
"de" across the break despite the fact that both the d and e are "alone" on 
that line. Such an extender may never be killed.

The 2nd part of the extender is killed by the "if (heads.size () < 2)". That could be changed to "if 
(left_edge->internal_has_interface (ly_symbol2scm ("lyric-syllable-interface")) && heads.size () < 
2)".

It's late now, good night.

Knut



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

How to typeset a voice cross over mark on a piano staff ?

[Harald Christiansen]

Hi,

I would like to mark a voice cross over on a piano staff with a
dotted/dashed line.
(I couldn't find anything related to lilypond)

Essentially I want to connect a note in the "upper" stave (played by the
right hand) with the "next" note on the lower stave (played by the left
hand) to mark that it's a "continuation" (same melodic line) (sorry, but I
don't know how to describe this better)

BTW this is not a glissando, it's just a courtesy mark.

Thank you.

Cheers,
Harald
-- 

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi,

> That’s a design question. There are styles which use extenders on single
> notes (e.g. for very wide c.f. notes),

I also think I have seen it for long notes, for instance in a final measure.

I could also think of a situation where a voice splits up into two in
the final measure (bass voices sometimes do). Then it would be handy to
write the lyrics according to the main (and then upper) voice. But the
new temporary voice could have a melisma calling for an extender line.

{
  <<
\new Staff <<
  \new Voice = "one" { a'4 a' a' a' \voiceOne a'1 \bar "|." }
  \new Voice  { s1 \voiceTwo  a4 b c' d' }
>>
\new Lyrics \lyricsto "one" { A B C D
  \override Lyrics.LyricExtender.minimum-length = #8.5
  E __ }
  >>
}

> so I think it should ideally be controlled by a context property.

+1

There could be two options:
a) Extender length is always at least minimum-length
b) Extenders shorter than a threshold length are omitted.

It seems like currently single note (non-melisma) extenders choose
option (a) which looks bad in most cases: Either they need to be
lengthened (like the override above) or they should be suppressed.

For an automatic extender creation, there could be two options:
a) only explicit extenders are printed (current behaviour)
b) extenders are printed for melismata

Cheers,
Joram

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

Re: New LilyPond website

[Michael Gerdau]

> >And my view is, if
> >
> > you refuse to use JavaScript, or try to run a defunct browser, that's
> > your problem.
> 
> That is my view too. I understand about your blind users, but you can
> view a javascript-enabled website with a text website. It is possible.

Refusing to use javascript has nothing to do with using defunct browsers.
Allowing a site to use javascript does by design incur
 - higher risk of being infected by malevolent or conquered sites
 - greater loss of privacy and personal data

We don't have to agree that the above are valueable assets but assets
they are.

Forcing anybody to trade them in in my book requires very good reason.

Therefor:
I'm fine with using javascript on any site as long as I who generally
and deliberately disables javascript can still use that site.

Note I'm saying this as someone very well versed with the benefits and
the disadvantages (as in dangers) of javascript.


That having said:
I strongly second Urs's posting in this thread an hour ago.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 11.12.2016 23:33, Alexander Kobel wrote:
IIUC (I didn't compile it in), your patch inhibits extenders on a 
single note, correct? Is that really what we want unconditionally, or 
are there reasonable use cases where one might want to have an 
extender printed after a single note? 


That’s a design question. There are styles which use extenders on single 
notes (e.g. for very wide c.f. notes), so I think it should ideally be 
controlled by a context property.


Best, Simon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-11 17:24, Knut Petersen wrote:

Am 11.12.2016 um 09:05 schrieb Simon Albrecht:

Sorry to ask so bluntly, but can it really be that simple? I thought a
solution must consider the x-extent of the syllable vs. the melisma as
well…


I think this is sufficiently easy to handle with the scheme callback. 
That might not necessarily be the most performant or elegant solution, 
but it works well. I guess one reason is that extenders do not interfere 
with horizontal spacing, and the x-extents can be readily read from the 
stencil; otherwise, we'd have to spend way more effort.



As you can see from 0001-Better-lyric-extender-handling.patch it needs
one more change,
and and automatic solution (don't write "__" but get extenders where
they are needed)
requires the scheme code by Alexander.

But at the moment I think this is all that is needed, and yes, it seems
to be that simple.


IIUC (I didn't compile it in), your patch inhibits extenders on a single 
note, correct? Is that really what we want unconditionally, or are there 
reasonable use cases where one might want to have an extender printed 
after a single note?


Second: Did you test with broken extenders? Like
{ c1 d \break e f } \addlyrics { c de __ _ f }? Asking because there 
should be an extender for "de" across the break despite the fact that 
both the d and e are "alone" on that line. Such an extender may never be 
killed.


Other than that, I have no worries about your changes - but as I said, I 
didn't compile.



Cheers,
Alexander

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

Finding documentation for deprecated lilypond features

[Michael Gerdau]

Hi list,

on Mutopia Project and other such sites there are quite a few older (as
in version 2.12 or 2.13) lilypond sources.

convert-ly is my friend. However there regularly are settings and commands
that convert-ly does not deal with. Examples would be:

  % keep 32nd notes in their beams
  #(revert-auto-beam-setting '(end 1 32 4 4) 1 8)
  #(revert-auto-beam-setting '(end 1 32 4 4) 3 8)
  #(revert-auto-beam-setting '(end 1 32 4 4) 5 8)
  #(revert-auto-beam-setting '(end 1 32 4 4) 7 8)

or

\override VerticalAlignment #'max-stretch = #ly:align-interface::calc-
max-stretch

or

\override VerticalAxisGroup #'minimum-Y-extent = #'(-3 . 4)

or

  between-system-padding = #0.1

The last one had been changed be convert-ly into

  obsolete-between-system-padding = #0.1  system-system-spacing #'padding = 
#(/ obsolete-between-system-padding staff-space)  score-system-spacing 
#'padding = #(/ obsolete-between-system-padding staff-space)

(all in one line) and I'm not quite convinced that is correct (as it
creates an error when processed by 2.19.52).


I'm prepared to deal with all of these manually. For this I'd like a
pointer as to where I could search for a description what these features
were and what did replace them.

My assumption is that revert-auto-beam-setting simply is no longer needed
with current versions of lilypond while VerticalAxisGroup.minimum-Y-extent
has been replaced by something else (what?)

For the max-stretch set of properties/functions I have no clue at all.

Could someone provide a pointer as to where I could look?

Alternatively I'd be happy to raise all such questions on this list and
hope for someone knowledgeable to provide answers... ;)



Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: New LilyPond website

[Urs Liska]

Hi John,

Am 11.12.2016 um 22:36 schrieb John Roper:
> I would really love to help, but I can spend the time fighting with
> every single person on the thread.
> 

Please let me share some personal memories with you.

You may know that I am one of the longer-lasting and pretty active
people in the LilyPond community. I have not contributed much to
LilyPond's code itself but all the more to the ecosystem. But that's of
course not the point.

My very first contribution to LilyPond's Git repository was about the
website too, and it went really similar to what you just experienced. In
a way I made the same mistake that you did, faced the same reaction, and
was at the brink of throwing the towel when someone (actually it was
Graham) made the essential remarks.

I didn't want to change the appearance of the website but its content. I
found the writing and the logic in the "introduction" tour insufficient,
and it looked to me like being written by developers who didn't have the
perspective of the actual target audience of the website anymore.
What I did was more or less completely rewrite this suite of pages (OK,
I tried to keep as much of it, but essentially it was a fundamental
rewrite), created a dummy website and proposed that to the developer
community.

Reactions were very similar to what you faced, and it was quite harsh at
times, although I was sure I was right, at least with my analysis, of
course not necessarily with the "single correct solution".

Graham then made two striking remarks:
First: The website is something *everybody* can and does have a
(potentially strong) opinion about. So patches (or suggestions)
concerning the website are much more likely to trigger debate and
dissent than obscure changes deeply hidden within the code that barely
anyone reads and understands.
Second: When you're coming freshly to a team (and correct me if I'm
wrong but your "New website" thread seems to be your very first
appearance on the scene at all, while I had already been a well-known
community member back then) and propose such a fundamental change it is
even more likely to face strong opposition and/or controversial debate.

Graham's suggestion then (and I believe he said something similar now) was:
* Strip your suggestions down to small, coherent changes
* Present them one after another
* Start with presumably uncontroversial things
* Expect your authority on the subject to grow with
  each applied patch
* This also gives you the chance to grow into the system, workflow and
  requirements/restrictions

I followed that suggestion and got most of my ideas through to the
current state of the website content. The main issue with this approach
is that it will take much longer to achieve the final goal (and I assume
there *were* some of my initial ideas that got lost during the process),
but it will run with much less friction, and through the iterative
nature of the process possibly with better overall results.

I think there's still a chance to continue implementing your ideas if
you'll be able not to perceive such a step-back as a failure or a
defeat. Especially as Graham had actually just started turning some of
your code into a patch.

Best regards
Urs

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

Re: New LilyPond website

[John Roper]

I would really love to help, but I can spend the time fighting with
every single person on the thread.

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

Re: Automatic lyric colouring

[Simon Albrecht]

On 11.12.2016 17:39, Jack Mackenzie wrote:

Anyone have any ideas?


Certainly not without an example.
Best, Simon

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

Re: New LilyPond website

[John Roper]

>> Why this unwarranted hostility?
?

>And my view is, if
> you refuse to use JavaScript, or try to run a defunct browser, that's your
> problem.

That is my view too. I understand about your blind users, but you can
view a javascript-enabled website with a text website. It is possible.

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

Re: New LilyPond website

[Chris Yate]

On 11 Dec 2016 07:23, "David Kastrup"  wrote:

Werner LEMBERG  writes:

>>> I just don't think I am the best person for the job.
>>
>> Roper has finally posted something I agree with.
>
> Why this unwarranted hostility?  His final design was sound, and I
> think we should adapt some key elements.  And even if you think it was
> not, you shouldn't word it like that.

I don't think there is a mythical "best person for the job" anyway.
Someone who is really into web design will really not be into our
constraints and tool chains.

John has demonstrated remarkable willingness to adapt himself to those,
so I was rather sad to see him overcome by a combination of those and on
top of that a bit of attitude that was in excess of what explaining the
situation strictly would have warranted.

He appeared like a lot more than we could have hoped for until he
finally threw in the towel.

--
David Kastrup


I'd missed him throwing in the towel, but with the sheer amount of
negativity in these threads regarding the idea of reworking the website, I
can't blame him.

Open source is great, old tools that still work are great, changing things
for no reason should be resisted; but let's not resist all change for the
sake of it.

I for one really liked his approach. And accessibility is important, as is
automatically/computationally generated documentation. And my view is, if
you refuse to use JavaScript, or try to run a defunct browser, that's your
problem.

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

Re: Automatic lyric colouring

[Jack Mackenzie]

I've been using this for a while now and sometimes the lyrics are randomly
coloured black instead of being associated with the note colour. I've tried
to find a pattern to it but there doesn't seem to be one. Anyone have any
ideas?

On 27 November 2016 at 16:42, Jack Mackenzie  wrote:

> Wonderful! Works perfectly. Thank you very much.
>
> On 27 November 2016 at 13:26, Thomas Morley 
> wrote:
>
>> 2016-11-27 2:40 GMT+01:00 Jack Mackenzie > >:
>> > I'm trying to put together an engraver for educational purposes, with
>> > noteheads coloured according to a particular scheme, and lyrics
>> following
>> > this colouring.
>> >
>> > I've used the snippet for notehead colouring successfully
>> > (http://lsr.di.unimi.it/LSR/Snippet?id=572), using "\override
>> NoteHead.color
>> > = #color-notehead", but have no idea how to get the lyrics to follow the
>> > same colour scheme without changing each word individually. I took a
>> punt
>> > but using "override LyricText.color = #color-notehead" didn't work.
>> >
>> > Anyone got any clues to whether my idea is possible and if so how?
>> >
>> > Thanks
>>
>>
>> Hi Jack,
>>
>> how about below?
>> Not an engraver, seems to work, tho'.
>>
>> \version "2.18.2"
>>
>> %Association list of pitches to colors.
>> #(define color-mapping
>>(list
>> (cons #{ c'   #} (x11-color 'red))
>> (cons #{ cis' #} (x11-color 'green))
>> (cons #{ des' #} (x11-color 'green))
>> (cons #{ d'   #} (x11-color 'blue))
>> (cons #{ dis' #} (x11-color 'cyan))
>> (cons #{ e'   #} (x11-color 'red))
>> (cons #{ eis' #} (x11-color 'green))
>> (cons #{ fes' #} (x11-color 'red))
>> (cons #{ f'   #} (x11-color 'green))
>> (cons #{ fis' #} (x11-color 'blue))
>> (cons #{ ges' #} (x11-color 'blue))
>> (cons #{ gis' #} (x11-color 'red))
>> (cons #{ aes' #} (x11-color 'red))
>> (cons #{ a'   #} (x11-color 'green))
>> (cons #{ ais' #} (x11-color 'blue))
>> (cons #{ bes' #} (x11-color 'blue))
>> (cons #{ bis' #} (x11-color 'red
>>
>> %Compare pitch and alteration (not octave).
>> #(define (pitch-equals? p1 p2)
>>(and
>> (= (ly:pitch-alteration p1) (ly:pitch-alteration p2))
>> (= (ly:pitch-notename p1) (ly:pitch-notename p2
>>
>> #(define (pitch-to-color pitch)
>>(let ((color (assoc pitch color-mapping pitch-equals?)))
>>  (if color
>>  (cdr color)
>>  '(
>>
>> #(define (color-notehead grob)
>>   (let* ((pitch-color
>>(pitch-to-color
>>  (ly:event-property (event-cause grob) 'pitch)))
>>  (pap-col-elts
>>(ly:grob-object
>>  (ly:grob-parent
>>(ly:grob-parent grob X)
>>X)
>>  'elements))
>>  (elts-list
>>(if (ly:grob-array? pap-col-elts)
>>(ly:grob-array->list pap-col-elts)
>>'()))
>>  (lyr-text
>>(filter
>>  (lambda (g)
>>(grob::has-interface g 'lyric-syllable-interface))
>>  elts-list)))
>>  (for-each
>>(lambda (lyr)
>>  (ly:grob-set-property! lyr 'color pitch-color))
>>lyr-text)
>>  (ly:grob-set-property! grob 'color pitch-color)))
>>
>> \score {
>>   <<
>> \new Voice = "voice"
>>   \relative c' {
>>   \override NoteHead.after-line-breaking = #color-notehead
>>   c8 b d dis ees f( g) aes
>> }
>> \new Lyrics \lyricsto "voice" { c b d dis ees f aes }
>>   >>
>> }
>>
>>
>> Cheers,
>>   Harm
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Am 11.12.2016 um 09:05 schrieb Simon Albrecht:

On 11.12.2016 08:37, Knut Petersen wrote:

The attached patch should solve your problem.


Thanks for having a look into it! Would you mind posting your patch as reply 
under issue 4509, to keep the information in one place?


No. Now and here's the discussion, I see no need to split it up into two 
threads at different locations.
Of course, you are free to add links to this thread ;-)


Sorry to ask so bluntly, but can it really be that simple? I thought a solution 
must consider the x-extent of the syllable vs. the melisma as well…


As you can see from 0001-Better-lyric-extender-handling.patch it needs one more 
change,
and and automatic solution (don't write "__" but get extenders where they are 
needed)
requires the scheme code by Alexander.

But at the moment I think this is all that is needed, and yes, it seems to be 
that simple.

If testing does not show problems, the code should be added to lilypond.

Todo:

- cleanup of c++ code
- proper documentation.

cu,
 Knut

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Alexander!


Here's a first shot. Please test thoroughly...

#(define (has-hyphen? event)
   (let* ((art (ly:music-property event 'articulations))
  (is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 
'HyphenEvent
  (find is-hyphen? art)))

[]


Thanks a lot for that code. Works fine together with my 
0001-Better-lyric-extender-handling.patch.

cu,
 Knut

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

Work-around for articulate+acciaccatura bug?

[Joel C. Salomon]

Hi all,

I’ve just been bit by a bug I’ve seen reference to, where

\version "2.19.52"
\include "articulate.ly"

\score {
  \articulate {
<<
  c'1
  \\
  e'1
>>
\acciaccatura c'8
c'1 |
  }
  \layout {}
}

fails the bar-check, though the other grace-note commands work fine.  Is
there a reasonable work-around for this?

I’ve got

\tagGroup #'(midi-only score-only)

and the obvious `\keepWithTag` lines in my layout and MIDI scores (and
of course `\articulate` is only ever used for the MIDI score), so is
there some way to wrap `\acciaccatura` so it becomes a plain `\grace` in
the MIDI-generating `\score` block?

(Or is the work-around, “Don’t use articulate.ly”?)

––Joel C. Salomon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Am 11.12.2016 um 10:08 schrieb David Kastrup:

Noeck  writes:


Btw, I realized that at least visually setting the min. length to 0
already makes the non-melismata hyphens disappear even without your code
to kill them:

\layout {
 \override Lyrics.LyricExtender.minimum-length = 0.0
}

{ a a( a) }
\addlyrics { A __ B __}

But one does not want extenders indistinguishable from fly specks, so 0
is a bad size to use.


I think also the minim-length should be handled differently in the c++ code.

Imho the use of minimum-length and documentation of minimum-length do not agree 
in current master,
so we have some freedom ;-)

cu,
 Knut

>From e37b3eeaca692db26a2384548c71d180f090c4a1 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Sun, 11 Dec 2016 12:30:38 +0100
Subject: [PATCH] Better lyric extender handling

---
 lily/lyric-extender.cc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lily/lyric-extender.cc b/lily/lyric-extender.cc
index 8afe2c5569..d05e71a41a 100644
--- a/lily/lyric-extender.cc
+++ b/lily/lyric-extender.cc
@@ -48,7 +48,7 @@ Lyric_extender::print (SCM smob)
 
   extract_grob_set (me, "heads", heads);
 
-  if (!heads.size ())
+  if (heads.size () < 2)
 return SCM_EOL;
 
   common = common_refpoint_of_array (heads, common, X_AXIS);
@@ -66,9 +66,8 @@ Lyric_extender::print (SCM smob)
 
   /* It seems that short extenders are even lengthened to go past the
  note head, but haven't found a pattern in it yet. --hwn 1/1/04  */
-  SCM minlen = me->get_property ("minimum-length");
-  Real right_point
-= left_point + (robust_scm2double (minlen, 0));
+  Real minlen = robust_scm2double (me->get_property ("minimum-length"), 0);
+  Real right_point = left_point + minlen;
 
   right_point = min (right_point, me->get_system ()->get_bound (RIGHT)->relative_coordinate (common, X_AXIS));
 
@@ -89,7 +88,7 @@ Lyric_extender::print (SCM smob)
   left_point += paddings[LEFT];
   Real w = right_point - left_point;
 
-  if (w < 1.5 * h)
+  if (w <= minlen)
 return SCM_EOL;
 
   Stencil mol (Lookup::round_filled_box (Box (Interval (0, w),
-- 
2.11.0

\version "2.19.53"
\language "deutsch"

\pointAndClickOff

% Requires Libertine Open Fonts from http://www.linuxlibertine.org/

\header {
  title = "Brich an, o schönes Morgenlicht"
  subtitle = "12. Choral – Weihnachtsoratorium"
  composer = "J. S. Bach"
  shortcomposer = "Bach"
  maintainer = "Joram Berger"
  maintainerWeb = "http://joramberger.de;
  style = "Baroque"
  source = "Breitkopf & Härtel, Leipzig, 1856"
  mutopiacomposer = "BachJS"
  mutopiapoet = "Johann Rist"
  mutopiaopus = "BWV 248"
  mutopiainstrument = "Choir (SATB)"
  license = "cc-by-sa"
  date = "1734"

 mutopialicense = "Creative Commons Attribution-ShareAlike 4.0"
 footer = "Mutopia-2016/04/22-1900"
 copyright = \markup {\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0) \right-column {\with-url #"http://www.MutopiaProject.org; {\abs-fontsize #9  "Mutopia " \concat {\abs-fontsize #12 \with-color #white \char ##x01C0 \abs-fontsize #9 "Project "}}}\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0 ) \center-column {\abs-fontsize #11.9 \with-color #grey \bold {\char ##x01C0 \char ##x01C0 }}\override #'(font-name . "DejaVu Sans,sans-serif") \override #'(baseline-skip . 0) \column { \abs-fontsize #8 \concat {"Typeset using " \with-url #"http://www.lilypond.org; "LilyPond " \char ##x00A9 " 2016 " "by " \maintainer " " \char ##x2014 " " \footer}\concat {\concat {\abs-fontsize #8 { \with-url #"http://creativecommons.org/licenses/by-sa/4.0/; "Creative Commons Attribution ShareAlike 4.0 International License "\char ##x2014 " free to distribute, modify, and perform" }}\abs-fontsize #13 \with-color #white \char ##x01C0 }}}
 tagline = ##f
}

#(define (lh-test-stencil arg)
 (lambda (grob)
   (if (ly:stencil? (ly:lyric-hyphen::print grob))
   (let* ((stil (ly:lyric-hyphen::print grob))
  (x-ext (ly:stencil-extent stil X))
  (dash-period (ly:grob-property grob 'dash-period))
  (arg-stil (grob-interpret-markup grob arg))
  (arg-stil-x-ext (ly:stencil-extent arg-stil X))
  (length-to-print (interval-length x-ext))
  (guess (max 0 (truncate (/ length-to-print dash-period
  (guessed-args-line-length (* guess dash-period))
  (line-length-diff (- length-to-print guessed-args-line-length))
  (line-length-diff-for-each-arg (/ line-length-diff guess))
  (first-arg-length (+ dash-period line-length-diff-for-each-arg))
  (first-arg-end-coord
  (/ (* first-arg-length
(- (interval-length x-ext)
   (interval-length arg-stil-x-ext)))
 length-to-print))
  (list-of-starts
(map
  (lambda (n) (* n first-arg-end-coord))

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-10 23:33, Alexander Kobel wrote:

On 2016-12-10 20:20, Noeck wrote:
[...]

Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?


Hm. Iterate over lyrics and add Extender events for each syllable
without a hyphen? Sounds reasonable...


Here's a first shot. Please test thoroughly...

#(define (has-hyphen? event)
   (let* ((art (ly:music-property event 'articulations))
  (is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 
'HyphenEvent

  (find is-hyphen? art)))

#(define (add-extender! event)
   (ly:music-set-property! event 'articulations
 (append (ly:music-property event 'articulations) (list (make-music 
(quote ExtenderEvent)

   event)

add-lyric-extenders =
#(define-music-function (parser location lyrics) (ly:music?)
   (music-map
(lambda (event)
  (if (and (eq? (ly:music-property event 'name) 'LyricEvent)
   (not (has-hyphen? event)))
  (add-extender! event))
  event)
lyrics))

% ... and change lyrics definitions from
%   text = \lyricmode { ... }
% to
%   text = \add-lyric-extenders \lyricmode { ... }

Attached is how it will look like in your score. Not too bad...


Cheers,
Alexander
\version "2.18.2"
\language "deutsch"

% Requires Libertine Open Fonts from http://www.linuxlibertine.org/

\header {
  title = "Brich an, o schönes Morgenlicht"
  subtitle = "12. Choral – Weihnachtsoratorium"
  composer = "J. S. Bach"
  shortcomposer = "Bach"
  maintainer = "Joram Berger"
  maintainerWeb = "http://joramberger.de;
  style = "Baroque"
  source = "Breitkopf & Härtel, Leipzig, 1856"
  mutopiacomposer = "BachJS"
  mutopiapoet = "Johann Rist"
  mutopiaopus = "BWV 248"
  mutopiainstrument = "Choir (SATB)"
  license = "cc-by-sa"
  date = "1734"

 mutopialicense = "Creative Commons Attribution-ShareAlike 4.0"
 footer = "Mutopia-2016/04/22-1900"
 copyright = \markup {\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0) \right-column {\with-url #"http://www.MutopiaProject.org; {\abs-fontsize #9  "Mutopia " \concat {\abs-fontsize #12 \with-color #white \char ##x01C0 \abs-fontsize #9 "Project "}}}\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0 ) \center-column {\abs-fontsize #11.9 \with-color #grey \bold {\char ##x01C0 \char ##x01C0 }}\override #'(font-name . "DejaVu Sans,sans-serif") \override #'(baseline-skip . 0) \column { \abs-fontsize #8 \concat {"Typeset using " \with-url #"http://www.lilypond.org; "LilyPond " \char ##x00A9 " 2016 " "by " \maintainer " " \char ##x2014 " " \footer}\concat {\concat {\abs-fontsize #8 { \with-url #"http://creativecommons.org/licenses/by-sa/4.0/; "Creative Commons Attribution ShareAlike 4.0 International License "\char ##x2014 " free to distribute, modify, and perform" }}\abs-fontsize #13 \with-color #white \char ##x01C0 }}}
 tagline = ##f
}

#(set-global-staff-size 18.1)


\paper {
  ragged-bottom = ##f
  ragged-last-bottom = ##f
  last-bottom-spacing #'basic-distance = 15
  myStaffSize = #18.5
  fonts = #(make-pango-font-tree
"Linux Libertine O"
"Linux Biolinum O"
"Ubuntu Mono"
(/ myStaffSize 20))
}

\layout {
  \override Staff.ClefModifier.font-name = #"Century Schoolbook L bold italic"
  \override Staff.ClefModifier.extra-offset = #'(-0.3 . 0.07)
  \override Score.BarNumber.font-name = #"Century Schoolbook L"
}

global = {
  \key g \major
  \time 4/4
  \partial 4
  \autoBeamOff
  \accidentalStyle modern-voice
}

fe = \fermata

soprano = \relative c'' {
  \global
  \repeat volta 2 {
g4 | g a h8[ cis] d4 | d cis d\fe
h4 | c h a h | a2 g4
  } \break
  a4  | \once \override Score.BarNumber.break-visibility = #all-visible
  a h c c | h8[( a]) h4 a\fe
  h4 | h h c8[( d]) e4 | e dis e\fe
  fis4 | g h, c h | a2 a4\fe
  d4 | e d c h8[ c] | a2 g='4\fe
  \bar "|."
}

alto = \relative c' {
  \global
  \repeat volta 2 {
d4 | e fis d8[ e] fis4 | e8[ fis] g4 fis\fe
fis4 | e d8[ e] fis4 g | g( fis) d
  }
  fis8[ g] | a4. gis8 a[( gis]) a4 | a gis e\fe
  e8[ dis] | e4 e e8[( fis]) g[( fis]) | fis8[( g]) a4 g\fe
  a4 | g8[ a] h4 h8[( a]) a[( g]) | g2 fis4\fe
  g8[ fis] | e4 fis g8[( a]) d,4 | e( d) d='\fe
}

tenor = \relative c' {
  \global
  \repeat volta 2 {
h4 | h8[ c] ~ c d h[ a] a4 | a a a\fe
h8[a] | g[a] h[ c] d4 d | d4.( c8) h4
  }
  d8[ e] | fis[ e] d4 e fis | h, e8[ d] c4\fe
  g8[ a] | h[ c] d[ e] c4 cis | h h h\fe
  d4 | d g g,8[( a]) h4 | e8[( d e cis]) d4\fe
  d4 | d8[( c]) c[( h]) h[( a]) g4 | g8[( fis16 e] fis4) h=\fe
}

bass = \relative c' {
  \global
  \repeat volta 2 {
g8[ fis] | e4 d g fis8[ g] | a4 a, d\fe
dis4 | e8[ fis] g[ c,] c'[ h] a[ g] | d'4( d,) g
  }
  d4 | d'8[ c] h4 a dis, | e e a,\fe
  e'8[ fis] | g4 gis a ais | h h, e\fe
  d'8[ c] | h[ a] g[ fis] e[ fis] g[ e] | cis[ h cis a] d4\fe
  h4 | c d e8[ fis] g4 | \shape #'((0 . -0.2) (0 . -0.8) (0 . -0.8) (0 . 0)) 

Re: Photoscore

[karl]

David Kastrup:
> And indeed the externally attached drive (via USB) was named /dev/sda
> while the internal drive the Linux rescue environment booted from was
> /dev/sdb.  So this time round the root disk system not being able to
> mount stuff on /dev/sda* had more than one reason.
>
> But I was surprised that a USB-connected drive (even though connected at
> bootup time) was listed before the internal mSATA one.  Without checking
> via fdisk prior to starting the copy I would indeed have assumed the
> reverse.

The kernel seem to prefer random assignment of scsi devices, at least
they don't want a scheme like we was used to in the /dev/hda days,
where there was a direct connection between the device name (or rather
maj/min. numbers) and the bus/id.

I call it "automatically wrong".

Fix it by using
 older kernel
 not loading usb-storage at boot time
 usign some udev-scheme with uuid or something

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-11 11:04, Alexander Kobel wrote:

Hi Joram.

On 2016-12-11 09:28, Noeck wrote:

Hi Alexander,

Am 11.12.2016 um 01:17 schrieb Alexander Kobel:

Ah, no, here's the problem, as can be readily seen in the "Brich an, o
schönes Morgenlicht", first full measure


I don't think so. Because for notes like the second one in the soprano
voice ("an,"), the added extender line is very short and therefore
killed. It does not even require a sufficient minimum-length. [...]


Well, with my default settings, it isn't. For me, this measure would
look like the attached picture.


Argh, forget my previous mail. I added the layout block to the MIDI 
score, stupid me...



Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi Joram.

On 2016-12-11 09:28, Noeck wrote:

Hi Alexander,

Am 11.12.2016 um 01:17 schrieb Alexander Kobel:

Ah, no, here's the problem, as can be readily seen in the "Brich an, o
schönes Morgenlicht", first full measure


I don't think so. Because for notes like the second one in the soprano
voice ("an,"), the added extender line is very short and therefore
killed. It does not even require a sufficient minimum-length. [...]


Well, with my default settings, it isn't. For me, this measure would 
look like the attached picture.
In general, I dislike setting the minimum-length too short; my default 
is 1.5 staff-line distances. Just the other day, I was affirmed by a 
measure of "In the bleak mid-winter" by Holst (attached excerpt from 
Oxford's engraving): The question arose (among non-native speakers) 
whether "Thronged" is supposed to be sung as one syllable or as "Throng 
-- ed". Here, the extender made clear that it should is meant as one 
syllable. In a slightly tighter setting, without the fifth verse, this 
extender might have been /really/ short, but still important.



It might not be robust enough, there may be problematic situations but I
could not find such a problem.


That's the main issue. Imagine a passage of semi-quavers in the other 
voices, and suddenly the extenders get large. Or think of BWV 140 
"Wachet auf" with the prolonged cantus firmus in soprano over the 
fast-moving rest of the choir...


Anyway, I'll try to have a look and see whether I can find an easy way 
to detect melismata...



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

Re: New LilyPond website

[Jan-Peter Voigt]

Am 11.12.2016 um 08:23 schrieb David Kastrup:

Werner LEMBERG  writes:


I just don't think I am the best person for the job.

Roper has finally posted something I agree with.

Why this unwarranted hostility?  His final design was sound, and I
think we should adapt some key elements.  And even if you think it was
not, you shouldn't word it like that.

I don't think there is a mythical "best person for the job" anyway.
Someone who is really into web design will really not be into our
constraints and tool chains.

John has demonstrated remarkable willingness to adapt himself to those,
so I was rather sad to see him overcome by a combination of those and on
top of that a bit of attitude that was in excess of what explaining the
situation strictly would have warranted.

He appeared like a lot more than we could have hoped for until he
finally threw in the towel.


+1

Jan-Peter

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

Re: Photoscore

[David Kastrup]

David Wright  writes:

> On Tue 29 Nov 2016 at 09:37:21 (+0100), David Kastrup wrote:
>> David Wright  writes:
>> 
>> > On Mon 28 Nov 2016 at 21:26:17 (+), Karlin High wrote:
>> >> On 11/28/2016 2:12 PM, David Wright wrote:
>> >> > So it should be worth booting from a live linux CD to mount the
>> >> > partitions to check their contents, and to reinstall Grub
>> >> > (or whatever you use to boot) into the MBR.
>> >> 
>> >> The thing to do IMMEDIATELY is make a "drive image backup."
>> >
>> > That would certainly be the action to take if the drive was giving
>> > disk errors.
>> 
>> It's also the action to take if you are dealing with damage to the data
>> structures.
>
> That doesn't necessarily buy you any advantage in the case you
> outlined. There are risks in making bit for bit copies of a drive.
> For starters, you're _writing_ to a device, whereas attempting to
> mount the partitions readonly involves _no_ writing to any device.
>
> Only on the 18th, I read a post where a user was trying to make an
> image of a drive, and was relying on the order they plugged in the
> two drives to get the kernel to assign the "correct" /dev/sdX values
> to the two drives so that they could then follow some remotely
> posted instructions for making the copy. Talk about tail wagging dog!

Just as a P.S.: am in the mirroring stage now (my father acquired a new
somewhat larger SSD disk with some mSATA interface like his computer
uses internally (the kind of crap that exists these days...) and a
suitable USB adapter).

And indeed the externally attached drive (via USB) was named /dev/sda
while the internal drive the Linux rescue environment booted from was
/dev/sdb.  So this time round the root disk system not being able to
mount stuff on /dev/sda* had more than one reason.

But I was surprised that a USB-connected drive (even though connected at
bootup time) was listed before the internal mSATA one.  Without checking
via fdisk prior to starting the copy I would indeed have assumed the
reverse.

-- 
David Kastrup

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

Re: exchange LyricHyphen with a "proper" hyphen

[David Kastrup]

Noeck  writes:

> Btw, I realized that at least visually setting the min. length to 0
> already makes the non-melismata hyphens disappear even without your code
> to kill them:
>
> \layout {
> \override Lyrics.LyricExtender.minimum-length = 0.0
> }
>
> { a a( a) }
> \addlyrics { A __ B __}

But one does not want extenders indistinguishable from fly specks, so 0
is a bad size to use.

-- 
David Kastrup

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

Re: New LilyPond website

[Urs Liska]

Am 11. Dezember 2016 08:07:04 MEZ, schrieb Werner LEMBERG :
>
>>> I just don't think I am the best person for the job.
>>
>> Roper has finally posted something I agree with.
>
>Why this unwarranted hostility?  His final design was sound, and I
>think we should adapt some key elements.  And even if you think it was
>not, you shouldn't word it like that.

+1

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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Btw, I realized that at least visually setting the min. length to 0
already makes the non-melismata hyphens disappear even without your code
to kill them:

\layout {
\override Lyrics.LyricExtender.minimum-length = 0.0
}

{ a a( a) }
\addlyrics { A __ B __}

Cheers,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi Alexander,

Am 11.12.2016 um 01:17 schrieb Alexander Kobel:
> Ah, no, here's the problem, as can be readily seen in the "Brich an, o
> schönes Morgenlicht", first full measure

I don't think so. Because for notes like the second one in the soprano
voice ("an,"), the added extender line is very short and therefore
killed. It does not even require a sufficient minimum-length. You can
try this with your code:

{ a a }
\addlyrics { A __ }

It might not be robust enough, there may be problematic situations but I
could not find such a problem.

Cheers,
Joram


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

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 11.12.2016 08:37, Knut Petersen wrote:

The attached patch should solve your problem.


Thanks for having a look into it! Would you mind posting your patch as 
reply under issue 4509, to keep the information in one place?
Sorry to ask so bluntly, but can it really be that simple? I thought a 
solution must consider the x-extent of the syllable vs. the melisma as well…


Best, Simon

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