Performance and MIDI
Hi, The code behind MIDI output and Performance seem to be pretty much tightly tied together. Was it ever intended that Performance be used for other output types? The Performance class contains specific MIDI references. I was under the impression that MIDI output was but one implementation of the Performance facility, but that does not now seem to be the case. Regards, Ralph ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GDP: documentation guidelines
I've updated the README.txt with more guidelines about
writing/maintaining documentation. I'll be asking the GDP Helpers to
fix any Section organiztion and Formatting issues, as well as any
Readability or Technical writing issues they feel comfortable updating.
If I've forgotten anything from this list, please speak up so we can add
them now.
Info for Documentation
--
% UPDATING DOCS
convert-ly -e --from=... --to=... --no-version *.itely
% to find the current version number,
grep "version \"" tutorial.itely
% (nobody ever remembers to update this file, so I've stopped
% trying to record it here)
% BOOKS
There are three parts to the documentation: the Learning Manual,
the Notation Reference, and the Technical Details.
* Learning Manual: long, chatty, friendly explanations go here.
This is aimed at users learning something for the first time --
not necessarily just learning lilypond notation, but also things
like learning how to deal with projects, tweaking, preparing parts
for orchestras, etc. Less formal language may be used here.
Users are encouraged to read the complete Learning Manual from
start-to-finish.
* Notation Reference: a (hopefully complete) description of
LilyPond input notation. Some material from here may be
duplicated in the Learning Manual (for teaching). The material is
presented in an approximate order of increasing difficulty, but
the goal is _not_ to provide a step-by-step learning environment.
For example, all material under "Pitches" should remain in that
section, even though microtonal accidentals may seem more advanced
than info about clefs or time signatures -- "Pitches" should be a
one-stop reference about the pitch portion of notes. This section
is written in formal technical writing style.
Users are not expected to read this manual from start to finish.
However, they should be familiar with the material in the Learning
Manual (particularly ``Fundamental Concepts''), so do not repeat
that material in this book.
* Program Usage: information about using the program lilypond with
other programs (lilypond-book, operating systems, GUIs,
convert-ly, etc). This section is written in formal technical
writing style.
Users are not expected to read this manual from start to finish.
% SECTION ORGANIZATION
The order of headings inside documentation sections should be:
main docs
@refcommands
@commonprop
@seealso
@refbugs
(omit any headings which do not apply)
Including at least one link to @lsrdir{} inside @seealso is
highly recommended.
% FORMATTING
* Use two spaces for indentation in lilypond examples.
* Do not use tabs. They expand to nothing in DVI output.
* Do not use spaces at the beginning of a line (except in @example
or @verbatim environments), and do not use more than a single
space between words. `makeinfo' copies the input lines verbatim
without removing those spaces.
* Use two spaces after a period.
* Don't use a @ref{link to another section} in the middle of a
sentence. It looks ok in HTML, moderately bad in PDF, and
utterly horrible in INFO. Instead, reword the sentence so that
users are encouraged to see @ref{link to another section}.
(at the end of the sentence)
* Variables or numbers which consist of a single character
(probably followed by a punctuation mark) should be tied
properly, either to the previous or the next word. Example:
The [EMAIL PROTECTED]@var{a} ...
* To get consistent indentation in the DVI output it is better to
avoid the @verbatim environment. Use the @example environment
instead if possible, but without extraneous indentation. For
example, this
@example
foo {
bar
}
@end example
should be replaced with
@example
foo {
bar
}
@end example
where [EMAIL PROTECTED]' starts the line (without leading spaces).
* Use the `quote' option in @lilypond commands if possible.
Do not compress the input vertically; this is, do not use
Beginning of logical unit
@example
...
@end example
continuation of logical unit
but
Beginning of logical unit
@example
...
@end example
@noindent
continuation of logical unit
This makes it easier to avoid forgetting the [EMAIL PROTECTED]'.
* Non-ASCII characters which are in utf-8 should be directly used;
this is, don't say [EMAIL PROTECTED]' but `Baßtuba'. This ensures that
all such characters appear in all output formats.
* Lines should be less than 72 characters long. (I personally
recommend writing with 66-char lines, but don't bother modifying
existing material.)
* Use @q instead of `...' and @qq instead of ``...''. The latter macro
should be used with care since we use `...' as the default quoting
throughout the manual, except for things related to direct speech.
Warning: @q{} and @qq{} *MUST NOT* come at the end or beginning
of a line (unless it begins the paragraph). If these
GDP: "Predefined commands" vs. "commonly teaked properties"
Should we keep @refcommands independent from @commonprop ? For example, look at Tuplets. Do you like it as it is, or should we move \tupletUp \tupletDown etc inside the "Commonly tweaked properties" ? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: partial rearrangement done, technical problems
On 9/20/07, Graham Percival <[EMAIL PROTECTED]> wrote: > People who offered to help: I'm sorry I still haven't started the actual > documentation work yet. However, these stupid technical problems need > to get sorted out -- or at the very least, I need to be certain that the > technical issues _can_ be sorted out -- before I'm going to commit hours > and hours of documentation editing. I don't want to waste your time. > - > > > I've rearranged the non-instrument-specific portion of the docs; you can > see them here: > > http://opihi.cs.uvic.ca/~gperciva/lilypond/ > > > KNOWN ISSUES (don't bother pointing these out) > > - the subsections in vocal music and ancient music are messed up. > > - some HTML links aren't working. See below. > > > GENERAL DISCUSSION > > - I still like the division of musical notation / instrument-specific? > No? Nobody else? ok, I'll divide up that chapter and stuff it all into > the monster Musical notation. The notation / instrument-specific division is fine, imo. But it does seem odd to have "Chord names" as part of the instrument-specific stuff. Are chord names instrument specific? If you think of chords names as primarily useful in theory class, then "Educational use" might make sense; on the other hand, if you think of chord names for lead sheets, then maybe they should just become their own chapter in the notation section. Either way, maybe move "Chord names" to the notation section. Also, I agree with an earlier comment (somehow lost it in the thread) that both Strings and Bagpipe should promote to full sections in the instrument-specific part. It's OK that they be small; they can just function as placeholders until more such content shows up later. That will get rid of the "other instrument stuff" junk drawer. > - Assuming that the technical issues are solved, how do you want these > merged subsections to look? Specifically, consider 1.2.3. Displaying > rhythms. There's > > Time signature > - @commonprop > - @seealso > - @refbugs > Upbeats > - @refbugs > Unmetered music > - @refbugs > ... > Automatic note splitting > - @refbugs > - @seealso > > > Do you like this format, or would you prefer one @commonprop at the end > of each page? Do you want links to LSR stuff at the end of each > portion, or just one set of links at the bottom of the page? > > ... and are you guys _sure_ you prefer the manual like this? Ew. I don't like. Reading 1.2.3 is choppy. And the bold subsection titles hurt rather than help. Here's an extraction of the 1.2.3 subsection titles right now: 1.2.3 Displaying rhythms Time signature Commonly tweaked properties See also Bugs Upbeats Bugs Unmetered music Bugs Polymetric notation Bugs Automatic note splitting Bugs See also Doesn't flow. And makes us look like we have an undue preoccupation with bugs. A better structure would be: 1.2.3 Displaying rhythms Time signature Upbeats Unmetered music Polymetric notation Automatic note splitting See also We don't need but bug subsections printed as separate subsections with separate headers. Just format the content of the @refbugs as regular old paragraphs with no special headers. The chunking will then look like the revised ex above (focusing on the musical ideas), and we won't appear to be so wrapped around the axle about bugs. As far as the LSR stuff, maybe include all external links (whether LSR or see also, or whatever) in a single "See also" section at page bottom? -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
Hi, On Fri, 21 Sep 2007, Valentin Villenave wrote: > 2007/9/21, Johannes Schindelin <[EMAIL PROTECTED]>: > > > > On Fri, 21 Sep 2007, Rune Zedeler wrote: > > > > > It seems that the problem is that I changed MY_PATCH_LEVEL to rz1. > > > Problem is, that master just updated PATCH_LEVEL from 32 to 33, and > > > because > > > MY_PATCH_LEVEL and PATCH_LEVEL are defined right next to each other, the > > > automerge fails. > > > > > > I resolved the conflict manually. > > > Try again, Valentin. > > OK, thanks to both of you. > > I did it the hard way: I deleted the VERSION file, then I did a git > reset --hard and pulled it again, then it worked. > > I didn't checkout -b another local branch, as all I wanted to do was > get Rune's source code to give it a try. But I know this is > quick-and-dirty :) Actually, if you pulled, you did not try Rune's code... but a merge of what you had before _and_ Rune's code. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Compiling lilypond on a Mac
I am trying to compile Lilypond devel branches (tried 28 to 33) and I *finally* got them to compile, but I cannot get them to pass the test-baseline set: $ ./configure --with-ncsb-dir=/sw/share/ghostscript/fonts $ make $ make test-baseline (.) lilypond-book.py (GNU LilyPond) @TOPLEVEL_VERSION@ Reading out-test/collated-files.tely... Dissecting... Writing snippets... Processing... Running lilypond...GNU LilyPond 2.11.33 command failed: ./lilypond .(assume you know this stuff) Child returned 1 make[3]: *** [out-test/collated-files.texi] Error 1 make[2]: *** [local-test] Error 2 make[1]: *** [test] Error 2 make: *** [test-baseline] Error 2 $ I tried 2.11.28, 2.11.30, 2.11.32, 2.11.33 and get similar errors. The latest stable release passes all the tests just fine. Any idea what I have done wrong? Jared - AN AMATEUR'S ATTEMPT TO COMPILE LILYPOND: (by the way... here is a step-by-step on what I had to do to get Lilypond to compile on Mac... it was quite a bit of work, so I documented it step-by-step in order to help anyone else who attempts to do this! It also might give some insight into something I did wrong?) NOTE 1: I had to use Fink, because there is an issue in GMP on Mac-intels, and I tried all sorts of work-arounds but could NOT get guile to compile. Therefore, I decided to do all the building from inside Fink. NOTE 2: Always try to build/install from source. Fink didn't find the dependencies on some of the packages right, so some of the source builds failed for me (I will mark those). Later, we will go back through and retry it once we get through the list once, and it should work then. NOTE 3: This is a list of things that must be done from a fresh Mac OS/X install. Make sure to install XCode and X11 tools from the Mac disks. -1) Get python 2.5. 0) download and install fink. Then, make sure to "selfupdate". The package list from the initial fink install is too out-dated and some of the packages wont show up (like guile18) 1) guile18, guile18-dev, guile18-doc, guile-libs, guile18-shlibs from source 2) bison from source 3) pkgconfig from source 4) autoconf from source 5) freetype2 from source 6) You now should install fontconfig2. Unfortunately, the fink package did not build all the tools (specifically fc-match). So instead, download 2.4.1 from the fontconfig2 website, and build and install from that source, NOT fink. 7) fontforge from source (the binary version is very old). I got an error in the build process that it could not find libpng12.dylib. The library search path was not working right, and I couldnt' figure out how to get the right path in. So, I cheated with a "sudo ln -s /sw/lib/libpng12.dylib /usr/local/lib/libpng12.dylib" and the build worked perfect. 8) gd2 from binary (this one would not compile from source) 9) t1lib5 from binary (this one wouldn't compile from source) At this point, I tried to get mftrace to install, but it required tetex, which would not compile. From a forum post, I learned that my X11 config was broken. So, I had to do a reinstall of X11User.pkg and X11SDK.pkg from the Mac system disc. Then, it worked! 10) mftrace from source (bin is too old) 11) pango1-xft2-ft219, pango1-xft2-ft219-dev, pango1-xft2-ft219-shlibs from source 12) glib2, glib2-dev, glib2-shlibs from source If you installed any of the packages above from binary, go back now and install from source. In my trials, lilypond would not compile right, but after I rebuilt all the above from source, it finally compiled just fine! TO FINALLY BUILD LILYPOND: Now, I found a nice forum post from lilypond list archives and set the following environment variables: * export PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig: /sw/lib/freetype219/lib/pkgconfig:/sw/lib/pango-ft219/lib/pkgconfig: $PKG_CONFIG_PATH * export GUILE_CONFIG=guile-1.8-config * export PYTHON=/sw/bin/python2.5 * export GUILE=/sw/bin/guile-1.8 And, now, time to build lilypond. Note the option for configure; without this option, configure will find TTF files instead of the PFB files * ./configure --with-ncsb-dir=/sw/share/ghostscript/fonts * make ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
2007/9/21, Johannes Schindelin <[EMAIL PROTECTED]>: > Hi, > > On Fri, 21 Sep 2007, Rune Zedeler wrote: > > > It seems that the problem is that I changed MY_PATCH_LEVEL to rz1. > > Problem is, that master just updated PATCH_LEVEL from 32 to 33, and because > > MY_PATCH_LEVEL and PATCH_LEVEL are defined right next to each other, the > > automerge fails. > > > > I resolved the conflict manually. > > Try again, Valentin. OK, thanks to both of you. I did it the hard way: I deleted the VERSION file, then I did a git reset --hard and pulled it again, then it worked. I didn't checkout -b another local branch, as all I wanted to do was get Rune's source code to give it a try. But I know this is quick-and-dirty :) Thanks Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
Hi, On Fri, 21 Sep 2007, Rune Zedeler wrote: > It seems that the problem is that I changed MY_PATCH_LEVEL to rz1. > Problem is, that master just updated PATCH_LEVEL from 32 to 33, and because > MY_PATCH_LEVEL and PATCH_LEVEL are defined right next to each other, the > automerge fails. > > I resolved the conflict manually. > Try again, Valentin. > > What is the recommended way of doing this? Do I really have to manually > edit and push my own branch each time the master branch changes version? No, you usually do not merge all too often, since the purpose of your branch -- at least as far as I can tell -- is a specific topic. So you usually work on that topic, not merging with upstream at all, or at least only rarely, and then only to check if it merges, and _undoing_ the merge right away. When your topic has evolved to a state where you think it should go to mainline, you rebase it. Meaning that git takes all your commits since the branch point, and grafts them on top of the upstream branch. This can be accomplished by the simple command "git rebase ". (It is easiest if your development was linear after branching off). Then you ask people to review your changes, and then your branch can be merged _trivially_, since it is a fast forward. Hth, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
Hi,
On Fri, 21 Sep 2007, Valentin Villenave wrote:
> 2007/9/21, Johannes Schindelin <[EMAIL PROTECTED]>:
>
> > This means that you have local changes. Try "git status" and/or "git
> > diff" to find out which changes those are.
>
> The point is: I do not have local changes: I haven't been working on the
> code nor modifying anything...
Ah, my bad.
> maybe this error message is more self explanatory:
> %%%
> Auto-merging VERSION
> CONFLICT (content): Merge conflict in VERSION
>
> Automatic merge failed; fix conflicts and then commit the result
> %%%
>
> ...and the git-diff goes:
> %%%
> diff --cc VERSION
> index aa9f7e7,7242416..000
> --- a/VERSION
> +++ b/VERSION
> @@@ -1,6 -1,6 +1,11 @@@
> PACKAGE_NAME=LilyPond
> MAJOR_VERSION=2
> MINOR_VERSION=11
> ++<<< HEAD/VERSION
> +PATCH_LEVEL=33
> +MY_PATCH_LEVEL=
> ++===
> + PATCH_LEVEL=32
> + MY_PATCH_LEVEL=rz1
> ++>>> 1982a5513e92f4f01605e9dbfdbb997f314b1cac/VERSION
> %%%
>
> I can't understand what's wrong this different versions thing. Every
> other branch gives me the message "already up to date".
>
> Can you enlighten me?
Yes, I think I can.
So this is part of the history:
B - ... - Y
\
... - T
where "B" is the branch point of _your_ branch ("Y") and _their_ branch
("T").
Now, somewhere on both development lines, the same part of the file was
touched. One side (you, or at least somebody else working on that branch)
changed the line to "VERSION=33". The other side (Rune) has changed this
line and/or the next line. This is a conflicting change, since git has no
way which version _you_ want.
Now, for you it is probably easy to tell, the part between "<<<" and "==="
is what you had in your working tree, and the part between "===" and ">>>"
is what comes from the branch you just pulled.
So you can resolve it by removing the part that you do not want to have,
including the conflict markers "<<<", "===" and ">>>".
But I could also imagine that you did not want to pull at all... Probably
you wanted to _switch_ to Rune's branch. That would have been "git
checkout -b dev/rune origin/dev/rune" (creating the new _local_ branch
called "dev/rune").
If the latter is what you want, you can still do it, even in the middle of
a conflicted merge, by using "git checkout -f" instead of "git checkout".
Hth,
Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
It seems that the problem is that I changed MY_PATCH_LEVEL to rz1. Problem is, that master just updated PATCH_LEVEL from 32 to 33, and because MY_PATCH_LEVEL and PATCH_LEVEL are defined right next to each other, the automerge fails. I resolved the conflict manually. Try again, Valentin. What is the recommended way of doing this? Do I really have to manually edit and push my own branch each time the master branch changes version? -Rune ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
2007/9/21, Johannes Schindelin <[EMAIL PROTECTED]>: > Hi, Hi Johannes, > This means that you have local changes. Try "git status" and/or "git > diff" to find out which changes those are. The point is: I do not have local changes: I haven't been working on the code nor modifying anything... maybe this error message is more self explanatory: %%% Auto-merging VERSION CONFLICT (content): Merge conflict in VERSION Automatic merge failed; fix conflicts and then commit the result %%% ...and the git-diff goes: %%% diff --cc VERSION index aa9f7e7,7242416..000 --- a/VERSION +++ b/VERSION @@@ -1,6 -1,6 +1,11 @@@ PACKAGE_NAME=LilyPond MAJOR_VERSION=2 MINOR_VERSION=11 ++<<< HEAD/VERSION +PATCH_LEVEL=33 +MY_PATCH_LEVEL= ++=== + PATCH_LEVEL=32 + MY_PATCH_LEVEL=rz1 ++>>> 1982a5513e92f4f01605e9dbfdbb997f314b1cac/VERSION %%% I can't understand what's wrong this different versions thing. Every other branch gives me the message "already up to date". Can you enlighten me? Thanks, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
Hi, On Fri, 21 Sep 2007, Valentin Villenave wrote: > 2007/9/21, Rune Zedeler <[EMAIL PROTECTED]>: > > > Sorry for the noise. > > I get this error message when I try to get your branch: > > %%% > Trying really trivial in-index merge... > VERSION: needs merge > fatal: you need to resolve your current index first This means that you have local changes. Try "git status" and/or "git diff" to find out which changes those are. As a rule of thumb, you should not pull if you have uncommitted changes. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
2007/9/21, Rune Zedeler <[EMAIL PROTECTED]>: > Sorry for the noise. I get this error message when I try to get your branch: %%% Trying really trivial in-index merge... VERSION: needs merge fatal: you need to resolve your current index first Nope. Merging HEAD with 1982a5513e92f4f01605e9dbfdbb997f314b1cac Merging: 239a9680db866039cbab17c10f99a6c13339dc12 fr changing default 1982a5513e92f4f01605e9dbfdbb997f314b1cac removed debug-output (whoops), changed version to rz1 found 1 common ancestor(s): 2ae5726ea4fcbcd40e42678db32d7da3227ef44a Translation of setup.itely to German git-read-tree: fatal: you need to resolve your current index first No merge strategy handled the merge. I don't know how to solve it. I do have merge, rcs and everything installed though (besides, when I try with, for instance, Joe's branch, everything goes fine :( What the hell am I doing wrong? Thanks Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git help
Rune Zedeler skrev: git push [...] dev/rune ... git checkout dev/rz Sorry for the noise. -Rune (really getting annoyed with git) Sorry. -Rune ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Git help
I (think I) made my own branch: [EMAIL PROTECTED]:~/lilypond/lilypond git push ssh+git://[EMAIL PROTECTED]/srv/git/lilypond.git/ dev/rune:dev/rune updating 'refs/heads/dev/rune' from 8505bf3b6810af409fb83e12eba32ff6599a1d17 to 1982a5513e92f4f01605e9dbfdbb997f314b1cac Generating pack... Done counting 9 objects. Result has 5 objects. Deltifying 5 objects. 100% (5/5) done Writing 5 objects. 100% (5/5) done Total 5, written 5 (delta 4), reused 0 (delta 0) refs/heads/dev/rune: 8505bf3b6810af409fb83e12eba32ff6599a1d17 -> 1982a5513e92f4f01605e9dbfdbb997f314b1cac [EMAIL PROTECTED]:~/lilypond/lilypond$ But nevertheless if I [EMAIL PROTECTED]:/tmp$ git clone git://git.sv.gnu.org/lilypond.git [...] [EMAIL PROTECTED]:/tmp$ cd lilypond [EMAIL PROTECTED]:/tmp/lilypond$ git checkout dev/rz error: pathspec 'dev/rz' did not match any. [EMAIL PROTECTED]:/tmp/lilypond$ What went wrong, and WHY THE "#¤%/"#¤/()"#¤/&)"#¤% didn't I get any error message when I did the push??? -Rune (really getting annoyed with git) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax highlighting in LilyPad?
Actually java need not be installed. You can zip together the whole editor distribution, and use it without any installing, but just unzipping. So really it would involve creating a folder structure: lilypondtool -- jedit (containing all necessary plugins in the jars directory) -- jre pdf reader you can also put some predefined properties into, to make everything work out of the box. the jre is also redistributable in this form according to the license. Actually it would be rather easy to create an installer (with nsis for example) that installs lilypond, jedit, java and external pdf reader, and sets the properties file of LilyPondTool to find everything out of the box. It's a pity I don't have time for it :-( Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
