Re: GDP: renaming Program {usage, reference}
I hope this contribution isn't too late, but here goes. I'm commenting here before I have a look closely at the PDFs and possibly get bogged down in detail. Isn't the purpose of the Internals Reference to show Lilypond users how to customize/interpreter the compiler to produce source code which will represent and produce music notation in a way that is convenient and comprehensible to them? Don't they then have the option of doing this by programming at either one of two levels, i.e. using the Lilypond language (variables, accessing Lilypond 'objects', 'attributes ' or 'methods'), or if needed, dropping into Lilypond's internal macro language, Scheme. If I understand correctly your Internals Reference needs to cover both these levels of usage, and maybe a good title may be Customization and Internals Reference Manual (CIR)? Or have I missed several points in taking my helicopter view of the GPD green fields site :-)? Cheers, Ian Hulin (Now off to have a look at the PDFs). Graham Percival-2 wrote: The strong editorial decision from a few months ago is this: Notation Reference: defines the lilypond input syntax. Application Usage: how to compile the syntax, how to convert to/from the syntax (including old versions), including the syntax in other programs, etc. Internals Reference: defines the under the hood lilypond stuff. Learning Manual: prepares users for those other manuals. (this is explained at the top of policy.txt -- if it's not clear, please suggest a rewrite) For people who like to print out PDFs, I expect them to print out the LM, NR, and AU. If they want to save paper, by all means pick and choose -- for example, I wouldn't print out any of NR chapter 2, since I've never used any of the notation in it. But there is certainly no the NR is the only manual you should print out thing. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- View this message in context: http://www.nabble.com/GDP%3A-renaming-Program-%7Busage%2C-reference%7D-tf4742154.html#a13665226 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
lilypond-book poet and composer cut off
Hi,
after upgrading from an earlier version to 2.11.34, composer and poet
get cut off, see the p in the attached png. Is there a tweak or
workaround available or should it be considered a bug? Using 2.11.34 on
ubuntu gutsy.
thanks in advance
rene
--- 8 --- lily-snippet: --- 8 ---
\documentclass[]{article}
\begin{document}
Here we write some great looking LaTeX Text
\begin{lilypond}
\header
{
title = Title
composer = Composer
poet = Poet
}
\relative c'' {
a4 b c d
}
\end{lilypond}
\end{document}
--- 8 --- END lily-snippet: --- 8 ---
attachment: lilypond-book_cut_off.png___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Roman numeral chord notation in lilypond
Hello, all. I'm a bit flummoxed; I've been searching for the last hour and a half for a way to typeset roman numeral chord notation (ii, V65/V, N6) under a staff in lilypond and found nothing, except for a lone message dating from 2003 stating that said notation wasn't yet supported. Is this still the case? And, if so, why? It does seem like there are far more arcane notations which *are* supported... and this one is used by every beginning music theory course in the us (and most likely elsewhere) Just curious. PTR ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Newbie question about variable durations
(going back on list)
Ben Fagin skrev:
I've revised my implementation to set up
variables using the make-pitch function instead of variables and it
works now. Thank you!
Now that I think about it, you do not have to use make-pitch. You can
extract the pitch information from a note, like this:
%%% BEGIN %%%
\version 2.10.0
#(define (getpitch mus)
(ly:music-property
(car (ly:music-property
(car (ly:music-property mus 'elements))
'elements))
'pitch))
myPitchnames = #`(
(myowndeepceses . ,(getpitch #{ ceses, #} ))
(myownf . ,(getpitch #{ f' #}))
)
pitchnames = #(append pitchnames myPitchnames)
#(ly:parser-set-note-names parser pitchnames)
{
c' d' e' f' myowndeepceses2 g'4 a' myownf1
}
%%% END %%%
-Rune
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
page breaks related to header size
2.11.34
In this example there is clearly room for another system on the first
page. Removing anything from the header will allow another system to
move to the first page. Whatever is removed from the header clearly
doesn't take as much vertical space as one system.
I have worked for several hours reducing my real example to the
following. If a simpler example is needed I will see what I can do.
Thanks,
Paul Scott
\version 2.11.34
\include english.ly
#(set-default-paper-size letter)
#(set-global-staff-size 20.8)
\paper{
paper-size = letter
ragged-bottom = ##t
ragged-lastbottom = ##t
top-margin = .2\in
bottom-margin = .4\in
head-separation = 0\in
foot-separation = 0\in
between-system-space = .08\in
between-system-padding = .08\in
before-title-space = .01\in
between-title-space = .01\in
after-title-space = .01\in
}
timingi = {
\time 4/4
s1*8
\break
s1*40
\bar |.
}
asiii =
\relative c'' {
\repeat unfold 32 d4
\repeat unfold 128 f'4
}
{ s1\f s1*7 s1\f s1*15 s1\p s1*7 s1\f }
asiiilii = \relative c {
R1*8
\repeat unfold 160 e4
}
\header {
title = \markup{ Page Break Test }
subtitle= \markup{ Subtitle }
subsubtitle = \markup{ Subsubtitle }
composer = \markup{
\column{
\line{ Line 1 } \line{ Line 2 } \line{ Line 3 } \line{ Line 4 }
\line{ Line 5 }
}
}
piece = \markup{ Test }
}
\layout {
indent = 0 \in
\context {
\Score
\override VerticalAxisGroup #'remove-first = ##t
}
\context { \RemoveEmptyStaffContext }
}
\score {
\set Score.restNumberThreshold = #0
\new StaffGroup
\new Staff \timingi \asiii
\new Staff \asiiilii
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
LSR - lilypond docs
LSR finally has tags, so it's time to describe how LSR and the lilypond docs are linked. I seem to be incredibly bad at describing this, so bear with me. I've described it to the devel team at least three times, and they're a lot more familiar with our source tree than anybody else. But let's try it anyway. (if you're familiar with the previous LSR-lilypond stuff, this is exactly the same, except snippets can have multiple tags instead of one category/directory) I'm reserving this subject for describing the actual link. Discussion about what this means for the exact tags in LSR and writing the docs (in particular, the @commonprop sections) will go in a separate subject. Open up a web browser, and go to LSR: http://lsr.dsi.unimi.it/ Type in rhythms in the search. This gives you a relatively short list of snippets tagged with rhythms. Now open up a new browser window, and go to the GDP docs: http://web.uvic.ca/~gperciva/ Go to the Notation Reference, and look at 1.2.1 Writing rhythms: Tuplets. Scroll down to the bottom. Click on the Snippets: rhythms/ link. See the similarity in the examples? NB: the snippets currently display may or may not remain there -- we still need to decide which kinds of snippets to include in this. Also, it's possible that some of these snippets are broken. This is just a quick tech demo, not the final product by any means. LSR snippets that are tagged with rhythms and docs are magically added to our docs every so often. If a snippet is updated in LSR, it's updated in our docs. If it's removed from LSR, it's removed from our docs. This process only takes a few minutes, and it's easy for any developer to do. LSR snippets tagged with rhythms but not docs are not included in this. This means that LSR can have a whole bunch of rhythms snippets, of which only a subset will be added to the main docs. These snippets are available as a PDF as well; go to the main GDP page and follow the Snippets link. The LSR-lilypnod docs link has the potential to simplify the Doc Editor's job -- snippets may be added or updated without the need to edit texinfo files in git. Any new (or updated) snippet must be approved by the LSR editor, so there is still some quality control for this. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: the snippets vs. texinfo
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. 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. Me vs. everybody: I want a set of easily maintained docs. I also want to set realistic goals. I feel no compunction about rejecting any suggestion -- no matter how good from a documentation standpoint -- which we do not have the resources (ie volunteer time/effort) to create and/or maintain. 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, Consider NR 1.2.1 Tuplets, for example. (if you haven't already, please see the LSR-lilypond docs email) Currently, the Commonly tweaked properties contains five examples. These demonstrate a number of neat tricks you can do with tuplets... but what happens if something needs to be updated? (ie a property name changes, somebody thinks of a better explanation, there's a nicer way to achieve a particular tweak, etc) 1) The helpful user could download the lilypond source, edit rhythms.tely, compile the docs to check that it works, make a patch, send it to -devel. That's a lot to expect from people. 2) The helpful user could send an email explaining what to do, according to the documentation suggestions page. I honestly don't think that's too much to ask from helpful users, but in the past two years I've received less than ten such emails. Clearly people are shy about sending emails. Now, suppose (for the sake of argument) that all of these tweaks were in the Snippets: rhythms/ link at the bottom of that page. This means that these tweaks are in LSR, and that gives helpful users a third option to fix examples: 3) The helpful users edits the snippet in LSR. The LSR editor is notified about the modified snippet, approves it, and the main lilypond docs are magically updated in a few days. I confess that I'm not totally convinced that hordes of users are going to follow #3... but whenever I complain about the lack of users helping with the docs (pointing out #2, all you need to do is send an email to me -- if you can complain about the docs on this mailist, then you can help fix the docs!) I always get people claiming that if there was a wiki, they would be committing updates. 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. Now that we have the technology in place and a description of how it might work, we need to decide how this affects the docs. In particular, what do we keep in @commonprop, and what do we move into LSR (and the Snippets) ? 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. For example, in Tuplets I would suggest keeping the first and second-last examples in the @commonprop section, and moving everything else into Snippets. Not because I don't think the tweaks are useful, but just to direct readers to the Snippets, and from there the LSR. Hopefully the easily-updateable LSR will generate a culture of doc-improvement. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
Michael David Crawford wrote: Paul Scott wrote: 2.11.34 In this example there is clearly room for another system on the first page. Removing anything from the header will allow another system to move to the first page. Whatever is removed from the header clearly doesn't take as much vertical space as one system. I have also found that increasing the height of the text at the bottom of the first page will increase the page count. My piece Recursion was seven pages, but when I reformatted its Creative Commons license to be a couple lines longer, the score went to eight pages. I fiddled with it for quite a while, but was completely unable to get it back to seven pages and still be sensibly laid out. Thanks for replying. It seems to me there might be a bug in how the vertical size of the next system is calculated or subtracted from the available vertical space on the current page. I have posted this in case there is some setting I am missing. Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
