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
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 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
[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
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
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
[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
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
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
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
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
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, 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
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 > -- [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
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. > COMM
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
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
> > > 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
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
[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
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
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > 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. that's really great. I can't tell how happy I'm to hear that. About the website, I'd probably go with plone. I'm by no means a web guru but I have some (not very pleasant) experience with PHP driven sites in the past. Besides, plone is written in and extensible in python, one of the languages of choice in LilyPond development. Things I want to do: I want to help with the gnome backend. I have some gui programming experience (delphi in another life, tcl/tk in the past, and gtk+python recently). I already started to hack the files and will post questions/suggestions/code soon. I'm writing an article showing off lilypond. The idea is to show cool things that are easy to do with lilypond and not so easy (or even very difficult) with GUI programs like finale and such. I'm planning to submit it to linux journal but I'll post it on lilypond-hackers first. Last but not least I'd like to contribute with more code and implement more features than the short hacks I've been doing. Pedro ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: battle-plan for 2.5 development
Hi, some general comments: On Fri, 5 Nov 2004, Han-Wen Nienhuys wrote: > ... > > 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. > The web page for the upcoming meeting (21-24 April 2005) is at http://www.zkm.de/lac/ and the page of the previous meeting is still available at: http://www.zkm.de/lad/ The LAD people have further material (slides, papers, fotos, etc.): http://www.linuxdj.com/audio/lad/eventszkm2003.php3 http://www.linuxdj.com/audio/lad/eventszkm2004.php3 The past two meetings, strictly speaking you did not need to write a paper to attend and also did not have to pay a fee for attendance. However, the meeting seems getting more and more professional with respect to the quality of the papers and presentations, and therefore I expect that sooner or later there will be a formal registration process. By the way, I am planning to submit a paper (not about lily, but on image-to-audio transformation), i.e. I will very likely participate! > * 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. Maybe this could also solve some of the convert-ly problems. At least, applying XSL transformations sounds to me much more sound than simple character replacement based on regular expressions. > 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. As usual, I am running too many projects at the same time... I probably will not be able to create major contributions before March. However, as a (hopefully) rather small project, I am going to introduce high-level ligature macros (roughly following the informal code fragment table at the end of section 5.16.10.2 in the user manual). The high-level syntax will look very close to what MusixTeX and OpusTeX do; however, the implementation will map to the current, much more flexible, low-level language, while MusixTeX and OpusTeX use a simple hard-coded mapping from high-level syntax to metafont glyphs. The idea of having an additional low-level language (as currently implemented in lily) is to abstract from a particular notation style (such as vaticana versus hufnagel), such that conversion between them becomes trivial for the user (i.e. just plugging in different backends for the same input syntax by selecting a particular ligature-engraver). Greetings, Jürgen ___ 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
battle-plan for 2.5 development
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 wan