Re: my favorite bug :-)
On 01.05.2015 (14:16), Werner LEMBERG wrote: For the curious people, here's `lines.pdf' if ghostscript erronously processes its own `lines.ps' demo file. Pretty! Have you tried to play it? e -- To be a kind of moral Unix, he touched the hem of Nature's shift. -- Shelley ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Limits of algorithmic typesetting (was: Re: mutopia's shortcomings)
On 24.04.2015 (14:12), tyronicus wrote: Simon Albrecht-2 wrote I should’ve written “I believe that nothing as beautiful/good as this will ever be engraved by a machine” then, since basically it is my belief. Maybe I exaggerated a little :-) And you may believe differently of course. My contrary belief: A machine will draw a circle better than a human 100% of the time. It's a matter of telling it how. A machine may draw a more geometrically perfect circle, but if I were to hang the drawing on my wall, I'd much rather have one made by Mirò than by a machine. Same with notation. -- will one flock stop at Senju town? geese flying north ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On 23.04.2015 (10:04), H. S. Teoh wrote:
Besides, only powers of 2 are valid for durations, which wastes all the
other numbers in between. Unfortunately I don't have a good idea on how
to write durations without using digits either.
I started on a vim script to remap the keyboard as follows:
-
| s | g | a | b |times| | | ' |16/64|32/128 | |
| Q | W | E | R | T | Y | U | I | O | P | | |
---
| c | d | e | f | r/R | 1 | 2 | 4 | 8 | | | |
| A | S | D | F | G | H | J | K | L | | | |
-
|undo | del |flat |sharp|breve| dot | , | | | | |
| Z | X | C | V | B | N | M | | | | |
---
So, the keyboard is completely remapped: the left hand enters the pitches, in
the sequence of a piano keyboard, and the right hand 'plays' the rhythms,
which are laid out 'ergonomically' from the \breve (B) to the 32nd note (P):
64th and 128th notes re-use the O and P keys in shifted position, and
\longa and \maxima are placed on S-l and S-m.
Flats and sharps are added with 'c' and 'v', octaves are modified with
'i' (up) and 'm' (down), and cautionary accidentals are entered with '!'
and '?'. A \fermata is added with '.'
The script simplifies note entry for lilypond files. Three different
kinds of tasks are performed with single or just-a-few key presses:
- entry of a new note;
- modification of an existing note (wrt duration, accidentals, octave,
dots, cautionary accidentals, and articulation signs);
- certain special signs, such as fermata, musica ficta, \times x/y {}, etc.
The layout ensures that values that are likely to be close together
(stepwise motion and leaps of fourths; 'f' + 'sharp', 'e' + 'flat';
adjacent rhythm values, etc.) are close together also on the keyboard.
Any of the pitch keys (asdfwer, plus qgG for s, r, and R) enters a
single note name. Accidental modifications are rememebered, so one
doesn't have to change every 'f' to 'fis' in g major. Modifications of
the simple note is done subsequently. E.g., to turn
f into fisis!,\breve..
one would type the keys 'vv!mbnn' in any order.
With this scheme, note entry is faster than in any other note-entry system
I've tried (and I've tried a lot), perhaps excepting midi input. Most
notably in this context is that there is no jumping up and down to the
number row, and, yes, no redundancy wrt which numbers are used.
Unfortunatly, I never managed to finish it - vimscript is an odd beast -
but I've found that MuseScore can be configured to work more or less the
same way, so that's what I'm using now.
Eyolf
--
A farmer with extremely prolific hens posted the following sign. Free
Chickens. Our Coop Runneth Over.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
On 23.04.2015 (19:40), Richard Shann wrote: Well, if you set up that mapping for Denemo you could get LilyPond's beautiful typesetting too :) The last time I tried, it wasn't possible in denemo, I think because the keyboard shortcuts were tied to specific octaves, or something like that. I've also tried to get it to work in frescobaldi, but also with no luck. MuseScore is the only frontend I've tried where it actually just works. Maybe I have to do another round. But believe me - I HAVE tried! Btw. I export from Musescore to xml and convert to ly, so the outcome is always Lilypond. Eyolf -- Just when you thought you were winning the rat race, along comes a faster rat!! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Setting entire document fonts
On Fri, 24 Oct 2014 10:10:34 -0700 (PDT) tisimst tisimst.lilyp...@gmail.com wrote: Internally, when you call set-global-staff-size, it resets the text fonts. Thus, if you want to use a different staff size, that must go PRIOR to where you define the fonts. Kinda weird, I know, but that's how it works. ... and one of those little points where lilypond devs should really massage their neighbourhood-user-friendliness muscle a little... Sorry - I don't mean to troll or flame, but this conversation just brought back memories of hours spent in search of the causes of silly errors such as this. Argh. eyolf -- Finality is death. Perfection is finality. Nothing is perfect. There are lumps in it. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Tilde causes error message: unrecognized string, not in text script or \lyricmode
If I try to run the following (either directly or as part of a score):
\relative c' {
\key e \minor
\time 4/4
r4 r8 e8 e fis g4 fis fis8 fis fis e dis e ~ e4 r8
e8 e fis g4 a a8 a a g a b~ b4 r8
b b b b4 c c8 c c b a b~ b4 r8
b8 b a g4 fis fis8 fis fis e dis e ~ e4 r8
}
I get the error message: unrecognized string, not in text script or
\lyricmode at the tildes in the first and last line. The es after the
tildes do not get written out. The two b~ work as expected, though,
even though everything but the pitches is the same as in the first line.
If I remove the tildes, everything works - except that I don't get the ties.
I'm running v. 2.18.2 under Arch Linux.
Eyolf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tilde causes error message: unrecognized string, not in text script or \lyricmode
On 13-10-2014 02:02, Mark Stephen Mrotek wrote: Eyolf, Your snippet compiles without error message for me. I am using Lilypond under Windows. Which version do you use? I notice that a space separates the two e from their ~. The space is not between the two b and theirs. I forgot to add that: no, there is no difference whether there is a space there or not. I also tested the snippet on lilybin.com, both with the latest stable (which is the same as I am running) and the latest devel, with the same result. e ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Margins
On 17.04.2009 (20:26), Arvid Grøtting wrote: I have a truly marvellous proof of why, which this margin is too narrow to contain. Post of the year :) Eyolf -- Love is the process of my leading you gently back to yourself. -- Saint Exupery ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing psalms
On 15.01.2009 (11:11), Alberto Simões wrote: Hello I am transcribing a music with psamls. What this mean: there is a standard music portion, with a correct time signature, but there is a portion where the singer will say a lot of words for each note, and these specific bars have different lengths than the one in the time signature. While I searched in the documentation for a way to specify bar lengths without defining a specific time signature, but didn't find it. I am sure it was my bad english/music knowledge. Can anybody point me with some example? You could have a look at some of the suggestions in section 2.8.5 of the Notation Reference: http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Working-with-ancient-music_002d_002dscenarios-and-solutions#Transcribing-Gregorian-chant It may not be exactly what you're after, but it may get you further. Eyolf -- Do what you can to prolong your life, in the hope that someday you'll learn what it's for. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: avoid slur help
On 26.12.2008 (15:06), Reinhold Kainhofer wrote: If so then I'd just use d!4. instead. No, it was common practice to put accidentals above notes in older times. Sometimes these were meant to be optional, sometimes they were cautinary accidentals. In any case, if you try to be close to the source, you should write it above the note and not as d!4. Slight correction: it is customary in modern editions to put editorial accidentals above the note. They are not optional, but frequently left to the performer to apply, according to more or less strict rules (see Musica ficta in the docs). Eyolf -- It's all GNU to me. -- From a Slashdot.org post ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: question about transposing an interval of a 4th
On 22.12.2008 (12:03), Graham Percival wrote: On Mon, Dec 22, 2008 at 06:21:56PM +0100, Eyolf ?strem wrote: 1. Make no mistake about it: using LilyPond IS to be a programmer, to a greater or lesser extent. And even though the plain an simple sheets with a melody line and a title just calls for a scripting language programmer, Not only that, but simply thinking about music expressions requires a certain amount of programmer-like thought. I still see newbies posting here when their misunderstanding traces back to not understanding music expressions... but hopefully that will lessen once 2.12 is out and people read the updated tutorial. Precisely. And there are three levels here, which require different treatment: a) what is a music expression in the first place (a compound something something which can consist of any number of elements of different types denoting musical content, with properties which can be tuned in various ways). This I think is taken well care of in the new docs; b) all the different kinds of properties, the problem here being mainly syntactical: there is a bewildering amount of possibilities, not necessarily easy to find (although it has improved a lot) and every letter has to be EXACTLY RIGHT. This is where a macro layer would be helpful, but as On 22.12.2008 (14:52), Carl D. Sorensen wrote: This may be possible as far as scheme is concerned, but I don't think it's possible for context properties. Until all collisions and spacing can be automatically resolved, users will need access to the context properties in order to resolve collisions or incorrect spacing. Although I don't imagine a macro system *replacing* the direct access, only *simplifying* it. c) scheme functions; the real programming stuff: how to automate tasks, use loops and conditions, etc. Realistically, this is probabaly where a user with no interest in or experience with programming will be lost anyway, so apart from explaining what all those parentheses do, there may not be much more to do than to say learn scheme and point to some good introductions. A macro layer would be helpful, though. As also, on 22.12.2008 (14:52), Carl D. Sorensen wrote: Predefined scheme packages are a great idea, IMO. On 22.12.2008 (12:03), Graham Percival wrote: 2. Minimize the visibility of scheme (and the direct envolvement with LP's context properties etc.) by developing a more complete macro layer between the user and the backend, the way LaTeX sits between TeX and the user. Stuff along those lines are planned for GOP... Good! but just like the extent of doc work in GDP, it all depends on the amount of time and effort that users are prepared to give. Of course. Eyolf -- It is exactly because a man cannot do a thing that he is a proper judge of it. -- Oscar Wilde ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: question about transposing an interval of a 4th
On 22.12.2008 (17:37), John Mandereau wrote: Le lundi 22 décembre 2008 à 15:14 +0100, James E. Bailey a écrit : Am 22.12.2008 um 14:04 schrieb John Mandereau: Indeed: there is currently no thing in all LilyPond documentation that introduces Scheme programming for non-programmers. And there shouldn't be, in my opinion. Why not? I'm sure a not so small amount of users would like to program with LilyPond, so revising and extending the Scheme tutorial is a solution IMHO. There are two solutions in the long run, taking two different approaches, which are not necessarily incompatible -- in fact, they should be combined, but they both call for efforts in different areas: 1. Make no mistake about it: using LilyPond IS to be a programmer, to a greater or lesser extent. And even though the plain an simple sheets with a melody line and a title just calls for a scripting language programmer, most people will sooner or later want/need to take one step further. Scheme is -- at least the way LP works at the moment -- an essential part of that. A full-scale scheme-from-the-LilyPond-perspetive tutorial would be nice to have, but a less ambitious solution would be a thorough and precise description of the INTERFACE between the two (How does LP use scheme? or How will an LP user use scheme profitably?), together with a brief description of the most common elements of scheme. I'd add also an outline of which things HAVE to be the way they are (because of requirements within scheme) and which are arbitrary in the sense that they are the way they are because of choices made by the LP developers. 2. Minimize the visibility of scheme (and the direct envolvement with LP's context properties etc.) by developing a more complete macro layer between the user and the backend, the way LaTeX sits between TeX and the user. This might probably be done to a large extent with today's LP, but the full consequence of this approach would be to modularize LP -- let the core program take care of the typesetting mechanics, and make packages for Gregorian chant, for harp music, for lead sheets, etc., i.e. for WHAT to typeset and for how the user communicates with the typesetting backend. One could think of it as an extended and systematized LSR: not just isolated examples of how to solve a particular problem, but a system of task-oriented packages. I'm sure there are disadvantages with this (in addition to the the necessary development time), but there are certainly also advantages -- one of them being to minimize the need for threads like this one. Eyolf -- A wizard cannot do everything; a fact most magicians are reticent to admit, let alone discuss with prospective clients. Still, the fact remains that there are certain objects, and people, that are, for one reason or another, completely immune to any direct magical spell. It is for this group of beings that the magician learns the subtleties of using indirect spells. It also does no harm, in dealing with these matters, to carry a large club near your person at all times. -- The Teachings of Ebenezum, Volume VIII ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Notation Reference typo
On 16.12.2008 (05:14), Graham Percival wrote:
Yes, lilypond can read strings just fine without the #, but as a
matter of doc policy, we're supposed to use the # everywhere for
scheme arguments.
Ugly, ugly. This is one of my main gripes with LP, this damned freedom of
choice which creeps in everywhere and makes everything more complicated,
not easier, because it blurs one's conception of the syntax. So, here, the
#' is optional, whereas elsewhere it isn't. One can leave out everything but
the braces around a music expression -- defaults, defaults everywhere --
but eternal damnation (and a failed file) upon you if you mix the cases
wrongly in a grob property name.
If the '#' isn't needed, why keep it as the thing one has to learn? For
future compatibility? I can understand if a certain unified syntax ('#
before all scheme strings') should be available, for automated tasks, etc,
but I also assume that the optionality of the '#' is there for the benefit
of the user, so is there any good reason why the ordinary, human user
should see the # form at all?
Eyolf
--
(6) Men employees will be given time off each week for courting
purposes, or two evenings a week if they go regularly to church.
(7) After an employee has spent his thirteen hours of labor in the
office, he should spend the remaining time reading the Bible
and other good books.
(8) Every employee should lay aside from each pay packet a goodly
sum of his earnings for his benefit during his declining years,
so that he will not become a burden on society or his betters.
(9) Any employee who smokes Spanish cigars, uses alcoholic drink
in any form, frequents pool tables and public halls, or gets
shaved in a barber's shop, will give me good reason to suspect
his worth, intentions, integrity and honesty.
(10)The employee who has performed his labours faithfully and
without a fault for five years, will be given an increase of
five cents per day in his pay, providing profits from the
business permit it.
-- Office Worker's Guide, New England Carriage Works, 1872
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
How to make note spacing disregard lyrics
What would be the setting to let notes be spaced without regard for the corresponding lyrics? E.g. to let two eighth notes be on the same distance from each other whether the first note has mum or if. I've played around with removing engravers and setting properties, but I haven't found anything that works. (And, yes: it's for the ancient chapter -- I'm not just wasting time here :) Eyolf -- Quid me anxius sum? [ What? Me, worry? ] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to make note spacing disregard lyrics
On 25.11.2008 (16:26), Trevor Daniels wrote:
Eyolf
Does this do what you want? I'm not sure what it is you want to do, so
this may be wide of the mark. The quotes make a phrase into one big
syllable which can then be placed by specifying its musical length. The
notes are spaced out to fit each phrase, but that can be controlled by
changing the musical length.
Sorry, I wasn't clear. What I'm after is a way to mimic the ligatures of
plainchant in ordinary notation. I've found that the easiest way to do that
(without fiddling with scheme) is to use \time 1/4 and set all the
neumes as subdivisions of a quarter note. With \override BarLine
#'X-extent = #'(-1.5 . 1.5), each neume will then be separated into nice
groups, without having to resort to slurs etc.
BUT the problem that remains is that long syllables, like -bum cause the
notes on that syllable to be spread wider apart than e.g. with -ri-, as
in the following example:
\include gregorian.ly
spiritusC = \relative c' {
\time 1/4
\override Lyrics.LyricSpace #'minimum-distance = #0
d4 \times 2/3 { f8 a g } g a a4 g f8 e
d4 f8 g g8 d f g a g f4 g8 a a4
\times 2/3 { g8 f d } e f g a g4 }
spirLyr = \lyricmode {
Spi -- ri -- _ _ tus _ Do -- mi -- ni _
re -- ple -- _ vit _ or -- _ bem _ ter -- ra -- _ rum,
al -- _ _ le -- _ lu -- _ ia.
}
\score {
\new Staff
\new Voice = melody \spiritusC
\new Lyrics = one \lyricsto melody \spirLyr
\layout {
\context {
\Staff
\remove Time_signature_engraver
\remove Collision_engraver
\override BarLine #'X-extent = #'(-1.5 . 1.5)
\override Stem #'transparent = ##t
\override Beam #'transparent = ##t
\override BarLine #'transparent = ##t
\override TupletNumber #'transparent = ##t
}
}
}
I should also say that if there is a better way of doing this, I will stop
my search here and now.
eyolf
--
James Bond: Oh, thanks for deserting me back there.
Major Anya Amasova: Every woman for herself, remember?
James Bond: Well, you did save my life. Thank you.
Major Anya Amasova: We all make mistakes, Mr. Bond.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to make note spacing disregard lyrics
On 25.11.2008 (05:46), Till wrote: But this is just a workaround, not a solution. It has been stated many times that the spacing is not really working for ancient: it is too much built on the assumption that a note takes space according to its duration and not only according to its real extent. Even though this is a different problem than the one I was addressing, it's definitely one that I would like to see a solution to. Some of the gregorian examples in LSR and manual alike are ... ehem ... slightly embarrassing. e -- The worst sort of alliances are those which weaken us. Worse still is when an Emperor fails to recognize such an alliance for what it is. -- PRINCE RAPHAEL CORRINO, Discourses on Leadership ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ubuntu 8.04 and Lilypond
On 25.11.2008 (16:54), Ronald van Eunen wrote: Hi, I have installed Lilypond on a Windows Xp based computer. Just for trying, music notation used to be my only reason for keeping Windows. But now that I've found Lilypond, I want to install it on my Ubuntu laptop. It seems to install (via apt-get), but no results so far. What do I need to know? I still consider myself an Ubuntu/Linux newbie. Please help me enjoy Lilypond and get rid of Microsoft!! 1. Solution #1 (basic) a) write a .ly file and save it somewhere, e.g. /home/ronald/music/great-music.ly, which in linux can be abbreviated to ~/music/great-music.ly (I remember searching for a while for an explanation of what '~' actually meant when I was new to linux; I mean: how do you google something like that...?) b) Open a console and cd to where you saved your file (cd music) c) process your file: lilypond great-music.ly d) open your fine file with a pdf reader (e.g. xpdf great-music.pdf) 2. Solution #2 (simpler) apt-get jedit, then install the lilypondTool in the plugins section. eyolf -- KnaraKat Bite me. * TheOne gets some salt, then proceeds to nibble on KnaraKat a little bit ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Just chords and lyrics.
On 25.11.2008 (20:56), Johan Vromans wrote: Try http://chordii.sourceforge.net . Hey, that looks nice! Another approach, for which I'm partly but indirectly responsible, is Seal (http://www.math.tu-dresden.de/~kuettler/seal/), which doesn't have much to do with the original request, but which may be of interest on a general level. It's a ruby program which takes the html files from a specific chord site by yours truly (http://dylanchords.info) as input and outputs a typographically and practically well-designed pdf file with LaTeX as the middle ground. It is not generally applicable, though, since it uses the site-specific css classes. Eyolf -- To make an enemy, do someone a favor. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quick-insert mode for vim -- work in progress
On 21.11.2008 (14:34), Bertalan Fodor wrote: Also there is a quick insert mode work in progress for jEdit / LilyPondTool. That's the second reason why I found out I had to make something myself (third, actually: after my sound contempt for emacs, and the desire to do some learning-by-doing): I had high hopes for the LPT's quick insert mode, but in the current version, it didn't do much for me (that's also why I nagged you for an update in the other thread :) However, my quick insert mode will be really a virtual piano made from the keyboard. I found that approach much better. It will sport automatic accidental handling. For example if you want to write c es c bes, b c in quick lily you type: d g e d l , e d In LilyPondTool you'll be able to type: c g c s x c (try it!) Hm... where in that sequence is the ',' information? If 's' is 'bes,', why then is'nt 'x' = 'b,'? As far as I understand your layout, the two bottom rows mimic a piano keyboard, like so: - | | | | | | | | | | | | | Q | W | E | R | T | Y | U | I | O | P | | | --- | as | bes | | cis | dis | | fis | gis | | | | | | A | S | D | F | G | H | J | K | L | | | | - | a | b | c | d | e | f | g | | | | | | Z | X | C | V | B | N | M | | | | | --- That, to me, has the great disadvantage of moving too far away from the ergonomics of the computer keyboard, i.e. disregarding the difference between a piano keyboard and a computer keyboard. With this layout, (a) the home row is taken up by little-used accidentals, and (b) one function (add a note) will either have to be done with two hands, or by letting one hand jump all over the keyboard. That's why I went for the home-row based layout with the pitches in one hand and the rhythms in the other: - | s | g | a | b |times| | | ' |16/64|32/128 | | | Q | W | E | R | T | Y | U | I | O | P | | | --- | c | d | e | f | r/R | 1 | 2 | 4 | 8 | | | | | A | S | D | F | G | H | J | K | L | | | | - |undo | del |flat |sharp|breve| dot | , | | | | | | Z | X | C | V | B | N | M | | | | | --- In practice, I find this much quicker, even though there are a few extra key strokes. I would type a dc a rmc rv a Much more natural. However, it makes it complicated, because the software must know the key. So for example is c minor it will be rendered as c es c bes, b c but in h major, it will be rendered as c dis c ais, b c I assume/home you will also have a key-agnostic mode, e.g. for transcribing music; I wouldn't want to have to think which key am I in? all the time, if all I want is to enter a 'g'. In practice, at least for most of the music I type, the remember the accidental modification model does more or less what you wish (after the initial switch from 'b' to 'bes', every 'r' press will give a 'bes'), but with greater simplicity and -- I think -- flexibility. I like the idea of setting the key, though. It could either be done explicitly, or by reading back to the previous \key command if one exists. I think I'm going to shamelessly steal that idea... Eyolf -- Neurotics build castles in the sky, Psychotics live in them, And psychiatrists collect the rent. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quick-insert mode for vim -- work in progress
On 21.11.2008 (18:50), Nicolas Sceaux wrote: I'm using the keyboard mapping suggested by a user and described here: http://nicolas.sceaux.free.fr/index.php/2006/07/01/8 That's very close to my layout. The arrangement of the pitch keys is a little different, but the principle is the same. That also confirms my experience: that fewer key-presses isn't necessarily the quickest. That said, tastes and techniques differ; I could probably type in a beethoven sonata quicker than I could play it on a real piano eyolf -- You don't have to wait--you can have it in 5.004_54 or so. :-) -- Larry Wall in [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quick-insert mode for vim -- work in progress
On 21.11.2008 (21:00), Bertalan Fodor wrote: Then for sure I will include your layout as an option. ... and an option to customize the layout, I assume? e -- At Microsoft, quality is job 1.1 - Use Linux! ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with learning lilypond
On 20.11.2008 (09:49), [EMAIL PROTECTED] wrote: I had the same problem. Then I started to develop LilyPondTool for jEdit. Using that I managed to understand LilyPond much better. Talking of which: when will there be a new version? :) Eyolf -- You're all clear now, kid. Now blow this thing so we can all go home. -- Han Solo ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Quick-insert mode for vim -- work in progress
The most useful and simple tool I've had the pleasure to work on lilypond files with, is Nicolas Sceaux's lyqi mode (lilypond quick insert). There is only one thing wrong with it: it's for emacs. I therefore decided to make my own version of it for vim. I also decided to do it mostly in python and not in vimscript, both because of the latter's slightly arcane syntax, and because I eventually expect to take advantage of some of the midi oriented modules that exist for python. These are plans for the future; at the moment, it is hardly more than a skeleton. I didn't know any python before I started this, and my vim-script abilities are limited. However, following the principle release early and often, I now make it available, with all necessary qualifications, if anyone is interested either to use it or to participate. One thing that is missing, is a proper plugin architecture, so I wouldn't recomment putting it in the ~/.vim/plugins folder, but the file lyqi-all.vim can be sourced, and the main function Lyqi_key() called. There is some documentation in the file, which is located at http://repo.or.cz/w/lyqi-vim.git I welcome comments and contributions. Eyolf -- The study of non-linear physics is like the study of non-elephant biology. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: No time signature?
On 17.11.2008 (19:49), Derek Schmidt wrote:
Graham,
I did briefly look at that chapter. What I really need to know is:
will it take away any bar lines? Or at least let me decide where to
put them?
I actually don't want the Gregorian style (or, at least, that's not
what I'm working on). I don't know enough about Gregorian chant to
know if it's similar (for all intents and purposes) to Slavic and
Byzantine chant.
Thanks again,
A
Actually, most of the relevant chapter has been updated, but not the parts
about working with chant in modern notation. Until then, you may find the
attached file useful. It was made to mimic a very specific layout, but you
may play around with some of the settings in the layout section.
There are also some useful hints in the lsr.
Eyolf
--
This report is filled with omissions.
\version 2.11.60
% this is the latest development version. The file should work on earlier
% versions too, although the compiler may complain. Change to your own
% version number, or upgrade your installation.
%
% Everything after a % is a comment, which is ignored in the output.
%
% To generate png files suitable for inclusion, open the console (on
% windows: Win-r), move to the directory with your files, and type
%
% lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png -dresolution=600 filename.ly
%==
\header {
title =
subtitle =
subsubtitle =
composer =
poet =
tagline = ##f
}
% This setting corresponds to the mystaffsize variable defined in layout
% section below.
#(set-global-staff-size 14)
genStuff = {
\key c\major
\time 4/4
}
%==
% The following sections are variables with the different melodies,
% defined here and entered into the score later on. This is a convenience
% to make the file easier to read. It is not strictly necessary -- it could
% all have been written directly into the \score section, but it is more
% organized this way.
%
% I've found it most convenient in situations like this, with several
% different melodic versions of possibly different length vertically
% aligned, to use tuplets (defined with \times x/y {}).
%
% \startGroup and \stopGroup are for the brackets. The \markup command is a
% hack to get the label in place; here, it's tied to a note within the
% bracket. I haven't figured out how to tie them to the brackets
% themselves. ^ means: place above staff. _ would place it below.
%==
Lo = \relative c'' {
\genStuff
\clef treble
\set Staff.instrumentName = Lo4951
\times 4/9 { c\startGroup c c d c^\markup{a} b a a g\stopGroup }
\times 4/7 { s s s g a g s }
\times 4/9 { a\startGroup b c b a^\markup{c} c a a g\stopGroup }
}
PaA = \relative c'' {
\set Staff.instrumentName = Pa776
\genStuff
\clef treble
\times 4/9 { c\startGroup c c d c^\markup{a} b a a g\stopGroup }
\times 4/8 { a\startGroup c b a^\markup{b} g g a g\stopGroup }
s1
}
PaB = \relative c'' {
\genStuff
\clef treble
\set Staff.instrumentName = Pa780
\times 4/9 { c4\startGroup c c d c^\markup{a} b a a g\stopGroup }
\times 4/8 { a\startGroup c b a^\markup{b} g g a g\stopGroup }
\times 4/9 { a\startGroup b c b a^\markup{c} c a a g\stopGroup }
}
textA = \lyricmode {
%==
% if you want text in the examples, fill them in here, syllables separated
% with space--space, and add \new Lyrics \textA (etc.) at the place
% in the score declaration below where you want the text to appear
%==
}
%==
% Here, the variables defined above are entered into the score. The ...
% indicates polyphonic music, i.e. separate staves.
%==
\score {
\new StaffGroup {
\new Staff \Lo
%\new Lyrics \textA
\new Staff \PaA
\new Staff \PaB
}
%==
% Everything below this point is settings to override standard notation to
% get stemless notes etc., and to get a layout which you can copy to
% all the different files. Even better: save it in a separate file in the
% same directory as the music files, e.g. layout.ly and add the line
% \include layout.ly
% at this point. Then, if you want to make changes, you can do them in one
% place instead of in every single file.
%
% You will need to change the font tree, since you won't have these fonts
% installed. They are the serif, the sans-serif, and the monospaced fonts,
% in that order.
%==
\layout {
indent = 0\cm
ragged-last = ##t
myStaffSize = #14
#(define fonts
(make-pango-font-tree
JensonOSN
Re: Lighter appearance
On 14.11.2008 (16:20), Carl D. Sorensen wrote: On 11/14/08 2:27 PM, Graham Percival [EMAIL PROTECTED] wrote: I agree -- are you sure the top line isn't from Finale or something? It looks incredibly bad. WTF is up with the gap between the sixteenth and eighth in the second bar from the end?! LilyPond would *not* produce that. The note spacing in Johan's sample is dramatically different (worse) than in my LilyPond output. I assume that the bad spacing in the top example was due to some wide-syllable lyrics which were not included in the image? Other than that, I think the head to head comparison proves with all the clarity one could desire how superior Lilypond's output is to its rivals'. That music typesetting is not just about joining dots. Tastes may differ, but the Sibelius sample looks like something from a first-grade piano manual with its oversized noteheads -- almost like setting a whole text in helvetica capitals. Finale has -- apart from its abhorrable spacing -- these ultra-thin hairlines which makes it look like something that is set by a computer... That said, I sometimes think the lilypond defaults are a bit to the heavy side. Especially the final barlines come to mind. As a future feature, it wouldn't be a bad idea with an alternative set of lighter settings which could be turned on with a \layout or \paper option. Eyolf -- I know the answer! The answer lies within the heart of all mankind! The answer is twelve? I think I'm in the wrong building. -- Charles Schulz ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Automatic indentation in Vim
On 13.11.2008 (22:03), Martin Tarenskeen wrote: Hi Lilyponders, Any Vim users here ? I'm using Vim for editing Lilypond files on a Linux Fedora 9 system. I have syntax highlighting, which is great. How do I enable automatic indentation to make things even easier ? set autoindent set smartindent filetype plugin indent on syntax on This is what I have in .vimrc. And then of course the lilypond ft-plugin. The indent file is loaded with set runtimepath+=/usr/share/lilypond/LILYPOND_VERSION/vim/ I'm also working on a lyqi-mode for vim. It's going to be great, some day, but don't hold your breath... e -- Neutrinos have bad breadth. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: adding rests automatically
On 11.10.2008 (11:01), Carl D. Sorensen wrote:
You can read about music functions in the documentation. See the notation
reference for 2.11, section 6. Music functions.
The paradigm in the beginning is confusing:
function =
#(define-music-function (parser location var1 var2... )
(var1-type? var2-type?...)
#{
...music...
#})
where
argiith variable
argi-type? type of variable
It is clear what it means, of course, but a mathematician would be troubled
by a where clause which defines arguments which are not present in the
equation, and a musician may be confused by it, at least intially.
Eyolf
--
___ __ Frobtech, Inc.
/__/\ ___/_/\
\ \ \ / /\\
\ \ \_/__ / \ If you've got the job,
_\ \ \ /\_/___ \ we've got the frob.
// \__\/ / \ /\ \
___//___/\ / _\/__
/ / \ \// //\
__/ / \ \ // // _\__
/ / / \___\// // / /\
/_/__/___/ // /___/ \
\ \ \___\ \\ \ \ /
\_\ \ / /\\ \\ \___\/
\ \/ / \\ \\ /
\_/ /\\ \\/
/__/ \\ /
\ _ \ /_\/
\ //\ \/ \ \ \
// \ \ / \ \ \
\\ /___\/ \ \ \
\\/\__\/
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Notating recitative
On 10.10.2008 (16:32), Ari Torhamo wrote: I don't know how to get the two vertical lines before and after the note/chord that defines the pitches on the recitative section. Is there some command/marking I can attach to a note in the chord so that all lines would be automatically drawn from the lowest note to the highest. Or do I need to draw four vertical lines (bar lines perhaps?) and define their length and horizontal position on the staff? If you have to get it EXACTLY as in the pictures, I guess some kind of line-drawing/markup command is what you're facing (and I don't know how to draw them). However, the customary thing in this kind of notation is to use breve notes (the modern kind, which has single vertical lines, close to what you have in your example). Eyolf -- Some say I have no conscience. How false they are, even to themselves. I am the only conscience which has ever existed. As wine retains the perfume of its cask, I retain the essence of my most ancient genesis, and that is the seed of conscience. That is what makes me holy. I am God because I am the only one who really knows his heredity! -- The Stolen Journals ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: rolled chords
On 10.10.2008 (11:11), Danny Sosa wrote:
First of all... thanks to James for his help with mBreak, the magic words
were outside of any music block. I was trying to define mbreak inside the
{}.
Does anyone know how to write rolled chords in Lilypond?
The sign in the picture is an arpeggio, which is denoted by appending
\arpeggio to the chord construct:
c e g c1\arpeggio
Look for arpeggio in the manual.
eyolf
--
There's never enough time to do all the nothing you want.
-- Calvin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Elision mark glyph (was: unusual Alto Clef)
On 09.10.2008 (16:51), Werner LEMBERG wrote: Well, of course, but the idea is not to `trace' such a glyph but to generate it, using mathematical rules, in particular to make it optically fit to different sizes, similar to the other feta glyphs. While we're on this subject: there's another quite important (at least in my line of work) glyph missing, and that's a better mark for lyric elisions. At present, it's a slur SPANNING the last letter of one word and the first of the next, but ideally it should be a small semi-circle JOINING the words. As glyphs go, this is probably the easiest there is, since there should be no decorations or serifs or anything, just the lower half of a circle. I can write THAT in metafont, but I have no idea how to incorporate it in the macro system that the feta font apparently needs to comply with. I discussed this with Han-Wen, and he referred me to you, for pointers on how to use the macros. How about it...? Eyolf -- All men make mistakes, but married men find out about them sooner. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: unusual Alto Clef
I suppose this thread brings up the issue of styles: since the mentioned clef is not really a new SIGN just a different GLYPH, are there other such signs that we want? What about the Fake book style (a more hand-written'ish style)? Or, perhaps more pertinent, since it's already half there: a complete set of glyphs for the ancient styles? I could also imagine(/desire) a set of manuscript-like glyphs for mensural music, and perhaps an even more 16th/17th century alternative to petrucci. Im not saying either that this should all be made, or that if one addition is kept out so should all others -- rather, I'm asking if there are more glyphs that should be considered, and (following up on my previous post) what are the requirements and how does one make them. Eyolf On 09.10.2008 (15:54), David Bobroff wrote: I've posted a slightly clearer copy of such a clef to issue 693. For what it's worth, my memory tells me that this style of C clef is to be found in French publications. I certainly remember seeing it in trombone parts of French pieces and this example comes from the Ravel Concerto for left hand (1st trombone part). David Jonathan Kulp wrote: I can't seem to find a better image of this clef in the materials I have on hand or on an internet search. I got it originally from a .pdf file downloaded from the International Music Score Library Project. It'd be better to have an original paper score in hand for scanning at high res. If no one can come up with one in a day or two I'll talk to our orchestra conductor and see if he might have some examples in his library. Jon Werner LEMBERG wrote: Well, your version differs heavily from what the scanned image shows. However, to create a good glyph shape, we probably need better scans of probably larger clefs. Anyone who could provide that, probably adding it to http://code.google.com/p/lilypond/issues/detail?id=693 ? Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- Chaos is King and Magic is loose in the world. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: unusual Alto Clef
On 09.10.2008 (18:07), David Bobroff wrote: I wondered the same thing. There is yet another style of C clef. I've seen this other style in French music. It is a more boxy style that is somewhere in-between the modern 'B' type C clef and the French style 'K' type. There is also another type of bass clef that I think of as English because it shows up in British works (Elgar for example). It spirals in the opposite direction of the normal bass clef that is used by LilyPond and it has more turns. Now that you mention it, isn't there also a G_8 type of clef with arms, almost like the C clef here? As for the hand-written look; this has been discussed in the past and, if I recall correctly, it was deemed inconsistent with the goals of LilyPond (to look like engraved music). So the hufnagel style should be eliminated, then... :) As for these different styles of glyphs; I think it would be cool to have them, but I don't need them. I suppose it is a matter of someone willing to either write the code for the alternate glyph(s) or pay someone to write the code. I'm thinking more or less the same -- with the addition that I'd gladly make a set of glyphs, if only I knew how... Eyolf -- (null cookie; hope that's ok) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
On 02.10.2008 (07:18), Werner LEMBERG wrote: Not only is texinfo the worst beast I've ever worked with, You are exaggerating. The LaTeX kernel stuff is worse IMHO. bibtex also comes to mind. But luckily, I've never had to work in any of those directly. Eyolf -- Why are we importing all these highbrow plays like `Amadeus'? I could have told you Mozart was a jerk for nothing. -- Ian Shoales ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: WANTED: Design for documentation (Photoshop power users!)
On 01.10.2008 (21:24), Werner LEMBERG wrote: The only possibility to customize the look of the PDF is to modify texinfo.tex. Ah, I see. Well, there *is* good news for Eyolf: any modifications he makes can be added to the official docs instantly. Mhmm. texinfo.tex is quite complex. Nothing for the fainthearted. I have noticed. Not only is texinfo the worst beast I've ever worked with, it's badly documented too, at least once one moves past the basics -- ironic, for a documentation format... And that texinfo.tex file... phew... I haven't given up yet, but... eyolf -- Marriage is the sole cause of divorce. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: What term do you use?
On 27.02.2008 (11:37), Anh Hai Trinh wrote: On Wed, 27 Feb 2008 10:04:35 -0500, Kieren MacMillan [EMAIL PROTECTED] wrote: Hi Eyolf, Or one might turn the argument around and say that the melody is indeed trans-posed -- placed somewhere else, whereas the negative associations of dis- is that it's ended up in the wrong place... Interesting point... Really, what we're talking about is a NOTATIONAL SHORTHAND: the notes in question aren't actually TRANSPOSED or DISPLACED, just like notes in a treble_8 clef are neither TRANSPOSED nor DISPLACED: they are simply NOTATED using a different (shorthand) method. I think you are mistaken here, a concert A written in any clef would sound with f = 440Hz, whereas a written concert A with a 8va bracket would sound with f = 880Hz. Anything sounding at a different interval than what is notated is called transposition in orchestration books. I believe the correct term, if there need be one, would be octave transposition. That's what I'd suggest too -- I failed to say so explicitly, but that was what I had in mind. So: +1 for octave transposition Eyolf -- The moss on the tree does not fear the talons of the hawk. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: What term do you use?
On 17.02.2008 (11:41), Valentin Villenave wrote: 2008/2/17, David Fedoruk [EMAIL PROTECTED]: Octave transposition seems a confusing, since transposition in music usually implies that the passage is to be played in a different key. Octave displacement does not change the key. Or one might turn the argument around and say that the melody is indeed trans-posed -- placed somewhere else, whereas the negative associations of dis- is that it's ended up in the wrong place... In Danish, Swedish, and Norwegian, it would be oktavering. Yes, I'd prefer to avoid transposition as well. In French, we say octaviation (notice the additional i, it got me confused more than once). Cheers, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- The more you complain, the longer God lets you live. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Volunteering with LilyPond
On 07.01.2008 (12:14), Bertalan Fodor (LilyPondTool) wrote: I don't find the \overrides very hard to understand; it's one of the very first thing I knew how to achieve in LilyPond (Bertalan's plugin LilyPondTool helped me a lot to understand it, though). Well, actually it was what made me start implementing the plugin: I also wanted to understand \override :-) \overrides in themselves are not so hard to understand, but in many cases, the scheme code that is needed in the construction seems more complicated than necessary for simple tasks -- it takes a lot of work, looking up things to get things right. Besides, once one draws in \set and \tweak along with \override, it's not so simple anymore... e -- Challenge: Time? Answer: A brilliant, many-faceted gem. Challenge: Time? Answer: A dark stone, reflecting no visible light. -- Fremen wisdom, from The Riddle Game ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Volunteering with LilyPond
On 06.01.2008 (09:51), Reilly wrote:
No offense to everyone who has worked on the documentation for Lilypond, but
the documentation is the weakest component of the package. The index often
lacks entries for my questions. The entries more often than not, do not
address my problems. The coded examples are often too clever and don't
illuminate my ignorance. Obviously everyone wants to make the documentation
equal to the programming. That is why the GDP is underway.
Hopefully, the GDP will be able to remedy some of this. As one of the
rewriters of the Notation Reference (in fact the *only*, AKA Mr Zero), I
can subscribe to some of the criticism. I don't know about the index -- I
hardly ever use it, perhaps for the reasons you mention -- but as for the
examples, it has been my guiding principle that if I don't understand an
example, down to the details of why does this setting do that, why does it
have to follow this syntax?, it needs to be rewritten. I've tested all the
examples I've been through so far according to that principle.
To some extent, this runs counter to another documentation principle which
I've reluctantly, very reluctantly come to accept, if not endorse: since
all the music examples are updated automatically with convert-ly if syntax
changes etc. are introduced in Lilypond, the explaining text should not be
too directly tied to the examples, since it will then require quite a lot
of extra effort to go over all the text that is NOT automatically updated,
and this is a constant risk of error. I don't like it, but I see the
rationale.
Suggestion:
Collect a team of Lilypond MUSIC Consultants. This could be the general
lilypond-user group or a subset. Volunteer members would agree to answer
questions. The GDP team should *not* spend time researching answers to
musical or notational questions IF they can find a local Lilypond user who
knows the answer. For instance, take the questions below:
Re. your
What is a fall?
What is a doit?
example, the problem is not so much knowing what it means -- that can be
looked up quite easily -- but to know (a) what kind of variations does a
user expect? does size matter? angle? are different symbols or styles in
use, and are they informative variations, etc.; (b) figure out how to
effect all these variations through Lilypond code; (c) choose how much of
this is really needed in the docs, and how much of it can be written
meaningfully without violating the don't comment the examples directly
principle.
Your suggestion of a group of music consultants is fine, and I intend to
try to distribute some responsibility along similar lines when we come to
the Specialist notation chapters (so that Graham would not have to write
the guitar section), but I fear that such a group would tend to become too
loose (volunteers come and go), and it would probably be too much of a
hit-and-miss thing -- can I expect to have a sax player in the group when I
write about doits? Maybe, maybe not. It is probably more practical if
people write in with concrete suggestions if something is missing, wrong,
or unclear in their particular field of expertise.
A general *alert* to the GDP team: music notation is NOT standardized.
We know that...
I am conflicted in
regard to notation. I want to keep the flexibility of Lilypond to tweak the
output to my needs. Yet, I want to introduce some consistency in output to
improve the quality of printed music for all the composers who don't want to
tweak their output. I think minimally this would require a number of style
sheet packages (like LaTeX packages) which (a) address all the issues
appropriate for the intended output (e.g. contemporary conducting score
style sheet; contemporary study score style sheet; contemporary condensed
score style sheet); and (b) at the same time, make the issues user
tweakable.
Yes, and as Graham pointed out in another thread, this is perfectly doable
-- it just takes someone to do it. I'd love to be able to write
\rehearsalmarks{alphabetic} or \setlenght{betweensystemspace}{2em} if
someone writes a package that includes it.
Eyolf
--
`...we might as well start with where your hand is now.'
Arthur said, `So which way do I go?'
`Down,' said Fenchurch, `on this occasion.'
He moved his hand.
`Down,' she said, `is in fact the other way.'
`Oh yes.'
- Arthur trying to discover which part of Fenchurch is wrong.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Volunteering with LilyPond
On 06.01.2008 (17:15), Valentin Villenave wrote:
2008/1/6, Eyolf Østrem [EMAIL PROTECTED]:
I'd love to be able to write
\rehearsalmarks{alphabetic} or \setlenght{betweensystemspace}{2em} if
someone writes a package that includes it.
What, you mean something like:
http://lsr.dsi.unimi.it/LSR/Item?id=368
Something like it, yes. Great to see the example. But I also had something
more general in mind: a set of macros to avoid any direct fiddling with
scheme altogether, sth. like LaTeX in relation to plain TeX. I really,
really hate things like Staff.VerticalAxisGroup #'minimum-Y-extent = #'(-8
. 4), and it shouldn't be necessary to write something like that for
something as common as adjusting the vertical spacing. OK, if you want to
slant your stems by 5 degrees, then it would be nice to have the option,
but all the \once \override and #'(stencil bla bla) stuff should be made
much easier.
If someone cares to do it, that is...
eyolf
--
Besides, REAL computers have a rename() system call.:-)
-- Larry Wall in [EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Volunteering with LilyPond
On 06.01.2008 (14:21), Reilly wrote: Eyolf, On Jan 6, 2008, at 12:00 PM, [EMAIL PROTECTED] wrote: Perhaps I misunderstand the purpose of Graham's example question. It's easy: the purpose of ALL of Graham's examples is that THIS TAKES RESOURCES and no matter how good the idea is, someone has to do it. :) It's annoying as hell, but he's right... In re your clarification re falls and doits above (a), yes, lots of variations, sometimes the length of the gliss indicates length of fall or doit. The fall/doit symbol is something like a musical font. I personally would not tweak this feature much, unless I hated the preset symbol. Thanks I think we disagree slightly on how my proposal would work (or, perhaps, how people behave). If I have to notate a classical guitar passage and I consult the Lilypond documentation and I find it inadequate, it is expecting a lot of my --- aka, the casual music engraver --- to rewrite the documentation and send it to somebody. (I don't even know to whom I would send it.) On the other hand, if I am a subscriber to a Lilypond Resource List and a specific question comes along to which I know the answer, I think I would be inclined to answer it. I do agree that from the documentation team's point of view it is more practical for volunteers to commit to rewrite sections of the manual. I was thinking more along the lines of: person A writes a lot of guitar scores, over the years (or months) he has aquired a good understanding of how the guitar-specific features of LP work, and he has also assembled a number of tweaks. He would be in a better position to rewrite those sections or come up with good/annoying questions than person B, who only writes polyrhytmic stuff for gamelan gongs. I was unclear about the somebody part. This list is a good candidate (although things tend to disappear in the bulk of messages here unless one has a good email client and working habits; I try to flag important messages, but I know I miss things); the docs meister is another -- once there is one again. ps: How would an English speaker pronounce your name? Eye-olph with the stress on the first syllable. Should be easy, but I have friends who still call me Eee-loph, even after almost a decade... Eyolf -- The Principal of Greenbow County Central Schools: Your momma sure does care 'bout your schoolin' son ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Leaving: I can't help
On 06.01.2008 (12:52), Graham Percival wrote: It's been about a month since an update from you. Ten days, to be exact :) Besides, did you _really_ want to be the only person working on the content? Of course not! I just reacted to the zero part. eyolf -- Who dat who say who dat when I say who dat? -- Hattie McDaniel ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
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-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Instrumental Group Names in Score
On 03.01.2008 (13:50), Kieren MacMillan wrote: Hi Graham, And you don't need explanations. I disagree! Me too. For the reasons Kieren gives, and - Do normal LaTeX users ever look at the details of packages? I do... but then again, I'm not normal. - the follow-up question: ARE there any normal users? Which in a Lilypond context also translates to: are there any normal user situations? OK, quite a few guitar scores have more or less the same basic requirements as compared to a piano score, but there are also almost always individual differences which would make it difficult to make a ly file comparable to a sty file which you can just include and use. Besides, the most useful LaTeX packages are the ones that are thoroughly documented, and in any case, I don't think I've ever used a sty file without issuing some \renewcommand or \setlength. Eyolf -- We can't schedule an orgy, it might be construed as fighting --Stanley Sutton ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tie across triplet boundary
On 29.12.2007 (23:17), Michael Nelson wrote:
Hi guys. I'm a new user of Lilypond. I'm notating an old (out of copyright)
edition of Bach's Invention 1. I was happy to get through the first 5 bars
with remarkably few problems. But I have hit a snag in bar 6. See the
snapshot of the original:
http://bayimg.com/CaIonAabj
In the last 6 notes in the treble stave there is a triplet with the last note
tied to the following b. I get an error because (I presume) the tie crosses
the triplet boundary. My failed attempt for those last 6 notes is:
No, you get it because you didn't place the tie mark ~ after the note that
should be tied, but after the bracket.
\times 2/3 { b32 c b } ~ b16 vs.
\times 2/3 { b32 c b ~ } b16
--
Today's robots are very primitive, capable of understanding only a few
simple instructions such as 'go left', 'go right', and 'build car'.
--John Sladek
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: macro for instrument changes
On 27.12.2007 (16:40), Stefan Thomas wrote:
Dear Lilypond-users,
I am sure there is an easy way to create a macro for the layout of
the two markup-commands in the below quoted example:
\relative c' {
c1^\markup {\bold \box Englischhorn }
c1^\markup {\bold \box Heckelphon } }
I would like to write something like
{ c1\change Englischhorn c1 \change Heckelphon }
How can I do it?
Thanks for Your support.
Stefan
Something like this?
EH = \markup {\bold \box Englischhorn }
HP = \markup {\bold \box Heckelphon }
\relative c' {
c1^\EH c1^\HP
}
--
What do Holy Accidents teach? Be resilient. Be strong.
Be ready for change, for the new. Gather many experiences
and judge them by the steadfast nature of our faith.
-- Tleilaxu Doctrine
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond for serial music?
On 30.11.2007 (11:24), Trevor Bača wrote: Hi Andrea and Miguel and Eyolf and everybody, The initial efforts were all implemented in C ... major or minor? :) So (lack of) robustness drove me away from C What's more robust than a C major chord? Sorry for joking -- thanks for your story. I must admit I don't do that kind of music, but I'm quite interested in the possibilities. Some day I'll look into it... Eyolf -- There are three possible parts to a date, of which at least two must be offered: entertainment, food, and affection. It is customary to begin a series of dates with a great deal of entertainment, a moderate amount of food, and the merest suggestion of affection. As the amount of affection increases, the entertainment can be reduced proportionately. When the affection IS the entertainment, we no longer call it dating. Under no circumstances can the food be omitted. -- Miss Manners' Guide to Excruciatingly Correct Behaviour ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hang --going backwards in time; insane spring
On 27.11.2007 (20:10), Trevor Bača wrote: Oh, Eyolf, what a gem. Thanks so much for the beautiful reference. My pleasure. Honestly -- if you knew how rarely it happens that people ask for these things... and then even enjoy the answer..! :) eyolf -- Time does not count itself. You have only to look at a circle and this is apparent. -- Leto II (The Tyrant) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hang --going backwards in time; insane spring
On 27.11.2007 (13:44), Trevor Bača wrote: I wish I knew enough about Medieval music (or Medieval music theory anyway) to know if the Medieval invetors of duplum and triplum and perfectus and imperfectus and the like ever touched on the topic ... they'd make a good source to steal from ... Oh, they did, they did... Not the medieval guys, but their early-renaissance followers, such as Franchino Gaffurio, who, as far as I remember, is the one who does the most thorough presentation of all the different alternatives: http://www.chmtl.indiana.edu/tml/15th/GAFPM4_TEXT.html The principle is an extension of the nomenclature of sesquialtera (3:2) and sesquitertia (4:3) etc., and particularly the names with -partiens and -particularis. As the complexities grow, so do the names: 30:7 is called Quadruplasuperbipartiensseptimas... sesqui-: numerator one higher than denominator subsesqui-: denom. one higher than num. superpartiens: num. contains den. plus a specified part of itself, e.g. supertripartiensquinta = 8:5, supersexcupartiensseptima=13:7, etc. subsuperpartiens: same as the former, only upside down: supersexcupartiensseptima=7:13 etc. Charming system, but not very practical... However ... (A good example is prolation ... which I *think* Ferneyhough borrows from prolatio ... though not sure ... and which makes a great cover term for tuplets and all forms of duration scaling in general.) True -- it is basically the same word as relation, which makes it a good generic term which still -- while not in general use -- retains some specificity. I'd go for prolations for all those odd meters. (No, really, I'd go for writing simple tunes in 4/4 :) Eyolf -- _-^--^=-_ _.-^^ -~_ _-- --_ ) | | \._ _./ ```--. . , ; .--''' | | | .-=|| | |=-. `-=#$%%$#=-' | ; :| _.,-#%[EMAIL PROTECTED]#~,._ ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hang --going backwards in time; insane spring
On 27.11.2007 (21:48), Eyolf Oestrem wrote: subsuperpartiens: same as the former, only upside down: supersexcupartiensseptima=7:13 That should of course have been SUBsupersexcupartiensseptima... how stupid of me... Eyolf -- No discipline is ever requisite to force attendance upon lectures which are really worth the attending. -- Adam Smith, The Wealth of Nations ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Lilypond for serial music?
The thread about strange meters made me wonder: have any of you lilypudlians used LP to write serial music? It would seem to be an ideal combination: make a variable and expose it to different output parameters. I assume that with some scheme code, a sequence of pitches could be translated into other series like rhythmic values, dynamics, etc., either through hard-coded permutations or generated from the series by way of some kind of algorithm. If anyone has experiences to share, I'd be interested in hearing about it. I can often say: It's not for me, it's for my son when I ask this kind of question at gaming sites etc. -- this time around it's for a colleague who writes serial-tonal music. I feel so sorry for him when he sits there, the night before the premiere, like a latter-day Mozart, and writes out all his permutations, when it could have been done by a simple lilypond weirdly.ly Eyolf -- You will be audited by the Internal Revenue Service. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \markup in manual volta endings
On 26.11.2007 (07:03), Risto Vääräniemi wrote: Another thing. The user manual section Manual repeat commands states that the repeatCommands accepts markup text. This does not seem to be valid as Paul Scott already pointed out. The statement is present also in the GDP. If the markup text doesn't work, please consider revising the document when you get there. Thanks, it has been noted. Eyolf -- Somewhere, just out of sight, the unicorns are gathering. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: once again with a header, tie into polyphony question
On 21.11.2007 (13:58), Rune Zedeler wrote:
Ole Schmidt skrev:
I want to have both of the first two notes tied -the d and the f-sharp. How
do I achieve
that?
Another possibility is to fake it by letting a stemless (i.e. transparent
stem) in one voice be merged with that of another: the head is still there,
and can therefore start a tie, but it appears as if the ties change from
one voice to another. Below is the first measure of Fernando Sor's Fantasie
elegiaque, which requires the notes of a grace-like arpeggio to be tied to
three different voices. It may not be the prettiest code in the world, but
at least it works
(BTW, I thought there was supposed to be something like
\override Staff.NoteCollision #'merge-differently-dotted = ##t
\override Staff.NoteCollision #'merge-differently-headed = ##t
in there, but apparently, it works)
\relative c' {
\key e\minor
\time 4/4
{
\set Staff.tieWaitForNote = ##t
\partial 64*5
\voiceOne \slurDown
a64\f fis' c'
\tieDown
dis64~ c'
\stemUp
dis, c'4..
\times 2/5 { b'32 a g fis e } dis8
}
\\
{
\voiceTwo
s64
\once \override Stem #'transparent = ##t
fis,64~
\noBeam \once \override Stem #'transparent = ##t
c'64*3~ fis, c'4..
}
\\
{
\voiceFour
\once \override Stem #'transparent = ##t
\tieDown
a,64*5 ~
\stemDown a2
}
}
Eyolf
--
Non-sequiturs make me eat lampshades.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Creating a nice formatted Chords + Lyrics layout for guitar players
On 19.11.2007 (00:16), Thomas Bonte wrote: I'm trying to create a nice Chords + Lyrics layout, formatted in the same way as you may see on the many websites offering ascii chords and lyrics. I seem to remember that this was discussed some time before -- you may search the list archive. What I wonder is: why do you want to use Lilypond to lay out something which is pure text? Why not just use LaTeX? There are some packages for this purpose, such as http://rath.ca/Misc/Songbook/ which seems pretty good. Or even html -- it's quite good at the job too. I say so with several years of experience with the chord sheet business. I run a website with Dylan chords (http://dylanchords.info), which has one extra feature which might interest you: a ruby program, Seal, which takes the html files as input and generates a book through LaTeX, nicely formatted and ensuring that pages are not broken between chord lines and the corresponding lyrics lines. You will find a link to Seal on the address above, and the full pdf file (3.4 Mb) on http://oestrem.com/tmp/mbpbook.pdf. The ruby script can -- with some work -- be tweaked to be applicable to other collections of html based chord sheets, as long as one uses the same css styles. Anyway this is probably making too much of it -- the LaTeX package is probably the better alternative -- I just wanted to point out the alternative. Eyolf -- Tibana was an apologist for Socratic Christianity, probably a native of IV Anbus who lived between the eight and ninth centuries before Corrino, likely in the second reign of Dalamak. Of his writings, only a portion survives from which this fragment is taken: The hearts of all men dwell in the same wilderness. -- from The Dunebuk of Irulan ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Creating a nice formatted Chords + Lyrics layout for guitar players
On 19.11.2007 (02:24), Thomas Bonte wrote: Hi eyolf, It is indeed already discussed before, but without proper results. The reason why we use lilypond is because I want to use the transpose functionality, in order to transpose several keys in one time using a little script. So, I don't consider this as pure text. You're right -- that might be a reason to use Lilypond. However, some of the other approaches do the same, only with much less hassle. I tried out chordpack (http://mujweb.cz/www/danielpolansky/chordpack/) which does transposition as well. GuitarTeX (http://guitartex.sourceforge.net/en/guitartex/book1.html) seems ok as well, but I haven't tried it out yet. e -- Oops, I always forget the purpose of competition is to divide people into winners and losers. -Hobbes being sarcastic ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dodgy dotted notes
On 17.11.2007 (01:27), Ossie Wilson wrote: I am using Version 2.8.6 on Windows 98. Clementi Sonata op.7 no.3 has some bars with dotted quaver followed by demi- semi-quavers and then other notes which can give bar lengths varying from the time sig by 1 to 2 demi-semi-quavers. Manual typesetting can handle this but LP ends up with bar-creep. Any suggestions how to print the notes in the correct places and still end up with no bar-creep. I take it that you mean that there are too many notes in the measure. You can either use \times to create a tuplet and then hide it with \once \override TupletNumber 'transparent = ##t or scale the durations with something like a4. b16*2/3 c16*2/3 b16*2/3 where the three 16ths will equal an 8th note. See the manual, chapters on Scaling durations and Tuplets. Eyolf -- Emperor Palpatine: Everything that has transpired has done so according to my design. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: keep separate pdf files?
On 15.11.2007 (07:34), Mats Bengtsson wrote: Graham Percival wrote: Since the GDP docs are spread over the LM, NR, AU, and snippets -- not to mention MG and IR -- what about making a tarball / zip which contained all these manuals, and removing the download links for individual PDFs? This would avoid problems with people downloading only the LM and discovering all the links which wouldn't work. True! On the other hand, downloading a ZIP requires somewhat more computer experience than just clicking on a link to a PDF file, so I'm not sure we should remove the current links. I agree. A separate tarball link, perhaps also with a brief explanation of why it is a a good idea to download it all, is good, but I would hate to have to take down the whole thing and then unzip every time I for some reason don't have the docs at hand but need to have the pdf. eyolf -- And I beheld another beast coming up out of the sand; and he had two horns like a lamb, but his mouth was fanged and fiery as the dragon and his body shimmered and burned with great heat while it did hiss like the serpent. -- Revised Orange Catholic Bible ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
On 14.11.2007 (16:18), Graham Percival wrote: I think we should have a consistent format for the NR; which one do people prefer? I have a slight preference against #2 (sentences everywhere), since IMO I know you have, and you know this is the one I prefer. Giving a hint at WHY one should seealso ain't fluff. This isn't dungeons and dragons (you are in a dark cave. To the east there is a link to Proportional notation, to the south is a snippet. etc). In other words ... in most cases it's obvious why somebody might want to look at other section. ... I'd say that in SOME cases it's obvious, but in many it's not, and if a general rule is needed, I'd go for 2 (with 3 as a variant). eyolf -- Law always chooses sides on the basis of enforcement power. Morality and legal niceties have little to do with it when the real question is: Who has the clout? -- Bene Gesserit Council Proceedings: Archives #XOX232 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: chattiness in @seealso
On 15.11.2007 (16:19), Graham Percival wrote:
At the very least, I want it clear which sentence refer to the Notation
Reference, and which sentences refer to the other parts of the docs.
Agreed.
... I _really_ think this is completely unnecessary, though. And if you
want to add full sentences to every single notation reference @ref{}, I
assume you want to do the same for every @lsr{dir,snippet}, every
@internalsref{}, etc ?
No, not really. My only concern -- since you asked for general principles
-- is that there shouldn't be a rule to preclude explanation where it is
desirable. This will be the case, I imagine, with references to some
complicated function in an altogether general section, or in other cases
where the reference in its barest form is less than obvious. In many cases,
I agree that an extra description will be fluff and should be avoided.
Mats, you're the yardstick for efficient NR use. What do you think of
the compact vs. full sentence form of @seealso ? I don't want to
approve any change that makes the NR harder to use for knowledgeable
users, and IMO this is one such change.
How do you define a knowledgeable user in this respect? One who is
knowledgeable in using the docs will know to look for links in the seealso
sections, and I can't see how it would make it more difficult to use it
with an extra pointer or two (like Remember to bring the towel from your
hotel room) -- and one as knowledgeable about LP as Mats probably won't
need those links in any case :)
sorry, the question wasn't for me, so I'll shut up.
Eyolf
--
Life, like beer, is merely borrowed.
-- Don Reed
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: the snippets vs. texinfo
On 09.11.2007 (21:02), Graham Percival wrote: OK, it's finally time for the big fight! In managing the docs, I need to weigh multiple contradictory demands. PDF vs. HTML: pdf readers generally prefer to have consecutive documentation, with few links. HTML readers generally prefer to have links everywhere. Slight correction: pdf readers do like links -- internal ones -- it's a Good Thing. Having unneccessary divisions into separate documents which then cannot be linked, is a Bad Thing. Stable docs vs. wiki: some people want an unchanging, complete, finished set of docs, particularly if they print them out. Other people like the constant flux of web 2.0 stuff. I agree completely with your position that there should be one stable, complete, fixed set of docs, and that a wiki solution is not good for a complex piece of software like LP. On the other hand, I see the numerous private LP-tips-and-tricks-pages as a result of this: a feeling something like: I have figured out some neat things but since the docs are stable, complete, fixed, there is no way in there, so I'll make my own page. This is fine, but for the user who is looking for that extra information, it means that he has to hunt around among disparate pages of varying quality, organization, and up-to-date-ness. This may not be an accurate description anymore: with the LSR as a well-established and semi-official entity, there is hardly any need for the private pages anymore. In other words: I think it's fine as it is now: a fixed documentation and an officially endorsed repo of user-contributed stuff. One might still discuss practicalities: should the LSR only be snippets, is snippets the right term (or does it give too much associations in the direction of trifles?), etc. but that is another discussion for another thread. Out of all of these concerns, I naturally feel that my own position is the most important. If anybody wants me to relax my we don't have the resources to do this position, please volunteer in GDP. If I have more resources, of course I'll accept more good doc ideas, As an aside: I did volunteer, but I still get the we don't have the resources reply. :-) Some PDF users may not be so fond of the snippets because they move material out of the main docs. I'd like to point out that the Snippets are available as PDF, so that might mitigate this concern. The pdf does not contain the LP code, so it is fairly useless, at least in its current state. My proposal, taking into consideration all the contradictory demands laid out at the top of this email, is to have one or two tweaks in the @commonprop. The main goal of @commonprop is to pique the interest of a reader, to encourage him to follow the Snippets: foo, bar links. Finally, the reason why I started writing this: is this really the purpose of @commonprops? Or phrased differently: given the lack of resources and the concern that the documentation files grow too big, is it really a good idea to fill it up with appetizers? What I want to say is: if what you're saying is that everything which is now in @commonprop is just appetizers, some of it could even be removed, and what remains will remain as appetizers, I disagree, but if you're saying that the @commonprops should be revised so that all that which is necessary to accomplish normal typesetting tasks, i.e. solve commonly encountered problems, or as Trevor recently wrote: to reproduce anything in a score found on their bookshelves, should be elevated to main documentation text whereas that which is more of the btw, you can also do THIS kind could be moved to the LSR, I do agree. In any case, the flow should go in both directions: important tweaks in the LSR should be moved into the docs (but I think we agree on that). On the whole: the NR should contain everything and nothing but that which is necessary for the score on the bookshelf test. Eyolf -- Several years ago, an international chess tournament was being held in a swank hotel in New York. Most of the major stars of the chess world were there, and after a grueling day of chess, the players and their entourages retired to the lobby of the hotel for a little refreshment. In the lobby, some players got into a heated argument about who was the brightest, the fastest, and the best chess player in the world. The argument got quite loud, as various players claimed that honor. At that point, a security guard in the lobby turned to another guard and commented, If there's anything I just can't stand, it's chess nuts boasting in an open foyer. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR Specification
On 08.11.2007 (15:44), Graham Percival wrote: Based on the recent discussions, what should change in the written policy? I'd say: the following sentence: However, they should be familiar with the material in the Learning Manual (particularly ``Fundamental Concepts''), so do not repeat that material in this book. Also, you should assume that users Fundamental concepts should be explained in the NR also, but in a different style than in the LM: in the NR in a precise, technical man page-like way, in the LM in a tutorial style. There should not be *information* in the LM which is not also available from the NR, it should just be presented differently. Eyolf -- Sometimes I indulge myself in safaris which no other being may take. I strike inward along the axis of my memories. Like a schoolchild reporting on a vacation trip, I take up my subject. Let it be . . . female intellectuals! I course backward into the ocean which is my ancestors. I am a great winged fish in the depths. The mouth of my awareness opens and I scoop them up! Sometimes... sometimes I hunt out specific persons recorded in our histories. What a private joy to relive the life of such a one while I mock the academic pretentions which supposedly formed a biography. -- The Stolen Journals ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: the snippets vs. texinfo
On 10.11.2007 (06:17), Graham Percival wrote: Eyolf Østrem wrote: Slight correction: pdf readers do like links -- internal ones -- it's a Good Thing. Having unneccessary divisions into separate documents which then cannot be linked, is a Bad Thing. Oh, was that your concern? Half of it. The other -- main -- half is searching. Furthermore, cross-document linking isn't as uncomplicated as you make it appear: as you say, the files must be in the same dir, and they have to exist in the first place (what if I use my own copy of the NR and for some reason haven't downloaded the PU?). On the other hand, I see the numerous private LP-tips-and-tricks-pages as a result of this: a feeling something like: I have figured out some neat things but since the docs are stable, complete, fixed, there is no way in there, so I'll make my own page. This is fine, but for the user who is looking for that extra information, it means that he has to hunt around among disparate pages of varying quality, organization, and up-to-date-ness. I would argue that this is _not_ fine, for precisely the reasons you state. Ideally, users should look for info in two places: - official docs (be it NR, IR, LM, etc) - LSR (which is massively promoted, and linked to, from the official docs) Agreed - that's what I meant too, and I think it's a great step when we have in fact got these two channels. At the time, i.e. before LSR was firmly established, it was fine, because there was no easy outlet for that kind of wiki-like contributions, but now the LSR should take care of that. As an aside: I did volunteer, but I still get the we don't have the resources reply. :-) The volunteer more. Eyolf, currently you are the *only* person working on Rewriting NR 1. The entire chapter needs to be done before the end of 2007. Well, if what you say below is the goal, that on the whole the docs should not change after the GDP, I'd say there is no need to rush it, especially if there are so few people to do the work. As for me, I have a daytime job too... Now do you see why I keep on saying we can't do X? :( Of course. As long as it doesn't turn into a We can't do X, so we won't even consider it, not even if it would make Y -- which we can and must do -- easier. But I'm not advocating featuritis. Finally, the reason why I started writing this: is this really the purpose of @commonprops? Well, that's the main question in this discussion. :-) My proposal -- only a *proposal* -- is to use it as appetizers. In any case, the flow should go in both directions: important tweaks in the LSR should be moved into the docs (but I think we agree on that). Important tweaks in LSR are moved into the docs by giving them a docs tag. but that will only include them in the snippet part of the docs, right? This may of course be enough in many cases, but there are some snippets which are central enough to merit inclusion in the main text as well. The snippet Adding an extra staff (http://lsr.dsi.unimi.it/LSR/Item?id=110) IMHO should be included directly, and Adding beams, slurs, ties, etc. (http://lsr.dsi.unimi.it/LSR/Item?id=321) is even *formulated* in a Documentation way, as an extension to what is already in there, rather than an additional piece of information. Those two could go almost straight in. eyolf (who will now stop spending time writing list mail and instead do some volunteer work...) -- Delay not, Caesar. Read it instantly. -- Shakespeare, Julius Caesar 3,1 Here is a letter, read it at your leisure. -- Shakespeare, Merchant of Venice 5,1 [Quoted in VMS Internals and Data Structures, V4.4, when referring to I/O system services.] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
User survey?
I was wondering: has there ever been a user survey for Lilypond users? What made me think about this is the current work on the documentation, but I suppose it might be interesting for other purposes too. - How many users are there? - how many of the users are only/primarily musicians, and how many are programmers who also write music? - How many use windows/mac/linux? - How do they use the docs? - Which parts of the docs are they most happy/dissatisfied with? - How many have ever used scheme code in their scores (beyond the simplest almost standard LP syntax like ##t)? - How many have written a scheme function themselves? - What kind of music do they write? which parts of LP are most used? - and which parts are most in need of extensions/simplifications? Things like this. I imagine it could be done as a running survey with a link from the front page, or something like that. Has this been done before? is there any interest in doing it now? Eyolf -- Darth Vader: The Force is strong with this one. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: renaming Program {usage, reference}
On 04.11.2007 (01:23), Graham Percival wrote: Eyolf Østrem wrote: Sorry - my fault, I was thinking of the Program Usage, which to a large extent has to do with how to write code to produce a certain output (the LP-book part) leaving bits and pieces which not necessarily belongs together with the notation reference thematically, but which on the other hand is so few pages, dealing with the fundamentals of how to run the program, that it seems logical to have it in one place. I don't follow -- especially the to a large extent. In the current version of lilypond-program.pdf, 12 out of 31 pages (not counting the licence and the index) are about lilypond-book -- that's what I meant with to a large extent. The rest is Installation and setup (8pp), command-line usage etc (7 pp), and the conversion utilities (3p). In the newly-renamed Application Usage, is there anything other than chapter 4 which you believe should be in NR? I really can't see anything of the sort. No, only ch. 4 belongs in a Notation Ref., strictly speaking (even this is debatable, depending on HOW strictly one is speaking). I'm thinking more of the NR as the document that one would want to save to the harddisk, or even print out as a handy reference to cover all the things that one would need to know in the day-to-day dealings with LP. Given the character of LP, as a compiler of external text files, and not a gui or a wysiwyg environment, text input and compilation will always go hand in hand. This is the reason why I'd like to have ch. 3 in the same book (on my imaginary shelf, together with the vim manual and the LaTeX companion). This would leave the three pages about conversion, which don't necessarily belong in the same book, but which doesn't do any harm either. 2.2. Text editor support could well defend its place in a notational referece: how to edit LP code, which leaves 1 Install, which is more README or man page-like, and setup, which is mainly about mac problems... In other words: if it is a strong editorial decision that there should be one document which contains only the details about notational syntax and nothing else, then my suggestion of course falls flat. The document I'm talking about is broader: Everything You Need To Know To Produce A Score With Lilypond (Once It's Installed And Provided You Don't Need To Change Too Many Scheme Lists). Eyolf -- All hope abandon, ye who enter here! -- Dante Alighieri ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: renaming Program {usage, reference}
On 03.11.2007 (12:43), Valentin Villenave wrote: 2007/11/3, [EMAIL PROTECTED] [EMAIL PROTECTED]: Quoting Graham Percival [EMAIL PROTECTED]: Does anybody object if I rename Program Reference to Internals Reference? or maybe Tweak Reference? or... ? (renaming Program Usage is also an option) ... or merging it with Notation Reference, where it belongs :-) Not at all! The notation Reference is here to help users produce scores using predefined commands and interface, whereas the Internals Reference describes the way LilyPond *internally* works, to possibly allow them to change the interface itself. Sorry - my fault, I was thinking of the Program Usage, which to a large extent has to do with how to write code to produce a certain output (the LP-book part) leaving bits and pieces which not necessarily belongs together with the notation reference thematically, but which on the other hand is so few pages, dealing with the fundamentals of how to run the program, that it seems logical to have it in one place. e -- user-friendly adj. Programmer-hostile. Generally used by hackers in a critical tone, to describe systems that hold the user's hand so obsessively that they make it painful for the more experienced and knowledgeable to get any work done. See menuitis, drool-proof paper, user-obsequious. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: typeset lyrics
On 02.11.2007 (16:26), Wilbert Berendsen wrote:
Op vrijdag 2 november 2007, schreef Ole Schmidt:
There is also the { } \\ { } model for polyphony, when to use
which construction?
The short answer is that this is used for single-staff polyphony, but since
giving a short answer is cheating, I won't reveal it until you have read
the manual :-)
Another point are the rules of the \relative mode when you have
polyphony/chord constructions (how to use , and ' properly)
See:
http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Relative-octaves
Or rather the address that Mats gave, which is in the development manual,
but which concerning this particular section applies to any version of
Lilypond.
Eyolf
--
The modern child will answer you back before you've said anything.
-- Laurence J. Peter
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Great documentation was: Re: typeset lyrics
On 02.11.2007 (11:05), Paul Scott wrote: I haven't needed to look at the tutorial in a while. This is great!! Thanks to everyone improving the documentation!!! there's always room for one more to look at it, if you discover that your new enthusiasm becomes too overwhelming :) Eyolf -- Robustness, adj.: Never having to say you're sorry. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Beginner question
On 31.10.2007 (18:45), Jocke wrote:
Aha, there should be a space there, okay. :-) Thanks! But one more thing.
That underscore thing in the notation thing, I want it to be shorter. It
streches so long to other notes. For example, in this code, the underscore
between the word och streches to E. I just want it to stretch to under the
second A there.
First of all: notes that are tied together count as one syllable.
Second: the extender should stretch for as many syllables as you
specify, i.e. with single underscores separated by spaces after a
syllable: ba -- ch __ _ _ _ would have an extender stretching under
four syllables. In Jo -- hann __ Se -- ba -- sti -- an the extender
will stretch for as long as that syllable lasts -- in your case, that
would mean over the two tied notes.
However, as you note, it goes one note further, which looks odd. In
this case, the reason for this behaviour seems to be that this is the
last syllable in your lyrics. The docs state that the extender goes
between a syllable and the next one. This does seem to be a minor bug,
though, which may not be of practical consequence, since the case in
your example is probably very rare in practice, but if it's a bug, it
should nevertheless be looked into.
Thirdly: there is a way around this, if you desperately want the
lyrics to end with an extender while there is still music left: use a
phrasing slur a\( a\) instead of the tie a ~ a. That way, the
notes will be counted as two syllables, and when the extender
stretches too far it will still stretch only as far as you want it.
Lastly: watch your mouth; your lyrics aren't exactly appropriate for
such a splendid piece of software, are they ;-)
\version 2.10.33
\score {
\relative c'' {
\key g \major
| a4 ~ a b2 | a4 ~ a e c
| e4 c e f | e4 e8[ c] b2 \bar |: \break
| a'4 b ces bis | a4 b8[ a] f2
| e4 c e f | e4 e8[ c] b2 \break
| a'4 a b2 | a4 a b2
| d,4 e b'8[ a] f4 | e1 \bar |.
}
\addlyrics {
ba -- js och __
}
\addlyrics {
bajs två tre f -- e -- s
}
\layout { }
\midi {}
}
%%% Local Variables:
%%% coding: utf-8
%%% End:
--
View this message in context:
http://www.nabble.com/Beginner-question-tf4728652.html#a13522183
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
C-3PO:
I do believe they think I am some kind of god.
Han Solo:
Well, why don't you use your divine influence and
get us out of this?
C-3PO:
I beg your pardon General Solo, but that just
wouldn't be proper.
Han Solo:
Proper???
C-3PO:
It's against my programming to impersonate a deity.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: ties
On 28.10.2007 (02:39), Graham Percival wrote: Should ties go in Rhythms or Expressive marks? Pros of 1.3.2 Curves - it makes a nice progression from ties, slurs, phrasing slurs - beginners are more likely to look for ties in here Pros of 1.2.1 Writing rhythms - ties really do effect the duration of a note, rather than providing expressive notation - beginners should have already read the tutorial, and will therefore know the difference between ties and slurs. If they haven't read the tutorial, we officially Do Not Care (tm) about them, so that negates the advantages of Expressive marks. I think I'd go for curves, for the reasons given above, but I'm not sure. Ties certainly are NOT expressive marks... So if the approach is that a user is supposed to sit down with the ToC and logically maneuvre through the headings, it should probably be under rhythms. I'd probably just search for Ties in the pdf file, so in that sense, it doesn't matter that much, as long as there is a link from one place to the other. eyolf -- This Fremen religious adaptation, then, is the source of what we now recognize as The Pillars of the Universe, whose Qizara Tafwid are among us all with signs and proofs and prophecy. They bring us the Arrakeen mystical fusion whose profound beauty is typified by the stirring music built on the old forms, but stamped with the new awakening. Who has not heard and been deeply moved by The Old Man's Hymn? I drove my feet through a desert Whose mirage fluttered like a host. Voracious for glory, greedy for danger, I roamed the horizons of al-Kulab, Watching time level mountains In its search and its hunger for me. And I saw the sparrows swiftly approach, Bolder than the onrushing wolf. They spread in the tree of my youth. I heard the flock in my branches And was caught on their beaks and claws! -- from Arrakis Awakening by the Princess Irulan ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: troubles with time change
On 24.10.2007 (10:33), Herbert Liechti wrote: Hello all I'm in troubles with a time change from 4/4 to 2/4. d8. c16 ~ c8 a r2| \time 2/4 r2 \time 4/4 | The compiler always complains: sample.ly:29:32: warning: barcheck failed at: 1/2 d8. c16 ~ c8 a r2 It complains because you have a different number of full measures in the two voices: eight full 4/4 measures after the repeat in the tuba part, and seven in the chords part. Thus, the time change that you have indicated in the chords, fall in the middle of the last full tuba measure. BTw, you don't have to indicate time changes in both parts; unless you specify differently, a change in one will apply to the whole score. Eyolf -- Emotional Ketchup Burst: The bottling up of opinions and emotions inside oneself so that they explosively burst forth all at once, shocking and confusing employers and friends -- most of whom thought things were fine. -- Douglas Coupland, Generation X: Tales for an Accelerated Culture ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: time signature
On 24.10.2007 (10:25), andrew wood wrote: Usin the time command \time 4/4 as recommended in you documentation, I do not get the results I am after. What else should I do to make it work? That depends on what you want to do. A little more information, please. Eyolf -- The onset and the waning of love make themselves felt in the uneasiness experienced at being alone together. -- Jean de la Bruyere ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: pitches second draft
On 22.10.2007 (11:56), Trevor Daniels wrote:
I see the note on the lowest staff has now been changed to a
C, but this is the bass C, not middle C.
Arrghh. Corrected in next update. Thanks.
eyolf
GDP helper and typo-(ir)responsible
--
_/I\_o__o___/I\ l * //_/ * __ ' .* l
I_l__l___I\ l *// _l__l_ . *. l
[__][__][(**)__][__](**)[__][] \l l-\ ---//---*(oo)--l
[][__][__(**)][__][_(**)_][__] l l \\ // -()-/ l
[__][__][_ll[__][__][ll][__][] l l \\)) .__.(..) .@@@:::l
[][__][__]l .l_][__][__] .l__][__] l l ll _(o_o)_(@*_*@ l
[__][__][/ _)[__][__]/ _)][__][] l l ll ( / \ ) / / / ) l
[][__][ /..,/][__][__][/..,/_][__][__] l l / \\ _\ \_ / _\_\ l
[__][__(__/][__][__][_(__/_][__][__][] l l__l
[__][__]] l , , . [__][__][] l
[][__][_] l . i. '/ , [][__][__] l/\**/\ season's
[__][__]] l O .\ / /, O[__][__][] l ( o_o )_) greetings
_[][__][_] l__l==='=l[][__][__] l___,(u u ,),__
[__][__]]/ /l\---/l\ [__][__][]/ {}{}{}{}{}{}R
In Ellen's house it is warm and toasty while fuzzies play in the snow outside.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: where do we discuss MIDI?
On 18.10.2007 (23:45), Graham Percival wrote: There are two options to this: No, there's only one: 1) Gather everything about MIDI into one section (currently 4.3) and mention everything there :-) -- He who lives without folly is less wise than he believes. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Church Rests
On 19.10.2007 (16:24), Francisco Vila wrote: 2007/10/19, Trevor Daniels [EMAIL PROTECTED]: In the section on multi-measure rests the manual talks about church rests, meaning the use of increasing numbers of little rectangles to indicate how many measures are included in the multi-measure rest. In this a generally accepted musical term, or one invented for lily? They are completely usual in orchestral parts since I can remember. The signs, yes (they go back to mensural notation in the fourteenth century), but the name? I've never heard it before, and Grove doesn't mention it... eyolf -- Creditor, n.: A man who has a better memory than a debtor. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: introducing examples
On 19.10.2007 (16:38), Francisco Vila wrote: 2007/10/19, Hans Aberg [EMAIL PROTECTED]: So how do you find the LSR?... You have the link into the main documentaion page http://lilypond.org/web/documentation and it links to http://lsr.dsi.unimi.it/ ... and in the final GDP, there will be so many LSR links that you're going to moan: Oh, please, Graham -- not another LSR snippet, I can't take it anymore! :-) you'll find it, rest assured. eyolf -- Insults are effective only where emotion is present. -- Spock, Who Mourns for Adonais? stardate 3468.1 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Offsetting a turn horizontally
On 08.10.2007 (17:04), Mats Bengtsson wrote:
Quoting Joseph Wakeling [EMAIL PROTECTED]:
Reinhold Kainhofer wrote:
It doesn't work absolutely perfectly because the skips do not contribute
to the musical spacing---you can see the difference if instead of s4 you
write e.g. d4. Is there an option to make skips count towards the
layout?
Exactly what do you mean. The spacing should be the same as if the turn
was appeared over a true note at the same position in the bar. Try
replacing
the s by a pitch to see this.
Isn't that what the OP said? A quick test here also confirms that it
is true: replacing one or both s-s with pitches, changes the spacing
the spacing is different with s than with a pitch.
In fact,
{d4 d4\turn}
{s4 s4\turn}
{s4 d4\turn}
{d4 s4\turn}
in the original example give four different spacings.
--
kernel, n.:
A part of an operating system that preserves the medieval
traditions of sorcery and black art.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: pitches rewrite
On 04.10.2007 (19:09), Graham Percival wrote: First-come, first-serve. Let us know if you claim a task, so that nobody else starts working on the same thing. Files in the normal places. I'll have a look at it. eyolf -- Luke blows up his first TIE fighter. Luke Skywalker: Got 'im! I got 'im! Han Solo: Great, kid! Don't get cocky! ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: pitches rewrite
On 05.10.2007 (11:35), Graham Percival wrote: Eyolf Østrem wrote: I'll have a look at it. Great! The whole thing, or just certain items on the list? We can split the tasks up, and I'd rather have Pitches done sooner rather than later. More people working on the chapter at once will get it finished faster, as long as everybody just works on the specific tasks they signed up for. From your former list, I've done the formatting part, and made a suggestion for the f/fis warning thing. If someone else wants to work on any of the rewrite parts, that's fine with me. I'll be doing some more on it later this evening, but I'm not sure exactly when I'll have a file ready to send. Asap, though. e -- For a moment, nothing happened. Then, after a second or so, nothing continued to happen. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond-book -- almost there... round III
On 04.10.2007 (16:19), Graham Percival wrote:
Eyolf Østrem wrote:
I made a last attempt, with minimal files included, which look like
this:
I'm now going to commit the sin of jumping into a long discussion without
having read the intermediate steps (with GDP going on, I've been pretty
much ignoring -user), so please ignore if this is totally off-base...
playground/book.tex:
\documentclass{article}
\begin{document}
\include{out/lpb-file}
\end{document}
playground/lpb-file.lytex:
\lilypondfile{music.ly}
... why? Just not stick
\lilypnodfile{out/music.ly
in your main book.tex? That's what I do. Call it book.lytex, run it
through lilypond-book, then run the generated .tex through texinfo. Or
pdflatex.
I'll look into that, but I think -- to the extent that I'm able to, at
these hours -- that the answer is that in real life, the included file
does not just contain the ly-file, but is a full chapter of its own,
so it needs to be kept in a separate file altogether. I think...
This example was just to make it as minimal as possible. So while your
solution is certainly a workaround which works to some extent, it also
shows that the output=out thing has its limits.
But thanks for your input (or should that be include...? :-)
Now, is this how it's supposed to be, or is there a way to work around
this? As I said, I'm happy to keep all the output files in the main
folder -- now it's become almost a matter of principle: I want to find
out if I've overlooked something...
This is related to a current bug (or enhancement request) about \includes
in pure lilypond files. All the filenames are relative to the first file
called, not the first file. Err, the bug summary has a better summary
than this.
I understand. I hope it will be fixed.
Eyolf
--
The one-eyed view of our universe says you must not look far afield for
problems. Such problems may never arrive. Instead, tend to the wolf within
your fences. The packs ranging outside may not even exist.
-- The Azhar Book; Shamra I:4
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: new display for warnings
On 03.10.2007 (17:07), Graham Percival wrote: Hi guys, What do you think of the new warnings in the manual? In the Learning Manual, see 2.1.1 Compiling a file 2.3.1 Music expressions explained I definitely like it. I'm not sure about the word Warning, though... makes it sound dangerous... In Norwegian I would have used NB -- I don't know how that would work? e -- This is your fortune. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Elision/lyric tie again
One more thing about the elision/lyric tie, which I discovered today: I generated eps files from two different but structurally identical files, in the same batch process, and one ended up at 100 kb, the other at 1.2 Mb. I couldn't understand why, but eventually, I realized that there was an elision tie in the big file. I understand that the sign is not part of LPs own font and that it is taken from some other font available on the system, but it seems a huge difference just for one sign. It may not be something that everyone uses all the time, but I do, and I'd very much like to see a better solution to this. Another thing is that the sign as it now is -- at least as it is generated on my system -- is way too wide. Common practice is that it looks more like a semi-circle than a musical tie, and it goes *between* the syllables, not *under* them. Consider this a request and a sponsorship offer for a better elision mechanism. Eyolf -- * lilo hereby declares OPN a virtual pain in the ass :) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pitches rewrite draft
On 01.10.2007 (13:12), Graham Percival wrote: Trevor Daniels wrote: Graham wrote: - move Micro tones into Accidentals. No, too specialist. Should it be moved into Specialist notation? Wherever it is it needs a link to Other languages. I disagree with this, although I admit that I can't come up with a good reason. One of the things I was trying to do was to make the new doc sections a complete reference for each item. So Pitches would include everything about pitches, expressive marks would include everything about that, etc. Here's where my reasoning falls down: I admit that this doesn't work with Ancient music. Pitches-displaying-clefs doesn't include ancient music clefs, for example. This should be solved through a cross-ref. I think the reason that you say you can't come up with, has to do with the question Where would a user be most likely to go looking for it? In the case of ancient music, it would be counter-intuitive and -productive to strictly follow any technical-analytical distinction, since the ancient music features come as a package: you would rarely write an ordinary score and then use a petrucci-g clef, e.g. (whereas Modern music is more about adding bits and pieces to standard notation, hence it is justified to put the bits and pieces where they belong, technically). I'm still confident that the manual should be split up this way, but I can't point to a general principle to back me up on this. :|(other than our ancient music support is a bit old, no pun intended, so I'd rather hide it at the back of the manual) I'm looking forward to taking part in the upcoming revision of the Ancient section :-) Eyolf -- Why do so many foods come packaged in plastic? It's quite uncanny. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: guitar chords
On 02.10.2007 (09:57), Zoltan Kota wrote:
Hi,
I'm newbie here. I have just started to learn lilypond. It looks very nice
(altough it needs some time to learn syntax, commands and tricks). :-)
Is it possible to add guitar chords above a staff (accompanying guitar
chords for a vocal)? Like Em, D, C, H, etc. I have played with \chords,
\chordmode, ChordNames, but I'm not sure I'm doing the right thing:
You're making it too complicated. Try to add the following:
versechords = \chords { e2:m d4 c2. } %etc,
and replace your current score section with the following:
\score {
\versechords
\context ChoirStaff
\context Voice = sop \Soprano
\new Lyrics \lyricsto sop \soptext
\context Voice = ooo \Chor
\new Lyrics \lyricsto ooo \chortext
}
Also, in the ooo section, you could replace Oo- with Oo __ (two
underscores), that will produce nice extenders under the whole chord
passage.
I couldn't add H4 (B4) for example.
b:sus4 is probably what you're after.
Eyolf
--
BOFH excuse #256:
You need to install an RTFM interface.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Lilypond-book -- almost there...
I've been struggling to get lilypond-book do what I want it to do, and
I think I'm almost there. Now, I have working output, my question is
if there is a better way to work to get there.
I want to include files with lp-examples in chapters that I \include
in a main LaTeX document, fullbook.tex, something like this:
\documentclass[a4paper]{memoir}
\begin{document}
\include{ch1}
\include{ch2}
\include{lp-examples}
\end{document}
How I finally made it work, was to have a file lp-examples.lytex
containing sth like the following:
\chapter{appendix}
\section{1 Gioia et amore}
This is a song.
\lilypondfile{graphics/01-gioia-et-amore.ly}
which I first process through lilypond-book. This gives a file
lp-examples.tex, which is then processed nicely when I do latex
fullbook.
1. Is this the recommended way to work?
2. Is there a way to automatize the process? E.g. in Kile, vim, or
-- god forbid -- emacs/auctex?
Eyolf
--
I already have too much problem with people thinking the efficiency of
a perl construct is related to its length. On the other hand, I'm
perfectly capable of changing my mind next week... :-) --lwall
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pitches rewrite draft
On 01.10.2007 (16:16), Trevor Daniels wrote: Some comments on Pitches - move Micro tones into Accidentals. No, too specialist. Should it be moved into Specialist notation? Wherever it is it needs a link to Other languages. I say yes, in accordance with the general principle that everything that belongs together, should be together, no matter how advanced or basic it is. Also, the specialist notation section is for specialized areas of use (guitar, piano, ancient, etc) rather than very advanced features that only 20th-c. music freaks will ever need :-) BTW, I've been thinking about that title... I was trying to find the section on vocal music, which ought to be easy enough, but it took me a while to find it there, even though I knew it was there. I didn't think of it as specialist in any way. I think specialized notation would make it a little better, but I'm not sure. -- Han Solo: You said you wanted to be around when I made a mistake, well, this could be it, sweetheart. Princess Leia: I take it back. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Canorus 0.4 released
On 30.09.2007 (23:41), Matevž Jekovec wrote: - Document recovery, if Canorus crashes. ... which it does. I've compiled and installed it, but I always get segfaults with this message: (eval): [BUG] Segmentation fault ruby 1.8.6 (2007-09-23) [i686-linux] zsh: abort canorus In fact, I don't even get a first window, and none of the buttons work, nothing. But when I try to import a midi file, e.g., or open a new view, it segfaults. Eyolf ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- But, for my own part, it was Greek to me. -- William Shakespeare, Julius Caesar ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: add extender line to the glossary?
On 29.09.2007 (13:08), Till Rettig wrote: Graham Percival wrote: Should we add extender line to the glossary? Is this a real musical term, or a made-up lilypond term? Any vocalists want to comment? Another word that should perhaps be there, is elision (with whatever second word is correct -- mark, slur, tie, bow, line?), i.e. the small bow used to tie together syllables from different words that still belong to the same note, most frequent in italian music. e ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- University politics are vicious precisely because the stakes are so small. -- C. P. Snow ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplets
On 9/26/07, Kieren MacMillan [EMAIL PROTECTED] wrote: Hello all, It's not nearly as slick as tuplet... but how about rhythmic ratios? The phrase sums up almost precisely what it represents, and would be (I imagine) VERY easily translated. I think it's good -- only reservation is whether it is also intuitive, in both directions: will people know what it means when they see it, and will they consider looking under that heading for answers about sextuplets? On 26.09.2007 (15:20), Trevor Bača wrote (about irrational rhythm): So, there's that. It's available. And although I don't personally like it because I think it's counter-descriptive, it will at least translate readily to those languages that simply cannot backform something like tuplet. I don't like it either. In any way. It may be that musicians would find 17/11 an irrational rhythm, but what about a triplet, which would also be an irrational rhythm? But thanks for bringing it up :-) FWIW, I would *much* prefer tuplet in our English docs; I would only propose irrational rhythm where the translators are coming up empty in the other languages. FWIW (2), neither Grove nor Merriam-Webster have an entry on tuplet at all. Nor do any of the other dictionaries or lexica I've checked. That, if anything, for me is the strongest and perhaps only argument against it: it doesn't seem to be an established term, other than in the fairly small group of people who have once used Finale; and even there it (a) invites a certain confusion with duplets, and (b) carries connotations by assonance with the mathematical term tuple. My gut reaction is that I dislike the term, even though I acknowledge that it may be useful. http://www.musictheory.halifax.ns.ca/19triplets.html has the heading: Triplets and other tuplets, and quotes the Concise Oxford dict. of music, which uses the term irregular combinations [of notes]. Hm Eyolf -- Ahead warp factor one, Mr. Sulu. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP - Learning Manuall Songs section
On 26.09.2007 (17:41), Graham Percival wrote: Trevor Daniels wrote: This is rather short at present, and I would like to extend it. The question is, by how much. I'd welcome your views on the suggestions below. In particular, is this too long? Does this cover too many/too few topics? I've been thinking about the Tutorial vs. the rest of the Learning Manual, and I think I finally have a good answer: the Tutorial should cover just enough material to allow people to write simple pieces using the Templates. Can I come in here with a small request? I agree that the Tutorial should be limited to what you say, but concerning the templates, I don't think it should be limited to just being able to copy a template and filling in the dotted lines. It would be much more useful if the templates were lavishly commented (following the principle give a man a fish vs. teach him to steal cattle). I know this is a question of time, but I also know that I would have progressed more quickly from quite confused, making lots of mistakes, to having a vague idea why this works and finally heureka! if every non-trivial step had been explained. I've actually started on something like that, and I'll be happy to contribute eventually. Eyolf ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplets (was: GDP for kids :)
2007/9/21, Trevor Bača [EMAIL PROTECTED]: Yeah, I may be spreading unsubstantiated rumours here, but the term seems definitely to have shown up first in English (rather than FR or DE) and I *think* it actually originated in an early version of the Finale user manual (God help us). I've never been able to verify this last bit, but, if true, it would at least explain why the word doesn't seem to exist in any EN dictionaries yet. Does this mean that we should consider not using the word? Not that I have anything against Finale (hehe :-), but do we have to copy their strange nomenclature? The question is, I suppose: - is it a good term (perhaps it is; are there any alternatives for a cover-all term for -- eh, for tuplets...?) - is the term so well-established in note-typesetting circles that it would be strange not to use it, even if the answer to the first question is no? Personally, I thought it was a strange term when I first came across it -- yes, in the Finale manual -- especially since 90% of all tuplets are TRIplets, but on the other hand, once one gets used to it, it is a handy term. Just wondering. Eyolf -- It is commonly reported, my dear Georad, that there exists great natural virtue in the melange experience. Perhaps this is true. There remain within me, however, profound doubts that every use of melange always brings virtue. Me seems that certain persons have corrupted the use of melange in defiance of God. In the words of the Ecumenon, they have disfigured the soul. They skim the surface of melange and believe thereby to attain grace.: They deride their fellows, do great harm to godliness, and they distort the meaning of this abundant gift maliciously, surely a mutilation beyond the power of man to restore. To be truly at one with the virtue of the spice, uncorrupted in all ways, full of goodly honor, a man must permit his deeds and his words to agree. When your actions describe a system of evil consequences, you should be judged by those consequences and not by your explanations. It is thus that we should judge Muad'Dib. -- The Pedant Heresy ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partial rearrangement done, technical problems
On 22.09.2007 (11:09), Trevor Daniels wrote: Going off to make a cup of coffee I asked my wife what she would suggest. She said instantly, Specialist topics or Topics for Specialists. I could add Specialist Notation or Notation for Specialists. Any of these any good? I prefer the last one. I think your wife is a genius. I like it. I prefer Specialist notation because one doesn't have to be a specialist to need 'specialist notation'. Great idea. Case closed, as far as I'm concerned. Eyolf -- At the end of the money I always have some month left. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: welcome, helpers!
On 22.09.2007 (18:08), Graham Percival wrote: Great! We have our first claim; Michael Rasmussen is doing Pitches. I'll have a look at simultaneous, then. eyolf -- Good men are like Martians, you hear a lot about them but you never actually see one. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: partial rearrangement done, technical problems
On 20.09.2007 (00:55), Graham Percival wrote: GENERAL DISCUSSION - I still like the division of musical notation / instrument-specific? No? I have nothing against it, as long as vocal music isn't stuffed in there. :-) - Assuming that the technical issues are solved, how do you want these merged subsections to look? Specifically, consider 1.2.3. Displaying rhythms. There's Time signature - @commonprop - @seealso - @refbugs Upbeats - @refbugs Unmetered music - @refbugs ... Automatic note splitting - @refbugs - @seealso Do you like this format, or would you prefer one @commonprop at the end of each page? I think it should be next to where the properties that are commonly tweaked are described. That particular section reminded me of something that's been bugging me before: Lilypond has many defaults, which is fine, but somehting like: Setting it to #'() uses fraction style for 4/4 and 2/2 time, just makes me wonder: why!?! This is one of those cases where the middle ground is missing between the beginner (who would take it as a piece of information and that's that) and the programmer (who would know how to look up the program reference. Do you want links to LSR stuff at the end of each portion, or just one set of links at the bottom of the page? I don't mind. ... and are you guys _sure_ you prefer the manual like this? Other than that I still don't like the headings Displaying ... Thanks to the defaults, you are, for all intents and purposes, displaying a rhythm by writing c8, aren't you? For some of the topics something like Modifying the display/presentation... might work, but I'd like to see the reader who would go to a heading like that to find out how to write a key signature. Eyolf -- Q: How many mathematicians does it take to screw in a light bulb? A: One. He gives it to six Californians, thereby reducing the problem to the earlier joke. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: six
On 14.09.2007 (08:23), Graham Percival wrote: http://lilypondwiki.tuxfamily.org/index.php?title=Doc * 1 Notation Reference o 1.1 Pitches I don't like the sectioning of this one. Why is Transpose and Instrument transpositions split up? It doesn't make sense to me. Ottava brackets should also belong here somewhere. Also, Changing multiple pitches -- it sounds precise, but it isn't necessarily so. At least it sounds unnecessarily complex Join Note names in other languages with Writing pitches - that's where it belongs. That leaves Clef and Key signature, which might come first -- since it's fairly fundamental -- or last, since it falls a little on the side of the other items. Thus: o 1.1 Pitches + Clef + Key signature + Normal pitches + Note names in other languages + Accidentals + Cautionary accidentals + Micro tones + Relative octaves/Octave check + Transpositions + Ottava brackets o 1.4 Repeats + Repeats and MIDI I wonder: isn't it more natural to gather the midi stuff in one place and just have a cross reference here? After all, the page looks the same regardless of what the midi output sounds like; the person who is likely to need this information, will have trouble with his midi file and will be looking for it in the midi section, not primarily under repeats. At least I would. I did. o 1.7 Educational use (or increasing readibility ?) I don't like this one, I must say. Neither font size, improvisation, or shape notes or fingering have much to do with educational use in my book. I think font size should go in a page layout section or something (at least that's how I use it, but I can also see how it would fit here). The sections are ok, I guess, but please don't call it all educational use... How about Appearance Tweaks or something? o 1.15 Ancient notation I have no problem with this section -- and it is my area. Eyolf -- Brandy-and-water spoils two good things. -- Charles Lamb ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: six
On 14.09.2007 (13:10), Graham Percival wrote:
Eyolf Østrem wrote:
I don't like the sectioning of this one. Why is Transpose and
Instrument transpositions split up? It doesn't make sense to me.
Ottava brackets should also belong here somewhere.
Instrument transpositions affects how pitches are displayed in cues and on
midi. Ottava displays how pitches are displayed.
Transpose affects the actual _pitches_. Remember our distinction between
content and presentation.
{ fis''' }
is that note, regardless of instrument transpositions or ottava. If we
stick \transpose, then fis''' will produce a different pitch.
Yes, but where are people going to be looking for it? Better to have
it under the same heading and explain that distinction there, instead
of having them scurrying from place to place between technically
distinct but conceptually related items.
Also, Changing multiple pitches -- it sounds precise, but it isn't
necessarily so. At least it sounds unnecessarily complex
I'm not wild about that name; please suggest an alternative.
My suggestion is (a) to let go of that level of sectioning, or (b) if
that isn't viable, call that section octaves and transposition or
something.
Join Note names in other languages with Writing pitches - that's
where it belongs.
Note names in other languages _is_ in writing pitches.
Sorry, I meant Normal pitches -- to a spaniard, si IS the normal
pitch, that's what I was getting at.
That leaves Clef and Key signature, which might come first -- since
it's fairly fundamental -- or last, since it falls a little on the
side of the other items. Thus:
Again, these clearly affect the way we _display_ pitches, not the actual
_pitches_ themselves.
To me, this borders on the level of technicalities. Much as I
appreciate the absolute pitch approach of Lilypond, I'm not so sure if
it enhances the usability of the manual to enforce that distinction in
how the material is presented. After all, cis IS not the actual
pitch itself either, it's some letters that are used to *represent*
(sounding) pitches in a different (written) notation.
But these theoretical issues apart, my main concern is with what to
me appears as unnecessary fragmentation. Then again, it's no hanging
matter.
+ Repeats and MIDI
I wonder: isn't it more natural to gather the midi stuff in one place
and just have a cross reference here?
Repeats is slated for a huge rewrite anyway. I have no objection
whatsoever to removing this subsection and putting in a link. But please
raise this issue again when we come to Repeats (probably in 5 or 6
weeks), since I have many other issues to keep track of.
OK.
o 1.7 Educational use (or increasing readibility ?)
I don't like this one, I must say. Neither font size, improvisation,
or shape notes or fingering have much to do with educational use in my
book.
They make the music easier to read.
Shape notes is not only about making it easier to read, is it? It's
closer to a notational system of its own. The affinities with
solmization are strong, and even though that too had an educational
function, it went way beyond that.
Fingering: sure, it's educational too, but again, I wouldn't have
thought of looking for it there. How about in the instrument section
somewhere?
Again, I'm not wild about the section
name, as you can tell from the (?) in the name.
I think font size should go in a page layout section or something (at
least that's how I use it, but I can also see how it would fit here).
The sections are ok, I guess, but please don't call it all educational
use... How about Appearance Tweaks or something?
hmm... I'd rather avoid the term tweaks, since we use that elsewhere to
mean \override stuff. Modifying appearance for legibility is too long.
What if one drops for legibility (since there can be many other
reasons to modify the appearance) and call it modifying appearance?
Eyolf
--
Debian is the Jedi operating system: Always two there are, a master and
an apprentice.
-- Simon Richter on debian-devel
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: flattening the manual to two layers?
On 11.09.2007 (06:41), Trevor Bača wrote: Hey Graham, hey everyone, The GDP discussion has been extremely interesting and I think I've caught up on most of the threads. But I'm not certain so feel free to tell me if this topic has already come up. Question: has anyone suggested replacing the three-layer chapter / section / section structure with a two-layer chapter / section structure? The major sections are extremely useful and have, importantly, self-evident titles; but I've never felt that grouping the major sections into basic, decorating, instrument-specific etc really buys anything ... it's always going to be quite arbitrary as to what counts as basic versus decorating versus text, IMO, so maybe best to just kill the false disctinctions. That would leave us with a 20 or 30 chapter manual, which makes perfect sense for something like a notation reference for an engraving system (again IMO). I really second this, and it also seems to be perfectly in line with the overall intention of the rewrite. If all the tutorial stuff is kept separate from the manual, there is no need for that kind of arbitrary distinctions between basic and advanced etc. that Trevor mentions. Eyolf -- April 1 This is the day upon which we are reminded of what we are on the other three hundred and sixty-four. -- Mark Twain, Pudd'nhead Wilson's Calendar ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: rearrangement (third attempt)
On 10.09.2007 (05:22), Graham Percival wrote: Rune Zedeler wrote: And in all cases, it is way too early. The user has not even learned what the 4 in c4 means. Tutorial. If a user hasn't read the LM, they're on their own and I have *no* sympathy for them. That's definitely the right approach. The *Documentation* should be in a reference form, arranged according to contents. This, IMHO, relates also to the question: bigger or smaller sections/subsections: it is rarely the case that one has a very specific question which can be answered by looking at a small subsection. My own usage is to open the pdf, search through the whole document for some word I expect to be relevant, and hopefully find the answer, either in some specific place, or from what I can piece together. I hardly ever use the ToC. For the same reason, I hardly ever use the one-page-per-subsection version of the doc. ... my general concern with it isn't musical content, only with how it is displayed is that most musicians don't make that distinction. Most people _would_ say that ottava changes pitches. This is also the right way to go, I think. Whether or not something CHANGES the pitch, it still has to do with representing pitches, and I have no problem at all with a main heading Pitches, which then, if necessary, can be subdivided into Entering pitches and modifying the display or something. I don't think that beams belong in this section - they belong together with phrasing slurs. IMO, beaming is intricately bound up in meter. I could be convinced otherwise, though. Anybody else have opinions about this? o 8.7 Ancient notation Hmm, not really instrument specific. Specific-purpose notation ? Notation for limited use ? Why not a section of its own? o 9.3 Vocal music If we consider the human voice an instrument, then this is very instrument specific. Move it to that section. That's where it used to be, but singers complained. :) And rightly so... :-) If it should go anywhere else, it could perhaps be together with Text, since that is (mainly) what distinguishes it from normal music. Eyolf -- David Brinkley: The daily astrological charts are precisely where, in my judgment, they belong, and that is on the comic page. George Will: I don't think astrology belongs even on the comic pages. The comics are making no truth claim. Brinkley: Where would you put it? Will: I wouldn't put it in the newspaper. I think it's transparent rubbish. It's a reflection of an idea that we expelled from Western thought in the sixteenth century, that we are in the center of a caring universe. We are not the center of the universe, and it doesn't care. The star's alignment at the time of our birth -- that is absolute rubbish. It is not funny to have it intruded among people who have nuclear weapons. Sam Donaldson: This isn't something new. Governor Ronald Reagan was sworn in just after midnight in his first term in Sacramento because the stars said it was a propitious time. Will: They [horoscopes] are utter crashing banalities. They could apply to anyone and anything. Brinkley: When is the exact moment [of birth]? I don't think the nurse is standing there with a stopwatch and a notepad. Donaldson: If we're making decisions based on the stars -- that's a cockamamie thing. People want to know. -- This Week with David Brinkley, ABC Television, Sunday, May 8, 1988, excerpts from a discussion on Astrology and Reagan ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: rearrange manual
On 10.09.2007 (05:28), Graham Percival wrote:
Eyolf Østrem wrote:
I would also say -- although this may exceed the limits of what kind
of suggestions were allowed -- that one thing that is missing is a
comprehensive survey of the syntax of Lilypond.
Like Appendix E Cheat sheet ? It's quite limited at the moment, but is
that what you're talking about?
Something like that, but also containing a summary of what is in ch. 9
Changing defaults and 10. File structure. Anyone who uses LP is to
some extent a programmer, and one doesn't have to stray very far from
the simplest pieces before it becomes necessary to look into those
chapters. But although the information is probably there, there is a
gap between the simple basics and the syntactically quite complicated
stuff in scheme: it takes a while to get one's head around Why should
this word be in CamelCase? Why are there no braces here? etc.
In an earlier mail, I mentioned one such case:
9.1.5 Changing context default settings
\layout {
...
\context {
\Staff
...
}
}
Here \Staff takes the existing definition for context Staff from the
identifier \Staff.
Why is this an identifier, which usually (it seems) are lower-case? Why isn't
what follows it enclosed in {}? And, again, do the three Staffs in the
explaining sentence refer to three different (types of) objects? Is the first
\Staff a different item than the context Staff, which just happens to have
the same name? Is this \Staff the identifier \Staff which is mentioned
later in the sentence, or is it yet another thing with the same name?
I'm confused... Mostly because of the {}-less syntax, but also by the
same-same-but-different names.
Expanding the Cheat sheet has been discussed from time to time; it comes
down to resources. At the moment, I think it's more important to clean up
the notation reference. If we have time/energy left afterwards, we could
tackle this... or if anybody wants to volunteer specifically to do this,
that would be great; I could help you get started.
I fully understand the resources thing, and I greatly appreciate your
work on this.
Eyolf
--
Seek for the Sword that was broken:
In Imladris it dwells;
There shall be counsels taken
Stronger than Morgul-spells.
There shall be shown a token
That Doom is near at hand,
For Isildur's Bane shall waken,
And the Halfling forth shall stand.
-- J. R. R. Tolkien
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: rearrangement (third attempt)
On 10.09.2007 (09:06), Kieren MacMillan wrote: Hi Valentin, I doubt we have enough stuff to make a whole Page layout chapter. I disagree... There's *more* than enough for a Page Layout chapter: even if some (much?) of the material is referenced elsewhere/earlier, it would be beneficial to have a single coherent section in which all of the features are collated. Agree wholeheartedly. Besides, what's wrong with having a chapter which is smaller than others if it fulfills an independent function? Which page layout definitely is. e -- I'm killing time while I wait for life to shower me with meaning and happiness.-- Calvin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: length/page-splitting of subsections
On 10.09.2007 (11:09), Kieren MacMillan wrote: Hi Graham (et al.): Does anybody _like_ the current layout? That being said... ;-) My preference is for 2 Me 2. Me 3. -- paak, n:A stadium or inclosed playing field. To put or leave (a a vehicle) for a time in a certain location. patato, n: The starchy, edible tuber of a widely cultivated plant. Septemba, n:The 9th month of the year. shua, n:Having no doubt; certain. sista, n: A female having the same mother and father as the speaker. tamato, n: A fleshy, smooth-skinned reddish fruit eaten in salads or as a vegetable. troopa, n: A state policeman. Wista, n: A city in central Masschewsetts. yaad, n:A tract of ground adjacent to a building. -- Massachewsetts Unabridged Dictionary ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: length/page-splitting of subsections
BTW I'd like to see an forever-working URL like http://lilypond.org/doc/current/Documentation/ (instead of the version; should need only one symlink; maybe current-stable and current-dev). Well, http://lilypond.org/doc/v2.11/Documentation/ gives you the current-dev. Yes, you need to update this link whenever we release a new stable branch... but that only happens once or twice a year. But what the OP said, is true, and a very simple thing to do, and it means nobody will have to change their links as often as twice a year :-) e -- love, n.: When, if asked to choose between your lover and happiness, you'd skip happiness in a heartbeat. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
