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: LilyPond C/C++ #include cleanup
Andreas Scherer writes: Has anyone considered to apply Doxygen to the LilyPond sources? See these threads http://lists.gnu.org/archive/html/lilypond-devel/2004-03/msg00226.html http://lists.gnu.org/archive/html/lilypond-devel/2004-04/msg00083.html there were some good intentions, but not much has happened. I'm aware that the internal comments are not doxygen'erated, however, Doxygen is capable to analyze plain C/C++ codes and to generate at least rudimentary documentation in various output formats. As Han-Wen said, a docstring mechanism would be preferrable, but doxygen doc is better than nothing -- if it can offer some basic quality. Now, when I click through the HTML documentation and look at the images of the include graphs, I find that many #include directives are redundant, Thanks for looking into this. If there is interest in this group for such an improvement of the C/C++ sources of LilyPond, I would volunteer to make the necessary modifications, i.e., to remove the superfluous #include directives, while guaranteeing the correct compilability of the system. Any comments? That would be great. Make sure to use latest CVS and send unified diffs, (cvs diff -u). Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond C/C++ #include cleanup
Jan Nieuwenhuizen writes: there were some good intentions, but not much has happened. Apart from Carl Sorensen, who started a programming concepts document http://lists.gnu.org/archive/html/lilypond-devel/2004-10/msg00241.html which is not the same thing, but it's related. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ 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
lilypond-book manual updated
The file lilypond-book.itely is now up to date. Werner ___ 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
