Re: linux distro recommendations?
On 08.05.2009 (09:56), Jonathan Kulp wrote: > Does this mean that, for instance, Debian's repo will have more > up-to-date versions of things like texi2html and fontforge? I've had > problems with outdated versions of certain packages on Ubuntu. I've used > Ubuntu for 18+ months now, and it was my first Linux distro. It was a > good way to get started because in general things just work. I'm much > more advanced now and am considering something like Arch or Debian. I > wiped my Windows partition yesterday (now I can't test any Lilypond > issues on Windows anymore...) to install xubuntu 9.04 and see if it's > ready to use as my main system yet, but I might turn right around and try > Debian on that partition. I've been curious about it for a while. > > BTW I hear that Linux Mint (an Ubuntu derivative) is even more > noob-friendly b/c it contains all the proprietary drivers and media > codecs already and you don't have to go hunting around for them. Grab > the (indecent) Live CD and give it a spin. ;) My turn here. If up-to-date-ness is an issue, I'd like to suggest Arch linux, which has been my loyal companion for four years, which is my whole linux life minus two weeks. Now, Arch has a reputation for being the geeks' distro, up there with gentoo and slackware, and VERY difficult and best to stay away from if you're a noob. Well, I certainly was a noob (I had used another debian-derivative for a few weeks first), but unless you're scared of the command-line and text config files (which you're probably not if you're using lilypond), there really is no problem, and Arch is ideal as a way to learn the insides of linux, for two reasons: (1) it's based on the KISS principle (Keep it simple, s...id): everything you need in terms of system configuration is there in sane text files, and (2) the community is very qualified and friendly (I cringe everytime I stumble into a ubuntu forum). Add to that the close-to-the-bleeding-edge policy (i.e. bleeding edge is in "testing", while the stable repo is closer to the bleeding that in most distros), and the rolling-release system (which means that your system is always up-to-date - no need for reinstallation with every major release), and the best package manager around, which makes it shamelessly simple to build new packages, should the one you need not be in the official repos, and the only thing that would keep anyone away from arch is if they're scared of the commandline or has some religious affiliation to some other distro. :) Seriously, though, I've had some issues over the years with packages which hadn't spent quite as long as they should have in testing, but on the whole it has been rock solid, and I've learned a lot. Eyolf -- Yes, I've now got this nice little apartment in New York, one of those L-shaped ones. Unfortunately, it's a lower case l. -- Rita Rudner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distribution updates and documentation woes
On 15.01.2009 (16:43), Jan Nieuwenhuizen wrote: > Hi, > > After 2.12 I decided to do my small round checking of distributions > again (should we add something like this to release tasks?). > > Fedora already has 2.12 (yay!), while Debian and Ubuntu already had 2.12 > wishlist bugs filed (great!), but none of the major distributions > manages to provide proper images in the Info docs. Time for action! > Arch has 2.12.0 in community and both 2.12.1 and the latest git in ABS. Re. the doc woes, the Arch is to discard any documentation other than man pages, so problem solved :) Eyolf -- "Arthur yawed wildly as his skin tried to jump one way and his skeleton the other, whilst his brain tried to work out which of his ears it most wanted to crawl out of. `Bet you weren't expecting to see me again,' said the monster, which Arthur couldn't help thinking was a strange remark for it to make, seeing as he had never met the creature before. He could tell that he hadn't met the creature before from the simple fact that he was able to sleep at nights." - Arthur discovering who had diverted him from going to a party. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ideas for Google Summer of Code
I don't know if this is a pie in the sky, but the gregorian notation system could use a caring hand, especially the spacing stuff. Eyolf On 15.01.2009 (13:45), Han-Wen Nienhuys wrote: > Other pie-in-the sky: completely redo the part-combiner, using the > music streams infrastructure. > > (unfortunately, no I don't have time to mentor.) > > > On Thu, Jan 15, 2009 at 12:32 PM, Jonathan Kulp > wrote: > > Anne Ghisla wrote: > >> > >> Hello all, > >> > >> On Wednesday 14 January 2009 18:58:25 Johannes Schindelin wrote: > >>> > >>> On Wed, 14 Jan 2009, Carl D. Sorensen wrote: > > On 1/14/09 8:51 AM, "Han-Wen Nienhuys" wrote: > > > > I think we can be under the umbrella of FSF/GNU. > > Can the mentor be a FSF/GNU mentor, or does there need to be a LilyPond > mentor? > >>> > >>> The mentor can be anyone that is accepted by the project. GSoC is mostly > >>> a "we know who you are and therefore we trust you" thing. Even if these > >>> things become rare these days, it is the only way to run something > >>> successful _and_ fun. > >> > >> fisrt of all: many thanks for your answers, the proposals look great. > >> > >> If it is possible to be under FSF/GNU umbrella, it could give us better > >> chances for project approval - organisators have already warned future > >> participants that 2009 edition will cont on a reduced budget. > >> > >> But it worths trying! I'll do my best to become a Frog and start > >> understanding how LilyPond works. > >> regards, > >> > >> Anne > >> > > > > Pie-in-the-sky idea for summer of code: create working lilypond-to-musicXML > > conversion tool. At least two of us have also placed a bounty on this :). > > > > Jon > > -- > > Jonathan Kulp > > http://www.jonathankulp.com > > > > > > ___ > > lilypond-devel mailing list > > lilypond-devel@gnu.org > > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > > > > > -- > Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- MARRIAGE is the only WAR where you sleep with the ENEMY. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Beating everything in terms of speed (was: barCheckNumber to endSpanners)
On 12.01.2009 (15:18), Reinhold Kainhofer wrote: > I use Alt+F2, typing "kai" + Return (auto-completes to > kainhofer.com/~lilypond) in KDE's runner ;-) Beats everything in terms of > speed. Not really; with a QuickMark in vimperator/firefox, I type "gol" (or "gnl" to open it in a new tab). THAT, I think, beats everything (unless you set it as your home page). eyolf -- Ted Turner Unveils All-Commercial Channel For years, the pundits have predicted that the Web would become more like television. However, media tycoon Ted Turner is pursuing the exact opposite. Taking a cue from pop-under advertisements, Flash ads, get-rich-quick spam emails, viral marketing, and "Gator" programs, Turner has unveiled "TCC", the Turner Commercial Channel, for cable TV. TCC will feature "shows" like "Best Commercials That You've Seen A Million Times", "Life Is A Slogan, Just Buy It", and "Name That Jingle". These shows will occupy about 30% of the screen, while several rows of marquees at the bottom will flash various advertising messages. An animated "TCC" watermark will float around the screen while corporate logos are flashed randomly in the corners. Meanwhile, "pop-up ads" will randomly appear that obscure the other ads. These pop-ups will sometimes be further obscured by meta-pop-ups. Likewise, corporate jingles will play in the background, interfering with other jingles and advertising sounds. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Mensural style
On 28.12.2008 (13:05), Trevor Daniels wrote: > At present the MensuralVoice context sets the NoteHead style to 'petrucci, > but does not set the style for rests. I know nothing of ancient music, > but it seems to me that rests should be set to 'mensural style? Advice > please, from anyone who understands ancient music. Yes, that would be good. Another thing that's worth considering, is what to do with the accidentals: one thing is which accidental style to choose for each general style, but there also ought to be an option to use the sharp sign for naturals/cancellations, as was customary. Eyolf -- [Norm goes into the bar at Vic's Bowl-A-Rama.] Off-screen crowd: Norm! Sam: How the hell do they know him here? Cliff: He's got a life, you know. -- Cheers, From Beer to Eternity Woody: What can I do for you, Mr. Peterson? Norm: Elope with my wife. -- Cheers, The Triangle Woody: How's life, Mr. Peterson? Norm: Oh, I'm waiting for the movie. -- Cheers, Take My Shirt... Please? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP pre-planning: Frog bugfixing
On 11.12.2008 (22:00), Valentin Villenave wrote: > Both sides are equally important, because it's the feature count that > makes users *and devs* stick with Lily. I don't know about the devs -- you're probably right that to them, new features are more interesting -- but THIS user sticks with LilyPond because the output is superb. As it is, LP deals with 99% of the western music notation canon, and to me, the perfectioning of that is far more important than filling in the remaining %. Also, a higher priority for me would be to simplify input for the 30% which go beyond simple music expressions and where scheme or fiddling with grob properties are required. For the academic world, I've suggested a five-year enforced writer's block, to give us all a chance to catch up. Something similar for LP would mean: no more features until the buglist is empty :) Eyolf -- rib site n. [by analogy with backbone site] A machine that has an on-demand high-speed link to a backbone site and serves as a regional distribution point for lots of third-party traffic in email and Usenet news. Compare leaf site, backbone site. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Getting help web page
On 02.12.2008 (17:01), Jonathan Kulp wrote: > Mats Bengtsson wrote: >> A couple of minor comments: >> >> - At the main page, I would expect to quickly find my way to a page like >> your Getting Help, if I looked below the title "Dive into ... the >> LilyPond" and followed the link to "More about LilyPond". >> > > I agree. It'd be nice for the "Getting Help" link to be more prominent. I suggest a "Help" as the rightmost item in the top bar of links. That's where poeple would be looking for it. Other than that: good. One comment only: The sentence: "(And until version 2.12 is released, users of either version 2.10 or 2.11 should use the Learning Manual from version 2.11)." -- that's confusing enough to require a separate help page... I assume those users should use the LM even after 2.12 is released, so how about sth like: "It is written for the latest stable release candidate (soon to be released as version 2.12), but the explanation of the general principles of Lilypond applies to earlier versions as well." or something like that Eyolf > Once there, though, the getting help page is very good. This would > definitely help newbies understand how LP works. > > Jon > -- > Jonathan Kulp > http://www.jonathankulp.com > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Space tells matter how to move and matter tells space how to curve. -- Wheeler ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs should include --define options; ly:set-option explanation
On 12.11.2008 (05:14), Graham Percival wrote: > On Tue, Nov 11, 2008 at 11:12:11PM -0800, Mark Polesky wrote: > > Currently, "a few interesting options" are listed > > with a mention of -dhelp to show the rest. Why not > > list them all? > > Because they change relatively often and are advanced options > anyway. People who should be using -dsomething can run -dhelp to > find them. Couldn't the output of -dhelp be included there? I understand the concern with frequent changes, but an automatic output should avoid any such concerns, and serve the advanced user (who may of course run the command himself, but having it in the docs (a) makes it searchable, and (b) makes the docs more complete). Eyolf -- Whoever tells a lie cannot be pure in heart -- and only the pure in heart can make a good soup. -- Ludwig Van Beethoven ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.8 Ancient music ready for review
On 02.11.2008 (22:15), Till Rettig wrote: > Trevor Daniels schrieb: >> Eyolf >> >> More comments on Ancient now seem unlikely. T > Oops, I totally forgot about it. I would like to review this, but I am > not really fast at the moment. I might just start next week, or would it > be better to wait for the next version? No, just go ahead -- I won't have time to do anything about it right at the moment. e > > Greetings > Till > -- It's illegal in Wilbur, Washington, to ride an ugly horse. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc main page: too many parentheses
On 25.10.2008 (23:06), Francisco Vila wrote: > It's me, or aren't there too many adjacent parenthesized phrases in > the Doc main page? Now that you mention it: yes. Another thing on that page: is the music glossary really only for non-English users? I think not. Eyolf -- Speaking of Godzilla and other things that convey horror: With a purposeful grimace and a Mongo-like flair He throws the spinning disk drives in the air! And he picks up a Vax and he throws it back down As he wades through the lab making terrible sounds! Helpless users with projects due Scream "My God!" as he stomps on the tape drives, too! Oh, no! He says Unix runs too slow! Go, go, DECzilla! Oh, yes! He's gonna bring up VMS! Go, go, DECzilla!" * VMS is a trademark of Digital Equipment Corporation. * DECzilla is a trademark of Hollow Chocolate Bunnies of Death, Inc. -- Curtis Jackson ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Vocal music
On 13.10.2008 (09:06), Trevor Daniels wrote: > Valentin, you wrote Sunday, October 12, 2008 12:38 PM > >> 2008/10/3 Trevor Daniels <[EMAIL PROTECTED]>: >> >>> This is good. I'm very happy with this. >> >> Greetings Trevor, >> >> I have pushed a new reordering for 2.1 "Vocal music"; please tell me >> what you think about it. > > I don't like it. Is Trevor beginning to sound like Graham...? :) e -- Muad'Dib tells us in "A Time of Reflection" that his first collisions with Arrakeen necessities were the true beginnings of his education. He learned then how to pole the sand for its weather, learned the language of the wind's needles stinging his skin, learned how the nose can buzz with sand-itch and how to gather his body's precious moisture around him to guard it and preserve it. As his eyes assumed the blue of the Ibad, he learned the Chakobsa way. -- Stilgar's preface to "Muad'Dib, the Man" by the Princess Irulan ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for stylesheets
On 02.10.2008 (12:01), Kieren MacMillan wrote: > Hi Reinhold, > >> Yes, texi2html creates HTML 4.01 ;-) > > That's a pretty darned good reason! =) ... for leaving behind this horrible beast called texinfo :) In addition to an xml-compliant format. eyolf -- "Ann and I will carry out this equivocal message to the world. Markets must be open." George W. Bush March 2, 2001 >From the President's speech delivered during the swearing-in ceremony for Ann Veneman, the new Secretary of Agriculture. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.8 Ancient music ready for review
On 02.10.2008 (00:04), Juergen Reuter wrote: > > Very nice, I like the structure and your explanatory add-ons! Thanks > Just a few nitpicking comments: > > * 2.8.3 (Typesetting mensural music): "There are no rests in Gregorian > chant notation; instead, it uses Divisiones." I would have expected this > statement to appear somewhere in 2.8.4 (Typesetting Gregorian chant) > instead. Right. Shall move. There may be other similar formulations left behind in the wrong place too. > * 2.8.4 (Typesetting Gregorian chant): > > * "... by placing one of the joining commands pes or flexa ..." => "... > by placing one of the joining commands \pes or \flexa ..." Check. > * "... by modifying the shape of a single-note neume with \auctus and > one of the direction markers \descendens or \ascendens, e.g. \[ > \auctus \descendens a \] ...": Replace "\auctus" => "\auctum". N.B.: > From an implementation point of view, I felt the need to minimize > redundancy in the input language and therefore only defined the > neutrum form "auctum". Maybe users prefer using the correctly > declined forms? Three possibilities: - stick with \auctum and let the users (and documentation writers...) learn that form - allow \auctus too (but where to stop? \aucta as well? what about all the other commands? \cava? \inclinatus?) - allow the root form without inflection: \auct, \inclinat, etc. I don't know which is best. > * FYI: gregorian.ly defines also the commands \versus, \responsum, > \ij, \iij, \IJ, and \IIJ that will produce the corresponding > characters (e.g. for use in lyrics). However, since these commands > uses quite special unicode characters, they will only work with > properly installed unicode fonts that support these characters. > Unfortunately, to my knowledge there is no slashed "A" character > available in unicode. (As far as I know, all of these commands > have not at all been documented so far.) I definitely think this should be documented. I'll have a look at gregorian.ly. Eyolf -- Refreshed by a brief blackout, I got to my feet and went next door. -- Martin Amis, _Money_ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
NR 2.8 Ancient music ready for review
The section on Ancient music is now ready for comments. It has been completely rewritten and reorganized, so please have a look at it and comment, correct, or criticize. Here's a "changelog": - The main change is that the general organization has been revised into two main sections: Gregorian chant notation and Mensural music. There was fairly little overlap between the alternative signs, which were mostly ancient, and the additional, which mostly belonged to the Gregorian section. - The two ligature tables in the Gregorian section have been merged into one. - There are still a few TODOs left, as well as missing cross references here and there, the odd example of bad formatting, etc. This is particularly true about the last section, which has not yet been written. I focused on the main text for this first round; there will be another round for this kind of formalities later on. Eyolf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building the docs fails on require_python_version
On 01.10.2008 (02:11), John Mandereau wrote: > On 2008/09/30 22:46 +, Eyolf Oestrem wrote: > > Since yesterday, I haven't been able to build the docs -- > > fresh git checkout and a newly compiled lilypond. > > Are you sure? (see below) > Do > > make -C python Arghh, I had forgotten about that one in the branch I was building from. Sorry for the noise. eyolf -- Historians exercise great power and some of them know it. They recreate the past, changing it to fit their own interpretations. Thus, they change the future as well. -- Leto II, His Voice, from Dar-es-Balat ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Three questions for ancient.itely
On 27.09.2008 (02:16), Juergen Reuter wrote: > > > On Wed, 24 Sep 2008, =?ISO-8859-1?Q?Eyolf_=D8strem_ wrote: > > Originally, I borrowed the term "Episem" from the OpusTeX implementation of > Gregorian Chant. Just a couple of minutes ago, I did a small search on > Google and have to agree that the form "Episema" is obviously much more used > than "Episem", especially in non-German languages. OK. It has been changed in the doc text. Since the word doesn't appear in that form as a command in any case, I suppose it's not such a big deal to change the command name (but should there, in the future, come an episema command that can be applied to single notes, it should definitely be named "episema" (I thought for a moment that a standard articulation ^- would work, but although it does draw a line, it looks too ugly to even be mentioned as an option...) > As you are working on the docs, there is another thing that comes into my > mind: Currently, \augmentum is introduced in Sect. 2.8.3.6 (Gregorian > square neumes ligatures). This was motivated from an implementation > point of view, which is special for \augmentum within ligatures. However, > from a user's perspective, I think \augmentum should be introduced in > Sect. 2.8.3.1 (Ancient articulations), showing simply an augmented > punctum note. Agreed. In fact, the whole chapter has been rewritten/reorganized with the user perspective in mind. > And yet another thing: The "Hufnagel" style of Gregorian Chant is in > English language obviously better known as "Gothic" style. However, now > that lily 2.12 is already in beta release stage, I would not recommend > performing such a big rename at present. No, besides, those who would want to use it, would know the German name, which is also widely used in English. It is also a much more precise term than Gothic, which can cover anything from Chartres cathedral to pale chicks with long hair... :) I recommend staying with Hufnagel. Eyolf -- Gentlemen, I want you to know that I am not always right, but I am never wrong. -Samuel Goldwyn ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Three questions for ancient.itely
On 25.09.2008 (04:09), Graham Percival wrote: > > Remember that nobody is maintaining the code for ancient music. > If you can supply a patch, great! If not, then don't hold your > breath. One can't remember sth one never knew. Now that I know, I'll start breathing again. e -- Aliquid melius quam pessimum optimum non est. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Episema not showing
It is mentioned as one of the known issues in the ancient section of the documentation that "The episema line is not displayed in many cases." That in itself does not make it very useful, but it's doubly bad when it doesn't even show up in the example that illustrates it. I also noticed that there is a bug report/enhancement request to allow for episemas over single notes, which I strongly support, since that is the most common way to use it (either over a single note, or over one of the notes in a ligature). Eyolf -- Q: Heard about the who couldn't spell? A: He spent the night in a warehouse. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Three questions for ancient.itely
On 24.09.2008 (21:51), Neil Puttock wrote:
> Hi Eyolf,
>
> 2008/9/24 Eyolf Østrem <[EMAIL PROTECTED]>:
>
> > 1. Is there a good reason why it takes the monstruous
> > \override Staff.Accidental #'glyph-name-alist =
> > #alteration-mensural-glyph-name-alist
> > to change the Accidental style of a piece,
>
> I guess what you're after is something like this, which hides the
> 'glyph-name-alist changes using a callback which reads 'style:
>
> \version "2.11.60"
>
> #(define (glyph-name-alist-callback grob)
> (let* ((style (ly:grob-property grob 'style))
> (style-list `((default . ,standard-alteration-glyph-name-alist)
>(hufnagel . ,alteration-hufnagel-glyph-name-alist)
>(makam . ,makam-alteration-glyph-name-alist)
>(medicaea . ,alteration-medicaea-glyph-name-alist)
>(mensural . ,alteration-mensural-glyph-name-alist)
>(vaticana . ,alteration-vaticana-glyph-name-alist
>
> (ly:assoc-get style style-list standard-alteration-glyph-name-alist)))
>
> \relative c' {
> \override Accidental #'glyph-name-alist = #glyph-name-alist-callback
> \override Accidental #'style = #'mensural
> c cis d es
> \revert Accidental #'style
> e f ges g
> \override Accidental #'style = #'vaticana
> as bes b c
> }
Yes, this looks good. Any chance of getting this incorporated in the core
code -- also in such a way that the first \override line is not necessary?
After all, a typical user case would be to want to set the style once for
the whole piece, occasioning much hair-tearing in search for the right
syntax for the one necessary \override line.
e
--
San Francisco isn't what it used to be, and it never was.
-- Herb Caen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Three questions for ancient.itely
I'm working on the docs for ancient music, and I've come across a number of things that relate not primarily to the documentation, but to the program itself: 1. Is there a good reason why it takes the monstruous \override Staff.Accidental #'glyph-name-alist = #alteration-mensural-glyph-name-alist to change the Accidental style of a piece, in contrast to the simple syntax for time signature and clef styles? Heck, even the flag style can be changed with a simple setting... IIRC, it used to be much simpler -- why this change? Any chance of a \set syntax? 2. One of the "known issues" under flags states: The attachment of ancient flags to stems is slightly off due to a change in early 2.3.x. About time to fix that, is it...? 3. The form "Episem" is used, both as a lilypond command and in the documentation text. Since it's not really a medieval concept at all, but a term invented by the Solesmes monks when plainchant was revised/-vived in the late nineteenth century, it is not an established term in any language other than french, where it is episeme (and it doesn't appear neither in Merriam-Webster nor in the full OED). If anything, Episem is the german form. I would strongly recommend going with the latinized greek "episema", which is what the Vatican editions have. This may be too small a matter to merit a change in the lilypond code, but I intend to change to episema in the documentation text, unless there are strong objections to it. Eyolf -- Mate, this parrot wouldn't VOOM if you put four million volts through it! -- Monty Python ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Leaving
On 01.01.2008 (02:52), Graham Percival wrote: > With the end of 2007, I am announcing my intention to leave > LilyPond. Many thanks for all your hard work. Much appreciated. So who's now going to say "can't be done"? :) Eyolf -- Linux: the operating system with a CLUE... Command Line User Environment. -- seen in a posting in comp.software.testing ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Request for comments: prettify snippets page
On 28.12.2007 (08:09), Graham Percival wrote: > I hate to be a wet blanket No, you don't -- just admit it: you love it! :) ... > but everything that I've > learned about documentation project management is screaming "not > worth the effort". ... and you're probably right. eyolf -- Quid me anxius sum? [ What? Me, worry? ] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: voltaOnThisStaff not working as expected
On 01.12.2007 (08:28), Joe Neeman wrote:
> On Sat, 1 Dec 2007 03:27:37 Mats Bengtsson wrote:
> > It seems that this property has been removed in the implementation and
> > that the Volta_engraver by default has been moved to the Score context
> > (I seem to recall that I proposed a similar solution many years ago).
> > So, to get volta brackets on the top of a stave in the middle of the score,
> > you should instead add the Volta_engraver to it, see the regression test
> > called volta-multi-staff-inner-staff.ly
> >
> > \score { <<
> > \new Staff { \repeat volta 2 { c'1 } \alternative { c' } }
> > \new Staff { \repeat volta 2 { c'1 } \alternative { c' } }
> > \new Staff \with { \consists Volta_engraver } { c'2 g' e' a' }
> > \new Staff { \repeat volta 2 { c'1 } \alternative { c' } }
> >
> > >> }
> >
> > Unfortunately, the manual (and the documentation of voltaOnThisStaff in
> > scm/define-context-properties.scm) were not updated correspondingly.
>
> Yes, I changed this behaviour and forgot to update the docs. Sorry.
OK. I'll write up the changes and post a note when it's ready, for you to
check if it's correct.
Eyolf
--
Too much knowledge never makes for simple decisions.
-- CROWN PRINCE RAPHAEL CORRINO, Discourses on Leadership
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
voltaOnThisStaff not working as expected
voltaOnThisStaff is documented as follows in the IR:
Normally, volta brackets are put only on the topmost staff. This variable
overrides this behavior, when set to #t or #f.
However, taking a snippet from LSR and trying out various combinations,
always gives the same result: the volta bracket is printed above the top
staff (incl. the ChordNames).
\score { <<
\new ChordNames \with { voltaOnThisStaff = ##f } \chordmode { c1 c }
\new Staff \with { voltaOnThisStaff = ##t } { \repeat volta 2 { c'1 }
\alternative { c' } }
>> }
\score { <<
\new Staff \with { voltaOnThisStaff = ##f } { \repeat volta 2 { c'1 }
\alternative { c' } }
\new Staff \with { voltaOnThisStaff = ##t } { c'2 g' e' a' }
>> }
\score { <<
\new ChordNames \with { voltaOnThisStaff = ##t } \chordmode { c1 c }
\new Staff \with { voltaOnThisStaff = ##t } { \repeat volta 2 { c'1 }
\alternative { c' } }
\new Staff \with { voltaOnThisStaff = ##t } { c'2 g' e' a' }
>> }
\score { <<
\new ChordNames \with { voltaOnThisStaff = ##f } \chordmode { c1 c }
\new Staff \with { voltaOnThisStaff = ##f } { \repeat volta 2 { c'1 }
\alternative { c' } }
\new Staff \with { voltaOnThisStaff = ##t } { c'2 g' e' a' }
>> }
--
It's easier to be terrified by an enemy you admire.
-- THUFIR HAWAT, Mentat and Security Commander to House Atreides
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \set does not work ???
On 21.11.2007 (15:16), Mats Bengtsson wrote: > In the IR, it's very clear what properties are context properties and what > are > object properties. This is something I will try to explain in the overview of > property settings that I have promised in > http://lists.gnu.org/archive/html/lilypond-devel/2007-09/msg00383.html > (It should be ready any year ;-) ) Excellent! (And now that a new year is coming up, one might hope that that's the one) Eyolf -- Q: What's the difference between a dead dog in the road and a dead lawyer in the road? A: There are skid marks in front of the dog. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \set does not work ???
On 21.11.2007 (11:34), Han-Wen Nienhuys wrote: > 2007/11/21, Rune Zedeler <[EMAIL PROTECTED]>: > > The following gives a syntax error: > > > > \set Staff.Tie #'transparent = ##t > > > > but if I replace with > > > > \revert Staff.Tie #'transparent \override Staff.Tie #'transparent = ##t > > > > then the error disappears - and it seems to be working. > > I do not understand this - the two constructs should be synonymous. > > No, you're wrong. Perhaps it's confusing due to the terminology from > the time you last hacked LilyPond, but \set works on context > properties, and \override on grob properties (or: more exactly: > context properties that contain the initialization of immutable grob > properties.) Out of curiosity, but also with an eye to the GDP and future revisions: (1) is there a reason for this distinction (I'm sure there is), and (2) is there an easy way to explain it? The section \set vs \override in the docs refers to define-grobs.scm "to see what kind of settings they are", but other than that, it seems that the case of the property names is the only guide the poor user has. I know what I usually do: trial and error, starting with \override, which usually works for the things I do Eyolf -- Luke can't levitate his X-Wing out of the bog. Luke Skywalker: I can't. It's too big. Yoda: Size matters not. Look at me. Judge me by my size, do you? Hmm? Hmm. And well you should not. For my ally is the Force, and a powerful ally it is. Life creates it, makes it grow. Its energy surrounds us and binds us. Luminous beings are we, not this crude matter. You must feel the Force around you; between you, me, the tree, the rock, everywhere. Yes, even between the land and the ship. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Weirdness with auto-beaming
On 14.11.2007 (13:56), Mats Bengtsson wrote: > Fixed in GIT! That was quick! Great. Eyolf -- "...[Arthur] leapt to his feet like an author hearing the phone ring..." - Who says that the character of Arthur isn't autobiographical? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Weirdness with auto-beaming
In the following example --
\version "2.11.34"
\relative c' {
\time 3/2
c32 c c c c c c c
c c c c c c c c
c c c c c c c c
c c c c c c c c
c c c c c c c c
c c c c c c c c
}
... all the notes are grouped by four -- except for the 7th and 8th groups,
where eight notes are joined in the same beams. I can't imagine that this
is intentional...
Eyolf
--
"Windows for Dummies" is much more than a book title, it's a Microsoft
way of life!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
GDP: squashed noteheads in improvisation
The improvisationOn/Off command produces squashed noteheads -- fine -- but if there are accidentals in the input code -- as in the example in the docs (1.1.4 Note heads in the GDP version of the docs) -- these are retained, which looks strange and defies the purpose of the squashing: to remove the pitch information. Something for a bug report? Eyolf -- BOFH excuse #162: bugs in the RAID ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff arpeggios
On 01.11.2007 (10:11), Mats Bengtsson wrote: > Cross-staff arpeggios already work in StaffGroups and GrandStaffs, without > adding any extra engraver: Ah, great! Thanks. Why didn't I think of that...? e -- "To make a bad day worse, spend it wishing for the impossible." -Calvin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Cross-staff arpeggios
In the section about arpeggios in the documentation, there is an
example of cross-staff arpeggios in a PianoStaff context:
@lilypond[quote,ragged-right,fragment,relative=1,verbatim]
\new PianoStaff <<
\set PianoStaff.connectArpeggios = ##t
\new Staff { \arpeggio }
\new Staff { \clef bass \arpeggio }
>>
@end lilypond
There should also be something there about how to accomplish this in
other kinds of contexts as well. There is one example in the LSR of
arpeggios between voices in the same staff, and building on that, I
made the following, more general example.
The same can be accomplished in contexts other than
@code{PianoStaff} if the @code{Span_arpeggio_engraver} is included
in the Score context.
@lilypond[quote,ragged-right,verbatim]
\score {
\new StaffGroup {
\set Score.connectArpeggios = ##t
<<
\new Staff \relative c' {
4\arpeggio
}
\new Staff \relative c {
\clef bass
4\arpeggio
}
>>
}
\layout {
\context {
\Score
\consists "Span_arpeggio_engraver"
}
}
}
@end lilypond
My questions are:
1. Is it correct that the Span_arpeggio_engraver should be included in
the Score context? I've tried to include it in StaffGroup, but that
has no effect: the arpeggios just disappear.
2. Is there a more elegant way to write the example? E.g. to avoid the
\layout section?
Eyolf
--
Bill Gates did not realize was that his daughter would grow up to be a
rebel and would never use anything but Linux for her whole life.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Questions about articulation settings for the GDP
On 31.10.2007 (00:14), Graham Percival wrote: > Mats Bengtsson wrote: > >Actually, the answer is different for different articulations. Some, like > > \fermata > >are always placed above the stave, whereas others like \accent are placed > >opposite to the stem. All this is specified in the file scm/script.scm. > Eyolf, could you include info about this in your next update of > Expressive? Yes. Perhaps this should be a general sub(sub)section, since it applies to many different kinds of signs? As it is now, there are more or less identical remarks about the "_" and "^" constructs in "dynamics", "articulations", "Ties", "Slurs", and "Phrasing Slurs". That's not necessarily a problem, but it might be an idea to gather the info together and then refer very briefly to it at the relevant places. eyolf -- There was this drylander who was asked which was more important, a literjon of water or a vast pool of water? The drylander thought a moment and then said: "The literjon is more important. No single person could own a great pool of water. But a literjon you could hide under your cloak and run away with it. No one would know." -- The Jokes of Ancient Dune, Bene Gesserit Archives ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Questions about articulation settings for the GDP
I'm working on the articulations for the GDP, and I've ran into some
things that I would need assistance on:
1. Automatic placement. I think there should be a brief note about
what the rules are for how they are placed by default. Opposite of the
stem? How about polyphony? According to the voice number?
2. I've tried to work with different values for crescendoSpanner, but
there is no difference between line and dashed-line -- they both
produce a dashed line. Here's the example from the manual (ran with v.
2.11.34):
\set crescendoText = \markup { \italic "cresc. poco" }
\set crescendoSpanner = #'line
a'2\< a a a a a a a\!\mf
3. similar problem with \override Hairpin #'after-line-breaking = ##t
It should, as I've understood it, let the hairpin continue to the
first note on the following line, but that doesn't happen here.
Eyolf
--
Honi soit la vache qui rit.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
