Re: anyone notice speed of 2.17.95 on Windows ?
Mike Solomon m...@mikesolomon.org writes: On Dec 15, 2013, at 12:58 AM, Keith OHara k-ohara5...@oco.net wrote: On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon m...@mikesolomon.org wrote: On Dec 14, 2013, at 9:35 AM, David Kastrup d...@gnu.org wrote: Most of the contortions seem focused about when or when not and how to pass begin/end columns. It would seem to make sense to turn them into dynamic parameters *begin* *end* that you can then query with (*begin*) and (*end*). If (*begin*) returns ##f, we can assume being in a pure calculation. That would seem to get rid of most of the current interface complications. I can see the utility of having one function instead of two for these things. The current pure and non-pure functions are often wrappers around a single internal function that has a bool parameter called “pure”, so this would eliminate the need for the wrapper functions. The word 'pure' might have too much a connotation as 'good'. Maybe we should rename 'pure' - ‘shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me' I prefer the second name, Too verbose. raw/final would be shorter than pure/unpure. with the corollary that pure heights and pure anythings are the largest implementation of a basic strategy all over the code base, which is: elaborate several options score them pick the one with the highest score This happens for slurs, beams, ties, and line breaking. In the case of line breaking, the elaboration of the options entails making estimates, which is why we calculate pure heights. -- The most transparent reorganization might be to have all properties that can hold data use the usual callback mechanism: where the callback function is used just once, and the data it returns takes the place of the callback. This is indeed transparent, but given that a single object can return many pure heights based on the begin/end values being used or based on Huh? pure and based on the begin/end values being used seems like a contradiction. how far downstream we are, it’s not clear what this property would look like. For the standard caching, Scheme has futures, stuff that is evaluated when forced and then memoized. What we need here is more like a conditional future, where we memoize based on met or unmet dependencies. The only dependency we currently deal with is post-break, given start and end columns. The layout engine could use get_property_data() freely, but before it has set line-breaks the layout engine would refrain from calling any callback functions directly. Instead of a callback for height', layout functions would look up the grob property tentative-height-estimator' where tentative-*-estimators are always functions that take the start-end columns as parameters. This seems not too far from what we’re doing now, but it adds a lot more properties. I was of the opinion that the tentative estimators (pure) were for the situation _before_ the line breaking. The tentative-height-estimator for something like a Slur or VerticalAxisGroup would return its best guess for the height, while the estimator for a Clef would simply get_property(height) causing its stencil to be formed and leaving the resulting data in the stencil' and 'height' properties for further use. This seems to get the same result we have now while adding a lot of extra properties. Yup. It would seem like we'd need more some nicer construct for providing a number of behaviors in a single callback/property, with caching for each set of _relevant_ preconditions. I like the idea of their being a single property that is honed in on with successive estimates until we get the perfect value. This is how I do a Sudoku - I pencil the guesses in the squares Blasphemy! until I get the actual value and then erase all the estimates and write the good value. Something about using the container (the property) as a holder of the estimates and the final item itself feels sound design-wise. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 15, 2013, at 10:46 AM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: The layout engine could use get_property_data() freely, but before it has set line-breaks the layout engine would refrain from calling any callback functions directly. Instead of a callback for height', layout functions would look up the grob property tentative-height-estimator' where tentative-*-estimators are always functions that take the start-end columns as parameters. This seems not too far from what we’re doing now, but it adds a lot more properties. I was of the opinion that the tentative estimators (pure) were for the situation _before_ the line breaking. This is the case. The tentative-height-estimator for something like a Slur or VerticalAxisGroup would return its best guess for the height, while the estimator for a Clef would simply get_property(height) causing its stencil to be formed and leaving the resulting data in the stencil' and 'height' properties for further use. This seems to get the same result we have now while adding a lot of extra properties. Yup. It would seem like we'd need more some nicer construct for providing a number of behaviors in a single callback/property, with caching for each set of _relevant_ preconditions. Yup. I like the idea of their being a single property that is honed in on with successive estimates until we get the perfect value. This is how I do a Sudoku - I pencil the guesses in the squares Blasphemy! Then LilyPond is a blasphemous piece of software...that has typeset thousands of pieces of liturgical music… Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Mike Solomon m...@mikesolomon.org writes: On Dec 15, 2013, at 10:46 AM, David Kastrup d...@gnu.org wrote: [...] I like the idea of their being a single property that is honed in on with successive estimates until we get the perfect value. This is how I do a Sudoku - I pencil the guesses in the squares Blasphemy! Then LilyPond is a blasphemous piece of software...that has typeset thousands of pieces of liturgical music… It did not desecrate Sudokus with pencils in the process. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
raw/final would be shorter than pure/unpure. I like that. At least for me this is easier to understand from a conceptual point of view. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Blasphemy! Then LilyPond is a blasphemous piece of software...that has typeset thousands of pieces of liturgical music… Well, Moses got his ten commands typeset on stone plates. It probably takes some time until the heavenly software gets updated to use more recent releases. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Werner LEMBERG w...@gnu.org writes: Blasphemy! Then LilyPond is a blasphemous piece of software...that has typeset thousands of pieces of liturgical music… Well, Moses got his ten commands typeset on stone plates. He got only the first version typeset for him. He destroyed them. The second version he had to do himself. Read up on it. It probably takes some time until the heavenly software gets updated to use more recent releases. It was basically right away, and more like a downgrade. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM raw/final would be shorter than pure/unpure. I like that. At least for me this is easier to understand from a conceptual point of view. pencil/ink. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Trevor Daniels t.dani...@treda.co.uk writes: Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM raw/final would be shorter than pure/unpure. I like that. At least for me this is easier to understand from a conceptual point of view. pencil/ink. More like pencil/stencil, and then we get in a conflict of names/concepts. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 15, 2013, at 11:22 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM raw/final would be shorter than pure/unpure. I like that. At least for me this is easier to understand from a conceptual point of view. pencil/ink. All of these are good - the use of “pure” (not sure who started it - maybe Joe?) comes from: http://en.wikipedia.org/wiki/Pure_function 1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices. 2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices. Currently, LilyPond’s pure functions do (2) but not (1). I don’t even think it’s desirable that they do (1), as the approximation can get better over time. (2), however, is very important. (2) would mean we’re inking things elsewhere. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On 2013/12/14 22:32:06, Devon Schudy wrote: This interface is unlike any other in Lilypond, in ways that make it less flexible and may surprise users: * It has two separate files that need to be included in the right places. * It requires the user to use certain specific variable names. * The second include file doesn't just add definitions; it directly produces output. All this is hopefully made clear in the description. You should compare this approach with the existing templates in the Learning Manual. It is an attempt to improve on them by a) clearly separating music from layout; b) requiring no change to the layout part to help newcomers; b) adding flexibility so two templates cover a range of layouts without any layout changes being required. I run a small choir and constantly need to generate, transpose, and reset choral music in 2, 3 or 4 staves, occasionally with descant, both with and without accompaniment. These two templates, so far, have met all my, admittedly rather simple, needs. * The output isn't accessible for the user to modify (by e.g. \transpose). ? If there's library code for SATB, There isn't I'm not sure this is much of an improvement on just writing \ChoralStaff,\lyricsto etc. manually, though. Previously I used to do this, removing a staff context, adding lyrics contexts, adding or removing piano staves etc, as required. This took time and was error-prone. With these templates all that is unnecessary. I find it remarkably effective; my hope was that many other similar users would do so too. https://codereview.appspot.com/41990043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On 2013/12/14 23:17:55, Keith wrote: On 2013/12/14 22:32:06, Devon Schudy wrote: This interface is unlike any other in Lilypond, This was intended not as an interface to a built-in bulletproof engine, but rather a template that users can adopt and change. Exactly, although the flexibility greatly reduces the need to 'adopt and change'. Maybe calling it a 'built-in' template, and its attempt to be as general as feasible, invites misunderstanding of its intended use. Maybe. It's 'built-in' as there is no need to copy and edit the templates, but perhaps a better word to distinguish these templates from the previous ones could be found. Suggestions welcome. Trevor https://codereview.appspot.com/41990043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Am 15.12.2013 06:47, schrieb Graham Percival: On Sat, Dec 14, 2013 at 09:46:54AM +, lilyli...@googlemail.com wrote: On 2013/12/14 03:51:33, Graham Percival wrote: Umm, isn't the whole point of this to be a warning? Why are you removing the warning CSS tag? It's the whole point of this patch to raise this information to the level of regular website text. Why? So that it's not as obvious? No. So that it's obvious on a different level. I imagine two situations in which people download the binary without knowing what they're getting. 1) they didn't notice the existing warning. Solution: change the CSS to make it more prominent. I don't think that a warning is the right approach in that context. Most users will take a warning as a kind of side note, and if it doesn't look crucial (like this may break your system or Works only on Ubuntu 13.10 or later) they may put it aside for later consideration (if at all). Of course this is an opinion I can't prove formally. If you say: It's all there, people should read it or should be forced to read it I can't formally object. Nevertheless I'm convinced that the approach should be modified. 2) they noticed the existing, read the text input page, but were still confused. Solution: improve the text input page. I think the only issue with text input might be that it isn't explicit (or rather suggestive) enough about the editing environment. Was it clear from the discussion on -user which of those problems it was? Not unambiguously clear. But it seems clear that we will have to take into account that people will proceed directly to the Download page without reading anything of the introduction or the Features page at most. From discussion in several quite diversified threads on lilypond-user it became clear that people (i.e. potential new users) have to get a clearer picture of what LilyPond and its infrastructure essentially are. This was the whole idea of starting a website review. Ok. That should be done in the introduction. Maybe more images on the Text input page? No, that page is good IMO. Maybe another whole page about sample usage, or something like that? I think I've already made a suggestion in this regard: Rename Easier editing to Editing and add an introduction there. Text input and Editing environments are two concepts that have to be made explicit independently. I think the text input is explained very well, but the editing aspect is somewhat blurred, one could even perceive it as somewhat bashfully belittled. Maybe this should even be split: One dedicated page explaining the concept of IDEs, similar to the Text Input page but less elaborate, and another page that more or less lists available editors (i.e. the current Easier editing page with some modifications). ... wait a moment, doesn't the Windows download page include screenshots of how to use the lilypond binary? Did people fail to notice those screenshots? Probably they fail to draw the right conclusions from it. I don't think making the Note more visible will help with the fact that people reaching the homepage, then click on Download get the right picture from it. I think a regular box with Before you proceed and the second stopper You just wnat a new version? will be more effective than a warning box. I'm fine with rewording the warning box. Text like before you proceed might be good. However, I'm *not* fine with reproducing a bunch of explanations about how lilypond works. We have a place to explain that: the introduction. Either people aren't finding Text input, or Text input needs work. It was consensus that new users should actively be encouraged to download one of the complete environments, namely Frescobaldi or Denemo, which would then take care of installing LilyPond. Denemo already has LilyPond bundled, and Frescobaldi will/can be made to download and install LilyPond if needed. The Download page *is* the right place for this IMO. And the regular text of that page. ### I think the considerations about chattiness of texts or redundancy of information are suitable and necessary for the docs, but much less for the website. The website doesn't have to be redundancy-free document with every information exactly once and in the right place (which it is far from currently BTW). It should rather be a comfortable place for potential new users who aren't already familiar with LilyPond or text based toolchains in general. If that requires some redundancy or colloquial style then it should have it. One problem with the current website is that it contains too much content which is clearly written from a developer's perspective. I have invested a considerable amount of energy and time to review the site by taking the POV of our target audience. This resulted in a first set of suggestions but there would also have to be considerable follow-up work, for example reworking the Community chapter. I'm
Re: Web: Download: Add introductory text (issue 40510046)
Urs, On 15/12/13 12:23, Urs Liska wrote: I'm worried about the opposition even my first modest suggestions raise. There will be patches with more involved changes to come. And if each tiny bit is discussed to death from exactly the developer's perspective that seems part of the problem, I'll surely consider it an inappropriate use of my time quite soon. You will need to be prepared for this kind of back and forth when doing anything significant with regard to Documentation. I have good experience of this. This is why Graham et al, always recommend to do small incremental changes, see https://codereview.appspot.com/4124056/ This took me 4 months to get consensus. Mainly because I picked this up from another Developer who had also (like I fear you are going to) gave up from 'comment fatigue' but the changes were massive. Just remember it isn't because we don't care what you think or want :) it's because we care _too much_ that some doc edits (and web includes this) takes time and needs discussion. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
tweet or http://lilypond.org/productions.html
Hello, I tried to look back on the old discussions when we set up the Pondings and I am not sure where the tweet/web line should be drawn (if it should be drawn at all). That is the tweet is I assume going to be rather ephemeral whereas the website is going to be around for a while in terms of being search-able. So for example David K added a Ponding recently: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=49eb1b3eab84975c67613986c65f60f731c9818b Which is great but I see no reason why this would not be better served in the 'productions' part of the website. Are there any strong opinions? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
James pkx1...@gmail.com writes: Hello, I tried to look back on the old discussions when we set up the Pondings and I am not sure where the tweet/web line should be drawn (if it should be drawn at all). That is the tweet is I assume going to be rather ephemeral whereas the website is going to be around for a while in terms of being search-able. So for example David K added a Ponding recently: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=49eb1b3eab84975c67613986c65f60f731c9818b Which is great but I see no reason why this would not be better served in the 'productions' part of the website. Basically it was to avoid making a more definite decision. It may well be that it belongs in some of the more permanent sections ultimately. I'm trying not to drop too many balls, so I decided to do at least something. Are there any strong opinions? Well, my strongest opinion is that anything I need not bother with helps me focus on things I am better at. We have some rules due to our being a GNU project: we don't want to advertise non-free software or services based on similar lock-ins. So anything deserves a close look before it is placed in our more permanent sections. Also one should try not having too many dead links... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
Hello, On 15/12/13 13:43, David Kastrup wrote: James pkx1...@gmail.com writes: Hello, I tried to look back on the old discussions when we set up the Pondings and I am not sure where the tweet/web line should be drawn (if it should be drawn at all). That is the tweet is I assume going to be rather ephemeral whereas the website is going to be around for a while in terms of being search-able. So for example David K added a Ponding recently: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=49eb1b3eab84975c67613986c65f60f731c9818b Which is great but I see no reason why this would not be better served in the 'productions' part of the website. Basically it was to avoid making a more definite decision. It may well be that it belongs in some of the more permanent sections ultimately. I'm trying not to drop too many balls, so I decided to do at least something. Well I am starting to go back through this kind of doc/tracker stuff and get back to committing. So you don't have to worry. My only issue with the pondings is it looked like there was some more 'syntax' I had to learn for the xml stuff. I can handle tags but the other special character stuff looked tiresome. Are there any strong opinions? Well, my strongest opinion is that anything I need not bother with helps me focus on things I am better at. Quite. We have some rules due to our being a GNU project: we don't want to advertise non-free software or services based on similar lock-ins. So anything deserves a close look before it is placed in our more permanent sections. Also one should try not having too many dead links... Normally I check all the links each time I visit this page (I did a load of link clear up last time) so that shouldn't be a problem. They will get caught. I guess my own take is it can be on both, but for things 'books' that are really published that other people can get to (possibly many years later) that they are better served long term in the productions section. However I can see now why your commit was made into a Ponding and why Phil suggested it for http://code.google.com/p/lilypond/issues/detail?id=3657 Than productions. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
- Original Message - From: James pkx1...@gmail.com To: Devel lilypond-devel@gnu.org Sent: Sunday, December 15, 2013 1:29 PM Subject: tweet or http://lilypond.org/productions.html Hello, I tried to look back on the old discussions when we set up the Pondings and I am not sure where the tweet/web line should be drawn (if it should be drawn at all). That is the tweet is I assume going to be rather ephemeral whereas the website is going to be around for a while in terms of being search-able. So for example David K added a Ponding recently: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=49eb1b3eab84975c67613986c65f60f731c9818b Which is great but I see no reason why this would not be better served in the 'productions' part of the website. Are there any strong opinions? James Broadly, I think the Pondings are for what are essentially adverts for new or upcoming things. The website is for something we endorse and are proud of. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
- Original Message - From: James pkx1...@gmail.com My only issue with the pondings is it looked like there was some more 'syntax' I had to learn for the xml stuff. I can handle tags but the other special character stuff looked tiresome. I think you have to escape special characters: for example. https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references is a rather more exhaustive list... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
Am 15.12.2013 15:06, schrieb Phil Holmes: My only issue with the pondings is it looked like there was some more 'syntax' I had to learn for the xml stuff. I can handle tags but the other special character stuff looked tiresome. I think you have to escape special characters: for example. https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references is a rather more exhaustive list... There should be tools to do that for you Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Am 15.12.2013 14:14, schrieb James: Urs, On 15/12/13 12:23, Urs Liska wrote: I'm worried about the opposition even my first modest suggestions raise. There will be patches with more involved changes to come. And if each tiny bit is discussed to death from exactly the developer's perspective that seems part of the problem, I'll surely consider it an inappropriate use of my time quite soon. You will need to be prepared for this kind of back and forth when doing anything significant with regard to Documentation. I know that and I'm prepared, but I'm only willing to a certain extent to let this overtake my work and my attitude towards LilyPond. ... Just remember it isn't because we don't care what you think or want :) it's because we care _too much_ that some doc edits (and web includes this) takes time and needs discussion. I know that and I fully agree that it's important to be somewhat strict about what comes into LilyPond or its parts. And I also see that not _each_ of my patches is objected against. But it's actually quite off-putting when you prepare a patch that is more or less based on a broad (and astonishingly productive) discussion on lilypond-user, and then (after two steps of fine-tuning) someone steps out and asks why are you doing this?. (This is not personal against Graham because I know next it might be someone else.) Viewed from the very narrow perspective of the actual patch there isn't much I can argue against People should read Text Input and if they don't we can't help them/we should help them find that page or this kind of stuff should conceptually be dealt with in the Introduction chapter. But actually my work and suggestions should be considered in the context of an overall user experience on lilypond.org, that's why I offered a set of drafts to be read online. From there I was directed to propose small, atomic patches, and now we're in wrangles about details. It's out of proportion given the state some portions of the website are in currently. I don't want to imagine what happens if I propose my rewrite of the Features page (http://www.openlilylib.org/lilyweb/features.html). Urs James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On Sun, Dec 15, 2013 at 4:51 AM, tdanielsmu...@googlemail.com wrote: On 2013/12/14 23:17:55, Keith wrote: On 2013/12/14 22:32:06, Devon Schudy wrote: This interface is unlike any other in Lilypond, This was intended not as an interface to a built-in bulletproof engine, but rather a template that users can adopt and change. Exactly, although the flexibility greatly reduces the need to 'adopt and change'. Maybe calling it a 'built-in' template, and its attempt to be as general as feasible, invites misunderstanding of its intended use. Maybe. It's 'built-in' as there is no need to copy and edit the templates, but perhaps a better word to distinguish these templates from the previous ones could be found. Suggestions welcome. Trevor First question I anticipate from users on this, if we are making a canonical SATB score template in this way: How do I get the altos and sopranos on the same staff, and the tenors and basses on the same staff? For instance, this template doesn't help me at all, since I use the two staves instead of four. I could be wrong, and realize that many use separate staves, but there are also many who don't. Cheers, Carl P. https://codereview.appspot.com/41990043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: splitting file movement and whitespace-only changes into separate commits (issue 42330044)
if requested, I can either update dev/janek/metafont-cleanup or push as a new branch. Please do so! pushed as dev/benko/metafont-cleanup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Urs Liska u...@openlilylib.org writes: I know that and I fully agree that it's important to be somewhat strict about what comes into LilyPond or its parts. Yes and no. One wants to avoid unpleasant surprises. And I also see that not _each_ of my patches is objected against. Well, it's basically one of the most visible parts of LilyPond. And everybody is qualified for an _opinion_ about that. In contrast, bad code often sneaks in and is discovered months later. The web site is basically immediate, is seen by tens of thousands of people, and is translated by all the translators. So it saves a _lot_ of trouble to get it right the first time. But it's actually quite off-putting when you prepare a patch that is more or less based on a broad (and astonishingly productive) discussion on lilypond-user, and then (after two steps of fine-tuning) someone steps out and asks why are you doing this?. (This is not personal against Graham because I know next it might be someone else.) Yes. It is a major part of review processes that a) some people come late into the game b) the preceding discussion on the user list is isolated from the actual patch review process. c) people have different opinions. It is also the nature of electronic communication that every opponent feels more or less like the same person. If one sees a similar objection repeated times, one tends to get annoyed even though it may just be an independent opinion. Viewed from the very narrow perspective of the actual patch there isn't much I can argue against People should read Text Input and if they don't we can't help them/we should help them find that page or this kind of stuff should conceptually be dealt with in the Introduction chapter. It's input. In the end, most of the decisions remain with the people who do the actual work. If you disagree with particular input, there is nothing wrong with saying so. If you find that three people tell you something in a row, then it may be worth figuring out what the underlying reason might be. On the one hand, it may be unfortunate that not everybody reads up on everything before voicing an opinion. On the other hand, this helps a bit with weighing some input. If you need a discussion for three people in a row to see your point, chances are that you would need a discussion to make a user visiting the web site see your point. But you won't get a discussion: they just go away. So just treat it as input. It's easy to fall into the trap of seeing it as a controverse, meaning that people try to defend a standpoint that only became fixed by the want to differentiate oneself from somebody else. It's a trap that I see myself in often. And it has happened a few times that I convinced somebody with compelling arguments that a proposal of his was a bad idea and technically infeasible. Only to implement it half a year later. It's usually in the area of user interface that something like this happens, and a web site is a user interface in some manner. But actually my work and suggestions should be considered in the context of an overall user experience on lilypond.org, that's why I offered a set of drafts to be read online. From there I was directed to propose small, atomic patches, and now we're in wrangles about details. It's out of proportion given the state some portions of the website are in currently. Perhaps. The point is that this state has been there for a while, and all the translation work on it has already been done. Another point is that the mode of operation of LilyPond tends to attracts a breed of perfectionists that can be positively unstandable when occuring in groups. I don't want to imagine what happens if I propose my rewrite of the Features page (http://www.openlilylib.org/lilyweb/features.html). Let me tell you: it's not really that more satisfactory to get no feedback at all. That's what happens with the majority of my patches. It might also be due to people a) trusting my judgment b) not being eager to involve themselves in a discussion with me. You can expect a rather mixed bag of responses overall: sometimes you get more than you ask for, sometimes nothing at all. Getting more feedback often turns out more directly nettling at least to me, but sometimes the perceived annoyance does lead to changed solutions that, if one is honest about it, are an improvement over the original proposal. That's a lot of verbiage: the main point being that people take an active interest in the work you are now doing and which has not been worked on for a while, or worked on with different goals and perspectives and views and strategies, and those goals, perspectives and views and strategies were the result of a lot of thought and discussion. And even if one has to face that this thought and discussion failed to converge to an optimal solution, it's not gone in just a moment, and the intent is not all wrong, but probably just prioritized badly. Rewriting
Re: anyone notice speed of 2.17.95 on Windows ?
Keith OHara wrote:
the pure-estimate and unpure-final versions of a function
[...]
The word 'pure' might have too much a connotation as 'good'. Maybe we
should rename 'pure' -
'shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
Oh, so *that's* what all the 'pure' stuff is about! I was wondering.
The CG says it's just functional purity, but that obviously isn't the
whole story. Renaming them to something like 'estimate' would be less
confusing. ('Raw' is opaque to me, but 'estimate' is clear. Or are
they really ideals instead of estimates?)
Is everything with 'pure' in its name for estimates, or are some of
them just functions that happen to be pure, or that need to be pure
for some other reason?
Unpure-pure-container is also confusing. There's an explanatory
comment at the top of unpure-pure-container.cc, but it's unfinished:
“Used for rerouting a function of (grob start end) to one of (grob)”.
Perhaps it should be named after its purpose rather than its
implementation: something like 'estimator', 'with-estimator',
'estimable', 'two-phase-layout-function'?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Devon Schudy dsch...@gmail.com writes:
Keith OHara wrote:
the pure-estimate and unpure-final versions of a function
[...]
The word 'pure' might have too much a connotation as 'good'. Maybe we
should rename 'pure' -
'shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
Oh, so *that's* what all the 'pure' stuff is about! I was wondering.
The CG says it's just functional purity, but that obviously isn't the
whole story. Renaming them to something like 'estimate' would be less
confusing. ('Raw' is opaque to me, but 'estimate' is clear. Or are
they really ideals instead of estimates?)
Is everything with 'pure' in its name for estimates, or are some of
them just functions that happen to be pure, or that need to be pure
for some other reason?
Unpure-pure-container is also confusing. There's an explanatory
comment at the top of unpure-pure-container.cc, but it's unfinished:
“Used for rerouting a function of (grob start end) to one of (grob)”.
That's just for the special use case where only a single callback is
placed in the container. Then a proxy function is created that throws
the extra arguments away.
Perhaps it should be named after its purpose rather than its
implementation: something like 'estimator', 'with-estimator',
'estimable', 'two-phase-layout-function'?
There were a few proposals already, most of them I like better than
these.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Sat, 14 Dec 2013 23:57:20 -0800, Mike Solomon m...@mikesolomon.org wrote: On Dec 15, 2013, at 12:58 AM, Keith OHara k-ohara5...@oco.net wrote: The most transparent reorganization might be to have all properties that can hold data use the usual callback mechanism: where the callback function is used just once, and the data it returns takes the place of the callback. This is indeed transparent, but given that a single object can return many pure heights based on the begin/end values being used or based on how far downstream we are, it’s not clear what this property would look like. There would be no more 'pure properties' as you use that term. The property 'height' would give the final height. If the object changes height based on layout, 'height' would be a callback. Code that works while layout is tentative would not call callbacks, but could lookup a property 'height-estimator' that links to the pure_height() function. This seems to get the same result we have now while adding a lot of extra properties. Extra properties on those Grobs that use them, in place of the unpure-pure-containers. Reorganization for transparency makes complexity visible. I like the idea of there being a single property that is honed in on with successive estimates until we get the perfect value. But so far, we do not use the previous estimate of a property to inform the next estimate. In fact, with only one slot to hold either the property value or the function to compute it, Grobs keep secret any progress they have made toward a better estimate, and even forget it themselves. Simple properties like 'height' could hold either data or simple callbacks that are executed once, with these callbacks allowed to *pull* information from other grobs and cause their callbacks to execute as well. Separate function-properties like 'height-estimator' could provide estimates when we must avoid forcing other decisions. They could use /data/ in other Grobs' properties, but not callbacks. These function-properties belong to the Grob, so can write the result to its 'height when that estimate is good enough to share. You have wanted to use a preliminary shape for cross-staff slurs to inform layout, for example. The code re-shaping things like Slurs after page-spacing could *push* an improved shape onto the 'stencil' and 'height' properties. Something about using the container (the property) as a holder of the estimates and the final item itself feels sound design-wise. At the moment, the property does not hold any estimates; it holds either the final data or various functions to fetch the data, and some of these functions operate under subtly different rules, both in your unpure-pure-container system and Joe's former system. This subtleties confuse people: issues 3512 and 3482, and the difficulty I had in this thread understanding that the same function was called multiple times to repeatedly build 'vertical-skylines around each letter. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On 2013/12/15 17:41:17, Carl P. wrote: First question I anticipate from users on this, if we are making a canonical SATB score template in this way: How do I get the altos and sopranos on the same staff, and the tenors and basses on the same staff? For instance, this template doesn't help me at all, since I use the two staves instead of four. I could be wrong, and realize that many use separate staves, but there are also many who don't. Good point. The SA-TB template pair puts SA on one staff and TB on another, but in this revision it has only verses between. There is no reason why it should not also have soprano lyrics above, bass lyrics below and alto and tenor lyrics in-between, with each aligning to their respective voices. I'll do that in the next revision. I think then all the major SATB layouts will be incorporated in just two template pairs. Trevor https://codereview.appspot.com/41990043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On Sun, Dec 15, 2013 at 2:40 PM, tdanielsmu...@googlemail.com wrote: Good point. The SA-TB template pair puts SA on one staff and TB on another, but in this revision it has only verses between. There is no reason why it should not also have soprano lyrics above, bass lyrics below and alto and tenor lyrics in-between, with each aligning to their respective voices. I'll do that in the next revision. I think then all the major SATB layouts will be incorporated in just two template pairs. Trevor https://codereview.appspot.com/41990043/ There is that, and I realize after looking at the files again that you did address what I was asking about. But you do bring up a good point. Depending upon whether music is presented as through-composed or in songbook format (with verses), there may be a need for multiple sets of alternate (above or below staff) lyrics. I think I share in what I get to be the general sense of many of the comments that have been made thus far. There is a tradeoff between ease of default use and the customizability. To use a bad and probably over-generalized analogy, we're going from Linux (where you pretty much have to do it yourself, but you can make it do pretty much anything you want) to Mac (where everything is easy IF you are willing to work within the predefined templates, and anything else is almost impossible). We need something in between. I don't know that this is the route to go. If our goal is to get people using LP, I don't think that what we need is a function that hides basic structures from the users, where if they want to go beyond this, they have to move from two include commands to a whole new structure. I think what we need is a stripped-down choral/SATB layout that uses minimal overrides and extra code so that new users can copy-and-paste and start experimenting with. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
Keith wrote:
This was intended not as an interface to a built-in bulletproof engine, but
rather a template that users can adopt and change.
Isn't the template-to-modify use case already covered by the SATB
templates in the Learning Manual and LSR? ISTM using two include files
is harder for a beginner than modifying a template.
tdanielsmu...@googlemail.com wrote:
* The output isn't accessible for the user to modify (by e.g.
\transpose).
?
I often apply music functions like \transpose, \articulate and
\unfoldRepeats to the whole contents of a score, e.g.
\score { \transpose c' g \new ChoralStaff \triplum \duplum \tenor }
\score {
\articulate \unfoldRepeats ...
\midi { \context { \Staff midiInstrument = oboe } }
}
With s-a-t-b.ily, this isn't possible, because the user has no access
to the final music-expression. Putting the music-function before the
\include doesn't work...
\transpose c' g
\include s-a-t-b.ily
...because \score isn't a music expression (and there are definitions
before it).
If there's library code for SATB,
There isn't
By “library code”, I meant the contents of this patch: it adds code to
Lilypond's built-in library of include files.
Previously I used to do this, removing a staff context,
adding lyrics contexts, adding or removing piano staves
etc, as required. This took time and was error-prone.
With these templates all that is unnecessary. I find
it remarkably effective; my hope was that many other
similar users would do so too.
I agree that it's useful to separate the layout from the content, and
SATB is so common that it's worth having built-in support. I just
don't think requiring the user to define certain variable names and
include a file in place of \score is a good interface to it. It's
compatible with your style of writing scores, but not with other
reasonable styles.
I'd rather support the same thing through music functions:
\score {
\satbTwoStaves \soprano \alto \VerseOne \VerseTwo \tenor \bass
\pianoStaff \rh \pianoDynamics \lh
}
...where \satbTwoStaves creates a ChoirStaff and staves and assigns
the music-expressions to them appropriately (keeping lyrics separate),
and \pianoStaff makes a PianoStaff etc. (Piano scores are another very
common thing that's a bit complicated for beginners, so it may be
worth having a convenience for them.)
perhaps a better word to distinguish these templates from
the previous ones could be found.
'Framework'? That's often used for this sort of thing.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the PO files of lilypond (resending)
2013/12/15 Benno Schulenberg coordina...@translationproject.org Hello Francisco and Jean-Charles, On 2013-12-15 16:54, Francisco Vila wrote: This is correct. Translation of PO files (which we use to maintain translations of the binary executable o lilypond -- not the translations of manuals) are managed using the TP, see [...] Yes, I know -- I am one of the coordinators of the TP. :) The point of my email was: from the website of Lilypond it is not clear *that* the translations are managed by the TP. I would have expected somewhere a paragraph explaining this clearly, including a hyperlink to http://translationproject.org/domain/lilypond.html . Could this be added? I agree this is not clearly explained and it should. Translation of lilypond PO files is not coordinated by our team here at lilypond, just it happens a few of PO translators are also documentation translators of the lilypond team. But most of the (very numerous) PO translators who use the FTP are not. An issue open for a documentation editor to write this down would be fine. I'll forward to devel list. Which language do you want to maintain? I don't wish to maintain any language. :) I've just updated the Dutch PO file a bit, and corrected a bunch of language errors in it, but I have no knowledge of music, so I am a bit at a loss there. Here is a field which you can find help among us, if you want, although any musician or amateur can help, too. Jean-Charles, a member of our team is in charge of sending/harvesting PO files to/from the FTP. Ff to him, Jean-Charles, my apologies. When I started updating the Dutch lilypond PO file, I noticed on the Lilypond site that there was a more recent release, 2.17.96, which sounded to me like a release of 2.18 was imminent, so I announced it immediately to the tranlastors at the TP. But I guess I should have waited for your mail. (By the way, it is not necessary to attach a POT file; the URL of the tarball that contains that POT file is enough). I don't know exactly what are you talking about (I seem to have missed a message in between), but anyway feel free to ask for any additional help. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the PO files of lilypond (resending)
Francisco Vila paconet@gmail.com writes: 2013/12/15 Benno Schulenberg coordina...@translationproject.org Jean-Charles, my apologies. When I started updating the Dutch lilypond PO file, I noticed on the Lilypond site that there was a more recent release, 2.17.96, which sounded to me like a release of 2.18 was imminent, so I announced it immediately to the tranlastors at the TP. Hooray, my version number psychology actually works. Yes, it could have been the last version before 2.18. It turns out that it wasn't. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: splitting file movement and whitespace-only changes into separate commits (issue 42330044)
pushed as dev/benko/metafont-cleanup LGTM, thanks! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On 2013/12/15 20:00:24, Carl P. wrote: I don't know that this is the route to go. If our goal is to get people using LP, I don't think that what we need is a function that hides basic structures from the users, where if they want to go beyond this, they have to move from two include commands to a whole new structure. I think what we need is a stripped-down choral/SATB layout that uses minimal overrides and extra code so that new users can copy-and-paste and start experimenting with. I believe the rest of the templates in the Appendix to the LM have been in the form you suggest for at least 6 years. They will remain there for those users who want to learn. But many users don't want to learn; they just want an easy way of producing simple music with as little effort as possible. Why not give it to them as an alternative? Trevor https://codereview.appspot.com/41990043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On 2013/12/15 20:06:56, Devon Schudy wrote:
I'd rather support the same thing through music functions:
\score {
\satbTwoStaves \soprano \alto \VerseOne \VerseTwo \tenor \bass
\pianoStaff \rh \pianoDynamics \lh
}
...where \satbTwoStaves creates a ChoirStaff and staves and assigns
the music-expressions to them appropriately (keeping lyrics separate),
and \pianoStaff makes a PianoStaff etc. (Piano scores are another very
common thing that's a bit complicated for beginners, so it may be
worth having a convenience for them.)
I don't think I'd convince my sceptical pianist friend that
LilyPond is easy to use by saying that's how a vocal score is
produced. The point of this patch is to make LilyPond more
approachable by facilitating the production of quite complex
vocal scores by typing _just_ the music, which _is_ quite easy
to explain, comprehend and do.
Trevor
https://codereview.appspot.com/41990043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: Add comment about git-cl editor (issue 41310043)
uliska wrote: Actually I'm not sure if @var is the right one here? The Texinfo documentation says it should be @code: “Do not use @var for the names of normal variables in computer programs. These are specific names, so @code is correct for them”. https://codereview.appspot.com/41310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Website improvements, part 1
On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote: Am 12.12.2013 04:19, schrieb Graham Percival: ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? If this was aimed at programmers, I'd be tempted to call it Integration or Library, but those would not be clear to 95%+ of people reading the introduction. Hmm... I have a slight preference for applications rather than appliances; as a native speaker, I think appliances as being things like the fridges, ovens, or washing machines. IMO examples should remain part of that. Any more opinions on that? My reasoning was: - I think Features-Background-Freedom and then How LilyPond works is a good reading path - Examples is similar to a Screenshots menu item in many websites and can be somewhat taken out of that intitial reading path Yes and no... I totally agree that Examples is similar to screenshots, but when we're talking about music engraving, the quality of engraving (and flexibility / range of supported notation) is an essential feature. The only reason I didn't put examples and features together was that I wanted to have a tab called examples for additional visibility; some readers might not realize that features included examples if I put them together. I mean, if you're talking about why use lilypond?, then IMO the examples are the most important part. Freedom matters to some people but not others, and IMO the background is almost completely irrelevant. If anything, I think that the web frontends should get their own tab. You mean the box from Editing should be raised to its own page, next to Editing? Yes. The general design of the website is to go top-left, top-right, bottom-left, bottom-right. I'm not certain this is an important distinction, but it's worth considering. OK, I considered it by clicking through the complete website (except the docs of course) and saw that there isn't any single comparable case. Usually when we have two boxes side by side they are followed by a column-center box, so the flow is clear. True. Could we retain the flow in a similar way? Do we need 4 divs, or could we still only have 3? So what to do with it? Semantically it would be less ambiguous to use only one column for the Introduction page. But that wouldn't look nice because the items are so short. I could accept changing this order (i.e. exchange the boxes right-top and bottom-left), but I wouldn't consider it necessary - the ambiguity should be suitable for that page. I'm still not wild about this optional flow. The original pages were aimed at: - info 1. Decided you want lilypond? goto text input. Not decided go next. - info 2. Decided you want lilypond? goto text input. Not decided go next. - info 3. Decided you want lilypond? goto text input. Not decided go next. - info 4. ... etc. The whole goal is to funnel people towards text input so they get the warnings about lilypond. Either people aren't reaching text input, or the warnings on that page aren't sufficiently clear. I think that's a more clear flow than the proposed change. The incentive for reviewing of the website structure was (on lilypond-user) that too many people don't realize the basics of the compiled approach when visiting the website. See other thread for clarifying text input. More involved changes that I could nevertheless put up for review? - Rename Easier Editing to Editing (does this affect translation more than other changes?) Probably, but that's why it's even more important to present that as an independent change. - Updating the Editing page (split in two parts: reorganisation of items / rewording) - Rewrite of the Features page I'd include adding a new page for web apps in the list of small, independent patches that should go forward. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Sun, Dec 15, 2013 at 07:48:28PM +0100, David Kastrup wrote: Urs Liska u...@openlilylib.org writes: But it's actually quite off-putting when you prepare a patch that is more or less based on a broad (and astonishingly productive) discussion on lilypond-user, and then (after two steps of fine-tuning) someone steps out and asks why are you doing this?. (This is not personal against Graham because I know next it might be someone else.) Yes. It is a major part of review processes that a) some people come late into the game b) the preceding discussion on the user list is isolated from the actual patch review process. I want to emphasize these points. The whole review process was put into place to encourage the senior developers to stick around and at least give comments on patches. There's still a ton of design decisions that are only known to the people who originally wrote that code or document. The goal is to allow encourage those people (which I guess include me now) to pass along reasons why they made the decisions they did. If patches were accepted and pushed within a day, the senior devs might not have a chance to reply, and then give up on providing any input at all. Having a patch countdown of 48 hours or more, with no penalty for people coming late to the discussion (provided it's still within 48 hours), is a trade-off of encouraging senior devs to comment vs. encouraging new developers to make lots of changes. Of course, I'm not clamining that the design decisions of previous developers are necessarily correct. Maybe after discussing it with them, the community decides that it's worth breaking the previous architecture plan. But I think that discussion is well worth having. I don't want to imagine what happens if I propose my rewrite of the Features page (http://www.openlilylib.org/lilyweb/features.html). A rewrite of a single page has less impact than changing the intended flow of a new reader through the website. My only problem with your proposed Features page is that it changes the flow (i.e. the where now? box at the bottom). If you changed it back to the original where now? box, I'd have no problem with that new Features page. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Mon, Dec 16, 2013 at 11:29:44AM +0800, Graham Percival wrote: Urs Liska u...@openlilylib.org writes: I don't want to imagine what happens if I propose my rewrite of the Features page (http://www.openlilylib.org/lilyweb/features.html). A rewrite of a single page has less impact than changing the intended flow of a new reader through the website. My only problem with your proposed Features page is that it changes the flow (i.e. the where now? box at the bottom). If you changed it back to the original where now? box, I'd have no problem with that new Features page. Oops, there is one problem with that new Features page. You wrote: Read more on the _Community_ pages. with the link on _Community_. This is not encouraged with texinfo, because that _Community_ link will be hard to read in the pdf version. Instead, please reword the sentence so that the link is at the end of the sentence (as you've done everywhere else on that page). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Website improvements, part 1
Graham Percival gra...@percival-music.ca writes: On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote: Am 12.12.2013 04:19, schrieb Graham Percival: ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? If this was aimed at programmers, I'd be tempted to call it Integration or Library, but those would not be clear to 95%+ of people reading the introduction. Hmm... I have a slight preference for applications rather than appliances; as a native speaker, I think appliances as being things like the fridges, ovens, or washing machines. Well, the proposal was literally applicances which is not a word. I'd lean towards applications. Basically, it seems to be LilyPond as a building block but that's too long for a tab name. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Sun, Dec 15, 2013 at 01:23:51PM +0100, Urs Liska wrote: Am 15.12.2013 06:47, schrieb Graham Percival: 2) they noticed the existing, read the text input page, but were still confused. Solution: improve the text input page. I think the only issue with text input might be that it isn't explicit (or rather suggestive) enough about the editing environment. Then it should be fixed. Was it clear from the discussion on -user which of those problems it was? Not unambiguously clear. But it seems clear that we will have to take into account that people will proceed directly to the Download page without reading anything of the introduction or the Features page at most. Hence the warning. Maybe another whole page about sample usage, or something like that? Maybe this should even be split: One dedicated page explaining the concept of IDEs, similar to the Text Input page but less elaborate, and another page that more or less lists available editors (i.e. the current Easier editing page with some modifications). I like that idea. So there would be 3 pages in Introduction: - lilypond is text input - text input means you write text - list of available editors It was consensus that new users should actively be encouraged to download one of the complete environments, namely Frescobaldi or Denemo, which would then take care of installing LilyPond. Is Frescobaldi available on OSX? It's lacking the appropriate symbol on the easier-editing page. ... apparently it's only available in macports. That isn't something that we should ask most users to try. Denemo is not available on FreeBSD or OSX (accoring to the symbols) so we can't recommend it without deliberately ignoring some users. Granted, anybody using freebsd will already know how things work, but we shouldn't ignore OSX users, particularly since many composers prefer OSX. I think the considerations about chattiness of texts or redundancy of information are suitable and necessary for the docs, but much less for the website. I think that suitable chattiness is even *more* important for the website. Adding text is the easiest thing to do to docs, but can often make users turn off their brains and not read stuff. My rule of thumb is that doubling the text results in half the number of people reading it. The website doesn't have to be redundancy-free document with every information exactly once and in the right place (which it is far from currently BTW). It should rather be a comfortable place for potential new users who aren't already familiar with LilyPond or text based toolchains in general. Right. So let's direct new users to the best explanation we have for how lilypond works. Not a 3-sentence summary of the situation. Direct them to a whole page with images, examples, screenshots, video screencasts, embedded youtube videos, etc. If somebody is unfamiliar with text input, you cannot give a good explanation in 3 sentences that they will understand. You can't, I can't, nobody can. It's a whole different concept. Sure, we could add 3 pages of material to the top of the download page (and presumably the top of the Windows download page as well). But that would annoy experienced users. Solution: use a short notice to get newbies onto a dedicated page for them. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Dec 16, 2013 12:16 AM, Graham Percival gra...@percival-music.ca wrote: On Sun, Dec 15, 2013 at 01:23:51PM +0100, Urs Liska wrote: It was consensus that new users should actively be encouraged to download one of the complete environments, namely Frescobaldi or Denemo, which would then take care of installing LilyPond. Is Frescobaldi available on OSX? It's lacking the appropriate symbol on the easier-editing page. ... apparently it's only available in macports. That isn't something that we should ask most users to try. Denemo is not available on FreeBSD or OSX (accoring to the symbols) so we can't recommend it without deliberately ignoring some users. Granted, anybody using freebsd will already know how things work, but we shouldn't ignore OSX users, particularly since many composers prefer OSX. Just thinking out loud here...would it be worth looking into tweaking the .htaccess file to do OS-based redirection on the download page, like many sites do? That way, if someone requests download.html, they are redirected to download-win.html if the server detects Windows, download-mac.html if it dectects OS X, download-nix.html for *nix, and so on, with download-all.html being the current page (and .htaccess silently redirecting here if there is no OS match). This would allow us to put all the information on one page for an operating system and recommend or not based on what is actually available. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Graham Percival-3 wrote Maybe another whole page about sample usage, or something like that? Maybe this should even be split: One dedicated page explaining the concept of IDEs, similar to the Text Input page but less elaborate, and another page that more or less lists available editors (i.e. the current Easier editing page with some modifications). I like that idea. So there would be 3 pages in Introduction: - lilypond is text input - text input means you write text - list of available editors Continuing in this direction... what if the list of available editors was then put on the download page itself, just below the LilyPond download content? With a header to the effect of Download an Editor to Use with LilyPond, and a brief explanatory text (these are 3rd party... etc.) with links to the text input pages. Or even more radically, on the download page the list of editors could be in the right-hand column, and the LilyPond download content in the left hand column. Either way this would really convey that you need LilyPond and (probably also) an editor. Graham Percival-3 wrote My rule of thumb is that doubling the text results in half the number of people reading it. +1 for keeping the website text concise Graham Percival-3 wrote If somebody is unfamiliar with text input, you cannot give a good explanation in 3 sentences that they will understand. You can't, I can't, nobody can. It's a whole different concept. Here's how I would reword the warning to make it as concrete and simple as possible: Note: With LilyPond you write and edit music by typing text with your keyboard, not by dragging notes around with a mouse. Before downloading, please read about LilyPond's Text input. As compared with the current: Note: LilyPond is a text-based music engraver; it is more similar to a programming language than a graphical score editing program. Before downloading LilyPond, please read about our Text input. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Web-Download-Add-introductory-text-issue-40510046-tp155657p155923.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Paul Morris p...@paulwmorris.com writes: Here's how I would reword the warning to make it as concrete and simple as possible: Note: With LilyPond you write and edit music by typing text with your keyboard, not by dragging notes around with a mouse. It's not just simple, but wrong. The point is exactly that you _don't_ do this with LilyPond, but that you need a different application for that. Before downloading, please read about LilyPond's Text input. Still won't prepare me that LilyPond has no means to write and edit music. As compared with the current: Note: LilyPond is a text-based music engraver; it is more similar to a programming language than a graphical score editing program. Before downloading LilyPond, please read about our Text input. Which is not helping much. It prepares me for an IDE like Visual C++ or, uh, Frescobaldi. Not for a command line application. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Mon, Dec 16, 2013 at 07:53:38AM +0100, David Kastrup wrote: Note: LilyPond is a text-based music engraver; it is more similar to a programming language than a graphical score editing program. Before downloading LilyPond, please read about our Text input. Which is not helping much. It prepares me for an IDE like Visual C++ or, uh, Frescobaldi. Not for a command line application. But surely programming language means edit with vim, compile with make. ;) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
note-spacing: stretch somewhat uniformly; issue 3304 (issue 36830045)
https://codereview.appspot.com/36830045/diff/20001/lily/note-spacing.cc File lily/note-spacing.cc (right): https://codereview.appspot.com/36830045/diff/20001/lily/note-spacing.cc#newcode117 lily/note-spacing.cc:117: ret.set_inverse_stretch_strength (base_space); Looked at it, but I have no idea what any of this stuff means. If you understand this stuff, could you put a comment in lily/include/spring.hh as to what inverse_compress_strength and inverse_stretch_strength are? https://codereview.appspot.com/36830045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
David Kastrup wrote Paul Morris lt; paul@ gt; writes: Here's how I would reword the warning to make it as concrete and simple as possible: Note: With LilyPond you write and edit music by typing text with your keyboard, not by dragging notes around with a mouse. It's not just simple, but wrong. The point is exactly that you _don't_ do this with LilyPond, but that you need a different application for that. Hi David, Ok, yes, I agree that it's important to convey the need for a separate editor application. I was intending With LilyPond... in the broader sense of overall user experience compared with the typical user's GUI expectations. To me that seems like the first thing to get across. Maybe something like Using LilyPond involves writing and editing music by typing... is clearer and meets the requisite standards for accuracy? Of course, if there's a way to concisely and clearly convey both the overall text-editing user experience and the need for a separate editor that would be even better. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Web-Download-Add-introductory-text-issue-40510046-tp155657p155928.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Mon, Dec 16, 2013 at 12:42:16AM -0500, Carl Peterson wrote: Just thinking out loud here...would it be worth looking into tweaking the .htaccess file to do OS-based redirection on the download page, like many sites do? That's possible, but having the unified landing page lets us include the software license, sponsors, and pointers to source code, old downloads, and devel versions. We could add those to all the individual pages, of course, but I don't think it's worth changing that much. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
