Re: Paper default margins
Hi Neil,
I hope I've lost nothing.
Regards,
Michael
From aa34f02a9eb85aaa39d3ff45f31597d279330461 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= xmichae...@web.de
Date: Sat, 12 Sep 2009 21:55:17 +0200
Subject: [PATCH] Let default margins depend on paper size.
* Make indent and short-indent defaults accessible in paper-defaults-init.ly
* Default margins apply to the paper size set by (ly:set-option 'paper-size)
and are linearly scaled for other paper sizes
* Modify input/regression/page-turn-page-breaking-auto-first-page.ly to work
with the new margin sizes
---
.../page-turn-page-breaking-auto-first-page.ly |4 +-
input/regression/paper-default-margins-a6.ly | 24 +++
input/regression/paper-default-margins-def.ly | 23 +++
input/regression/paper-margins-consistency.ly |4 +-
input/regression/paper-margins-left-margin.ly |4 +-
input/regression/paper-margins-line-width.ly |4 +-
input/regression/paper-margins-no-checks.ly|4 +-
input/regression/paper-margins-overrun.ly |4 +-
input/regression/paper-margins-right-margin.ly |4 +-
input/regression/paper-margins.ly |4 +-
lily/output-def.cc |4 +-
ly/paper-defaults-init.ly | 14 +++-
scm/lily-library.scm | 37 +---
scm/paper.scm | 66 +---
14 files changed, 169 insertions(+), 31 deletions(-)
create mode 100644 input/regression/paper-default-margins-a6.ly
create mode 100644 input/regression/paper-default-margins-def.ly
diff --git a/input/regression/page-turn-page-breaking-auto-first-page.ly b/input/regression/page-turn-page-breaking-auto-first-page.ly
index a9c3f31..0aa5570 100644
--- a/input/regression/page-turn-page-breaking-auto-first-page.ly
+++ b/input/regression/page-turn-page-breaking-auto-first-page.ly
@@ -17,6 +17,6 @@ number to 2 in order to avoid a bad page turn.
\book {
\score {
-{\repeat unfold 40 {a b c d}}
+\relative c' {\repeat unfold 60 {a b c d}}
}
-}
\ No newline at end of file
+}
diff --git a/input/regression/paper-default-margins-a6.ly b/input/regression/paper-default-margins-a6.ly
new file mode 100644
index 000..163a9bf
--- /dev/null
+++ b/input/regression/paper-default-margins-a6.ly
@@ -0,0 +1,24 @@
+\version 2.13.7
+
+\header {
+ texidoc = Default margin values are accessible in paper-defaults-init.ly
+and apply to the default paper size returned by (ly:get-option
+'paper-size). For other paper sizes, they are scaled linearly.
+This also affects head- and foot-separation as well as indents.
+}
+
+someNotes = \repeat unfold 30 { c4 d e f }
+
+\paper {
+ #(set-paper-size a6)
+}
+
+\book {
+ \markup { For other paper sizes, margins are scaled accordingly. }
+ \score {
+\relative c' {
+ \someNotes
+}
+ }
+}
+
diff --git a/input/regression/paper-default-margins-def.ly b/input/regression/paper-default-margins-def.ly
new file mode 100644
index 000..82afc4d
--- /dev/null
+++ b/input/regression/paper-default-margins-def.ly
@@ -0,0 +1,23 @@
+\version 2.13.7
+
+\header {
+ texidoc = Default margin values are accessible in paper-defaults-init.ly
+and apply to the default paper size returned by (ly:get-option
+'paper-size). For other paper sizes, they are scaled linearly.
+This also affects head- and foot-separation as well as indents.
+}
+
+someNotes = \repeat unfold 30 { c4 d e f }
+
+\paper { }
+
+\book {
+ \markup { If the paper size remains default, the margin values from
+paper-defaults-init.ly remain unchanged. }
+ \score {
+\relative c' {
+ \someNotes
+ \someNotes
+}
+ }
+}
diff --git a/input/regression/paper-margins-consistency.ly b/input/regression/paper-margins-consistency.ly
index 1b58b15..a3a7a40 100644
--- a/input/regression/paper-margins-consistency.ly
+++ b/input/regression/paper-margins-consistency.ly
@@ -16,4 +16,6 @@ someNotes = \relative c' { \repeat unfold 40 { c4 d e f } }
line-width = 100 \mm
}
-\score { \someNotes }
+\book {
+ \score { \someNotes }
+}
diff --git a/input/regression/paper-margins-left-margin.ly b/input/regression/paper-margins-left-margin.ly
index 5876196..efb9981 100644
--- a/input/regression/paper-margins-left-margin.ly
+++ b/input/regression/paper-margins-left-margin.ly
@@ -10,4 +10,6 @@ someNotes = \relative c' { \repeat unfold 40 { c4 d e f } }
left-margin = 40 \mm
}
-\score { \someNotes }
+\book {
+ \score { \someNotes }
+}
diff --git a/input/regression/paper-margins-line-width.ly b/input/regression/paper-margins-line-width.ly
index bf6e14d..e38f57f 100644
--- a/input/regression/paper-margins-line-width.ly
+++ b/input/regression/paper-margins-line-width.ly
@@ -10,4 +10,6 @@ someNotes = \relative c' { \repeat unfold 40 { c4 d e f } }
line-width = 100 \mm
}
-\score { \someNotes }
+\book {
+ \score { \someNotes }
+}
Re: support of `to-barline' property in \Dynamics
Ping! Werner == From: Werner LEMBERG w...@gnu.org Subject: support of `to-barline' property in \Dynamics Date: Fri, 25 Sep 2009 21:06:18 +0200 (CEST) I think something like the following patch should be applied so that the \Dynamics context supports the `to-barline' property of hairpins. However, I haven't tested whether it has any negative side effects. Werner == --- engraver-init.ly.old2009-09-16 22:22:31.0 +0200 +++ engraver-init.ly2009-09-25 21:03:23.0 +0200 @@ -350,6 +350,7 @@ \name Dynamics \alias Voice \consists Output_property_engraver + \consists Bar_engraver \consists Piano_pedal_engraver \consists Script_engraver \consists New_dynamic_engraver ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
Ping! Werner == From: Werner LEMBERG w...@gnu.org Subject: Re: line breaks and broken beams Date: Sun, 27 Sep 2009 16:08:31 +0200 (CEST) What's the reason that line breaks are by default forbidden if there is a broken beam crossing the bar line, and that you have to set the `breakable' flag manually to override it? BTW, it is very unpleasant that lilypond doesn't emit any kind of warning if it produces an overlong staff caused by that issue. It silently accumulates unbreakable bars and happily walks out of the right margin. I would consider this behaviour a bug. +1. (I've always felt this way, too.) Then let's drop the IMHO unfounded limitation of not breaking at beams crossing a barline. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
NEWS/changes entry for font switching
Could we get an entry in Documentation/changes.tely about the font switching? I guess we can't show an actual example of it working (unless we make the new font required for compiling lilypond), but it would be nice to have a bullet point about this, at least. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
tracking patches
Could we get a volunteer to keep track of patches? The idea is that whenever somebody sends a patch, if nobody does anything to it within, say, 3 days, you add it to the google issue tracker. If you already read the mailists, I estimate it will take 1 hour each month. That's not much time to volunteer, but it could make a *huge* difference for new contributors. It's really discouraging when you submit something, nobody replies, and you're left wondering if your email client ate the patch or if everybody hates you or something. Absolutely no programming skills or understanding of the patch in question is required; anybody capable of recognizing the English word patch can do this job! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tracking patches
Hi, I will do it. -- Marek Klein http://gregoriana.sk 2009/10/26 Graham Percival gra...@percival-music.ca Could we get a volunteer to keep track of patches? The idea is that whenever somebody sends a patch, if nobody does anything to it within, say, 3 days, you add it to the google issue tracker. If you already read the mailists, I estimate it will take 1 hour each month. That's not much time to volunteer, but it could make a *huge* difference for new contributors. It's really discouraging when you submit something, nobody replies, and you're left wondering if your email client ate the patch or if everybody hates you or something. Absolutely no programming skills or understanding of the patch in question is required; anybody capable of recognizing the English word patch can do this job! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 872 in lilypond: Changes split-page has broken images
Le samedi 24 octobre 2009 à 17:13 +, codesite-nore...@google.com a
écrit :
We don't *have* to discuss it as a tracker issue,
Especially when it's not necessary, as Google Code sends text emails
with horrible indentation, or rather I'm not able to fill Google Code
tracker form in a way to avoid such horrible indentation.
Maybe those aren't good reasons... I have no objection to keeping such TODO
items to
myself in the future, if that's desired.
What about the wiki for this kind of stuff?
Anyway, for this specific issue: if changes.tely is a non-splitted manual,
then the
html page from general/manual.itexi @section Changes will overwrite the
non-splitted
version of changes.itely. I figured that the simplest way to fix this
would be to
make Changes a split manual, thereby putting changes-one-page.html in the
main doc
source output, and also giving us changes/index.html.
How ugly, this gives two almost identical HTML documents
changes-one-page.html and changes/index.html.
There was also an issue with the xref produced by @rchanges{Top,blah}
inside general,
that has to do with the broken html refs that I'm avoiding with that
disgusting find
| xargs sed trick.
One purpose of postprocess_html is avoiding messing with make and shell
to do such tricks.
In general (umm, I mean, as a summary, not anything to do with
general.texi), I'd
like to avoid manual-specific hacks; I like the idea of only having two
types of
manuals: general.texi, which goes in the top output dir, and all the other
manuals,
which are all treated the same.
There are two distinct documentation targets: online (lilypond.org) and
offline (downloadable docball).
As for the offline target, I don't understand why you want to make
General go at the top output dir: why should the directory structure
match the hierarchy between HTML Info manuals? The only grounds I can
see for doing so would be
- navigating directories/typing URL by hand,
- reading the URL to see where you are because the docs structure is not
obvious from the HTML pages themselves.
I hope we put enough effort into the usability of our docs and new web
site so these grounds are not valid.
As for the online docs, we want
- the website in lilypond.org/web (IIRC you suggested lilypond.org,
which changes nothing to the issue)
- the docs in lilypond.org/doc/vX.Y/
Moving HTML output of General one directory up suits none of the two
targets, so it should be abandoned. However, we should generate each
output of General twice, removing for the offline target the download
page and other pages that make sense only for the online web site; I'm
willing to take over this, but not for the to-be-dead build system.
Long-term, I think it would be nice to have the older Changes in the same
document,
but I haven't thought through all the issues involved in doing this.
(namely, what
happens if the syntax changes from 1.4 to 1.8, then again from 1.8 to 2.13
-- how do
we generate the picture for the changes-1.8 page?)
Let's not have a headache for this :-)
Now that I think about it some more, I'm leaning towards abandoning the
idea entirely.
I second this. It's (and it should be with the new web site) easy to
see changes for each new stable branch from the page Documentation from
the web site.
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Fix typo in build script
Hello, this patch fixes a potential bug in scripts/build/grand-replace.py -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com From f253378959983a4777c8169f0011eda5413c5c4e Mon Sep 17 00:00:00 2001 From: Francisco Vila francisco.v...@hispalinux.es Date: Mon, 26 Oct 2009 13:05:50 +0100 Subject: [PATCH] Fix Spanish filename typo in update script. --- scripts/build/grand-replace.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/build/grand-replace.py b/scripts/build/grand-replace.py index dc0697d..abd67ba 100644 --- a/scripts/build/grand-replace.py +++ b/scripts/build/grand-replace.py @@ -46,7 +46,7 @@ copied_files = [ 'txi-de.tex', 'txi-en.tex', 'txi-fr.tex', -'txi-sf.tex', +'txi-es.tex', ] def main (): -- 1.5.6.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: documentation: unreadable html tables
Graham Percival-3 wrote: The languages involved are perl, texinfo, and html. In particular, the documentation is written in texinfo; a perl script (called texi2html) interprets the texinfo files, and outputs html. i have some experience with html; texinfo and perl are fully new to me! furthermore i am working on windows - hope this is not a problem!? The first step is to reproduce the problem in a small example. Try making a tiny texinfo file, which contains the same kind of table as in pitches.itely. I think it's a @multitable, but I'm not 100% certain. i will need to know where i can download this file from! Verify that running texi2html 1.82 on your tiny texinfo file produces the bad output. Then have a look at the output and see what exactly you want to change -- is it just removing the p tags? Would it look better if there was some table attribute being set? etc. Then you need to figure out how to get texi2html to produce the output you want to see. As it happens, texi2html is relatively easy to extend (it's in perl, you can replace any of its built-in fuctions easily, etc). We *could* just add a special overriding function to our texi2html init script, but in this case I'd recommend getting your fix integrated into texi2html itself. This won't help us with 1.82, but when texi2html 1.84 comes out, it'll have the fix. I really hope that you'll take this up; we could really use somebody who's familiar with texi2html. We have a few problems with our texi2html init scripts, and there's other parts of those scripts that work well, but I think other texi2html users could benefit from (like the sectioning-by-numbers), so it would be nice if we could send a patch for this upstream. altogether i think it will take me some time to get familiar with these new components and surroundings! if anybody could advise a practical tutorial both for texinfo and perl this could help a lot. If you're not familiar with perl... well, it's not as easy to learn as python, but I'd still say that it's on the easy side of programming languages. It's much easier than scheme! :) Cheers, - Graham cheers -Eluze -- View this message in context: http://www.nabble.com/documentation%3A-unreadable-html-tables-tp26037552p26060704.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
On 10/23/09 5:52 PM, Ian Hulin i...@hulin.org.uk wrote:
init.ly - Add new parser variables book-output-suffix and book-filename
initialized as #f and empty queue/stack structure.
music-functions-init.ly adds three new functions
* \bookOutputSuffix - to set the output suffix for the \book block
* \bookOutputName - to set output filename for the current \book block
* \bookOuptutNameRevert - to restore the the output filename to the value
prior to that of the last \bookOuputName call.
I think these functions should be named
\setBookOutputSuffix
\setBookOutputName
\revertBookOutputName
\bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
structure. I have used this so we can we could eventually allow users to do
stuff like the following (controlling the names used to open the midi files is
not part of the current patch).
\book {
\bookOutputName My-Homeland
\score {
\bookOutputName Vysehrad
music-declarations ...
\midi{
% midi file gets written to Vysehrad.mid(i)
}
\layout{
}
\bookOutputNameRevert
}
\score {
\bookOuputName Vltava
...
\midi {
% midi file is written to Vltava.mid(i)
}
}
.
.
.
This code doesn't demonstrate the need for \bookOutputNameRevert; the same
thing would happen if the \bookOutputNameRevert were omitted, as far as I
can tell.
lily-library.scm has changes to the filename generating code in
print-book-with to pick up the current values of the new parser variables if
set before using the current output-suffix or result of a call to
ly:parser-output-name.
The routine to get the name now uses as combination of the current output name
and output suffix value to at as a key for the internal a-list of filenames
being written to during a compilation.
lily-guile.hh, lily-guile.cc and parser.yy have code that I would like to use
to re-initialize book-output-suffix and book-filename to initial values on
encountering the end of a \book block, but I've hit a dead-end currently in
this as the code I tried to use in parser.yy negates the effect of calling
the new functions altogether. If anyone with more experience of how bison
works has any better ideas as to how do this I'd be interested in hearing
them.
It would seem to me (this is a relatively poorly informed opinion) that
setting them to the initial values at the *start* of a book block would be a
more sane way to do it that to reset them at the end of a book block. Or is
there something I'm missing?
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH] : Supply missing documentation strings in music-function-init.ly
Neil Puttock wrote:
2009/10/25 Ian Hulin i...@hulin.org.uk:
Thanks for the feedback, Neil. Is this OK to push now?
Sure is.
Thanks,
Neil
Woo-hoo, green light! Could someone with the relevant privileges push
this to the main git repository, please?
Cheers,
Ian
From 48d7cf640be9b78b398bc61d00aedbaa795cf540 Mon Sep 17 00:00:00 2001
From: Ian Hulin i...@hulin.org.uk
Date: Sun, 25 Oct 2009 22:42:37 +
Subject: [PATCH] [PATCH] Add missing documentation strings in property-init.ly and
music-functions-init.ly.
---
ly/music-functions-init.ly | 22 --
ly/property-init.ly| 10 +-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index 718615a..4283157 100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -449,7 +449,7 @@ or @code{\GrobName\})
%% because music identifiers are not allowed at top-level.
pageBreak =
#(define-music-function (location parser) ()
- (_i Force a page break. May be used at toplevel (ie between scores or
+ (_i Force a page break. May be used at toplevel (i.e. between scores or
markups), or inside a score.)
(make-music 'EventChord
'page-marker #t
@@ -584,13 +584,16 @@ parenthesize =
partcombine =
#(define-music-function (parser location part1 part2) (ly:music? ly:music?)
- (make-part-combine-music parser
- (list part1 part2)))
+ (_i Take the music in @var{part1} and @var{part2} and typeset so that they share a staff.)
+ (make-part-combine-music parser
+ (list part1 part2)))
pitchedTrill =
#(define-music-function
(parser location main-note secondary-note)
(ly:music? ly:music?)
+ (_i Print a trill with @var{main-note} as the main note of the trill and
+print @var{secondary-note} as a stemless note head in parentheses.)
(let*
((get-notes (lambda (ev-chord)
(filter
@@ -622,8 +625,12 @@ pitchedTrill =
quoteDuring =
#(define-music-function
- (parser location what main-music)
- (string? ly:music?)
+ (parser location what main-music)
+ (string? ly:music?)
+ (_i Indicate a section of music to be quoted. @var{what} indicates the name
+of the quoted voice, as specified in an @code{\\addQuote} command.
+...@var{main-music} is used to indicate the length of music to be quoted;
+usually contains spacers or multi-measure rests.)
(make-music 'QuoteMusic
'element main-music
'quoted-music-name what
@@ -803,7 +810,10 @@ tweak =
unfoldRepeats =
#(define-music-function (parser location music) (ly:music?)
- (unfold-repeats music))
+ (_i Force any @code{\\repeat volta}, @code{\\repeat tremolo} or
+...@code{\\repeat percent} commands in @var{music} to be interpreted
+as @code{\\repeat unfold}.)
+ (unfold-repeats music))
diff --git a/ly/property-init.ly b/ly/property-init.ly
index 4983506..a73848e 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -278,7 +278,9 @@ phrasingSlurNeutral = \revert PhrasingSlur #'direction
% dash-patterns (make-simple-dash-definition defined at top of file)
phrasingSlurDashPattern =
#(define-music-function (parser location dash-fraction dash-period)
- (number? number?)
+ (number? number?)
+ (_i Set up a custom style of dash pattern for @var{dash-fraction} ratio of
+line to space repeated at @var{dash-period} interval.)
#{
\override PhrasingSlur #'dash-definition =
$(make-simple-dash-definition dash-fraction dash-period)
@@ -301,10 +303,16 @@ phrasingSlurSolid =
pointAndClickOn =
#(define-music-function (parser location) ()
+ (_i Enable generation of code in final-format (e.g. pdf) files to reference the
+originating lilypond source statement;
+this is helpful when developing a score but generates bigger final-format files.)
(ly:set-option 'point-and-click #t)
(make-music 'SequentialMusic 'void #t))
+
pointAndClickOff =
#(define-music-function (parser location) ()
+ (_i Suppress generating extra code in final-format (e.g. pdf) files to point
+back to the lilypond source statement.)
(ly:set-option 'point-and-click #f)
(make-music 'SequentialMusic 'void #t))
--
1.6.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Need interface/data structure design advice
Hi, I am working on accordion register symbol typesetting right now. Up to now, there are some font elements in the font, and some basic hackish stuff in the snippets. Right now I am stuck in the interfaces. The focus right now is discant registers, other registers have similar concerns. Now here is the basic data I have to deal with: The register symbols have a basic symbol, and they have dots that are on or off. (cf URL:http://en.wikipedia.org/wiki/Accordion_reed_ranks__switches) The German page URL:http://de.wikipedia.org/wiki/Register_(Akkordeon) has quite a few more details with regard to naming schemes. The dots correspond to reed banks. For some accordions, there are unusual reed banks (and dots), so the user should be able to add dot coordinates and corresponding data. For each dot, there will be a set of coordinates where to draw it on the accordion symbol, a default midi instrument and a default pitch adjustment: accordions have reed banks that are one octave off, but they also have reed banks that are only a few cents off-pitch, usually with a linear tuning curve (linear in cents/semitone, with the lower notes being more cents off and the higher less). So we want a default midi instrument per reed bank, with an optional fine-tuning (translated in pitch bend). Now to registers: a register is a combination of reed banks (and dots on the symbol). A register has a name. I don't think that cleverness is warranted for pulling apart register names like 101 or MM or whatever else: the combinations are few enough that it is fine not to pick apart those strings but just use them as identifier for one register each. Registers should have an override regarding the used midi instruments in order to adapt them to available patches. Now there is an additional complication: if the lowest used reed bank is not at nominal pitch (namely either 16 or 4), notation and sound are not in accord. It is common to write at pitch and affix an 8 or more wordy equivalent at the top or bottom (depending on whether to play one octave lower or higher than written) of the register symbol to indicate that one should play one octave higher/lower in order to get pitch. If this octavation (in playing) is dissolved, there is loco at the next register symbol. So usually the register symbol should interact in some manner with \ottava specs. Accordions are usually limited enough in range not to need ottava notation in addition to registration: the keyboard for piano accordions tends to go from f to a''', really big ones e to c. Chromatic button accordions are a bit more impressive, mine has notes from a, to bes, so some possible use for ottava changes that are not directly related to register changes is there: those would likely use ottava brackets independent of the current register. It is common to have different registers for different repeats and write that out. That would be nice to have in Midi. However, it is also common to have different dynamics for different repeats, and Lilypond has no way to deal with that right now IIRC. So that's a different topic and should likely be addressed in the context of repeats without special consideration of accordions. Ok, all this verbage: there need to be ways to specify the available reed banks, their dot layout, their midi impact and audible octave. Registers have a reed bank combination and a sounding octave of the lowest reed bank, and should have an override for the chosen midi output. This situation is principally the same in bass registrations for free bass, and with some modifications for standard bass (cf. URL:http://www.accordions.com/index/art/stradella.shtml) where some reed banks are used for chords, and some for single bass notes (usually sounding the chord banks as well through mechanical couplers). So the same mechanisms for tweaking, dot layout specification, register naming, midi impact, and use should apply. What kind of data structure can I use such that one can tweak with a reasonable interface? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
Carl Sorensen wrote:
On 10/23/09 5:52 PM, Ian Hulin i...@hulin.org.uk wrote:
init.ly - Add new parser variables book-output-suffix and book-filename
initialized as #f and empty queue/stack structure.
music-functions-init.ly adds three new functions
* \bookOutputSuffix - to set the output suffix for the \book block
* \bookOutputName - to set output filename for the current \book block
* \bookOuptutNameRevert - to restore the the output filename to the value
prior to that of the last \bookOuputName call.
I think these functions should be named
\setBookOutputSuffix
\setBookOutputName
\revertBookOutputName
You're probably right. It's just that in music-functions-init the
source likes to group all the functions alphabetically, and this was a
way of getting all the related things together.
It's a shame we haven't got a way of declaring generic functions with
the parser so you could code \bookCommand \OutputSuffix mysuffix.
Well, I suppose we have if you imitate what \markup does in the parser
but I'm not going to go there...
So I'll go with your suggestions.
\bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
structure. I have used this so we can we could eventually allow users to do
stuff like the following (controlling the names used to open the midi files is
not part of the current patch).
\book {
\bookOutputName My-Homeland
\score {
\bookOutputName Vysehrad
music-declarations ...
\midi{
% midi file gets written to Vysehrad.mid(i)
}
\layout{
}
\bookOutputNameRevert
}
\score {
\bookOuputName Vltava
...
\midi {
% midi file is written to Vltava.mid(i)
}
}
.
.
.
This code doesn't demonstrate the need for \bookOutputNameRevert; the same
thing would happen if the \bookOutputNameRevert were omitted, as far as I
can tell.
Consider this in one file Smetana.ly:
;; Music for Má Vlast
\book {
\bookOutputName My-Homeland
\score {
\bookOutputName Vyšehrad
...
}
\score {
\bookOutputName Vltava
...
}
%% three more \score blocks setting the output name
\score {
\bookOutputName Blanik
...
}
}
;; Music for Bartered Bride Overure
\book {
% No \bookOutputName here
% Until scoping for \book blocks is sorted out,
% this block will get output to Blanik.pdf and Blanik.midi.
\score {
...
}
}
lily-library.scm has changes to the filename generating code in
print-book-with to pick up the current values of the new parser variables if
set before using the current output-suffix or result of a call to
ly:parser-output-name.
The routine to get the name now uses as combination of the current output name
and output suffix value to at as a key for the internal a-list of filenames
being written to during a compilation.
lily-guile.hh, lily-guile.cc and parser.yy have code that I would like to use
to re-initialize book-output-suffix and book-filename to initial values on
encountering the end of a \book block, but I've hit a dead-end currently in
this as the code I tried to use in parser.yy negates the effect of calling
the new functions altogether. If anyone with more experience of how bison
works has any better ideas as to how do this I'd be interested in hearing
them.
It would seem to me (this is a relatively poorly informed opinion) that
setting them to the initial values at the *start* of a book block would be a
more sane way to do it that to reset them at the end of a book block. Or is
there something I'm missing?
D'oh, I was getting blown away by having to learn Bison and work out
what was doing what, with which, to what, when, and by whom. . .
I'll try it out.
HTH,
Thank, you, yes it does,
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix typo in build script
Thanks, applied. Cheers, - Graham On Mon, Oct 26, 2009 at 01:13:17PM +0100, Francisco Vila wrote: Hello, this patch fixes a potential bug in scripts/build/grand-replace.py -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com From f253378959983a4777c8169f0011eda5413c5c4e Mon Sep 17 00:00:00 2001 From: Francisco Vila francisco.v...@hispalinux.es Date: Mon, 26 Oct 2009 13:05:50 +0100 Subject: [PATCH] Fix Spanish filename typo in update script. --- scripts/build/grand-replace.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/build/grand-replace.py b/scripts/build/grand-replace.py index dc0697d..abd67ba 100644 --- a/scripts/build/grand-replace.py +++ b/scripts/build/grand-replace.py @@ -46,7 +46,7 @@ copied_files = [ 'txi-de.tex', 'txi-en.tex', 'txi-fr.tex', -'txi-sf.tex', +'txi-es.tex', ] def main (): -- 1.5.6.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: documentation: unreadable html tables
On Mon, Oct 26, 2009 at 07:18:54AM -0700, -Eluze wrote: Graham Percival-3 wrote: The languages involved are perl, texinfo, and html. In particular, the documentation is written in texinfo; a perl script (called texi2html) interprets the texinfo files, and outputs html. i have some experience with html; texinfo and perl are fully new to me! furthermore i am working on windows - hope this is not a problem!? Working on windows will be no problem. The first step is to reproduce the problem in a small example. Try making a tiny texinfo file, which contains the same kind of table as in pitches.itely. I think it's a @multitable, but I'm not 100% certain. i will need to know where i can download this file from! Please see the Contributor's Guide, particularly the section about windows git. altogether i think it will take me some time to get familiar with these new components and surroundings! if anybody could advise a practical tutorial both for texinfo and perl this could help a lot. You don't need a lot of texinfo; a seven-line file should be fine for your testing. As for perl, there are many tutorials on the internet devoted to it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
On Mon, Oct 26, 2009 at 12:11:55PM -0600, Carl Sorensen wrote: On 10/23/09 5:52 PM, Ian Hulin i...@hulin.org.uk wrote: music-functions-init.ly adds three new functions * \bookOutputSuffix - to set the output suffix for the \book block * \bookOutputName - to set output filename for the current \book block * \bookOuptutNameRevert - to restore the the output filename to the value prior to that of the last \bookOuputName call. I think these functions should be named \setBookOutputSuffix \setBookOutputName \revertBookOutputName No! Having \set vs. \setBlahBlah is a nightmare for newbies. Sorry, my brain is fried at the moment, so I have no alternative suggestions. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Need interface/data structure design advice
On 10/26/09 1:41 PM, David Kastrup d...@gnu.org wrote: Hi, I am working on accordion register symbol typesetting right now. Up to now, there are some font elements in the font, and some basic hackish stuff in the snippets. Right now I am stuck in the interfaces. The focus right now is discant registers, other registers have similar concerns. Now here is the basic data I have to deal with: The register symbols have a basic symbol, and they have dots that are on or off. (cf URL:http://en.wikipedia.org/wiki/Accordion_reed_ranks__switches http://en.wikipedia.org/wiki/Accordion_reed_ranks__switches ) The German page URL:http://de.wikipedia.org/wiki/Register_(Akkordeon) has quite a few more details with regard to naming schemes. The dots correspond to reed banks. For some accordions, there are unusual reed banks (and dots), so the user should be able to add dot coordinates and corresponding data. I'd lean towards something like bank-properties , an alist containing the properties of a bank: ((x-offset . bank-x-offset) (y-offset . bank-y-offset) (pitch-offset . bank-pitch-offset) (midi-intsrument . bank-midi-instrument)) By making it an alist, any of the properties can be left out and filled in by default, and the order of the properties doesn't matter. It's the way most LilyPond properties are set. Alternatively, bank-properties could be a list: (bank-x-offset bank-y-offset bank-pitch-offset bank-midi-instrument) This has less typing, but makes ordering important. It also requires non-standard accessor functions to get particular values, whereas the alist can use standard LilyPond accessor functions (like chain-assoc-get). The available banks would then be an alist of banks and bank-properties: (define my-available-banks '((bank1 . ((x-offset . x-offset1) (y-offset . y-offset1) (pitch-offset . pitch-offset1) (midi-instrument . midi-instrument1))) (bank2 . ((x-offset . x-offset2) (y-offset . y-offset2) (pitch-offset . pitch-offset2) (midi-instrument . midi-instrument2))) (bank3 . ((x-offset . x-offset3) (y-offset . y-offset3) (pitch-offset . pitch-offset3) (midi-instrument . midi-instrument3) And it's really straightforward to add an additional bank. For each dot, there will be a set of coordinates where to draw it on the accordion symbol, a default midi instrument and a default pitch adjustment: accordions have reed banks that are one octave off, but they also have reed banks that are only a few cents off-pitch, usually with a linear tuning curve (linear in cents/semitone, with the lower notes being more cents off and the higher less). So we want a default midi instrument per reed bank, with an optional fine-tuning (translated in pitch bend). Now to registers: a register is a combination of reed banks (and dots on the symbol). A register has a name. I don't think that cleverness is warranted for pulling apart register names like 101 or MM or whatever else: the combinations are few enough that it is fine not to pick apart those strings but just use them as identifier for one register each. Here I'd have a register that's a list of the banks that apply: (bank1 bank3 bank7) accordion-registers would then be an alist that contains all of the available registers: (define my-accordion-registers '((register1 . (bank1 bank3 bank7)) (register2 . (bank2)) (register3 . (bank4 bank6)) (register4 . (bank 5 Again, it's really straightforward to add an additional register. An accordion could be defined as an alist containing available banks and available registers: (define my-accordion '((available-banks . my-available-banks) (available-registers . my-accordion-registers))) One could either define a set of different accordions, each with the appropriate banks and registers; or define a full set of accordion banks and accordion registers that cover all possible accordions. Registers should have an override regarding the used midi instruments in order to adapt them to available patches. I'm not sure what this means, so I can't really comment on it. Now there is an additional complication: if the lowest used reed bank is not at nominal pitch (namely either 16 or 4), notation and sound are not in accord. It is common to write at pitch and affix an 8 or more wordy equivalent at the top or bottom (depending on whether to play one octave lower or higher than written) of the register symbol to indicate that one should play one octave higher/lower in order to get pitch. If this octavation (in playing) is dissolved, there is loco at the next register symbol. So usually the register symbol should interact in some manner with \ottava specs. Accordions are usually limited enough in range not to need ottava notation in addition to registration: the keyboard for piano accordions tends to go from f
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
On 10/26/09 3:09 PM, Graham Percival gra...@percival-music.ca wrote: On Mon, Oct 26, 2009 at 12:11:55PM -0600, Carl Sorensen wrote: On 10/23/09 5:52 PM, Ian Hulin i...@hulin.org.uk wrote: music-functions-init.ly adds three new functions * \bookOutputSuffix - to set the output suffix for the \book block * \bookOutputName - to set output filename for the current \book block * \bookOuptutNameRevert - to restore the the output filename to the value prior to that of the last \bookOuputName call. I think these functions should be named \setBookOutputSuffix \setBookOutputName \revertBookOutputName No! Having \set vs. \setBlahBlah is a nightmare for newbies. Sorry, my brain is fried at the moment, so I have no alternative suggestions. You're right, of course. The problem is that Ian wants to really have a revert option (and we can't use revert either, because of confusion with \revert). How about \useBookOuptutSuffix \useBookOutputName \usePreviousBookOutputName or \bookOutputSuffix \bookOutputName \bookOutputNameUsePrevious (I hate the english of this, but it sorts where it belongs and it captures the intent). Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
On Mon, Oct 26, 2009 at 03:53:55PM -0600, Carl Sorensen wrote: On 10/26/09 3:09 PM, Graham Percival gra...@percival-music.ca wrote: No! Having \set vs. \setBlahBlah is a nightmare for newbies. Sorry, my brain is fried at the moment, so I have no alternative suggestions. The problem is that Ian wants to really have a revert option (and we can't use revert either, because of confusion with \revert). \bookOutputSuffix \bookOutputName \bookOutputNameUsePrevious (I hate the english of this, but it sorts where it belongs and it captures the intent). I like these. And it fits with some proposals for GLISS, which will start when GUB or the new website is finished. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
On 10/26/09 1:47 PM, Ian Hulin i...@hulin.org.uk wrote:
Carl Sorensen wrote:
On 10/23/09 5:52 PM, Ian Hulin i...@hulin.org.uk wrote:
\bookOutputName and \bookOuptutNameRevert use the book-filename as a stack
structure. I have used this so we can we could eventually allow users to do
stuff like the following (controlling the names used to open the midi files
is
not part of the current patch).
\book {
\bookOutputName My-Homeland
\score {
\bookOutputName Vysehrad
music-declarations ...
\midi{
% midi file gets written to Vysehrad.mid(i)
}
\layout{
}
\bookOutputNameRevert
}
\score {
\bookOuputName Vltava
...
\midi {
% midi file is written to Vltava.mid(i)
}
}
.
.
.
This code doesn't demonstrate the need for \bookOutputNameRevert; the same
thing would happen if the \bookOutputNameRevert were omitted, as far as I
can tell.
Consider this in one file Smetana.ly:
;; Music for Má Vlast
\book {
\bookOutputName My-Homeland
\score {
\bookOutputName Vyšehrad
...
}
\score {
\bookOutputName Vltava
...
}
%% three more \score blocks setting the output name
\score {
\bookOutputName Blanik
...
}
}
;; Music for Bartered Bride Overure
\book {
% No \bookOutputName here
% Until scoping for \book blocks is sorted out,
% this block will get output to Blanik.pdf and Blanik.midi.
\score {
...
}
}
Yes, I understand the issues with (the lack of) scoping of bookOutputNames.
But where in this example would you put \bookOutputNameRevert (or
\bookOutputNameUsePrevious)?
If you put it after the the last score in My-Homeland, then I guess it
would go to the default values again.
It seems to me the problem could easily be resolved here by just giving a
bookOutputName to Bartered Bride Overture (and if one is using
bookOutputName in some of the books, it seems reasonable to use it for all
of the books). It also seems that one could just set it to in order to
use the default, and there wouldn't be a need for a separate revert.
Also, following on with the discussion we had on the earlier message, if
every \book block initializes the bookOutputName to the default value, that
implements a scoping rule, IIUC.
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH] : Supply missing documentation strings in music-function-init.ly
Neil already pushed it yesterday. Thanks, Carl On 10/26/09 12:47 PM, Ian Hulin i...@hulin.org.uk wrote: Neil Puttock wrote: 2009/10/25 Ian Hulin i...@hulin.org.uk: Thanks for the feedback, Neil. Is this OK to push now? Sure is. Thanks, Neil Woo-hoo, green light! Could someone with the relevant privileges push this to the main git repository, please? Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
