Discussion:
LilyPond 2.10—10 years anniversary release
Han-Wen Nienhuys
2006-11-13 13:52:28 UTC
Permalink
Utrecht the Netherlands—November, 2006.

The initial inspiration for LilyPond came ten years ago when two
musician friends grew disappointed with the bland and boring look of
computer formatted scores. Every musician prefers to read beautiful
music, so couldn't we programmers solve that printing problem?

LilyPond just does that: it prints music in the best traditions of
classical engraving with minimum fuss. Don't waste time on tuning
spacing, moving around symbols, or shaping slurs. Impress friends and
colleagues with sharp sheet music!

Check out LilyPond at

http://lilypond.org


We are proud to announce the 10-year anniversary release, LilyPond
version 2.10.


NEW STUFF

* Creating music with good page turning points is easier than ever.

The new page breaking algorithm will tune both horizontal and
vertical spacing. Hence, page turns will only fall at rests or places
that you mark explicitly.

* Flat music export format.

LilyPond uses an elegant input format, that uses identifiers,
arbitrary nested structures and inline Scheme expressions. While the
format is easy to write and read for humans, it is less so for programs.

With this release, Erik Sandberg has contributed internal
rewrites that make it possible to output a much simpler intermediate
format. In the long term, this will enable other programs to read
LilyPond music.

* Many small features and formatting improvements.

This includes support for falls and doits, dashed barlines, al
niente hairpins, right hand fingerings for guitar, better formatting of
tied chords, automatic beaming and nested tuplets.

A full list of new features is at

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

Enjoy!

Han-Wen Nienhuys - Core development
Jan Nieuwenhuizen - Core development
Graham Percival - Documentation Editor and Bug Meister
Mats Bengtsson - Support Guru





Contributors

Angelo Contardi, David Feuer, Erik Sandberg, Erlend Aasland, Guido
Amoruso, Heikki Junes, and Joe Neeman.


Sponsors

Andrew Sidwell, Anthony Youngman , Chris Sawer, David Griffel, Jamie
Bullock, Kieren MacMillan, Michael Meixner , Paul Scott, Rick Hansen,
Steve Doonan, Trent Johnston, Trevor Bača, Vivian Barty-Taylor and
William Wilson.


Documentation helpers

Cameron Horsburgh, Dave Luttinen, Eduardo Vieira, Erlend Aasland, Geoff
Horton, and Juergen Reuter.


Bughunters

Albert Frantz, Arvid Grøtting, Anthony Youngman, Aurèle Duda, Ben
Hoefer, Bernie Arai, Cameron Horsburgh, Charles Cave, Christian Hitz,
Christopher Ellis, Claude Routhier, Colin Wilding, Daniel Tonda
Castillo, David Rogers, Francisco Vila, Harald Wellmann, Henrik Frisk,
Johannes Schindelin, John Williams, J. Leung, Karim Haddad, Karl Hammar,
Keith Packard, Kieren MacMillan, Lee T. Wilkirson, Lieke van der Meer,
Luc Wehli, Manuzhai, Mark Dewey, Marcus Macauley, Markus Schneider,
Matti Aaltonen, Michael Meixner, Michael Welsh Duggan, Milan Zamazal,
Orm Finnendahl, Paul Scott, Phillip Kirlin, Quentin Spencer, Rainer
Typke, Rick Hansen, Rutger Helmers, Ruud van Silfhout, Sietse Brouwer,
Stephen Carter, Stephen Kress, Thies Albrecht, Toine Schreurs, Trent
Johnston, Trevor Bača, Trevor Daniels, Vaclav Smilauer, Vicente Solsona
Dellá, Victor Eijkhout, Villum Sejersen, Werner Lemberg, Will Oram, and
Zoltan V. Laszlo.
--
Han-Wen Nienhuys - hanwen-qWit8jRvyhVmR6Xm/***@public.gmane.org - http://www.xs4all.nl/~hanwen
David Psenicka
2006-12-03 21:56:53 UTC
Permalink
Fixed a big problem with running speed in OpenMCL (if quantizing is
turned on)--it should be much much faster now (seconds as opposed to
minutes).

v0.2.12
Some module-compiling/loading enhancements w/ ASDF (Kilian)
Fixed huge performance bottleneck noticeable especially in
OpenMCL--now runs at least 30x faster in OpenMCL and slightly faster in
other Lisps
(small tweak in quantize function was all that was needed)
Changed "plugins" to "modules" everywhere (seems to be a better name
for them)
Rob Canning
2006-12-04 20:18:05 UTC
Permalink
hi david,

i've just installed fomus on a new computer - had 0.2.09 on it at first
which worked then upgraded to the 2.12 - now i get the error:

;;;error in function LISP::CLOSED FLAME:
;;#(Stream for file "/fomus-0.2.12/modules/ads.lisp") is closed"

any idea what this is about? i'm using --cmucl by the way

i've been away from fomus for a while but am starting to use it again -
many thanks for it - i'm finding it an invaluable tool

rob
--
rob canning
skype: retroerto
Rob Canning
2006-12-04 20:39:07 UTC
Permalink
i just downgraded to 0.2.11 and the problem disappears so i guess its a
bug in 0.2.12 ?
Post by Rob Canning
hi david,
i've just installed fomus on a new computer - had 0.2.09 on it at
;;#(Stream for file "/fomus-0.2.12/modules/ads.lisp") is closed"
any idea what this is about? i'm using --cmucl by the way
i've been away from fomus for a while but am starting to use it again
- many thanks for it - i'm finding it an invaluable tool
rob
--
rob canning
flat 57 besford house
london e29bj
info-***@public.gmane.org
www.robcanning.info
+44 (0)7981913075
skype: retroerto
David Psenicka
2006-12-04 21:43:01 UTC
Permalink
Thanks, I'll check it out--if it happens right when it loads (after the
banner appears) and it's only printing something out (not actually
signaling an error) then it's probably okay (it's compiling the modules
to see which ones it's able to load)
Post by Rob Canning
i just downgraded to 0.2.11 and the problem disappears so i guess its
a bug in 0.2.12 ?
Post by Rob Canning
hi david,
i've just installed fomus on a new computer - had 0.2.09 on it at
;;#(Stream for file "/fomus-0.2.12/modules/ads.lisp") is closed"
any idea what this is about? i'm using --cmucl by the way
i've been away from fomus for a while but am starting to use it again
- many thanks for it - i'm finding it an invaluable tool
rob
Rick Taube
2006-12-05 22:57:20 UTC
Permalink
id be interested in knowing what the issues were that resulted in the
slowdown in openmcl. when i was notating my last piece i heard the
disk chatter quite a bit, i thought perhaps it was something with
vmem but apparently not...
ill have to try the new version with some input that took several
minutes -- i dont knwo if quantizing was on or not (i used the
defaults) but i was specfiying time values as rationals.
Post by David Psenicka
Fixed a big problem with running speed in OpenMCL (if quantizing is
turned on)--it should be much much faster now (seconds as opposed to
minutes).
v0.2.12
Some module-compiling/loading enhancements w/ ASDF (Kilian)
Fixed huge performance bottleneck noticeable especially in
OpenMCL--now runs at least 30x faster in OpenMCL and slightly
faster in
other Lisps
(small tweak in quantize function was all that was needed)
Changed "plugins" to "modules" everywhere (seems to be a better name
for them)
_______________________________________________
fomus-devel mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/fomus-devel
David Psenicka
2006-12-06 02:07:06 UTC
Permalink
From what I can tell, openmcl was spending a lot of time instantiating
some of the classes I had defined (although according to
http://www.cliki.net/Performance%20Benchmarks2 openmcl should be pretty
fast at this). so I'd have to do more profiling to be sure that that's
what it really was--all of my profiling tests kept pointing to the
make-instance functions in splitrules.lisp (which generates rules for
splitting measures, etc.)--the real problem was in another part of the
program anyways (the quantizing search engine) which generated much more
of these rules than were necessary, so I fixed this which seemed to fix
the problem. (it was a pretty dumb error, but it makes the difference
between having to instantiate tens-of-thousands of CLOS classes and
generating only a few hundred)

I'd like to know how it runs w/ your input--I'd wait until I'm done
retesting this in all the different lisps/platforms though (in a day or
two), there are a few issues in the module loading/compiling that I have
to make sure are fixed... :) (or you can tell fomus to skip the
modules part when it loads by adding a FOMUS-NOAUTOREG to *features* &
recompiling)
id be interested in knowing what the issues were that resulted in the
slowdown in openmcl. when i was notating my last piece i heard the
disk chatter quite a bit, i thought perhaps it was something with vmem
but apparently not...
ill have to try the new version with some input that took several
minutes -- i dont knwo if quantizing was on or not (i used the
defaults) but i was specfiying time values as rationals.
Loading...