[abcusers] LilyPond 2.2.0 released
This is really from Jan Nieuwenhuizen [EMAIL PROTECTED], who asked me
to forward it here.
Dear music enthousiasts,
LilyPond is a program for making beautiful music notation. It is
free/open source software, and is available for all popular operating
systems. It runs on most Unix flavors --including Linux and MacOS X--
and MS Windows. Use it for your music too!
LilyPond version 2.2 was released today!
This release has completely revamped support for for orchestral score
formatting, cue notes, font size management, lyric formatting, drum
notation/playback and document integration.
In addition, it has numerous syntax simplifications, proper support
for 8va brackets, and a completely updated manual.
Go and grab it at
http://lilypond.org
A big thank-you goes out to our contributors:
David Bobroff, Edward Sanford Sutton, Heikki Junes, and Nicolas
Sceaux.
Also thanks to our bug-hunters:
Alexandre Beneteau, Andrew McNabb, Atte Andre Jensen , Bertalan Fodor,
Bruce McIntyre, Dave Symonds, David Bobroff, Darius, Delma Avers, Doug
Linhardt, Eric Wurbel, Erik Sandberg, Ferenc Wagner, Hans Forbrich,
John Williams, Jos Luis Cruz, Juergen Reuter, Kieren Richard
MacMillan, Laurent Martelli, Mats Bengtsson, Matthias Kilian, Nancho
Alvarez, Nick Busigin, Nicolas Sceaux , Olivier Guery, Patrick
Atamaniuk, Paul Scott, Pawel D, Pedro Kroger, Ray McKinney, Reuben
Thomas, Rob V, Stef Epardaud, Thomas Willhalm, Thomas Scharkowski, Tom
Tom Bckstrm, Werner Lemberg, and Will Oram.
Happy music printing,
Han-Wen Nienhuys Jan Nieuwenhuizen
(core development team)
New features in 2.2 since 2.0
*
* Setting `raggedlast = ##t' in the `\paper' block causes the last
line to be set flush-left instead of justified.
* The `Timing_engraver' now sets the `Timing' alias on its
containing context automatically.
* The code for font selection has been rewritten. In addition to
existing font selection properties, the property `font-encoding'
has been added, which makes the switch between normal `text' and
other encodings like `braces', `music' and `math'.
* The pmx2ly script has been removed from the distribution.
* Pedal brackets will now run to the last bar of a piece if they are
not explicitly ended.
* Context definitions now use the word `\context' instead of
`\translator'.
* Property functions may be used as an argument to `set!', for
example
(set! (ly:grob-property grob 'beam) ... )
* In anticipation of Emacs 21.4 or 22.1, the info documentation
contains images.
* Cue notes can be quoted directly from the parts that contain them.
This will take into account transposition of source and target
instrument. For example,
\addquote clarinet \notes\relative c' {
\transposition bes
fis4 fis fis fis
}
\score {
\notes \relative c'' {
c8 d8 \quote 2 oboe es8 gis
}
}
* The transposition of an instrument can be specified using the
`\transposition' command. An E-flat alto saxophone is specified as
\transposition es'
* The naming of exported Scheme functions now follows Scheme
conventions. Changes be applied to Scheme files with
convert-ly -e -n --from=2.1.24 --to=2.1.26 *.scm
* Notes can be excluded from auto-beaming, by marking them with
`\noBeam'
c8 c \noBeam c c
will print two separate eighth notes, and two beamed notes.
* Translators and contexts have been split. The result of this
internal cleanup is that `Score' no longer is the top context;
`Score' is contained in the `Global' context. Consequently, it is
possible to tweak `Score' as follows:
\context Score \with {
...
}
* The number of staff lines in Tablature notation is now
automatically deduced from the `stringTunings' property.
* The program reference has been cleaned up and revised.
* The syntax for setting properties has been simplified: the
following table lists the differences:
(old) (new)
\property A.B = #C\set A.B = #C
\property A.B \unset \unset A.B
\property A.B \set #C = #D\override A.B #C = #D
\property A.B \override #C = #D (removed)
\property A.B \revert #C \revert A.B #C
Furthermore, if `A' is left out, the bottommost context is used by
default. In other words, it is no longer necessary to explicitly
mention `Voice', `Lyrics' or `ChordNames'.
Old:
\property Voice.autoBeaming = ##f
\property Staff.TimeSignature \set #'style = #'C
New:
\set autoBeaming = ##f
\override Staff.TimeSignature #'style = #'C
* Tweaks made with `\override' and `\revert' no longer hide tweaks
at
Re: [abcusers] ABC and MusicXML
I had not considered using separate voicing for chords. Thanks. Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| Either way, I'm going to use your examples to go back and reformat many tunes. Thanks. //Christian Jack Campin wrote: There's a few things that prove to be making reading ABC on the fly a real difficult task. I wonder what other people feel about my stumbling stones. 1. inline chords. Flotsom floating down midstream making navigation difficult. Yes, better to put them in a separate voice if possible. 2. spacing on either side of barlines... this actually is a very helpful deliniation for me... the problem arises with the numbered repeats |1 and :|2... all the programs I've tried only recognize these 'tokens' provided they do not have those spaces I like so much for readability | 1 aBc aBc :| 2 abc abc | No. Barlines are far less obtrusive if you align your source properly, and taking three characters to express each one can soon run you out of columns in attempting to align a complicated piece. Any readability problem with this? X:1 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| and if you want repeats, this is more readable than your way, as the [1 notation says clearly what the numeral is for and you only use one way of expressing the repeat boundary rather than two depending on where in the bar the repeat starts: X:2 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2| A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2| a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|[1 A4 A2AB|d4 e2de|f2d2 d2 :| [2 ABAF A2AB|d4 e2de|f2d2 d2 |] Though usually you'd write this instead, making the repeat unit a more meaningful piece of musical structure: X:3 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| [1 d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| [2 d2B2 A2F2|ABAF A2AB|d4 e2de|f2d2 d2 |] And it's usually easier to find a reasonable staff notation layout for 20 bars than is for 19, e.g,. for five bars to a line: X:4 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB| d4 e2de| f2e2 egfe|\ d2B2 A2F2|!A4 A2AB| d4 e2de| f2d2 d2 :|\ de|f2e2 f2g2| a2ba g2f2|!e2b2 b2a2| b2e2 egfe|\ [1 d2B2 A2F2| A4 A2AB| d4 e2de|!f2d2 d2 :|\ [2 d2B2 A2F2| ABAF A2AB| d4 e2de| f2d2 d2 |] - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- //Christian Christian Marcus Cepel| And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again.--Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
What? No xhtml compliance? p / John Chambers wrote: html Neil Jennings writes: blockquote MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. MusicXML needs to be read along with the DTD. /blockquote p Well, yes, that's technically true. HTML was intended to be a simple, unobtrusive markup that wouldn't interfere with readability. I like to illustrate this by adding HTML to my message, which I'll do now . p But most of the HTML you see in email is utterly unreadable by the typical human. We can expect that most MusicXML will be similar computer gibberish. Neither could be remotely called plain text. p Of course, it's easy to find ABC that's nearly as unreadable. p (Maybe we should refer ABC newbies to Jack Campin for lessons in making readable ABC. ;-) p I hope the list server doesn't strip out this HTML ... /html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- //Christian Christian Marcus Cepel| And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again.--Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Christian M. Cepel writes: | What? No xhtml compliance? | p / Nah; HTML 0.9. ;-) | John Chambers wrote: | | html |Neil Jennings writes: |blockquote | MusicXML is plain text, just as all the markup languages are, but that | doesn't mean you don't have to decode it. | Can you decode even simple HTML by just reading it?. | MusicXML needs to be read along with the DTD. |/blockquote | p |Well, yes, that's technically true. HTML was intended to be a |simple, unobtrusive markup that wouldn't interfere with readability. |I like to illustrate this by adding HTML to my message, which I'll |do now . | p |But most of the HTML you see in email is utterly unreadable by the |typical human. We can expect that most MusicXML will be similar |computer gibberish. Neither could be remotely called plain text. | p |Of course, it's easy to find ABC that's nearly as unreadable. | p |(Maybe we should refer ABC newbies to Jack Campin for lessons in |making readable ABC. ;-) | p |I hope the list server doesn't strip out this HTML ... | /html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| No, they're fine by all standards since 1.5 at least - nor, as far as I know, has any ABC software ever had a problem with them in practice. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 6 Apr 2004, at 21:10, Jack Campin wrote: Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| No, they're fine by all standards since 1.5 at least - nor, as far as I know, has any ABC software ever had a problem with them in practice. Provided, that is that the line doesn't start with a field letter. A space before a non-inline field is illegal. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Phil Taylor writes: | On 6 Apr 2004, at 21:10, Jack Campin wrote: | | Regarding lining up barlines... I had thought that spaces in | position 0 | on a line were illegal. | IE, the # here | | fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| | ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| | | No, they're fine by all standards since 1.5 at least - nor, as far as | I know, has any ABC software ever had a problem with them in practice. | | Provided, that is that the line doesn't start with a field letter. A | space before a non-inline field is illegal. Funny thing is that I've been lately working on handling ABC that does just this. One of the ongoing challenges with my Tune Finder has been handling ABC embedded inside HTML. This is not a good idea, of course, but you can't stop people from doing it. One of the frequent ways that people do this includes indenting all the ABC to match the indentation of the HTML tags. It looks fine on the screen, because HTML renderers ignore such white space. I've found one site that has all its ABC done this way. (I won't name them, to protect the guilty - and clueless. ;-) My situation right now is that there are some such tunes that my search bot can recognize, but they aren't always recognized by the code that the Finder uses to extract a tune from a page. So you can see a tune listed, and then when you try to get it, you're told that it's not there. This web stuff isn't always easy. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
