Tilde causes error message: "unrecognized string, not in text script or \lyricmode"

[Eyolf Østrem]

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 "e"s 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"

[Eyolf Østrem]

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: Setting entire document fonts

[Eyolf Østrem]

On Fri, 24 Oct 2014 10:10:34 -0700 (PDT) tisimst 
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

Re: What is the problem with "\relative"? (Was: Do we really offer the future?)

[Eyolf Østrem]

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  and . 
" 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?)

[Eyolf Østrem]

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: Limits of algorithmic typesetting (was: Re: mutopia's shortcomings)

[Eyolf Østrem]

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: my favorite bug :-)

[Eyolf Østrem]

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: tuplets

[Eyolf Østrem]

> 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

[Eyolf Østrem]

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: GDP: add "extender line" to the glossary?

[Eyolf Østrem]

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: Fwd: Users' Manual

[Eyolf Østrem]

On 29.09.2007 (06:07), Rick Hansen (aka RickH) wrote:
> 
> I would buy the manual in a nice spiral book, perhaps the sales could be used
> to pay developers.  The cost of printing and binding the PDF at my local
> office store is not cheap, and I'd much rather have the money go to the
> devs. and to the doc writers.  If you guys could work something out and sell
> it on the lp site profitably.

THat's actually one of the first things I did when I realized that
"hey, I'm going to ditch Finale!": I went to the copyshop and made
myself a spiral bound version of the manual, since, as I thought: I'm
going to use this one a lot. 
Which I did, although I've used the pdf file more. But some kind of
print-on-demand solution (there is also lulu.com) where some money
could go to the devs, wouldn't be a bad solution, and probably both
better and cheaper than what I got.

e
-- 
"A University without students is like an ointment without a fly."
-- Ed Nather, professor of astronomy at UT Austin


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Canorus 0.4 released

[Eyolf Østrem]

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

Elision/lyric tie again

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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...

[Eyolf Østrem]

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

[Eyolf Østrem]

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: Lilypond-book -- almost there...

[Eyolf Østrem]

On 03.10.2007 (00:19), Francisco Vila wrote:
> 2007/10/2, Eyolf Østrem <[EMAIL PROTECTED]>:
> > 2. Is there a way to automatize the process? E.g. in Kile, vim, or
> 
> You can obtain a reasonable degree of automation using the 'make'
> utility. Search for Marcus Brinkmann, (marcus dot brinkmann at rub dot
> de) for a nice example of how to use it on a complete book (Slave
> Songs of the United States, 1867)

Thanks for the pointer. I had actually downloaded that file when it
was announced, because of the contents, but it most certainly seems
that I will have to look at make.

One problem: it doesn't seem to be possible to use the recommended --output=out 
for the
files generated by lilypond-book if it is supposed to be part of a
larger tex file, is that correct?

I have the following structure:

whole-book.tex
chapter1.tex
chapter2.tex
.
.
etc
.
appendix.lytex
out/
 appendix.tex
 loads
 of
 garbage
 and
 eps
 files

If I have \include{out/appendix} in the master file whole-book.tex,
the latex compilation stops, complaining that 

"! I can't find file `lily-c02d2e2f36-systems.tex'."

So I assume that out/ is not searched for files, only ./
It's not that I mind having all the files in the top dir, though, I
was just wondering.

Eyolf
-- 
   It seems like once people grow up, they have no idea what's cool.
  -- Calvin


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: new display for warnings

[Eyolf Østrem]

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

Re: Lilypond-book -- almost there...

[Eyolf Østrem]

On 04.10.2007 (00:09), Francisco Vila wrote:
> 2007/10/3, Eyolf Østrem <[EMAIL PROTECTED]>:
> >
> > If I have \include{out/appendix} in the master file whole-book.tex,
> > the latex compilation stops, complaining that
> >
> > "! I can't find file `lily-c02d2e2f36-systems.tex'."
> >
> > So I assume that out/ is not searched for files, only ./
> > It's not that I mind having all the files in the top dir, though, I
> > was just wondering.
> 
> The out directory is supossed to be for output files. You can name it
> las you want, however. I'd first change the name of include directory
> to "include" or "input" for greater clarity.
> 
> Your message seems to indicate that some error happened with this file
> in particular, as this is not your given name, but the one generated
> by lilypond-book. Try compiling it as included into a minimal,
> self-complete tex file so you can test it separately.

It's not just that file -- somehow (and I'm sure I could track that
down, but there are so many files...) there is some mixup in the
folders. I may pursue it further some other day. Until then, I'm
perfectly happy with the current solution: lots of glorious crap in
the same folder... 
My makefile works wonders too. Thank god I sat down and figured out
how to use make -- it's going to save me lots of time in the future.

Eyolf

-- 
Genius is ten percent inspiration and fifty percent capital gains.


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond-book -- almost there... round III

[Eyolf Østrem]

I made a last attempt, with minimal files included, which look like
this:

playground/book.tex:
\documentclass{article}
\begin{document}
\include{out/lpb-file}
\end{document}

playground/lpb-file.lytex:
\lilypondfile{music.ly}

playground/music.ly:
\version "2.10.25"
\relative c' { 
  \clef treble
a'2 gis4. gis8 gis4 a b2. c4 c b a2 gis
c4 c8 c c2 c c4. c8 g4 a b2 c
r4 b8 b b2 b4 cis4 d2. d4 c2. a4 gis4 a2 gis4 a1 }

I have no preamble or anything in the lytex-file, because it is
supposed to be included in the book.tex file. 

A run of lilypond-book --psfonts --output=out gives the following
structure, with the relevant files given in full:

playground/book.tex
playground/lpb-file.lytex
playground/music.ly

playground/out:
lily-05a48313a2-1.eps
lily-05a48313a2-2.eps
lily-05a48313a2-systems.tex:
\includegraphics{lily-05a48313a2-1}
\ifx\betweenLilyPondSystem \undefined
  \linebreak
\else
  \betweenLilyPondSystem{1}
\fi
\includegraphics{lily-05a48313a2-2}
% eof - 'eof' is Makefile marker; do not remove. 

lily-05a48313a2-systems.texi
lily-05a48313a2.eps
lily-05a48313a2.ly
lily-05a48313a2.txt
lpb-file.dep
lpb-file.psfonts
lpb-file.tex
{%
\parindent 0pt%
\ifx\preLilyPondExample \undefined%
 \relax%
\else%
 \preLilyPondExample%
\fi%
\def\lilypondbook{}%
\input lily-05a48313a2-systems.tex%
\ifx\postLilyPondExample \undefined%
 \relax%
\else%
 \postLilyPondExample%
\fi%
}

snippet-map.ly
snippet-names

Now, if all the includes and inputs are resolved, the book.tex file
ends up looking like this, with irrelevant lines deleted: 

\documentclass{article}
\begin{document}
{%
\includegraphics{lily-05a48313a2-1}
\includegraphics{lily-05a48313a2-2}
}
\end{document}

which means it's not strange that latex complains that:

! I can't find file `lily-05a48313a2-systems.tex'.
 
   \relax 
l.11  \relax
%
Please type another input file name: 

since what it SHOULD have been looking for, is
out/lily-05a48313a2-systems.tex.

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...

eyolf
-- 
C-3PO:
R2 says that the chances of survival are 725 to 1.
Actually R2 has been known to make mistakes - from time
to time... Oh dear...


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond-book -- almost there... round III

[Eyolf Østrem]

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: pitches rewrite

[Eyolf Østrem]

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

[Eyolf Østrem]

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: On popular demand: Free Meter :-)

[Eyolf Østrem]

On 06.10.2007 (16:35), Rune Zedeler wrote:

> (ofcourse you could rename the \increaseBarNumber function to something 
> shorter - e.g. \ibn thereby getting \ibn\bar "||")

Sounds like something that would be useful for arabic music :-)

eyolf
-- 
warez /weirz/ n. 

 Widely used in cracker subcultures
   to denote cracked version of commercial software, that is versions
   from which copy-protection has been stripped.  Hackers recognize
   this term but don't use it themselves.  See warez d00dz.



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Offsetting a turn horizontally

[Eyolf Østrem]

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: where do we discuss MIDI?

[Eyolf Østrem]

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: GDP: introducing examples

[Eyolf Østrem]

On 19.10.2007 (14:58), Graham Percival wrote:


> Mark Knoop wrote:
> >Graham Percival wrote:

> >>1)  The text just continues directly into

> >>2)  The text suggests that one may do foo,

> >>3)  The text directs the reader to the following example:

> >>4)  The text forms a complete sentence.

> >>Should allow all?  Specify one method?  Disallow one or two methods?
> >I prefer 4, 3, 2, 1 (in that order). But I don't think standardisation
> >is necessary, although perhaps an official preference could be specified.

> That's my preference as well, although IMO #1 looks like a mistake 
> (missing punctuation) -- my vote is to not allow #1, but let writers pick 
> any of the other three methods.

I agree too. I can probably think of a case where 1) MIGHT be
permissible, (sth like:

"if you file has
[example]
you will get ... ")

but such constructions will rarely look elegant, and it's better to
rephrase it to 2)-4).

eyolf

-- 
   "All this modern technology just makes people try to do everything at once."
-Hobbes


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Church Rests

[Eyolf Østrem]

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

[Eyolf Østrem]

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: GDP: pitches second draft

[Eyolf Østrem]

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  \\ //  >-()-

Re: troubles with time change

[Eyolf Østrem]

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

[Eyolf Østrem]

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: lyrics and german hyphenation

[Eyolf Østrem]

On 25.10.2007 (14:13), Werner LEMBERG wrote:
 
> BTW, the correct way of the Neue Deutsche Rechtschreibung is Ku-ckuck
> -- `ck' is treated similarly to `ch' or `sch'.

Geeeze -- I thought German was a cultivated language... :-)

Eyolf

-- 
Breeding rabbits is a hare raising experience.


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: ties

[Eyolf Østrem]

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: Beginner question

[Eyolf Østrem]

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: typeset lyrics

[Eyolf Østrem]

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

[Eyolf Østrem]

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: GDP: renaming Program {usage, reference}

[Eyolf Østrem]

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: GDP: renaming Program {usage, reference}

[Eyolf Østrem]

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

User survey?

[Eyolf Østrem]

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: the snippets vs. texinfo

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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

Re: GDP: keep separate pdf files?

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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: Dodgy dotted notes

[Eyolf Østrem]

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: Creating a nice formatted Chords + Lyrics layout for guitar players

[Eyolf Østrem]

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

[Eyolf Østrem]

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: once again with a header, tie into polyphony question

[Eyolf Østrem]

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
  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~ 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: \markup in manual volta endings

[Eyolf Østrem]

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: hang --"going backwards in time; " "insane spring

[Eyolf Østrem]

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

[Eyolf Østrem]

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?

[Eyolf Østrem]

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: hang --"going backwards in time; " "insane spring

[Eyolf Østrem]

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: Lilypond for serial music?

[Eyolf Østrem]

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: macro for instrument changes

[Eyolf Østrem]

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: Tie across triplet boundary

[Eyolf Østrem]

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: Leaving

[Eyolf Østrem]

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

[Eyolf Østrem]

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: Leaving: "I can't help"

[Eyolf Østrem]

On 05.01.2008 (22:49), Graham Percival wrote:
> On Wed, 2 Jan 2008 09:50:01 -0500
> Kieren MacMillan <[EMAIL PROTECTED]> wrote:
> 
> > I'm a professional composer.
> > I use Lilypond (nearly) every day.
> > I don't actively (i.e., visibly) contribute to Lilypond code or  
> > documentation... and may not in the near future, despite attempts to  
> > guilt me into doing so.  ;-)
> 
> You know my instant hostile reaction to anybody making demands of
> lilypond volunteers.  And I am quite aware that I'm being
> hypocritical in trying to guilt advanced users into contributing
> to the docs.
> 
> So it is with the greatest of reluctance that I continue such
> attempts.
> 
> 
> We currently have *zero* active helpers in GDP who are working on
> the contents of the docs. 

Ehem... unless with "currently" you mean "at this very moment", we do have
one, although too pressed for time at this very moment (lasting until the
middle of the month) to be as active as desirable. But *zero*? No.

eyolf

-- 
  He has gone from Alia, 
  The womb of heaven! 
  Holy, holy, holy! 
  Fire-sand leagues 
  Confront our Lord. 
  He can see 
  Without eyes!
  A demon upon him! 
  Holy, holy, holy 
  Equation:
  He solved for 
  Martyrdom!
  
-- The Moon Falls Down Songs of Muad'dib


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Volunteering with LilyPond

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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"

[Eyolf Østrem]

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: Volunteering with LilyPond

[Eyolf Østrem]

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: GDP: What term do you use?

[Eyolf Østrem]

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: GDP: What term do you use?

[Eyolf Østrem]

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: WANTED: Design for documentation (Photoshop power users!)

[Eyolf Østrem]

The recent changes to the html/css are really a significant improvement to
the web-based documentation. Kudos to all! 

But what about the pdf version? I guess, sine it's so much raw tex,
changing it may be more troublesome (at least the attempts I made failed),
but it would really be good, either just to spice up the layout a little
(better distinction between levels of headlines, e.g.), or even better: to
bring it in better accordance with the html/css version, such as using
colors, borders, etc.

I could do it in LaTeX, but I'm not sure about plain tex. 

eyolf

-- 
Corruption wears infinite disguises.

  -- Tleilaxu Thu-zen


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: WANTED: Design for documentation (Photoshop power users!)

[Eyolf Østrem]

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: WANTED: Design for documentation (Photoshop power users!)

[Eyolf Østrem]

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

Elision mark glyph (was: unusual Alto Clef)

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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: Notating recitative

[Eyolf Østrem]

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

[Eyolf Østrem]

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:

1\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

Re: adding rests automatically

[Eyolf Østrem]

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: Automatic indentation in Vim

[Eyolf Østrem]

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//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: Lighter appearance

[Eyolf Østrem]

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: No time signature?

[Eyolf Østrem]

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 .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 --, 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 
	

Re: problems with learning lilypond

[Eyolf Østrem]

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

[Eyolf Østrem]

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: Quick-insert mode for vim -- work in progress

[Eyolf Østrem]

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

[Eyolf Østrem]

On 21.11.2008 (18:50), Nicolas Sceaux wrote:
> I'm using the keyboard mapping  suggested by a user and described here:
>   

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

[Eyolf Østrem]

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

How to make note spacing disregard lyrics

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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

[Eyolf Østrem]

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

-- 
 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.

[Eyolf Østrem]

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: Notation Reference typo

[Eyolf Østrem]

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

Re: question about transposing an interval of a 4th

[Eyolf Østrem]

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: question about transposing an interval of a 4th

[Eyolf Østrem]

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: avoid slur help

[Eyolf Østrem]

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: Writing psalms

[Eyolf Østrem]

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: Margins

[Eyolf Østrem]

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: GDP: rearrange manual

[Eyolf Østrem]

On 09.09.2007 (16:32), Graham Percival wrote:
> Well, don't I feel like a complete newbie.  :/Does anybody know how to 
> make Thunderbird treat text like pure bloody text, and not change the 
> displayed text when it sends an email out?  thanks in advance.  :(

One of the reasons why I prefer mutt over any other mail handler...
perfect example of the difference between "user-friendliness" and
*user-friendliness*.

Anyway, I second the suggestions that ... 

On 09.09.2007 (18:06), Trevor Bača made:
> 
> Specifically:
> 
> - promote section 8.1 "Text" to the status of a free-standing chapter

Definitely. It also belongs together with ...  
 
> ~ subsection 8.4.8 "Selecting notation font size";

... which is relevant, in my experience at least, when you want to
change the size of the whole score and have also made changes to the
pango font tree -- much more so than for changing the size of
individual notes in "contemporary notation" (then again, I don't write
contemporary scores).
So perhaps a unified section on "Fonts and sizes"?

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. Now, it's all there,
I'm sure, but there is a huge gap between the "First Steps" section,
giving the beginner just enough information at the time to avoid
overflow, and the "Interfaces for Programmers" section, which is
intimidating, not only because it's complex, but also because of the
language: one is likely to think: "Hey, I'm not a programmer, I hardly
know what 'interface' means -- this section is not for me", which is
wrong, because that chapter contains information that anyone is likely
to need some day if one writes things more advanced than single melody
lines.
In the gap between these two extremes -- which means the rest of the
manual -- I'm sure everything one needs to know can be found, but I'd
welcome a separate section "Lilypond syntax", which would briefly but
exactly list and explain the syntax, from the file structure (which
also belongs here) down to typographical requirements (escapes, space
around { } , naming conventions for various types of objects
(Music expressions, GROBs and Contexts with CamelCase, Music classes, music
properties, Grob interfaces, and backend properties use scheme-type,
Engravers: Caps_and_underscores, and Context properties use
lowercaseAndCamelCase). 

This would be very helpful, I think.

Eyolf

-- 
Aliquid melius quam pessimum optimum non est.


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: rearrangement (third attempt)

[Eyolf Østrem]

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

[Eyolf Østrem]

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 "Staff"s 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