lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LilyPond blog


From: Flaming Hakama by Elaine
Subject: Re: LilyPond blog
Date: Wed, 6 Dec 2017 13:04:15 -0800


---------- Forwarded message ----------
From: Urs Liska <address@hidden>
To: address@hidden
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 <address@hidden>
To: lilypond-user <address@hidden>
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



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"
address@hidden
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]