Urs Liska <u...@openlilylib.org> writes: >> This becomes particularly important when it comes to tweaking >> output. He wrote (my translation): "My first look at LilyPond [through >> my presentation and a follow-up email] shows similarities to Amadeus, >> but OTOH I have the suspicion that the operation isn't sufficiently >> mature to allow economic ans fast work. I think, you just have to >> input too much information to get an optimal result." But he's also >> arguing at the level of actually entered number of characters. >> >> >> That's something better addressed by input tools rather than the >> language. Emacs would be a good building block if you are used to >> UNIX-like systems (and if you ported some large application for generic >> UNIX to GNU/Linux, you probably have a bit of exposure here). It's been >> a long time since I looked at what lyqi, the "LilyPond quick input" mode >> by, uh, Nicolas Sceaux?, did. > > Partly yes. When it comes to creating the input text for tweaks I > agree that editing tools can do a lot to improve things. But when you > have the strong opinion that typing "f" is an improvement over typing > "fis" there's not much editing tools can do for you.
Huh? The editing tools can, of course, be made to insert "fis" into your text when you are typing f. >> I have the impression that LilyPond always needs twice or three times >> the characters for the same content. That's offputting ..." >> >> >> Introduce him to MusiXTeX. > > That's not the point. He's (rightly) only interested in the comparison > to Amadeus. That _is_ for the comparison to Amadeus. MusiXTeX is output-oriented and has a concise but totally cryptic input language. >> While I still think that explicit pitches are better for a number of >> reasons this _is_ the way someone thinks who has to produce >> 1.500-2.000 pages of high-quality scores per year. For him each >> additional character makes a difference. >> >> >> Input tool problem. > > I don't think so. > Take the "ho" example, which is shorter than "\stemUp". > You can define a wrapper and write "\ho", which is still longer than > "ho". The only thing to come to par with the two characters would be a > keyboard shortcut. But of course it's not a good idea to create > shortcuts for all of these commands. That would be way over the top. Why? That's what Emacs abbrevs are for, for example. > I think he is right in saying that with LilyPond you need more typing > than with Amadeus. You need more screen and file estate. But the typing is a matter of the input tool. LilyPond only provides a _language_, not an application. > But I think that's not the real point. I think it's a tradeoff between > number of characters to type, clarity and verbosity. Clarity and verbosity are a feature of the language, numbers of characters to type of the input tool. They are the same only when using a plain text editor without LilyPond-specific support. >> Much of the internals of LilyPond are inefficient, and the glue layers >> and data structures of Scheme also come at a cost (and using >> GUILEv1, >> not exactly renowned to be an efficient Scheme implementation, also >> plays into that). But Scheme is also giving us building blocks for >> solving a lot of stuff without recompilation. > > OK, that may well be. But in effect it's a usability issue that > shouldn't be underestimated. near-realtime WYSIWIG is an important > factor, particularly when you have to tweak things iteratively by > trial-and-error. Against Finale users we can always say that the > compiled approach has inherent advantages that are worth the waiting > time. But in this case that doesn't count. If it does not even count, you want a visual workflow. LilyPond is not tailored for that. It does not sound like Amadeus is, either, but its performance makes it easier to gloss over that. >> In the current environment? I don't think all that much. The important >> thing remains the creative process, and that does not (or should not) >> involve running LilyPond. > > I don't understand what you mean. You mean the creative process of > preparing the content of a score takes more time than compiling the > LilyPond file? > We're talking about producing an average of ~10 publication quality > pages per working day, and for this it does make a difference if you > have to wait 0.2 or 12 seconds to get visual feedback for your > editing. That's about one page every 50 minutes. 12 seconds are not much for that as long as the tools don't require you to recompile for doing every trivial little correction. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
