Lilypond-book: Implement MusicXML support in lilypond-book
This patch adds support for including MusicXML files into
documents processed by lilypond-book. In particular:
-) HTML: <musicxmlfile options>filename.xml</musicxmlfile>
-) TeX: \musicxmlfile[options]{filename.xml}
-) Texinfo: @musicxmlfile[options]{filename.xml}
Since MusicXML is so verbose, it doesn't make much sense to
support inline MusicXML.
The snippets are basically processed like a lilypond file,
except that musicxml2ly is run on them (with the options given
for the snippet) and the returned lilypond code is then processed
as if it were the original contents of the file.
For the output links, however, the html and texinfo pages will
link to the .xml/.mxl file rather than the intermediate .ly file.
If a file has the extension .mxl, it is assumed to be a compressed
MusicXML file (alternatively, the 'compressed' snippet option can
be given).
What's missing is proper documentation in "Usage". I'm unsure
how to document such new snippet types...
Patrick McCarty [Thu, 18 Aug 2011 06:18:46 +0000 (23:18 -0700)]
Guile v2: Set 'show-file-name option correctly.
This fixes a compile issue with Guile v2.
Using the `debug-enable' procedure with non-boolean debug options raises
an error with Guile v2. The internal type for `show-file-name' is
SCM_OPTION_SCM, and this is why we can't use `debug-enable' here.
The fix is to use `debug-set!', passing the unquoted option name and
the value as arguments (as stated in the Guile documentation).
Werner Lemberg [Thu, 18 Aug 2011 06:04:35 +0000 (08:04 +0200)]
[doc] Try to omit leading # if not necessary.
I wonder whether a leading ' should be omitted also, but I think it doesn't
really harm because it's never part of a Scheme expression (unlike to `#f'
or `#t').
Werner Lemberg [Wed, 17 Aug 2011 17:22:21 +0000 (19:22 +0200)]
[doc] Handle leading dash in @code.
Due to the default value of texinfo.tex's `@allowcodebreaks true', line
breaks after a dash within @code is allowed; this makes sense due to the
very long Scheme identifiers containing many dashes. However, we have a lot
of `@code{-1}', and it looks very ugly to have a line break within this
expression.
This patch fixes it (also converting many `@code' to the correct `@option'),
using `@w{...}' where appropriate. However, I've done it only for the
English documentation, expecting the translators to follow up.
Mike Solomon [Wed, 17 Aug 2011 08:18:00 +0000 (10:18 +0200)]
Fixes issue 620.
Also fixes issue 591 (which was previously fixed, but is re-fixed
here).
Does this by making the extents of an axis group maleable depending
on the interfaces one chooses to use for bounds in the property
bound-alignment-interfaces
See generic_bound_extent in axis-group-interface.cc to see
how this works. All other changes get the data pumped into
this function.
Get rid of some compiler warnings; Fix chdir handling of errors
-) Some "unused parameter" warnings
-) Some "ignoring return value" are a bit trickier. They are bad coding style:
o) the file-name.cc one returns a string with undefined contents if getcwd
fails, which might either crash guile or lead to other bugs.
o) the lily-parser-scheme.cc warning was also a programming error (if you
used --output=dir/file, and dir/ had the wrong permissions, then
lilypond would not print an error, but simply put the output file into
the current directory without telling the user!).
In this case (output dir explicitly requested, but not possible
to change there), I think it's best to exit lilypond with an
error.
-) signed/unsigned warning in glissando-engraver.cc, where we already
had a check for negative values, so explicitly casting to unsigned
shuts up the compiler.
-) Remove unneccessary #(set-paper-size "a6") in the regtests
-) fix bad texinfo code in function documentation
Allow the user to specify which messages (s)he wants to see on stderr:
The lilypond code basically stays the same, I only added a loglevel
global variable, which is used in the warning/error*/progress*/success
functions (ly:warning, ly:error, etc. in Scheme). If the proper level
is not set for a message, it is not printed.
There are only some larger changes:
-) Global var be_verbose_global replaced by loglevel (in warn.cc, accessor
is_loglevel(...); much finer-grained)
-) New functions debug_output, which replaces code like:
if (be_verbose_global) {
progress_indication (...)
}
-) Move all scheme log functions to warn-scheme.cc
-) Add (optional) source location info to warning/error/log messages
All changes were done to warn.cc and to the member of the Input class
(apparently, we have two parallel error-reporting "frameworks" in
lilypond...).
Note for all functions in warn.cc (not for the members of Input):
The debug_output function (and progress_indication and message) have
an optional argument to specify whether the output of the message
should always start on a new line or continue the previous output.
All functions of the Input class now are just a front-end for the functions
in warn.cc
Documentation for this new feature is still missing (both in the AU
as well as in the CG).
Fix 1214: Don't crash with \relative c' \new Voice {...}
Also add better warnings if the quoted music is empty
or cannot be found.
Also works if a complete voice (or a more complex structure) is
quoted, i.e. when one uses
\addQuote "quote" \new Voice {...}
\addQuote "quote" \relative c' \new Voice {...}
As a positive (unintended) side-effect, quoting music
with parallel sections, i.e. containing << { ...} \\ { ...} >>
now also quote those notes.
Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices
If a voice was quoted that created a subvoice, add-quotable wrongly selected
only that subvoice for quoting rather than the original voice.
The proper fix is to correctly use the assoc list returned by
recording-group-emulate. We need to hand it a proper unique voice name
and can then extract the events for just this voice, no matter which other
voices are created.
If the music expression passed to \addQuote is a voice itself, we only use
its contents for quoting.
GUILE debug: Revert part of 52bea08ef73a55ee, so the file of an error is shown
When debug is set to #f, a guile error, like for example (cdr '()) will only
show the error message itself, but no indication whatsoever where the error
occured. This makes debugging scheme bugs in our lilypond code basically
impossible.
This patch properly fixes the debug settings, by either setting 'debug for
guile <2.0 or setting the finer-grained debug options for guile >=2.0.
That's also the correct fix that Ian Hulin suggest in a private mail.
Keith OHara [Sat, 6 Aug 2011 23:09:41 +0000 (16:09 -0700)]
Clean troublesome regression tests
beam-skip.ly: choose input that demonstrates the bug of issue 1706,
but without cyclic dependencies and variable output.
nested-property-revert.ly: the test fails because the functionality
it tests was removed with commit 47473646b1.
James Lowe [Sun, 7 Aug 2011 10:45:53 +0000 (11:45 +0100)]
Doc: NR 5.5.4 - Modifying ties and slurs
Started off as adding a @cindex for 'control points'.
Ended up tidying up the overall description of how the bezier
curve describes its arc.
Then noted a reference to a non-existant property of the TieColumn
object - so I have referred to the correct interface for this property
and added an @seealso.