Re: Natural marked with a sharp symbol (mensural notation)

[Niols]

Hi Lukas,

On 25/07/2020 20:16, Lukas-Fabian Moser wrote:
I stumbled upon a score in G minor where a E natural would be marked 
as a E note preceded by a sharp symbol. What would be a “clean” way to 
achieve that?


I have thought of redefining the natural symbol by the sharp one, but:

  1. I don't know how to do this.

  2. This would not work in an other key signature with sharps where, I
 assume, the natural would be marked with flat symbols.


Perhaps:

\version "2.20.0"

forceSharp =
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text ##{ \markup { \sharp } #}
\etc

forceFlat =
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text ##{ \markup { \flat } #}
\etc

\relative {
   \key f \major
   f' g a \forceSharp b
}

\relative {
   \key g \major
   a' g \forceFlat f e
}


I like this solution! And it made me discover a few new things, which is 
always great :-)



This probably has to be customized if you use mensural glyphs.


By playing with the documentation, I finally found out how to access the 
mensural glyphs, and a mensural version of your suggestion could be:


forceSharp =
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text ##{ \markup { \musicglyph "accidentals.mensural1" 
} #}

\etc

forceFlat =
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text ##{ \markup { \musicglyph 
"accidentals.mensural-1" } #}

\etc

---

Now I also looked into the sources for the definition of the "alteration 
mensural glyph name alist" and found this:


(define-public alteration-mensural-glyph-name-alist
  '((-1/2 . "accidentals.mensuralM1")
(0 . "accidentals.vaticana0")
(1/2 . "accidentals.mensural1")))

and this allowed me to define two variations, one that replaces the 
natural by the flat, and one that replaces it by the sharp. They can 
then be used accordingly:


\version "2.20.0"

#(define-public alteration-mensural-natural-as-sharp-glyph-name-alist
  '((-1/2 . "accidentals.mensuralM1")
(0. "accidentals.mensural1")
(1/2  . "accidentals.mensural1")))

#(define-public alteration-mensural-natural-as-flat-glyph-name-alist
  '((-1/2 . "accidentals.mensuralM1")
(0. "accidentals.mensuralM1")
(1/2  . "accidentals.mensural1")))

\relative {
  \key f \major
  \override Staff.Accidental.glyph-name-alist = 
#alteration-mensural-natural-as-sharp-glyph-name-alist

  f' g a b b
}

\relative {
  \key g \major
  \override Staff.Accidental.glyph-name-alist = 
#alteration-mensural-natural-as-flat-glyph-name-alist

  a' g f e f
}

---

I haven't found a clever way to do that while taking into account the 
key signature, but this sounds good enough for me. That gives us both a 
way to do it systematically, and a way to do it locally. I like having 
the choice.


Thanks a lot for your help!

Best,
— Niols

Re: Natural marked with a sharp symbol (mensural notation)

[Lukas-Fabian Moser]

Hi Niols,

I stumbled upon a score in G minor where a E natural would be marked 
as a E note preceded by a sharp symbol. What would be a “clean” way to 
achieve that?


I have thought of redefining the natural symbol by the sharp one, but:

  1. I don't know how to do this.

  2. This would not work in an other key signature with sharps where, I
 assume, the natural would be marked with flat symbols.


Perhaps:

\version "2.20.0"

forceSharp =
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text ##{ \markup { \sharp } #}
\etc

forceFlat =
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text ##{ \markup { \flat } #}
\etc

\relative {
  \key f \major
  f' g a \forceSharp b
}

\relative {
  \key g \major
  a' g \forceFlat f e
}

This probably has to be customized if you use mensural glyphs.

Best
Lukas

Natural marked with a sharp symbol (mensural notation)

[Niols]

Hello,

I stumbled upon a score in G minor where a E natural would be marked as 
a E note preceded by a sharp symbol. What would be a “clean” way to 
achieve that?


I have thought of redefining the natural symbol by the sharp one, but:

  1. I don't know how to do this.

  2. This would not work in an other key signature with sharps where, I
 assume, the natural would be marked with flat symbols.

I actually found something about this in the documentation here:


http://lilypond.org/doc/v2.19/Documentation/notation/typesetting-mensural-music#mensural-accidentals-and-key-signatures

It does say that the natural symbol does not exist really and that the 
sharp or flat is used more often. However, I could not see a clean way 
to say that I indeed wanted that.


As a bonus question, what if I wanted the sharp from the mensural 
accidentals to be bigger in my score (I find the default one really tiny).


Thank you so much in advance,
— Niols

RE: positioning a natural

[Mark Stephen Mrotek]

Malte Meyn,

Perfect! Thank you.
I am so fortunate to have people who can help me with the finer points of
Lilypond

Mark

-Original Message-
From: lilypond-user
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of
Malte Meyn
Sent: Thursday, January 02, 2020 10:59 PM
To: lilypond-user@gnu.org
Subject: Re: positioning a natural



Am 03.01.20 um 06:55 schrieb Mark Stephen Mrotek:
> Hello All,
> 
> In the following the natural should be associated with the a4.
> 
> Any suggestions/corrections welcome.

How about this?

\version "2.19.83"
\relative c'' {

   <<
 {
   ais8 ([b])
 } \\ {
   \once \override NoteColumn.force-hshift = #2.2
   \once \override Accidental.X-extent = #'(1 . 0)
   \once \override Accidental.extra-offset = #'(3 . 0)
   a!4
 }
   >>

}

Re: positioning a natural

[Malte Meyn]

Am 03.01.20 um 06:55 schrieb Mark Stephen Mrotek:

Hello All,

In the following the natural should be associated with the a4.

Any suggestions/corrections welcome.


How about this?

\version "2.19.83"
\relative c'' {

  <<
{
  ais8 ([b])
} \\ {
  \once \override NoteColumn.force-hshift = #2.2
  \once \override Accidental.X-extent = #'(1 . 0)
  \once \override Accidental.extra-offset = #'(3 . 0)
  a!4
}
  >>

}

positioning a natural

[Mark Stephen Mrotek]

Hello All,

 

In the following the natural should be associated with the a4.

Any suggestions/corrections welcome.

 

Thank you for your kind attention.

 

Mark

 

\version "2.19.83"

 

\relative c'' {

  <<{ais8 ([b])}\\

 {\once \override NoteColumn #'force-hshift = #1

 a!4}>>

}

Re: removing automatically generated natural signs

[Chris Jones]

On Sun, Dec 10, 2017 at 03:16:12PM EST, David Wright wrote:
> On Fri 08 Dec 2017 at 16:21:41 (-0500), Chris Jones wrote:
> > On Fri, Dec 08, 2017 at 02:22:32PM EST, Ben wrote:
> > > (
> > > On 12/8/2017 2:09 PM, Chris Jones wrote:

[..]

> This response seems to invite a brief explanation.
> 
> Your o.png image shows what your original score looks like. In it,
> the fourth note is an F#. It's printed in the F-space, but the #
> in the key signature on the F-line (top of staff) makes the note
> into an F#. That's the rôle of a key signature.
> 
> If you write fis in your LP source, the F# will print without any
> accidental because any note printed in the F-space has the key
> signature applied to it. Again, that's the rôle of the key signature.
> 
> If you write f in your LP source, you're specifying a different (and
> erroneous) note. LP now still prints the note in the F-space but has
> to override the key signature by printing a ♮ in front of it. That
> is what you are observing in the picture n.png (though you generated
> it differently).
> 
> So because the composer printed an F# key signature, and all the
> unadorned notes in and on the F-spaces/lines are the composed F#s,
> you need to write them all as fis in your LP source.
> 
> If you do that, the business of printing the music in G# boils
> down to adding "\transpose g gis" just once in the source.
> If you do anything with "\set Staff.extraNatural = #ff", you will
> get into an unholy mess which nobody, including yourself, will
> understand or be able to help you with.

Thank you for your explanation. It's all beginning to make sense now.

I like the way you spell "rôle".

I know French pretty well and it just dawned on me that "role" (as in
the insufferable "role model"...) that it was originally a French
import.

Thanks,

CJ

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

Re: removing automatically generated natural signs

[David Wright]

On Fri 08 Dec 2017 at 16:21:41 (-0500), Chris Jones wrote:
> On Fri, Dec 08, 2017 at 02:22:32PM EST, Ben wrote:
> > (
> > On 12/8/2017 2:09 PM, Chris Jones wrote:
> 
> [..]
> >
> > (from documentation)
> > "...
> > 
> > To determine whether to print an *accidental*, LilyPond examines the pitches
> > and the key signature. The key signature only affects the
> > */printed/***accidentals, not the note’s pitch!
> > 
> > --> This is a feature that often causes confusion to newcomers, so let us
> > explain it in more detail.
> > 
> > LilyPond makes a clear distinction between musical content and layout. The
> > alteration (flat, natural sign or sharp) of a note is part of the pitch, and
> > is therefore musical content. Whether an accidental (a */printed/***flat,
> > natural or sharp sign) is printed in front of the corresponding note*is a
> > question of layout*. Layout is something that follows rules, so accidentals
> > are printed automatically according to those rules. The pitches in your
> > music are works of art, so they will not be added automatically, and you
> > must enter what you want to hear."
> > 
> > 
> > Hope this helps :)
> 
> Indeed. 
> 
> But that is precisely the documentation I have been reading over and
> over without being able to quite understand the implications. 
> 
> And I think that my problem lies with the last word: "... hear". 
> 
> Since I am not a musician but a mere scribe when I am looking at sheet
> music... I do *not* hear anything. ;)
> 
> Moot point anyway... because in this particular instance my perspective
> is completely different.
> 
> I am putting together an epub with images... and some of the images
> happen to be the scores of a dozen songs, each one on a separate page. 
> 
> I initially tried to extract the images from the scanned PDF found
> online but no matter how hard I tried fiddling the resolution, boosting
> brightness & constrast, smoothing or sharpening... the end result was
> barely legible and well... just too ugly for words.
> 
> So I figured I would look for something that produces high quality sheet
> music output with the intention of creating a dozen .png images that
> I could easily add to the epub.
> 
> That's how I came across lilypond and after spending the weekend reading
> the documentation and experimenting I was able to come up with something
> quite satisfactory. (cf. note 1)
> 
> But since I am not a musician not by any stretch of the imagination...
> and therefore I do not understand whether any changes that creep in
> matter or not... I am trying to have my lilypond output reproduce the
> original as faithfully as possible. 
> 
> So now that I have reached the point where song #1 is almost ready there
> are still a couple of minor but nonetheless annoying issues that need to
> be addressed before I can move on to the remaining eleven.
> 
> And one of them is getting rid of these naturals that are not in the
> original. 
> 
> I do realize that it is quite possible that the original typesetting of
> the song is at best sloppy in this respect and that lilypond is right
> amending it. 
> 
> But that's not for me to decide.
> 
> Obviously rather than tampering with lilypond's output after the fact
> I would much rather find a way to force the software to reproduce
> the original score down to every detail. 
> 
> Anyway, sorry for the lenghty explanation but since this mailing list
> appears to be mostly a haunt for the the music-savvy... I thought
> I might make it clear that I am not trying to emulate Ludwig Van or
> Johannes B. but rather the anonymous grease monkey in the printer's
> shop.

This response seems to invite a brief explanation.

Your o.png image shows what your original score looks like. In it,
the fourth note is an F#. It's printed in the F-space, but the #
in the key signature on the F-line (top of staff) makes the note
into an F#. That's the rôle of a key signature.

If you write fis in your LP source, the F# will print without any
accidental because any note printed in the F-space has the key
signature applied to it. Again, that's the rôle of the key signature.

If you write f in your LP source, you're specifying a different (and
erroneous) note. LP now still prints the note in the F-space but has
to override the key signature by printing a ♮ in front of it. That
is what you are observing in the picture n.png (though you generated
it differently).

So because the composer printed an F# key signature, and all the
unadorned notes in and on the F-spaces/lines are the composed F#s,
you need to write them all as fis in your LP source.

If you do that, the business of printing the 

Re: removing automatically generated natural signs

[Simon Albrecht]

On 08.12.2017 23:18, Chris Jones wrote:

As a matter of fact without being an expert I have great respect for
quality typesetting, past and present... paper-oriented or digital.


Quality typesetting requires some degree of understanding about what you 
are typesetting; so if you’re going to do quality music engraving, 
you’ll need a decent understanding of music theory. LilyPond is designed 
to allow your typesetting solutions to be in line with how the music works.


Best, Simon

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

Re: removing automatically generated natural signs

[Chris Jones]

On Fri, Dec 08, 2017 at 04:40:51PM EST, David Kastrup wrote:
> Chris Jones  writes:
> 
[..]
> 
> Don't underestinmate the anonymous grease monkeys in printers' shops.

Far from my intention I can assure you.

As a matter of fact without being an expert I have great respect for
quality typesetting, past and present... paper-oriented or digital.

And that is precisely the reason I am currently looking at epub's
capabilities and so far I have not come across anything that I like.

Thanks,

CJ

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

Re: removing automatically generated natural signs

[Chris Jones]

On Fri, Dec 08, 2017 at 03:30:00PM EST, Simon Albrecht wrote:
> On 08.12.2017 20:09, Chris Jones wrote:
> > Wouldn't this become rather painful/tedious if the gentleman who wrote
> > this particular song had had the bright idea of transposing it to
> > a fancier key like... G# major for instance?
> > 
> > If that were the case I would have to add an "is" to just about every
> > single note in the score!
> 
> You could use e.g. english note names if it’s only about the typing: that
> saves you one keystroke per flat/sharp/doublesharp.
> 

I can type reasonably fast... much faster than I can think, anyway.

I made the decision to stick with the Dutch [is/es] because with two
letters I find it easier to spot the accidentals.

The reason behind this is that a beginner like myself is likely to spend
far more time reading what he typed over and over in order to fix
mistakes than typing.

So I decided I might as well stick with a notation that is a bit less
cryptic than the [b,s] English form. 

The extra letter helps make the accidentals stand out.

Thanks,

CJ

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

Re: removing automatically generated natural signs

[David Kastrup]

Chris Jones  writes:

> But that is precisely the documentation I have been reading over and
> over without being able to quite understand the implications. 
>
> And I think that my problem lies with the last word: "... hear". 
>
> Since I am not a musician but a mere scribe when I am looking at sheet
> music... I do *not* hear anything. ;)

LilyPond can be easily made to produce Midi files which one can replay
proper software.  It's probably a good idea to "proofhear" your
rendition in order to figure out whether it sounds sensible.

The problem with not spelling notes out properly but merely copying
their visuals is that this is not robust against a whole number of
modifications (like a canon shifted by half a measure), that it is a
nightmare to change the notation conventions, that copy does not
work musically.

> But since I am not a musician not by any stretch of the imagination...
> and therefore I do not understand whether any changes that creep in
> matter or not... I am trying to have my lilypond output reproduce the
> original as faithfully as possible.
>
> So now that I have reached the point where song #1 is almost ready
> there are still a couple of minor but nonetheless annoying issues that
> need to be addressed before I can move on to the remaining eleven.
>
> And one of them is getting rid of these naturals that are not in the
> original.

They will likely disappear when using the "correct" note names.  The
problem with wanting to use LilyPond only as a musical typewriter is
that LilyPond takes care of a number of fine points of typesetting that
just depend on more than a superficial understanding of the content.
For example, there are accidentals that only appear right after a line
break but are otherwise removed.  So the output depends on line break
decisions.

> Obviously rather than tampering with lilypond's output after the fact
> I would much rather find a way to force the software to reproduce the
> original score down to every detail.
>
> Anyway, sorry for the lenghty explanation but since this mailing list
> appears to be mostly a haunt for the the music-savvy... I thought I
> might make it clear that I am not trying to emulate Ludwig Van or
> Johannes B. but rather the anonymous grease monkey in the printer's
> shop.

Don't underestinmate the anonymous grease monkeys in printers' shops.

Sorry for your pains.  Unfortunately, I cannot really think of a way to
make this more to your liking in a manner that would not become even
more prone to problems.

-- 
David Kastrup

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

Re: removing automatically generated natural signs

[Chris Jones]

On Fri, Dec 08, 2017 at 03:23:35PM EST, Noeck wrote:
> Hi,
> 
> this isa bad hack I would not recommend, but you *could* revert the key
> back to c major without showing it:
> 
> \relative {
>   \key g \major
>   c'
>   \once \omit Staff.KeyCancellation
>   \key c \major
>   d e f g a b c
> }
> 
> Midi, transposition etc. will be broken, of course.

Indeed. Never shy of an ugly hack... I was vaguely contemplating
something along these lines. ;)

Thanks,

CJ

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

Re: removing automatically generated natural signs

[Chris Jones]

On Fri, Dec 08, 2017 at 02:22:32PM EST, Ben wrote:
> (
> On 12/8/2017 2:09 PM, Chris Jones wrote:

[..]
>
> (from documentation)
> "...
> 
> To determine whether to print an *accidental*, LilyPond examines the pitches
> and the key signature. The key signature only affects the
> */printed/***accidentals, not the note’s pitch!
> 
> --> This is a feature that often causes confusion to newcomers, so let us
> explain it in more detail.
> 
> LilyPond makes a clear distinction between musical content and layout. The
> alteration (flat, natural sign or sharp) of a note is part of the pitch, and
> is therefore musical content. Whether an accidental (a */printed/***flat,
> natural or sharp sign) is printed in front of the corresponding note*is a
> question of layout*. Layout is something that follows rules, so accidentals
> are printed automatically according to those rules. The pitches in your
> music are works of art, so they will not be added automatically, and you
> must enter what you want to hear."
> 
> 
> Hope this helps :)

Indeed. 

But that is precisely the documentation I have been reading over and
over without being able to quite understand the implications. 

And I think that my problem lies with the last word: "... hear". 

Since I am not a musician but a mere scribe when I am looking at sheet
music... I do *not* hear anything. ;)

Moot point anyway... because in this particular instance my perspective
is completely different.

I am putting together an epub with images... and some of the images
happen to be the scores of a dozen songs, each one on a separate page. 

I initially tried to extract the images from the scanned PDF found
online but no matter how hard I tried fiddling the resolution, boosting
brightness & constrast, smoothing or sharpening... the end result was
barely legible and well... just too ugly for words.

So I figured I would look for something that produces high quality sheet
music output with the intention of creating a dozen .png images that
I could easily add to the epub.

That's how I came across lilypond and after spending the weekend reading
the documentation and experimenting I was able to come up with something
quite satisfactory. (cf. note 1)

But since I am not a musician not by any stretch of the imagination...
and therefore I do not understand whether any changes that creep in
matter or not... I am trying to have my lilypond output reproduce the
original as faithfully as possible. 

So now that I have reached the point where song #1 is almost ready there
are still a couple of minor but nonetheless annoying issues that need to
be addressed before I can move on to the remaining eleven.

And one of them is getting rid of these naturals that are not in the
original. 

I do realize that it is quite possible that the original typesetting of
the song is at best sloppy in this respect and that lilypond is right
amending it. 

But that's not for me to decide.

Obviously rather than tampering with lilypond's output after the fact
I would much rather find a way to force the software to reproduce
the original score down to every detail. 

Anyway, sorry for the lenghty explanation but since this mailing list
appears to be mostly a haunt for the the music-savvy... I thought
I might make it clear that I am not trying to emulate Ludwig Van or
Johannes B. but rather the anonymous grease monkey in the printer's
shop.

Thanks,

CJ

1. The rendering of my first .png on a 7" ~300 dpi android tablet is
   absolutely gorgeous... looks as good as high quality sheet music you
   could buy from the store.

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

Re: removing automatically generated natural signs

[Simon Albrecht]

On 08.12.2017 20:58, Urs Liska wrote:

I think this is a great way to explain this concept. And I also belong to the 
party of those who want to write down (encode) what it*is*  and not what it 
looks like.


However, sometimes in ancient music accidentals are _not_ part of the 
actual content, but truly up to the performer. In that case I’d 
sometimes like to code a pitch with ‘neutral’ accidental and add the -is 
or -es as part of the presentation.


Best, Simon

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

Re: removing automatically generated natural signs

[Simon Albrecht]

On 08.12.2017 20:09, Chris Jones wrote:

Wouldn't this become rather painful/tedious if the gentleman who wrote
this particular song had had the bright idea of transposing it to
a fancier key like... G# major for instance?

If that were the case I would have to add an "is" to just about every
single note in the score!


You could use e.g. english note names if it’s only about the typing: 
that saves you one keystroke per flat/sharp/doublesharp.



Best, Simon

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

Re: removing automatically generated natural signs

[Noeck]

Hi,

this isa bad hack I would not recommend, but you *could* revert the key
back to c major without showing it:

\relative {
  \key g \major
  c'
  \once \omit Staff.KeyCancellation
  \key c \major
  d e f g a b c
}

Midi, transposition etc. will be broken, of course.

Cheers,
Joram

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

Re: removing automatically generated natural signs

[Urs Liska]

Am 8. Dezember 2017 21:06:05 MEZ schrieb Ben <soundsfromso...@gmail.com>:
>On 12/8/2017 2:58 PM, Urs Liska wrote:
>>
>>> (from documentation)
>>> "...
>>>
>>> To determine whether to print an *accidental*, LilyPond examines the
>>> pitches and the key signature. The key signature only affects the
>>> */printed/***accidentals, not the note’s pitch!
>>>
>>> --> This is a feature that often causes confusion to newcomers, so
>let
>>> us explain it in more detail.
>>>
>>> LilyPond makes a clear distinction between musical content and
>layout.
>>> The alteration (flat, natural sign or sharp) of a note is part of
>the
>>> pitch, and is therefore musical content. Whether an accidental (a
>>> */printed/***flat, natural or sharp sign) is printed in front of the
>>> corresponding note*is a question of layout*.
>> But to be fair one should note that there are serious encoding
>systems out there that work like the OP expects, for example the MEI
>encoding format or the Amadeus notation software.
>>
>
>I didn't think Amadeus was still being developed...?

It isn't but there still are a handful og users still around who had invested 
enormous amounts of money back in thr eighties ;-)
It seems the original developer is still alive snd can be talked into fixing 
small items occasionally.

Urs

>
>> When I discussed the topic with an Amadeus power user he said that he
>would go nuts with all the typing (of the extra is and es) with the
>thousands of pages of music he has to create every year.
>
>I went nuts typing with SCORE for years but looking back, it built 
>character I say :)
>
>> MEI on the other hand wants to encode "what is on the paper", that
>is: an "a" for any pitch on that step.  However, I don't accept that
>because that a flat in e flat major is *not* printed as an "a" that
>becomes an a flat through the key signature. Actually it's a note head
>in the second space that becomes an a through the treble clef and only
>then an a flat.
>>
>> Urs
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: removing automatically generated natural signs

[Kieren MacMillan]

Urs,

> But to be fair one should note that there are serious encoding systems out 
> there that work like the OP expects, for example the MEI encoding format or 
> the Amadeus notation software. 
> When I discussed the topic with an Amadeus power user he said that he would 
> go nuts with all the typing (of the extra is and es) with the thousands of 
> pages of music he has to create every year.
> MEI on the other hand wants to encode "what is on the paper", that is: an "a" 
> for any pitch on that step.  However, I don't accept that because that a flat 
> in e flat major is *not* printed as an "a" that becomes an a flat through the 
> key signature. Actually it's a note head in the second space that becomes an 
> a through the treble clef and only then an a flat.

There is no reason one can't code some syntactic sugar to make it work “as 
expected” (i.e., without "all the 'extra' typing") in Lilypond as well.
I just don't think it's a great idea.  =)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: removing automatically generated natural signs

[Ben]

On 12/8/2017 2:58 PM, Urs Liska wrote:



(from documentation)
"...

To determine whether to print an *accidental*, LilyPond examines the
pitches and the key signature. The key signature only affects the
*/printed/***accidentals, not the note’s pitch!

--> This is a feature that often causes confusion to newcomers, so let
us explain it in more detail.

LilyPond makes a clear distinction between musical content and layout.
The alteration (flat, natural sign or sharp) of a note is part of the
pitch, and is therefore musical content. Whether an accidental (a
*/printed/***flat, natural or sharp sign) is printed in front of the
corresponding note*is a question of layout*.

But to be fair one should note that there are serious encoding systems out 
there that work like the OP expects, for example the MEI encoding format or the 
Amadeus notation software.



I didn't think Amadeus was still being developed...?


When I discussed the topic with an Amadeus power user he said that he would go 
nuts with all the typing (of the extra is and es) with the thousands of pages 
of music he has to create every year.


I went nuts typing with SCORE for years but looking back, it built 
character I say :)



MEI on the other hand wants to encode "what is on the paper", that is: an "a" for any 
pitch on that step.  However, I don't accept that because that a flat in e flat major is *not* printed as an 
"a" that becomes an a flat through the key signature. Actually it's a note head in the second space 
that becomes an a through the treble clef and only then an a flat.

Urs



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

Re: removing automatically generated natural signs

[Urs Liska]

Am 8. Dezember 2017 20:22:32 MEZ schrieb Ben <soundsfromso...@gmail.com>:
>(
>On 12/8/2017 2:09 PM, Chris Jones wrote:
>> I would need some help removing the autmatically generated natural
>signs
>> that I see in lilypond's output.
>>
>> |   melody = \relative c {
>> | \global
>> |   \partial 16 d'16 \bar "||"
>> |   \set melismaBusyProperties = #'()
>> |   \autoBeamOff
>> |   \set Staff.extraNatural = ##f
>> |   g4.. g16 f8. g16 a8. g16|   % b01
>>
>> ... expecting to see output with no accidentals.
>
>See below.
>
>>
>> Obvious workaround is coding "fis8l." instead of "f8." to get rid of
>> that extra natural sign:
>
>Yes. This is correct. It's one of the great things about LilyPond in my
>
>opinion. (how it works semantically, etc)
>
>>
>> |   g4.. g16 fis8. g16 a8. g16  |   % b01
>>
>> ... and remember to do the same for every "F" in my .ly file.
>>
>> I have read the section entitled "Warning: key signatures and
>pitches"
>> in the lilypond learning manual at least a dozen times and I still
>don't
>> see why I would need to do that.
>>
>> Wouldn't this become rather painful/tedious if the gentleman who
>wrote
>> this particular song had had the bright idea of transposing it to
>> a fancier key like... G# major for instance?
>>
>> If that were the case I would have to add an "is" to just about every
>> single note in the score!
>>
>>
>
>(from documentation)
>"...
>
>To determine whether to print an *accidental*, LilyPond examines the 
>pitches and the key signature. The key signature only affects the 
>*/printed/***accidentals, not the note’s pitch!
>
>--> This is a feature that often causes confusion to newcomers, so let 
>us explain it in more detail.
>
>LilyPond makes a clear distinction between musical content and layout. 
>The alteration (flat, natural sign or sharp) of a note is part of the 
>pitch, and is therefore musical content. Whether an accidental (a 
>*/printed/***flat, natural or sharp sign) is printed in front of the 
>corresponding note*is a question of layout*. Layout is something that 
>follows rules, so accidentals are printed automatically according to 
>those rules. The pitches in your music are works of art, so they will 
>not be added automatically, and you must enter what you want to hear."
>
>
>Hope this helps :)

I think this is a great way to explain this concept. And I also belong to the 
party of those who want to write down (encode) what it *is* and not what it 
looks like.

But to be fair one should note that there are serious encoding systems out 
there that work like the OP expects, for example the MEI encoding format or the 
Amadeus notation software. 

When I discussed the topic with an Amadeus power user he said that he would go 
nuts with all the typing (of the extra is and es) with the thousands of pages 
of music he has to create every year.

MEI on the other hand wants to encode "what is on the paper", that is: an "a" 
for any pitch on that step.  However, I don't accept that because that a flat 
in e flat major is *not* printed as an "a" that becomes an a flat through the 
key signature. Actually it's a note head in the second space that becomes an a 
through the treble clef and only then an a flat.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: removing automatically generated natural signs

[David Wright]

On Fri 08 Dec 2017 at 14:09:31 (-0500), Chris Jones wrote:
> I would need some help removing the autmatically generated natural signs
> that I see in lilypond's output.
> 
> I coded this:
> 
> |   global = {
> | \time 4/4
> | \key g \major
> | \tempo \markup { \concat {Mouv. \super t} de Marche}
> |   }
> |   
> |   #(set-global-staff-size 16.5)
> |   
> |   melody = \relative c {
> | \global
> |   \partial 16 d'16 \bar "||" 
> |   \set melismaBusyProperties = #'()
> |   \autoBeamOff
> |   \set Staff.extraNatural = ##f
> |   g4.. g16 f8. g16 a8. g16|   % b01
> 
> ... expecting to see output with no accidentals.
> 
> Now what happens is that lilypond adds a natural sign in front of the
> "f8"... thus changing the implied F# (key is G major) to an F... (?)

There is no "implied" F#. The \key specifies the key signature
to be printed. It has no effect on the pitches of following notes.

> Obvious workaround is coding "fis8l." instead of "f8." to get rid of
> that extra natural sign:

If the music contains an F#, you have to write fis.

> |   g4.. g16 fis8. g16 a8. g16  |   % b01
> 
> ... and remember to do the same for every "F" in my .ly file.
> 
> I have read the section entitled "Warning: key signatures and pitches"
> in the lilypond learning manual at least a dozen times and I still don't
> see why I would need to do that.

Well, you've found the correct section to read, but have
yet to understand its simplicity: for the musical pitch FOO,
write the note FOO into the LP file.

Cheers,
David.

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

Re: removing automatically generated natural signs

[Ben]

(
On 12/8/2017 2:09 PM, Chris Jones wrote:

I would need some help removing the autmatically generated natural signs
that I see in lilypond's output.

|   melody = \relative c {
| \global
|   \partial 16 d'16 \bar "||"
|   \set melismaBusyProperties = #'()
|   \autoBeamOff
|   \set Staff.extraNatural = ##f
|   g4.. g16 f8. g16 a8. g16|   % b01

... expecting to see output with no accidentals.


See below.



Obvious workaround is coding "fis8l." instead of "f8." to get rid of
that extra natural sign:


Yes. This is correct. It's one of the great things about LilyPond in my 
opinion. (how it works semantically, etc)




|   g4.. g16 fis8. g16 a8. g16  |   % b01

... and remember to do the same for every "F" in my .ly file.

I have read the section entitled "Warning: key signatures and pitches"
in the lilypond learning manual at least a dozen times and I still don't
see why I would need to do that.

Wouldn't this become rather painful/tedious if the gentleman who wrote
this particular song had had the bright idea of transposing it to
a fancier key like... G# major for instance?

If that were the case I would have to add an "is" to just about every
single note in the score!




(from documentation)
"...

To determine whether to print an *accidental*, LilyPond examines the 
pitches and the key signature. The key signature only affects the 
*/printed/***accidentals, not the note’s pitch!


--> This is a feature that often causes confusion to newcomers, so let 
us explain it in more detail.


LilyPond makes a clear distinction between musical content and layout. 
The alteration (flat, natural sign or sharp) of a note is part of the 
pitch, and is therefore musical content. Whether an accidental (a 
*/printed/***flat, natural or sharp sign) is printed in front of the 
corresponding note*is a question of layout*. Layout is something that 
follows rules, so accidentals are printed automatically according to 
those rules. The pitches in your music are works of art, so they will 
not be added automatically, and you must enter what you want to hear."



Hope this helps :)

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

Re: removing automatically generated natural signs

[Ben]

On 12/8/2017 2:09 PM, Chris Jones wrote:

I would need some help removing the autmatically generated natural signs
that I see in lilypond's output.

I coded this:

|   global = {
| \time 4/4
| \key g \major
| \tempo \markup { \concat {Mouv. \super t} de Marche}
|   }
|
|   #(set-global-staff-size 16.5)
|
|   melody = \relative c {
| \global
|   \partial 16 d'16 \bar "||"
|   \set melismaBusyProperties = #'()
|   \autoBeamOff
|   \set Staff.extraNatural = ##f
|   g4.. g16 f8. g16 a8. g16|   % b01

... expecting to see output with no accidentals.

Now what happens is that lilypond adds a natural sign in front of the
"f8"... thus changing the implied F# (key is G major) to an F... (?)

Obvious workaround is coding "fis8l." instead of "f8." to get rid of
that extra natural sign:

|   g4.. g16 fis8. g16 a8. g16  |   % b01

... and remember to do the same for every "F" in my .ly file.

I have read the section entitled "Warning: key signatures and pitches"
in the lilypond learning manual at least a dozen times and I still don't
see why I would need to do that.

Wouldn't this become rather painful/tedious if the gentleman who wrote
this particular song had had the bright idea of transposing it to
a fancier key like... G# major for instance?

If that were the case I would have to add an "is" to just about every
single note in the score!

This of course might be a non-issue e.g. for professional musicians who
think at a different level and hear what they are typing... but for
a mere "typesetter" like myself who has to make do with vague memories
of the very basics of music notation from his high school days this
could make life somewhat difficult...!

So... I initally looked for something that might let me globally
override this behavior via a single setting or command but I haven't
come across anything obvious.

As you can see above I tried adding a "\set Staff.extraNatural = #ff"
just in case--even though from what I read in the documentation it
didn't sound promising... but as I suspected this didn't help.

Is there any other way I could handle this?

Thanks,

CJ

PS. Attaching sample png's.



Sorry, I meant to say that *because *you're using that command ##f, the 
output should be as you have attached. :)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: removing automatically generated natural signs

[Ben]

On 12/8/2017 2:09 PM, Chris Jones wrote:

I would need some help removing the autmatically generated natural signs
that I see in lilypond's output.

I coded this:

|   global = {
| \time 4/4
| \key g \major
| \tempo \markup { \concat {Mouv. \super t} de Marche}
|   }
|
|   #(set-global-staff-size 16.5)
|
|   melody = \relative c {
| \global
|   \partial 16 d'16 \bar "||"
|   \set melismaBusyProperties = #'()
|   \autoBeamOff
|   \set Staff.extraNatural = ##f
|   g4.. g16 f8. g16 a8. g16|   % b01

... expecting to see output with no accidentals.


Not sure what version you're using in this project, but have you checked 
this page out? I believe it should help you. :)


http://lilypond.org/doc/v2.18/Documentation/notation/writing-pitches#accidentals


You can set extra naturals off easily in one command:

\set Staff.extraNatural = ##f


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

removing automatically generated natural signs

[Chris Jones]

I would need some help removing the autmatically generated natural signs
that I see in lilypond's output.

I coded this:

|   global = {
| \time 4/4
| \key g \major
| \tempo \markup { \concat {Mouv. \super t} de Marche}
|   }
|   
|   #(set-global-staff-size 16.5)
|   
|   melody = \relative c {
| \global
|   \partial 16 d'16 \bar "||" 
|   \set melismaBusyProperties = #'()
|   \autoBeamOff
|   \set Staff.extraNatural = ##f
|   g4.. g16 f8. g16 a8. g16|   % b01

... expecting to see output with no accidentals.

Now what happens is that lilypond adds a natural sign in front of the
"f8"... thus changing the implied F# (key is G major) to an F... (?)

Obvious workaround is coding "fis8l." instead of "f8." to get rid of
that extra natural sign:

|   g4.. g16 fis8. g16 a8. g16  |   % b01

... and remember to do the same for every "F" in my .ly file.

I have read the section entitled "Warning: key signatures and pitches"
in the lilypond learning manual at least a dozen times and I still don't
see why I would need to do that.

Wouldn't this become rather painful/tedious if the gentleman who wrote
this particular song had had the bright idea of transposing it to
a fancier key like... G# major for instance? 

If that were the case I would have to add an "is" to just about every
single note in the score! 

This of course might be a non-issue e.g. for professional musicians who
think at a different level and hear what they are typing... but for
a mere "typesetter" like myself who has to make do with vague memories
of the very basics of music notation from his high school days this
could make life somewhat difficult...!

So... I initally looked for something that might let me globally
override this behavior via a single setting or command but I haven't
come across anything obvious.

As you can see above I tried adding a "\set Staff.extraNatural = #ff"
just in case--even though from what I read in the documentation it
didn't sound promising... but as I suspected this didn't help. 

Is there any other way I could handle this?

Thanks,

CJ

PS. Attaching sample png's.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to fix bad overlap between normalsize and smaller note sharp, flat, natural?

[Pieter Terpstra]

Ben wrote:

> Which accidentals did you want to show, the larger one?
> You could just do a few overrides I think, like this:
> (see attached)
> 
> Is this what you meant?

Yes exactly as i was looking for, thank you so much Ben and have a nice day!

Peter


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

Re: How to fix bad overlap between normalsize and smaller note sharp, flat, natural?

[Ben]

On 10/21/2017 1:11 PM, Pieter Terpstra wrote:

Dear lilypond users,
How would you recommend to fix this?

Most kindly,

Peter

Have an example here:
\version "2.18.2"

\relative c'' {
\key gis \minor
\time 2/4
<<  {
% Voice "1"
\teeny
g16 ais b cis d e fis gis | eis, fis gis a eis!4
} \\ {
   % Voice "2"
   g4 d' | eis,4 eis!
} >>
}




Hello,

Which accidentals did you want to show, the larger one?
You could just do a few overrides I think, like this:
(see attached)

Is this what you meant?


\version "2.18.2"

\relative c'' {
\key gis \minor
\time 2/4
<<  {
   % Voice "1"
   \teeny
   \once \override Accidental #'stencil = ##f
   g16 ais b
   cis \once \override Accidental #'stencil = ##f
   d e fis gis
   \once \override Accidental #'stencil = ##f
   | eis, fis gis a \once \override Accidental #'stencil = ##f
   eis!4
   } \\ {
  % Voice "2"
  g4 d' | eis,4 eis!
   } >>
}


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

How to fix bad overlap between normalsize and smaller note sharp, flat, natural?

[Pieter Terpstra]

Dear lilypond users,
How would you recommend to fix this?

Most kindly,

   Peter

Have an example here:
\version "2.18.2"

\relative c'' {
\key gis \minor
\time 2/4
<<  { 
   % Voice "1"
   \teeny
   g16 ais b cis d e fis gis | eis, fis gis a eis!4
   } \\ {
  % Voice "2" 
  g4 d' | eis,4 eis!
   } >> 
}
   


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

Re: "natural width" of a measure

[Peter Crighton]

2017-04-11 22:34 GMT+02:00 David Nalesnik :

> Here's how you can determine the widths of measures.  Note that I've
> put everything on one line, so that the \once \override of the
> NoteHead gives access to every column in the score.  You can adjust
> what alignment objects are used to gauge width by changing the symbol
> in ly:paper-column::break-align-width (available as of 2.19.59).
> Right now, it's BreakAlignment objects to give you an extent
> considering all prefatory materials.  staff-bar would give extents of
> the bar lines.
>
> \version "2.19.59"
>
> \paper {
>   page-breaking = #ly:one-line-breaking
> }
>
> #(define (display-measure-widths grob)
>(let* ((sys (ly:grob-system grob))
>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>   (nmpcs
>(filter
> (lambda (elt)
>   (and (grob::has-interface elt 'paper-column-interface)
>(eq? #t (ly:grob-property elt 'non-musical
> cols))
>   (widths
>(map
> (lambda (c) (ly:paper-column::break-align-width c
> '(break-alignment)))
> nmpcs))
>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>   )
>  (pretty-print widths)))
> {
>
>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>   \repeat unfold 4 { c''8. c''16}
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> Hope this helps with something!
>
> David


Hello David et al.,

it surely has the potential of helping me with my current project. My
Scheme skills are still quite rudimentary, though, so I’m stuck for now.
Below you can find a stripped-down version of my chord chart template. I
need to offset all the notes and chords, apart from the first in a bar, to
the left; the exact offset values I want to calculate based on the length
of a measure. In the end, the distances between the notes should be the
same as the distance from the last note of a measure to the next bar line.
I think if I know the length of a measure and the position of each note, I
can work out a formula for that.

So, my questions are:
How can I display the positions (or extents) of notes, similar to what you
did with the extents of bar lines?
How can I access the x and y values of your function outside of that
function?
Both seem to me not that difficult, but I couldn’t find the solution for
now …


\version "2.19.47"

#(define (display-measure-widths grob)
   (let* ((sys (ly:grob-system grob))
  (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
  (nmpcs
   (filter
(lambda (elt)
  (and (grob::has-interface elt 'paper-column-interface)
   (eq? #t (ly:grob-property elt 'non-musical
cols))
  (widths
   (map
(lambda (c) (ly:generic-bound-extent c sys))
nmpcs))
  (widths (sort widths (lambda (x y) (< (car x) (car y)
  )
 (pretty-print widths)))

<<
  \new Voice {
\once \override NoteHead.after-line-breaking = #display-measure-widths
\repeat unfold 4 {
  4 4 4 4
}
  }

  \new ChordNames \chordmode {
\repeat unfold 4 {
  c2 c
}
  }
>>

\layout {
  \context {
\ChordNames
\consists "Bar_engraver"
\consists "Time_signature_engraver"
\numericTimeSignature

\override ChordName.Y-extent = ##f
\override ChordName.Y-offset = #-0.9
\override ChordName.X-offset = #1

\override BarLine.bar-extent = #'(-2 . 2)
  }

  \context {
\Staff
\remove "Time_signature_engraver"

\override Clef.stencil = #point-stencil
\hide BarLine
\override StaffSymbol.line-count = #0

\override NoteColumn.X-offset = #1
  }

  \context {
\Voice
\consists "Pitch_squash_engraver"
\improvisationOn
\stemUp
fontSize = #-4
  }

  \context {
\Score
\override BarNumber.stencil = #point-stencil

\override Clef.space-alist.first-note = #'(fixed-space . 0)
\override Clef.space-alist.time-signature = #'(extra-space . -2)

proportionalNotationDuration = #(ly:make-moment 1/2)
\override SpacingSpanner.uniform-stretching = ##t
\override SpacingSpanner.strict-note-spacing = ##t

\override NonMusicalPaperColumn.padding = #0
  }
}

\paper {
  indent = 0
  ragged-right = ##f
}


Thanks,
Peter

--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

[Urs Liska]

Am 14. April 2017 16:04:31 MESZ schrieb David Nalesnik 
<david.nales...@gmail.com>:
>On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <u...@openlilylib.org> wrote:
>>
>>
>> Am 13.04.2017 um 16:48 schrieb David Nalesnik:
>>> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org>
>wrote:
>>>>
>>>> Am 11.04.2017 um 21:04 schrieb tisimst:
>>>>
>>>>
>>>>
>>>> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden
>email]>
>>>> wrote:
>>>>>
>>>>>
>>>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>>>>>> So, is there any moment in the compilation process where the
>natural,
>>>>>>> unstretched length of a measure can be calculated? It doesn't
>have to
>>>>>>> be
>>>>>>> an easily-read property and can involve calculation, but
>actually the x
>>>>>>> position of the barlines would be an easy target - *if* there's
>this
>>>>>>> magic moment in the compilation pipeline ;-)
>>>>>> Maybe you could experiment with the ly:one-line-breaking?
>>>>> I don't think so (only, of course, to investigate how much can be
>done
>>>>> on the internal level).
>>>>> Basically what I'm after is a ly:cheap-line-breaking mode that
>doesn't
>>>>> care at all about overall appearance or good page turns but
>instead
>>>>> simply places as many measures in a line as fit naturally. If then
>a
>>>>> line break changes and I know the natural width of the measures I
>can
>>>>> determine before compilation how many measures will fit on the
>*next*
>>>>> system.
>>> But given clefs, key signatures, cautionaries, doesn't this mean
>that
>>> you need to know the width of any measure as the first measure of
>the
>>> line, as the last measure on a line, at a median position?
>>
>> Ah yes, this is true. But I guess we could do with some estimates
>here
>> (see below).
>>
>>>
>>> I'm not clear on the need to know how many measures will fit on
>>> subsequent lines before compilation.  Is it so that you can compile
>by
>>> system?
>>>
>>> (Just trying to get a handle on your goals so I can help better.)
>>
>> Yes, you're right. I'm not going to tackle this right now, but I have
>to
>> think about it for writing some plans.
>> I'm thinking about a "music entry mode" where I don't care at all
>about
>> "good" line and page breaking, so music can just be engraved like
>Word
>> "justifies" paragraphs - just fill the line and then go to the next.
>
>Doesn't ly:minimal-breaking already do this?  It might try out
>different line configurations -- I'm not entirely sure -- but looks
>pretty stripped down.

I'll have a look into that, but it's of course only half of the equation.

>
>>
>> Given that the music is available in a measure-by-measure state and
>> given that it is available in a parsed state from a LilyPond server
>> (both of which I hope to achieve one day) this would mean that I can
>> simply recompile the "current" system as long as the changed don't
>> require a change in line breaking. Only then I'd have to recompile
>the
>> next system as well, and then the next if the changed lines requires
>> this. I could do this sequentially, so the score would also update
>> incrementally without having to wait for the full compilation. But if
>I
>> knew the natural width of each existing measure I could perform the
>> calculations up front and decide which system should contain which
>> measures. In that case one could even have the systems be engraved in
>> parallel.
>> If any of these subsequent system fails because the measures don't
>fit
>> on it (BTW some help could be available by LilyPond's ability to
>squeeze
>> the system a bit) the parallel engraving could be stopped and
>restarted
>> in the incremental fashion.
>
>OK, I understand.  This would be a great selling point..
>
>Possibly related: have you considered the page/scroll view option from
>*ahem* Finale?  (In scroll view, of course, all music is on a single
>line, whereas page view presents pages roughly as they will be
>engraved.)

That was the first I used as notation interface, back with Finale 2001.
That would be an option as well, with just one system in the window. For a main 

Re: "natural width" of a measure

[David Nalesnik]

On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <u...@openlilylib.org> wrote:
>
>
> Am 13.04.2017 um 16:48 schrieb David Nalesnik:
>> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> wrote:
>>>
>>> Am 11.04.2017 um 21:04 schrieb tisimst:
>>>
>>>
>>>
>>> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>>>>> So, is there any moment in the compilation process where the natural,
>>>>>> unstretched length of a measure can be calculated? It doesn't have to
>>>>>> be
>>>>>> an easily-read property and can involve calculation, but actually the x
>>>>>> position of the barlines would be an easy target - *if* there's this
>>>>>> magic moment in the compilation pipeline ;-)
>>>>> Maybe you could experiment with the ly:one-line-breaking?
>>>> I don't think so (only, of course, to investigate how much can be done
>>>> on the internal level).
>>>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>>>> care at all about overall appearance or good page turns but instead
>>>> simply places as many measures in a line as fit naturally. If then a
>>>> line break changes and I know the natural width of the measures I can
>>>> determine before compilation how many measures will fit on the *next*
>>>> system.
>> But given clefs, key signatures, cautionaries, doesn't this mean that
>> you need to know the width of any measure as the first measure of the
>> line, as the last measure on a line, at a median position?
>
> Ah yes, this is true. But I guess we could do with some estimates here
> (see below).
>
>>
>> I'm not clear on the need to know how many measures will fit on
>> subsequent lines before compilation.  Is it so that you can compile by
>> system?
>>
>> (Just trying to get a handle on your goals so I can help better.)
>
> Yes, you're right. I'm not going to tackle this right now, but I have to
> think about it for writing some plans.
> I'm thinking about a "music entry mode" where I don't care at all about
> "good" line and page breaking, so music can just be engraved like Word
> "justifies" paragraphs - just fill the line and then go to the next.

Doesn't ly:minimal-breaking already do this?  It might try out
different line configurations -- I'm not entirely sure -- but looks
pretty stripped down.

>
> Given that the music is available in a measure-by-measure state and
> given that it is available in a parsed state from a LilyPond server
> (both of which I hope to achieve one day) this would mean that I can
> simply recompile the "current" system as long as the changed don't
> require a change in line breaking. Only then I'd have to recompile the
> next system as well, and then the next if the changed lines requires
> this. I could do this sequentially, so the score would also update
> incrementally without having to wait for the full compilation. But if I
> knew the natural width of each existing measure I could perform the
> calculations up front and decide which system should contain which
> measures. In that case one could even have the systems be engraved in
> parallel.
> If any of these subsequent system fails because the measures don't fit
> on it (BTW some help could be available by LilyPond's ability to squeeze
> the system a bit) the parallel engraving could be stopped and restarted
> in the incremental fashion.

OK, I understand.  This would be a great selling point..

Possibly related: have you considered the page/scroll view option from
*ahem* Finale?  (In scroll view, of course, all music is on a single
line, whereas page view presents pages roughly as they will be
engraved.)

About "natural measure widths": I'm still poking around, hoping that
you wouldn't need to run a copy of various structures through the
page/line breaking algorithms.

>
> Urs
>
> PS: Still, I haven't found the opportunity to install the latest version
> to test your suggestions.
>

Oh, I just added the latest bell-and-whistle assuming that you're
always at the forefront!  You can get the extents in other ways:

Replace

 (lambda (c) (ly:paper-column::break-align-width c '(break-alignment)))

with

(lambda (c) (ly:generic-bound-extent c sys))

or

(lambda (c) (ly:grob-extent c sys X))

HTH,
David

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

Re: "natural width" of a measure

[Urs Liska]

Am 13.04.2017 um 16:48 schrieb David Nalesnik:
> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> wrote:
>>
>> Am 11.04.2017 um 21:04 schrieb tisimst:
>>
>>
>>
>> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden email]>
>> wrote:
>>>
>>>
>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>>>> So, is there any moment in the compilation process where the natural,
>>>>> unstretched length of a measure can be calculated? It doesn't have to
>>>>> be
>>>>> an easily-read property and can involve calculation, but actually the x
>>>>> position of the barlines would be an easy target - *if* there's this
>>>>> magic moment in the compilation pipeline ;-)
>>>> Maybe you could experiment with the ly:one-line-breaking?
>>> I don't think so (only, of course, to investigate how much can be done
>>> on the internal level).
>>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>>> care at all about overall appearance or good page turns but instead
>>> simply places as many measures in a line as fit naturally. If then a
>>> line break changes and I know the natural width of the measures I can
>>> determine before compilation how many measures will fit on the *next*
>>> system.
> But given clefs, key signatures, cautionaries, doesn't this mean that
> you need to know the width of any measure as the first measure of the
> line, as the last measure on a line, at a median position?

Ah yes, this is true. But I guess we could do with some estimates here
(see below).

>
> I'm not clear on the need to know how many measures will fit on
> subsequent lines before compilation.  Is it so that you can compile by
> system?
>
> (Just trying to get a handle on your goals so I can help better.)

Yes, you're right. I'm not going to tackle this right now, but I have to
think about it for writing some plans.
I'm thinking about a "music entry mode" where I don't care at all about
"good" line and page breaking, so music can just be engraved like Word
"justifies" paragraphs - just fill the line and then go to the next.

Given that the music is available in a measure-by-measure state and
given that it is available in a parsed state from a LilyPond server
(both of which I hope to achieve one day) this would mean that I can
simply recompile the "current" system as long as the changed don't
require a change in line breaking. Only then I'd have to recompile the
next system as well, and then the next if the changed lines requires
this. I could do this sequentially, so the score would also update
incrementally without having to wait for the full compilation. But if I
knew the natural width of each existing measure I could perform the
calculations up front and decide which system should contain which
measures. In that case one could even have the systems be engraved in
parallel.
If any of these subsequent system fails because the measures don't fit
on it (BTW some help could be available by LilyPond's ability to squeeze
the system a bit) the parallel engraving could be stopped and restarted
in the incremental fashion.

Urs

PS: Still, I haven't found the opportunity to install the latest version
to test your suggestions.

>
> David

-- 
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: "natural width" of a measure

[David Nalesnik]

On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> wrote:
>
>
> Am 11.04.2017 um 21:04 schrieb tisimst:
>
>
>
> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden email]>
> wrote:
>>
>>
>>
>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>> >
>> > Am 11.04.2017 um 20:36 schrieb Urs Liska:
>> >> So, is there any moment in the compilation process where the natural,
>> >> unstretched length of a measure can be calculated? It doesn't have to
>> >> be
>> >> an easily-read property and can involve calculation, but actually the x
>> >> position of the barlines would be an easy target - *if* there's this
>> >> magic moment in the compilation pipeline ;-)
>> > Maybe you could experiment with the ly:one-line-breaking?
>>
>> I don't think so (only, of course, to investigate how much can be done
>> on the internal level).
>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>> care at all about overall appearance or good page turns but instead
>> simply places as many measures in a line as fit naturally. If then a
>> line break changes and I know the natural width of the measures I can
>> determine before compilation how many measures will fit on the *next*
>> system.

But given clefs, key signatures, cautionaries, doesn't this mean that
you need to know the width of any measure as the first measure of the
line, as the last measure on a line, at a median position?

I'm not clear on the need to know how many measures will fit on
subsequent lines before compilation.  Is it so that you can compile by
system?

(Just trying to get a handle on your goals so I can help better.)

David

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

Re: "natural width" of a measure

[Urs Liska]

Am 11.04.2017 um 21:04 schrieb tisimst:
>
>
> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden
> email] > wrote:
>
>
>
> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
> >
> > Am 11.04.2017 um 20:36 schrieb Urs Liska:
> >> So, is there any moment in the compilation process where the
> natural,
> >> unstretched length of a measure can be calculated? It doesn't
> have to be
> >> an easily-read property and can involve calculation, but
> actually the x
> >> position of the barlines would be an easy target - *if* there's
> this
> >> magic moment in the compilation pipeline ;-)
> > Maybe you could experiment with the ly:one-line-breaking?
>
> I don't think so (only, of course, to investigate how much can be
> done
> on the internal level).
> Basically what I'm after is a ly:cheap-line-breaking mode that
> doesn't
> care at all about overall appearance or good page turns but instead
> simply places as many measures in a line as fit naturally. If then a
> line break changes and I know the natural width of the measures I can
> determine before compilation how many measures will fit on the *next*
> system.
>
>
> Does ragged-right = ##t not do what you want (at least in terms of
> displaying the natural measure widths)?

Well, it *would*. But it would require *two* compilations, one iwth
ragged-right to determine the widths and one without ragged-right to do
the actual engraving.

So, no, thanks, but it doesn't really help.

Best
Urs

>
> Best,
> Abraham 
>
> --------
> View this message in context: Re: "natural width" of a measure
> <http://lilypond.1069038.n5.nabble.com/natural-width-of-a-measure-tp202182p202185.html>
> Sent from the User mailing list archive
> <http://lilypond.1069038.n5.nabble.com/User-f3.html> at Nabble.com.
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

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

Re: "natural width" of a measure

[Urs Liska]

Hi David,


Am 11.04.2017 um 22:42 schrieb David Nalesnik:
> On Tue, Apr 11, 2017 at 3:34 PM, David Nalesnik
> <david.nales...@gmail.com> wrote:
>> On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska <u...@openlilylib.org> wrote:
>>>
>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>>>> So, is there any moment in the compilation process where the natural,
>>>>> unstretched length of a measure can be calculated? It doesn't have to be
>>>>> an easily-read property and can involve calculation, but actually the x
>>>>> position of the barlines would be an easy target - *if* there's this
>>>>> magic moment in the compilation pipeline ;-)
>>>> Maybe you could experiment with the ly:one-line-breaking?
>>> I don't think so (only, of course, to investigate how much can be done
>>> on the internal level).
>>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>>> care at all about overall appearance or good page turns but instead
>>> simply places as many measures in a line as fit naturally. If then a
>>> line break changes and I know the natural width of the measures I can
>>> determine before compilation how many measures will fit on the *next*
>>> system.
>>>
>> But spacing depends on the sorts of durations present -- the most
>> common duration, the shortest duration.

I think I have expressed myself poorly.
I mean that after a first full engraving I would know the natural width
of a measure (as if it were typeset ragged-right). When now something
(e.g. additional notes) forces the line breaking to be changed I can
take the - known - natural widths of the following measures and
calculate which measures would fit into the next system.

>>
>> Do you mean to typeset each measure as if it's in isolation, without
>> stretching based on surrounding measures?
>>
>> For example,
>>
>> \version "2.19.59"
>>
>> \layout { ragged-right = ##t }
>>
>> {
>>   \repeat unfold 16 { c''16 }
>>   \repeat unfold 4 { c''4 }
>>   c''1
>>   c''2 c''2
>>   \repeat unfold 64 { c''64 }
>> }
>>
>> \layout {
>>   \context {
>> \Score
>> \override SpacingSpanner.common-shortest-duration = #'()
>>   }
>> }

No, I just want to know how much space a measure would need if it were
ragged-right but still have the actual engraving stretched to justified
lines.

>>
>> %%
>>
>> Alternately, you could create a \newSpacingSection every measure,
>> though this gives different values.  Don't know why.
>>
>> 
>>
>> Here's how you can determine the widths of measures.  Note that I've
>> put everything on one line, so that the \once \override of the
>> NoteHead gives access to every column in the score.  You can adjust
>> what alignment objects are used to gauge width by changing the symbol
>> in ly:paper-column::break-align-width (available as of 2.19.59).
>> Right now, it's BreakAlignment objects to give you an extent
>> considering all prefatory materials.  staff-bar would give extents of
>> the bar lines.
>>
>> \version "2.19.59"
>>
>> \paper {
>>   page-breaking = #ly:one-line-breaking
>> }
>>
>> #(define (display-measure-widths grob)
>>(let* ((sys (ly:grob-system grob))
>>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>>   (nmpcs
>>(filter
>> (lambda (elt)
>>   (and (grob::has-interface elt 'paper-column-interface)
>>(eq? #t (ly:grob-property elt 'non-musical
>> cols))
>>   (widths
>>(map
>> (lambda (c) (ly:paper-column::break-align-width c
>> '(break-alignment)))
>> nmpcs))
>>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>>   )
>>  (pretty-print widths)))
>> {
>>
>>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>>   \repeat unfold 4 { c''8. c''16}
>>   \repeat unfold 4 { c''4 }
>>   c''1
>>   c''2 c''2
>>   \repeat unfold 64 { c''64 }
>> }
>>
>> \layout {
>>   \context {
>> \Score
>> \override SpacingSpanner.common-shortest-duration = #'()
>>   }
>> }
>>
>> Hope this helps with something!
>>

I'll have to look into this tomorrow. RIght now it's too late to install
another LilyPond ...

> Oh, I should have mentioned that the function is showing the extents
> of objects held by the columns organizing barlines, clefs, key
> signatures, etc --  not measure lengths.  Finding the measures will
> involve an extra fun step.

Looking forward to that ;-)

Best
Urs

>
> David

-- 
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: "natural width" of a measure

[David Nalesnik]

On Tue, Apr 11, 2017 at 3:34 PM, David Nalesnik
<david.nales...@gmail.com> wrote:
> On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska <u...@openlilylib.org> wrote:
>>
>>
>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>
>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>>> So, is there any moment in the compilation process where the natural,
>>>> unstretched length of a measure can be calculated? It doesn't have to be
>>>> an easily-read property and can involve calculation, but actually the x
>>>> position of the barlines would be an easy target - *if* there's this
>>>> magic moment in the compilation pipeline ;-)
>>> Maybe you could experiment with the ly:one-line-breaking?
>>
>> I don't think so (only, of course, to investigate how much can be done
>> on the internal level).
>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>> care at all about overall appearance or good page turns but instead
>> simply places as many measures in a line as fit naturally. If then a
>> line break changes and I know the natural width of the measures I can
>> determine before compilation how many measures will fit on the *next*
>> system.
>>
>
> But spacing depends on the sorts of durations present -- the most
> common duration, the shortest duration.
>
> Do you mean to typeset each measure as if it's in isolation, without
> stretching based on surrounding measures?
>
> For example,
>
> \version "2.19.59"
>
> \layout { ragged-right = ##t }
>
> {
>   \repeat unfold 16 { c''16 }
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> %%
>
> Alternately, you could create a \newSpacingSection every measure,
> though this gives different values.  Don't know why.
>
> 
>
> Here's how you can determine the widths of measures.  Note that I've
> put everything on one line, so that the \once \override of the
> NoteHead gives access to every column in the score.  You can adjust
> what alignment objects are used to gauge width by changing the symbol
> in ly:paper-column::break-align-width (available as of 2.19.59).
> Right now, it's BreakAlignment objects to give you an extent
> considering all prefatory materials.  staff-bar would give extents of
> the bar lines.
>
> \version "2.19.59"
>
> \paper {
>   page-breaking = #ly:one-line-breaking
> }
>
> #(define (display-measure-widths grob)
>(let* ((sys (ly:grob-system grob))
>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>   (nmpcs
>(filter
> (lambda (elt)
>   (and (grob::has-interface elt 'paper-column-interface)
>(eq? #t (ly:grob-property elt 'non-musical
> cols))
>   (widths
>(map
> (lambda (c) (ly:paper-column::break-align-width c
> '(break-alignment)))
> nmpcs))
>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>   )
>  (pretty-print widths)))
> {
>
>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>   \repeat unfold 4 { c''8. c''16}
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> Hope this helps with something!
>

Oh, I should have mentioned that the function is showing the extents
of objects held by the columns organizing barlines, clefs, key
signatures, etc --  not measure lengths.  Finding the measures will
involve an extra fun step.

David

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

Re: "natural width" of a measure

[David Nalesnik]

On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska <u...@openlilylib.org> wrote:
>
>
> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>
>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>> So, is there any moment in the compilation process where the natural,
>>> unstretched length of a measure can be calculated? It doesn't have to be
>>> an easily-read property and can involve calculation, but actually the x
>>> position of the barlines would be an easy target - *if* there's this
>>> magic moment in the compilation pipeline ;-)
>> Maybe you could experiment with the ly:one-line-breaking?
>
> I don't think so (only, of course, to investigate how much can be done
> on the internal level).
> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
> care at all about overall appearance or good page turns but instead
> simply places as many measures in a line as fit naturally. If then a
> line break changes and I know the natural width of the measures I can
> determine before compilation how many measures will fit on the *next*
> system.
>

But spacing depends on the sorts of durations present -- the most
common duration, the shortest duration.

Do you mean to typeset each measure as if it's in isolation, without
stretching based on surrounding measures?

For example,

\version "2.19.59"

\layout { ragged-right = ##t }

{
  \repeat unfold 16 { c''16 }
  \repeat unfold 4 { c''4 }
  c''1
  c''2 c''2
  \repeat unfold 64 { c''64 }
}

\layout {
  \context {
\Score
\override SpacingSpanner.common-shortest-duration = #'()
  }
}

%%

Alternately, you could create a \newSpacingSection every measure,
though this gives different values.  Don't know why.



Here's how you can determine the widths of measures.  Note that I've
put everything on one line, so that the \once \override of the
NoteHead gives access to every column in the score.  You can adjust
what alignment objects are used to gauge width by changing the symbol
in ly:paper-column::break-align-width (available as of 2.19.59).
Right now, it's BreakAlignment objects to give you an extent
considering all prefatory materials.  staff-bar would give extents of
the bar lines.

\version "2.19.59"

\paper {
  page-breaking = #ly:one-line-breaking
}

#(define (display-measure-widths grob)
   (let* ((sys (ly:grob-system grob))
  (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
  (nmpcs
   (filter
(lambda (elt)
  (and (grob::has-interface elt 'paper-column-interface)
   (eq? #t (ly:grob-property elt 'non-musical
cols))
  (widths
   (map
(lambda (c) (ly:paper-column::break-align-width c
'(break-alignment)))
nmpcs))
  (widths (sort widths (lambda (x y) (< (car x) (car y)
  )
 (pretty-print widths)))
{

  \once \override NoteHead.after-line-breaking = #display-measure-widths
  \repeat unfold 4 { c''8. c''16}
  \repeat unfold 4 { c''4 }
  c''1
  c''2 c''2
  \repeat unfold 64 { c''64 }
}

\layout {
  \context {
\Score
\override SpacingSpanner.common-shortest-duration = #'()
  }
}

Hope this helps with something!

David

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

Re: "natural width" of a measure

[tisimst]

On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n202184...@n5.nabble.com> wrote:

>
>
> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
> >
> > Am 11.04.2017 um 20:36 schrieb Urs Liska:
> >> So, is there any moment in the compilation process where the natural,
> >> unstretched length of a measure can be calculated? It doesn't have to
> be
> >> an easily-read property and can involve calculation, but actually the x
> >> position of the barlines would be an easy target - *if* there's this
> >> magic moment in the compilation pipeline ;-)
> > Maybe you could experiment with the ly:one-line-breaking?
>
> I don't think so (only, of course, to investigate how much can be done
> on the internal level).
> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
> care at all about overall appearance or good page turns but instead
> simply places as many measures in a line as fit naturally. If then a
> line break changes and I know the natural width of the measures I can
> determine before compilation how many measures will fit on the *next*
> system.
>

Does ragged-right = ##t not do what you want (at least in terms of
displaying the natural measure widths)?

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/natural-width-of-a-measure-tp202182p202185.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: "natural width" of a measure

[Urs Liska]

Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>
> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>> So, is there any moment in the compilation process where the natural,
>> unstretched length of a measure can be calculated? It doesn't have to be
>> an easily-read property and can involve calculation, but actually the x
>> position of the barlines would be an easy target - *if* there's this
>> magic moment in the compilation pipeline ;-)
> Maybe you could experiment with the ly:one-line-breaking?

I don't think so (only, of course, to investigate how much can be done
on the internal level).
Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
care at all about overall appearance or good page turns but instead
simply places as many measures in a line as fit naturally. If then a
line break changes and I know the natural width of the measures I can
determine before compilation how many measures will fit on the *next*
system.

Urs


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

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


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

Re: "natural width" of a measure

[Malte Meyn]

Am 11.04.2017 um 20:36 schrieb Urs Liska:
> So, is there any moment in the compilation process where the natural,
> unstretched length of a measure can be calculated? It doesn't have to be
> an easily-read property and can involve calculation, but actually the x
> position of the barlines would be an easy target - *if* there's this
> magic moment in the compilation pipeline ;-)

Maybe you could experiment with the ly:one-line-breaking?

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

"natural width" of a measure

[Urs Liska]

Hi,

is there any chance to retrieve the "natural width" of a measure after
typesetting but before the line is stretched to the full line width?

This is a rather long-term question, but it would be terrific if - upon
a compilation - I could retrieve a list of initial widths of each
measure. From this I hope to be able to determine how many concrete
measures fit in a line, so if for example adding some content requires
the current line to be broken earlier I could determine if the next line
would still fit or if that changed break has to continue for subsequent
systems.

So, is there any moment in the compilation process where the natural,
unstretched length of a measure can be calculated? It doesn't have to be
an easily-read property and can involve calculation, but actually the x
position of the barlines would be an easy target - *if* there's this
magic moment in the compilation pipeline ;-)

Thanks for any opinions, info or pointers
Urs


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


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

Re: Accidental/natural on the same note in a polyphonic staff.

[Pierre Perol-Schneider]

Thanks Phil.

2016-09-05 15:31 GMT+02:00 Phil Holmes <m...@philholmes.net>:

> https://sourceforge.net/p/testlilyissues/issues/1134/ ?
>
> --
> Phil Holmes
>
>
>
> - Original Message -
> *From:* Pierre Perol-Schneider <pierre.schneider.pa...@gmail.com>
> *To:* lilypond-user <lilypond-user@gnu.org>
> *Sent:* Monday, September 05, 2016 1:30 PM
> *Subject:* Accidental/natural on the same note in a polyphonic staff.
>
> Hi All,
>
> This question comes from the French list:
> http://lilypond-french-users.1298960.n2.nabble.com/
> Deplacer-une-alteration-td7584109.html
>
> Here's the situation:
>
> \version "2.18.2"
> \relative c' {
>   \omit TupletBracket
>   \omit TupletNumber
>   \tuplet 3/2 4 { r8 << { fis g } \\ { <c, f!>  } >> }
> }
>
> %% My idea to get a readable score: =>
> \relative c' {
>   \omit TupletBracket
>   \omit TupletNumber
>   \tuplet 3/2 4 {
> r8
> <<
>   {
> fis
> %% ugh, ugly hack:
> \tweak X-offset #2.1
> \tweak extra-offset #'(-2.1 . 0)
> g
>   }
>   \\
>   {
> \once\override NoteColumn.force-hshift = #2.1
> <c, f>
> %% => j'imposerai le bécarre ici afin d'éviter
> %% l'espacement indésirable du silence :
> %% (natural sign placed here to avoid the rest misplacement)
> \once\override Accidental.extra-offset = #'(-2.8 . 0)
> 
>   }
> >>
>   }
> }
>
> Now I'm sure to have read something about this situation but I cannot find
> it...
> (A much simpler solution).
> Any help?
>
> TIA, Cheers,
> Pierre
>
> --
>
> ___
> 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: Accidental/natural on the same note in a polyphonic staff.

[Phil Holmes]

https://sourceforge.net/p/testlilyissues/issues/1134/ ?

--
Phil Holmes


  - Original Message - 
  From: Pierre Perol-Schneider 
  To: lilypond-user 
  Sent: Monday, September 05, 2016 1:30 PM
  Subject: Accidental/natural on the same note in a polyphonic staff.


  Hi All,


  This question comes from the French list:
  
http://lilypond-french-users.1298960.n2.nabble.com/Deplacer-une-alteration-td7584109.html


  Here's the situation:

  \version "2.18.2"
  \relative c' {
\omit TupletBracket 
\omit TupletNumber
\tuplet 3/2 4 { r8 << { fis g } \\ { <c, f!>  } >> }
  }


  %% My idea to get a readable score: =>
  \relative c' {
\omit TupletBracket 
\omit TupletNumber
\tuplet 3/2 4 {
  r8 
  << 
{ 
  fis 
  %% ugh, ugly hack:
  \tweak X-offset #2.1
  \tweak extra-offset #'(-2.1 . 0)
  g 
} 
\\ 
{ 
  \once\override NoteColumn.force-hshift = #2.1
  <c, f> 
  %% => j'imposerai le bécarre ici afin d'éviter
  %% l'espacement indésirable du silence :
  %% (natural sign placed here to avoid the rest misplacement)
  \once\override Accidental.extra-offset = #'(-2.8 . 0)
   
}
  >>
}
  }


  Now I'm sure to have read something about this situation but I cannot find 
it...

  (A much simpler solution).

  Any help?


  TIA, Cheers,

  Pierre





--


  ___
  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: Accidental/natural on the same note in a polyphonic staff.

[Pierre Perol-Schneider]

That's it!! Thanks for the reminder Robin.
Cheers,
Pierre

2016-09-05 20:47 GMT+02:00 Robin Bannister :

> Pierre Perol-Schneider wrote:
>
>> Now I'm sure to have read something about this situation but I cannot find
>> it...
>> (A much simpler solution).
>>
>
>
> Well, the following technique might be considered _simpler_
> but is it acceptable as a _solution_ ?
>
>
> \relative c' {
>\omit TupletBracket
>\omit TupletNumber
>\tuplet 3/2 4 { r8 << { fis g } \\ { s128 8*15/16 8 } >> }
> }
>
>
> As Mats says: 'To get a reasonable output.'
> http://lists.gnu.org/archive/html/lilypond-user/2006-11/msg00137.html
>
>
> Cheers,
> Robin
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Accidental/natural on the same note in a polyphonic staff.

[Robin Bannister]

Pierre Perol-Schneider wrote:

Now I'm sure to have read something about this situation but I cannot find
it...
(A much simpler solution).



Well, the following technique might be considered _simpler_
but is it acceptable as a _solution_ ?


\relative c' {
   \omit TupletBracket
   \omit TupletNumber
   \tuplet 3/2 4 { r8 << { fis g } \\ { s128 8*15/16 8 } >> }
}


As Mats says: 'To get a reasonable output.'
http://lists.gnu.org/archive/html/lilypond-user/2006-11/msg00137.html


Cheers,
Robin

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

Accidental/natural on the same note in a polyphonic staff.

[Pierre Perol-Schneider]

Hi All,

This question comes from the French list:
http://lilypond-french-users.1298960.n2.nabble.com/Deplacer-une-alteration-td7584109.html

Here's the situation:

\version "2.18.2"
\relative c' {
  \omit TupletBracket
  \omit TupletNumber
  \tuplet 3/2 4 { r8 << { fis g } \\ { <c, f!>  } >> }
}

%% My idea to get a readable score: =>
\relative c' {
  \omit TupletBracket
  \omit TupletNumber
  \tuplet 3/2 4 {
r8
<<
  {
fis
%% ugh, ugly hack:
\tweak X-offset #2.1
\tweak extra-offset #'(-2.1 . 0)
g
  }
  \\
  {
\once\override NoteColumn.force-hshift = #2.1
<c, f>
%% => j'imposerai le bécarre ici afin d'éviter
%% l'espacement indésirable du silence :
%% (natural sign placed here to avoid the rest misplacement)
\once\override Accidental.extra-offset = #'(-2.8 . 0)

  }
>>
  }
}

Now I'm sure to have read something about this situation but I cannot find
it...
(A much simpler solution).
Any help?

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

Re: Removing "cautionary" natural

[tisimst]

\once \omit Accidental

Best,
Abraham

On Sunday, November 8, 2015, Alberto Simões-2 [via Lilypond] <
ml-node+s1069038n183251...@n5.nabble.com> wrote:

> Hello
>
> I have a melody where, somewhere, there is a bes
> a little later, the is a bes'
> then a b'
> and later a b
> this last b has a natural mark (like the previous one) because (I think)
> it is in a different pitch.
>
> Nevertheless I would like to "remove" (hide) it.
>
> What is the easiest way?
>
> THank you
> Alberto
>
> ___
> lilypond-user mailing list
> [hidden email] <http:///user/SendEmail.jtp?type=node=183251=0>
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Removing-cautionary-natural-tp183251.html
> To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
> <javascript:_e(%7B%7D,'cvml','ml-node%2bs1069038n...@n5.nabble.com');>
> To unsubscribe from Lilypond, click here
> <http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=2=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=>
> .
> NAML
> <http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Removing-cautionary-natural-tp183251p183253.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: Removing "cautionary" natural

[Alberto Simões]

On 08/11/15 18:16, tisimst wrote:

\once \omit Accidental


Like a charm.

Thank you!
Alberto

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

Removing "cautionary" natural

[Alberto Simões]

Hello

I have a melody where, somewhere, there is a bes
a little later, the is a bes'
then a b'
and later a b
this last b has a natural mark (like the previous one) because (I think) 
it is in a different pitch.


Nevertheless I would like to "remove" (hide) it.

What is the easiest way?

THank you
Alberto

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

quarter tone - hide natural that appears to cancel key sig

[Ian Rashkin]

Hi,

So, I am in the key of B flat, and one melody line has in it a beh (B 
quarter-flat). When it renders, I get a natural sign followed by a 
quarter-flat sign - how can I have just the quarter flat? The natural 
seems redundant in this context.


Thanks.

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

Re: quarter tone - hide natural that appears to cancel key sig

[Malte Meyn]

Am 22.08.2015 um 00:35 schrieb Ian Rashkin:

Hi,

So, I am in the key of B flat, and one melody line has in it a beh (B
quarter-flat). When it renders, I get a natural sign followed by a
quarter-flat sign - how can I have just the quarter flat? The natural
seems redundant in this context.

Thanks.



See Learning Manual 3.3.4 or Notation Reference 1.1.1

\version 2.19.25

{
  \key bes \major
  \set Staff.extraNatural = ##f
  beh
}

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

how to prevent natural sign?

[Jinsong Zhao]

Hi there,

I don't want the natural sign to be displayed. However, I don't find a 
way to do so.


Many thanks!

Regards,
Jinsong

\version 2.19.18
\relative c'' {
  \clef treble
% \set Staff.extraNatural = ##f
 r4  g bes  r  g b 
}




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

Re: how to prevent natural sign?

[David Nalesnik]

Hi,

On Thu, Apr 9, 2015 at 9:10 AM, Jinsong Zhao jsz...@yeah.net wrote:

 Hi there,

 I don't want the natural sign to be displayed. However, I don't find a way
 to do so.

 Many thanks!

 Regards,
 Jinsong

 \version 2.19.18
 \relative c'' {
   \clef treble
 % \set Staff.extraNatural = ##f
  r4  g bes  r  g b 
 }



You could do something like:

\version 2.19.17
\relative c'' {
  \clef treble
  % \set Staff.extraNatural = ##f
  r4  g bes  r \once \omit Accidental  g  b 
}

However, I wonder if you doing this as part of a more contemporary
accidental style.  In that case, you should see:

http://www.lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#automatic-accidentals

Hope this helps,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: how to prevent natural sign?

[David Nalesnik]

On Thu, Apr 9, 2015 at 9:21 AM, David Nalesnik david.nales...@gmail.com
wrote:

 Hi,

 On Thu, Apr 9, 2015 at 9:10 AM, Jinsong Zhao jsz...@yeah.net wrote:

 Hi there,

 I don't want the natural sign to be displayed. However, I don't find a
 way to do so.

 Many thanks!

 Regards,
 Jinsong

 \version 2.19.18
 \relative c'' {
   \clef treble
 % \set Staff.extraNatural = ##f
  r4  g bes  r  g b 
 }



 You could do something like:

 \version 2.19.17
 \relative c'' {
   \clef treble
   % \set Staff.extraNatural = ##f
   r4  g bes  r \once \omit Accidental  g  b 
 }

 However, I wonder if you doing this as part of a more contemporary
 accidental style.  In that case, you should see:


 http://www.lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#automatic-accidentals



Though the question is whether the second note on the third staff line is
meant to be a B-flat, and thus wouldn't require a flat in ordinary
notation...  In that case you need to write bes again instead of b.

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

Re: parts for natural horns and trumpets

[Jay Anderson]

On Wed, Apr 1, 2015 at 12:22 AM, Urs Liska u...@openlilylib.org wrote:

 You may have a look at
 https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/auto-transpose


That's pretty awesome. Unfortunately it doesn't behave like I'd expect by
default. Here's an example:

\version 2.19.15

\include auto-transpose.ily

music = \relative c'
{
  \transposition f
  c1 |
}

\score
{
  \new Staff \with { \autoTranspose } \music
}

Playing a middle C with an F transposition I'd expect the output to be a
fifth down instead it results in a fifth up. There are two variable which
control this: 'music-concert-pitch' - is the music entered in concert
pitch, and 'print-concert-pitch' - should the output music be concert pitch
(as opposed to the transposition pitch). By default it's set to the music
being entered in concert pitch and to output the music in the transposed
pitch. This is the opposite of what lilypond's 'transposition' means.
Switching these around works great, but the default seems wrong.

Anyway, this is a _very_ useful function. Functionality like this should be
part of liliypond itself. Thanks.

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

Re: parts for natural horns and trumpets

[Urs Liska]

Am 01.04.2015 um 04:48 schrieb Craig Dabelstein:

Hi Lilyponders,

Does anyone have a successful way of writing parts for natural horns 
and trumpets that would change crooks (and therefore transpositions) 
several times during a part.


There would be a global file holding the many key and time signature 
changes and then I would need the part to change from say Horn in F, 
to Horn in D, to Horn in Af, etc.


Any help would be greatly appreciated.

Craig




You may have a look at 
https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/auto-transpose


HTH
Urs


*Craig Dabelstein*
e:craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com
http://www.facebook.com/craig.dabelstein 
http://au.linkedin.com/pub/craig-dabelstein/b2/5b8/389/en




___
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

parts for natural horns and trumpets

[Craig Dabelstein]

Hi Lilyponders,

Does anyone have a successful way of writing parts for natural horns and
trumpets that would change crooks (and therefore transpositions) several
times during a part.

There would be a global file holding the many key and time signature
changes and then I would need the part to change from say Horn in F, to
Horn in D, to Horn in Af, etc.

Any help would be greatly appreciated.

Craig


   *Craig Dabelstein*
 e:craig.dabelst...@gmail.com
 http://www.facebook.com/craig.dabelstein
http://au.linkedin.com/pub/craig-dabelstein/b2/5b8/389/en
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: parts for natural horns and trumpets

[Alex Loomis]

I'm trying to understand your problem. Is it that the horn part is
currently in concert pitch and you're looking for an easy way to transpose
it? Are you asking how to notate the changes? Perhaps it would help if you
attached an image of what things look like now and described what you want.

Alex

On Tue, Mar 31, 2015 at 10:48 PM, Craig Dabelstein 
craig.dabelst...@gmail.com wrote:

 Hi Lilyponders,

 Does anyone have a successful way of writing parts for natural horns and
 trumpets that would change crooks (and therefore transpositions) several
 times during a part.

 There would be a global file holding the many key and time signature
 changes and then I would need the part to change from say Horn in F, to
 Horn in D, to Horn in Af, etc.

 Any help would be greatly appreciated.

 Craig


*Craig Dabelstein*
  e:craig.dabelst...@gmail.com
  http://www.facebook.com/craig.dabelstein
 http://au.linkedin.com/pub/craig-dabelstein/b2/5b8/389/en

 ___
 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

Putting a natural sign on a note

[William Marchant]

Hi all,
The following two bars of code result in the music correctly written, 
however,
I would like to place a natural symbol on the first note of the second 
bar, just to
remind folks that it is different.  I know this is not the convention, 
but I want to do it anyhow.

Is there a way?
Bill

bf4 bf bf8 bf bf bf |b8 b b b d4 d  |

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

Re: Putting a natural sign on a note

[William Marchant]

Thanks to you and Jan-Peter.
Bill
On 15-02-10 11:16 AM, Kevin Barry wrote:


On Tue, Feb 10, 2015 at 3:13 PM, William Marchant 
wmarch...@eastlink.ca mailto:wmarch...@eastlink.ca wrote:


I would like to place a natural symbol on the first note of the
second bar, just to
remind folks that it is different.  I know this is not the
convention, but I want to do it anyhow.
Is there a way?
Bill


There's nothing unconventional about it at all! To add a cautionary 
accidental just put an exclamation mark after the pitch, i.e.


bf4 bf bf8 bf bf bf | b! b b b d4 d |

hth,
Kevin



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

Re: Putting a natural sign on a note

[Jan-Peter Voigt]

Hi William,

you can use the exclamation or question mark:
b! b?

or you place a markup as a text script above the note:
b^\markup \natural

HTH
Jan-Peter

Am 10.02.2015 um 16:13 schrieb William Marchant:

Hi all,
The following two bars of code result in the music correctly written, 
however,
I would like to place a natural symbol on the first note of the second 
bar, just to
remind folks that it is different.  I know this is not the convention, 
but I want to do it anyhow.

Is there a way?
Bill

bf4 bf bf8 bf bf bf |b8 b b b d4 d  |

___
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: Putting a natural sign on a note

[Noeck]

As an addition: If you want this behaviour as a general rule (reminder
in the next bar), you can use the modern accidental style:

\version 2.18.2
\language english
{
  \accidentalStyle modern
  bf4 bf bf8 bf bf bf | b b b b d4 d |
}

http://www.lilypond.org/doc/v2.18/Documentation/notation/displaying-pitches#automatic-accidentals

Cheers,
Joram

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

Re: Putting a natural sign on a note

[Kevin Barry]

On Tue, Feb 10, 2015 at 3:13 PM, William Marchant wmarch...@eastlink.ca
wrote:

 I would like to place a natural symbol on the first note of the second
 bar, just to
 remind folks that it is different.  I know this is not the convention, but
 I want to do it anyhow.
 Is there a way?
 Bill


There's nothing unconventional about it at all! To add a cautionary
accidental just put an exclamation mark after the pitch, i.e.

bf4 bf bf8 bf bf bf | b! b b b d4 d |

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

Re: Putting a natural sign on a note

[David Stephen Grant]

Also you may like to look at options for automatic handling of accidentals
in the documentation:
http://www.lilypond.org/doc/v2.18/Documentation/notation/displaying-pitches#automatic-accidentals
Best, David

On 10 February 2015 at 16:24, William Marchant wmarch...@eastlink.ca
wrote:

  Thanks to you and Jan-Peter.
 Bill

 On 15-02-10 11:16 AM, Kevin Barry wrote:


 On Tue, Feb 10, 2015 at 3:13 PM, William Marchant wmarch...@eastlink.ca
 wrote:

 I would like to place a natural symbol on the first note of the second
 bar, just to
 remind folks that it is different.  I know this is not the convention,
 but I want to do it anyhow.
 Is there a way?
 Bill


 There's nothing unconventional about it at all! To add a cautionary
 accidental just put an exclamation mark after the pitch, i.e.

  bf4 bf bf8 bf bf bf | b! b b b d4 d |

  hth,
 Kevin



 ___
 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: would 'gn' for G-natural be useful in \language english ?

[Paul Morris]

Keith OHara wrote
 so I am taking Michael Ellis' suggestion to use an include file containing
 the note names I use

Ok, for anyone else interested, here is the full include file for using 'gn'
style note names:

english-n.ly
http://lilypond.1069038.n5.nabble.com/file/n169409/english-n.ly  

The content of the file is also below just for good measure.

Cheers,
-Paul



pitchnames =
#`(
(cff . ,(ly:make-pitch -1 0 DOUBLE-FLAT))
(cf . ,(ly:make-pitch -1 0 FLAT))
(c  . ,(ly:make-pitch -1 0 NATURAL))
(cn . ,(ly:make-pitch -1 0 NATURAL))
(cs . ,(ly:make-pitch -1 0 SHARP))
(css . ,(ly:make-pitch -1 0 DOUBLE-SHARP))
(cx . ,(ly:make-pitch -1 0 DOUBLE-SHARP))

(dff . ,(ly:make-pitch -1 1 DOUBLE-FLAT))
(df . ,(ly:make-pitch -1 1 FLAT))
(d  . ,(ly:make-pitch -1 1 NATURAL))
(dn . ,(ly:make-pitch -1 1 NATURAL))
(ds . ,(ly:make-pitch -1 1 SHARP))
(dss . ,(ly:make-pitch -1 1 DOUBLE-SHARP))
(dx . ,(ly:make-pitch -1 1 DOUBLE-SHARP))

(eff . ,(ly:make-pitch -1 2 DOUBLE-FLAT))
(ef . ,(ly:make-pitch -1 2 FLAT))
(e  . ,(ly:make-pitch -1 2 NATURAL))
(en . ,(ly:make-pitch -1 2 NATURAL))
(es . ,(ly:make-pitch -1 2 SHARP))
(ess . ,(ly:make-pitch -1 2 DOUBLE-SHARP))
(ex . ,(ly:make-pitch -1 2 DOUBLE-SHARP))

(fff . ,(ly:make-pitch -1 3 DOUBLE-FLAT))
(ff . ,(ly:make-pitch -1 3 FLAT))
(f  . ,(ly:make-pitch -1 3 NATURAL))
(fn . ,(ly:make-pitch -1 3 NATURAL))
(fs . ,(ly:make-pitch -1 3 SHARP))
(fss . ,(ly:make-pitch -1 3 DOUBLE-SHARP))
(fx . ,(ly:make-pitch -1 3 DOUBLE-SHARP))

(gff . ,(ly:make-pitch -1 4 DOUBLE-FLAT))
(gf . ,(ly:make-pitch -1 4 FLAT))
(g  . ,(ly:make-pitch -1 4 NATURAL))
(gn . ,(ly:make-pitch -1 4 NATURAL))
(gs . ,(ly:make-pitch -1 4 SHARP))
(gss . ,(ly:make-pitch -1 4 DOUBLE-SHARP))
(gx . ,(ly:make-pitch -1 4 DOUBLE-SHARP))

(aff . ,(ly:make-pitch -1 5 DOUBLE-FLAT))
(af . ,(ly:make-pitch -1 5 FLAT))
(a  . ,(ly:make-pitch -1 5 NATURAL))
(an . ,(ly:make-pitch -1 5 NATURAL))
(as . ,(ly:make-pitch -1 5 SHARP))
(ass . ,(ly:make-pitch -1 5 DOUBLE-SHARP))
(ax . ,(ly:make-pitch -1 5 DOUBLE-SHARP))

(bff . ,(ly:make-pitch -1 6 DOUBLE-FLAT))
(bf . ,(ly:make-pitch -1 6 FLAT))
(b  . ,(ly:make-pitch -1 6 NATURAL))
(bn . ,(ly:make-pitch -1 6 NATURAL))
(bs . ,(ly:make-pitch -1 6 SHARP))
(bss . ,(ly:make-pitch -1 6 DOUBLE-SHARP))
(bx . ,(ly:make-pitch -1 6 DOUBLE-SHARP))
)
#(ly:parser-set-note-names parser pitchnames)




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/would-gn-for-G-natural-be-useful-in-language-english-tp165872p169409.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: would 'gn' for G-natural be useful in \language english ?

[Keith OHara]

Paul Morris paul at paulwmorris.com writes:

 Keith OHara wrote
  
  I'm proposing \languageabbreviated 
 
 +1 for adding an opt-in way to use 'cn' (etc.) via another version of the
 'english' input language.  This allows for use of this helpful form of 
input
 without confusing new users who still haven't learned LilyPond's input
 syntax (which I believe was the main objection to modifying 'english'
 itself).
 

The proposed \language abbreviated  met resistance, arguing that it is
a worse choice than adding 'bn' to \language english, and that any 
use of 'bn' in LilyPond implies some distinction to 'b' that LilyPond
does not preserve.

Nevertheless, written English uses -natural in a systematic way
https://archive.org/stream/wellknownpianoso00wilkrich/
wellknownpianoso00wilkrich_djvu.txt
and I find that helpful in typing LilyPond, so I am taking Michael Ellis'
suggestion to use an include file containing the note names I use

pitchnames = #`(
(cff . ,(ly:make-pitch -1 0 DOUBLE-FLAT))
(cf . ,(ly:make-pitch -1 0 FLAT))
(c  . ,(ly:make-pitch -1 0 NATURAL))
(cn . ,(ly:make-pitch -1 0 NATURAL))
%% et cetera
#(ly:parser-set-note-names parser pitchnames)


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

Re: would 'gn' for G-natural be useful in \language english ?

[Paul Morris]

Keith OHara wrote
 Then I'll propose that LilyPond accept 'cn' only when the user requests
 that input style, and I won't call that style 'American'.
 
 Another inconvenience with \languageenglish is that its default names
 are the long forms, so
   \displayLilyMusic \transpose c e {fs as cs}
 is not as helpful for rearranging music as it could be.
 
 I'm proposing \languageabbreviated for people who want to use
 \displayLilyMusic to generate brief english, and/or want to type
 'cn' for the same reasons that we sometimes pronounce 'natural'
 in English.
 lt;https://code.google.com/p/lilypond/issues/detail?id=4076#c26gt;

+1 for adding an opt-in way to use 'cn' (etc.) via another version of the
'english' input language.  This allows for use of this helpful form of input
without confusing new users who still haven't learned LilyPond's input
syntax (which I believe was the main objection to modifying 'english'
itself).

Cheers,
-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/would-gn-for-G-natural-be-useful-in-language-english-tp165872p169051.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: would 'gn' for G-natural be useful in \language english ?

[Keith OHara]

Ralph Palmer palmer.r.violin at gmail.com writes:

 On Sun, Nov 16, 2014 at 11:31 PM, Keith OHara k-ohara5a5a at oco.net 
wrote:Dear list,
 In English, pronouncing the 'natural' in 'C-natural' is required if the 
note is out-of-key.  LilyPond does not consider the key when reading note-
input, but could easily accept 'cn' as a name for the pitch C-natural.  There 
was a feature request on the bug-list, that LilyPond do so.
 Among those responding to the proposal, the Americans were in favor, while 
the British Germans Dutch and Flemish opposed.
 I have started using English note-entry with 'cn', etc., for naturals when 
I would say natural and I find it helpful.  If anyone else will use it, 
I'll push for it and put it in LilyPond.
 
 Hmm. . . . I am an American and I am opposed, for the reasons given in the 
previous discussion(s). My 2 cents.


Then I'll propose that LilyPond accept 'cn' only when the user requests
that input style, and I won't call that style 'American'.

Another inconvenience with \languageenglish is that its default names
are the long forms, so
  \displayLilyMusic \transpose c e {fs as cs}
is not as helpful for rearranging music as it could be.

I'm proposing \languageabbreviated for people who want to use
\displayLilyMusic to generate brief english, and/or want to type
'cn' for the same reasons that we sometimes pronounce 'natural'
in English. https://code.google.com/p/lilypond/issues/detail?id=4076#c26


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

Re: would 'gn' for G-natural be useful in \language english ?

[Michael Ellis]

Also American, can't see the need for this because LP supports defining
your own pitch names in an include file.

For example, I once made an include file (attached) that supports both
English and Chromatic Fixed Do solfege, i.e. one can enter an E-flat major
scale as either

ef f g af bf c d ef

or

me fa sol le te do re me

or any mixture of the two systems (but that way lies madness.)


Cheers,
Mike

On Thu, Nov 20, 2014 at 12:50 AM, Paul Morris p...@paulwmorris.com wrote:

 Another American here, but I don't have a very strong opinion on this.  I
 can
 see arguments on both sides.

 -Paul



 --
 View this message in context:
 http://lilypond.1069038.n5.nabble.com/would-gn-for-G-natural-be-useful-in-language-english-tp165872p168834.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



english-solfa.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: would 'gn' for G-natural be useful in \language english ?

[Paul Morris]

Another American here, but I don't have a very strong opinion on this.  I can
see arguments on both sides.

-Paul



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/would-gn-for-G-natural-be-useful-in-language-english-tp165872p168834.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: would 'gn' for G-natural be useful in \language english ?

[Ralph Palmer]

On Sun, Nov 16, 2014 at 11:31 PM, Keith OHara k-ohara5...@oco.net wrote:

 Dear list,
 In English, pronouncing the 'natural' in 'C-natural' is required if the
 note is out-of-key.  LilyPond does not consider the key when reading
 note-input, but could easily accept 'cn' as a name for the pitch
 C-natural.  There was a feature request on the bug-list, that LilyPond do
 so.

 Among those responding to the proposal, the Americans were in favor, while
 the British Germans Dutch and Flemish opposed.

 I have started using English note-entry with 'cn', etc., for naturals when
 I would say natural and I find it helpful.  If anyone else will use it,
 I'll push for it and put it in LilyPond.


Hmm. . . . I am an American and I am opposed, for the reasons given in the
previous discussion(s). My 2 cents.

Thanks to all for your help and input,

Ralph

-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: would 'gn' for G-natural be useful in \language english ?

[Shane Brandes]

American here, the cn is a waste of effort and more liable to muddle
things up.

regards,
Shane

On Mon, Nov 17, 2014 at 7:36 AM, Ralph Palmer palmer.r.vio...@gmail.com wrote:
 On Sun, Nov 16, 2014 at 11:31 PM, Keith OHara k-ohara5...@oco.net wrote:

 Dear list,
 In English, pronouncing the 'natural' in 'C-natural' is required if the
 note is out-of-key.  LilyPond does not consider the key when reading
 note-input, but could easily accept 'cn' as a name for the pitch C-natural.
 There was a feature request on the bug-list, that LilyPond do so.

 Among those responding to the proposal, the Americans were in favor, while
 the British Germans Dutch and Flemish opposed.

 I have started using English note-entry with 'cn', etc., for naturals when
 I would say natural and I find it helpful.  If anyone else will use it,
 I'll push for it and put it in LilyPond.


 Hmm. . . . I am an American and I am opposed, for the reasons given in the
 previous discussion(s). My 2 cents.

 Thanks to all for your help and input,

 Ralph

 --
 Ralph Palmer
 Brattleboro, VT
 USA
 palmer.r.vio...@gmail.com

 ___
 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: would 'gn' for G-natural be useful in \language english ?

[Keith OHara]

Dear list,
In English, pronouncing the 'natural' in 'C-natural' is required if the note is 
out-of-key.  LilyPond does not consider the key when reading note-input, but 
could easily accept 'cn' as a name for the pitch C-natural.  There was a 
feature request on the bug-list, that LilyPond do so.

Among those responding to the proposal, the Americans were in favor, while the 
British Germans Dutch and Flemish opposed.

The worry is that if LilyPond accepts 'cn' without an error, this might imply 
that 'c' means something different than C-natural, causing someone accustomed 
to ABC or Amadeus input to type 'c' for the leading-tone in the key of D.


The current situation, however, is more difficult for a user accustomed to other 
English-centric note-entry systems.  LilyPond flags each 'cn' with unrecognized 
string and produces (usually) no engraved output.

This might remind him that 'c' always means C-natural, and thus by implication 
that he should check his uses of 'c' to see if he ever meant 'cs'.  But he must 
first change (most of) the 'cn's to 'c' to get any output, and then has no 
method better than %{comments%} to note which 'c's really meant C-natural.  I 
tried using 'c!' in these cases, but not all C-naturals need a printed natural.


If instead LilyPond accepts 'cn' as C-natural, and the documentation mentions that in English 
'cn' is accepted as a synonym for 'c'  (just after in Dutch 'aes' is accepted as a 
synonym for 'as') then LilyPond will give that hypothetical user engraved output.  If he has 
used 'c' when he meant C-sharp, he can see that LilyPond typeset a C-natural, and hear it in the 
MIDI.  This behavior form LilyPond would be at least kinder to the user.

That user would want to remember give LilyPond pitches, not scale-steps.  
Being able to type the explicit pitch 'cn' (when it is distinct from the scale-step C) 
seems to help in that goal.


I have started using English note-entry with 'cn', etc., for naturals when I would say 
natural and I find it helpful.  If anyone else will use it, I'll push for it 
and put it in LilyPond.
__
\language english
\new Staff \transpose c c'' {
  \key c\minor \partial 2
  r16 g f g ef g d g |
  c g bn, g c g d g ef g g, g an, g bn, g |
  c g bn, g c g d g ef g d g c g bf, g |
  af, g bf, g c f af, f d f c f bf, f af, f |
  g, f af, f bf, ef g, ef c ef bf, ef af, ef g, ef |
  f, ef g, ef af, d f, d bn, d af, d g, d f, d |
  ef, d f, d g, c ef, c r2 }


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

How to prevent natural signs from being printed when the key signature changes

[Jayaratna]

Dear Lilyfriends,
I am following the steps from the notation manual at this location:
http://lilypond.org/doc/v2.18/Documentation/notation/displaying-pitches#key-signature
My code is:

\version 2.18.2
\score { 
\relative c'  {
\key f \major c d e f 
\set Staff.printKeyCancellation = ##f
\clef soprano \key c \major g a g f 
  }
}

But I still get the natural sign printed.
http://lilypond.1069038.n5.nabble.com/file/n168456/2014-11-06-170533_1024x600_scrot.png
 
Am I doing something wrong or is this a bug?
Thank you,
A






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-prevent-natural-signs-from-being-printed-when-the-key-signature-changes-tp168456.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: How to prevent natural signs from being printed when the keysignature changes

[Trevor Daniels]

Jayaratna wrote Thursday, November 06, 2014 11:42 AM

 My code is:
 
 \version 2.18.2
 \score { 
 \relative c'  {
 \key f \major c d e f 
 \set Staff.printKeyCancellation = ##f
 \clef soprano \key c \major g a g f 
  }
 }
 
 But I still get the natural sign printed.
 http://lilypond.1069038.n5.nabble.com/file/n168456/2014-11-06-170533_1024x600_scrot.png
  
 Am I doing something wrong or is this a bug?

No, it's not a bug.  As there would be no other indication of the
key change when changing to C major the key cancellation is
always printed in this case.  If you really, really want to suppress it
use either \hide or \omit, depending on whether you want to leave
a space where it was, like this:

  \omit Staff.KeyCancellation

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

Re: How to prevent natural signs from being printed when the key signature changes

[Helge Kruse]

You did it as describe in the notation manual. Further it works for key
signatures that have a sharp.

But it doesn't work for C major without a neither a sharp nor a flat.
I assume it's a bug.

Regards,
Helge

2014-11-06 12:42 GMT+01:00 Jayaratna jayara...@gmail.com:

 Dear Lilyfriends,
 I am following the steps from the notation manual at this location:

 http://lilypond.org/doc/v2.18/Documentation/notation/displaying-pitches#key-signature

 \version 2.18.2
 \score {
   \relative c'  {
 \key f \major c d e f
 \set Staff.printKeyCancellation = ##f
 \clef soprano \key c \major g a g f
   }
 }

 But I still get the natural sign printed.


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

Re: How to prevent natural signs from being printed when the key signature changes

[Helge Kruse]

Just wait a minute!

If you don't have the natural sign and the next key signature has neither
sharp nor flat sign, how would you read the new key signature? I think the
flat is necessary here.

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

Re: How to prevent natural signs from being printed when the key signature changes

[Jayaratna]

Ok, that one was a dummy example I made to see if the 'error' happened in a
context different from the one I have in my file. Maybe it would just be
good to add Trevor's explanation to the website.

I actually wanted to copy the following score: I just decided to keep the f
key. 

http://lilypond.1069038.n5.nabble.com/file/n168461/2014-11-06-183422_1024x600_scrot.png
 

Thank you,
A



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-prevent-natural-signs-from-being-printed-when-the-key-signature-changes-tp168456p168461.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

would 'gn' for G-natural be useful in \language english ?

[Keith OHara]

Dear user list,
  The suggestion quoted below from the bug-lilypond list
http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html
makes sense to me, as an addition to the \language english  note-names.

It would not fit in German-style pitch-names, where 'cis' and 'ces' get 
completely distinct names from 'c'.
I am not sure if something similar makes sense in fixed-do naming as used in 
French and Spanish.

Would anyone else like to see 'fn' as a second way to express F-natural in 
English (in addition to the existing 'f') ?


David Winfrey  writes:


A new accidental for entering natural notes would be useful.
In English, this would be 'n', as in 'bn4' or 'gn2'.
These would have exactly the same effect as 'b4' or 'g2',
but would be easier to debug.
If the user is entering or editing music in the key of F,
or some other key where B is normally flat, it is often
not clear if 'b4' was intended to be B-natural, or if
someone just forgot to flat it.
If the note is written as 'bn4', the note was clearly
meant to be B-natural.



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

Re: would 'gn' for G-natural be useful in \language english ?

[Phil Holmes]

- Original Message - 
From: Keith OHara k-ohara5...@oco.net

To: lilypond-user@gnu.org
Sent: Friday, August 29, 2014 7:41 AM
Subject: would 'gn' for G-natural be useful in \language english ?



Dear user list,
  The suggestion quoted below from the bug-lilypond list
http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html
makes sense to me, as an addition to the \language english  note-names.

It would not fit in German-style pitch-names, where 'cis' and 'ces' get 
completely distinct names from 'c'.
I am not sure if something similar makes sense in fixed-do naming as used 
in French and Spanish.


Would anyone else like to see 'fn' as a second way to express F-natural in 
English (in addition to the existing 'f') ?



My vote: no.  I don't see the point of adding an alias.

--
Phil Holmes 



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

Re: would 'gn' for G-natural be useful in \language english ?

[Brian Barker]

At 23:41 28/08/2014 -0700, Keith OHara wrote:

The suggestion quoted below from the bug-lilypond list
http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html
makes sense to me, as an addition to the \language english  note-names.

It would not fit in German-style pitch-names, where 'cis' and 'ces' 
get completely distinct names from 'c'.


Sorry, but I don't see the distinction you are trying to make between 
German and English. Surely C, C-sharp, and C-flat (and for that 
matter -double sharp and -double flat) have separate names in any 
language, including German, English, German Lilypond, and English Lilypond?


Would anyone else like to see 'fn' as a second way to express 
F-natural in English (in addition to the existing 'f') ?


No: please not.

There are surely two ways of indicating pitches? One is the method 
used in musical notation itself, where a note on the C line or space 
without any accidental represents any one of C, C-sharp, or C-flat, 
depending on the key signature. The other is that used in Lilypond 
input, where c always represents C-natural, irrespective of the key 
signature in force. Similarly cis or cs and so on are interpreted 
literally, without reference to the key signature.


The danger in allowing cn would not be to the operation of Lilypond 
but to the mind of the user! As soon as you allow the user to input 
cn, s/he will easily be distracted into thinking in terms of the 
first method above and will easily omit the appropriate necessary 
suffixes when a modified pitch is required but which is already 
present in the key signature. After entering cn in, say, D major, 
one would readily fall into the trap of using c in the next bar 
where cis (or cs) was actually meant and required.



David Winfrey writes:

A new accidental for entering natural notes would be useful. [...]


The original suggester has fallen into this very trap by mentioning 
an accidental: that's musical thinking, not Lilypond thinking. 
Accidentals in the musical output appear automatically; no concept of 
accidental is necessary in the Lilypond method of entering pitches.


You could argue that Lilypond input should work like music does (for 
the avoidance of doubt, I'm not doing that), but that's a completely 
different suggestion.


Brian Barker  



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

Re: would 'gn' for G-natural be useful in \language english ?

[Knute Snortum]

English speakers (at least the ones in my part of America) will say cee
or cee-natural for the note C.  The latter is to emphasis that you are
not speaking of another pitch like C-sharp.  In the key of D, say, some
people will say cee when they mean cee-sharp.  cee-natural shows you
haven't made this mistake.

So it seems natural (!) that LilyPond would include this sort of emphasis.
 Writing cs (with \language english and \key d \major) is confusing to
newcomers -- as evidenced by the section in the documentation under
Accidentals.  cn in LilyPond would be like speaking cee-natural -- it
would assure the reader that you really mean C-natural.  The compiler would
just ignore it.


Knute Snortum
(via Gmail)


On Fri, Aug 29, 2014 at 3:06 AM, Brian Barker b.m.bar...@btinternet.com
wrote:

 At 23:41 28/08/2014 -0700, Keith OHara wrote:

 The suggestion quoted below from the bug-lilypond list
 http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html
 makes sense to me, as an addition to the \language english  note-names.

 It would not fit in German-style pitch-names, where 'cis' and 'ces' get
 completely distinct names from 'c'.


 Sorry, but I don't see the distinction you are trying to make between
 German and English. Surely C, C-sharp, and C-flat (and for that matter
 -double sharp and -double flat) have separate names in any language,
 including German, English, German Lilypond, and English Lilypond?


  Would anyone else like to see 'fn' as a second way to express F-natural
 in English (in addition to the existing 'f') ?


 No: please not.

 There are surely two ways of indicating pitches? One is the method used in
 musical notation itself, where a note on the C line or space without any
 accidental represents any one of C, C-sharp, or C-flat, depending on the
 key signature. The other is that used in Lilypond input, where c always
 represents C-natural, irrespective of the key signature in force. Similarly
 cis or cs and so on are interpreted literally, without reference to the
 key signature.

 The danger in allowing cn would not be to the operation of Lilypond but
 to the mind of the user! As soon as you allow the user to input cn, s/he
 will easily be distracted into thinking in terms of the first method above
 and will easily omit the appropriate necessary suffixes when a modified
 pitch is required but which is already present in the key signature. After
 entering cn in, say, D major, one would readily fall into the trap of
 using c in the next bar where cis (or cs) was actually meant and
 required.

  David Winfrey writes:

 A new accidental for entering natural notes would be useful. [...]


 The original suggester has fallen into this very trap by mentioning an
 accidental: that's musical thinking, not Lilypond thinking. Accidentals in
 the musical output appear automatically; no concept of accidental is
 necessary in the Lilypond method of entering pitches.

 You could argue that Lilypond input should work like music does (for the
 avoidance of doubt, I'm not doing that), but that's a completely different
 suggestion.

 Brian Barker

 ___
 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: would 'gn' for G-natural be useful in \language english ?

[Brian Barker]

At 07:20 29/08/2014 -0700, Knute Snortum wrote:
English speakers (at least the ones in my part of America) will say 
cee or cee-natural for the note C. The latter is to emphasis 
that you are not speaking of another pitch like C-sharp.


Agreed.


In the key of D, say, some people will say cee when they mean cee-sharp.


I've heard that only very seldom, and I've always thought of it as a 
simple mistake.



cee-natural shows you haven't made this mistake.


It shows something to a human reader, but the suggestion I was 
responding to is that it should show nothing to Lilypond - that c 
and cn should be synonymous.



So it seems natural (!) that LilyPond would include this sort of emphasis.


Not at all.

Writing cs (with \language english and \key d \major) is 
confusing to newcomers -- as evidenced by the section in the 
documentation under Accidentals.


That's certainly true. But I see that as a good reason *not* to 
include cn as a notation: it would not help accuracy or 
communication with the program and would encourage those newcomers to 
maintain their confusion. I remember the time early in my use of 
Lilypond that I typed something like bn in the key of, perhaps, F 
major - no doubt whilst imagining the necessary accidental in the 
output. I was initially confused that it was objected to by the 
program, wondering for a second or two what the code for natural 
had to be if it wasn't n, but this experience forced me to remember 
(and learn) that I needed to be writing in Lilypond-speak, not in 
Music-speak. If I hadn't had that jolt, I would soon have been 
writing b when I meant (and needed) bf.


cn in LilyPond would be like speaking cee-natural -- it would 
assure the reader that you really mean C-natural. The compiler would 
just ignore it.


But the compiler is the only reader: there is no other! Well, that's 
true for my input files, anyway.


Brian Barker  



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

Re: would 'gn' for G-natural be useful in \language english ?

[Keith OHara]

On Fri, 29 Aug 2014 03:06:31 -0700, Brian Barker b.m.bar...@btinternet.com 
wrote:


At 23:41 28/08/2014 -0700, Keith OHara wrote:

The suggestion quoted below from the bug-lilypond list
http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html
makes sense to me, as an addition to the \language english  note-names.

It would not fit in German-style pitch-names, where 'cis' and 'ces'
get completely distinct names from 'c'.


Sorry, but I don't see the distinction you are trying to make between
German and English. Surely C, C-sharp, and C-flat (and for that
matter -double sharp and -double flat) have separate names in any
language, including German, English, German Lilypond, and English Lilypond?



In English the names use two parts, noun-adjective, which allows the construction 
C-natural.  German has single words (ces c cis) for the pitches, and these are distinct 
from the names for the alterations (Be, AuflösungZeichen, Kreuz).  English speakers use 
C-natural to name the pitch in contexts where the key has sharped the scale-step C.



 After entering cn in, say, D major,
one would readily fall into the trap of using c in the next bar
where cis (or cs) was actually meant and required.



The feature-request implicitly assumed, based on experience, that such errors 
already happen.  Anyone using, for example, ABC notation had developed the 
habit of typing 'C' for the pitch at scale-step C in the key.

The distinct naming was suggested as a way to help us more efficiently correct 
those errors.

Would the ability to enter 'cn', or a note in the Languages table saying In 
English 'cn' is an alternative to 'c' to denote the pitch C-natural, actually increase the 
rate of forgetting the 's' in 'cs' ?


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

Re: would 'gn' for G-natural be useful in \language english ?

[Johan Vromans]

Brian Barker b.m.bar...@btinternet.com writes:

 There are surely two ways of indicating pitches? One is the method
 used in musical notation itself, where a note on the C line or space
 without any accidental represents any one of C, C-sharp, or C-flat,
 depending on the key signature. The other is that used in Lilypond
 input, where c always represents C-natural, irrespective of the key
 signature in force. Similarly cis or cs and so on are interpreted
 literally, without reference to the key signature.

+1

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

Re: would 'gn' for G-natural be useful in \language english ?

[Brian Barker]

At 08:38 29/08/2014 -0700, Keith OHara wrote:
In English the names use two parts, 
noun-adjective, which allows the construction 
C-natural. German has single words (ces c cis) 
for the pitches, and these are distinct from the 
names for the alterations (Be, AuflösungZeichen, Kreuz).


Interesting: thank you. I hadn't appreciated 
that. Rather as some arithmeticians call -3 
negative three and not minus three, so as to 
distinguish negation from subtraction - the result from the process.


The feature-request implicitly assumed, based on 
experience, that such errors [c, when cs was 
meant but was in the key signature] already happen.


Oh, indeed they will.

Anyone using, for example, ABC notation had 
developed the habit of typing 'C' for the pitch 
at scale-step C in the key. The distinct naming 
was suggested as a way to help us more efficiently correct those errors.


That's where we disagree.

Would the ability to enter 'cn', or a note in 
the Languages table saying In English 'cn' is 
an alternative to 'c' to denote the pitch 
C-natural, actually increase the rate of forgetting the 's' in 'cs' ?


That's what I'm suggesting - that allowing cn 
would encourage users to think as they would if 
writing music by hand or reading out the note names.


Brian Barker  



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

Cautionary \natural

[Charles Marshall]

The composer would like me to place a cautionary natural symbol on 
several notes.  He specifies a /parenthesized/ natural.  Can anyone help 
me find a way to do this?


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

Re: Cautionary \natural

[Urs Liska]

{ c? }

On 5. Juli 2014 21:06:52 MESZ, Charles Marshall marsh...@potsdam.edu wrote:
The composer would like me to place a cautionary natural symbol on 
several notes.  He specifies a /parenthesized/ natural.  Can anyone
help 
me find a way to do this?

Charlie




___
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: Cautionary \natural

[Urs Liska]

{ c? }

On 5. Juli 2014 21:06:52 MESZ, Charles Marshall marsh...@potsdam.edu wrote:
The composer would like me to place a cautionary natural symbol on 
several notes.  He specifies a /parenthesized/ natural.  Can anyone
help 
me find a way to do this?

Charlie




___
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: \fill-line while respecting natural widths

[David Nalesnik]

Hi all,

I've posted an update to this on the issue tracker.  I think the discussion
should move there.

https://code.google.com/p/lilypond/issues/detail?id=3860

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

Re: \fill-line while respecting natural widths

[Alexander Kobel]

On 02/08/2014 11:22 PM, Kieren MacMillan wrote:

Hi David,


Hmm--do you think it should be added as an option to \fill-line?


DEFINITELY!
As just one example: I’m going to use it in the musical theatre scores I’m 
engraving right now, to [evenly] space two columns of dialogue above a system 
of underscore music.

But maybe it should be its own separate function, e.g., \spaced-line, or some 
such thing?


Agreed.  What about \equispaced-line?

The rationale for \fill-line IMHO is only to be used for one, two or 
three arguments, which is the common case in headings.  One for 
center-aligned (which should be available as \center-line on it's 
own...), two for left-right-aligned, three for 
left-center-right-aligned.  That's it.  Everything else gives highly 
unintuitive results.  It's the analogue of one of the rare features I 
miss in OpenOffice vs. Word:  In the latter, you can specify the 
horizontal alignment for groups of words in a single line, separated by 
tabs.
\fill-line might not be the best name for that, but it's late to change 
it.  (\equicentered-line?  Leftmost and rightmost element don't fit in, 
though...)  And it's description is really bad, now that I read it again...
BTW, I'd like to see collision avoidance there (and there should be a 
comment in the code on what's necessary), but probably it's overkill for 
what it's used for.


On the other hand, especially for two-column-dialogues or verses, I 
always end up to use manually spaced columns:  I want a consistent 
column separation, I (usually) want columns of consistent width, and I 
(usually) want the columns to start at the same horizontal position.  At 
least if you have several of those places.  Then, it's almost no 
difference whether you use \spaced-line (\equispaced-line?) or simply a 
\fill-line (as \center-line) of $stuff to autocalculate left and right 
margin.



Best,
Alexander

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

Re: \fill-line while respecting natural widths

[Janek Warchoł]

2014-02-08 23:22 GMT+01:00 Kieren MacMillan kieren_macmil...@sympatico.ca:
 Hi David,

 Hmm--do you think it should be added as an option to \fill-line?

 DEFINITELY!

+1000 - this is awesome!
As for now, i have added it to the snippets
repo(https://github.com/openlilylib/snippets/commit/4bb8a0456c42d5859cd6945b4213901785cfbd23),
but please go ahead and add it to official lily!  I think it is a
feature important enough to warrant a new function.

 As just one example: I’m going to use it in the musical theatre scores I’m 
 engraving right now,
 to [evenly] space two columns of dialogue above a system of underscore music.

Also, it will be perfect for aligning stanzas for songs.  I have
already used it in the openlilylib/snippets stanza template (which
could be turned into a function, btw - didn't have time to do it
myself, yet...):

https://github.com/openlilylib/snippets/blob/master/templates/adjustable-centered-stanzas/definitions.ily
https://github.com/openlilylib/snippets/commit/eeb8d075dff02d29f02316345774fd18c7a5c732

2014-02-09 12:53 GMT+01:00 Alexander Kobel n...@a-kobel.de:
 The rationale for \fill-line IMHO is only to be used for one, two or three
 arguments, which is the common case in headings.  One for center-aligned
 (which should be available as \center-line on it's own...), two for
 left-right-aligned, three for left-center-right-aligned.  That's it.
 Everything else gives highly unintuitive results.  It's the analogue of one
 of the rare features I miss in OpenOffice vs. Word:  In the latter, you can
 specify the horizontal alignment for groups of words in a single line,
 separated by tabs.

yes, very good observation!  \fill-line is needed exactly for that,
and because of this we should keep it like it is (and add David's work
as a new function).

I won't have time to follow this topic closely, but i support David's efforts!

best,
Janek

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

Re: \fill-line while respecting natural widths

[Ed Gordijn]

Hi David,

See the attached.  (I just changed a line or two of the definition of 
\fill-line from scm/define-markup-commands.scm.) Hopefully this gives 
you what you want!


--David



That's interesting, see the result of the two markups:

\version 2.18.0


\markup \fill-line {
  This line has got even spaces, or is it a bit different?
}
\markup \fill-line-two {
  And this line has different spacing, it uses word length!
}

Is this a bug in the original \fill-line?

Greetings, Ed


fill-line-variant.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \fill-line while respecting natural widths

[Mike Solomon]

On Feb 8, 2014, at 10:24 AM, Ed Gordijn ed.klari...@gmail.com wrote:

 Hi David,
 
 See the attached.  (I just changed a line or two of the definition of 
 \fill-line from scm/define-markup-commands.scm.) Hopefully this gives you 
 what you want!
 
 --David
 
 
 That's interesting, see the result of the two markups:
 
 \version 2.18.0
 
 \markup \fill-line {
   This line has got even spaces, or is it a bit different?
 }
 \markup \fill-line-two {
   And this line has different spacing, it uses word length!
 }
 
 Is this a bug in the original \fill-line? 

It’s a feature - \fill-line evenly distributes the centers of objects along a 
line irrespective of their widths.

Cheers,
MS

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

Re: \fill-line while respecting natural widths

[Ed Gordijn]

Hi Mike,


 It's a feature - \fill-line evenly distributes the centers of objects
 along a line irrespective of their widths.


I see,so there wasn't enough room in the last column for the long word
different? I created too many columns.

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

Re: \fill-line while respecting natural widths

[Kieren MacMillan]

David (et al.),

OOO!
This is wonderful. I can already see several places where I will use this.

Thanks,
Kieren.

On Feb 8, 2014, at 2:20 AM, Mike Solomon m...@mikesolomon.org wrote:

 
 On Feb 8, 2014, at 1:18 AM, David Nalesnik david.nales...@gmail.com wrote:
 
 Hi Mike,
 
 See the attached.  (I just changed a line or two of the definition of 
 \fill-line from scm/define-markup-commands.scm.) Hopefully this gives you 
 what you want!
 
 --David
 fill-line-variant.ly
 
 Great work!
 
 Thanks for taking the time to do this.
 
 I’ve posted on-line a PDF of how I use it. By spacing top-level markups
 this way, we get nice columns : 
 http://mikesolomon.org/lilypond/davidNSolution.pdf
 
 Cheers,
 MS
 ___
 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: \fill-line while respecting natural widths

[David Nalesnik]

Hi Mike,


On Sat, Feb 8, 2014 at 1:20 AM, Mike Solomon m...@mikesolomon.org wrote:


 On Feb 8, 2014, at 1:18 AM, David Nalesnik david.nales...@gmail.com
 wrote:

 Hi Mike,

 See the attached.  (I just changed a line or two of the definition of
 \fill-line from scm/define-markup-commands.scm.) Hopefully this gives you
 what you want!

 --David
 fill-line-variant.ly


 Great work!


Thanks!


 I’ve posted on-line a PDF of how I use it. By spacing top-level markups
 this way, we get nice columns :
 http://mikesolomon.org/lilypond/davidNSolution.pdf


Very nice looking.

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

Re: \fill-line while respecting natural widths

[David Nalesnik]

Hi Kieren,


On Sat, Feb 8, 2014 at 7:16 AM, Kieren MacMillan 
kieren_macmil...@sympatico.ca wrote:

 David (et al.),

 OOO!
 This is wonderful. I can already see several places where I will use this.

 Thanks,
 Kieren.


Hmm--do you think it should be added as an option to \fill-line?  (Well, it
would need some going over first.)

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

Re: \fill-line while respecting natural widths

[Kieren MacMillan]

Hi David,

 Hmm--do you think it should be added as an option to \fill-line?

DEFINITELY!
As just one example: I’m going to use it in the musical theatre scores I’m 
engraving right now, to [evenly] space two columns of dialogue above a system 
of underscore music.

But maybe it should be its own separate function, e.g., \spaced-line, or some 
such thing?

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