battle-plan for 2.5 development

[Han-Wen Nienhuys]

Hi there,

with 2.4 just released, it is time to share what each of us is up to.
In this post, I want to tell you about my plans for LilyPond for the
coming time.

I invite you all to follow this example, and post where you would like
to steer LilyPond to. To keep the discussion focused, please respond
with what you plan to contribute rather than what you want to have.


Before I continue, I want to stress that there are a lot of "minor"
improvements (eg. string-number notation, figured bass improvements,
accordion notation, etc etc etc), that are not mentioned in this post.
This is on purpose. My plan is to stick to the development points that
I have put in this mail.  Additional feature requests will still be
considered, in exchange for contributions, either in the form of money
or patches.



INTRODUCTION

My target for LilyPond is that it becomes the tool of choice for
high-quality engraving, both for professionals and amateurs. More
concretely spoken: to take the leading position in this area from
SCORE, Finale and Sibelius.

This breaks down into several short-term sub-goals, each of which I
want to describe below,





TEX/ENCODING

The next stable release will probably be called LilyPond 3.0, and the
primary goal for that release is to be usable without requiring TeX.


Why?

* It simplifies installation

* reduces size of install (I hear windows users getting scared of the
  install procedure, since "It starts to download other things!")

* PostScript is a more robust solution, while the TeX solution is
  rather complex, and takes relatively much developer time to support.

This problem is linked with getting support for international
character sets internally. We need this get accurate widths for lyrics
and other texts.

Problems/issues for TeX/encoding:

    * lilypond/lilypond-book should be modified use 1 EPS file per
      system.

    * We will need a custom file searching system

    * We will need a point and click substitute (the Gnome backend!)

    * In case TeX is used, it should be a runtime option (ie.: dynamic
      loading of the TeX backend, so we can ship it as separate add-on
      package)

    * Handling text completely inside LilyPond also implies dealing
      with ligatures and kerning.  

    * How do we construct output in the PostScript, TeX and the GNOME
      backends?

    * Most fonts have a limited set of glyphs, and we will have to
      glue accents and unaccented characters together to get
      international (latin) characters

I hope to work on this together with Werner, who has already agreed to
tackle the PostScript part of the encoding problem.


GNOME BACKEND FOR POINT AND CLICK

Tweaking output remains a cumbersome task, and without TeX, we don't
have a backend for point & click anymore. Both problems can be solved
with the Gnome backend.

In the GNOME backend, we have full access to the internals, so that
when you click a note head, we can have a window popping up, saying

  object:
    NoteHead
  properties:
    font-size = 0
    duration-log = 2

within such a window, we have assistents for creating tweaks, and link
to the internal documentation directly. For instance, we can show the
documentation for "font-size" within a tooltip, and we can show the
complete documentation for "NoteHead" when it is clicked.

I expect that this functionality will yield a major productivity boost
when tweaking complex scores.



TYPOGRAPHY

The worst outstanding typographical problems should be solved, among others,

    * Rewrite tie formatting

    * Dynamics ?

    * Cross-staff stems

Especially the first point should also be tackled for the 3.0 release.



WEBSITE

The current website is a lot better than we had; I'm glad it has some
interesting articles, and that it refreshes a lot (basically, for
every Lilypond release), but it could be much more the center of a
community.

For this reason, I think that lilypond.org should become a database
driven website, where users can log-in, post comments, contribute
articles and give the development team instant feedback on releases,
documentation, etc.

This means that the lilypond.org website should be transformed to use
a CMS (content-management system), like mambo-server, drupal or plone,
and it should be redesigned to look nicer and be more colorful.

This is something I plan to look at myself, but it is also something I
could definitely use help with from PHP/CMS/webdesign gurus.



COMMUNICATION

The development team should be present at the 2005 Linux Audio
Developers Meeting (april 2005) in Karlsruhe. This requires writing a
paper, which I plan to do myself. Nevertheless, interested writers are
welcome to contact me, should they wish to attend as well. For
example, it would be interesting to have a case-study of "advanced"
LilyPond use.


BUILD IMPROVEMENTS

Maintenance of the autoconf/make build system is a cumbersome waste of
time.  It takes a lot of work to add new compile/link (-f gnome!)
dependencies. I want to move the build system to Scons (www.scons.org)
as soon as possible. This depends on a number of fixes for SCons
slowness. I hope that the SCons development team fixes these soon.


CLEANUPS

There are some open ends with existing functionality, among others 

    * Manual slur tweaks

    * Cleaning out input/test/

    * Internationalise user messages emitted from Scheme

    * Fix outstanding problems with cue-notes.  Among others, 
      the problem of quoting grace notes.

    * Make {} represent real lists in markup, and transform \markup {
      a b \bold { c d } e } in

      \markup \formatline { a b \bold c \bold d e }


POST-3.0

At the moment, most post-3.0 issues that we see are related to
interaction with other software.

* Right now, there are a bunch of programs that try to export (and
  even: import) .ly files. This is rather impractical for a number of
  reasons. It would be much better if we could read and write .ly
  files in XML (or similar format). This should be thought of along
  the lines of the to-xml.ly example file.

* The GNOME backend can be the start of an architecture where LilyPond
  acts as the "notation display server" for third party applications
  like Ardour, RoseGarden, etc.: a program wishing to display notation
  dumps aforementioned XML down a pipe/socket/etc., and LilyPond puts
  the result in a GNOME canvas or down some other IPC channel.

* Interoperation can take other forms. Most notably, there is
  MusicXML. We have received multiple requests to support MusicXML,
  both as import and export format. Personally, I am a bit skeptical
  of this feature, as I haven't heard many actual LilyPond users ask
  for them. Until further notice, I classify this feature as a "will
  gladly implement this in exchange for money."






-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen