Re: Lilypond and Jazz chords

[Kieren MacMillan]

Hi David,

> The engraver would convert  into something akin to c c' d' f'
> bf' (somewhat opaque example since the first is the root pitch and the
> others are the relation to the root note, expressed as intervals from
> c').  There would be one or several markups for interpreting the c' d'
> f' bf' part of the list.  And likely some exceptions mechanism.

I personally think like an input like

  /c  ==>  Bb/C or Bb(6/3)/C or etc.
==>  C7(sus2,4) or etc.

would be a huge help (at least to me). Wouldn’t have to be exactly like that, 
of course… but should be a clear and easy way to explicitly separate the 
chord(s), inversion(s), and root(s) into bits to be reassembled into a name 
later.

> But it would be quite clear how to assemble one's own solution
> from scratch and what building blocks were available for it.

That would ultimately be the most important thing.

> The current situation also offers "from scratch" assembly, but there are
> basically no useful building blocks or recognizable mechanisms.

+1

> It's a feature rather than a bug that LilyPond tries to avoid passing
> information via anything but the chord pitches: that way you can get
> sensible labelling of chords not entered via chordmode.  This is not
> complete: some special properties come into play in order to allow for
> inversions to be labelled relative to the purported root note rather
> than the nominally lowest note.

Correct.

Best,
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: Lilypond and Jazz chords

[BB]

Sorry for  misunderstanding/misinterpretation.
In lilypond I write bes for bflat, In text writing  I use bB.

On 18.01.2016 15:23, Kieren MacMillan wrote:

Hi,


Bb/C is built of  C Bb D F

…which is what I wrote: “bf” is Bb using english note names.


May be you did a typing error

No.


You never get correct chord names without knowing the context

That’s exactly my point.

Regards,
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: Lilypond and Jazz chords

[Kieren MacMillan]

Hi Robert,

> It is possible though that all tools for doing that are already present in 
> LilyJazz ... I simply don't remember now.

Sorry, I wasn’t clear: the accidentals in your chord names aren’t using the 
LilyJazz font, as far as I can tell, whereas the rest of the glyphs (e.g., 
letters, numbers) are.

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: Lilypond and Jazz chords

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> The engraver would convert  into something akin to c c' d' f'
>> bf' (somewhat opaque example since the first is the root pitch and the
>> others are the relation to the root note, expressed as intervals from
>> c').  There would be one or several markups for interpreting the c' d'
>> f' bf' part of the list.  And likely some exceptions mechanism.
>
> I personally think like an input like
>
>   /c  ==>  Bb/C or Bb(6/3)/C or etc.
> ==>  C7(sus2,4) or etc.
>
> would be a huge help (at least to me). Wouldn’t have to be exactly
> like that, of course… but should be a clear and easy way to explicitly
> separate the chord(s), inversion(s), and root(s) into bits to be
> reassembled into a name later.

Well, the above was not supposed to represent input to LilyPond: it's
what the chord naming functions work with internally.

LilyPond's input is basically just the notes in arbitrary order.
However, there are additional properties on single notes: root (boolean
flag for the root note), inversion (boolean flag for the inversion
note), octavation (octave difference to bring the note into an octave
suitable for recognizing the uninverted chord).

Creating nice music functions for conveying the same information might
be a start, but I don't think that it would suffice for everything
called out as "context information" in this thread.

One thing to note is that stuff like the "octavation" property should be
sufficient for hauling guitar chord shapes back into the realm of the
chord namer by placing everything back into its functional octave (and
presumably removing duplicates, haven't tried).

-- 
David Kastrup

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

Re: Lilypond and Jazz chords

[Simon Albrecht]

On 18.01.2016 14:33, BB wrote:

On 18.01.2016 13:29, Kieren MacMillan wrote:



might be named
Dm9no5/C,
Cno5add2add4,
Fmaj7add6no3/C
depending on the context. Names are interpretations of the notes and 
always depend on the context. Your chords in the posting

 be labelled as Bb/C or C7(sus2,sus4)


Bb/C is built of  C Bb D F
C7(sus2) C D G A#
C7(sus4) C F G A#
you mention are different.

May be you did a typing error, then




Whatever you read into this, bf is just the English lilypond notename 
for what the English call B flat and the Germans call B.


Yours, Simon

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

Re: Lilypond and Jazz chords

[Kieren MacMillan]

Hi,

> Bb/C is built of  C Bb D F

…which is what I wrote: “bf” is Bb using english note names.

> May be you did a typing error

No.

> You never get correct chord names without knowing the context

That’s exactly my point.

Regards,
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: Lilypond and Jazz chords

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Here's my take on how to do this more transparently: first have an
>> engraver that does the basic chord analysis and writes one or several
>> properties with the basic analysis results (like fundamental pitch and
>> scale offsets).  Those properties are made part of text-interface.
>> 
>> Then have several markup commands producing output based on those
>> properties.  Like German chord names, or a markup list with
>> modifications and stuff like that.  And then you can basically create
>> one fixed markup for each chord naming style and assign that to the
>> "text" field of a ChordName.
>> 
>> Also it then becomes easy to put chord names into a TextScript
>
> That all sounds great. If the engraver broke the chord components into
> the smallest possible bits (e.g., root, quality, third stack,
> alterations, bass or inversion), then the NameBuilder (or whatever)
> could format those however one pleased.
>
> However, I’m also concerned that the current input syntax isn’t rich
> enough. For example, one can’t tell Lilypond “at run time" if  bf> should be labelled as Bb/C or C7(sus2,sus4). [Note that, at this
> point, I don’t care what anyone’s preference for display of this chord
> is — I’m simply pointing out that I don’t know of a mechanism to force
> Lilypond to label the same set of notes two or more different ways.]

The engraver would convert  into something akin to c c' d' f'
bf' (somewhat opaque example since the first is the root pitch and the
others are the relation to the root note, expressed as intervals from
c').  There would be one or several markups for interpreting the c' d'
f' bf' part of the list.  And likely some exceptions mechanism.

So yes, configurability would still be a hand-wavy thing.  But it would
be quite clear how to assemble one's own solution from scratch and what
building blocks were available for it.

The current situation also offers "from scratch" assembly, but there are
basically no useful building blocks or recognizable mechanisms.

> So we should attack the input mode as well, to support the widest and
> most flexible possible usage.

It's a feature rather than a bug that LilyPond tries to avoid passing
information via anything but the chord pitches: that way you can get
sensible labelling of chords not entered via chordmode.  This is not
complete: some special properties come into play in order to allow for
inversions to be labelled relative to the purported root note rather
than the nominally lowest note.

-- 
David Kastrup

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

Re: Lilypond and Jazz chords

[BB]

On 18.01.2016 13:29, Kieren MacMillan wrote:



might be named
Dm9no5/C,
Cno5add2add4,
Fmaj7add6no3/C
depending on the context. Names are interpretations of the notes and 
always depend on the context. Your chords in the posting

 be labelled as Bb/C or C7(sus2,sus4)


Bb/C is built of  C Bb D F
C7(sus2) C D G A#
C7(sus4) C F G A#
you mention are different.

May be you did a typing error, then



makes  Bb/C or Dm7#5/C again an ambiguity

You never get correct chord names without knowing the context - that is 
one will learn in the basic lessons any jazz school or jazz academy etc. 
To find the fitting context you need a kind of artificial intelligaence 
or knowledge base or a composers analyst tool ...


My 2 cts to the topic just beside of personal preferences of the chord 
name layout, position etc.


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

Re: Lilypond and Jazz chords

[Robert Schmaus]

Yes, that's true - I guess that never bothered me ... until now, that is, now 
that you mention it, thank you very much. 
Quite possibly that is easy to fix though - I'll look into that asap. 

Maybe I should add that, while I like producing aesthetically pleasing lead 
sheets, my first priority has always been to produce sheets that serve the 
performer. And LilyJazz - with or without jazzy accidentals - does provide 
output that is superbly readable even in shady, dim conditions. Only last week 
I played in a bar, and the sheets provided had chord names the size of a 
fine-print edition of the bible. I practically had to kiss the music stand the 
whole gig through ...

Cheers, Robert 

> Hi Robert,
> 
>> It is possible though that all tools for doing that are already present in 
>> LilyJazz ... I simply don't remember now.
> 
> Sorry, I wasn’t clear: the accidentals in your chord names aren’t using the 
> LilyJazz font, as far as I can tell, whereas the rest of the glyphs (e.g., 
> letters, numbers) are.
> 
> 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: Lilypond and Jazz chords

[Kieren MacMillan]

Hi Robert,

> I guess that never bothered me ... until now, that is, now that you mention 
> it, thank you very much.

You’re welcome!

I’m very detail-oriented, so things that others might consider “little” often 
drive me quite crazy.  =)

> Quite possibly that is easy to fix though

Should be.

> LilyJazz […] does provide output that is superbly readable even in shady, dim 
> conditions.

Agreed.

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: Lilypond and Jazz chords

[Blöchl Bernhard]

Am 18.01.2016 08:44, schrieb Carl-Henrik Buschmann:

18. jan. 2016 kl. 02.40 skrev tim...@bitstream.net:


On Jan 17, 2016, at 4:16 PM, Carl-Henrik Buschmann
 wrote:

I'm not talking about code, i'm talking about style. And by the looks of 
it Sibelius at least have by and large been inspired by B But as you 
said, predefined is not the way to go. Even so, look at what they have 
done and simply mimick the behaviour. "Great artists steal".


Do you really believe that Sibelius was inspired by R?
The first edition of
Standardized chord symbol notation : (a uniform system for the music 
profession)

von Carl Brandt; Clinton Roemer Englisch
was published 1976 by Sherman Oaks, Calif. : Roerick Music Co.

Johan Julius Christian („Jean“) Sibelius * 8. Dezember 1865 in 
Hämeenlinna; † 20. September 1957 in Järvenpää near Helsinki;


Are you really doing in music? May be you are only a bit bored and like 
to make some noise?





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: Lilypond and Jazz chords

[Johan Vromans]

On Mon, 18 Jan 2016 09:12:42 +0100
Blöchl Bernhard  wrote:

> Do you really believe that Sibelius was inspired by R?

Not sure if troll

> Johan Julius Christian („Jean“) Sibelius * 8. Dezember 1865 in 
> Hämeenlinna; † 20. September 1957 in Järvenpää near Helsinki;

Sibelius Software
Initial release 1993

-- Johan

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

Re: Lilypond and Jazz chords

[Marc Hohl]

Am 18.01.2016 um 09:12 schrieb Blöchl Bernhard:
[...]


Do you really believe that Sibelius was inspired by R?
The first edition of
Standardized chord symbol notation : (a uniform system for the music
profession)
von Carl Brandt; Clinton Roemer Englisch
was published 1976 by Sherman Oaks, Calif. : Roerick Music Co.

Johan Julius Christian („Jean“) Sibelius * 8. Dezember 1865 in
Hämeenlinna; † 20. September 1957 in Järvenpää near Helsinki;


IIUC, it is about the software called Sibelius, not the composer.


Are you really doing in music? May be you are only a bit bored and like
to make some noise?


Please, let's come back to a more decent style of discussion.

Chord naming rules tend to upset people, but let's not get on
with that stuff ...

Marc


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

Re: Lilypond and Jazz chords

[David Kastrup]

Kieren MacMillan  writes:

> Hi Simon,
>
>> Note the effect of sensible code formatting – it can’t be emphasised
> often enough…
>
> I actually had it that way in my example, but decided to put it on one
> line to save vertical space in the post.

Well, that's important for those of us who receive the mailing list over
fax.  Otherwise, line feeds tend to come pretty cheap in transmission.

-- 
David Kastrup

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

Re: Lilypond and Jazz chords

[David Kastrup]

Carl-Henrik Buschmann  writes:

> Kieren is thankfully working on this and i hope the brains that code
> for lilypond can bash heads together and at least give us a *working*
> solution and stop bickering over personal preferences that only hinder
> the development.

I think you are confused about the line of command in LilyPond
development.  There isn't one.  The main motivation of the developers is
seeing their personal preferences attended.  Those may be preferences in
the code and its maintenance, it may be preferences in typesetting.
There is no "brains that code" who have to placate "us" by "at least
giving us a *working* solution".

You really need to get off that entitlement rap.  Either you don't
expect developers to read the user lists in which case there is no way
they could figure out what to do for "us", or you do, in which case the
motivational value of speeches like that cannot be underestimated.

-- 
David Kastrup

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

Re: temporarily escaping chordmode

[David Kastrup]

Kieren MacMillan  writes:

> Hello all,
>
> If I’ve want to explicitly enter a chord in a chordmode block, e.g.,
>
>   \chordmode {
> c1
> d1:m6
> 
>   }
>
> what’s the incantation?

That already works as of version 2.19.13,

commit 3399446a56b0832d5fa690146e4c9a953e635589
Author: David Kastrup 
Date:   Sun Aug 10 21:41:12 2014 +0200

Issue 4063: Interpret < > and << >> in \chordmode

There is no compelling reason not to do so, and having < > available
allows stuff like

\chordmode { \clef bass  c/e  c/e }

or other ways of explicitly spelling out some not-really chord material.


-- 
David Kastrup

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

Re: Lilypond and Jazz chords

[David Kastrup]

Thomas Morley  writes:

> 2016-01-17 22:28 GMT+01:00 Carl-Henrik Buschmann :
>
> Thanks for code and links!
>
>> A properly formatet complex chord stacks alterations in parenthesis.
>
> Well, I disagre - at least as a general verdict.
>
>> Lilyponds default is
>> [...] undesirable.
>
> Ofcourse I disagree again, ;)
> Though, there are so many opinions about that topic...
>
> The main problem is that current LilyPond-default is very hard to
> tweak, apart from doing exceptions as Kieren already demonstrated.

Here's my take on how to do this more transparently: first have an
engraver that does the basic chord analysis and writes one or several
properties with the basic analysis results (like fundamental pitch and
scale offsets).  Those properties are made part of text-interface.

Then have several markup commands producing output based on those
properties.  Like German chord names, or a markup list with
modifications and stuff like that.  And then you can basically create
one fixed markup for each chord naming style and assign that to the
"text" field of a ChordName.

Also it then becomes easy to put chord names into a TextScript: it's
common for Jazz accordion scores using standard bass to name chords and
bass notes in textscript style in the bass staff according to the chord
button(s) to use, and to name them in ChordNames style according to
their function.  For example, you might have a chord c♭ for fingering
reasons in the accordion part while having B functionally (chord buttons
are in circle-of-fifth arrangement with considerable redundancy, so c♭
and b are 12 buttons apart from each other even though sounding exactly
the same notes).  Or you have Em6 functionally and c+em as buttons.

So the accordion chord naming function would likely take some auxiliary
info to be placed by either engraver or manually.

And so on.  If done right, stuff will both play and transpose reasonably
well.

And everybody could puzzle together his own chord markup reasonably
easy.

-- 
David Kastrup

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

Re: Lilypond and Jazz chords

[Robert Schmaus]

--
Note beforehand: I'm sending this from a phone, and I can't control if the 
attached picture is sent inline or not - hope you can see it, otherwise I'll 
have to resend it later today. 
--

Hi Carl-Henrik,

Fwiw, I write jazz sheets all the time, and I've trimmed Lilypond to produce 
stuff like this:



So, Lilypond is quite able to produce those complex chords you mention. This is 
definitely not out of the box though ... I've put quite some work into it. But 
I guess it goes along the lines of what Kieren sent you earlier ...

The question if it is sensible to go that way is something else.

Best, Robert 



> On 17 Jan 2016, at 20:30, Carl-Henrik Buschmann  wrote:
> 
> Sorry, thought the thread was referenced. 
> 
> I'm wondering if lilypond is able to notate complex chords, as discussed in 
> the before mentioned thread. 
> Examples as shown: 
> 
> 
> 
>> Den 17. jan. 2016 kl. 20.18 skrev Thomas Morley :
>> 
>> 2016-01-17 19:55 GMT+01:00 Carl-Henrik Buschmann :
>>> Any news regarding this?
>> 
>> 
>> 
>> Well, what's "this"?
>> LilyPond exists, yes. There is no common definiton of "JazzChords".
>> So, no news. ;)
>> Maybe you may want to be a little more specific?
>> 
>> Cheers,
>> Harm
> ___
> 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: Lilypond and Jazz chords

[Carl-Henrik Buschmann]

Chill pills for everybody! Smile :-)

> 18. jan. 2016 kl. 09.39 skrev David Kastrup :
> 
> There is no "brains that code" who have to placate "us" by "at least
> giving us a *working* solution".



I see how that might have been misunderstood, but please belive it was with the 
best of intentions, no disrespect to the guys keeping the fire going. If i 
could code this i would!

The way lilypond treats chords right now are lacking for anything but basic 
chords, this much we are agreed apon. The "real book" convention is a very good 
place to start. Let us not be so childish that we abandon that quest in a hay 
fire of name calling. 


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

Re: Handling of subdivisions with shortened beams

[Urs Liska]

ehm, attachment?

Am 18.01.2016 um 18:20 schrieb Urs Liska:
> One more from this round of review ...
>
> I had changed the subdivision behaviour (which is already in 2.19.35)
> for shortened beams.
>
> c32 [ c c c c c c] r
>
> (i.e. a beam shortened by 1/32) subdivided by 1/8 currently has *two*
> beams at the subdivision - to indicate that the remaining group is
> shorter than 1/8.
>
> However, now I realize that we are not actually counting the *length* of
> a group but rather its metric situation. And I think that's the right
> way because this is how the performer gets the right information to
> "navigate" complex situations.
>
> OTOH this feature seems to have been welcomed during review, so I
> wouldn't want to silently revert that now. I had the idea to also add an
> option for this. If you consider the attached image, what would you suggest:
>
> a)
> Always do the first version (i.e. strictly beam according to metric
> position)
>
> b)
> Always do the second version (i.e. shorten to indicate the shortened
> length of the beam)
>
> c)
> Take a) as the default and provide a context property
>
> ?
> Urs
>
> ___
> 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: Handling of subdivisions with shortened beams

[Urs Liska]

Am 18.01.2016 um 18:24 schrieb Kieren MacMillan:
> Hi Urs,
>
>> c)
>> Take a) as the default and provide a context property
> This.
>
> Thanks,
> Kieren.
>

Any suggestions for a better name than

\set subdividedBeamCountAddForShortenedBeam = ##t

?

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

Re: Configuring beam count at subdivisions

[Urs Liska]

Am 18.01.2016 um 18:28 schrieb Kieren MacMillan:
> Hi Urs,
>
>> deep in my heart I also feel we shouldn't support incorrect notation
> Well, okay, then… Let's eliminate the ability to move NoteHead to the wrong 
> side of Stem, block \rotate from affecting e.g., Rest, etc. etc.  ;)
>
> Just a Devil’s Advocate-y way of saying: I completely agree that Lilypond 
> should *encourage* correct notation, but not necessarily eliminate *user 
> options*.
>
> We just provide the rope — it’s up to the user to tie a bowline or noose, as 
> desired or appropriate.
>
> My 2¢.
> Kieren.

Hm.
Actually it's about adding two lines of code and adding one entry in a
Scheme list ...

So I'll keep the option #'one in for now, may people object during
review or not ...
(If I should ever get to that state, this whole subject is getting more
complex with each iteration. I'm astonished that the code hasn't grown
to enormous amounts by now and that it was always possible to condense
the conditionals to a reasonable amount. But I still haven't really
tackled rests under beams (which had some unnoticed bugs already), and
my first attempts indicate that they are quite nasty ...

If I had realized that before I probably wouldn't have touched it - so
fortunately I didn't expect ... ;-)

Urs

> 
>
> 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: Handling of subdivisions with shortened beams

[Kieren MacMillan]

Hi all,

> the options seem to be complex enough to be better stored in an alist.

Agreed!
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: Handling of subdivisions with shortened beams

[Simon Albrecht]

On 18.01.2016 18:27, Urs Liska wrote:

Am 18.01.2016 um 18:24 schrieb Kieren MacMillan:

Hi Urs,


c)
Take a) as the default and provide a context property

This.

Thanks,
Kieren.


Any suggestions for a better name than

 \set subdividedBeamCountAddForShortenedBeam = ##t


It would almost call for
\override Beam.subdivide-details.ignore-shortening = ##f
(this would be the default). Still a bit clumsy, and I don’t want to 
upturn your plans. But the options seem to be complex enough to be 
better stored in an alist.

Just my 2cts,
Simon

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

Re: Configuring beam count at subdivisions

[Urs Liska]

Thanks for the feedback.

off-list I got one strong opinion against providing the #'one option
because it's incorrect.

I know it's incorrect, and that's why I had asked for an improvement
around a year ago.
However, it's the way everybody is used to, and that's why some might
still *want* to engraver their scores that way.

Apart from LilyPond < 2.19.21 this is what Sibelius and Finale users can
achieve automatically (except for drawing the extra secondary beams
manually ...).

Well, deep in my heart I also feel we shouldn't support incorrect
notation, and so I'm inclined to throw it out again (no big deal of
course) and only provide the #'base-moment option.
While I wouldn't use it personally I can think of scores where the new
default beaming (with differing beam numbers on the different positions)
might look too inconsistent.

Urs

Am 18.01.2016 um 17:32 schrieb Urs Liska:
> Hi again,
>
> some aspects of the discussion about beaming made me realize again that
> we shouldn't always/only look for "the" solution but rather provide the
> choices and set a sensible default. And this is probably true also for
> the beam count at subdivisions.
>
> Earlier (up to ca. 2.19.20) LilyPond always returned one beam at a beam
> subdivision.
> After that the beam count at subivisions were governed by their metric
> position (which had been my first request).
> Later this was modified again, and the beam count was goverend by the
> baseMoment property (i.e. when baseMoment was set to 1/16 all
> subdivisions got two beams. (This is the state in 2.19.34).
> 2.19.35 shows the behaviour of >2.19.21 again.
>
> Today I realized we should provide all of these options and set the
> "metric position" approach as the default.
> The attached image shows three renderings of a phrase, with
> subdivideBeams set to true and baseMoment set to 1/16.
>
> The first line is the default result,
> the second with \set subdividedBeamCount = #'base-moment
> and the third with \set subdividedBeamCount = #'one
>
> This gives arguably the best option as default and still gives
> Sibelius-converts the chance to redo their familiar shortcomings ;-)
>
> Opinions?
>
> Best
> Urs
>
>
> ___
> 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

Handling of subdivisions with shortened beams

[Urs Liska]

One more from this round of review ...

I had changed the subdivision behaviour (which is already in 2.19.35)
for shortened beams.

c32 [ c c c c c c] r

(i.e. a beam shortened by 1/32) subdivided by 1/8 currently has *two*
beams at the subdivision - to indicate that the remaining group is
shorter than 1/8.

However, now I realize that we are not actually counting the *length* of
a group but rather its metric situation. And I think that's the right
way because this is how the performer gets the right information to
"navigate" complex situations.

OTOH this feature seems to have been welcomed during review, so I
wouldn't want to silently revert that now. I had the idea to also add an
option for this. If you consider the attached image, what would you suggest:

a)
Always do the first version (i.e. strictly beam according to metric
position)

b)
Always do the second version (i.e. shorten to indicate the shortened
length of the beam)

c)
Take a) as the default and provide a context property

?
Urs

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

Re: Configuring beam count at subdivisions

[Simon Albrecht]

On 18.01.2016 18:12, Urs Liska wrote:

Thanks for the feedback.

off-list I got one strong opinion against providing the #'one option 
because it's incorrect.


‘Because it’s incorrect’ being one of the weaker arguments. Actually it 
impedes legibility, so…




I know it's incorrect, and that's why I had asked for an improvement 
around a year ago.
However, it's the way everybody is used to, and that's why some might 
still *want* to engraver their scores that way.


Apart from LilyPond < 2.19.21 this is what Sibelius and Finale users 
can achieve automatically (except for drawing the extra secondary 
beams manually ...).


Well, deep in my heart I also feel we shouldn't support incorrect 
notation, and so I'm inclined to throw it out again (no big deal of 
course) and only provide the #'base-moment option.
While I wouldn't use it personally I can think of scores where the new 
default beaming (with differing beam numbers on the different 
positions) might look too inconsistent.


no matter whether it would ‘look inconsistent’ it would aid the 
performer to decipher the actual rhythm. If it’s a mere aestheticist 
idiosyncracy of the composer and practical considerations don’t matter – 
so be it. But I think it’s a strong point in LilyPond that it’s not only 
about beauty.
With perhaps a good explanation of this in the docs, I agree that we 
don’t need the #'one option.


Yours, Simon

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

Re: Handling of subdivisions with shortened beams

[Kieren MacMillan]

Hi Urs,

> c)
> Take a) as the default and provide a context property

This.

Thanks,
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: Configuring beam count at subdivisions

[Kieren MacMillan]

Hi Urs,

> deep in my heart I also feel we shouldn't support incorrect notation

Well, okay, then… Let's eliminate the ability to move NoteHead to the wrong 
side of Stem, block \rotate from affecting e.g., Rest, etc. etc.  ;)

Just a Devil’s Advocate-y way of saying: I completely agree that Lilypond 
should *encourage* correct notation, but not necessarily eliminate *user 
options*.

We just provide the rope — it’s up to the user to tie a bowline or noose, as 
desired or appropriate.

My 2¢.
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: Lilypond and Jazz chords

[Kieren MacMillan]

Hi David,

> Here's my take on how to do this more transparently: first have an
> engraver that does the basic chord analysis and writes one or several
> properties with the basic analysis results (like fundamental pitch and
> scale offsets).  Those properties are made part of text-interface.
> 
> Then have several markup commands producing output based on those
> properties.  Like German chord names, or a markup list with
> modifications and stuff like that.  And then you can basically create
> one fixed markup for each chord naming style and assign that to the
> "text" field of a ChordName.
> 
> Also it then becomes easy to put chord names into a TextScript

That all sounds great. If the engraver broke the chord components into the 
smallest possible bits (e.g., root, quality, third stack, alterations, bass or 
inversion), then the NameBuilder (or whatever) could format those however one 
pleased.

However, I’m also concerned that the current input syntax isn’t rich enough. 
For example, one can’t tell Lilypond “at run time" if  should be 
labelled as Bb/C or C7(sus2,sus4). [Note that, at this point, I don’t care what 
anyone’s preference for display of this chord is — I’m simply pointing out that 
I don’t know of a mechanism to force Lilypond to label the same set of notes 
two or more different ways.] So we should attack the input mode as well, to 
support the widest and most flexible possible usage.

Best regards,
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: Lilypond and Jazz chords

[Robert Schmaus]

,
> 
>> it involves the (fantastic) LilyJazz package which was created by Thorsten 
>> Hämmerle some time ago.
> 
> Why are the alterations in the chord names not LilyJazz?

Well, now that you mention it, they might well be. It's been quite some time 
since I worked on that. What I *am* sure of is that I defined all chord layouts 
myself - like the bracketed stacks, or should I use  Dø7 or rather Dmin7b5 for 
a half-diminished chord and so on. 

It is possible though that all tools for doing that are already present in 
LilyJazz ... I simply don't remember now.

Cheers, Robert 

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

Re: temporarily escaping chordmode

[Kieren MacMillan]

Hi Simon,

> In case you should need that for which you initially asked :-) – there’s 
> \notemode {}. Normally implicit, it can be used in special situations such as 
> this.

That’s what I was looking for! Thanks.
I think I will need this for tagged non-chord material (e.g., split Voice 
constructions) which I have had difficulty coding.

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: temporarily escaping chordmode

[Kieren MacMillan]

Hi David,

>\chordmode { \clef bass  c/e  c/e }
>or other ways of explicitly spelling out some not-really chord material.

On a related note, I discovered yesterday — quite by accident — the output of

\chordmode { c1:1 }

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: Microtonal notation - arrows up and down

[Graham Breed]

On 13/01/16 16:53, Luca Danieli wrote:


I tried to find information on how to do it on internet, but I am unable to 
find anything.
I am sorry to continuously asking, but can you give me any hint on how to do it?


I think this is what you want:

arrowGlyphs = #`(
(,DOUBLE-SHARP . "accidentals.doublesharp")
(,SHARP-RAISE  . "accidentals.sharp.arrowup")
(,SHARP. "accidentals.sharp")
(,SHARP-LOWER  . "accidentals.sharp.arrowdown")
(,NATURAL-RAISE . "accidentals.natural.arrowup")
(  0. "accidentals.natural")
(,NATURAL-LOWER . "accidentals.natural.arrowdown")
(,FLAT-RAISE   . "accidentals.flat.arrowup")
(,FLAT . "accidentals.flat")
(,FLAT-LOWER   . "accidentals.flat.arrowdown")
(,DOUBLE-FLAT  . "accidentals.flatflat")
(,(/ SHARP 2) . "accidentals.sharp.slashslash.stem")
(,(/ FLAT 2) . "accidentals.mirroredflat")
(,(* SHARP 3/2) . "accidentals.sharp.slashslash.stemstemstem")
(,(* FLAT 3/2) . "accidentals.mirroredflat.flat"))
)


(I tried to update all the software in Ubuntu, but I am already the newest 
version)

Kind regards,
Luca



Subject: RE: Microtonal notation - arrows up and down
To: lilypond-user@gnu.org
From: gbr...@gmail.com
Date: Tue, 12 Jan 2016 20:01:53 +


Date: Mon, 11 Jan 2016 19:39:06 +0100
From: Luca Danieli



It works perfectly! I understand that I need to rename ALL pitches, otherwise 
the building fails.The only problem now is that I have lost the default 
microtonal symbols.
So for example, how do I re-write the default symbol ceh (to have the symbol 
"d")?
In your example it is: (ceh . ,(ly:make-pitch -1 0 (/ FLAT 2))), but this 
doesn't show any accidental.
(I can't find information on internet)


The accidentals are listed in the "arrowGlyphs" object.  You need to
update that to match the names.




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

Re: Lilypond and Jazz chords

[Carl-Henrik Buschmann]

This is smashing! Great job. 

The alignment of the chords, is it possible to push above the staff like 
traditional chords? The 8, is it part of a multi rest? 



> 18. jan. 2016 kl. 11.40 skrev Robert Schmaus :
> 
> 
> --
> Note beforehand: I'm sending this from a phone, and I can't control if the 
> attached picture is sent inline or not - hope you can see it, otherwise I'll 
> have to resend it later today. 
> --
> 
> Hi Carl-Henrik,
> 
> Fwiw, I write jazz sheets all the time, and I've trimmed Lilypond to produce 
> stuff like this:
> 
> 
> 
> So, Lilypond is quite able to produce those complex chords you mention. This 
> is definitely not out of the box though ... I've put quite some work into it. 
> But I guess it goes along the lines of what Kieren sent you earlier ...
> 
> The question if it is sensible to go that way is something else.
> 
> Best, Robert 
> 
> 
> 
> On 17 Jan 2016, at 20:30, Carl-Henrik Buschmann  > wrote:
> 
>> Sorry, thought the thread was referenced. 
>> 
>> I'm wondering if lilypond is able to notate complex chords, as discussed in 
>> the before mentioned thread. 
>> Examples as shown: 
>> 
>> 
>> 
>>> Den 17. jan. 2016 kl. 20.18 skrev Thomas Morley >> >:
>>> 
>>> 2016-01-17 19:55 GMT+01:00 Carl-Henrik Buschmann >> >:
 Any news regarding this?
>>> 
>>> 
>>> 
>>> Well, what's "this"?
>>> LilyPond exists, yes. There is no common definiton of "JazzChords".
>>> So, no news. ;)
>>> Maybe you may want to be a little more specific?
>>> 
>>> Cheers,
>>> Harm
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/lilypond-user 
>> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: Lilypond and Jazz chords

[Johan Vromans]

On Mon, 18 Jan 2016 11:40:47 +0100
Robert Schmaus  wrote:

> Fwiw, I write jazz sheets all the time, and I've trimmed Lilypond to
> produce stuff like this:

Nice, very nice!
It's a shame the "8" won't match...

I've tried to obtain something like this some years ago, but never got as
far as your example. 

-- Johan

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

Re: Lilypond and Jazz chords

[Robert Schmaus]

Thanks! 
I can post the code for that if you're interested, I just can't promise I'll be 
able to do that tonight. And it involves the (fantastic) LilyJazz package which 
was created by Thorsten Hämmerle some time ago.
If can get a hold of that, and put it together with Kieren's suggestions, 
that's basically it - the rest is routine work ...

As for the 8 - this is actually a percent repeat counter that simply ticks off 
every n-th repeat for easier readability. You're right - I should set the 
"jazz-font" for it also. It's not a big deal, too ... 

The chords usually *are* above the staff lines - like here:



The chords of my first posting were from a solo passage (I sometimes engrave 
the solo passages separately for easier overview during soloing), and I prefer 
solo changes to be placed within the staff for compactness as well as clarity. 

Best, Robert 


__

The cure for a fallacious argument is a better argument, not the suppression of 
ideas.
-- Carl Sagan


> On 18 Jan 2016, at 12:16, Carl-Henrik Buschmann  wrote:
> 
> This is smashing! Great job. 
> 
> The alignment of the chords, is it possible to push above the staff like 
> traditional chords? The 8, is it part of a multi rest? 
> 
> 
> 
>> 18. jan. 2016 kl. 11.40 skrev Robert Schmaus :
>> 
>> 
>> --
>> Note beforehand: I'm sending this from a phone, and I can't control if the 
>> attached picture is sent inline or not - hope you can see it, otherwise I'll 
>> have to resend it later today. 
>> --
>> 
>> Hi Carl-Henrik,
>> 
>> Fwiw, I write jazz sheets all the time, and I've trimmed Lilypond to produce 
>> stuff like this:
>> 
>> 
>> 
>> So, Lilypond is quite able to produce those complex chords you mention. This 
>> is definitely not out of the box though ... I've put quite some work into 
>> it. But I guess it goes along the lines of what Kieren sent you earlier ...
>> 
>> The question if it is sensible to go that way is something else.
>> 
>> Best, Robert 
>> 
>> 
>> 
>>> On 17 Jan 2016, at 20:30, Carl-Henrik Buschmann  wrote:
>>> 
>>> Sorry, thought the thread was referenced. 
>>> 
>>> I'm wondering if lilypond is able to notate complex chords, as discussed in 
>>> the before mentioned thread. 
>>> Examples as shown: 
>>> 
>>> 
>>> 
 Den 17. jan. 2016 kl. 20.18 skrev Thomas Morley :
 
 2016-01-17 19:55 GMT+01:00 Carl-Henrik Buschmann :
> Any news regarding this?
 
 
 
 Well, what's "this"?
 LilyPond exists, yes. There is no common definiton of "JazzChords".
 So, no news. ;)
 Maybe you may want to be a little more specific?
 
 Cheers,
 Harm
>>> ___
>>> lilypond-user mailing list
>>> lilypond-user@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond and Jazz chords

[Kieren MacMillan]

Hi Robert,

> it involves the (fantastic) LilyJazz package which was created by Thorsten 
> Hämmerle some time ago.

Why are the alterations in the chord names not LilyJazz?

> If can get a hold of that, and put it together with Kieren's suggestions, 
> that's basically it - the rest is routine work …

Not exactly… The input mode/syntax isn’t rich enough (IMO) to allow for 
complete flexibility.

> The chords of my first posting were from a solo passage (I sometimes engrave 
> the solo passages separately for easier overview during soloing), and I 
> prefer solo changes to be placed within the staff for compactness as well as 
> clarity.

I personally love the way that looks.

Thanks,
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: Configuring beam count at subdivisions

[Simon Albrecht]

On 18.01.2016 17:32, Urs Liska wrote:

This gives arguably the best option as default and still gives
Sibelius-converts the chance to redo their familiar shortcomings ;-)

Opinions?


LGTM :-)

Best, Simon

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

Configuring beam count at subdivisions

[Urs Liska]

Hi again,

some aspects of the discussion about beaming made me realize again that
we shouldn't always/only look for "the" solution but rather provide the
choices and set a sensible default. And this is probably true also for
the beam count at subdivisions.

Earlier (up to ca. 2.19.20) LilyPond always returned one beam at a beam
subdivision.
After that the beam count at subivisions were governed by their metric
position (which had been my first request).
Later this was modified again, and the beam count was goverend by the
baseMoment property (i.e. when baseMoment was set to 1/16 all
subdivisions got two beams. (This is the state in 2.19.34).
2.19.35 shows the behaviour of >2.19.21 again.

Today I realized we should provide all of these options and set the
"metric position" approach as the default.
The attached image shows three renderings of a phrase, with
subdivideBeams set to true and baseMoment set to 1/16.

The first line is the default result,
the second with \set subdividedBeamCount = #'base-moment
and the third with \set subdividedBeamCount = #'one

This gives arguably the best option as default and still gives
Sibelius-converts the chance to redo their familiar shortcomings ;-)

Opinions?

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

Re: Configuring beam count at subdivisions

[Kieren MacMillan]

Hi Urs,

> This gives arguably the best option as default and still gives
> Sibelius-converts the chance to redo their familiar shortcomings ;-)
> 
> Opinions?

LGreatTM!

Thanks for doing this.
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: Handling of subdivisions with shortened beams

[Urs Liska]

Am 18.01.2016 um 18:37 schrieb Simon Albrecht:
> On 18.01.2016 18:27, Urs Liska wrote:
>> Am 18.01.2016 um 18:24 schrieb Kieren MacMillan:
>>> Hi Urs,
>>>
 c)
 Take a) as the default and provide a context property
>>> This.
>>>
>>> Thanks,
>>> Kieren.
>>>
>> Any suggestions for a better name than
>>
>>  \set subdividedBeamCountAddForShortenedBeam = ##t
> 
> It would almost call for
> \override Beam.subdivide-details.ignore-shortening = ##f
> (this would be the default). Still a bit clumsy, and I don’t want to
> upturn your plans. But the options seem to be complex enough to be
> better stored in an alist.

I find this a very good idea. I don't feel very good with inventing
arbitrary independent context properties. Having a single object and
consistent interface would make it much more consistent to add more
configuration options to the beaming.

That wouldn't bother my "plans" at all, it's just that I don't know out
of my hat where to define (and initialize) such an alist and how to
access its value from within the C++ beaming code. So any hints welcome ...

Best
Urs

> Just my 2cts,
> Simon




-- 
Urs Liska
www.openlilylib.org

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

Swedish letters in Lilypond lyrics?

[Karin]

Hi!



I have just recently discovered the world of Lilypond and was really 
pleased as long as I wrote the lyrics in English. When switching to Swedish 
I ran into trouble. There are three specific characters in Swedish and only 
onle of them is available in the Lilypond "list of special characters". I 
need the letters å, ä, ö, Å, Ä and Ö - or as a HTML-person would put it: 
 

Can you help me fix this? I have only found  and  which corresponds 
to the HTML-ish  and 



Please help!

Regards,

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

Re: Swedish letters in Lilypond lyrics?

[karl]

Karin:
> I have just recently discovered the world of Lilypond and was really 
> pleased as long as I wrote the lyrics in English. When switching to Swedish 
> I ran into trouble. There are three specific characters in Swedish and only 
> onle of them is available in the Lilypond "list of special characters". I 
> need the letters å, ä, ö, Å, Ä and Ö - or as a HTML-person would put it: 
>  
> Can you help me fix this? I have only found  and  which corresponds 
> to the HTML-ish  and 

There is no special thing with theese, just make sure you have an 
editor that can handle utf-8.

Example:

 http://turkos.aspodata.se/git/musik/songs/pilgrimssaang_1200.ly

Regards,
/Karl Hammar

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



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

Re: Controlling hairpin length

[Thomas Morley]

Hi David,

2016-01-18 22:56 GMT+01:00 David Sumbler :

> After spending some hours trying to get to the bottom of this problem,
[...]

Well, I spend some hours creating the function(s) ;)

> I narrowed it down to 3 different elements in my files
[...]
> I feel
> that ideally an improvement in an area where Lilypond is somewhat
> unsatisfactory (so far as the user is concerned) should not at the same
> time break some other aspect(s) of the program's output,

Indeed.
Though I can't fix a problem which I didn't foresee or which wasn't reported.
Thus, thanks for your examples.

Please replace
#(define ((hairpin-minimum-length my-minimum) grob)
...

with the code below:

#(define ((hairpin-minimum-length my-minimum) grob)
  (let* ((bound-left (ly:spanner-bound grob LEFT))
 (bound-right (ly:spanner-bound grob RIGHT))
 (sys (look-up-for-parent 'System Y grob))
 (left-x-ext (ly:grob-extent bound-left sys X))
 (right-x-ext (ly:grob-extent bound-right sys X)))
(ly:grob-set-property! grob 'minimum-length
  ;; keep 'minimum-length user-settable
  (max (ly:grob-property-data grob 'minimum-length)
   ;; nb, this calculation is only an approximation
   ;; should work in most cases, though
   (+ my-minimum
  (max (cdr left-x-ext) 0)
  (max (cdr right-x-ext) 0))

Please report back, whether it works now.

Cheers,
  Harm

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

Re: Configuring beam count at subdivisions

[Carl Sorensen]

On 1/18/16 10:28 AM, "Kieren MacMillan" 
wrote:

>Hi Urs,
>
>> deep in my heart I also feel we shouldn't support incorrect notation
>
>Well, okay, thenŠ Let's eliminate the ability to move NoteHead to the
>wrong side of Stem, block \rotate from affecting e.g., Rest, etc. etc.  ;)
>
>Just a Devil¹s Advocate-y way of saying: I completely agree that Lilypond
>should *encourage* correct notation, but not necessarily eliminate *user
>options*.
>
>We just provide the rope ‹ it¹s up to the user to tie a bowline or noose,
>as desired or appropriate.

If a user wants to get the incorrect engraving, they can do it by manually
setting the beamlet count on the stem.

I don't think we should provide a setting to do it incorrectly.

Thanks,

Carl


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

Re: tuplet number

[Stanton Sanderson]

> On Jan 18, 2016, at 5:07 PM, Malte Meyn  wrote:
> 
> 
> 
>> Am 18.01.2016 um 23:52 schrieb Mark Stephen Mrotek:
>> In 2.18,
>> 
>> Tuplet - no number\override TupletNumber #'stencil = ##f
> 
> Setting the stencil to ##f is exactly what \omit does ;) (\omit already
> exists in 2.18).

A third option to your first two, which proves quite useful in my case- 
\once \undo \omit 

Thanks for the explanation!

Stan

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

ly:one-page-breaking (was: ly:one-line-breaking)

[Paul Morris]

> On Jan 9, 2016, at 1:30 PM, Richard Shann  wrote:
> 
> I was wondering if it would be possible to develop a variant of "all on
> one line", namely "all on one page", where the page height would be
> automatically adjusted to fit the music, leaving the width as set.

I’m glad to report that I’ve made some real progress.  The code in the attached 
patch delivers the basic functionality, with a few "known issues".  Namely the 
tagline and any footnotes are not included, and bookparts trigger default page 
breaking for some reason.  I haven’t tested it extensively but titles (etc.), 
top level markups, multiple scores, all seem to work just fine.

The approach is to temporarily set the page-height to the largest size 
possible, do the line breaking and page layout for that page height, then get 
the vertical position on the page and the height of the lowest system (or top 
level markup), and use that to calculate and then set the final page height so 
that it fits the content of the page.

(Also, I now see how to improve the ly:one-line-auto-height code to avoid some 
of the unintuitive results related to bottom-margin and top-system-spacing.  So 
a new patch set for that is on the way, when I can get to it...)

-Paul


%%% TEST SNIPPET %%%

\version "2.19.36"

\paper {
  % system-system-spacing.basic-distance = #0
  page-breaking = #ly:one-page-breaking
  % ragged-bottom = ##t
  % top-margin = 0
  % bottom-margin = 0
  % system-system-spacing.minimum-distance = #0
  % system-system-spacing.padding = #0
}

\header {
  % title = "a title”
  % tagline = ""
}

% \markup \large "top level markup"

\repeat unfold 100 { c’4 d' e' f’ }

\repeat unfold 10 { g'1 }

{ c,1 }

% \markup \large “another top level markup"

%




one-page-breaking-1-18-2016.patch
Description: Binary data


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

Re: Controlling hairpin length

[Thomas Morley]

2016-01-19 1:04 GMT+01:00 Thomas Morley :
> Hi David,
>
> 2016-01-18 22:56 GMT+01:00 David Sumbler :
>
>> After spending some hours trying to get to the bottom of this problem,
> [...]
>
> Well, I spend some hours creating the function(s) ;)
>
>> I narrowed it down to 3 different elements in my files
> [...]
>> I feel
>> that ideally an improvement in an area where Lilypond is somewhat
>> unsatisfactory (so far as the user is concerned) should not at the same
>> time break some other aspect(s) of the program's output,
>
> Indeed.
> Though I can't fix a problem which I didn't foresee or which wasn't reported.
> Thus, thanks for your examples.
>
> Please replace
> #(define ((hairpin-minimum-length my-minimum) grob)
> ...
>
> with the code below:
>
> #(define ((hairpin-minimum-length my-minimum) grob)
>   (let* ((bound-left (ly:spanner-bound grob LEFT))
>  (bound-right (ly:spanner-bound grob RIGHT))
>  (sys (look-up-for-parent 'System Y grob))
>  (left-x-ext (ly:grob-extent bound-left sys X))
>  (right-x-ext (ly:grob-extent bound-right sys X)))
> (ly:grob-set-property! grob 'minimum-length
>   ;; keep 'minimum-length user-settable
>   (max (ly:grob-property-data grob 'minimum-length)
>;; nb, this calculation is only an approximation
>;; should work in most cases, though
>(+ my-minimum
>   (max (cdr left-x-ext) 0)
>   (max (cdr right-x-ext) 0))

Probably even better:

#(define ((hairpin-minimum-length my-minimum) grob)
  (let* ((bound-left (ly:spanner-bound grob LEFT))
 (bound-right (ly:spanner-bound grob RIGHT))
 (sys (look-up-for-parent 'System Y grob))
 (left-x-ext (ly:grob-extent bound-left sys X))
 (right-x-ext (ly:grob-extent bound-right sys X)))
(ly:grob-set-property! grob 'minimum-length
  ;; keep 'minimum-length user-settable
  (max (ly:grob-property-data grob 'minimum-length)
   ;; nb, this calculation is only an approximation
   ;; should work in most cases, though
   (+ my-minimum
  (if (interval-sane? left-x-ext) (cdr left-x-ext) 0)
  (if (interval-sane? right-x-ext) (cdr right-x-ext) 0))

>
> Please report back, whether it works now.
>
> Cheers,
>   Harm

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

Re: Top margin

[Carl Sorensen]

On 1/18/16 3:30 PM, "Sharon Rosner"  wrote:

>In many cases this would not be such a problem, as the highest object on
>the
>top staff would be the bar number. But in cases where there are high notes
>on ledger lines, or other objects high above the top staff, this would
>lead
>to the distance between the top of the page and the actual top line of the
>top staff changing from page to page, which creates a somewhat unpleasant
>appearance for facing pages.
>
>So, am I missing something or is this the expected behavior for Lilypond?
>Is
>this something that can be changed in some way?

In LilyPond, there is always a way to change it.  If you would prepare a
two-page example that demonstrates the problem, we can have a go at fixing
it.  

You can certainly set the top staff on each page at an absolute position
as described in 
http://lilypond.org/doc/v2.18/Documentation/notation/explicit-staff-and-sys
tem-positioning

But it would be more convenient to do it automatically with LilyPond
parameters.  I believe that one convenient way to do it is by setting the
stretchability of top-system-spacing to zero.
See 
http://lilypond.org/doc/v2.18/Documentation/notation/flexible-vertical-spac
ing-paper-variables

Of course, at that point you will need to make sure you have left enough
space for whatever might be at the top of your staff by setting the
appropriate value of basic-distance.

Similarly, you should be able to fix the location of the bottom staff by
setting the stretchability of last-bottom-spacing to zero.  And a similar
note about the basic-distance of last-bottom-spacing also applies.

Finally, you should make sure that basic-distance and minimum-distance are
equal for both of these spacing values, since that will set the
compressibility to zero as well.

HTH,

Carl


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

Re: Swedish letters in Lilypond lyrics?

[Andrew Bernard]

Hi Karin,

Lilypond is Unicode aware. HTML escape codes have no relevance to lilypond. Any 
editor that supports Unicode will allow you to type Swedish, and there is no 
need for ‘special characters’.

Frescobaldi is highly recommneded as a lilypond programming environment.

Andrew


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

Re: Lilypond and Jazz chords

[timmcn]

> On Jan 18, 2016, at 1:44 AM, Carl-Henrik Buschmann  
> wrote:
> 
> 
>> 18. jan. 2016 kl. 02.40 skrev tim...@bitstream.net:
>> 
>>> 
>>> On Jan 17, 2016, at 4:16 PM, Carl-Henrik Buschmann  
>>> wrote:
>>> 
>>> While i might agree with you to some extent this is also a practial matter: 
>>> 
>>> 1) Whether or not you call it maj or *triangle*, m or MI is indeed a matter 
>>> of culture and personal taste. But consider the following: A C7, a 
>>> dominant, might tell a performing musician lots but when dealing with 
>>> academic and analysis it is quite thin if the actual sounding timbre is a 
>>> C13(b9), also a dominant, but allowed for when performing certain styles. 
>>> What the composer/arranger chooses to do, is a different case than the 
>>> needs of the academic (and specific composer/arranger).
>> 
>> Perhaps.  Musicality and practicality often seem secondary in academic 
>> pursuits as it is the idea that seems primary, not the resultant. 13b9 
>> chords are common enough in jazz, though, although practically speaking in 
>> improvisation it is often more fruitful to think of them as a polychord- C7 
>> with A major triad superimposed in this case- as this offers more options.
> 
> While i agree on this way of thinking *practically* makes a lot of sense. But 
> you are talking about changing a whole culture of thinking. To sum up: 
> Stacked chords are useful for in some musical settings but it is not the 
> future as of yet as they do not display function.

True, if one is focusing on writing out functional harmony the use of 
polychords can obscure that to a degree.

> Although the ever singing chorus here on lilypond-user is that there is no 
> agreed apon conventions in chords, i disagree both as a musician and a 
> scholar. The way to notate jazz/pop chords are established thoroughly through 
> the "real book" series and others. 

As an American jazz musician- hmm, attempted jazz musician would be more 
accurate- I agree that the Real Book has become the de facto standard for most 
jazz musicians.  It’s been some 40 years that those books have been around now, 
several generations of musicians are used to them.  Although the Real Books are 
inconsistent in how complex chords are written out- some have the extensions 
written out horizontally, some are parenthesized, some are parenthesized and 
stacked, etc.

> Kieren is thankfully working on this and i hope the brains that code for 
> lilypond can bash heads together and at least give us a *working* solution 
> and stop bickering over personal preferences that only hinder the 
> development. 

I have had a cobbled-together Brandt-Roemer chord exceptions file modified from 
the pop-chords.ly file for a couple of years, Kieran’s is going to be much more 
comprehensive and rigorous than mine is and I am looking forward to it.  One 
advantage of the B-R system is that when I hand out lead sheets to other 
musician, no one ever asks what the chord symbols mean.

>>> 2) There is also the matter of spacing. Cmaj7 #5 b9 #11/F# is stealing a 
>>> whole system! That is insane (in the membrane!) and i stand by my statement 
>>> that the default output of lilypond is undesirable.
>> 
>> Which is why you can create chord exceptions to the default behavior.
>> 
>> Excessive definition of chords restricts the freedom of the musician- for 
>> jazz, maximizing freedom is more useful.
> 
> I see your point and I agree.

Between my quoted response and the subsequent one to Kieran I thought about 
intended purpose.  If you’re creating a chart to use on the bandstand it may 
look different than one being created for analytical or academic purposes.  The 
latter is intended to elucidate the concepts at work and the greater 
specificity of a C13b9 rather than a C7 is probably necessary; never having 
done academic music study I do not tend to think of this.  My apologies for not 
having considered this sooner in the discussion.

Tim



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

Compressing percent repeats.

[Hwaen Ch'uqi]

Greetings All,

I am generating parts from an orchestral score and am wondering if
there is any way of handling percent repeats in the same manner as
\compressFullBarRests does for multimeasure rests? That is, a number
would be placed above, say, an isolated repeat informing the player
how many times to repeat the measure; meanwhile, currentBarNumber
would be automatically updated. I see from this thread

https://lists.gnu.org/archive/html/lilypond-user/2014-02/msg00050.html

that text could be placed manually (though not optimally) above the
isolated repeat, and so too could I manually reset currentBarNumber,
but that will surely prove to be time-consuming for a piece of this
magnitude. Any help would be greatly appreciated.

Hwaen Ch'uqi

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

Re: Handling of subdivisions with shortened beams

[Werner LEMBERG]

>> b) Always do the second version (i.e. shorten to indicate the
>>shortened length of the beam)

I prefer this, and it seems to me that this would be a good default.


Werner

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

ly:one-page-breaking (was: ly:one-line-breaking)

[Paul Morris]

> On Jan 9, 2016, at 1:30 PM, Richard Shann  wrote:
> 
> I was wondering if it would be possible to develop a variant of "all on
> one line", namely "all on one page", where the page height would be
> automatically adjusted to fit the music, leaving the width as set.

I’m glad to report that I’ve made some real progress.  The code in the attached 
patch delivers the basic functionality, with a few "known issues".  Namely the 
tagline and any footnotes are not included, and bookparts trigger default page 
breaking for some reason.  I haven’t tested it extensively but titles (etc.), 
top level markups, multiple scores, all seem to work just fine.

The approach is to temporarily set the page-height to the largest size 
possible, do the line breaking and page layout for that page height, then get 
the vertical position on the page and the height of the lowest system (or top 
level markup), and use that to calculate and then set the final page height so 
that it fits the content of the page.

-Paul


%%% TEST SNIPPET %%%

\version "2.19.36"

\paper {
 % system-system-spacing.basic-distance = #0
 page-breaking = #ly:one-page-breaking
 % ragged-bottom = ##t
 % top-margin = 0
 % bottom-margin = 0
 % system-system-spacing.minimum-distance = #0
 % system-system-spacing.padding = #0
}

\header {
 % title = "a title”
 % tagline = ""
}

% \markup \large "top level markup"

\repeat unfold 100 { c’4 d' e' f’ }

\repeat unfold 10 { g'1 }

{ c,1 }

% \markup \large “another top level markup"

%




one-page-breaking-1-18-2016.patch
Description: Binary data


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

Re: Swedish letters in Lilypond lyrics?

[Simon Albrecht]

On 19.01.2016 01:52, Andrew Bernard wrote:

Hi Karin,

Lilypond is Unicode aware. HTML escape codes have no relevance to 
lilypond.


There are the text replacements, see NR A.13 (2.19.35).

Best, Simon

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

Re: Swedish letters in Lilypond lyrics?

[karl]

Simon Albrecht:
> On 18.01.2016 22:18, k...@aspodata.se wrote:
> > Simon Albrecht:
> >> On 18.01.2016 22:03, Karin Glasmästar wrote:
> >>> Now I found the way to what Karl wrote: I am using the built-in
> >>> crude editor of Lilypond itself - doesn't that editor support UTF-8?
> >> I don’t know, I’m not even sure if there is a Linux version of it. Anybody?
> > As far as I know there is no "built-in" editor in lilypond.
> 
> Yes, there is LilyPad. But I don’t know any more about it.
...

I see. It is mentioned in the learning manual:

http://lilypond.org/doc/v2.18/Documentation/learning/macos-x
http://lilypond.org/doc/v2.18/Documentation/learning/windows

shouldn't it be considered a bug if it cannot handle utf-8 (like åäö) ?

Regards,
/Karl Hammar

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



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

Re: tuplet number

[Malte Meyn]

Am 18.01.2016 um 23:46 schrieb Stanton Sanderson:
> How does one revert  \omit TupletNumber to allow the number to appear for a 
> specific tuplet?

There are two options:

1. If you want to omit only one TupletNumber you can use \once:
… \once \omit TupletNumber \tuplet …
2. Revert the \omit using \undo:
… \omit TupletNumber \tuplet … \undo \omit TupletNumber …

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

Re: tuplet number

[Malte Meyn]

Am 18.01.2016 um 23:52 schrieb Mark Stephen Mrotek:
> In 2.18,
> 
> Tuplet - no number\override TupletNumber #'stencil = ##f

Setting the stencil to ##f is exactly what \omit does ;) (\omit already
exists in 2.18)

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

Re: Swedish letters in Lilypond lyrics?

[Simon Albrecht]

On 18.01.2016 22:03, Karin Glasmästar wrote:

Now I found the way to what Karl wrote: I am using the built-in crude editor of 
Lilypond itself - doesn't that editor support UTF-8?


I don’t know, I’m not even sure if there is a Linux version of it. Anybody?

Best, Simon



BR,
Karin



Den mån 2016-01-18 skrev Simon Albrecht :

  Ämne: Re: Swedish letters in Lilypond lyrics?
  Till: "Karin" , lilypond-user@gnu.org
  Datum: måndag 18 januari 2016 21:47
  
  On 18.01.2016 20:33, Karin wrote:

  > Hi!
  >
  > I have just recently discovered the world of Lilypond
  and was really
  > pleased as long as I wrote the lyrics in English. When
  switching to Swedish
  > I ran into trouble. There are three specific characters
  in Swedish and only
  > onle of them is available in the Lilypond "list of
  special characters". I
  > need the letters å, ä, ö, Å, Ä and Ö - or as a
  HTML-person would put it:
  >
   
  >
  > Can you help me fix this? I have only found 
  and  which corresponds
  > to the HTML-ish  and 
  
  As Karl pointed out: the easiest way is to just include them

  plain into
  your input file, since LilyPond has no problem with UTF-8
  input.
  In case you should really need ASCII-only input for whatever
  reason,
  there’s the markup command \char:
  \markup\concat { \char ##x00E4 \char ##x00F6 \char ##x00C4
  \char ##x00D6 }
  
  HTH, Simon



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

Re: Swedish letters in Lilypond lyrics?

[Simon Albrecht]

Hi Karin,

first: we use to keep all the discussions on-list. Thus others may step 
in (e.g. if I cannot help with the editor you are using – which is 
likely…) or retrieve the information from the list archives.


On 18.01.2016 21:58, Karin Glasmästar wrote:

Hi!
Thanks for fast answer. It's just that all my å, ä, ö letters are ignored by Lilypond 
when compiling! Here is my source and the pdf. The text should read "Det satt en mås 
på en klyarbom och tom i krävan var kräket"... Any suggestion as to what is wrong?


The input file seems to be wrongly encoded, so you should look if you 
can find an option in your editor to save it in UTF-8 encoding.


Best, Simon





BR,
Karin


Den mån 2016-01-18 skrev Simon Albrecht :

  Ämne: Re: Swedish letters in Lilypond lyrics?
  Till: "Karin" , lilypond-user@gnu.org
  Datum: måndag 18 januari 2016 21:47
  
  On 18.01.2016 20:33, Karin wrote:

  > Hi!
  >
  > I have just recently discovered the world of Lilypond
  and was really
  > pleased as long as I wrote the lyrics in English. When
  switching to Swedish
  > I ran into trouble. There are three specific characters
  in Swedish and only
  > onle of them is available in the Lilypond "list of
  special characters". I
  > need the letters å, ä, ö, Å, Ä and Ö - or as a
  HTML-person would put it:
  >
   
  >
  > Can you help me fix this? I have only found 
  and  which corresponds
  > to the HTML-ish  and 
  
  As Karl pointed out: the easiest way is to just include them

  plain into
  your input file, since LilyPond has no problem with UTF-8
  input.
  In case you should really need ASCII-only input for whatever
  reason,
  there’s the markup command \char:
  \markup\concat { \char ##x00E4 \char ##x00F6 \char ##x00C4
  \char ##x00D6 }
  
  HTH, Simon



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

Re: Swedish letters in Lilypond lyrics?

[karl]

Simon Albrecht:
> On 18.01.2016 22:03, Karin Glasmästar wrote:
> > Now I found the way to what Karl wrote: I am using the built-in
> > crude editor of Lilypond itself - doesn't that editor support UTF-8?
> I don’t know, I’m not even sure if there is a Linux version of it. Anybody?

As far as I know there is no "built-in" editor in lilypond.
Maybe something was setup for you when you installed lilypond.

What system are you using, linux/unix, MS-window or Apple MacOS-X
(I can help you with linux/unix, but not with the others) ?

Regards,
/Karl Hammar

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



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

Top margin

[Sharon Rosner]

Hello

I'm currently exploring layout in lilypond and have come across a problem
which I haven't noticed before and it's kind of a show stopper for me. In
Elaine Gould's excellent "Behind bars" she states:

"Match the levels of top and bottom staves across facing pages, regardless
of whether the pages have the same number of staves.

Ideally pages should have consistent top and bottom stave levels throughout
a piece." (p. 487)

I take this to mean that that the top stave lines should be at the same
distance from the top of the page throughout a piece, or at least on facing
pages. But apparently, this kind of constraint is not really possible with
lilypond. Experimenting a bit with setting top-margin, I noticed that this
setting determines the distance from the top edge of the page to the stave's
"skyline", and this assuming the header markup is turned off.

In many cases this would not be such a problem, as the highest object on the
top staff would be the bar number. But in cases where there are high notes
on ledger lines, or other objects high above the top staff, this would lead
to the distance between the top of the page and the actual top line of the
top staff changing from page to page, which creates a somewhat unpleasant
appearance for facing pages.

So, am I missing something or is this the expected behavior for Lilypond? Is
this something that can be changed in some way?

I also have a related question about headers and footers. I noticed that the
documentation does not discuss at all the relation between headers, footers
and page margins. How do the headers and footers affect page margins? Do
they just gobble up space at the printable edges?

Thanks
Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Top-margin-tp186119.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

tuplet number

[Stanton Sanderson]

How does one revert  \omit TupletNumber to allow the number to appear for a 
specific tuplet? In the following example, I would like to show the tupet 
number in the second measure. Thanks in advance.

Stan

\version "2.19.35"
 \relative c'' {
c   \omit TupletNumber   \tuplet 3/2 {c4 b8} c4 c |
c  % \omit TupletNumber   
\tuplet 3/2 {c4 b8} c4 c |
}


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

Re: Controlling hairpin length

[David Sumbler]

On Sun, 2016-01-17 at 20:15 +0100, Thomas Morley wrote:
> 2016-01-17 19:21 GMT+01:00 David Sumbler :
> 
> >
> > The only trouble is, I am getting a lot of compiler errors and warnings.
> > For each of the relevant layout blocks, I get:
> >
> > programming error: infinite rod
> > continuing, cross fingers
> >
> > and then numerous instances of:
> >
> > programming error: ignoring weird minimum distance
> > continuing, cross fingers
> >
> > In the cases of the 2nd violin and the viola, this latter message is
> > printed 50 times each for the 3rd movement alone - quite a lot for a
> > movement with only 64 bars!  And there are certainly well over 1,000 of
> > these errors for the whole quartet (score and parts).
> >
> > Have you come across this behaviour?
> 
> 
> 
> In one word: no.
> Please try to boil it down to minimal example otherwise I can't help.
> 
> Cheers,
>   Harm

After spending some hours trying to get to the bottom of this problem, I
narrowed it down to 3 different elements in my files which were causing
these hundreds of error messages when \myHairpinMinimumLength was set.
There were not hundreds of triggers in my files: but it seems that, once
triggered, the hairpin routine couldn't sort itself out for the
remainder of a movement and so kept on repeating the same message.

The first element that caused the errors was my occasional use of \invP,
defined as:
invP = \tweak stencil ##f \p

I have used this in a few places, rather than \! to terminate a hairpin.
I do this as an easy way to finish a diminuendo just before a notehead
so that the note in question does not appear to be included within the
diminuendo.

The second thing that gave rise to problems was the following bar:
d'2..*6/7 \sf\> s8\! e,8~\< |
I had done this so that there would be more space between the diminuendo
hairpin and the following crescendo hairpin.  I wanted it to be clear
that the new crescendo actually begins with the second note.

The third item that caused "infinite rod" and "weird minimum distance"
errors was the following (all 4 quartet instruments in "parallelMusic"):

<< b1\fermata {s2..\> s8\!} >> |
<< c1\fermata {s2..\> s8\!} >> |
<< e1\fermata {s2..\> s8\!} >> |
<< b1\fermata {s2..\> s8\!} >> |

My reason for using this was, again, to try to control the position of
the end of the diminuendo hairpins.

No doubt none of these 3 examples is very elegant, and they are very
likely not the best way of achieving the result I want.  But they worked
perfectly well until I used the improved hairpin length routine.  I feel
that ideally an improvement in an area where Lilypond is somewhat
unsatisfactory (so far as the user is concerned) should not at the same
time break some other aspect(s) of the program's output, so I am
pointing these out not as a criticism, but for information.

For the time being, perhaps, I shall have to go back to individual
tweaks for hairpin length, using trial and error to find the best
values.

Thanks again for your help.

David



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

Re: tuplet number

[Stanton Sanderson]

Mark 

Thanks for the very complete answer. Malte’s method ( \undo \omit TupletNumber 
) is almost too obvious! Both work exactly aa hoped.

Stan
> On Jan 18, 2016, at 4:52 PM, Mark Stephen Mrotek  wrote:
> 
> Stan,
> 
> In 2.18,
> 
> Tuplet - no bracket   \override TupletBracket #'bracket-visibility = ##f
> Tuplet - no number\override TupletNumber #'stencil = ##f
> Tuplet - number   \revert TupletNumber #'stencil
> 
> Mark
> 
> -Original Message-
> From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org
> [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of
> Stanton Sanderson
> Sent: Monday, January 18, 2016 2:46 PM
> To: LilyPond Users 
> Subject: tuplet number
> 
> How does one revert  \omit TupletNumber to allow the number to appear for a
> specific tuplet? In the following example, I would like to show the tupet
> number in the second measure. Thanks in advance.
> 
> Stan
> 
> \version "2.19.35"
> \relative c'' {
>c   \omit TupletNumber   \tuplet 3/2 {c4 b8} c4 c |
>c  % \omit TupletNumber   
>\tuplet 3/2 {c4 b8} c4 c |
> }
> 


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

RE: tuplet number

[Mark Stephen Mrotek]

Stan,

In 2.18,

Tuplet - no bracket \override TupletBracket #'bracket-visibility = ##f
Tuplet - no number  \override TupletNumber #'stencil = ##f
Tuplet - number \revert TupletNumber #'stencil

Mark

-Original Message-
From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of
Stanton Sanderson
Sent: Monday, January 18, 2016 2:46 PM
To: LilyPond Users 
Subject: tuplet number

How does one revert  \omit TupletNumber to allow the number to appear for a
specific tuplet? In the following example, I would like to show the tupet
number in the second measure. Thanks in advance.

Stan

\version "2.19.35"
 \relative c'' {
c   \omit TupletNumber   \tuplet 3/2 {c4 b8} c4 c |
c  % \omit TupletNumber   
\tuplet 3/2 {c4 b8} c4 c |
}


___
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: Swedish letters in Lilypond lyrics?

[Simon Albrecht]

On 18.01.2016 20:33, Karin wrote:

Hi!

I have just recently discovered the world of Lilypond and was really
pleased as long as I wrote the lyrics in English. When switching to Swedish
I ran into trouble. There are three specific characters in Swedish and only
onle of them is available in the Lilypond "list of special characters". I
need the letters å, ä, ö, Å, Ä and Ö - or as a HTML-person would put it:
 

Can you help me fix this? I have only found  and  which corresponds
to the HTML-ish  and 


As Karl pointed out: the easiest way is to just include them plain into 
your input file, since LilyPond has no problem with UTF-8 input.
In case you should really need ASCII-only input for whatever reason, 
there’s the markup command \char:

\markup\concat { \char ##x00E4 \char ##x00F6 \char ##x00C4 \char ##x00D6 }

HTH, Simon

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

Re: Swedish letters in Lilypond lyrics?

[Simon Albrecht]

On 18.01.2016 22:18, k...@aspodata.se wrote:

Simon Albrecht:

On 18.01.2016 22:03, Karin Glasmästar wrote:

Now I found the way to what Karl wrote: I am using the built-in
crude editor of Lilypond itself - doesn't that editor support UTF-8?

I don’t know, I’m not even sure if there is a Linux version of it. Anybody?

As far as I know there is no "built-in" editor in lilypond.


Yes, there is LilyPad. But I don’t know any more about it.


Maybe something was setup for you when you installed lilypond.

What system are you using, linux/unix, MS-window or Apple MacOS-X
(I can help you with linux/unix, but not with the others) ?


No matter what system you use: Frescobaldi  is 
to be highly recommended for editing LilyPond code.


Best, Simon

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

Re: Swedish letters in Lilypond lyrics?

[karl]

Martin Tarenskeen:
> On Mon, 18 Jan 2016, k...@aspodata.se wrote:
> > Example:
> > http://turkos.aspodata.se/git/musik/songs/pilgrimssaang_1200.ly

> Unfortunately not a fully working example, because of the two \include 
> statements at the beginning of the file:
> 
> \include "../include/global.ly"
> \include "../include/common.ly"

Yes, things accumulate...

It was an example of åäö in a lilypond file.

Regards,
/Karl Hammar

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



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