Re: 13th chord?

[David Kastrup]

msk...@ansuz.sooke.bc.ca writes:

> On Sun, 26 Feb 2017, David Kastrup wrote:
>> To me it would seem that the default mode of operation should be for
>> them to have matched rules where feasible, in order to have least
>> element of surprise.
>
> I agree, but A. it may not be feasible in some important cases, and
> B. even matched rules wouldn't really solve the problem, because users
> would still have to explain to both the input and output systems their
> own preferred conversion between note sets and displayed chord symbols.
> (It doesn't help that the standard and traditional musical rules are
> *screwy* and the nonstandard rules many people want to use are even
> screwier.)
>
> Users want what they type to match what is displayed, even when it doesn't
> follow the default rules and possibly even when it doesn't follow any
> rules.  For the common use case of chord mode being used solely to
> generate notes for ChordNames, and ChordNames getting its notes solely
> from chord mode, we don't really need the notes at all.

There still is Midi output.

-- 
David Kastrup

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

Re: 13th chord?

[Thomas Morley]

2017-02-26 1:53 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> Well,
>> the printed output of
>>
>> m =
>> \chordmode {
>> 
>> c:11.13
>> %% unnecessarily verbose:
>> c:1.3.5.7.9.11.13
>> }
>>
>> mII =
>> \chordmode {
>> 
>> c:13
>> %% unnecessarily verbose:
>> c:1.3.5.7.9.13
>> }
>>
>> <<
>>   \new ChordNames { \m \mII }
>>   \new Staff { \m \mII }

>>
>> looks perfectly fine to me.
>
> The printed output for all of the first is C13 (so we have c:11.13 ->
> C13).  The printed output for all of the second is C9 13 (so we have
> c:13 -> C9 13).
>
> As a user interface, that's peculiar.  The question is why we have
> different defaults for input and output of chords.

The most common use-case for a 13-chord is to _omit_ the 11th, so we
make an exception for it. And it's even documented:

NR Extended and altered chords
"Since an unaltered 11 does not sound good when combined with an
unaltered 13, the 11 is removed from a :13 chord (unless it is added
explicitly)."

and

NR A.2 Common chord modifiers

Dominant thirteenthDominant ninth, major thirteenth c1:13 
Dominant thirteenthDominant eleventh, major thirteenth13.11
c1:13.11 


>
>> Obviously it's _me_ not understanding the issue.
>
> Does this make it clearer?

You explained the issue sufficiently, thanks!

Though, as said before, it's a design-decision and ofcourse we could
do it the other way round, i.e.:
c:13 -> c 13
c:13^11 -> c 9 13
but no bug.

Cheers,
  Harm

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

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, David Kastrup wrote:
> To me it would seem that the default mode of operation should be for
> them to have matched rules where feasible, in order to have least
> element of surprise.

I agree, but A. it may not be feasible in some important cases, and
B. even matched rules wouldn't really solve the problem, because users
would still have to explain to both the input and output systems their
own preferred conversion between note sets and displayed chord symbols.
(It doesn't help that the standard and traditional musical rules are
*screwy* and the nonstandard rules many people want to use are even
screwier.)

Users want what they type to match what is displayed, even when it doesn't
follow the default rules and possibly even when it doesn't follow any
rules.  For the common use case of chord mode being used solely to
generate notes for ChordNames, and ChordNames getting its notes solely
from chord mode, we don't really need the notes at all.  Just turning the
user's input directly into markup would make all the common problems with
chords disappear.

I've actually used lyrics to print chord names sometimes when I just
couldn't get "proper" ChordNames contexts to do what I wanted.  It seems
like lyrics are 80% of the way to the markup idea I'm describing.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: Fermata above and below bar line generates warnings

[Knute Snortum]

On Sat, Feb 25, 2017 at 2:07 PM, Thomas Morley 
wrote:

> 2017-02-25 22:42 GMT+01:00 Knute Snortum :
> > The following code produces the correct output of fermatas above and
> below
> > the bar line, but it also emits warnings.  Is there another way to do
> this
> > without warnings, or can the warnings be suppressed?  I got this code
> from:
> >
> > http://lsr.di.unimi.it/LSR/Snippet?id=10
> >
> > \version "2.19.55"
> >
> > \score {
> >   \new GrandStaff <<
> > \context Staff = one {
> >   c'1 \bar "|."
> >   \override Score.RehearsalMark.break-visibility =
> > #begin-of-line-invisible
> >   \mark \markup { \musicglyph #"scripts.ufermata" }
> > }
> > \context Staff = two \with { \consists "Mark_engraver" } {
> >   c'1
> >   \override Staff.RehearsalMark.direction = #DOWN
> >   \mark \markup { \musicglyph #"scripts.dfermata" }
> > }
> >   >>
> > }
> >
> > ---
> > Knute Snortum
> > (via Gmail)
>
>
> Hi,
>
> the warning happens because two different RehearsalMarks are read by
> the Mark_engraver in Score-context, one of them is dropped, again: in
> Score-context!!
> But the Mark_engraver is in the Staff-context of the lower Staff as
> well. So this engraver prints the fermata below.
>
> A naughty coding, not working around but using this behaviour would be:
>
> \version "2.19.52"
>
> \score {
>   \new GrandStaff <<
> \context Staff = one {
>   c'1 \bar "|."
> }
> \context Staff = two \with { \consists "Mark_engraver" } {
>   c'1
>   \override Score.RehearsalMark.break-visibility =
> #begin-of-line-invisible
>   \override Staff.RehearsalMark.direction = #DOWN
>   \override Staff.RehearsalMark.rotation = #'(180 0 0)
>   \mark \markup { \musicglyph #"scripts.ufermata" }
> }
>   >>
> }
>
>
>
> Cheers,
>   Harm
>

Wow, that code confuses me, I admit it!  Is the Mark_engraver printing the
upper *and* lower fermata in context "two"?
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fermata above and below bar line generates warnings

[Knute Snortum]

On Sat, Feb 25, 2017 at 2:02 PM, Jeffery Shivers 
wrote:

> On Sat, Feb 25, 2017 at 4:42 PM, Knute Snortum  wrote:
> > The following code produces the correct output of fermatas above and
> below
> > the bar line, but it also emits warnings.  Is there another way to do
> this
> > without warnings, or can the warnings be suppressed?  I got this code
> from:
> >
>
> What warnings? Without sharing that info, (1) you are expecting us to
> compile it ourselves (not a big hurdle, but potentially a redundant
> one which may prevent people who are away from their workstations from
> advising)
> and (2) nobody can know if you are getting a unique warning.
>

This is the output I get, with the warnings:

Starting lilypond.exe 2.19.55 [Untitled]...

Processing
`C:/Users/Knute/AppData/Local/Temp/frescobaldi-ctt4d4ig/tmp5l5e6d3u/
document.ly'

Parsing...

Interpreting music...

C:/Users/Knute/AppData/Local/Temp/frescobaldi-ctt4d4ig/tmp5l5e6d3u/document.ly:13:7
<0>: warning: Two simultaneous mark events, junking this one

\mark \markup { \musicglyph #"scripts.dfermata" }


C:/Users/Knute/AppData/Local/Temp/frescobaldi-ctt4d4ig/tmp5l5e6d3u/document.ly:8:7
<1>: warning: Previous mark event here

\mark \markup { \musicglyph #"scripts.ufermata" }


Preprocessing graphical objects...

Finding the ideal number of pages...

Fitting music on 1 page...

Drawing systems...

Layout output to `./tmp-lilypond-hzkSsS'...

Converting to `document.pdf'...

Deleting `./tmp-lilypond-hzkSsS'...

Success: compilation successfully completed

Completed successfully in 1.1".


> > http://lsr.di.unimi.it/LSR/Snippet?id=10
> >
> > \version "2.19.55"
> >
> > \score {
> >   \new GrandStaff <<
> > \context Staff = one {
> >   c'1 \bar "|."
> >   \override Score.RehearsalMark.break-visibility =
> > #begin-of-line-invisible
> >   \mark \markup { \musicglyph #"scripts.ufermata" }
> > }
> > \context Staff = two \with { \consists "Mark_engraver" } {
> >   c'1
> >   \override Staff.RehearsalMark.direction = #DOWN
> >   \mark \markup { \musicglyph #"scripts.dfermata" }
> > }
> >   >>
> > }
> >
>
> Oftentimes searching the web or specifically the LP archives will lead
> to past threads in which others have already encountered/debugged
> the same problem.
>
> I *strongly* suggest googling this issue yourself first - particularly
> if there is a line or two in the log that start with "warning: ...".
>
> --
>
> Jeffery Shivers
>  jefferyshivers.com
>  soundcloud.com/jefferyshivers


Just to let you know, I *do* search for answers first, but I don't always
know the right keywords to use.  In this case I searched for "fermata above
and below the bar line" and I got the snippet I posted, plus some prior
threads talking about the how to solve the problem, but all the solutions
produced warnings when I compiled them.

I use LilyPond to contribute to The Mutopia Project, so I can't submit a
file that compiles with warnings.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[David Kastrup]

msk...@ansuz.sooke.bc.ca writes:

> On Sun, 26 Feb 2017, Wols Lists wrote:
>> I'm guessing lily is taking *in* his request for "C 13", converting it
>> into the chord, and then converting that chord *back* into what it
>> thinks is called "C 9 13". With the result that lily's output does *not*
>> match the user's input. Frustrating!
>
> Okay, I think I see the issue - it's the same problem everybody has with
> chord mode and ChordNames, which is that those two things are completely
> separate from each other despite the usual use case treating them as a
> single entity.
>
> \chordmode { c:13 } turns into 
>
> \new ChordNames {  } prints "C9 13"
>
> I agree it looks like a bug, but because of the separation between chord
> mode and ChordNames, each is going to point the finger at the other as
> being at fault, because each one is using its own rules which taken
> independently seem sensible.

To me it would seem that the default mode of operation should be for
them to have matched rules where feasible, in order to have least
element of surprise.

-- 
David Kastrup

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

Re: 13th chord?

[David Kastrup]

Thomas Morley  writes:

> Well,
> the printed output of
>
> m =
> \chordmode {
> 
> c:11.13
> %% unnecessarily verbose:
> c:1.3.5.7.9.11.13
> }
>
> mII =
> \chordmode {
> 
> c:13
> %% unnecessarily verbose:
> c:1.3.5.7.9.13
> }
>
> <<
>   \new ChordNames { \m \mII }
>   \new Staff { \m \mII }
>>>
>
> looks perfectly fine to me.

The printed output for all of the first is C13 (so we have c:11.13 ->
C13).  The printed output for all of the second is C9 13 (so we have
c:13 -> C9 13).

As a user interface, that's peculiar.  The question is why we have
different defaults for input and output of chords.

> Obviously it's _me_ not understanding the issue.

Does this make it clearer?

-- 
David Kastrup

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

Re: Making the Dedication field align left

[Simon Albrecht]

Am 26.02.2017 um 00:47 schrieb Wols Lists:

I've stuck that definition
in its own .ily file, and I just %include that file at the start of my
\paper definition.


I think it would be slightly cleaner to write an entire \paper{} block 
in the .ily file and include the file on top level. Multiple paper 
blocks will be combined as you’d expect them to.


Best, Simon

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

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Wols Lists wrote:
> I'm guessing lily is taking *in* his request for "C 13", converting it
> into the chord, and then converting that chord *back* into what it
> thinks is called "C 9 13". With the result that lily's output does *not*
> match the user's input. Frustrating!

Okay, I think I see the issue - it's the same problem everybody has with
chord mode and ChordNames, which is that those two things are completely
separate from each other despite the usual use case treating them as a
single entity.

\chordmode { c:13 } turns into 

\new ChordNames {  } prints "C9 13"

I agree it looks like a bug, but because of the separation between chord
mode and ChordNames, each is going to point the finger at the other as
being at fault, because each one is using its own rules which taken
independently seem sensible.  The real solution would be a thing like
ChordNames that is actally a specialized markup mode and just *prints
whatever is typed dammit*, with minimal formatting transformations
(perhaps automatically putting numbers in superscript, and that's about
all), instead of trying to convert to "music" and back.

Probably the easiest thing to do is use an override on printing the chord,
and just ignore the fact that the notes are wrong internally (which
doesn't matter as long as the chord mode input is only used for
ChordNames).  Like so:

chExceptionMusic = {
  1-\markup { \super "13" }
}

chExceptions = #( append
  ( sequential-music-to-chord-exceptions chExceptionMusic #t)
  ignatzekExceptions)

\new ChordNames {
  \set chordNameExceptions = #chExceptions
  \chordmode { c:13 }
}

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: Force tuplet number above notes

[Knute Snortum]

Even better, thanks!


---
Knute Snortum
(via Gmail)

On Sat, Feb 25, 2017 at 2:01 PM,  wrote:

> Am 2017-02-25 22:56, schrieb Knute Snortum:
>
> That works, thanks!
>>
>
> I'm at the wrong computer so I can't double-check right now, but I think
> the reason for this is that it's the tuplet *bracket* that is responsible
> for the direction, so you can't override the tuplet *number*'s direction
> independently.
>
> Instead of the explicit override you could probably also use the shorthand
> \tupletUp (optionally prepended with \once).
> Urs
>
>
>> ---
>> Knute Snortum
>> (via Gmail)
>> On Sat, Feb 25, 2017 at 1:45 PM, Jeffery Shivers <
>> jefferyshiv...@gmail.com> wrote:
>>
>> On Sat, Feb 25, 2017 at 4:18 PM, Knute Snortum 
>>> wrote:
>>>
 I am trying to get both tuplet numbers above the notes in the following
 code.  I've tried \override TupletNumber.direction = #UP, but evidently
 this
 does not work.  What's the correct way to do this?

 \version "2.19.55"
 \language "english"

 \relative {
 \omit TupletBracket
 \override TupletNumber.direction = #UP
 \tuplet 3/2 2 { 4-> -> ->
 -> -> -> }
 }


>>> Maybe not the correct/best answer, but try it this way:
>>>
>>> == snip
>>> \relative {
>>> \override TupletBracket #'direction = #UP
>>> \omit TupletBracket
>>> \tuplet 3/2 2 {
>>> 4-> -> ->
>>> -> -> ->
>>> }
>>> }
>>> == snip
>>>
>>> --
>>>
>>> Jeffery Shivers
>>> jefferyshivers.com
>>> soundcloud.com/jefferyshivers
>>>
>>
>> ___
>> 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
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[Wols Lists]

On 25/02/17 23:47, Thomas Morley wrote:
> Obviously it's _me_ not understanding the issue.

As a complete outsider, I read it extremely simply ...

The OP asked lilypond to print the chord name as "C 13". Lilypond
ignored him and printed the name as "C 9 13".

Everybody seems to have got fixated on what the chord *is*. The OP
couldn't care, he is concerned about what the chord is *called*, and the
problem is lily is *changing* what he asked it to do. If I ask a
computer "please print X", I'm going to get rather upset if it prints Y
instead.

I'm guessing lily is taking *in* his request for "C 13", converting it
into the chord, and then converting that chord *back* into what it
thinks is called "C 9 13". With the result that lily's output does *not*
match the user's input. Frustrating!

Cheers,
Wol

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

Re: 13th chord?

[mskala]

On Sat, 25 Feb 2017, Rob Torop wrote:
> 13 chord would be rendered as C13 in Ignatzek notation. My question is - is
> there a way for me to omit the "9" in the chord name?  My experience is

There's no "9" in the chord name "C13", so what are you really asking?

Do you want to enter a chord name and get a C13 chord with no ninth (or,
presumably, eleventh) in it - that is, the notes C E G Bb A?  In that
case, try
  \chordmode { c:13^9 }
This is also the same thing as a
seventh chord with added thirteenth, so you could use
  \chordmode { c:7.13 }

Do you want to change the input syntax so that
  \chordmode { c:13 }
will have the same effect currently achieved by
  \chordmode { c:13^9 }
?
If so, that's probably a bad idea and it's unlikely anyone here will be
eager to help you do it.  You'd have to go find whatever code parses
input in chord mode, and hack that.  This would break compatibility
between your customized version of LilyPond and files created to use
chord mode with the released version.

Do you want to enter these notes, by whatever means, and have the chord
name that is displayed by a ChordNames context be "C13" and not something
else, in particular, not mentioning the ninth?  (The default naming
scheme seems to be "C7 13".)  In that case, you can use a chord name
exception as described at
   
http://lilypond.org/doc/v2.19/Documentation/notation/displaying-chords#Selected-Snippets-62
 .

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Making the Dedication field align left

[Wols Lists]

On 25/02/17 20:59, Simon Albrecht wrote:
> Am 25.02.2017 um 21:02 schrieb Chad Linsley:
>> Hi all,
>>
>> I'm a Lilypond noob and am trying to customize the header. How do I
>> override the "Dedication" so that it aligns left and not centre?
> 
> The way I understand it you want the dedication field placed on the left
> of the page, right? For that you need to change the paper variable
> bookTitleMarkup, which is explained on
> .
> Unfortunately, I’m not at my machine and need to ask others to give more
> specific advice – unless you can figure it out on your own.
> Speaking of ‘figure it out on your own’ – it’s incredibly helpful to
> have read the entire Learning Manual carefully (unless you already
> have). Many questions will be answered there. For more information on
> the markup commands required for customising bookTitleMarkup see
> .
> 
I'm not sure where in the lily source you will find the definition of
bookTitleMarkup, but I've done exactly that. I've stuck that definition
in its own .ily file, and I just %include that file at the start of my
\paper definition. Works a treat (I always put the instrument on the
left, not lily's centre default).

Cheers,
Wol


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

Re: 13th chord?

[Thomas Morley]

2017-02-26 0:38 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> 2017-02-25 23:08 GMT+01:00 David Kastrup :
>>> Rob Torop  writes:
>>>
 When I enter a 13th chord like this e:13, it renders with a 9 as well.
 I know a 13 chord officially contains the 9 and 11, and that lilypond
 by convention will omit the 11.  But I don't really want to have the 9
 showing.  Do I inadvertently have some setting on that is giving me
 this?
>>>
>>> Minimal example:
>>>
>>>
>>>
>>> The default chord printer is Ignatzek.  No idea whether this would count
>>> as a bug with the Ignatzek naming framework or not, and how the other
>>> chord printers would behave in comparison.
>>>
>>> As a default, the mismatch between input and output seems weird.
>>
>>
>> Well, we omit the 11 by purpose,
>> See the comment in construct-chord-elements from chord-entry.scm and
>> regtest chord-name-entry-11.ly.
>
> Huh?  Have you taken a look at the output?
>
>> Also quoting "Standardized Chord Symbol Notation" by Brandt/Roemer in
>> section "Dominant Thirteenths":
>> "In accepted usage, the 9th is included but the 11th is omitted. Quite
>> frequently the unaltered 5th is also left out."
>>
>> So no bug, but a design decision.
>
> The problem is not with the conversion of the input to a chord but with
> the conversion of a chord to a ChordName.
>
>> To have the 11th included, one needs to explicitely state it:
>>
>> \chords { e:11.13 }
>>
>> If this is not done, the printing as E⁹ ¹¹ is ok, imho.
>
> \chords { e:13 } is printed as E9 13 rather than E13 .  So the question
> is why the rationale for converting e:13 to chord notes differs from the
> rationale converting the chord notes to a chord name.
>
> --
> David Kastrup

Well,
the printed output of

m =
\chordmode {

c:11.13
%% unnecessarily verbose:
c:1.3.5.7.9.11.13
}

mII =
\chordmode {

c:13
%% unnecessarily verbose:
c:1.3.5.7.9.13
}

<<
  \new ChordNames { \m \mII }
  \new Staff { \m \mII }
>>

looks perfectly fine to me.


Obviously it's _me_ not understanding the issue.


Thus I'll be silent here.

Cheers,
  Harm

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

Re: 13th chord?

[Thomas Morley]

2017-02-26 0:20 GMT+01:00 Noeck :
> Hi Harm,
>
> Am 25.02.2017 um 23:47 schrieb Thomas Morley:
>> So no bug, but a design decision.
>>
>> To have the 11th included, one needs to explicitely state it:
>>
>> \chords { e:11.13 }
>>
>> If this is not done, the printing as E⁹ ¹¹ is ok, imho.
>
> As far as I understood Rob, the question is not so much about the 11 but
> about the 9 in the printed chord name.
>
> Wouldn't E¹³ be enough to name that chord?

The question remains is 11th in or not?

> What does the ⁹ tell?

The ⁹ _and_ ¹³ tells the 11th is missing, as far as I understood.

> I am exaggerating a bit, but if
> e:13   is   E⁹ ¹¹
> we could also label
> e:7as   E¹ ³ ⁵ ⁷.

Sure, but the tonic-pitch is always in, no need for ¹
The third as well, the absence of a minor-modifier tells us about a
major-chord, no need for ³
The 5th may be in or not, it is that frequently omitted that
explicitely stating ⁵ makes sense only for power-chords.
So as the only interesting addition the ⁷ remains.

> It might of course be, that I am misunderstanding
> the issue.
>
> Cheers,
> Joram


\chords {
%% from
%% http://lilypond.org/doc/v2.19/Documentation/notation/chord-name-chart

%% or
c:11.13
%% or unnecessarily verbose:
c:1.3.5.7.9.11.13
}

all inputs print c¹³

This should solve the OP's issue.

But thinking about common usage, i.e. omitting the 11th...
How to print it?
C⁹ ¹³ looks reasonable to me.


Though, ofcourse I may misunderstand the issue as well...

Cheers,
  Harm

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

Re: 13th chord?

[David Kastrup]

Thomas Morley  writes:

> 2017-02-25 23:08 GMT+01:00 David Kastrup :
>> Rob Torop  writes:
>>
>>> When I enter a 13th chord like this e:13, it renders with a 9 as well.
>>> I know a 13 chord officially contains the 9 and 11, and that lilypond
>>> by convention will omit the 11.  But I don't really want to have the 9
>>> showing.  Do I inadvertently have some setting on that is giving me
>>> this?
>>
>> Minimal example:
>>
>>
>>
>> The default chord printer is Ignatzek.  No idea whether this would count
>> as a bug with the Ignatzek naming framework or not, and how the other
>> chord printers would behave in comparison.
>>
>> As a default, the mismatch between input and output seems weird.
>
>
> Well, we omit the 11 by purpose,
> See the comment in construct-chord-elements from chord-entry.scm and
> regtest chord-name-entry-11.ly.

Huh?  Have you taken a look at the output?

> Also quoting "Standardized Chord Symbol Notation" by Brandt/Roemer in
> section "Dominant Thirteenths":
> "In accepted usage, the 9th is included but the 11th is omitted. Quite
> frequently the unaltered 5th is also left out."
>
> So no bug, but a design decision.

The problem is not with the conversion of the input to a chord but with
the conversion of a chord to a ChordName.

> To have the 11th included, one needs to explicitely state it:
>
> \chords { e:11.13 }
>
> If this is not done, the printing as E⁹ ¹¹ is ok, imho.

\chords { e:13 } is printed as E9 13 rather than E13 .  So the question
is why the rationale for converting e:13 to chord notes differs from the
rationale converting the chord notes to a chord name.

-- 
David Kastrup

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

Re: 13th chord?

[Noeck]

Hi Harm,

Am 25.02.2017 um 23:47 schrieb Thomas Morley:
> So no bug, but a design decision.
> 
> To have the 11th included, one needs to explicitely state it:
> 
> \chords { e:11.13 }
> 
> If this is not done, the printing as E⁹ ¹¹ is ok, imho.

As far as I understood Rob, the question is not so much about the 11 but
about the 9 in the printed chord name.

Wouldn't E¹³ be enough to name that chord? What does the ⁹ tell?
I am exaggerating a bit, but if
e:13   is   E⁹ ¹¹
we could also label
e:7as   E¹ ³ ⁵ ⁷. It might of course be, that I am misunderstanding
the issue.

Cheers,
Joram

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

Re: 13th chord?

[Rob Torop]

I'm pretty confused!  According to
http://lilypond.org/doc/v2.19/Documentation/notation/chord-name-chart, a 13
chord would be rendered as C13 in Ignatzek notation. My question is - is
there a way for me to *omit* the "9" in the chord name?  My experience is
limited just to looking at jazz lead sheets and pop music, but at least in
those I've never seen it done this way. I'm not saying it's wrong of course.

On Sat, Feb 25, 2017 at 5:47 PM, Thomas Morley 
wrote:

> 2017-02-25 23:08 GMT+01:00 David Kastrup :
> > Rob Torop  writes:
> >
> >> When I enter a 13th chord like this e:13, it renders with a 9 as well.
> >> I know a 13 chord officially contains the 9 and 11, and that lilypond
> >> by convention will omit the 11.  But I don't really want to have the 9
> >> showing.  Do I inadvertently have some setting on that is giving me
> >> this?
> >
> > Minimal example:
> >
> >
> >
> > The default chord printer is Ignatzek.  No idea whether this would count
> > as a bug with the Ignatzek naming framework or not, and how the other
> > chord printers would behave in comparison.
> >
> > As a default, the mismatch between input and output seems weird.
> >
> > --
> > David Kastrup
>
>
> Well, we omit the 11 by purpose,
> See the comment in construct-chord-elements from chord-entry.scm and
> regtest chord-name-entry-11.ly.
>
> Also quoting "Standardized Chord Symbol Notation" by Brandt/Roemer in
> section "Dominant Thirteenths":
> "In accepted usage, the 9th is included but the 11th is omitted. Quite
> frequently the unaltered 5th is also left out."
>
> So no bug, but a design decision.
>
> To have the 11th included, one needs to explicitely state it:
>
> \chords { e:11.13 }
>
> If this is not done, the printing as E⁹ ¹¹ is ok, imho.
>
> Ofcourse we could do it the other way round. as said: a design decision.
>
>
> Cheers,
>   Harm
>



-- 
Sent using my Mnemonic Memory Circuit
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[Thomas Morley]

2017-02-25 23:08 GMT+01:00 David Kastrup :
> Rob Torop  writes:
>
>> When I enter a 13th chord like this e:13, it renders with a 9 as well.
>> I know a 13 chord officially contains the 9 and 11, and that lilypond
>> by convention will omit the 11.  But I don't really want to have the 9
>> showing.  Do I inadvertently have some setting on that is giving me
>> this?
>
> Minimal example:
>
>
>
> The default chord printer is Ignatzek.  No idea whether this would count
> as a bug with the Ignatzek naming framework or not, and how the other
> chord printers would behave in comparison.
>
> As a default, the mismatch between input and output seems weird.
>
> --
> David Kastrup


Well, we omit the 11 by purpose,
See the comment in construct-chord-elements from chord-entry.scm and
regtest chord-name-entry-11.ly.

Also quoting "Standardized Chord Symbol Notation" by Brandt/Roemer in
section "Dominant Thirteenths":
"In accepted usage, the 9th is included but the 11th is omitted. Quite
frequently the unaltered 5th is also left out."

So no bug, but a design decision.

To have the 11th included, one needs to explicitely state it:

\chords { e:11.13 }

If this is not done, the printing as E⁹ ¹¹ is ok, imho.

Ofcourse we could do it the other way round. as said: a design decision.


Cheers,
  Harm

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

Re: 13th chord?

[David Kastrup]

Rob Torop  writes:

> When I enter a 13th chord like this e:13, it renders with a 9 as well.
> I know a 13 chord officially contains the 9 and 11, and that lilypond
> by convention will omit the 11.  But I don't really want to have the 9
> showing.  Do I inadvertently have some setting on that is giving me
> this?

Minimal example:

\version "2.19.50"

\chords { e:13 }

The default chord printer is Ignatzek.  No idea whether this would count
as a bug with the Ignatzek naming framework or not, and how the other
chord printers would behave in comparison.

As a default, the mismatch between input and output seems weird.

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

Re: Fermata above and below bar line generates warnings

[Thomas Morley]

2017-02-25 22:42 GMT+01:00 Knute Snortum :
> The following code produces the correct output of fermatas above and below
> the bar line, but it also emits warnings.  Is there another way to do this
> without warnings, or can the warnings be suppressed?  I got this code from:
>
> http://lsr.di.unimi.it/LSR/Snippet?id=10
>
> \version "2.19.55"
>
> \score {
>   \new GrandStaff <<
> \context Staff = one {
>   c'1 \bar "|."
>   \override Score.RehearsalMark.break-visibility =
> #begin-of-line-invisible
>   \mark \markup { \musicglyph #"scripts.ufermata" }
> }
> \context Staff = two \with { \consists "Mark_engraver" } {
>   c'1
>   \override Staff.RehearsalMark.direction = #DOWN
>   \mark \markup { \musicglyph #"scripts.dfermata" }
> }
>   >>
> }
>
> ---
> Knute Snortum
> (via Gmail)


Hi,

the warning happens because two different RehearsalMarks are read by
the Mark_engraver in Score-context, one of them is dropped, again: in
Score-context!!
But the Mark_engraver is in the Staff-context of the lower Staff as
well. So this engraver prints the fermata below.

A naughty coding, not working around but using this behaviour would be:

\version "2.19.52"

\score {
  \new GrandStaff <<
\context Staff = one {
  c'1 \bar "|."
}
\context Staff = two \with { \consists "Mark_engraver" } {
  c'1
  \override Score.RehearsalMark.break-visibility = #begin-of-line-invisible
  \override Staff.RehearsalMark.direction = #DOWN
  \override Staff.RehearsalMark.rotation = #'(180 0 0)
  \mark \markup { \musicglyph #"scripts.ufermata" }
}
  >>
}



Cheers,
  Harm

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

Re: Fermata above and below bar line generates warnings

[Jeffery Shivers]

On Sat, Feb 25, 2017 at 4:42 PM, Knute Snortum  wrote:
> The following code produces the correct output of fermatas above and below
> the bar line, but it also emits warnings.  Is there another way to do this
> without warnings, or can the warnings be suppressed?  I got this code from:
>

What warnings? Without sharing that info, (1) you are expecting us to
compile it ourselves (not a big hurdle, but potentially a redundant
one which may prevent people who are away from their workstations from advising)
and (2) nobody can know if you are getting a unique warning.

> http://lsr.di.unimi.it/LSR/Snippet?id=10
>
> \version "2.19.55"
>
> \score {
>   \new GrandStaff <<
> \context Staff = one {
>   c'1 \bar "|."
>   \override Score.RehearsalMark.break-visibility =
> #begin-of-line-invisible
>   \mark \markup { \musicglyph #"scripts.ufermata" }
> }
> \context Staff = two \with { \consists "Mark_engraver" } {
>   c'1
>   \override Staff.RehearsalMark.direction = #DOWN
>   \mark \markup { \musicglyph #"scripts.dfermata" }
> }
>   >>
> }
>

Oftentimes searching the web or specifically the LP archives will lead
to past threads in which others have already encountered/debugged
the same problem.

I *strongly* suggest googling this issue yourself first - particularly
if there is a line or two in the log that start with "warning: ...".

-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers

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

Re: Force tuplet number above notes

[Knute Snortum]

That works, thanks!


---
Knute Snortum
(via Gmail)

On Sat, Feb 25, 2017 at 1:45 PM, Jeffery Shivers 
wrote:

> On Sat, Feb 25, 2017 at 4:18 PM, Knute Snortum  wrote:
> > I am trying to get both tuplet numbers above the notes in the following
> > code.  I've tried \override TupletNumber.direction = #UP, but evidently
> this
> > does not work.  What's the correct way to do this?
> >
> > \version "2.19.55"
> > \language "english"
> >
> > \relative {
> >   \omit TupletBracket
> >   \override TupletNumber.direction = #UP
> >   \tuplet 3/2 2 { 4-> -> ->
> > -> -> -> }
> > }
> >
>
> Maybe not the correct/best answer, but try it this way:
>
> == snip
> \relative {
>   \override TupletBracket #'direction = #UP
>   \omit TupletBracket
>   \tuplet 3/2 2 {
> 4-> -> ->
> -> -> ->
>   }
> }
> == snip
>
> --
>
> Jeffery Shivers
>  jefferyshivers.com
>  soundcloud.com/jefferyshivers
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Force tuplet number above notes

[Jeffery Shivers]

On Sat, Feb 25, 2017 at 4:18 PM, Knute Snortum  wrote:
> I am trying to get both tuplet numbers above the notes in the following
> code.  I've tried \override TupletNumber.direction = #UP, but evidently this
> does not work.  What's the correct way to do this?
>
> \version "2.19.55"
> \language "english"
>
> \relative {
>   \omit TupletBracket
>   \override TupletNumber.direction = #UP
>   \tuplet 3/2 2 { 4-> -> ->
> -> -> -> }
> }
>

Maybe not the correct/best answer, but try it this way:

== snip
\relative {
  \override TupletBracket #'direction = #UP
  \omit TupletBracket
  \tuplet 3/2 2 {
4-> -> ->
-> -> ->
  }
}
== snip

-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers

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

Fermata above and below bar line generates warnings

[Knute Snortum]

The following code produces the correct output of fermatas above and below
the bar line, but it also emits warnings.  Is there another way to do this
without warnings, or can the warnings be suppressed?  I got this code from:

http://lsr.di.unimi.it/LSR/Snippet?id=10

\version "2.19.55"

\score {
  \new GrandStaff <<
\context Staff = one {
  c'1 \bar "|."
  \override Score.RehearsalMark.break-visibility =
#begin-of-line-invisible
  \mark \markup { \musicglyph #"scripts.ufermata" }
}
\context Staff = two \with { \consists "Mark_engraver" } {
  c'1
  \override Staff.RehearsalMark.direction = #DOWN
  \mark \markup { \musicglyph #"scripts.dfermata" }
}
  >>
}

---
Knute Snortum
(via Gmail)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

13th chord?

[Rob Torop]

When  I enter a 13th chord like this e:13, it renders with a 9 as well.  I
know a 13 chord officially contains the 9 and 11, and that lilypond by
convention will omit the 11.  But I don't really want to have the 9
showing.  Do I inadvertently have some setting on that is giving me this?
[image: Inline image 1]
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Force tuplet number above notes

[Knute Snortum]

I am trying to get both tuplet numbers above the notes in the following
code.  I've tried \override TupletNumber.direction = #UP, but evidently
this does not work.  What's the correct way to do this?

\version "2.19.55"
\language "english"

\relative {
  \omit TupletBracket
  \override TupletNumber.direction = #UP
  \tuplet 3/2 2 { 4-> -> ->
-> -> -> }
}

---
Knute Snortum
(via Gmail)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Making the Dedication field align left

[Simon Albrecht]

Am 25.02.2017 um 21:02 schrieb Chad Linsley:

Hi all,

I'm a Lilypond noob and am trying to customize the header. How do I 
override the "Dedication" so that it aligns left and not centre?


The way I understand it you want the dedication field placed on the left 
of the page, right? For that you need to change the paper variable 
bookTitleMarkup, which is explained on 
. 
Unfortunately, I’m not at my machine and need to ask others to give more 
specific advice – unless you can figure it out on your own.
Speaking of ‘figure it out on your own’ – it’s incredibly helpful to 
have read the entire Learning Manual carefully (unless you already 
have). Many questions will be answered there. For more information on 
the markup commands required for customising bookTitleMarkup see 
.


HTH…
Simon

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

Re: Making the Dedication field align left

[Jeffery Shivers]

On Sat, Feb 25, 2017 at 3:39 PM, Jeffery Shivers
 wrote:
>
> Have a look at ...
>
> http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Creating-titles

Oops, I mean: 
http://lilypond.org/doc/v2.18/Documentation/notation/titles-and-headers

-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers

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

Re: Making the Dedication field align left

[Jeffery Shivers]

On Sat, Feb 25, 2017 at 3:02 PM, Chad Linsley  wrote:
> Hi all,
>
> I'm a Lilypond noob and am trying to customize the header. How do I override
> the "Dedication" so that it aligns left and not centre?

Hi Chad,

Have a look at ...

http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Creating-titles

... and ...

http://lilypond.org/doc/v2.18/Documentation/notation/align

Try this:

\header {
  dedication = \markup \column {
\fill-with-pattern #2 #LEFT "" "Dedicated to You" ""
  }
  title = "Title"
}




-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers

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

Re: UTF-8 in MIDI Lyrics

[karl]

Joseph Austin:
> > From: Karl Hammar  > >
...
> >> But if we are going to use a "private standard", we might as well
> >> imitate the "official" standard and insert something like
> >> FF 05 07 { @ U T F 8 }
> >> And lobby AMEI/MMA to adopt an official UTF8 position.
> > 
> > Could be good, but why just not capitalize on the BOM and just use
> > utf8.
...
> OK, the UTF-8 BOM is 0x EF BB BF
> But given that the MIDI file is not a "text file" but a binary
> file with text fields scattered throughout,
> normally embedded in various MIDI Meta-events, where should the BOM
> be placed?
> 
> Interpreting your suggestion, we could add a Lyric Meta-Event with
> the BOM as the text field to Track 0 Time 0.  
> That should work for lyrics, but RP-26 indicates that lyrics
> "language encoding" should not extend to other types of text events.
> For other text events, it seems we would need to prefix every UTF-8
> text field with the BOM.

Unfortunately midi-file standard and rp26 doesn't help you with that.
The only fallback we have is the notice that you can use extended
charset, but you have to check that programs at the other end of the
pipe does something reasonable with it.

And all this boils down to how do programs out there interpret any
extended char, do they support utf8 BOM, do they support rp26 ?
Well, I don't know.

>From reading rp26, it only talks about latin (latin-1 I assume),
ms-kanji and utf16* (which has the boms "FFFE", "FEFF"), so I don't
think we can expect anything more. Utf16 points to MS-Windows, what
programs makes midi files on that os, how to they do it ?

Soo in the end, I think we should just use utf8 and wait and see if
any bug reports comes in about it.

But as you suggest, we could talk to the midi assosiation to amend
the standard. The easiest would be if they replaced the word "ascii"
with "utf8".

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

Making the Dedication field align left

[Chad Linsley]

Hi all,

I'm a Lilypond noob and am trying to customize the header. How do I
override the "Dedication" so that it aligns left and not centre?

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

Re: Png cropping

[Renato Fiorenza]

Hi,
Thank you for your replies. Using a GUI like Frescobaldi is not really 
something I can do while programming. However, I can surely insert margins to 
the cropped png, which is definitely what I am going to do.
Best regards,
  Renato
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Png cropping

[Renato Fiorenza]

Hi Simon, hi David,

I am very sorry. I absolutely did not intend to make any sort of accusation. I 
did word the phrase badly, led by the too impulsive thought that I couldn't 
believe that LilyPond, even being so powerful, couldn't do what I thought it 
would be certainly able to do.

Actually, after reading your replies, I realised why this behaviour is actually 
intended and indeed much more rational than giving the option of cropping the 
png as the user wants. I will surely follow your suggestions of adding margins 
to the cropped png, instead of trying to crop the full one.

Thank you for your replies.
   Renato
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI Lyrics

[Joseph Austin]

> On Feb 25, 2017, at 11:41 AM, lilypond-user-requ...@gnu.org wrote:
> 
> Date: Sat, 25 Feb 2017 17:34:54 +0100 (CET)
> From: Karl Hammar  >
> To: Joseph Austin >
> 
> 
> And,  rp26 clearly states in section 5:
> 
> In addition, if a byte order mark which specifies UNICODE such as
> 'FF FE' or 'FE FF' exists, the character code SET should be treated
>  as UNICODE.
> 
> There is such a "byte order mark" for utf8, see [2]. And then by
> extension, you just have to insert that BOM somewhere in the midi
> file (exists == not restricted to the lyrics meta event, preferable
> in track 0 at time 0) and it would be legal (according to the
> recommendation) to use utf8 straigth out the box.
> 
> [2] http://www.unicode.org/faq/utf_bom.html#BOM 
> 
> 
> 
> 
>> only ASCII chars between 0 and 127 are allowed.
> 
> Your wording is too hard. complete_midi_96-1-3.pdf, p.137 (or [1] 
> p.10) clearly says "should", but 
> 
> "other characters codes
> using the high-order bit may be used for interchange of files between
> different programs on the same computer which supports an extended
> character set. Programs on a computer   which  does not support
> non-ASCII characters should ignore those characters."

I stand corrected.

>> But if we are going to use a "private standard", we might as well
>> imitate the "official" standard and insert something like
>> FF 05 07 { @ U T F 8 }
>> And lobby AMEI/MMA to adopt an official UTF8 position.
> 
> Could be good, but why just not capitalize on the BOM and just use
> utf8.
> 
> Regards,
> /Karl Hammar

OK, the UTF-8 BOM is 0x EF BB BF
But given that the MIDI file is not a "text file" but a binary file with text 
fields scattered throughout,
normally embedded in various MIDI Meta-events, where should the BOM be placed?

Interpreting your suggestion, we could add a Lyric Meta-Event with the BOM as 
the text field to Track 0 Time 0.  
That should work for lyrics, but RP-26 indicates that lyrics "language 
encoding" should not extend to other types of text events.
For other text events, it seems we would need to prefix every UTF-8 text field 
with the BOM.
---
Joe Austin


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

Re: cross-voice ties and merging noteheads

[Orm Finnendahl]

Hi all,

Am Samstag, den 25. Februar 2017 um 17:41:15 Uhr (+0100) schrieb Urs Liska:
> Yes, but I think the issue is solved by now with Andrew's suggestion.

 it is indeed. Thanks Andrew!

Yours,
Orm
--
Prof. Orm Finnendahl
Komposition
Hochschule für Musik und Darstellende Kunst
Eschersheimer Landstr. 29-39
60322 Frankfurt am Main

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

Re: ghostscript fails on pdf generation

[David Wright]

On Sat 25 Feb 2017 at 13:06:02 (+0100), N. Andrew Walsh wrote:
> Hi List,
> 
> so, I did some digging regarding this error I've been getting with pdf
> output (see below). I found this note to lilypond-users from two years ago:
> https://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00932.html
> 
> The money line is to comment out the last line of
> /usr/share/ghostscript/[$GS_VERSION]/Resource/Init/Fontmap,
> which reads:
> 
> (Fontmap.local) .runlibfileifexists
> 
> When I replaced that line with:
> %(Fontmap.local) .runlibfileifexists
> 
> pdf output worked correctly with lilypond/frescobaldi.
> 
> Some further information:
> Before this workaround, console output returned the following when running
> the same command from console that was failing in frescobaldi:
> 
> $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> -sOutputFile=lamento.pdf -c.setpdfwrite -f/tmp/lilypond-3iqFdT
> GPL Ghostscript 9.20: Can't embed the complete font LinLibertineO as it is
> too large, embedding a subset.
> GPL Ghostscript 9.20: Can't embed the complete font LinLibertineOI as it is
> too large, embedding a subset.
> GPL Ghostscript 9.20: Can't embed the complete font LinLibertineOB as it is
> too large, embedding a subset.
> $
> 
> If, however, the intended output filename has whitespaces, I get the
> following error:
> 
>  $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> -sOutputFile=Reinhold Urmetzer - Lamento di Achille.pdf -c.setpdfwrite
> -f/tmp/lilypond-DDb0P7
> Error: /undefinedfilename in (Urmetzer)
> Operand stack:
> 
> Execution stack:
>%interp_exit   .runexec2   --nostringval--   --nostringval--
> --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
> --nostringval--   false   1   %stopped_push
> Dictionary stack:
>--dict:1211/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--
> Current allocation mode is local
> Last OS error: No such file or directory
> GPL Ghostscript 9.20: Unrecoverable error, exit code 1
> $
> 
> So, to review:
> if the filename has spaces, gs output will fail both in frescobaldi and
> from console

…because of your second illustration. gs fails early on because
"Urmetzer" is a non-option and therefore expected to be a Ghostscript
program for interpretation.

> if the filename does not have spaces, output fails in frescobaldi, and also
> running lilypond from console, but not running the last 'gs' command from
> console

…because of your first illustration. gs fails later on because of the
font overcapacity.

> if that last line about Fontmap.local is commented out
> in /usr/share/ghostscript/[$GS_VERSION]/Resource/Init/Fontmap, pdf output
> works in both console and frescobaldi.
> 
> So, is this a bug/defect somewhere in frescobaldi/lilypond/ghostscript? If
> so, which?

The second problem looks as if the caller of gs is not protecting the
spaces in the filename. Some interesting things can happen by chance
with those filenames. If you put
... -sOutputFile="good output.pdf" -c.setpdfwrite -f/tmp/somefile
everything works as normal. So does
... -sOutputFile=good\ output.pdf -c.setpdfwrite -f/tmp/somefile
and so does
... -sOutputFile=good /tmp/somefile -c.setpdfwrite

However, if you put
... -sOutputFile=good output.pdf -c.setpdfwrite -f/tmp/somefile
and there happens to be a file called output.pdf, gs will happily
give you a PDF called "good" containing output.pdf followed by
the converted /tmp/somefile.

You could test that "in the field", as it were, by running a
file with a single space in its name, "foo bar", and leaving
a bar.pdf file in the output directory. The result should be
a PDF file called foo containing bar.pdf followed by the
LilyPond output.

I can't help with the font problem, sorry.

Cheers,
David.

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

Re: Png cropping

[David Wright]

On Sat 25 Feb 2017 at 04:01:43 (-0700), renyhp wrote:
> Hi,
> Thank you for your answers. I am actually programming something automated (a
> Telegram bot for LilyPond! If you are on Telegram you will find it at
> @lilypondbot), so probably the best option will be to discard using
> LilyPond's cropping feature and try to find another way to crop it myself.
> It is a bit sad, though, that a so powerful tool like LilyPond can't adjust
> some simple things like png output margins.

IMO that would be like going to the tile store and having to
buy tiles with 3mm of grout round them. One buys clean tiles
and applies grout of desired width when they're laid.

In my workflow, I don't use PNGs because they're already rasterised,
which messes up rescaling. PDFs are much better, and there's a tool
for cropping them, pdfcrop, which is bundled in the TeX Live
distribution, which LilyPond users are likely to be already using:
$ pdfcrop --margins  in.pdf out.pdf

Adding facilities to LP for manipulating PNGs would be a big
duplication of time and effort IMO. After all, where do you stop?
$ gm convert -negate -trim -bordercolor red -border 10x0 -bordercolor green 
-border 0x8 in.png out.png
looks like an over-the-top command you might use. It will convert the
image to white on black, trim it (by inspecting the colour of the
corner pixels), then add coloured borders to the sides and the top and
bottom. Just prune that command to taste.

Cheers,
David.

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

Re: UTF-8 in MIDI Lyrics

[karl]

sorry, last mail wrong from header.

Joe Austen:
> > Am 24.02.2017 um 02:15 schrieb Joseph Austin:
> >> This raises another question.  I'm working with MIDI files,
> >> and it's not clear how to encode UTF-8 text in MIDI.
> >> There must be some convention, but I haven't found an official RP for it.
...
> I don't have a program that displays MIDI  files with lyrics, so I can't test 
> it.

Timidity will show the lyrics.
I have a simple program that dumps the midi as text:

 http://aspodata.se/git/musik/bin/midi.pl

$ midi.pl test.midi  | grep lyric | head
['lyric', 0, 'Sta'],
['lyric', 768, 'bat '],
['lyric', 768, 'Ma'],
['lyric', 768, 'ter '],
['lyric', 384, 'do'],
['lyric', 768, 'lo'],
['lyric', 384, 'ro'],
['lyric', 768, 'sa '],
['lyric', 384, 'sa '],
['lyric', 384, 'jux'],
$

> It appears that, when generating a MIDI file, LilyPond currently
> just puts UTF8 chars in the text fields as if they were ASCII.
> According the base MIDI spec, this is illegal;  only ASCII chars
> between 0 and 127 are allowed.

Your wording is too hard. complete_midi_96-1-3.pdf, p.137 (or [1] 
p.10) clearly says "should", but 

 "other characters codes
 using the high-order bit may be used for interchange of files between
 different programs on the same computer which supports an extended
 character set. Programs on a computer   which  does not support
 non-ASCII characters should ignore those characters."

[1] http://www.cdik.se/pdf/midiformat.pdf

Also, rp17.pdf, last paragraph gives you the set that are "accepted for use"
and that "it is best to avoid the use of these characters: \ [ ] { }".

And,  rp26 clearly states in section 5:
 
 In addition, if a byte order mark which specifies UNICODE such as
 'FF FE' or 'FE FF' exists, the character code SET should be treated
  as UNICODE.

There is such a "byte order mark" for utf8, see [2]. And then by
extension, you just have to insert that BOM somewhere in the midi
file (exists == not restricted to the lyrics meta event, preferable
in track 0 at time 0) and it would be legal (according to the
recommendation) to use utf8 straigth out the box.

[2] http://www.unicode.org/faq/utf_bom.html#BOM

> However, MIDI RP-17 and RP-26 introduce additional encodings for
> the  portion of the lyric meta-event FF 05  .

You do extrapolate a litte, rp17 tells you the "recommended" way to 
specify end of word/line/paragraph, and gives you a list of characters
that should give no compatibility problems.

> In particular, RP-26 specifies the "language" code  {@LATIN} to
> include 8-bit chars > 127.  It seems no code for "UTF8" has been
> officially defined, but a reasonable proposal might be language code:
> {@UTF8}.

You don't need that, see above about BOM. Also it would be interesting
to see which programs that actually support rp26. Since midi "standards"
just are recommendations, you have to know what works in the wild.

..
> So for LilyPond purposes, it would suffice to use a reversible
> encoding, that is, LilyPond would accept any MIDI file text format
> that LilyPond generates.  The apparently existing UTF-8 default
> should work for that.

Lilypond don't read midi files, you can convert midi files to ly files,
which then lilypond can read.

> But if we are going to use a "private standard", we might as well
> imitate the "official" standard and insert something like
> FF 05 07 { @ U T F 8 }
> And lobby AMEI/MMA to adopt an official UTF8 position.

Could be good, but why just not capitalize on the BOM and just use
utf8.

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: Png cropping

[karl]

> renyhp wrote
> > I read in the documentation that it is possible to create a cropped png by
> > using "-dbackend=eps -dresolution=600 —png" and inserting this \paper
> > block:
> > 
> > However, I think the cropping is too heavy. How can I produce a png with
> > some nonzero margins? 

Have you tested adding margins with pnmpad as in
 pngtopnm input_file |
 pnmpad -white  -left 10 -righ 10 -top 10 -bottom 10 |
 pnmtopng > padded.png

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: cross-voice ties and merging noteheads

[Urs Liska]

Am 25.02.2017 um 17:21 schrieb Phil Holmes:
> - Original Message - From: "Orm Finnendahl"
> 
> To: 
> Sent: Saturday, February 25, 2017 2:45 PM
> Subject: Re: cross-voice ties and merging noteheads
>
>
>> Am Samstag, den 25. Februar 2017 um 14:25:52 Uhr (+0100) schrieb Urs
>> Liska:
>>> An image would be helpful to avoid misunderstandings.
>>
>> attached. I tried to keep the file size small. Let me know if you
>> need it in better resolution.
>>
>> -- 
>> Orm
>>
>
> I'm thinking that Urs meant an image of what you're trying to
> _achieve_ rather than what you currently _have_ with LilyPond.
>

Yes, but I think the issue is solved by now with Andrew's suggestion.
Urs

> -- 
> Phil Holmes
>
> ___
> 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: UTF-8 in MIDI Lyrics

[Karl Hammar]

Joe Austen:
> > Am 24.02.2017 um 02:15 schrieb Joseph Austin:
> >> This raises another question.  I'm working with MIDI files,
> >> and it's not clear how to encode UTF-8 text in MIDI.
> >> There must be some convention, but I haven't found an official RP for it.
...
> I don't have a program that displays MIDI  files with lyrics, so I can't test 
> it.

Timidity will show the lyrics.
I have a simple program that dumps the midi as text:

 http://aspodata.se/git/musik/bin/midi.pl

$ midi.pl test.midi  | grep lyric | head
['lyric', 0, 'Sta'],
['lyric', 768, 'bat '],
['lyric', 768, 'Ma'],
['lyric', 768, 'ter '],
['lyric', 384, 'do'],
['lyric', 768, 'lo'],
['lyric', 384, 'ro'],
['lyric', 768, 'sa '],
['lyric', 384, 'sa '],
['lyric', 384, 'jux'],
$

> It appears that, when generating a MIDI file, LilyPond currently
> just puts UTF8 chars in the text fields as if they were ASCII.
> According the base MIDI spec, this is illegal;  only ASCII chars
> between 0 and 127 are allowed.

Your wording is too hard. complete_midi_96-1-3.pdf, p.137 (or [1] 
p.10) clearly says "should", but 

 "other characters codes
 using the high-order bit may be used for interchange of files between
 different programs on the same computer which supports an extended
 character set. Programs on a computer   which  does not support
 non-ASCII characters should ignore those characters."

[1] http://www.cdik.se/pdf/midiformat.pdf

Also, rp17.pdf, last paragraph gives you the set that are "accepted for use"
and that "it is best to avoid the use of these characters: \ [ ] { }".

And,  rp26 clearly states in section 5:
 
 In addition, if a byte order mark which specifies UNICODE such as
 'FF FE' or 'FE FF' exists, the character code SET should be treated
  as UNICODE.

There is such a "byte order mark" for utf8, see [2]. And then by
extension, you just have to insert that BOM somewhere in the midi
file (exists == not restricted to the lyrics meta event, preferable
in track 0 at time 0) and it would be legal (according to the
recommendation) to use utf8 straigth out the box.

[2] http://www.unicode.org/faq/utf_bom.html#BOM

> However, MIDI RP-17 and RP-26 introduce additional encodings for
> the  portion of the lyric meta-event FF 05  .

You do extrapolate a litte, rp17 tells you the "recommended" way to 
specify end of word/line/paragraph, and gives you a list of characters
that should give no compatibility problems.

> In particular, RP-26 specifies the "language" code  {@LATIN} to
> include 8-bit chars > 127.  It seems no code for "UTF8" has been
> officially defined, but a reasonable proposal might be language code:
> {@UTF8}.

You don't need that, see above about BOM. Also it would be interesting
to see which programs that actually support rp26. Since midi "standards"
just are recommendations, you have to know what works in the wild.

..
> So for LilyPond purposes, it would suffice to use a reversible
> encoding, that is, LilyPond would accept any MIDI file text format
> that LilyPond generates.  The apparently existing UTF-8 default
> should work for that.

Lilypond don't read midi files, you can convert midi files to ly files,
which then lilypond can read.

> But if we are going to use a "private standard", we might as well
> imitate the "official" standard and insert something like
> FF 05 07 { @ U T F 8 }
> And lobby AMEI/MMA to adopt an official UTF8 position.

Could be good, but why just not capitalize on the BOM and just use
utf8.

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: cross-voice ties and merging noteheads

[Phil Holmes]

- Original Message - 
From: "Orm Finnendahl" 

To: 
Sent: Saturday, February 25, 2017 2:45 PM
Subject: Re: cross-voice ties and merging noteheads


Am Samstag, den 25. Februar 2017 um 14:25:52 Uhr (+0100) schrieb Urs 
Liska:

An image would be helpful to avoid misunderstandings.


attached. I tried to keep the file size small. Let me know if you
need it in better resolution.

--
Orm



I'm thinking that Urs meant an image of what you're trying to _achieve_ 
rather than what you currently _have_ with LilyPond.


--
Phil Holmes 



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

Re: Png cropping

[David Wright]

On Sat 25 Feb 2017 at 02:26:53 (-0700), Klaus Blum wrote:
> Hi Renato, hi Andrew,
> 
> Andrew Bernard wrote
> > why would you use backend = eps if you are generating a PNG file? I think
> > you can omit that.
> 
> The auto-cropping features only work with the EPS backend which can also be
> used to generate PNG or PDF output. 
> Making use of 
> \include "lilypond-book-preamble.ly"
> has the same effect.
> 
> 
> Renato-23 wrote
> > How can I produce a png with some nonzero margins? I've tried to add
> > top-margin, bottom-margin, top-system-spacing, last-bottom-spacing,
> > left-margin, right-margin, paper-width, but none of them seem to work
> 
> I'm afraid that it won't work out of the box. The cropping seems to take
> place after the image is composed and doesn't care about margin or indent
> settings. 
> My only idea would be to place invisible stuff around like, 
> \set Staff.instrumentName = \markup \with-color #white "X"
> but I don't think this will result in a usable workflow.

I tried lilypond-book last year and IIRC it even does things like
stripping off the opus from the top system and reassembling the
cropped fragments itself, so workarounds like this might not work
in any case.

> Maybe it's easier to add margins with an image editor that has automatic
> batch processing like IrfanView.

Cheers,
David.

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

Re: cross-voice ties and merging noteheads

[Orm Finnendahl]

Am Samstag, den 25. Februar 2017 um 14:25:52 Uhr (+0100) schrieb Urs Liska:
> An image would be helpful to avoid misunderstandings.

 attached. I tried to keep the file size small. Let me know if you
need it in better resolution.

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

Re: UTF-8 in MIDI Lyrics

[Joseph Austin]

> On Feb 24, 2017, at 7:47 AM, lilypond-user-requ...@gnu.org wrote:
> 
> Am 24.02.2017 um 02:15 schrieb Joseph Austin:
>> This raises another question.  I'm working with MIDI files,
>> and it's not clear how to encode UTF-8 text in MIDI.
>> There must be some convention, but I haven't found an official RP for it.
> 
> Personally, I have no idea. Does Lily not do it right?
> Best, Simon

I don't have a program that displays MIDI  files with lyrics, so I can't test 
it.
Both Finale and MuseScore accept LilyPond generated midi files but ignore the 
lyrics.

It appears that, when generating a MIDI file, LilyPond currently just puts UTF8 
chars in the text fields as if they were ASCII.
According the base MIDI spec, this is illegal;  only ASCII chars between 0 and 
127 are allowed.

However, MIDI RP-17 and RP-26 introduce additional encodings for the  
portion of the lyric meta-event FF 05  . In particular, RP-26 
specifies the "language" code  {@LATIN} to include 8-bit chars > 127.  It seems 
no code for "UTF8" has been officially defined, but a reasonable proposal might 
be language code: {@UTF8}.
It's my impression that the largest body of MIDI files with lyrics are 
"Karaoke" files (extension .kar),
which may not be of interest to LilyPond.

I suppose that interest in using MIDI as a "score" language has waned in favor 
of MusicXML.
So for LilyPond purposes, it would suffice to use a reversible encoding, that 
is, LilyPond would accept any MIDI file text format that LilyPond generates.  
The apparently existing UTF-8 default should work for that.
But if we are going to use a "private standard", we might as well imitate the 
"official" standard and insert something like
FF 05 07 { @ U T F 8 }
And lobby AMEI/MMA to adopt an official UTF8 position.

Joe Austin



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

Re: Png cropping

[SoundsFromSound]

renyhp wrote
> I read in the documentation that it is possible to create a cropped png by
> using "-dbackend=eps -dresolution=600 —png" and inserting this \paper
> block:
> 
> However, I think the cropping is too heavy. How can I produce a png with
> some nonzero margins? 

If you use Frescobaldi, you can save a PNG of a selected area of your score
by dragging and dropping it, it's pretty straight forward and I've had
success doing it in the past.

Perhaps that could help you?




-
composer | sound designer | asmr artist 
LilyPond Tutorials (for beginners) --> http://bit.ly/bcl-lilypond
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Png-cropping-tp200437p200451.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: cross-voice ties and merging noteheads

[Andrew Bernard]

Hi Orm,

Use voices. Here's a rough outline answer sketched out quickly, without
seeing the publication you refer to.

Basically you can only tie across notes in the same voice, so that clues
you in as to the way to set such music.

Andrew

== snip


\score {
  \new Staff \with { tieWaitForNote = ##t } {
\clef "bass"
\key e \major
\time 3/8

{
  <<
{
  \voiceOne
  e'4. ~ 4 s8 \stemDown
}
\new Voice
{
  \voiceTwo

  s4 b8 ^~ |
  \stemUp b4 \stemDown b,8 ^~ |
  \stemUp b,4. ^~ |
  b,4. |
}
\new Voice
{
  \voiceThree
  \shiftOff
  s4. |
  \once \override NoteColumn.ignore-collision = ##t
  e4. ^~ |
  e4. |
}
\new Voice
{
  \stemDown
  s4. |
  e4 s8 |
  e,4 b,,8 ^~ |
  b,,4. |
}
  >>
}
  }
}

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

Re: Png cropping

[Simon Albrecht]

Am 25.02.2017 um 12:01 schrieb renyhp:

It is a bit sad, though, that a so powerful tool like LilyPond can't adjust
some simple things like png output margins.


That’s not the best wording. LilyPond is a very powerful tool, because 
volunteers have invested their time and abilities to create solutions 
for what use cases they saw coming. IIUC, the PNG cropping has been 
designed for use with lilypond-book, at any rate the developers didn’t 
see any need for adjusting the margins. If you want to change it, you 
are very welcome to propose patches, or file a concise enhancement 
request with bug-lilyp...@gnu.org.
Certainly there are many (seemingly) small features missing from 
LilyPond’s toolset, but that’s no reason for any kind of accusations. 
Try rephrasing the sentence as ‘Wouldn’t it be great if there were some 
possibility to adjust margins with the PNG cropping mechanism?’ – that 
sounds a lot more appropriate.


Best, Simon

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

Re: cross-voice ties and merging noteheads

[Urs Liska]

Am 25. Februar 2017 13:33:54 MEZ schrieb Orm Finnendahl 
:
>Hi,
>
> in the example below (an excerpt of the left hand piano part of the
>Schumann Song "Mondnacht") I'd like to resemble the rendering of
>Clara Schumann's Edition in the Breitkopfärtel print.

An image would be helpful to avoid misunderstandings.

Urs

>
>%<
>\version "2.19.48"
>
>\score {
>  \new Staff \with { tieWaitForNote = ##t } {
>\clef "bass" \key e \major
>\time 3/8
>\relative f' {
>  <<
>{ e4. ~ 4 ~ s8 \stemDown e,,4 b8 ~ b4. }
>\\
>{ e''4.*2/3 b8 e,4 b8 ~ }
>\\
>{ s4.  \tieUp e4. ~ 4. ~  b4. }
>  >>
>}}}
>%<
>
>In the print,
>
>1. the noteheads of the e of the first beat in measure 2 are merged
>
>2. Both eigth note b on the third eigth of MM 1 and 2 are tied to the
>   first beat of the next measure.
>
>I managed to merge the first note in measure 1 by using a scaled
>dottet quarter in the second voice, but this doesn't seem to work if
>applied to simultaneous notes in voice 2 and 3.
>
>Any ideas?
>
>--
>Orm
>
>
>
>___
>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

cross-voice ties and merging noteheads

[Orm Finnendahl]

Hi,

 in the example below (an excerpt of the left hand piano part of the
Schumann Song "Mondnacht") I'd like to resemble the rendering of
Clara Schumann's Edition in the Breitkopfärtel print.

%<
\version "2.19.48"

\score {
  \new Staff \with { tieWaitForNote = ##t } {
\clef "bass" \key e \major
\time 3/8
\relative f' {
  <<
{ e4. ~ 4 ~ s8 \stemDown e,,4 b8 ~ b4. }
\\
{ e''4.*2/3 b8 e,4 b8 ~ }
\\
{ s4.  \tieUp e4. ~ 4. ~  b4. }
  >>
}}}
%<

In the print,

1. the noteheads of the e of the first beat in measure 2 are merged

2. Both eigth note b on the third eigth of MM 1 and 2 are tied to the
   first beat of the next measure.

I managed to merge the first note in measure 1 by using a scaled
dottet quarter in the second voice, but this doesn't seem to work if
applied to simultaneous notes in voice 2 and 3.

Any ideas?

--
Orm



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

Re: ghostscript fails on pdf generation

[N. Andrew Walsh]

Hi List,

so, I did some digging regarding this error I've been getting with pdf
output (see below). I found this note to lilypond-users from two years ago:
https://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00932.html

The money line is to comment out the last line of
/usr/share/ghostscript/[$GS_VERSION]/Resource/Init/Fontmap,
which reads:

(Fontmap.local) .runlibfileifexists

When I replaced that line with:
%(Fontmap.local) .runlibfileifexists

pdf output worked correctly with lilypond/frescobaldi.

Some further information:
Before this workaround, console output returned the following when running
the same command from console that was failing in frescobaldi:

$ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
-sOutputFile=lamento.pdf -c.setpdfwrite -f/tmp/lilypond-3iqFdT
GPL Ghostscript 9.20: Can't embed the complete font LinLibertineO as it is
too large, embedding a subset.
GPL Ghostscript 9.20: Can't embed the complete font LinLibertineOI as it is
too large, embedding a subset.
GPL Ghostscript 9.20: Can't embed the complete font LinLibertineOB as it is
too large, embedding a subset.
$

If, however, the intended output filename has whitespaces, I get the
following error:

 $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
-sOutputFile=Reinhold Urmetzer - Lamento di Achille.pdf -c.setpdfwrite
-f/tmp/lilypond-DDb0P7
Error: /undefinedfilename in (Urmetzer)
Operand stack:

Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
--nostringval--   false   1   %stopped_push
Dictionary stack:
   --dict:1211/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.20: Unrecoverable error, exit code 1
$

So, to review:
if the filename has spaces, gs output will fail both in frescobaldi and
from console
if the filename does not have spaces, output fails in frescobaldi, and also
running lilypond from console, but not running the last 'gs' command from
console
if that last line about Fontmap.local is commented out
in /usr/share/ghostscript/[$GS_VERSION]/Resource/Init/Fontmap, pdf output
works in both console and frescobaldi.

So, is this a bug/defect somewhere in frescobaldi/lilypond/ghostscript? If
so, which?

Cheers,

A

On Wed, Feb 15, 2017 at 2:15 PM, Wols Lists 
wrote:

> On 13/02/17 15:23, David Wright wrote:
> >> It seems daft to me that you need "w" permissions, and I haven't
> >> > experimented deeply with it, but if I have access to a file, why
> >> > shouldn't I be able to create a link to it?
> > Because it's a security risk. Geriatric unixers might wonder why their
> > suid scripts no longer work: similar reasons.
> >
> > https://lwn.net/Articles/502621/
> >
> Thank you very much indeed. I've relaxed hardlink security on my machine
> (well, hopefully next time I boot), and starred your email for reference
> :-)
>
> Cheers,
> Wol
>
> ___
> 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: Png cropping

[renyhp]

Hi,
Thank you for your answers. I am actually programming something automated (a
Telegram bot for LilyPond! If you are on Telegram you will find it at
@lilypondbot), so probably the best option will be to discard using
LilyPond's cropping feature and try to find another way to crop it myself.
It is a bit sad, though, that a so powerful tool like LilyPond can't adjust
some simple things like png output margins.
Best regards,
  Renato



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Png-cropping-tp200437p200445.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: [ANN] LilyQuick 0.9beta - fast accurate Lilypond MIDI note entry for Linux

[Johan Vromans]

On Sat, 25 Feb 2017 10:33:11 +1100, Vaughan McAlley
 wrote:

> Maybe your keyboard is interpreting F8 as something else rather than
> the function key proper.

It seems that lq isn't intercepting keystrokes at all. After uncommenting
line 341 nothing is printed:

$ sudo ./lq
Password:
Welcome to LilyQuick version 0.9β
Press F8 and a key on the MIDI keyboard to exit.
[1] 12613
^[[19~^[[19~^[[19~^[[19~^C

F8 generates ^[[19~ which is just echoed.

-- Johan

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

Re: Png cropping

[Klaus Blum]

Hi Renato, hi Andrew,

Andrew Bernard wrote
> why would you use backend = eps if you are generating a PNG file? I think
> you can omit that.

The auto-cropping features only work with the EPS backend which can also be
used to generate PNG or PDF output. 
Making use of 
\include "lilypond-book-preamble.ly"
has the same effect.


Renato-23 wrote
> How can I produce a png with some nonzero margins? I've tried to add
> top-margin, bottom-margin, top-system-spacing, last-bottom-spacing,
> left-margin, right-margin, paper-width, but none of them seem to work

I'm afraid that it won't work out of the box. The cropping seems to take
place after the image is composed and doesn't care about margin or indent
settings. 
My only idea would be to place invisible stuff around like, 
\set Staff.instrumentName = \markup \with-color #white "X"
but I don't think this will result in a usable workflow.

Maybe it's easier to add margins with an image editor that has automatic
batch processing like IrfanView.


Cheers, 
Klaus






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Png-cropping-tp200437p200441.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