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
_______________________________________________
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
