Re: Patch upload and LSR

[Keith OHara]

Marc Hohl  hohlart.de> writes:

> The testing process works fine on my local
> machine, but 'make doc' fails due to some
> syntax changes in the snippets. For example,
> defaultBarType = "empty" will not work once
> the patch is applied.
> 

> and I wonder if these changes should be included
> *in* the barline patch or the procedure described in the link
> above should be done *after* it is applied instead.

When you are finished with the code changes, and maybe a rule in 
convertrules.py, I would post the patch for review.  Maybe with 
a snippet after you run convert-ly by hand, if that helps to explain
the patch.

You certainly want to run makelsr and update-with-convert-ly before
creating the final patch to push.  Then the public history goes from
one stage, where everything works, to another stage, where everything 
works a little differently.  If you change the code in one commit
and the documentation/snippets later, there would be a point in the 
history where some things don't work, which can be confusing.


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

PATCH: Countdown to 20120918

[Colin Campbell]

For 20:00 MDT Tuesday September 18

Enhancement:
Issue 2612 
: Reverting 
previous: Excessive warnings for negative-spanning line spanner. - R 
6492126 
Issue 2793 
: Fret diagrams 
- end lines too thin - R 6450113 
Issue 2801 
: Patch: 
Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. - 
R 6498077 


Patch:
Issue 2823 
: Patch: Fixes 
position of mensural c clef - R 6503091 



Ugly:
Issue 1700 
: Chord names 
collide when several note-columns lay in between - R 6489107 



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: Sets TabVoice Stem height to ##f (issue 6303065)

[Keith OHara]

mike  apollinemike.com  apollinemike.com> writes:

> >> > On 2012/06/12 12:49:45, dak wrote:
> >> > > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
> >> > > File lily/grob.cc (right):
> >> > >
> >> > >
> > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
> >> > > lily/grob.cc:472: real_ext[d] += offset;
> >> > > On 2012/06/12 12:32:37, dak wrote:
> >> > > > I don't understand this.  The only way to get a nan from adding
> > an offset
> >> to
> >> > > > infinity is by adding another nan or an infinite offset with
> > different
> >> sign.
> >> > > >
> >> > > > What case is this supposed to catch?

The Flags in TabVoice had empty extent, and position at the end of their
Stems, which also had empty extents.  So we had (inf . -inf) being offset
by -inf.

The skyline code is not robust to NaNs, so with skylines being made
for all objects, NaNs in extents become more of a problem.



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

Re: Fix for /Documentation/snippets/text#text-center-text-below-hairpin-dynamics

[Thomas Morley]

2012/9/12 Thomas Morley :
> Hi,
>
> please have a look at the fix for
> http://lilypond.org/doc/v2.16/Documentation/snippets/text#text-center-text-below-hairpin-dynamics
> imported from LSR:
> http://lsr.dsi.unimi.it/LSR/Item?id=233
> making possible to add DynamicText to the NoteColumn where the Hairpin starts.
>
> Additionally I added two features:
> The Hairpin is now aligned to the DynamicText and the additional text
> switches the direction, if the Hairpin does it, too.
>
> If you think ist's ok, I'll change the LSR-snippet, downgrading it to
> 2.14.2. (simply adding a single $-sign)
>
>
> Because there is nothing wrong with lilypond, only the snippet should
> be improved, Phil adviced me to post the fix here, offering a minimal
> review possibility.
>
> If someone objects to such a minimal treatment, I'll take the Rietveld-route.
>
> The code, (added as attachment, too)
>
> %
>
> \version "2.16.0"
>
> hairpinWithCenteredText =
> #(define-music-function (parser location text) (markup?)
> #{
>   \once \override Voice.Hairpin #'after-line-breaking =
> #(lambda (grob)
>   (let* ((stencil (ly:hairpin::print grob))
>  (par-y (ly:grob-parent grob Y))
>  (dir (ly:grob-property par-y 'direction))
>  (new-stencil (ly:stencil-aligned-to
>(ly:stencil-combine-at-edge
>  (ly:stencil-aligned-to stencil X CENTER)
>  Y dir
>  (ly:stencil-aligned-to (grob-interpret-markup
> grob text) X CENTER))
>  X LEFT))
>  (staff-space (ly:staff-symbol-staff-space grob))
>  (staff-line-thickness (ly:staff-symbol-line-thickness grob))
>  (grob-name (lambda (x) (assq-ref (ly:grob-property x
> 'meta) 'name)))
>  (par-x (ly:grob-parent grob X))
>  (dyn-text (eq? (grob-name par-x) 'DynamicText ))
>  (dyn-text-stencil-x-length (if dyn-text
>(interval-length
> (ly:stencil-extent (ly:grob-property par-x 'stencil) X))
>0))
>  (x-shift (if dyn-text (- (+ staff-space
> dyn-text-stencil-x-length) (* 0.5 staff-line-thickness)) 0)))
>
>   (ly:grob-set-property! grob 'Y-offset 0)
>   (ly:grob-set-property! grob 'stencil
>  (ly:stencil-translate-axis
>   new-stencil
>   x-shift X
> #})
>
> hairpinMolto =
> \hairpinWithCenteredText \markup { \italic molto }
>
> hairpinMore =
> \hairpinWithCenteredText \markup { \larger moltissimo }
>
> \layout { ragged-right = ##f }
>
> \relative c' {
>   \hairpinMolto
>   c2\< c\f
>   \hairpinMore
>   c2\p\< c\f
>   \break
>   \hairpinMolto
>   c2^\< c\f
>   \hairpinMore
>   c2\p^\< c\f
> }
>
> %
>
> -Harm

I take no reaction for no objection.
http://lsr.dsi.unimi.it/LSR/Item?id=233
changed according to my proposal above.

-Harm

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

Re: [GLISS] - alternative viewpoint

[Francisco Vila]

2012/9/16 David Kastrup :
> This is the developer list, after all.

Hey, I have the Dragon Book in my bedside table, I can give a language
to my daughter for her birthday, and still find some things difficult.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Patch upload and LSR

[Marc Hohl]

Hello list,

I am still working on the barline interface ...

The testing process works fine on my local
machine, but 'make doc' fails due to some
syntax changes in the snippets. For example,
defaultBarType = "empty" will not work once
the patch is applied.

So I looked at

http://lilypond.org/doc/v2.17/Documentation/contributor/lsr-to-git

and I wonder if these changes should be included
*in* the barline patch or the procedure described in the link
above should be done *after* it is applied instead.

Step 2 says: commit the changes and make a patch. Does that mean
I should edit/run convert-ly the necessary files at this stage?
Or does makelsr.py call convert-ly for me?

Thanks in advance,

Marc



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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[k-ohara5a5a]

http://codereview.appspot.com/5626052/diff/114002/lily/skyline.cc
File lily/skyline.cc (right):

http://codereview.appspot.com/5626052/diff/114002/lily/skyline.cc#newcode111
lily/skyline.cc:111: if (start_height != end_height)
Does anyone know the reason for this change?

For some unusual input (issue 2836)
 { \override NoteHead #'stencil = ##f b2 b  }
both _heights can be NaNs, due to some other change in this patch.

This re-arrangement of logic looks like it /might/ have been intended to
set slope_=0 for NaNs on input, but in fact we get slope_=NaN and are
trapped at the assertion below.  (My reading of the standard says
NaN==NaN is false, NaN!=NaN is true, so gcc seems to comply.)

http://codereview.appspot.com/5626052/

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

Re: [GLISS] non-timed or non-musical events "z" "y"

[David Kastrup]

Werner LEMBERG  writes:

>> \tempo does not have "optional arguments" but rather several quite
>> different forms of argument lists, and then some rather weird form
>> of numeric range echoed nowhere else in the syntax.
>
> BTW, could you suggest a better syntax for \tempo which looks
> similar to the current definition, but avoiding the problems?

The markup-only variant could just be

\tempoMarkup markup

The Midi variant could likely be

\tempo [optional markup] duration number-or-number-pair

This is a syntax that should work fine currently.  A number-pair can be
entered as #'(50 . 56) or 50/56 currently.  I don't fancy 50~56 just for
the sake of \tempo.

I am not proposing a current change since "supporting functions that can
be used to the left of an equals sign" is a change that I have scheduled
for implementation, and it _might_ offer itself for

\tempo [optional markup] duration = number-or-number-pair

syntax.  This would, however, not relieve the necessity for a separate
markup-only function, and it would be a somewhat awkward use for the
feature since a standalone

\tempo [optional markup] duration

would not make independent sense.

-- 
David Kastrup


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

Re: [GLISS] - alternative viewpoint

[David Kastrup]

Janek Warchoł  writes:

> Hi,
>
> On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup  wrote:
>> Yup.  Here is my multi-stage plan for that:
>
> Great!  It's inspiring to see such a big plan :)
>
>> b) our C++ engravers announce to the type system (and via that, to the
>> documentation) which context properties they read, modify and write.
>> There is no reason that this does not also include the Grob descriptions
>> which are even now a special case of context property.
>
> I didn't understand this part well, but it guess it's not that
> important to have me understand it now (?).

Take a look in the internals manual.  It knows which engravers access
which context properties.  A Grob is actually just a (substructured)
context property, so it can be documented in the same manner.

> (i write this just to provide you with feedback on the difficulty of
> some of your emails)

This is the developer list, after all.

>> d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
>> being a context without \defaultchild (to be recursively created from
>> the current context, if that is not a bottom context, by creating the
>> respective defaultchildren in sequence until hitting bottom).  If all
>> our engravers had correctly registered the context properties they read,
>> \override xxx could instead set the property in the context closest to
>> bottom that will actually _look_ at the changed property.
>
> So,
>   \override BarNumber #'font-size = 5
> would actually result in
>   \override Score.BarNumber #'font-size = 5
> ?

Yes, that's the idea.  As long as you have no engraver at Staff level
looking at the BarNumber properties.  Maybe it would be more robust to
explicitly declare the default context for writing each property.  After
all, that is a one-time job.

Or declare an engraver "canonical" for some properties, so that if
_that_ engraver is moved, the default context moves along.  At the
current point of time, an engraver declares which properties it
reads/modifies/writes (why do we need all three?), and we might let it
declare which it "owns" with respect to the default context.

> Wonderful!

>> Of course, this is not without drawback either: if there are multiple
>> engravers looking at that property at multiple levels and you are
>> interested in overriding the behavior of the engraver in an outer
>> level, the unspecific override will be done in the inner level and
>> again not have an apparent effect.
>
> I think i won't understand this w/o an example.

Write an engraver at Staff level which looks at currentBarNumber, and
\override currentBarNumber will just work at Staff level instead of
Score level.

>> #'4 and #4 and 4 should be quite equivalent in most cases...
>
> You mean that they are quite equivalent now or that we want them to be
> equivalent in the future?

Where function arguments are concerned, they are equivalent.  Not
everything is a function argument, and #4 or #'4 cannot be used as a
duration.

> Anyway, being equivalent in most cases is, in my opinion, only
> marginally helpful: exceptions to the "most cases" introduce
> confusion.  If we want to simplify things, we need equivalence in all
> cases.

4 has several different meanings, #4 is a number.  I don't think I want
#4 . to be a valid duration.

>> One might argue that users who are able to write to a mailing list
>> after looking for it in the manual make up for less than 1% of our
>> targeted demographic group, users who come to LilyPond not primarily
>> since they enjoy being in total control over the data structures
>> their typesetting program uses.
>>
>> And particularly for those it makes a big selling point if naive
>> expectations disregarding the technical necessities and
>> implementation constraints happen to hit the mark semi-regularly.  Of
>> course, we can't make that 100%, but 80% is a lot more encouraging
>> than 2%.  If you get everything wrong at first try, that's a big
>> turnoff.  Even if some smart helpful guy explains to you why
>> everything is wrong.
>
> If i understand correctly, you mean that we don't have many emails
> from people being confused by pre/postfix issues because these people
> never make it to the mailing list (i.e. they are too discouraged by
> their first Lily try that they quit immediately)?  I think you're
> right.  *We* may never notice that some change simplified things
> (because we're already used to Lily), but newcomers will.

I think that if your first five attempts to do something on your own all
end catastrophically, you'll just quit again.

>> There are several lashback issues connected with convenience wrappers,
>> and they focus around the question:
>>
>> To what degree does a convenience wrapper become part of LilyPond's
>> language?
>
> Good question.  I think this is what Graham had in mind when he wrote
> about "ly vs. ly++".
>
>> There are several questions following from that starting point.
>>
>> a) reflection.  Should \displayLilyMusic recognize ex

Re: [GLISS] - alternative viewpoint

[David Kastrup]

Janek Warchoł  writes:

> On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup  wrote:
>>
>> You mean, currently we basically see the default error message from the
>> parser generator.  Improving this involves basically accepting errors in
>> input and acting on them by putting out hand-tailored messages.
>>
>> Currently, the parser is still undergoing significant restructuring work
>> in major areas and mechanisms.  That work entails a lot of time spent on
>> ironing out parser conflicts where some input would correspond to
>> multiple and diverging interpretations according to the current syntax.
>> It is significant work ironing out those conflicts.  Adding additional
>> rules for erroneous input means more potential for conflict, so it would
>> make the ongoing work even harder.  I am working towards recognizing
>> elements of the syntax in isolation, and then pasting them together.
>> The "pasting together" is then done outside of the immediate control of
>> the parser and can trigger independent error messages based on the
>> assumption that at least the elements used for combining were, by
>> themselves, recognized correctly.  Those error messages can be more
>> specific and helpful than the boilerplate parse errors from the parser
>> generator.
>
> Hmm, this sounds complicated.  Do you mean that implementing more
> informative ("custom") error messages with current parser will wreak
> havoc, but if we simplify the parser first, it would be possible to do
> this in a sane way?

No.  I don't mean "wreak havoc" but rather "will be in the way while I
am still reworking the parser internals".  It's like putting up tapestry
and setting up furniture before doing the plumbing.

-- 
David Kastrup

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

Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup  wrote:
>
> You mean, currently we basically see the default error message from the
> parser generator.  Improving this involves basically accepting errors in
> input and acting on them by putting out hand-tailored messages.
>
> Currently, the parser is still undergoing significant restructuring work
> in major areas and mechanisms.  That work entails a lot of time spent on
> ironing out parser conflicts where some input would correspond to
> multiple and diverging interpretations according to the current syntax.
> It is significant work ironing out those conflicts.  Adding additional
> rules for erroneous input means more potential for conflict, so it would
> make the ongoing work even harder.  I am working towards recognizing
> elements of the syntax in isolation, and then pasting them together.
> The "pasting together" is then done outside of the immediate control of
> the parser and can trigger independent error messages based on the
> assumption that at least the elements used for combining were, by
> themselves, recognized correctly.  Those error messages can be more
> specific and helpful than the boilerplate parse errors from the parser
> generator.

Hmm, this sounds complicated.  Do you mean that implementing more
informative ("custom") error messages with current parser will wreak
havoc, but if we simplify the parser first, it would be possible to do
this in a sane way?


On Sat, Sep 15, 2012 at 11:53 AM, Phil Holmes  wrote:
> - Original Message - From: "David Kastrup" 
>> You need to elaborate.  It is not clear what you mean with that, and
>> what kind of remedy you envision.
>
> \new Staff works.  \New staff doesn't.  There's no reason for that - we
> don't have two separate \new \New commands that do different things, nor two
> contexts Staff and staff that are different.  Worse is that \slurUp works
> but only with that precise casing.  TBH this specific one doesn't cause me
> worry, since I remember it, but there are much more arcane casings that I
> have to refer to the manual to find - so I can remember the command, but not
> the casing!

I think we should make the casing/naming uniform across all names, for example:
\New Staff
\SlurUp
LyricExtenderEngraver
SomePropertyName

> From a user perspective, it would be much simpler if everything
> they write was ToLower()-ed before further processing.

This sounds interesting to me, but David signalled an important
problem - distinguising notenames (which are always lower case) from
grob names ant other things.
Another solution would be to have Frescobaldi auto-correct the casing.

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

Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

Hi,

On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup  wrote:
> Yup.  Here is my multi-stage plan for that:

Great!  It's inspiring to see such a big plan :)

> b) our C++ engravers announce to the type system (and via that, to the
> documentation) which context properties they read, modify and write.
> There is no reason that this does not also include the Grob descriptions
> which are even now a special case of context property.

I didn't understand this part well, but it guess it's not that
important to have me understand it now (?).
(i write this just to provide you with feedback on the difficulty of
some of your emails)

> d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
> being a context without \defaultchild (to be recursively created from
> the current context, if that is not a bottom context, by creating the
> respective defaultchildren in sequence until hitting bottom).  If all
> our engravers had correctly registered the context properties they read,
> \override xxx could instead set the property in the context closest to
> bottom that will actually _look_ at the changed property.

So,
  \override BarNumber #'font-size = 5
would actually result in
  \override Score.BarNumber #'font-size = 5
?
Wonderful!

> Of course, this is not without drawback either: if there are multiple
> engravers looking at that property at multiple levels and you are
> interested in overriding the behavior of the engraver in an outer level,
> the unspecific override will be done in the inner level and again not
> have an apparent effect.

I think i won't understand this w/o an example.

> #'4 and #4 and 4 should be quite equivalent in most cases...

You mean that they are quite equivalent now or that we want them to be
equivalent in the future?

Anyway, being equivalent in most cases is, in my opinion, only
marginally helpful: exceptions to the "most cases" introduce
confusion.  If we want to simplify things, we need equivalence in all
cases.

> One might argue that users who are able to write to a mailing list after
> looking for it in the manual make up for less than 1% of our targeted
> demographic group, users who come to LilyPond not primarily since they
> enjoy being in total control over the data structures their typesetting
> program uses.
>
> And particularly for those it makes a big selling point if naive
> expectations disregarding the technical necessities and implementation
> constraints happen to hit the mark semi-regularly.  Of course, we can't
> make that 100%, but 80% is a lot more encouraging than 2%.  If you get
> everything wrong at first try, that's a big turnoff.  Even if some smart
> helpful guy explains to you why everything is wrong.

If i understand correctly, you mean that we don't have many emails
from people being confused by pre/postfix issues because these people
never make it to the mailing list (i.e. they are too discouraged by
their first Lily try that they quit immediately)?  I think you're
right.  *We* may never notice that some change simplified things
(because we're already used to Lily), but newcomers will.

> There are several lashback issues connected with convenience wrappers,
> and they focus around the question:
>
> To what degree does a convenience wrapper become part of LilyPond's
> language?

Good question.  I think this is what Graham had in mind when he wrote
about "ly vs. ly++".

> There are several questions following from that starting point.
>
> a) reflection.  Should \displayLilyMusic recognize expressions that
> can be produced by a wrapper and output them?  If we answer "yes" to
> that question, it would make sense to provide some infrastructure
> for specifying appropriate reverse engineering rules to LilyPond in
> a manner that is not significantly more complex to specify than the
> wrapper itself.

I don't understand what you mean here.

> b) When and how are third-party tools supposed to learn about such
> wrappers when they are supposed to be part of LilyPond?

ditto.

> c) MusicXML?

ditto.

>> And providing error messages when an override has no effect because it
>> was at the voice context and should have been at staff?
>
> See above.  If the system knows what needs to be done, there is little
> point in warning rather than doing it.  Of course, if "Voice" has been
> explicitly specified rather than via the implicit "Bottom.", using the
> same mechanisms and internally available information for producing a
> warning seems reasonable.  Basically I prefer the behaviors:
>
> a) implicit default choice is non-working -> make the right choice instead
> b) explicit choice is non-working -> obey but warn

+1!

> Now one might argue that this currently is rather a discussion on
> meta-bikeshedding, namely getting something right that will serve as a
> template for future bikeshedding, but it is quite clear that with
> convenience wrappers, everybody actually _can_ contribute his opinion
> without requirin

Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

On Fri, Sep 14, 2012 at 6:56 PM, Phil Holmes  wrote:
> What does get me more concerned is how hard it is to find some of the
> correct ways of tweaking output.  Using voice.SomeValue (or is it
> Voice.someValue) when it should be staff.Somevalue (or was it
> Staff.someValue) frequently results in no change to the output.  And is it
> \override or \set?  And \revert or \override back to something else.  And
> finding what comes after the \override staff.Something - is it ##f. or #'4
> or 4 or { 4} or what?

I agree, this is a problem.

> I personally think that providing more of these simple syntax features would
> make it much easier for the average user

+1

On Fri, Sep 14, 2012 at 7:10 PM, m...@mikesolomon.org
 wrote:
> consider doing Z" or even a "?" token one can put before or after an object 
> to have help messages
> printed to the logfile as well as detailed information about the command in 
> question and what it applies to.

interesting idea.

Janek

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

Re: GOP2-5 - GLISS discussions

[Janek Warchoł]

On Fri, Sep 14, 2012 at 10:05 PM, Marc Hohl  wrote:
> The whole discussion reminds me of the way songs are written in the
> music band I play – David, do you remind the story? I think I told it
> even before Graham arrived, so it was just you, Janek, and my wife
> at Waltrop listening to my clumsy English ...
>
> [...]
> I found out that at least 50% of the harmonics and ideas are to be
> reverted by the pianist himself in less than ten minutes because
> he realises that he has overdone it *without* threatening him with
> violence.

I think that's a nice illustration, Marc :)

As for Graham's proposal: a separate mailing list seems a reasonable
idea to me, but i don't insist since it looks that some people don't
like it.
Anyway, i'm ok with whatever Graham decides: he is the leader and i trust him.

best,
Janek

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

info reader and lilypond snippets

[Werner LEMBERG]

Today I've noticed that `Selected Snippets' sections, if viewed with
the TTY info viewer, only show the code example but not the
description text.

It seems that a snippet's `texidoc' block is dropped if not in TeX or
HTML mode while the *.texi files are generated.  Can this be fixed
somehow?


Werner

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

useless `See also' index entries

[Werner LEMBERG]

Folks,


not sure whether this has been already reported.

Looking at

  http://lilypond.org/doc/v2.17/Documentation/notation/lilypond-index.html

I see around 600 completely useless entries containing `See also'.

This problem doesn't exist in the PDF version.  In case this can't be
easily fixed in lilypond-texi2html.init, I suggest to simply filter
out those lines with sed or something similar.


Werner

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

Re: glissando in LP 2.16

[Werner LEMBERG]

[CCing devel instead of user, since this is a development
contribution.]

> you find attached 8 files: one .txt file containing seven
> documentation entries and seven .ly files for each entry.

I've now edited your contribution; attached is a patch.  Documentation
team, please comment and integrate if useful!

Thanks again!


Werner
diff --git a/Documentation/notation/expressive.itely b/Documentation/notation/expressive.itely
index 25dbc81..528cdb2 100644
--- a/Documentation/notation/expressive.itely
+++ b/Documentation/notation/expressive.itely
@@ -1038,15 +1038,88 @@ g2\glissando g'
 c2\glissando c,
 @end lilypond
 
+It is possible to place an expression mark at a certain point within
+the glissando, usually indicated by a stem without a notehead:
+
+@lilypond[verbatim,quote,relative=2]
+f4\glissando\<
+\once \override NoteColumn #'glissando-skip = ##t
+\once \override NoteHead #'transparent = ##t
+a4\f\> a8\! r4.
+@end lilypond
+
+@noindent
+Setting @code{glissando-skip} to @code{#t} makes the glissando skip the
+inserted @code{NoteColumn} grob.  To hide the notehead, the
+@code{transparent} property is set to @code{#t}.  If the stem doesn't
+align well with the glissando, it may need repositioning.
+
+The same works with more than one inserted grob:
+
+@lilypond[verbatim,quote,relative=2]
+r8 f2\glissando a8 r4 |
+r8 f8\glissando
+\override NoteColumn #'glissando-skip = ##t
+\override NoteHead #'transparent = ##t
+g4 a8
+\revert NoteColumn #'glissando-skip
+\revert NoteHead #'transparent
+a8 r4
+@end lilypond
+
+Setting the @code{breakable} property to @code{#t} in combination with
+@code{after-line-breaking} allows to break a glissando if it occurs
+at a line break:
+
+@lilypond[verbatim,quote,relative=2,line-width=4.0\cm]
+\override Glissando #'breakable = ##t
+\override Glissando #'after-line-breaking = ##t
+
+f1\glissando | \break
+a4 r2. |
+f1\glissando \break
+\once \override NoteColumn #'glissando-skip = ##t
+\once \override NoteHead #'transparent = ##t
+a2 a4 r4 |
+@end lilypond
+
+A glissando can connect notes across staves:
+
+@lilypond[verbatim,quote]
+\new PianoStaff <<
+  \new Staff = "right" {
+e'''2\glissando
+\change Staff = "left"
+a,,\glissando
+\change Staff = "right"
+b''8
+  }
+  \new Staff = "left" {
+\clef bass s1 s8
+  }
+>>
+@end lilypond
+
+A glissando can occur between chords:
+
+@lilypond[verbatim,quote,relative=2]
+c1\glissando g'
+1\glissando  \break
+
+\set glissandoMap = #'((0 . 1) (1 . 0))
+1\glissando 
+\set glissandoMap = #'((0 . 0) (0 . 1) (0 . 2))
+c1\glissando 
+\set glissandoMap = #'((2 . 0) (1 . 0) (0 . 1))
+1\glissando 
+@end lilypond
+
 Different styles of glissandi can be created.  For details, see
 @ref{Line styles}.
 
 @snippets
 
 @lilypondfile[verbatim,quote,texidoc,doctitle]
-{glissandi-can-skip-grobs.ly}
-
-@lilypondfile[verbatim,quote,texidoc,doctitle]
 {contemporary-glissando.ly}
 
 @seealso
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel