lilypond-devel
[Top][All Lists]
Advanced

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

Re: battle-plan for 2.5 development


From: Erik Sandberg
Subject: Re: battle-plan for 2.5 development
Date: Wed, 10 Nov 2004 17:36:00 +0100
User-agent: KMail/1.6.2

On Friday 05 November 2004 13.49, Han-Wen Nienhuys wrote:
> 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.

I will contribute with continuous work on bughunting and -administration, as 
usual.

Against your orders, I am here posting some features requests. Some are just 
my own ideas (i.e. pretty off-topic, it's better to see them as design ideas 
than as feature requests). Some are based on user response & bughunting, and 
can thus be seen as more relevant.

> 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 is just so cool. For the first time we have an open and clear 
step-by-step World Domination Plan :)

I believe that in the end, if finale & sibelius are to be beaten, someone 
should also sell lilypond in some kind of nice boxed form. I believe that it 
too often happens that a musician just goes to the music shop, and checks 
which programs there are to buy. If lilypond doesn't exist there, then she 
will buy some other program. But if there does exist a box with lilypond, 
much cheaper than the other programs, then there is a chance that she will 
have a look at it and actually see the difference in quality. We simply need 
to target the big group that doesn't yet understand about Free Software and 
still believe that software is something that you're supposed to buy.

Also, selling stuff like this might make it possible for our Gurus to spend 
more time on improving lilypond.

Selling boxed lilypond is probably far-future. And it might not even be our 
job, the sellable product might simply be a boxed lilypond-based music 
typesetting suite, using e.g. rosegarden as its user interface.

> 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.

* Makes the GNOME backend possible... This might be pretty important for World 
Domination.

> 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.

OK - I didn't notice this myself, but I guess you know what you're talking 
about.. c-tie-tie is the only active tie bug, which doesn't look too serious 
to me.

Among bugs, I find that the following ones make more sense to me (though all 
aren't layout problems):

- Grace notes is a problem. You mentioned yourself that the grace note code 
currently is very hairy; and there do exist severe bugs (e.g. midi-grace). 
Plus the problem with skip grace note padding as in <<{\key c \grace s c d e 
f} {grace a g f e d}>>. I will write more about this in a separate mail (I 
haven't gotten the time to continue our discussion on the thread with 
subject: grace-timing; I have more to say there).

- [OT] \noBreak seems a bit unlogical to me. It would be nicer with something 
like \startNoBreak and \endNoBreak, i.e. defining on which _intervals_ 
lines / pages shouldn't break. What you mostly want, is to keep e.g. a repeat 
on one line or on one page. For me this is a minor issue (I don't use those 
commands myself), I just observed that things could be done more logical from 
a user's point of view. There have been a few postings on lilypond-user from 
people trying things like \repeat unfold 44 {s1 \noBreak}

- [OT] Handle collision of text markup better (this is a future thing.. i just 
hope that you'll develop the TeX replacements with this in mind.. one thing 
I've been dreaming about is the use of polygonal convex hulls iso rectangular 
bounding boxes, but I understand that this might also be quite a nightmare to 
implement)

- Also, there are some issues about repeats, which however are far from 
urgent. I might post them in a separate mail once I have made my thoughts a 
bit more clear than they are now. Basically, I am thinking about the time 
concept in lilypond; scores do not always have linear time, question is 
whether this in the long run should be solved by extending the time concept, 
or by adding enough hacks to make it work well for 99% of the cases.

> 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.

Wow.. I suppose I count as being part of the dev team, though I'm not actually 
developing any code. Attending to someting like this would be really cool & I 
would like to meet all of you in real life. However I'm not rich and 
travelling costs money, so I'll have to think about this. if I find other 
things to do nearby I might go.

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

I have marked this as 'critical' in the 2.5 branch, using the late-2.3 
convention that critical bugs are those that prevent a stable release.

> 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.

This is really relevant for World Domination IMHO.. just imagine the situation 
when there's not just one text-based program, but 5 different WYSIWYG 
programs, one for each taste, which are Free and produce better output than 
all the non-free ones. This is something for a sellable Lilypond box.

By the way, have you been talking about these plans with the developers of any 
music notation GUIs (NoteEdit, Rosegarden, Denemo, etc?) It might be good for 
those to have this possibility in mind while planning their future 
development. If they are mentally prepared when the possibility comes, they 
might be able to implement it faster.

> * 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."

Conversion between "LilypondXML" and MusicXML might be easier, and as soon as 
the two first points are achieved, there might already exist support for this 
conversion through software such as Rosegarden. Then, by transitivity, we 
will have ly<->MusicXML witout needing to work.


wow... I'm really looking forward to see how lily will develop the following 
few years.. These plans sound really sensible to me; before this I believed 
that World Domination would have to wait until somewhere around lilypond 5 or 
6 in practise, but it looks possible that it could come much sooner.

Erik




reply via email to

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