> ---------- Forwarded message ----------
> From: Urs Liska <li...@openlilylib.org>
> To: lilypond-user@gnu.org
> Cc:
> Bcc:
> Date: Tue, 31 Oct 2017 23:31:25 +0100
> Subject: Re: LilyPond blog
>
> Hi David,
>
> Am 31.10.2017 um 23:07 schrieb Flaming Hakama by Elaine:
>
>
> From: Urs Liska <li...@openlilylib.org>
>> To: lilypond-user <lilypond-user@gnu.org>
>> Subject: LilyPond blog
>>
>> "Scores of Beauty" (http://lilypondblog.org) is LIlypond's semi-official
>> community blog, ...I urgently suggest that people decide to contribute to
>> it, and in particular I would be happy if someone could step up and take
>> over some editorial responsibility.
>
> ...
>
>>
>> Best
>> Urs
>>
>
>
> Having volunteered for this, I figured I could try a stab at writing a
> preliminary "what's new in 2.20" type of post in advance of the release.
>
>
> That sounds good. We'll have to see how that plays out and whether it will
> be good to publish that *before* the release or rather *write* it
> beforehand and publish it immediately after a release. My gut feeling says
> the latter would be better, but if you have a good idea how to "package"
> such a text I'm open for anything.
>
>
> What is the best way to find out what has been accomplished since 2.18?
>
>
> What you will probably want is http://lilypond.org/doc/v2.19/
> Documentation/changes-big-page.htm
> <http://lilypond.org/doc/v2.19/Documentation/changes-big-page.html>
>
>
Towards this end, I read through the contents of this page and attempted to
summarize it. I'd like to see if anyone had any constructive feedback on
this approach for the blog post.
My intention was to write to an audience which is not necessarily famililar
with Lilypond; anyone who is already familiar with Lilypond should
probably just read this exising page. So, I avoided mentioning specific
lilypond function names, and tried to recast features in terms of benefits.
I imagine that an appropriate categorization would be one that allows for
coherent follow-up blog posts for each area. Some features could be listed
in several categories.
However, I have question about the purpose of some of the features,
regarding what the feature allows you to do / do easier / do better? These
questions are marked in the list with a ? instead of *.
I will follow up with specific questions about each one. But, please jump
in if you have a quick explanation for any of these, or point me where to
RTFM.
Thanks.
Improvements in Lilypond 2.20
Improvements in musical input syntax
* French note names are now supported
* Simplified syntax for entering repeated pitches, by using only durations
* Rules for accidentals can now be applied across choir staves, with
additional rules for choir staves
* Easier to revert meter and measure position changes used in volta
alternatives, among other context properties.
? What does the chord change reversion look like or do?
* Simpler way to construct beaming exceptions
* Clearer naming rules for pitches that have "sharp" or "flat" in their
name, which now requires hyphenation
? The thin-kern property of the BarLine grob has been renamed to segno-kern.
? \chordmode can now use < > and << >> constructs.
Improvements in musical structure
* Ability to use lyrics in arbitrary contexts like Staves, not just voices
* Both \lyricsto and \addlyrics commands now accept the same kind of
arguments as \lyrics and \chords
* A new flexible template suitable for a range of choral music, is now
provided.
* It is now possible to change the time signature mid-measure
? Improvements to the \partial command have been made when used with
parallel music and/or multiple contexts.
* Individual slurs and phrasing slurs may now be started from an explicit
note within a chord.
* Ability to distinguish simultaneous slurs and phrasing slurs
* KeyCancellation grobs now ignore cue clefs (like KeySignature grobs do).
* Ability to manage groups of tags for conditional include of content
Improvements in visual output of music
* Four new clef glyphs: double G clef, tenor G clef, variable clef and an
alternate percussion clef.
* Multi-measure rests now have length according to their total duration
* The positioning of tuplet numbers has been improved for kneed beams
without brackets by being positioned closer to the beam, and shifted
horizontally if the number is too close to an adjoining objects
* Fine-tuned control over the ends of hairpins
* Fine-tuned control over the shape, style and slope of tremolo slashes
* Support for Frenching even the first page of scores
* Ability to scale spacing at the Staff level
* Ability to scale stems, beams, and horizontal spacing, without changing
the staff size
? Ability to override the text property of chord symbols
* Easier to make slight adjustments to the default vertical position of
individual systems by moving them with reference to their current position
* Grobs can now be aligned separately and with respect to their parents,
such as aligning the left edge of a grob with the center of its parent.
* All of \override, \revert, \set, and \unset commands now work with the
\once prefix for making one-time settings.
? LeftEdge now has a definable Y-extent (i.e.vertical).
Improvements in tabulature
* A slash note head style has been added for Tabulature
* The distance between frets and between strings are now independently
adjustable
* Ability to individually color both the dots and parentheses in fret
diagrams
* Ability to control the space between the dot and the parentheses
surrounding a fret label indication
* Support for additional bass strings (such as for lute tablature)
* Support for micro-tones (for bendings)
Improvements in output formats
* Ability to embed LilyPond source files in generated PDF files
* Ability to turn off better looking PDF previews to achieve smaller file
sizes
* Ability to automatically adjust the height of the page to fit all music
on one page, or the width to fit on one one line
* Ability for format SVG and PDF output without margins or page-breaks
* Ability to define multiple attributes in SVG output
? Ability to produce SVG output with the output-classic-framework procedure
and the -dclip-systems
* MIDI ouput now reflects common articulations and breath marks, to make
notes louder that are accented and marcato; to make notes shorter marked
with staccato, staccatissimo, portato, and before breath marks.
* When unfolding repeats, you can now specify which types of repeats to
unfold: percent, tremolo and/or volta.
* Ability to control the perceived volume of sustained notes using
‘expression level’ of MIDI channels
* Ability to use the header title (or other contexts' title) as the name of
the MIDI sequence in MIDI output
Improvements in fonts
* Small and regular ‘MI’ Funk and Walker noteheads are now the same width
as other shaped notes. Improved SOL noteheads when used with both the
normal Aiken and Sacred Harp heads, as well as with the thin variants.
* Easier approach to using alternative ‘music’ fonts
* Default fonts for SVG are now generic-family, like in CSS
* When using OpenType fonts, font features can be used.
? For PDF and other backends, default fonts have changed
Improvements in text formatting
* Ability to print Roman numerals for string numbers
* Page numbers may now be printed in roman numerals
* Ability to add text to analysis brackets
* Ability to balance whitespace so it is consistent between three or more
words in a markup
* Improved horizontal alignment when using TextScript, with DynamicText or
LyricText.
* Ability to display text in table format
? Instrument name now supports text-interface
Improvements in graphic formatting
* Ability to put ties above and below text
* Ability to draw squiggled lines, with control over thickness, angularity,
height and orientation
* Two new styles of whiteout: one that approximates the contours of a
glyph’s outline, and the other is a rounded rectangle shape. For all three
styles, including the default box style, the whiteout shape’s thickness, as
a multiple of staff-line thickness, can be customized.
* Easier-to-use interface for markup commands, which takes dimensions from
an existing object
* Improved support for all path commands, both relative and absolute,
including lineto, rlineto, curveto, rcurveto, moveto, rmoveto and
closepath, and supports ‘single-letter’ syntax used in standard SVG path
commands
Improvements in scripting
* Music, scheme and void functions and markup commands that just supply the
final parameters to a chain of overrides, music function and markup command
calls can now be defined using the abbreviation \etc.
* Dot-separated symbol lists, alternatively separated by commas, now
support the use of unsigned integers in expressions for assignments, sets,
and overrides, and association list elements may now be also referenced in
this manner.
? Blocks introduced with \header can be stored in variables and used as
arguments to music and scheme functions and as the body of #{…#} constructs.
* Custom LilyPond functions can now be directly called from Scheme as if
they were genuine Scheme procedures.
? Within GUILE functions, the current input location and parser can be
referenced, rather than requiring them to be supplied as arguments.
? Functions defined with define-music-function, define-event-function,
define-scheme-function and define-void-function no longer use parser and
location arguments.
? Scheme functions and identifiers can now be used as output definitions
(what is an output definition?)
? Scheme expressions can now be used as chord constituents (what is a chord
constituent?)
Thanks,
David Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
