jEdit, was Re: battle-plan for 2.5 development
Hi, On Sun, 21 Nov 2004, Anthony W. Youngman wrote: In message [EMAIL PROTECTED], Bertalan Fodor [EMAIL PROTECTED] writes Windows users should use jEdit. Actually, from choice I use PFE (Programmer's File Editor) :-) You can use what you want, of course. But I suggest you try jEdit with lily4jedit some time; there are plenty of useful things in there, and it's getting better by the day. You might find some of the features so useful that you want to use them... Ciao, Dscho ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
In message [EMAIL PROTECTED], Bertalan Fodor [EMAIL PROTECTED] writes We will create a beginner's guide to lilypond that shows the basics of lilypond with lily4jedit. Anyway to sum my opinion: Windows users shouldn't be directed to use your favorite text editor, because they don't have one. Windows users should use jEdit. The appropriate syntax highlighting is default in jEdit. Actually, from choice I use PFE (Programmer's File Editor) :-) Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
On Thursday 18 November 2004 09.10, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: Well, I'd think of an email-based (and for much money also phone-based) support for *users*, i.e people who don't want to be bothered with a compiler, but have to get work done. Ideally the questions would be answered by persons who know lily in her deepest core, and if bigger problems arise, also travel to the customers (for good money, of course!). [..] When it comes to making a boxed lilypond (possibly including some kind of support), it's not at all obvious that the lilypond team must create it. It could just as well be an independent company (like Red Hat) which has OK. Can we stop this discussion? This is about what you and I are going contribute ourselves. Not what an independent company is going to do. The point I'm trying to make, is something like: Given that time is limited, we might not be able to do all things ourselves. Distributing some of the work to other people might be worth considering. There's of course a scale, between doing everything ourselves (in this case boxing,marketing,selling,supporting), and letting someone else do everything, independent of us. The optimum is probably somewhere between the extremes. Management/economy stuff is quite much outside my area of expertise, but I find it reasonable to believe that things like marketing+distribution might be best handled through some existing company. experience of boxing free software. I think it's a good idea to let the lilypond team focus on developing lilypond as a high-quality music engraver; The lilypond team would be very glad if they could do so; unfortunately, the bills have to be paid as well, which means that we have to do other, less-exciting, stuff as well. Of course, it would be the coolest if I could devote 100% of my time to lily, so I'm always interested in ways of earning money for myself with lily. This is very true; in this case it might even be worth considering to make a boxed lilypond. All this talk about selling stuff, just started in my head as a wild idea for far-future/post-3.0. The main motivation was really to reach more users with the software, rather than making money.. but of course the money could be an even better motivation. I got the idea when I told a friend of mine about lilypond, and he told me to tell him when we have finished the program, so he can buy it. Sadly it seems that this is the way many people think about software. Erik ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
[EMAIL PROTECTED] writes: Well, I'd think of an email-based (and for much money also phone-based) support for *users*, i.e people who don't want to be bothered with a compiler, but have to get work done. Ideally the questions would be answered by persons who know lily in her deepest core, and if bigger problems arise, also travel to the customers (for good money, of course!). [..] When it comes to making a boxed lilypond (possibly including some kind of support), it's not at all obvious that the lilypond team must create it. It could just as well be an independent company (like Red Hat) which has OK. Can we stop this discussion? This is about what you and I are going contribute ourselves. Not what an independent company is going to do. experience of boxing free software. I think it's a good idea to let the lilypond team focus on developing lilypond as a high-quality music engraver; The lilypond team would be very glad if they could do so; unfortunately, the bills have to be paid as well, which means that we have to do other, less-exciting, stuff as well. Of course, it would be the coolest if I could devote 100% of my time to lily, so I'm always interested in ways of earning money for myself with lily. (For the record: amount of donations over 2004 so far is about EUR 75. Not exactly a good living.) -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Hi, Undeniably the mass market at the moment would look to be using Windoze as a platform. If we could see an end to dependance on Cygwin, that would (partly) open the door to mass acceptance of Lilypond by the general public. Certainly if, as Erik says it could be boxed up for one-step installation so that the Cygwin layer were packaged up with it, novice users would find it more acceptable. I did try to install Cygwin once in the past just to see what it was like and it was clunky to say the least. Ordinary users just don't want that hassle. A lot of issues raised on the users groups seem to be related to Cygwin and getting it up and running. Seeing Lilypond in the shops in a box would be so cool and would be nice to see some of the revenue returned to assist our friends Han-Wen, Jan et al. Regards, Ralph 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 snip -- [EMAIL PROTECTED] www.tribaldata.co.uk ...or see what I do in my spare time: www.skelmanthorpeband.org -- Man who shoot off mouth... expect to lose face. - Tribal Data Solutions has moved, please visit our website for more details http://www.tribaldata.co.uk. This e-mail and any attachments are confidential and are sent on the basis of our copyright, e-mail and security policy which can be inspected by visiting http://www.tribaldata.co.uk/policies.asp. If you are not the intended recipient, please notify the sender and delete this message. Thank you. --- ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Hi, On Wed, 17 Nov 2004, Ralph Little wrote: Certainly if, as Erik says it could be boxed up for one-step installation so that the Cygwin layer were packaged up with it, novice users would find it more acceptable. There is a way to package cygwin on a CD and preselecting packages by modifying setup.ini. However, this is huge. Fits on a CD, though... I did try to install Cygwin once in the past just to see what it was like and it was clunky to say the least. Ordinary users just don't want that hassle. A lot of issues raised on the users groups seem to be related to Cygwin and getting it up and running. Agree. Seeing Lilypond in the shops in a box would be so cool and would be nice to see some of the revenue returned to assist our friends Han-Wen, Jan et al. Agree. A few remarks regarding Windoze: - if the TeX backend goes away, then it gets a lot easier: the whole TeX system is huge. And maybe at one stage we could even revert to MinGW, which is much lighter on resources. However, AFAIK MinGW lacks some important functions like fork(). - when the TeX backend goes away, it gets harder: I think that the best Lilypond editor on Windoze to date is jedit (shameless plug (TM)). For now it depends on point-and-click! And it would be difficult at best to integrate GNOME support into jedit... - if you want to go for the Windoze market, you absolutely have to make the program fully clickable (again, I would tend to just use lily4jedit, which has a flurry of new features lately). Because jedit is written in java, this is relatively easy (you could even write a note editor in it), and it also runs on other platforms without changes! - the most important feature for professional Windoze users, the killer feature so to say, would be a competent payed-for support. This is what makes the difference between a good open source program and a successful good open source program. Ciao, Dscho ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Ralph Little wrote: Hi, Undeniably the mass market at the moment would look to be using Windoze as a platform. If we could see an end to dependance on Cygwin, that would (partly) open the door to mass acceptance of Lilypond by the general public. Certainly if, as Erik says it could be boxed up for one-step installation so that the Cygwin layer were packaged up with it, novice users would find it more acceptable. I did try to install Cygwin once in the past just to see what it was like and it was clunky to say the least. Really? I've experienced many Windows programs that are much more tricky to install than cygwin. I think that the actual installation is a minor problem compared to the mental steps going from mouse based windows programs to the text based input of LilyPond. Now when you can simply double-click on a file to process it, most windows users will only need to open the cygwin command window when they have upgraded LilyPond and have to run convert-ly. I know that feature requests shouldn't go to this mailing thread, but how about adding an option in the right-click menu to run convert-ly on the file? Ordinary users just don't want that hassle. A lot of issues raised on the users groups seem to be related to Cygwin and getting it up and running. /Mats ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: battle-plan for 2.5 development
Hi, I agree with all of that. When I said that I found Cygwin installation clunky, I actually didn't find it a big problem. Being a programmer, I shouldn't really ;) It just seems to me that any perceived barrier to installation ease should be reduced to encourage more general acceptance of the software. Also, I'm not sure what would be involved with boxing up Lily for easy one-shot installation from a CD. However, I wholeheartedly agree with your assertion that the biggest bridge to cross is the non-mousey nature of the software, which is doubly large for non-techy musicians that have not encountered programming work. This could be tackled by some kind of online interactive tutorial that the user could launch into after installation. I would imagine that the first few minutes of use are crucial in convincing the skeptical user that this is the route they should be taking. What I would think that most users are interested in is: * Speed * Quality of output * Learning curve If we can visibly overcome these perceived issues then I can see mass takeup of this superb software... Another issue for prospective users is the pace of change of Lilypond, especially in terms of the syntax. Even for a user like myself (and many other) that tries to stay up-to-date, the pace of change can be quite breathtaking. I have seen comments from Han-Wen and others regarding the probably stabilisation of the syntax now, which is a good thing for users generally and removes a potential barrier to upgrade. Regards, Ralph -- [EMAIL PROTECTED] www.tribaldata.co.uk ...or see what I do in my spare time: www.skelmanthorpeband.org -- Man who shoot off mouth... expect to lose face. -Original Message- From: Mats Bengtsson [mailto:[EMAIL PROTECTED] Sent: 17 November 2004 13:14 To: Ralph Little Cc: [EMAIL PROTECTED] Subject: Re: battle-plan for 2.5 development Ralph Little wrote: Hi, Undeniably the mass market at the moment would look to be using Windoze as a platform. If we could see an end to dependance on Cygwin, that would (partly) open the door to mass acceptance of Lilypond by the general public. Certainly if, as Erik says it could be boxed up for one-step installation so that the Cygwin layer were packaged up with it, novice users would find it more acceptable. I did try to install Cygwin once in the past just to see what it was like and it was clunky to say the least. Really? I've experienced many Windows programs that are much more tricky to install than cygwin. I think that the actual installation is a minor problem compared to the mental steps going from mouse based windows programs to the text based input of LilyPond. Now when you can simply double-click on a file to process it, most windows users will only need to open the cygwin command window when they have upgraded LilyPond and have to run convert-ly. I know that feature requests shouldn't go to this mailing thread, but how about adding an option in the right-click menu to run convert-ly on the file? Ordinary users just don't want that hassle. A lot of issues raised on the users groups seem to be related to Cygwin and getting it up and running. /Mats - Tribal Data Solutions has moved, please visit our website for more details http://www.tribaldata.co.uk. This e-mail and any attachments are confidential and are sent on the basis of our copyright, e-mail and security policy which can be inspected by visiting http://www.tribaldata.co.uk/policies.asp. If you are not the intended recipient, please notify the sender and delete this message. Thank you. --- ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Hi, On Wed, 17 Nov 2004, Mats Bengtsson wrote: Really? I've experienced many Windows programs that are much more tricky to install than cygwin. Do not underestimate the importance of a friendly dog telling you that the installer needs just a few more informations from you, like date of birth, account number, etc...! I think that the actual installation is a minor problem compared to the mental steps going from mouse based windows programs to the text based input of LilyPond. That's why I would like to have more integration with lily4jedit, like a java alternative to the GNOME backend. Now when you can simply double-click on a file to process it, most windows users will only need to open the cygwin command window when they have upgraded LilyPond and have to run convert-ly. Not even that: in jedit, you just click on the icon (or - in a future version - you are even asked if you would like to convert-ly before lilypond). Ciao, Dscho ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Now when you can simply double-click on a file to process it, most windows users will only need to open the cygwin command window when they have upgraded LilyPond and have to run convert-ly. I know that feature requests shouldn't go to this mailing thread, but how about adding an option in the right-click menu to run convert-ly on the file? I think using this method of working is definitely not the way to use lilypond. It should not be propagated much. I'd better propagate lily4jedit. That's not just because I'm working on it hard to make it the best tool for editing :-), but it solves almost all the problems of beginners: how to set up a score, how to run lilypond, how to run convert-ly, how to view output. (AD begins :-) ) Users only have to install lilypond and jEdit (installing LilyPondTool in jEdit is only three clicks). I think it also significantly reduces the learning curve, because it provides good examples of lilypond code. It is much easier to experiment with tweakings with the automatic code completion, because there is no need to always look at the internal documentation, it also provides an integrated help with full-text search (that searches in user manual, internals and even in lilypond snippets), that is much easier to use than the html or pdf version. There are many structure-related questions on the user mailing list that are automatically solved with the Document Wizard. (AD end) We will create a beginner's guide to lilypond that shows the basics of lilypond with lily4jedit. Anyway to sum my opinion: Windows users shouldn't be directed to use your favorite text editor, because they don't have one. Windows users should use jEdit. The appropriate syntax highlighting is default in jEdit. The LilyPond plugin will be updated in the near future, after then it will know almost everything that other editors know (I think the only thing is not implemented yet is the quick insert mode), and it has many features that no other editor has (tweaking assist, wizards, templates, macros, integrated DVI viewer, very easy extensibility), and much easier to install. Bert ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: battle-plan for 2.5 development
On Wed, 17 Nov 2004, Ralph Little wrote: ... However, I wholeheartedly agree with your assertion that the biggest bridge to cross is the non-mousey nature of the software, which is doubly large for non-techy musicians that have not encountered programming work. This could be tackled by some kind of online interactive tutorial that the user could launch into after installation. ... The generic approach to solve this kind of problem is to build a GUI that uniquely maps to a command line interface for content manipulation. This approach has been followed by *LOTS* of GUIs (just yesterday I looked into a rule-based reasoning software called xclips, which does this kind of approach). For lily, the approach could look like the following: * The application displays a gnome canvas, that shows the music that is currently being edited. * In the GUI, there is also a guile command line window. On application startup, either parse a .ly file and create a scheme expression, or, if no .ly is to be loaded, start with a minimal, but syntactically correct scheme expression that represents an empty score. (In this context, a scheme expression is called syntactically correct if and only if there is an .ly file such that lily's parser would create exactly this scheme expresssion.) * The guile window may be hidden by default (in order not to confuse unexperienced users). In this case, the GUI should provide a menu item that will show up the guile window on request. * Optionally, when parsing a file on startup, file position information (line/column) may be attached to atoms, such that e.g. for each note, there is a line/column pair that refers to the file position (or is lily's cause method already bound to musical atoms in scheme?). * Design and implement commands for editing music structures on scheme level. Commands maybe include add/delete staff/voice starting at [moment], insert note after [position], delete note at [position], add/change [property] of note at [position], or similar. More general editing commands like musical pattern matching/replacing may also be very interesting. Of course, finding a good representation for [position] may turn out to be tricky (Which voice/staff? Which moment?). Designing a sane, complete, but not too complex command line interface for content editing is crucial and probably the most difficult part. * Map each GUI action to a corresponding command on the guile command line. That is, whenever the user takes a GUI action that is intended to change the content, an appropriate command is created, pasted into and executed in the guile window. Analogously to the point-and-click interface, pointing to a note on a gnome canvas should somehow give you a proper [position] value that can be used on the command line. Similar, selection of, say, a staff should give one or more [position] values. A mouse action then should be reducable to an editing command on the command line, using selection and/or mouse position(s) as parameter(s) to the scheme function. * Whenever an editing command on the command line is executed, the musical contents changes, i.e. the gnome canvas may need to be updated. In the very first approach, you would completely execute everything starting with lily's processing stage on the modified scheme content. Howver, this approach will result in poor performance and flickering on the screen. In a more refined version, you may want to think about incremental compiler techniques that take into account that only a small part of the music has been modified (but this is another big project, I guess...). Yes, I know, this all sounds like work for a couple of years. I do not really expect someone to actually implement such a beast (although it would be really cool). ;-) Greetings, Jürgen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
[EMAIL PROTECTED] writes: - the most important feature for professional Windoze users, the killer feature so to say, would be a competent payed-for support. This is what makes the difference between a good open source program and a successful good open source program. Do you have any concrete idea or wish what this support should encompass? Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Hi, On Wed, 17 Nov 2004, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: - the most important feature for professional Windoze users, the killer feature so to say, would be a competent payed-for support. This is what makes the difference between a good open source program and a successful good open source program. Do you have any concrete idea or wish what this support should encompass? Well, I'd think of an email-based (and for much money also phone-based) support for *users*, i.e people who don't want to be bothered with a compiler, but have to get work done. Ideally the questions would be answered by persons who know lily in her deepest core, and if bigger problems arise, also travel to the customers (for good money, of course!). Why do I think that this is a killer feature? In my experience, Windows users just don't expect to be helped. Microsoft's phone support has seen to that. Everytime I work for Windows users (I am part of a small IT company), they seem very surprised that I actually want to help them! I just don't think that you can do that full-time. Not yet anyway. Ciao, Dscho ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Nicolas Sceaux [EMAIL PROTECTED] writes:
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
* 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 }
I'm starting to understand a couple of things about markups, I should
try that.
Cool; don't hesitate to ask questions; do you need a more precise
description than what's written here. I already have some ideas of
how it could be implemented.
Yes, actually a description is welcome! There is a long week end
coming, and thus some time to work on that.
Hello Han-Wen,
Could you explain what is wanted in these markup changes?
nicolas
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
* 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 }
I'm starting to understand a couple of things about markups, I should
try that.
Cool; don't hesitate to ask questions; do you need a more precise
description than what's written here. I already have some ideas of
how it could be implemented.
Yes, actually a description is welcome! There is a long week end
coming, and thus some time to work on that.
Hello Han-Wen,
Could you explain what is wanted in these markup changes?
The target is to change markup syntax, so
can be dropped, and
{ }
represent actual lists, instead of a hack which expands to \line. Most
of the work will be in rewriting the parser syntax, and a little
scheme trickery to rearrange lists of markups.
The idea is
1. to define syntax like
Markup_list:
'{' Markup_list_body '}'
;
Markup_list_body:
/* empty */
| Markup_list_body Markup
;
Markup_head_1_item
MARKUP_HEAD_MARKUP0
| MARKUP_HEAD_SCM0_MARKUP1 embedded_scm
| MARKUP_HEAD_SCM0_SCM1_MARKUP2 embedded_scm embedded_scm
;
Markup_head_1_list:
Markup_head_1_item
| Markup_head_1_list Markup_head_1_item
;
Markup:
markup_head_1_list Markup_list
| MARKUP_HEAD_MARKUP0 Markup
| MARKUP_HEAD_SCM0_MARKUP1 embedded_scm Markup
| ..etc, normal markup syntax follows..
;
2. Perform some trickery to convert
\bold \italic { foo bar }
into
{ \bold \italic foo \bold \italic bar }
i.e. map the Markup_head_1_item over the elements of a list,
3. To implicitly add
\line
to a \markup { } definition.
4. In the end,
\markup { \bold \italic { foo bar } }
would be internally converted to
\line { \bold \italic foo \bold \italic bar }
This makes it possible to drop and from the markup syntax.
5. If possible, it would be nice to flatten lists internally as well,
so
\markup { \column { foo bar \bold { baz bla } }
gets translated to
\column { \bold foo \bold bar \bold baz \bold bla }
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
On Wednesday 17 November 2004 21.10, Johannes Schindelin wrote: Hi, On Wed, 17 Nov 2004, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: - the most important feature for professional Windoze users, the killer feature so to say, would be a competent payed-for support. This is what makes the difference between a good open source program and a successful good open source program. Do you have any concrete idea or wish what this support should encompass? Well, I'd think of an email-based (and for much money also phone-based) support for *users*, i.e people who don't want to be bothered with a compiler, but have to get work done. Ideally the questions would be answered by persons who know lily in her deepest core, and if bigger problems arise, also travel to the customers (for good money, of course!). There exists a lilypond-user mailing list. I believe it gives a lot better support than you can buy for a reasonable amount of money (much thanks to Mats Bengtsson). When it comes to making a boxed lilypond (possibly including some kind of support), it's not at all obvious that the lilypond team must create it. It could just as well be an independent company (like Red Hat) which has experience of boxing free software. I think it's a good idea to let the lilypond team focus on developing lilypond as a high-quality music engraver; stuff that can be taken care of by others should be taken care of by others. Erik ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
On Wednesday 17 November 2004 18.02, Juergen Reuter wrote: ... * Whenever an editing command on the command line is executed, the musical contents changes, i.e. the gnome canvas may need to be updated. In the very first approach, you would completely execute everything starting with lily's processing stage on the modified scheme content. Howver, this approach will result in poor performance and flickering on the screen. In a more refined version, you may want to think about incremental compiler techniques that take into account that only a small part of the music has been modified (but this is another big project, I guess...). Yes, I know, this all sounds like work for a couple of years. I do not really expect someone to actually implement such a beast (although it would be really cool). ;-) To me, what makes Han-Wen's plans on World Domination sound quite achievable, is that if the native output mode is written generic enough, it would be possible to create a 'liblilypond'. Existing GPLed music notation programs could use this for their output to the screen. This way, lilypond would not grow to a beast; main focus could still remain on beautiful music typesetting, there would only have to be a lib interface as opposed to a builtin GUI. I can imagine that in a program like rosegarden, the implementation could be that when you create a new note, this is first placed on the screen by some simple fast drawing routine, without the use of lilypond, and then there could exists a button somewhere to do a complete redraw (i.e. re-align everything). But that's just a guess. Erik ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
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
Re: battle-plan for 2.5 development
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. I'll send it to you privately. This is something we should discuss... Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
example, it would be interesting to have a case-study of advanced
LilyPond use.
I have some examples of advanced LilyPond use here.
Also enough material for a real case study?
(Actually, I was trying to provoke Werner, who has given our cool
cue-note code a real stress test :-)
oh ok, I misunderstood. My stuff is mostly about user defined music
functions (the greatest invention ever :). [Digression. I am currently
upgrading Giulio Cesare to lily 2.4; they are *very* useful in large
scores with repetitive patterns. The \tag thing happens to be really
cool too, as I discovered.]
* 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 }
I'm starting to understand a couple of things about markups, I should
try that.
Cool; don't hesitate to ask questions; do you need a more precise
description than what's written here. I already have some ideas of
how it could be implemented.
Yes, actually a description is welcome! There is a long week end
coming, and thus some time to work on that.
nicolas
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
In message [EMAIL PROTECTED], Graham Percival [EMAIL PROTECTED] writes On 5-Nov-04, at 4:49 AM, Han-Wen Nienhuys wrote: 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. What's wrong with the mailing lists? They provide instant feedback on releases, documentation, comments, etc. If somebody wants to commit and article but doesn't want to code the HTML himself (and doesn't want to use an editor - HTML creator like OpenOffice), then I'll volunteer to edit their plaintext article into HTML. While it's nice to have BOTH email AND a good website, taking an either/or approach will disenfranchise a lot of users. For example, a mailing list I'm on recently rehosted. Because my mail server is behind a NAT firewall, the mail-list server refuses to talk to it and I can no longer post. The result is, I've just dropped off the radar because although there is also a website, I almost never go there. (Not many other people do, either, I don't think.) A working email list is a damn sight better than a web forum, imnsho. Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
[EMAIL PROTECTED] writes:
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
GNOME BACKEND FOR POINT AND CLICK
I would like to help on this (xDVI always crashes here, I don't have
point and click working, besides with gnome backend).
Cool! I think it's the most exciting thing currently on the list, so I
can't wait to get my hands dirty...
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.
I have some examples of advanced LilyPond use here.
Also enough material for a real case study?
(Actually, I was trying to provoke Werner, who has given our cool
cue-note code a real stress test :-)
* 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 }
I'm starting to understand a couple of things about markups, I should
try that.
Cool; don't hesitate to ask questions; do you need a more precise
description than what's written here. I already have some ideas of
how it could be implemented.
PS. The community web site idea is good, there lack a place for posting
articles.
Yes- probably this is even more important than getting gnome and
encoding support up and working. The better our community works, the
more people we can attract to help with Lily development.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
On 5-Nov-04, at 4:49 AM, Han-Wen Nienhuys wrote: 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. What's wrong with the mailing lists? They provide instant feedback on releases, documentation, comments, etc. If somebody wants to commit and article but doesn't want to code the HTML himself (and doesn't want to use an editor - HTML creator like OpenOffice), then I'll volunteer to edit their plaintext article into HTML. Changing lilypond.org into a more dynamic format seems like it would involve a lot of work with small payback. Now, if somebody _wants_ to do all that work, of course I'm not going to disagree with it. But I'm not certain if it's actually worth it. 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. I can't attend, but I'm available for any writing / editing if you want. CLEANUPS * Cleaning out input/test/ Doing what with them? Integrating the interesting tweaks into the manual, or a separate page of interesting tweaks? Or simply getting rid of uninteresting tweaks in input/test ? I could have a look at this part. POST-3.0 * 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. * 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. IMHO, if we're going to implement import/export in some kind of XML format, we might as well do it in MusicXML, rather than inventing our own XML format. (note that I have no knowledge of the details of MusicXML) DOCUMENTATION I propose that we make a distinction between reference documentation (for skilled users who want to look up something they've forgotten) and new users documentation. If other people agree to this, then I'll focus on improving / adding to the new users documentation. The new users documentation would be written in a chattier, less formal style. I'm planning on the following steps: 1) Make sure everything in the new users section is included in the reference docs 2) Separate the current tutorial into a basic tutorial, instrument-specific tutorial, and advanced tutorial. Add sections as appropriate. 3) Check the overall organization of the reference manual / lilypond-book manual / etc. 4) Respond to questions / complaints / comments about the docs; mainly being a user-friendly interface to contributing to the docs. (ie user says shouldn't section foo contain a warning about bar; I'll add the warning. Or a different user says I don't understand how to foo, and Mats replies with a great explanation of foo-ing; I'll take that explanation, add whatever texinfo tags it needs, and include it in the relevant section) Any new material and reorganizations would occur in Dec and Jan. Cheers, - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
GNOME BACKEND FOR POINT AND CLICK
I would like to help on this (xDVI always crashes here, I don't have
point and click working, besides with gnome backend).
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.
I have some examples of advanced LilyPond use here.
CLEANUPS
* 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 }
I'm starting to understand a couple of things about markups, I should
try that.
nicolas
PS. The community web site idea is good, there lack a place for posting
articles.
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
On Fri, 2004-11-05 at 05:49, Han-Wen Nienhuys wrote: 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 hope to be able to develop a fret-diagrams context, and fully integrate it into regular operation. I also hope to be able to add some of the features requested for Classical guitar requested in http://lists.gnu.org/archive/html/lilypond-devel/2004-10/msg00140.html As part of all this, I may be able to contribute to the programming concepts (or internals reference ) manual. Carl Sorensen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
