Re: Glissando notation?

[Trevor Bača]

On 1/30/07, Robert Kennedy <address@hidden> wrote:
> It seems in Lilypond (v2.10.14) the default notation for glissandos is
> a straight line. I've never seen that notation used for glissando
> before so I have no idea why it's the default, but that's OK because
> everything can be changed, right?
>
> So I tried "\override Glissando #'style = #'zigzag", thinking it would
> give me the right thing. But it gives me a very thin, light zig-zag
> line -- yet another notation that I have never seen used for
> glissando.
>
> The most common, correct notation for glissando looks like a trill
> mark. It's a wavy line of varying thickness.
>
> A statement in the on-line reference documentation suggests that
> "\override Glissando #'style = #'trill" might help:

Hi Robert,

Are you looking for the notation at the top of the 2.11 NEWS file?

 http://lilypond.org/doc/v2.11/Documentation/topdocs/NEWS.html

This tests OK in 2.11.14:

%%% BEGIN %%%

\version "2.11.14"

\new Staff {
  \override Glissando #'style = #'trill
  c'4 \glissando
  g'4
}

%%% END %%%

If you're not getting what you expect, here are a couple of things to
check in your input:

1. Make sure to include the \override just before the glissando start point

2. Make sure you include the \glissando command itself between the
glissando start point and end point

3. Watch the apostrophes; Glissando (with a capital letter) is a
"grob" (or graphic object) whose style "property" gets overriden to
the value of the *string* trill. It's not always this way with all
overrides. For example, you might later wish to write

  \override Glissando #'color = #red

Here red is not a string but a constant, meaning that red takes only a
hash mark and does not take an apostrophe. (Constants in LilyPond are
happily limited to numbers, the directions up and down, and names of
colors ... for the most part.) Make sure to watch for these things as
you're learning the program and you'll save yourself some heartache
wondering why an override that was just working isn't working any
more.

Welcome to Lily, BTW. You'll wind up being amazed, as you're already
starting to see with the quality of the output. There are projects on
the list ranging from 17th-century full operas to contemporary pieces
by composers working in many countries, and there are settings --
somewhere -- to accommodate all of these.

WRT to your previous mail asking about an architectural overview, what
you're looking for doesn't truly exist yet. That said, make sure to
read chapter 3 in the manual in its entirety, especially 3.2 "How
LilyPond files work". And my list of the top 6 things I wish someone
had told me the first (or maybe second) day I started using Lily is
here for your enjoyment:

1. The heavy lifting of the program implemented in (compiled) C++ code
with tweaks being made in (interpreted, dynamic) Scheme code.
Capitalized names in lily input generally refer to the C++ guts while
other properties in overrides talk directly to the Scheme code. Beyond
that, you never need to think about the division of labor between the
compiled and interpreted parts of the program, even though parts of
the docs and the archives might make you think otherwise.

2. A LilyPond "context" is, intuitively, a horizontal stratum of music.

3. Marking up text with markup is really a LOT more powerful (and
complicated) than you would think from your experience with any other
programs (except possibly LaTeX). There's a reason that something as
straightforward as text is placed in the "Advanced" section of our
manual. In practice this doesn't wind up being a problem, but make
*sure* to allow yourself some time to read the manual the morning that
you decide to go sprinkle text indications all over your first score.

4. \relative works great for music of the common practice; if you've
got a lot of disjunct intervals in your own music, avoid \relative
completely. Likewise, instantiate context explicitly with \new Staff
or \new Score or \new Voice or whatever. This is probably a religious
issue, but I never input a naked expression into a file ... Lily wraps
up naked expressions inside of a contexts for you, so why not just
instantiate explicitly yourself?

5. *ALL* the duration stuff works, no matter whether you're wanting
15th-century, 19-century or 21st-century rhythms. But learn about the
multiplication * operator for spacing tweaks.

6. And, possibly the most important thing, keep a copy of the LilyPond
equivalent of test.c (or test.py or whatever), open with you the
entire time you're working. For me this file is

 \version "2.11.14"

 \new Staff {
     c'4
 }

That one testfile right there is a good enough starting point to test
well over 90% of all the tweaks you'll ever want to test. Keep it
handy and get used to flipping over to test out things in the middle
of doing your note input.

Enjoy.

--
Trevor Bača
address@hidden