Re: [PATCH] Make some local functions public (was: Re: lily-library.scm question)
Jay Anderson wrote: > Actually, I like this much better. A couple things: > - It doesn't handle an empty list as input. Or is an error the correct > behavior? > - I'm not the biggest fan of multiple return values. You could do > (cons (take lst (1+ i)) (drop lst (1+ i))) instead (unless there are > efficiencies in the split-at approach). > - I think (list lst) is clearer than `(,lst). Thanks Jay, take/drop seems clearer (and somehow more appropriate) than call-with-values/split-at. Also thanks for testing '() -- it slipped my mind during all the srfi excitement. The original function handles empty lists so we need to keep it in. Maybe at some point I'll make yet another patch! - Mark ___ (use-modules (srfi srfi-1)) (define-public (split-at-predicate predicate lst) "Split a list into 2 lists at the first element that returns #f for (PREDICATE previous_element element). Return the two parts as a pair. Example: (split-at-predicate < '(1 2 3 2 1)) ==> ((1 2 3) . (2 1))" (if (null? lst) (list lst) (let ((i (list-index predicate (cdr lst) lst))) (if i (cons (take lst (1+ i)) (drop lst (1+ i))) (list lst) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2.14 release plans
Progress has been slow for the past month. I'd like to be able to claim that I'll be getting more done in the next few weeks, but in all honesty I doubt it. If anything, I'll be engaged in *more* household projects, not less. With that in mind, I think we're looking at 2.14 being at the end of July at the earliest. Therefore, I'd like to invite Joe to merge the new vertical spacing code in the next week or so (or whenever he feels ready). I'm also tentatively thinking about pushing to get the website ready for 2.14. I still think the English version can be finished in the next week, which would give the translators a month. Yes, the website doesn't need to be introduced at the same time as a new major version, but I think it'd be cute to do it that way. Including both these "features" would fit better with the overall release plan, too: add stuff for the 2.even release, then spend the next few months fixing issues. If we don't include the new vertical spacing in 2.14, then we'll have a lot of pressure to open up 2.15 as soon as possible, which will result in a 2.14.1, .2, and *maybe* .3. Ideally, we'd like to keep 2.14 around for longer. After a few days of discussion about this, I'll make a list of 2.14 release issues on the google tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Make some local functions public (was: Re: lily-library.scm question)
On Mon, Jun 22, 2009 at 6:03 PM, Mark Polesky wrote: > I know, I know, I just won't let this die. I rewrote this silly > function yet again (by now it's more of a programming exercise > than anything else). But the things I've learned from everyone so > far have found their way into my other LilyPond work, so I don't > think it's a waste of time. > > I discovered 2 procedures from srfi-1 that can work in tandem for > this: list-index and split-at. I'm left wondering if this is an > improvement or not. I don't know the implications of use-modules; > perhaps there's some overhead that I don't know about that isn't > worth it. Or maybe list-index and split-at are less optimal than > than Jay's loop-and-reverse solution. > > Just wanting to learn... > > Thanks, > Mark > ___ > > (use-modules (srfi srfi-1)) > > (define-public (split-at-predicate predicate lst) > "Split a list into 2 lists at the first element that returns #f for > (PREDICATE previous_element element). Return the two parts as a pair. > Example: (split-at-predicate < '(1 2 3 2 1)) ==> ((1 2 3) . (2 1))" > (let ((i (list-index predicate(cdr lst) lst))) > (if i > (call-with-values (lambda () (split-at lst (1+ i))) > cons) > `(,lst > ___ > Actually, I like this much better. A couple things: - It doesn't handle an empty list as input. Or is an error the correct behavior? - I'm not the biggest fan of multiple return values. You could do (cons (take lst (1+ i)) (drop lst (1+ i))) instead (unless there are efficiencies in the split-at approach). - I think (list lst) is clearer than `(,lst). -Jay ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Make some local functions public (was: Re: lily-library.scm question)
Jay Anderson wrote: > > last-pair is an O(n) operation, since it has to traverse the whole list, > > making split-at-predicate O(n^2) instead of O(n), as it should be. You'd be > > better off building L0 backwards and reversing it at the end, so that the > > element you need is always at the beginning of a list. > > Also it should avoid length when a null? check will do. Here's the > function with those changes: > > (define-public (split-at-predicate predicate lst) > "Split a list into 2 lists at the first element that returns #f for > (predicate previous_element element). Return the two parts as a pair. > Example: (split-at-predicate < '(1 2 3 2 1)) ==> ((1 2 3) . (2 1))" > (if (or (null? lst) (null? (cdr lst))) > (list lst) > (let loop ((lst-a (list (car lst))) (lst-b (cdr lst))) > (cond ((null? lst-b) (list lst)) > ((predicate (car lst-a) (car lst-b)) > (loop (cons (car lst-b) lst-a) (cdr lst-b))) > (else (cons (reverse lst-a) lst-b)) I know, I know, I just won't let this die. I rewrote this silly function yet again (by now it's more of a programming exercise than anything else). But the things I've learned from everyone so far have found their way into my other LilyPond work, so I don't think it's a waste of time. I discovered 2 procedures from srfi-1 that can work in tandem for this: list-index and split-at. I'm left wondering if this is an improvement or not. I don't know the implications of use-modules; perhaps there's some overhead that I don't know about that isn't worth it. Or maybe list-index and split-at are less optimal than than Jay's loop-and-reverse solution. Just wanting to learn... Thanks, Mark ___ (use-modules (srfi srfi-1)) (define-public (split-at-predicate predicate lst) "Split a list into 2 lists at the first element that returns #f for (PREDICATE previous_element element). Return the two parts as a pair. Example: (split-at-predicate < '(1 2 3 2 1)) ==> ((1 2 3) . (2 1))" (let ((i (list-index predicate(cdr lst) lst))) (if i (call-with-values (lambda () (split-at lst (1+ i))) cons) `(,lst ___ p.s. see the current version for comparison in this post: http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00226.html ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB / autoconf out-of-tree builds
On Mon, Jun 22, 2009 at 11:23:09AM +0200, Jan Nieuwenhuizen wrote: > Op woensdag 17-06-2009 om 13:24 uur [tijdzone -0700], schreef Graham > Percival: > > > I've tracked down the srcdir vs. builddir problem to autoconf. > > Is this now fixed? It seems that > > > The $(TOPDOC_TXT_FILES) includes RELEASE-COMMIT, which is only > > created in the builddir, not the srcdir. > > RELEASE-COMMIT is not included in TOPDOC_TXT_FILES in master? That's what I don't get! TOPDOC_TXT_FILES is defined as TOPDOC_TXT_FILES = $(addprefix $(top-build-dir)/Documentation/topdocs/$(outdir)/,$(addsuffix .txt,$(TOPDOC_FILES))) and yet a fresh "make lilypond" in gub produces this line: ln /home/lilypond/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/ChangeLog /home/lilypond/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/RELEASE-COMMIT ... (it's a whole screenful of files to be ln'd) but, as expected, ChangeLog and RELEASE-COMMIT don't exist in the ../src/.. dir. I've attached the log file. I just don't know where this "ln" command is coming from! Cheers, - Graham make -f lilypond.make make[1]: Entering directory `/home/lilypond/gub' python bin/gub --platform=linux-x86 'git://git.sv.gnu.org/lilypond.git?branch=master' darwin-ppc::'git://git.sv.gnu.org/lilypond.git?branch=master' darwin-x86::'git://git.sv.gnu.org/lilypond.git?branch=master' mingw::'git://git.sv.gnu.org/lilypond.git?branch=master' linux-64::'git://git.sv.gnu.org/lilypond.git?branch=master' linux-ppc::'git://git.sv.gnu.org/lilypond.git?branch=master' freebsd-x86::'git://git.sv.gnu.org/lilypond.git?branch=master' freebsd-64::'git://git.sv.gnu.org/lilypond.git?branch=master' calculating dependencies must rebuild[linux-x86]: linux-ppc::lilypond darwin-x86::lilypond *** Stage: pkg_install (cross/gcc-core, linux-x86) *** Stage: pkg_install (glibc-core, linux-x86) *** Stage: pkg_install (cross/gcc-core, linux-ppc) *** Stage: pkg_install (glibc-core, linux-ppc) *** Stage: pkg_install (cross/gcc-core, linux-64) *** Stage: pkg_install (glibc-core, linux-64) building package: linux-ppc::lilypond *** Stage: compile (lilypond, linux-ppc) *** Stage: install (lilypond, linux-ppc) *** Stage: package (lilypond, linux-ppc) *** Stage: clean (lilypond, linux-ppc) *** Stage: pkg_install (lilypond, linux-ppc) building package: darwin-x86::lilypond *** Stage: untar (lilypond, darwin-x86) *** Stage: patch (lilypond, darwin-x86) *** Stage: autoupdate (lilypond, darwin-x86) *** Stage: configure (lilypond, darwin-x86) *** Stage: compile (lilypond, darwin-x86) *** Stage: install (lilypond, darwin-x86) *** Stage: package (lilypond, darwin-x86) *** Stage: clean (lilypond, darwin-x86) *** Stage: pkg_install (lilypond, darwin-x86) done cross/gcc conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core cross/gcc-doc conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core cross/gcc-runtime conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core glibc conflicts with glibc-core non-core glibc already installed skipping request to install glibc-core glibc-doc conflicts with glibc-core non-core glibc already installed skipping request to install glibc-core cross/gcc conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core cross/gcc-doc conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core cross/gcc-runtime conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core glibc conflicts with glibc-core non-core glibc already installed skipping request to install glibc-core glibc-doc conflicts with glibc-core non-core glibc already installed skipping request to install glibc-core cross/gcc conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core cross/gcc-doc conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core cross/gcc-runtime conflicts with cross/gcc-core non-core cross/gcc already installed skipping request to install cross/gcc-core glibc conflicts with glibc-core non-core glibc already installed skipping request to install glibc-core glibc-doc conflicts with glibc-core non-core glibc already installed skipping request to install glibc-core python bin/gib --platform=linux-x86 --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond && python bin/gib --platform=darwin-ppc --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond && python bin/gib --platform=darwin-x86 --branch=lilypo
Re: guile sandbox without guile
On Mon, Jun 22, 2009 at 08:58:31AM +0100, Trevor Daniels wrote:
>
> Graham, should these be in the CG too? They are
> helpful to Windows users developing Scheme code.
If they are going to be in the LM B, then merely put a @ref{} in
the CG.
I'd like to claim that the iambic pentameter was unintentional,
but I was still two syllabels short in the second clause when I
was about to post it. So I spent a minute revising it. :)
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
Graham, Yes, I have used VMWare before, but only very very briefly. I'm downloading the `lilybuntu' iso at the moment, and will get back to you after I have managed to run it (I'll keep a note of all my steps in case anyone wants to repeat after me...). Tim W. Graham Percival wrote: On Fri, Jun 05, 2009 at 05:20:55PM -0500, Jonathan Kulp wrote: Thanks Graham. There was a ton of stuff owned by root in the lybook-db/ directory. I tried your command to xarg rm -rf but it said permission denied (even though I did it as sudo and typed the password). Oh yeah... IIRC if you do sudo fidn . blah | xargs then the xargs is evaluated as your normal user account. I'd have done a sudo bash, but changing the permissions with chown is also fine. What I don't understand is how the permissions got jacked up in the first place. I didn't do anything different this time than I usually do. I've never had the permissions problem before. Maybe I put a "sudo" in there inadvertently but I don't recall doing any sudos until "sudo make install." Do you think that was the problem? Yes, I'm sure that's it. It's just possible that "make" failed on some file(s), and when you tried "sudo make install" it successfully built those files. Re: the lilybuntu remix, I've removed a ton of applications but I can't get the .iso image below 853 MB. I'll try it with the xfce desktop and if that doesn't help I'll try it with ubuntu-lite, which does not yet have a stable release but is only 356 MB on the live CD, leaving plenty of room to add the lilypond build dependencies. It would be nice if it were 500 megs or so, but until/unless somebody is actually using it, I'm not certain it's worth the effort to reduce the 853 MB further. Tim, have you used VMware before? This should allow you to compile LilyPond inside a virtual machine. I'm not certain what the best way is to transfer the iso from Jonathan to you, though. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: is Score.LyricText really a bad syntax?
James E. Bailey wrote:
> I don't know where in the documentation this is...
It's in Trevor's patch from 9 hours ago:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blobdiff;f=Documentation/user/input.itely;h=2bf35cf51d0bc7c938bf148ae271f9acc341b075;hp=b20cc4ebf33679d5fe13165e64dc2c9c3e8a7a7f;hb=0d1d63151f21a3b3af3ec01aad3908562fba11e0;hpb=d511b69c1cb8836bc0b7b49b9f396cf06fef19ac
> ...but Lyrics Explained (2.1.2) explains why this particular
> (i.e., LyricText) example is necessary.
> Incidentally, just trying it shows that it's necessary...
I see my mistake... it's only in \lyricmode. Trevor's patch is
actually clearly worded; I'm just not used to reading texinfo.
If I had carefully observed the hierarchy of @item commands,
I would have understood.
+...@item Around every opening and closing curly bracket.
+...@item After every command or variable, i.e. every item that
+begins with a @code{\} sign.
+...@item After every item that is to be interpreted as a Scheme
+expression, i.e. every item that begins with a @code{#} sign.
+...@item To separate all elements of a Scheme expression.
+...@item In @code{lyricmode} to separate all the terms in both
+...@code{\override} and @code{\set} commands. In particular, spaces
+must be used around the dot and the equals sign in commands like
+...@code{\override Score . LyricText #'font-size = #5} and before and
+after the entire command.
Sorry for the noise.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: is Score.LyricText really a bad syntax?
On 22.06.2009, at 19:17, Mark Polesky wrote:
In particular, spaces
must be used around the dot and the equals sign in commands like
@code{\override Score . LyricText #'font-size = #5} and before and
after the entire command.
Really? What's the risk of doing Score.LyricText? Non-spaced
context.grob dots are all over the docs; do we need to change
them?
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Overview-
of-modifying-properties.html
- Mark
I don't know where in the documentation this is, but Lyrics Explained
(2.1.2) explains why this particular (i.e., LyricText) example is
necessary.
Incidentally, just trying it shows that it's necessary:
\version "2.12.2"
Melody = \new Voice = melody { b a g b }
Words = \new Lyrics \lyricmode { \override Score . LyricText #'font-
shape = #'italic These are the words }
badWords = \new Lyrics \lyricmode { \override Score.LyricText #'font-
shape = #'italic These are the words }
\score { << \Melody \lyricsto melody \Words >> }
\score { << \Melody \lyricsto melody << \badWords >> >> }
James E. Bailey
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
is Score.LyricText really a bad syntax?
In particular, spaces
must be used around the dot and the equals sign in commands like
@code{\override Score . LyricText #'font-size = #5} and before and
after the entire command.
Really? What's the risk of doing Score.LyricText? Non-spaced
context.grob dots are all over the docs; do we need to change
them?
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Overview-of-modifying-properties.html
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I want to develop automatic lyric contraction
Han-Wen Nienhuys wrote: On Mon, Jun 22, 2009 at 9:25 AM, Bertalan Fodor (LilyPondTool) wrote: I'd like to dig myself into the C++ source of LilyPond. I have a long-wished feature, for support automatic lyric contraction. That means the following: When there is not enough space for a hyphen to appear, the hyphen is removed. Like instead of "yeah - yeah - yeah", "yeah yeah yeah". In these cases I would like LilyPond to automatically contract it to "yeahyeah - yeah", moving the syllables, taking kerning into account. Do you think it is feasible without major rewrite? I do see some callback to the lyric syllable in the hyphen engraver, but I'm not sure about it. I think it would be a difficult to implement. You'd have to replace the hyphen code and write code that checks the distance between this syllable and the next; if that distance is too small, it would remove or make transparent the following syllable, and change the text of the 1st to be the contracted version. There are some other hairy issues: in general, any contraction can change the spelling of a word, so what happens if you have a - b - c - d - e and it is set very tightly? Any contraction change the spelling of any syllable (and the space it takes up), so how do you decide between contracting aB - c - d - e and a - b - Cd - e first? the changed spelling may alter the size of the word, and may trigger another round of contractions. I'd go one syllable by one. Also, I would not allow automatic change of spelling - that is generally impossible without a full hyphenation engine with dictionary (even in those cases it often mistakes), so the user would have to explicitly set spell-changing upon contraction. I can hardly imagine cases when the respelling results in more space, but certainly that would call for some handling - but that could be solved by the user by setting the minimum-distance in those places. Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I want to develop automatic lyric contraction
On Mon, Jun 22, 2009 at 9:25 AM, Bertalan Fodor (LilyPondTool) wrote: > I'd like to dig myself into the C++ source of LilyPond. > I have a long-wished feature, for support automatic lyric contraction. > That means the following: > When there is not enough space for a hyphen to appear, the hyphen is > removed. Like instead of "yeah - yeah - yeah", "yeah yeah yeah". In these > cases I would like LilyPond to automatically contract it to "yeahyeah - > yeah", moving the syllables, taking kerning into account. > > Do you think it is feasible without major rewrite? I do see some callback to > the lyric syllable in the hyphen engraver, but I'm not sure about it. I think it would be a difficult to implement. You'd have to replace the hyphen code and write code that checks the distance between this syllable and the next; if that distance is too small, it would remove or make transparent the following syllable, and change the text of the 1st to be the contracted version. There are some other hairy issues: in general, any contraction can change the spelling of a word, so what happens if you have a - b - c - d - e and it is set very tightly? Any contraction change the spelling of any syllable (and the space it takes up), so how do you decide between contracting aB - c - d - e and a - b - Cd - e first? the changed spelling may alter the size of the word, and may trigger another round of contractions. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I want to develop automatic lyric contraction
Generally I would fix the first syllable's position (leaving it as it is), and then move the following ones closer to the first. I believe this would always produce pleasant results, as if one of the last syllables would go too early, then it would be still long enough to remain under the corresponding note (because if it weren't long, then it wouldn't make the hyphen disappear in normal spacing.) However, there should be a way to change the first syllable's position, because in the hand-engraved scores I looked at, they often follow special rules: generally a syllable has 3 letters, it is centered under the note, but a 2 letter syllable is aligned to the left side of the note. So if you have a word with 2 syllables, like money, then in contraction ney will still be centered under its note, but mo will be moved to the right. But this is not general rule, so I think it would be enought to make sure there is a property, which in contraction situations would allow me to override the default spacing. Bert Mats Bengtsson wrote: Bertalan Fodor (LilyPondTool) wrote: Hi, I'd like to dig myself into the C++ source of LilyPond. I have a long-wished feature, for support automatic lyric contraction. That means the following: When there is not enough space for a hyphen to appear, the hyphen is removed. Like instead of "yeah - yeah - yeah", "yeah yeah yeah". In these cases I would like LilyPond to automatically contract it to "yeahyeah - yeah", moving the syllables, taking kerning into account. How would this contracted syllable be aligned to the two note heads? /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I want to develop automatic lyric contraction
Bertalan Fodor (LilyPondTool) wrote: Hi, I'd like to dig myself into the C++ source of LilyPond. I have a long-wished feature, for support automatic lyric contraction. That means the following: When there is not enough space for a hyphen to appear, the hyphen is removed. Like instead of "yeah - yeah - yeah", "yeah yeah yeah". In these cases I would like LilyPond to automatically contract it to "yeahyeah - yeah", moving the syllables, taking kerning into account. How would this contracted syllable be aligned to the two note heads? /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
A quick update on the new vertical spacing: the version now in dev/jneeman has most of the features that I had planned (although there are still lots of loose ends to tie up). In particular, you can - space staves in groups using \override StaffGroup.StaffGrouper #'after-last-staff-spacing = #'((space . 50) (stretchability . 2)) - change the alignment of lyrics (for example) with \override Lyrics.VerticalAxisGroup #'staff-affinity = #DOWN - adjust the position of the top staff using first-system-spacing in the paper block I haven't yet done Andrew's request to stretch the last page with the same force as the previous page. Anything I've missed? Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [frogs] Re: Patching the output file naming code (Was: thanks to whomever put this in the LSR...)
Thanks, Mats, for some useful input.
Mats Bengtsson wrote:
For PDF output, please remember that you get a single PDF for each
\book{} block, so
in that case there's no reason to do the setting per \score or \bookpart.
However, for MIDI the situation is different, since you get a separate
MIDI file for each
\score block, so for this reason it makes to allow for separate settings
in \paper and \midi.
However, it would also make sense that the setting done for the PDF file
name also is used
as the default prefix for the MIDI files, right?
Not quite, the base name and the output-prefix setting are two different
things.
I'd like to be able to do this:
In source file mozk165.ly
\paper{
%% or this could be specified in the --output command-line
%%argument
output-base="Exsultate"
%%
}
\bookpart
{
\header {
subtitle = "I. Allegro"
}
\score {
\layout {
}
\midi {
output-suffix = "Allegro"
}
... the actual music
}
}
\bookpart
{
\header {
subtitle = "II. Andante"
}
\score {
\layout {
}
\midi {
output-suffix = "Andante"
}
... the actual music
}
}
\bookpart
{
\header {
subtitle = "III. Vivace"
}
\score {
\layout {
}
\midi {
output-suffix = "Vivace"
}
... the actual music
}
}
Would give Exsultate.pdf, and
Exsultate-Allegro.mid(i)
Exsultate-Andante.mid(i)
Exsultate-Vivace.mid(i)
Without the \paper{output-base="Exsultate"} or --outfile=Exsultate
command-line option it
Would give mozk165.pdf, and
mozk165-Allegro.mid(i)
mozk165-Andante.mid(i)
mozk165-Vivace.mid(i)
However, until someone gives me a steer as to how to pick up and set the
properties in the relevant block I'm stuck. Here's why.
I know the Scheme code supporting \fromproperty does
define-builtin-markup-command (fromproperty layout props symbol)
(symbol?)
other
()
...
(let ((m (chain-assoc-get symbol props)))
;...;
(if (markup? m)
(interpret-markup layout props m)
empty-stencil)))
.
.
.
but I've got this available
(define (print-book-with parser book process-procedure)
(let*
((paper (ly:parser-lookup parser '$defaultpaper))
(layout (ly:parser-lookup parser '$defaultlayout))
(base (ly:parser-output-name parser))
I can pass in the paper, layout blocks (or even the midi if I add the
call to get the '$defaultmidi value ) to my procedure to generate the
output name, but how do I get hold of a properties block
so I could do something like this in my get-output-name code.
(let* ((pfile chain-assoc-get paper:output-base props base ))
((mfile chain-assoc-get midi:output-suffix props pfile)))
Hmmm... looks like I need to maintain two alists, one for the "main"
output filename and one for the midi files.
Do we have any other entities in lily that are liable to produce an
output file for each \score block in the source file?
Apologies for the lousy Scheme but I'm still learning.
If anyone can help out I'll buy you a virtual pint :=).
Cheers,
Ian Hulin
/Mats
Carl D. Sorensen wrote:
And here's Graham's reply about where the filenames should go.
I second his opinion that it ought to be in \paper for the printed
output.
By symmetry, it would seem that that drives us to needing to include
it in
\midi for the midi output.
Declaring the file name twice seems to be unseemly, but I can't think
of a
better way to do it.
Carl
-- Forwarded Message
From: Graham Percival
Reply-To:
Date: Sun, 21 Jun 2009 00:25:45 -0600
To:
Cc: Reinhold Kainhofer
Conversation: [frogs] Re: Patching the output file naming code (Was:
thanks
to whomever put this in the LSR...)
Subject: Re: [frogs] Re: Patching the output file naming code (Was:
thanks
to whomever put this in the LSR...)
On Sun, Jun 21, 2009 at 12:25:42AM +0100, Ian Hulin wrote:
Is \paper the right place to put properties relating to output
filenames, or should it be property of \score itself?
IMO it should be in \paper, but I suppose that it could be useful
in \midi as well. It doesn't feel right to have this in \score.
Cheers,
- Graham
---
Join the Frogs!
-- End of Forwarded Message
___
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: lilypond vs. GNU/LilyPond
On Mon, Jun 22, 2009 at 2:12 AM, Graham Percival wrote: > On the new website, I'm following the previous website which > simply wrote "LilyPond". Does anybody want to make a strong case > in favor of replacing this with "GNU/LilyPond" everywhere? If you want that, write GNU LilyPond, without the slash. I am not very fond of the moniker though, and think just 'LilyPond' is easier to read and looks. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
I want to develop automatic lyric contraction
Hi, I'd like to dig myself into the C++ source of LilyPond. I have a long-wished feature, for support automatic lyric contraction. That means the following: When there is not enough space for a hyphen to appear, the hyphen is removed. Like instead of "yeah - yeah - yeah", "yeah yeah yeah". In these cases I would like LilyPond to automatically contract it to "yeahyeah - yeah", moving the syllables, taking kerning into account. Do you think it is feasible without major rewrite? I do see some callback to the lyric syllable in the hyphen engraver, but I'm not sure about it. (Also, for some languages contraction would change the spelling, e.g. in German c-k may become kk, Hungarian sz-sz becomes ssz. But that's another story.) Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB / autoconf out-of-tree builds
Op woensdag 17-06-2009 om 13:24 uur [tijdzone -0700], schreef Graham Percival: > I've tracked down the srcdir vs. builddir problem to autoconf. Is this now fixed? It seems that > The $(TOPDOC_TXT_FILES) includes RELEASE-COMMIT, which is only > created in the builddir, not the srcdir. RELEASE-COMMIT is not included in TOPDOC_TXT_FILES in master? Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB test-lily/dist-check.py looking at src/ instead of build/ ?
Op maandag 15-06-2009 om 09:59 uur [tijdzone -0300], schreef Han-Wen Nienhuys: > correct. I think RELEASE-COMMIT is a new feature and has not been > debugged properly. That's right. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ppppp but no fffff
Graham Percival wrote: on the last page of book 2 of the Ligeti etudes. Sweet Mao...! Not that I condone that sort of ridiculous notation. Yeah, me neither. And if somebody really wants that, they can look at dynamic-init.ly and figure out how to force lilypond to do that themselves. :) Why not refer to the Notation Reference? ;-) http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Attached-to-notes#New-dynamic-marks /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [trivial patch] GUB avoid warning message
Op vrijdag 12-06-2009 om 00:44 uur [tijdzone -0300], schreef Han-Wen Nienhuys: [I am top posting :-) ] Applied. > LGTM. > > On Thu, Jun 11, 2009 at 2:31 PM, Graham > Percival wrote: > > Trivial patch to avoid so much clutter in the log files. > > > > Cheers, > > - Graham > > > > > > > > ___ > > lilypond-devel mailing list > > lilypond-devel@gnu.org > > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > > > > > > -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [frogs] Re: Patching the output file naming code (Was: thanks to whomever put this in the LSR...)
For PDF output, please remember that you get a single PDF for each
\book{} block, so
in that case there's no reason to do the setting per \score or \bookpart.
However, for MIDI the situation is different, since you get a separate
MIDI file for each
\score block, so for this reason it makes to allow for separate settings
in \paper and \midi.
However, it would also make sense that the setting done for the PDF file
name also is used
as the default prefix for the MIDI files, right?
/Mats
Carl D. Sorensen wrote:
And here's Graham's reply about where the filenames should go.
I second his opinion that it ought to be in \paper for the printed output.
By symmetry, it would seem that that drives us to needing to include it in
\midi for the midi output.
Declaring the file name twice seems to be unseemly, but I can't think of a
better way to do it.
Carl
-- Forwarded Message
From: Graham Percival
Reply-To:
Date: Sun, 21 Jun 2009 00:25:45 -0600
To:
Cc: Reinhold Kainhofer
Conversation: [frogs] Re: Patching the output file naming code (Was: thanks
to whomever put this in the LSR...)
Subject: Re: [frogs] Re: Patching the output file naming code (Was: thanks
to whomever put this in the LSR...)
On Sun, Jun 21, 2009 at 12:25:42AM +0100, Ian Hulin wrote:
Is \paper the right place to put properties relating to output
filenames, or should it be property of \score itself?
IMO it should be in \paper, but I suppose that it could be useful
in \midi as well. It doesn't feel right to have this in \score.
Cheers,
- Graham
---
Join the Frogs!
-- End of Forwarded Message
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: mats.bengts...@ee.kth.se
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile sandbox without guile
Trevor Daniels wrote: > Mark, do you want to make a patch for the changes > to LM B which you want to see, or shall I extract > some changes from your note and the various comments? > If you do it, I think we should document both of > these methods for Windows (or three, if we mention > git bash). You know, I don't what's come over me recently. I've been doing so much LilyPonding. I have so many different lily-projects going on at the same time, I don't know how I'll get all of them done! I'll get around to this eventually, of course, but if you're in the mood to offer, I'm in the mood to accept! Should be pretty easy, I think the devcom was pretty clear this time. I'll try to help out however I can. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile sandbox without guile
I played a bit with jEdit's console:
In jEdit Console plugin you need to add
%set GUILE_LOAD_PATH "g:\program files\lilypond\usr\share\guile\1.8"
and then you can start guile from the System Shell.
Unfortunately the LilyPond shell doesn't support the #(top-repl)
discussed in
http://lilypond.org/doc/v2.13/Documentation/devel/contrib-guide/Debugging-LilyPond#Debugging-LilyPond
So if you want the guile prompt you need to start LilyPond from the
system shell, but not from the bin directory (I don't why it happens,
that when you start lilypond.exe from its directory, it doesn't start):
G:\> "g:\Program Files\LilyPond\usr\bin\lilypond" ${f}
(${f} is substituted automatically with the current buffer's path)
Trevor Daniels wrote:
Henning Plumeyer Sunday, June 21, 2009 8:53 PM
Am 21.06.2009, 02:31 Uhr, schrieb Neil Puttock :
I also tried that with no success. Having read the Guile manual, I
thought adding the environment variable GUILE_LOAD_PATH=C:\Program
Files\LilyPond might work, but it doesn't have any effect.
I have an environment variable
GUILE_LOAD_PATH=D:\Programme\LilyPond\usr\share\guile\1.8
and guile works from inside the command prompt and from "Run"
Yes, this (or rather the equivalent location on
my system) works fine on Vista too. Seems like
we have two reliable ways of making guile work
under Windows now.
Mark, do you want to make a patch for the changes
to LM B which you want to see, or shall I extract
some changes from your note and the various comments?
If you do it, I think we should document both of
these methods for Windows (or three, if we mention
git bash).
Graham, should these be in the CG too? They are
helpful to Windows users developing Scheme code.
Trevor
___
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: lilypond vs. GNU/LilyPond
Bertalan Fodor wrote: > > On the new website, I'm following the previous website > > which simply wrote "LilyPond". Does anybody want to make > > a strong case in favor of replacing this with "GNU/LilyPond" > > everywhere? > > > > (or maybe just once or twice, in the intro or something like > > that?) > > I hope nobody. For a potential user, the term GNU is > incomprehensible. I think that's exaggerated. It's kind of like the D.C. in Washington, D.C. Most people don't know what it stands for, and nobody *ever* guesses correctly. On the surface, it seems completely unrelated to the city, the country, the capital, anything. You either know it or you don't. And if you don't, you look it up and say, "huh". All the same, it's the official name. GNU is what it is. It's not Unix, and if putting GNU on our homepage gets a tiny fraction of people a tiny bit more curious about free software, that's not a bad thing, IMO. Perhaps some people will be turned by a strangely pronounced word, but they'll eventually come back when their friends and colleagues eventually convince them that GNU LilyPond is not just an anachronistic image. We shouldn't be ashamed of our GNU heritage. I don't think GNU is incomprehensible, it's just self-referential, programmer style. PHP is another good example, it used to stand for something reasonable, but then they *officially* changed it to stand for PHP Hypertext Preprocessor. It's like foo and bar, and hello world, and counting from 0. Programmers have a culture of quirks, and self-referential acronyms are par for the course. Some GNU-friendly GNU-package webpages: http://www.gnu.org/software/3dldf/LDF.html http://www.gnu.org/software/anubis/ http://aspell.net/ Plenty of GNU projects unabashedly keep the GNU in their title. GCC - GNU Compiler Collection GCL - GNU Common Lisp GIFT - GNU Image Finding Tool GIMP - GNU image manipulation program GLPK - GNU Linear Programming Kit GLUE - GNU Links Users Everywhere GLib - GNU library etc. Maybe we should start calling it GnilyPond... or maybe we should put a picture of a gnu cooling off at a lily pond. By the way, do you know what most people guess D.C. to stand for? Da Capital. Seriously. We either know it or we're hopeless. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile sandbox without guile
Henning Plumeyer Sunday, June 21, 2009 8:53 PM Am 21.06.2009, 02:31 Uhr, schrieb Neil Puttock : I also tried that with no success. Having read the Guile manual, I thought adding the environment variable GUILE_LOAD_PATH=C:\Program Files\LilyPond might work, but it doesn't have any effect. I have an environment variable GUILE_LOAD_PATH=D:\Programme\LilyPond\usr\share\guile\1.8 and guile works from inside the command prompt and from "Run" Yes, this (or rather the equivalent location on my system) works fine on Vista too. Seems like we have two reliable ways of making guile work under Windows now. Mark, do you want to make a patch for the changes to LM B which you want to see, or shall I extract some changes from your note and the various comments? If you do it, I think we should document both of these methods for Windows (or three, if we mention git bash). Graham, should these be in the CG too? They are helpful to Windows users developing Scheme code. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new lilypond repos
2009/6/22 Patrick McCarty : >> That would be nice, but I have no clue where the windows lilypad >> code is. Until/unless they get merged, I favor keeping "macos" in >> the name, since it *is* specifically for osx. > > I have found 4 different LilyPad sources: 3 for Mac and 1 for Windows. > The URLs are below. > > Windows: > http://lilypond.org/download/gub-sources/lilypad/ There are open bugs asking for improving Windows Lilypad. Whatever surprising it is a source tarball and not a git tree, to ease its developing I suggest to put it in git. I vaguely remember to have submitted patches against it, in a further date to that of the aforementioned link. -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond vs. GNU/LilyPond
2009/6/22 Graham Percival : > On the new website, I'm following the previous website which > simply wrote "LilyPond". Does anybody want to make a strong case > in favor of replacing this with "GNU/LilyPond" everywhere? If you are talking by similarness with GNU/Linux against Linux, it's not the same case. GNU is an operative system and Linux is its kernel. The complete system with its kernel included is GNU/Linux. But Linux is not GNU software. An example of the GNU operative system with a different kernel was the GNU/Hurd project. If any among you think that the kernel makes the operative system and GNU plays no role in a Linux system, think again. Linux is _nothing_ without the GNU system around it (well maybe embedded systems like smartphones and the like do not have GNU into them, I'm not sure). LilyPond is GNU software. The first times we talk about it we should name it as GNU[space]LilyPond, then LilyPond for short. > (or maybe just once or twice, in the intro or something like that?) Yes, IMO -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
