Coder Social home page Coder Social logo

lydown's Introduction

Build Status

Lydown is a language and compiler for creating music scores, parts and snippets. The lydown code is compiled to lilypond code and then compiled to PDF, PNG or MIDI files.

About

Lydown builds on the ideas put forth by lilypond and makes the following improvements:

  • a greatly simplified syntax for entering notes, for more rapid note entry and improved legibility.
  • ability to enter lyrics and bass figures interspersed with the music.
  • rhythmic macros for rapid entry of repeated rhythmic patterns.
  • zero lilypond boilerplate code.
  • a sane file/folder structure for creating multi-part, multi-movement works with automatic part extraction.

Installation

If you have Ruby on your machine, you can simply install lydown as a gem:

gem install lydown

If not, you can simply grab the release file for your OS, which already includes Ruby.

Once you got lydown installed, you can verify it woks correctly by running:

lydown version

Lydown will display its version and also the version lilypond installed. If lilypond is not installed on your machine, you can install it by either running:

lydown install lilypond

Or by downloading it from the lilypond website.

Hello world in lydown

The following is a basic example of the lydown syntax:

// helloworld.ld
\key:D \time:2/4
4d''\"Hello world!" 6cbag 3fgag6fd 4e

And here's the equivalent lilypond code:

\version "2.18.2"
relative c' {
  \key d major
  \time 2/4
   d'4\"Hello world!" cs16 b a g fs32 g a g fs16 d e4
}

To compile the lydown source file into a PDF and then display it, invoke lydown as follows:

lydown -O helloworld.ld

More examples and resources

Examples of lydown code, used to test lydown, could be found in the specs directory of the lydown repository.

A recent reconstruction of Bach's Markuspassion BWV 247 is the first large-scale work to be written in Lydown.

Additional information and resources could be found on the lydown wiki.

Compiling lydown code

The lydown command line tool can compile the code into lilypond code, PDF, PNG, MIDI or MP3. The program creates an output file with the same name as the input file and the corresponding extension. Specifiying the -O switch causes the output to be opened immediately.

To create a lilypond file:

lydown -O --ly helloworld.lydown

To create a PDF file:

lydown -O --pdf helloworld.lydown

To create a PNG file:

lydown -O --png helloworld.lydown

To create a MIDI file:

lydown -O --midi helloworld.lydown

Proofing mode

Lydown can be run in a special proofing mode designed to minimize the turnaround time between editing and viewing the result when entering new music or when editing existing music. To run lydown in proofing mode, use the proof subcommand:

lydown proof

Lydown will then start to monitor all subdirectories and files in the current directory, and compile them whenever they're changed. Lydown will detect the lines that have changed and insert skip markers in order to speed up compilation and typeset only the music that has actually changed. In addition, notes in the bars that changed will be colored red.

In proof mode, lydown will generate parts and not a score. To include another part for reference along with the part that changed, you can use the include_parts parameter:

lydown proof --include_parts continuo # or:
lydown proof -i continuo

This is useful when editing baroque music for example, or when any other part can give context and aid in verifying the music.

Interactive mode

When invoked without any parameters, an interactive lydown session is started. This mode is useful when working on music involving multiple movements or multiple parts. In this mode, you can move between directories, edit files (using vim), and compile specific movements or specific parts.

Just like in proofing mode, any changes you make to files within the working directory are immediately compiled and shown in the system viewer.

To get a list of available commands, type help.

The lydown syntax

The lydown syntax is designed for faster note entry, better legibility and minimal boilerplate. The lydown syntax takes the basic ideas put forth by lilypond and simplifies them, with the following main differences:

  • musical context (staves, parts, etc) is implicit rather than explicit.
  • whitespace between notes is optional.
  • durations come before notes.
  • duration macros allow rapid entry of repeated rhythmic patterns (such as dotted rhythm).

It must be stressed that lydown is made to process music that is relatively simple, and it was designed to support the processing of baroque music in particular. Therefore, a lot of stuff that is possible with plain lilypond would not be possible with lydown.

For the sake of this tutorial, some familiarity with the concepts and syntax of lilypond is presumed. The lydown code will be shown alongside its lilypond equivalent.

Notes and durations

In lydown, durations are entered before the note to which they refer, and they stay valid for subsequent notes, until a new value is entered:

4c8de2f => c4 d8 e f2

In addition to the usual values (1, 2, 4, 8, 16, 32 etc), lydown adds two shortcuts for commonly used values: 6 for 16th notes and 3 for 32th notes:

8c6de3fefefede2f => c8 d16 e f32 e f e f e d e f2

Lydown recognizes the following values:

l   // longa
0   // breve
1   // whole note (semi breve)
2   // half note
4   // 1/4 note
8   // 1/8 note
6   // 1/16 note
16  // 1/16 note
3   // 1/32 note
32  // 1/32 note
64  // 1/64 note
128 // 1/128 note
256 // 1/256 note

Augmentation dots are entered like in lilypond:

8.c6d 8.e6f 2g => c8. d16 e8. f16 g2
8..g 3g 4c => g8.. g32 c4

Notes can be repeated using the @ placeholder:

4c@@@ => c4 c c c

(The repeating note placeholder is useful when entering repeated notes with accidentals).

Chords are written using angled brackets, like in lilypond:

(2<fd>4<ge>) => <f d>2( <g e>4)

Accidentals

Accidentals can be entered using + and -, altering the note relative to the key signature.

8cgb-c2a => c8 g bes c a2
- key: D
4dc-2b- => d4 c bes2

But can also be entered using the characters # for sharp, ß for flat and h for natural:

c#dßeh => cis des e

In lydown notes follow the key signature by default:

- key: g major
ff#fhfßd#bß => fis fisis f f dis bes

The accidental mode can be changed by specifiying the manual accidental mode:

- key: g major
- accidentals: manual
8g6f+edcba2g

In the default, automatic mode, when deviating from the key signature the accidental must be repeated for each note, regardless of barlines.

In the same manner as lilypond, accidentals can be forced by following the note name and accidental with a ! (for a reminder), or ? (for a cautionary accidental in parentheses):

cc+c+!cc? => c cs cs! c c?

A ficta accidental (an non-original accidental that appears above the staff) can be entered using the ^ symbol after the accidental:

cdef+^g

Octaves

In Lydown, the first note in the document carries an absolute octave marker, using the ' and , signs:

c,,   // contrabass octave
c,    // great octave
c     // small octave
c'    // first octave (middle c)
c''   // second octave
c'''  // third octave
...   // etc.

For the following notes, the octave markers ' and , are used for jumping between octaves, using the same rules as lilypond's relative mode:

Grace notes

Grace notes are signified by appending a grace kind after the the duration value:

// grace
6°d8edcd2c

// appoggiatura
6^d8cbag

// acciaccatura
6`dc8bcde

The grace holds until the next change of duration.

Barlines

Just like in lilypond, barlines are taken care of automatically according to the time signature. Final bar lines and repeat bar lines can be entered explicitly by using shorthand syntax:

|: cege :|: cfaf :|

When entering unmetered music, an invisible barline can be added in order to provide line breaks:

-time: unmetered
cdef ?| gag

Repeats with alternatives

Repeats with alternatives can be written by using the following syntax:

|:*2 // start a repeat
|*   // start a volta
*|   // end the repeat

// example: 2 repeats
|:*2 1c d |* e f |* g a *| b c

Rests and silences

Normal rests are written like in lilypond:

4ce2r => c4 e r2

Full bar rests are similar to lilypond, except there's no need to enter the rest value (it is implicit in the time signature):

- time: 3/4
// 4 bar rest in the middle
2c4e R*4 2.g

Silences (Invisible rests) are signified using s for normal silences and S for whole measure silences:

4ddsd
S*2
2.s4d

Beams, slurs and ties

Lydown uses automatic beaming as the default, except in the case of vocal parts (see document settings). Auto beaming can be

Beaming and sluring is similar to lilypond, except the beam/slur start comes before the note:

8(cdef)g[6fe]4f => c8( d e f) g f16[ e] f4

a regular tie is written just like in lilypond:

4g~6gfed2c => g4 ~ g16 f e d c2

Lydown also supports a shortened tie form, where the tied note is not repeated:

4g6&fed2c => g4 ~ g16 f e d c2

Articulation and expression marks

Lilypond shorthand articulation marks can be entered after a backslash

c\^ e\+ g\_ => c-^ e-+ g-_

Common articulation marks can be entered immediately after the note:

// tenuto, staccato, staccatissimo
c_e.g` => c-- e-. g-!

Other arbitrary lilypond articulations can be entered after a backslash:

c\staccato e\mordent g\turn => c\staccato e\mordent g\turn

Note: While whitespace between notes is usually optional, in the case of backslashed articulations you will have to add a whitespace after the articulation, so lydown will be able to parse it.

Dynamic marks are entered before the note to which they apply:

c\f eg

\f cege \p cfaf => c\f e g e c\p f a f

Arbitrary expression markup can be entered as a string following a backslash. Lydown supports basic markdown syntax for formatting the expression:

c\"hello" // displayed above the note
c\_"hello" // displayed below the note
c\<"hello" // right-aligned
c\|"hello" // centered
c\_|"hello" // centered, below the note
c\"_hello_" // italic
c\"__hello__" // bold

Repeated articulation and rhythmic patterns: macros

An important feature of lydown is the macro, which facilitates rapid entry of repeated rhythmic and articulative patterns.

A common scenario is repeated articulation, for example a sequence of staccato notes:

{.}cdefgabc => c-. d-. e-. f-. g-. a-. b-. c-.

A macro can also contain a fully qualified lilypond articulation specifier:

{\tenuto}cege => c\tenuto e\tenuto g\tenuto e\tenuto

Rhythmic macros can be used for repeated rhythmic patterns. A common scenario is a dotted rhythm:

// The _ symbol denotes a note placeholder
{8._6_}cdefgfed => c8. d16 e8. f16 g8. f16 e8. d16

A repeating diminution may also be expressed succintly:

// The @ symbol denotes a repeated pitch
{16_@@@}cfgf => c16 c c c f f f f g g g g f f f f

A macro can include both durations and articulation marks:

{4_~6@(_._._.)}cdefgfed => c4 ~ c16 d-.( e-. f-.) g4 ~ g16 f-.( e-. d-.)

A macro containing durations will remain valid until another duration or duration macro is encountered. A macro containing articulation only will be valid until another duration, macro or empty macro is encountered:

6{.}gg{}aa => g16-. g-. a a

Named macros

Macros can be defined with a name and reused:

- macros:
  - dotted: 8._6_
{dotted}gaba2g{dotted}abcb2a => g8. a16 b8. a16 g2 a8. b16 c8. b16 a2

Clefs, key and time signatures

Clefs are determined automatically by lydown based on the specified part. In case no part is specified, the default clef is a treble clef. The clef values are the same as in lilypond. The clef can be changed at any time with a clef setting:

- clef: bass
8cdefgabc
- clef: tenor
defedcbd
- clef: bass
1c

Key and time signatures are entered inline as document settings (see below). The key and time values follow the lilypond syntax:

- key: d major
- time: 3/4

In the case of key signatures, accidentals will follow the lydown syntax:

- key: b- major
- key: f+ minor

Key signatures can also be specified using shorthand notation (upper case for major, lower case for minor):

- key: B- // b flat major
- key: f+ // f sharp minor

The default key signature is C major, and the default time signature is 4/4.

Key or time signatures can be changed on the fly:

- time: 4/4
4c e g b
- time: 3/4
c e g 2.c

Pickup bars

Pickup bars (anacrusis, upbeat) are defined with the pickup setting:

- time: 3/4
- pickup: 4
    4g
c8cdcb4aaa
d8dedc4bb

Lilypond Commands and inline settings

Lilypond commands and settings can be entered inline as part of the note stream:

cd \key:E- e \stemDown f

A useful shorthand is for one-time (\once) overrides, with an exclamation mark between the backslash and the command:

\!override:"NoteHead.color = #red"

Multiple arguments can be given, separated by colons. Arguments need to be quoted only if they contain whitespace, or colons:

\!override:AccidentalSuggestion:"#'avoid-slur = #'outside"

Some lilypond command arguments are expected to be quoted. Quotes can be escaped by prefixing them with a backslash:

\footnote:"#'(-1 . 1)":"\"slurred?\""

Inline lyrics

Lyrics for vocal parts can be entered on separate lines prefixed by a > symbol:

4c[8de]4fd(4c[8de]2f)
> Ly-down is the bomb__

Or between notes using quotes:

4c[8de]4fd(4c[8de]2f) >"Ly-down is the bomb__"

Text alignment follows the duration, beaming and slurring of the music, just like in lilypond. Sillables are expected to be separated by a dash. Melismas, i.e. a single sillable streched over multiple notes, is signified by one or more underscores.

Multiple stanzas for the same music can be specified by including the stanza number in parens:

4cege1c
> Ly-down is the bomb.
>(2) Li-ly-pond is too.

Stream switching

Lyrics can be entered in a block, before or after musical notation, by switching streams:

8ccg'gaa4g
8ffeedd4c
=lyrics
Twin-kle twin-kle lit-tle star,
How I won-der what you are.
=music
8g'gffeed4
...

Multiple lyrics stanzas can be written by including the stanza number in parens:

=lyrics(1) // the numbering is optional, same as =lyrics
...
=lyrics(2)
...

Figured bass

Figured bass is entered inline, following notes or even between notes, when multiple figures align with a single note.

c<6>de<5>c // figures are automatically rhythmically aligned 
e<7`> // barred figure
f<6+> // sharp 6th
g<6-> // flat 6th
g<6!> // natural sixth
a<h> // natural third
a<#> // sharp third
a<b> // flat third
b<7#>b<6_> // extender (tenue) line on sharp third
1c2<6><7-> // use durations to change figures over a long note
1c2<><7-> // <> is an empty figure
c<->dec<.> // extender (tenue) line without figures over the four notes

Multiple parts

Multiple parts can be entered in the same file by prefixing each part's content with a -part setting:

- part: violino1
8c'cg'gaa4g
- part: continuo
4cefe

Multiple movements

For multi-movement works, prefix each movement with a -movement setting:

- movement: Adagio
...
- movement: Allegro
...

Multiple voices

Multiple voices on the same staff can be easily entered using the following notation:

1: 8egfdeg4f 2: 4cded u: ...

the u:<\code> command is used to return to single voice (unisono) mode.

Lyrics can be added for individual voices by using inline lyrics:

1: ceg >"yeah yeah yeah" 2: gbd >"no no no" u: ...

Piano scores

Piano/keyboard scores can be created by using the r/l (right/left) prefixes:

- part: piano
r: 8cdeccdec
l: 4cgcg

In order to jump between staves, you can use the special commands \r, \l

r: 8<e'c'> \l g,f+g \r <g'' c'> \l e,,d+e \r
l: 1s

multi-part scores and part extraction

As the example above shows, lydown supports multiple parts in the same file, but parts can also be written in separate files. This is useful for long pieces or those with a large number of parts.

For this we create a main file which defines the score structure:

// score.lydown
- score:
   - [violino1, violino2]
   - viola
   - violoncello
- time: 4/4
- key: c major

Then we enter the music in a separate file for each part:

// violino1.lydown
8c''cg'gaa4g 8ffeedd4c

And so forth.

To compile the score, we use the following command:

lydown -o -s score.lydown

To extract a specific part, we use the -p switch:

lydown -o -p violino1 score.lydown

Colla parte and part sources

lydown provides two ways to reuse a part's music in another part. The first is by defining a part source:

- parts:
  - violino1:
    - source: soprano

When dealing situations such as a choral being doubled by many instruments, a more convenient approach would be the colla_parte setting:

- colla_parte:
  - soprano: violino1, flute1, flute2, oboe1
  - alto: violino2, oboe2
  - tenor: viola, gamba1
  - basso: gamba2

It is important to remember that the colla_parte setting is the opposite of the part source. Instead of defining a source for a part, it defines the parts that follow the source part.

Including another part when extracting parts

When extracing parts, some cases, such as recitatives, require displaying another part together with the part to be extracted. Parts can be included in extracted parts using the include_parts setting:

- parts:
  - continuo:
    - include_parts: tenore

multiple parts can be specified by comma separating them.

Mode specific code

The \mode and \nomode commands can be used to render code for specific modes. This can be useful when the extracted part should display a different music than the score. The mode command causes anything after it to be rendered only when the rendering mode matches the specified mode.

\mode:score 4cege \mode:part 4cded \mode:none 1c

The example above will be render as 4cege1c when in score mode, and as 4cded1c in the extracted part.

To cancel a mode, use either \mode:none or \nomode

Staff and system appearance

Numerous settings can be used to control the way staves and systems are displayed. Normally, lydown will follow standard conventions when putting together a score: the different parts will be ordered correctly (e.g. flutes, then oboes, then strings, then vocal parts, then continuo), and braced/bracketed according to convention.

When a single movement switches between different ensembles, for example a recitativo secco followed by a recitativo accompagnato, empty staves may be hidden using setting empty_staves setting:

- empty_staves: hide

Normally, instrument names are shown according to convention, to the left of each staff in the first system. To hide the instrument names on the first system, use the instrument_names setting:

- instrument_names: hide

The instrument_names setting can also be set to , in which case the instrument name will be displayed above the beginning of each staff in the first system.

To show the instrument name inline at any point in the music, use the \instr command:

- part: flute
R*4
// when no parameter is given, the part name is used, 
// and engraved capitalized with numbers formatted to roman numerals
\instr 4c8eg2c
...
// when the instrument name is specifed, it is used in place of the 
// part name:
\instr:"Flute II" 4c8eg2c

The \instr command can also accept an alignment modifier:

\<instr // right-aligned
\>instr // left-aligned (default)
\|instr // centered

Another setting which controls the display of instrument names is instrument_name_style which can be set to normal or smallcaps, in which case the instrument name will be engraved using small caps.

Rendering MIDI && mp3 files

In order to render the source code into MIDI, the midi format should be specified:

lydown --midi score.ld

The playback tempo can be specified either using the midi_tempo setting:

- midi_tempo: 4=96

Or inline using the tempo command, putting the tempo in parens:

\tempo:(4=120)
cdef
/tempo:(4=54)
gabc

Rendering of mp3 files requires both timidity and LAME to be installed.

Including files

Lilypond files can be included into the generated lilypond code by using include settings:

- include: abc.ly

Multiple files can be included by adding an include setting for each file. Mode-specific include files can be defined by nesting include statements inside of score or parts settings:

- score:
  - include: def.ly // included only in score mode
- parts:
  - include: ghi.ly // included only in part mode

The include statements are placed inside of a movement's score block as lilypond \include commands, so for each movement different includes can be defined.

To place includes at the beginning of the lilypond document, includes should be defined under the document setting:

- document:
  - include: def.ly // this will be included at the top of the lilypond doc

Pathnames are relative to the lydown source file.

Requiring packages

Lyp packages can be loaded by using -include settings, usually in work.ld:

- require: better-slurs

Including templates

In addition to including normal lilypond files, Lydown also supports the rendering of templates into the generated lilypond doc, by using the .ely extension. The templates should be written using Ruby's ERB syntax, and are supplied with the lydown context object as self. A trivial example:

\markup {
  % will output either 'score' or 'part' according to the rendering mode
  <%= self.render_mode %> 
}

Adding a front cover

To be continued...

lydown's People

Contributors

noteflakes avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

lydown's Issues

MIDI tempo (invisible tempo)

To set a midi tempo that is hidden, with lilypond:

\set Score.tempoHideNote = ##t
\tempo 4 = 96

Lydown:

\tempo:(4=96)

Interactive mode for CLI

When run without any parameters, the lydown command should start an interactive session:

BWV247 sharon$ lydown
BWV247 ♬ score // compile the score for BWV247 and display in browser
BWV247 ♬ cd 01-choro
01-choro ♬ cat viola:53 // show line 53 of viola part
53> dr6re,6.f3g+8a+r4r
01-choro ♬ edit viola:53 // start vim on viola part at line 53
...
01-choro ♬ e flute1:23 // e is shorthand for edit
...
01-choro ♬ viola:53-54 // compile viola part bars 53-54 and open it
01-choro ♬ viola:53- // compile viola part bars 53 to end and open it

Fix settings

Currently settings are all over the place, with no real logic to the way settings are written to the context or read from the context according to circumstances. This leads to many problems (see #25, #26 among others) that are hard to solve.

The idea is to provide two new methods on WorkContext: #get_setting and #set_setting, that will interrogate the settings in part files, movement files, work files, and finally the lydown defaults (stored in lib/lydown/defaults.yml).

Measure number indicators

Measure number indicators are used signify the absolute position of anything that comes after the indicator in terms of the referenced measure. Lydown should automatically add rests (for actual parts) or silences (for the global context - see #37).

An example:

- time: 4/4
- key: D
(20): || // this will put a double bar line at the beginning of measure 20
(35): \fine // this puts a _fine_ indication at the beginning of measure 35...
(37:3): \fine // this puts a _fine_ indication on the third beat of measure 37
(end): \dacapoalfine // this puts a _da capo al fine_ indication at the end of the piece

The (end) measure indicator requires lydown to go over the other parts in the same movement and to calculate the maximum number of measures.

Allow hiding bar numbers

Add a new bar_numbers setting. When set to hide, the following is rendered:

\layout {
\context {
    \Score
    \remove "Bar_number_engraver"
  }
}

Parts sourced from other parts

In movement.ld:

- parts:
  - alto:
    - source: soprano // sources both music and lyrics from soprano
  - violino:
    - music_source: soprano // sources music only from soprano

Better lilypond variable names

It turns out numbers and other symbols can be used in variable names, provided they are quoted.

So, instead of doing the whole dance of converting numbers to roman numbers, capitalizing, upcasing etc, we use a much simpler variable naming scheme, which reflects the stream path in the work context:

"01-choro/soprano/music" = { ... }
"01-choro/soprano/lyrics/..." = { ... }
"01-choro/violino1/music" = { ... }

% usage:
... \"01-choro/violino1/music" ...

Move lilypond invocation code into separate gem

Create an abstract lilypond API, a single function that accepts lilypond source code as input, along with options, and optionally returns the compiled output, or simply writes to the output files and returns their names. For example:

Lilypond.compile(ly_source, format: :pdf, target_path: "BWV247-01-choro")

Reorganize all rendered lilypond code using variables

Objectives:

  • Make the rendering code / templates simpler and easier to change and enhance.
  • Make the rendered lilypond code reusable - repetition, transposition, etc.
  • Allow such features as repeat music with different lyrics.
  • Make the rendered lilypond code simpler to read.
  • Facilitate such features as inline free text markup, table of contents, additional stanzas after music, etc.
  • Facilitate engraving of score and individual parts.
  • Allow output modes such as only variables, only music, only lyrics, output to separate files, etc.

Planning:

This will require a significant change to the current codebase. Whereas a lilypond file generated by lydown looks like a giant nested web, the new file structure will as follows:

  • lilypond version
  • include commands for including standard libs.
  • a list of variable definitions for each stream: music, lyrics, figures.
  • any markup, table of contents, preface, etc.
  • any layout/paper settings.
  • the proper score structure, referencing the music variables.

Full bar silences

In order to faciliate the implementation of global contexts (#37), with or without measure number indicators (#38), lydown should support full bar silences, similar to full bar rests. The syntax is as follows:

S // a single full bar silence
S*20 // full bar silence for 20 meaures

This should be converted into the following valid lilypond code:

s1 // assuming 4/4 time
S1*20

Shorthand for recitativo speaker/part markup:

Right now:

8re\"_Evangelist:_" eb // explicit italic

Proposed syntax (various options):

8r ::Evangelist:: eeb // italic implied
8r :Evangelist: eeb // italic implied
8r \"_Evangelist:_" eeb // explicit italic
8r :Evangelist: eeb
8r :{Evangelist} eeb

Exclude part from score

Add option to exclude part from score. Suppose there's a part that's there only for part extraction, not for being rendered as part of the score.

- parts:
  - tenore_without_turbas:
    - render_modes: part

Where the default is part, score.

An idea for power editing

In interactive mode, we can zone in on different places in the score:

lydown
BWV247:) // this is the prompt
BWV247:) cd 01-choro // enter into a movement directory
01-choro:) flute1:37 // show measure 37 of flute1 part
  flute:37: 4fa'~{6._3_}afe+e6c-a8b
01-choro:) edit flute1:37 // open file in editor and select specified line 

Mode specific code

The code will be rendered only when the rendering mode fits corresponds to the specified mode:

\score // everything after this directive will be rendered only in score mode
\part // everything after this directive will be rendered only in part mode
\all // everything after this directive will be rendered in any mode

Markup section syntax

(See #33)

General features

  • Text is sort of markdown based: Free flowing paragraphs, support for italic and bold

  • back-slash-prefixed commands to control appearance

  • line breaks, page break are explicit

  • provide some way to control horizontal and vertical whitespace

    =intro
    \centered Passio Domini nostri\n
    _J. C. secundum evangelistam Marcum\n
    \n
    BWV 247\n
    ...

    =outro
    \n:30 // 30 times new line
    Sources:\n
    ...

Inline overrides

Lilypond syntax:

\override Stem.thickness = #5.0
\once \override Stem.thickness = #5.0

Lydown current command syntax:

\override:"Stem.thickness = #5.0"

New lydown override syntax:

\\Stem.thickness:5.0

Override once:

\\!Stem.thickness:5.0

Support for true/false literals (##t / ##f), strings (#"..."), numbers (#5 / #5.0) etc.

Part source and colla parte definitions

Parts should be able to source from other parts. For example, an oboe part that plays with the soprano in a choral, or a cello part that plays the continuo part, but without the figures.

Two ways to define part sources. The first:

- parts:
  - oboe1:
    - source: soprano
    - lyrics: hide
  - flute1:
    - source: violino1
  - violoncello:
    - source: continuo
    - figures: hide

The other way is define colla parte settings, which invert the setting:

- colla_parte:
  - soprano: oboe1, oboe2 // oboe1 & oboe2 double the soprano part
  - continuo: violoncello // the violoncello doubles the continuo part

When run on a movement, lydown should process the work directory

When invoked in a movement directory, lydown should automatically process the work.ld file of the parent directory, and treat the movement name as an -m parameter.

Same thing when the specified path given to lydown is a movement. For example:

BWV247$ lydown 01-choro

Should be equivalent to

BWV247$ lydown -m 01-choro

See also issue #2.

Cache event streams, rendered streams in order to improve performance

When a big project is being processed, the parsing and rendering of hundreds of files can take quite a bit of time, even before lilypond starts compiling the rendered code. For example, BWV 247 takes over 20 seconds to parse and render, and even that after being parallelized (see #5).

A way to improve this state of affairs is to cache the results of each step, using temp files.

For parsing, it's rather simple:

  1. The source lydown file is read.
  2. A hash for the content is calculated.
  3. Lydown searches for a corresponding temp file (e.g. .parse)
  4. If a temp file is not found, the content is parsed into a lydown event stream, then written to the temp file using MsgPack encoding.
  5. If the temp file is found, its content is parsed using MsgPack.

For rendering, it's a bit more complex, since we need to take into account the state of the work context, so:

  1. The hash value for the work context is calculated => h1.
  2. A hash for the lydown event stream is calculated => h2.
  3. Search for corresponding temp file:

    .

    .render.

  4. If the temp file is not found, the stream is rendered, then written to the temp file using MsgPack encoding.
  5. If the temp file is found, its content is parsed using MsgPack.

Translate Ripple code into Lydown code

  • Usage: lydown translate 01-choro
    The above command will translate the entire subdirectory, leaving the role files in place and creating new lydown files in the same directory
  • Translation code will reside in lib/lydown/translation/ripple
  • Parsing using custom treetop rules
  • Look for macros in _work.yml, _movement.yml files
  • Parse relative command to determine octave of first note.
  • Ignore curly brackets
  • Parse and translate note events: note head, duration, expressions
  • Parse key signature and translate chromatic note names into diatonic ones
  • Parse and translate duration macros
  • Look for lyrics files and as them to output under a =lyrics section

Global music

In order to maximize the DRY principle, we could use work.ld or movement.ld files to provide a global music stream that includes the key and time signatures (with partial/pickup definitions), key and time signature changes in the middle of the piece, tempo changes, double bar lines, repetitions, etc.

In the rendered lilypond code, a global stream can be incorporated as follows:

ldGlobalMusic = {
  ...
}

\new Staff <<
  \ldGlobalMusic
  { \ldFluteMusic }
>>

The lydown code will look as follows, for example a movement.ld file:

- key: D
- time: 3/4
- pickup: 4
- tempo: Largo
S*20 // full bar silences (this also needs a separate issue)
\tempo: Allegro \time:4/4 ||

See also #38 for measure number indicators.

Default house style

  • instrument names using small caps
  • thicker stems
  • thicker slurs
  • curvier slurs
  • Better font for lyrics
  • Nice inner/outer margins
  • Zero indent for first system, instrument names inline
  • note_head_style: baroque. See here
  • introduce some variability into setting by using a tiny amount of randomness.

lypad - Lilypond package manager (non lydown-related)

The idea is to be able to install libs & tools related to lilypond, and use them without too much hassle.

  • Dependencies for a project are declared in a filename called Lypadfile
  • packages are Ruby gems, downloadable using the gem tool.
  • package names are prefixed with lypad-. That way we can tell which gems are lypad-related. For example, a package called lilyjazz will be published as a gem called lypad-lilyjazz.
  • system is ruby based.
  • lypad command line tool is basically a wrapper around gem / bundler.
  • lypad also provides some lib tools for stuff like installing fonts, or changing the stock lilypond installation in any way.

When Lypad is installed it modifies lilypond to add a few lilypond commands used to reference and load packages.

Loading packages in lilypond sources

\require "lilyjazz" % that's all folks

Command line interface

lypad update # updates the lypad installation and installs hooks in the current lilypond installation
lypad install # installs anything in Lypadfile
lypad install <gem> # installs the gem
lypad install <gem> -s # installs the gem and writes it to Lypadfile
lypad uninstall <gem>
lypad list # lists all lilypond-related gems

Silent/verbose mode for command line tool

Translation mode: show progress bar for translation
Compile mode: show progress bar for parsing, and then progress bar for compiling
Proof mode: progress bar for compiling

In silent mode, show nothing except errors

Layout settings

  • layout:
    • paper_size: A5 landscape
    • top_margin: 1.4cm / 2in
    • bottom_margin: 1.4cm
    • inner_margin: 1.4cm // implies two-sided = ##t
    • outer_margin: 1.4cm // implies two-sided = ##t
    • left_margin: 1.4cm // implies two-sided = ##f
    • right_margin: 1.4cm // implies two-sided = ##f
    • staff_size: 14 // default: 20
    • indent: 0 // first system indent
    • vertical_align: justify/ragged/ragged_last // ragged-bottom, ragged-last-bottom settings (default is ragged_last)
    • horizontal_align: justify/ragged/ragged_last // ragged-right, ragged-last (default is justify)

Include lilypond files

Use the -include setting to include arbitrary lilypond files:

- include: abc.ly
- include: ../def.ly

The included files will be included at the beginning of a movement.

Including only in score mode:

- score:
  - include: ...

Including only in parts mode:

- parts:
  - include: ...

Including at top of lilypond doc:

- document:
  - include: ...

Cues in parts

The cues should appear only in part mode.

Lilypond:

<<
    { e'2\rest r4. e8 }
    \new CueVoice {
      \stemUp d'8^"flute" c d e fis2
    }
  >>

Lydown:

\cue:flute 8d'cde2f+ \cueWhile 2r4.r8e \cueEnd

Or maybe:

\cue:flute:{{8d'cde2f+}} 2r4.r8e

In that case, the system automatically matches the cue length to the music after, in order to create the corresponding nested lilypond structures.

Another option, in addition to the \cue command, is a quote command:

\quote:flute1 2r4.r \unquote, 8e

which translates to lilypond:

ldViolinoIMusic = { ... <>^\markup \tiny { \smallCaps { Flute I } } \cueDuring #"ldFluteIQuote" #UP { r2 r4.} e8 ... }
ldFluteIMusic = { ... }
\addQuote "ldFluteIQuote" { \ldFluteIMusic }

(Some kind of registry for quoted voices, so we know to add \addQuote commands)

Also, ability to provide custom titles for cue:

\quote:tenore:"_Evangelist:_" 2r4.r \unquote, 8e

Lilypond:

ldViolinoIMusic = { ... <>^\markup \tiny { \italic { Evangelist: } } \cueDuring #"ldFluteIQuote" #UP { r2 r4.} e8 ... }
ldFluteIMusic = { ... }
\addQuote "ldFluteIQuote" { \ldFluteIMusic }

Also, ability to cue with clef:

\quoteWithClef:treble_8:tenore:"_Evangelist:_" 2r4.r \unquote, 8e

Lilypond:

ldViolinoIMusic = { ... <>^\markup \tiny { \italic { Evangelist: } } \cueDuringWithClef #"ldFluteIQuote" #UP #"treble_8" { r2 r4.} e8 ... }
ldFluteIMusic = { ... }
\addQuote "ldFluteIQuote" { \ldFluteIMusic }

The vertical position of the cue on the staff can also be controlled using the vertical position specifiers:

\quote:tenore ... \unquote // default is on top of staff music (UP)
\_quote:tenore ... \unquote // on bottom - under staff music (DOWN)
\^quote:tenore ... \unquote // on top - like the default (UP)

Throw error on setting command attached to note

A setting command can be easily attached to a note by mistake, by omission of whitespace:

c\key:D

A simple heuristic to prevent this would be to reject any note expressions containing a colon after the expression name.

Better time signatures

Single digit time signatures

For certain pieces, we would like to display the numerator only. With lilypond:

\once \override Staff.TimeSignature.style = #'single-digit
\time 5/4

With lydown:

\time:5/(4)

Hidden time signatures

Lilypond:

\once \override Staff.TimeSignature #'break-visibility = ##(#f #f #f) 
% or:
\once \override Staff.TimeSignature #'stencil = ##f
\time 5/4

Lydown:

\time:(5/4)

No time signature before line break

Lilypond:

\once \override Staff.TimeSignature #'break-visibility = ##(#f #t #t) 
\time 5/4

Lydown:

\time:5/4!

4/4 time signature shorthand

\time:c

2/2 time signature shorthand

\time:c/

Emit lilypond warnings

Currently the compiler swallows warnings. Instead, they should be parsed and lydown should be able to find the offending part (usually these warnings have to do with unterminated ties, beams or slurs).

Parallelize source file processing

When processing a directory, things can be parallelized:

  • Parsing individual files can be performed by a thread pool. Generating an AST and event stream for each file can be completely parallelized. The actual generation of lilypond code can be serialized using a critical section or some other lock.
  • This actually should be relatively simple:
    • Work#process_directory starts a worker thread pool and adds each encountered file to the worker queue.
    • Workers pull file names from the worker queue and process them using process_lydown_file.
    • Work#process_lydown_file uses a critical section or other lock to synchronize the last stage of processing, the actual translation to lilypond code is serialized.

recitative mode

Recitative mode implies:
- instrument_names: hide
- empty_staves: hide except continuo

Score/part page breaks

In movement.ld:

- score:
  - page_break: before
- parts:
  - gamba1:
    - page_break: before

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.