Re: Variables when compiling a book
On 02/02/2015 02:34 PM, John McWilliam wrote:
I am compiling a collection of bagpipe tunes and am having a problem
when the individual files are to be compiled into a book. Many of the
tunes have sections of music defined in variables - these definitions
lie outside the \score context and are causing errors when I try to
compile the book.
I have also noticed that my list of \include files also defined
outside the score context have to be removed form the individual
tunes and listed at the beginning of the book file instead. This is
not a problem since the list is short, however, moving all my music
variables to the book file seems like a clumsy way of doing things
since they are many and vary from tune to tune.
Does anyone have a solution to this problem which could perhaps be
described as one of SCOPE or CONTEXT?
Unfortunately, this is one of the cases where LilyPond use resembles
other kinds of computer programming. You’ll need to refactor your files...
I’ve made a few books of songs or tunes. The music for each tune (or
song) goes in its own file; there is a sibling wrapper for each tune
that produces discrete output, which \includes the core music file.
Then the book file \includes the music for all the tunes.
A short example:
=-=-=-= atholl_highlanders_tune.ly =-=-=-=
\version 2.16.2
athollLayout = { ... }
athollFullChords = { ... }
athollFullTune = { ... }
=-=-=-= end =-=-=-=
=-=-=-= atholl_highlanders.ly =-=-=-=
\version 2.16.2
\include atholl_highlanders_tune.ly
theFullChords = \athollFullChords
theFullTune = \athollFullTune
theLayout = \athollLayout
theTempo = #(ly:make-moment 420 8)
theTitle = The Atholl Highlanders
% tunes.ly actually handles the layout and MIDI
% generation, given these variables
\include tunes.ly
=-=-=-= end =-=-=-=
=-=-=-= crism_tunes.ly =-=-=-=
\version 2.16.2
\include atholl_highlanders_tune.ly
% ...
\book {
% ...
\bookpart {
\header {
title = Jigs
}
\score {
\athollLayout
\header {
title = The Atholl Highlanders
}
}
\layout {}
}
% ...
}
% ...
}
=-=-=-= end =-=-=-=
Now, I end up actually generating the wrapper files and the book .ly
from an XML file, so that I can easily handle redundant information
(indexes by alternate titles and key, e.g.), but that’s for a different
time.
To see the full files for a single tune, see URL:
http://music.maden.org/index.php?title=The_Atholl_Highlanders ; for a
tune book sample, see URL: http://crism.maden.org/music/crism_tunes.xml
, URL: http://crism.maden.org/music/crism_tunes.ly , and URL:
http://crism.maden.org/music/crism_tunes.pdf .
~Chris
--
Chris Maden, text nerd URL: http://crism.maden.org/
Surround hate and force it to surrender.
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9 A210 4A51 DBAC 5C5C 3D5E
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Variables when compiling a book
I am compiling a collection of bagpipe tunes and am having a problem when the individual files are to be compiled into a book. Many of the tunes have sections of music defined in variables - these definitions lie outside the \score context and are causing errors when I try to compile the book. I have also noticed that my list of \include files also defined outside the score context have to be removed form the individual tunes and listed at the beginning of the book file instead. This is not a problem since the list is short, however, moving all my music variables to the book file seems like a clumsy way of doing things since they are many and vary from tune to tune. Does anyone have a solution to this problem which could perhaps be described as one of SCOPE or CONTEXT? - John McWilliam -- View this message in context: http://lilypond.1069038.n5.nabble.com/Variables-when-compiling-a-book-tp171346.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of
Re: ScholarLY - introduction and call for collaboration
Am 03.02.2015 um 01:55 schrieb Craig Dabelstein: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had: \include ../Notes/flute.ily \include part-init.ily I reversed the order of these two lines and now it works perfectly. \include part-init.ily \include ../Notes/flute.ily Ah yes, I did that too, but thought I needed that only for the dynamics-def file... It is still producing an inp file for every single part though. I'm not sure what you mean. As it is the function will produce one .inp file for any compilation. So if you compile a part it will produce a file for that part, and if you compile the score it will compile a file with annotations for the whole score. If that's not what you want (which is quite normal) you have to control the behaviour with the configuration commands (and that's where the multipart include set-up comes in). Try putting \setAnnotationExportTargets #'(latex) in init-score.ily and \setAnnotationExportTargets #'() in init-part.ily (and remove that command from init-main.ily) HTH Urs Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com wrote: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com
Re: ScholarLY - introduction and call for collaboration
Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can
Re: ScholarLY - introduction and call for collaboration
Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had: \include ../Notes/flute.ily \include part-init.ily I reversed the order of these two lines and now it works perfectly. \include part-init.ily \include ../Notes/flute.ily It is still producing an inp file for every single part though. Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include
Re: Hungarian Gregorian
2015-02-02 15:49 GMT+01:00 Pierre Perol-Schneider
pierre.schneider.pa...@gmail.com:
2015-02-02 15:43 GMT+01:00 Rita Composer ritacompo...@gmail.com:
Another proble happened with the dots I attached an example.
Ok, I'll take a look at tonight.
As promised, see attached files.
This is more or less a draft with some ideas (with far too many issues),
even if the output isn't that bad.
Waiting for your comments,
Goodnight,
Pierre
modernGregorian.ily
Description: Binary data
\version 2.19.15
\include modernGregorian.ily
\pointAndClickOff
\language deutsch
\paper {
indent = 0
top-margin = 15
left-margin = 15
right-margin = 15
tagline = ##f
ragged-last = ##t
markup-system-spacing.basic-distance = 11
}
siQuaerisMelody = \transpose c c' {
\clef G
\omit Stem
\melisma { g g \lst a \sli f \lst g \tli f \tli e \tli d \lst g }
\melisma { a h c' \lst d' }
\melisma { \lst c' \tli h \tli a } g a f g
\bar ' \noBreak
\melisma { c' \lst c' \tli h \tli a \lst h }
g a e \melisma { \lst f \tli e \tli d }
e g g
\bar |
h \melisma { \lst d' \tli c' \lst d' \sli h \lst h \sli g }
\bar \break
h \melisma { c' \lst d' } \melisma { \lst c' \tli h \tli a }
\melisma { h \lst c' } d'
\bar ' \noBreak
g \melisma { a \lst h \sli g \lst g \mli d \lst f \tli e \tli d }
e \melisma { c \lst e \lst g }
\melisma { \lst a \tli g \lst c' \tli h \tli a \lst h \sli g } g
\bar |
d' \melisma { \lst e' \sli c' d' \lst e' \lst e' \sli c' \lst d' }
h \melisma { \lst c' \tli h \tli a }
\bar \break
\melisma { h c' \lst d' } \melisma { \lst c' \tli h \tli a } g g
\bar ' \noBreak
\melisma { g \lst a } \melisma { e f \lst g } \melisma { a \lst h }
g c'-\tweak extra-offset #'(0 . 0.5) \orn a b
\bar |
\melisma { \lst c' \tli h \tli a } g h d' e' c' d'
\bar ' \noBreak
\melisma { \lst e' \sli c' \lst e' \tli d' }
\bar \break
\melisma {
\lst d' \sli h c' \lst d' \lst d' \lli g r
e f \lst g r
a \lst h \sli g r
h \lst d' d' r
\lst e' \sli c' \lst e' \tli d' r
\lst d' \sli h c' \lst d' r
\lst d' \lli g \lst a \tli g \tli f \tli e \lst f
}
d d a
\melisma {
f \lst g \tli f \tli e \tli d \lst g r
a \lst h r
\lst c' \sli a \lst h \sli g \lst a
}
g
\bar ||
\melisma {
c' \lst c' \tli h \tli a r
\lst h \sli g \lst a
}
\bar \break
g g \melisma { e \lst g } a f g
\bar ' \noBreak
h g c' a h d' \melisma { \lst d' \sli h }
\bar |
d' d' e' \melisma { c' d' \lst e' } d'
\melisma { \lst c' \tli h \tli a } h
\bar ' \noBreak
\space #1
\bar \break
\melisma { g \lst a a }
\melisma { e \lst f \sli d }
\melisma { g a \lst h } g
\melisma { \lst c' \tli h \tli a }
\melisma { \lst a \tli g }
\bar |.
}
siQuaerisLyrics = \lyricmode {
Si quae -- ris mi -- ra cu -- la
mors er -- ror ca -- la -- mi -- tas
dae -- mon
le -- pra fu -- gi -- unt
ae -- gri sur -- gunt sa -- ni
\set stanza = *
ce -- dunt ma -- re
\skip 4 vin -- cu -- la
\revert LyricText.self-alignment-X
mem -- bra res -- que per -- di -- tas
pe -- tunt et ac -- ci -- pi -- unt
ju --
\skip 4 ve -- nes et ca -- ni.
\set stanza = V)
Per --
e -- unt per -- i -- cu -- la
ces -- sat et ne -- ces -- si -- tas
nar -- rent hi qui sen -- ti -- unt
\override LyricHyphen.minimum-distance = #4
\override LyricSpace.minimum-distance = #4
di -- cant Pa -- du -- a -- ni. *
}
\score {
\cadenzaOn
\new Voice = SiQuaeris \siQuaerisMelody
\new Lyrics \lyricsto SiQuaeris \siQuaerisLyrics
\layout {
\context {
\Lyrics
%\override VerticalAxisGroup.staff-affinity = ##f
fontSize = #-1.5
}
}
\header {
piece = \markup\concat {
\fontsize #7 \bold 8216*
\hspace #3
\raise #0.5
{
\bold OFM: \hspace #0.5 Anton.cf./N3/R2.
\hspace #0.5
\bold F: \hspace #0.5 OFM-122: f.83v.
}
}
}
}
siQuaerisViiMelody = \transpose c c' {
\clef G
\omit Stem
\melisma {
c' \lst c' \tli h \tli a \lst h \lst h \sli g \lst a
}
g g \melisma { e \lst g }
\melisma { \lst a \sli f \lst g }
\melisma { \lst h \sli g } c'
\melisma { \lst h \tli a \lst h }
\melisma { \lst d' \sli h }
\bar ' \noBreak
\melisma { d' d' \lst e' }
\melisma { c' d' \lst e' } d'
\melisma { \lst c' \tli h \tli a } h
\melisma { g \lst a }
\melisma {
\lst a \mli e \lst f \sli d r
g \lst a r
h \lst c' \tli h \tli a \lst a \tli g
}
\bar |.
}
siQuaerisViiLyrics = \lyricmode {
\override LyricHyphen.minimum-distance = #2
\override LyricSpace.minimum-distance = #2
\set stanza = V2)
Glo -- ri -- a Pa -- tri et Fi -- li -- o
et Spi -- ri -- tu -- i San -- cto.
}
\markup\column {
\vspace #1
\scale #'(0.8 . 0.8) {
\score {
\cadenzaOn
\new Voice = SiQuaerisVii \siQuaerisViiMelody
\new Lyrics \lyricsto SiQuaerisVii \siQuaerisViiLyrics
\layout {
Re: Get current file
Am 02.02.2015 um 18:46 schrieb MarcM:
i don't have the complete answer but just to get you started.
May be this will help.
currentWorkingDir.ly
http://lilypond.1069038.n5.nabble.com/file/n171344/currentWorkingDir.ly
unfortunately this doesn't help, it will only print the directory of the
file that is *compiled*, and not that of the currently parsed (i.e.
included) one.
But this kicked me to turn a half-baked workaround into a generic
solution. It's surprisingly simple (see attached) :-)
Urs
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Get-current-file-tp171234p171344.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
--
Urs Liska
www.openlilylib.org
\version 2.19.16
\include definition.ly
#(display #{ \thisFile #})\version 2.19.16
thisFile =
#(define-scheme-function (parser location)()
(car (ly:input-file-line-char-column location)))
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
\sustainOff\sustainOn produces inconsistent MIDI results
Hi All, I'm having some trouble with the MIDI output from lilypond for a new piano composition. I have a lot of \sustainOff\sustainOn sequences in the music, and while they show up fine on the score, the MIDI file appears to sometimes turn off sustain completely instead, instead of turning off previously sustained notes and starting new sustained notes. Here's a snippet that exhibits this problem: | g8(\sustainOn d' g d f,\sustainOff\sustainOn d' f d | ees,\sustainOff\sustainOn c' ees c d,\sustainOff\sustainOn bes' d)\sustainOff r | I used a decompiler on the MIDI file and discovered that some of the sustain pedal controller events have been transposed. The correct sequence of controller events ought to be (64,0), (64,127), but lilypond appears to sometimes generate (64,127), (64,0) instead, which, of course, has the effect of completely turning off the sustain. (Note: 64 is the sustain pedal, 0 means pedal off, 127 means pedal on). Is this a known bug? Are there any workarounds? P.S. I'm using lilypond 2.18.2. T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Naming convention brainstorming
Hello folks, I’d use « data entry mode », as opposed to « presentation fine-tuning ». JM Le 2 févr. 2015 à 09:04, Urs Liska u...@openlilylib.org a écrit : Hi all, thank you for your feedback. I've got the following suggestions: Content mode (as opposed to presentation) Entry mode Working mode Crafting mode Sandbox Debug-structure When collecting that list I realized that entry mode got three votes - while I had already decided to settle on this term. I think this is the most generic and unbiased way of expressing the idea, although even this one is not perfect. What would perfectly match the essence would be edit mode - but that is highly ambiguous so it is practically useless. Best Urs Am 01.02.2015 um 00:41 schrieb Urs Liska: Hi all, for quite some time now I've been using a concept that is very useful, but finally I'd like to give it an authoritative name to be used in different places. I'm talking about the working, thinking and compiling mode when I'm working on the _content_ of a score and not it's final visual appearance. This mode is characterized for example by - not caring too much about layout - not caring too much about engraving quality - being interested in visual feedback about manual interventions (e.g. coloring annotations or the result of custom functions) Originally we talked about it as draft mode but this doesn't seem to hit the spot. Nor do devel mode or preview mode. I would really like to find the right term now because I want to make that kind of an authoritative term for a configuration option in a redesigned openLilyLib and sort of a general library specification in that context. There should be a common configuration option that library authors can (and are encouraged to) respect in their functions. Say I have a library function \crossVoiceTie that does all the work for me with a hidden voice etc. Then this should highlight that tie or the hidden noteheads when that special mode is active. This approach has proven extremely useful and I'd be happy to promote this as a more general best-practice. So what are your feelings about this mode of working *before* finishing an engraving to publication quality? Thanks for any opinions Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Naming convention brainstorming
Hi Jacques, nice suggestion. I like the notion of data as a neutral replacement to content vs. representation. Urs Am 02.02.2015 um 11:25 schrieb Jacques Menu: Hello folks, I’d use « data entry mode », as opposed to « presentation fine-tuning ». JM Le 2 févr. 2015 à 09:04, Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org a écrit : Hi all, thank you for your feedback. I've got the following suggestions: * Content mode (as opposed to presentation) * Entry mode * Working mode * Crafting mode * Sandbox * Debug-structure When collecting that list I realized that entry mode got three votes - while I had already decided to settle on this term. I think this is the most generic and unbiased way of expressing the idea, although even this one is not perfect. What would perfectly match the essence would be edit mode - but that is highly ambiguous so it is practically useless. Best Urs Am 01.02.2015 um 00:41 schrieb Urs Liska: Hi all, for quite some time now I've been using a concept that is very useful, but finally I'd like to give it an authoritative name to be used in different places. I'm talking about the working, thinking and compiling mode when I'm working on the _content_ of a score and not it's final visual appearance. This mode is characterized for example by - not caring too much about layout - not caring too much about engraving quality - being interested in visual feedback about manual interventions (e.g. coloring annotations or the result of custom functions) Originally we talked about it as draft mode but this doesn't seem to hit the spot. Nor do devel mode or preview mode. I would really like to find the right term now because I want to make that kind of an authoritative term for a configuration option in a redesigned openLilyLib and sort of a general library specification in that context. There should be a common configuration option that library authors can (and are encouraged to) respect in their functions. Say I have a library function \crossVoiceTie that does all the work for me with a hidden voice etc. Then this should highlight that tie or the hidden noteheads when that special mode is active. This approach has proven extremely useful and I'd be happy to promote this as a more general best-practice. So what are your feelings about this mode of working *before* finishing an engraving to publication quality? Thanks for any opinions Urs ___ lilypond-user mailing list lilypond-user@gnu.org mailto:lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \sustainOff\sustainOn produces inconsistent MIDI results
On Mon, Feb 02, 2015 at 09:27:44PM -0800, H. S. Teoh wrote: [...] So, I decided to try the latest git version of lilypond (2.19.16) to see if this glitch still exists, and I'm happy to report that it's now fixed!! [...] Oops, I spoke too soon. :-( The glitch still exists, just in a different random pattern, so I didn't catch it at first. Anybody has any idea how to fix / work around this? T -- Some days you win; most days you lose. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Get current file
Nice. PS: your files indicates \version 2.19.16. Are you working on the DEV version? -- View this message in context: http://lilypond.1069038.n5.nabble.com/Get-current-file-tp171234p171357.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
It is now working ABSOLUTELY BRILLIANTLY! Thanks for all your help. Craig On Tue Feb 03 2015 at 11:15:18 AM Urs Liska u...@openlilylib.org wrote: Am 03.02.2015 um 01:55 schrieb Craig Dabelstein: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had: \include ../Notes/flute.ily \include part-init.ily I reversed the order of these two lines and now it works perfectly. \include part-init.ily \include ../Notes/flute.ily Ah yes, I did that too, but thought I needed that only for the dynamics-def file... It is still producing an inp file for every single part though. I'm not sure what you mean. As it is the function will produce one .inp file for any compilation. So if you compile a part it will produce a file for that part, and if you compile the score it will compile a file with annotations for the whole score. If that's not what you want (which is quite normal) you have to control the behaviour with the configuration commands (and that's where the multipart include set-up comes in). Try putting \setAnnotationExportTargets #'(latex) in init-score.ily and \setAnnotationExportTargets #'() in init-part.ily (and remove that command from init-main.ily) HTH Urs Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at
Re: Naming convention brainstorming
From: Urs Liska u...@openlilylib.org To: lilypond-user lilypond-user@gnu.org Subject: Naming convention brainstorming Hi all, for quite some time now I've been using a concept that is very useful, but finally I'd like to give it an authoritative name to be used in different places. I'm talking about the working, thinking and compiling mode when I'm working on the _content_ of a score and not it's final visual appearance. Sorry if I'm late to the party, but I was curious if you would mind also listing out what the other phases of work would be. Seeing the whole workflow might make it clearer how this work is different than other kinds of work. For example, is this workflow the same for composition as well as arranging or transcription? Meaning, is the musical content considered to be complete before entering this phase? Is this phase where musical content is entered? Is musical content entered during any phase after this? This mode is characterized for example by - not caring too much about layout I assume that by not caring you mean that you are not entering information about layout. Because caring or not caring is not an activity related to lilypond workflow, per se. Doing something about layout would be. - not caring too much about engraving quality Is engraving quality distinct from layout? What parts of engraving fall outside of layout? - being interested in visual feedback about manual interventions (e.g. coloring annotations or the result of custom functions) From what follows, this seems to be the crux of what you are focused on: visually highlighting the work done by particular functions. It certainly seems to be only about visual feedback, although of a different kind than normal (temporarily, for the purpose of the developer, rather than finally for the consumer of the printed music.) So, I am confused as to why this has anything to do with content whatsoever. It sounds like it is *only* formatting, but of a preliminary intention. Are there other use cases besides coloring? There should be a common configuration option that library authors can (and are encouraged to) respect in their functions. Say I have a library function \crossVoiceTie that does all the work for me with a hidden voice etc. Then this should highlight that tie or the hidden noteheads when that special mode is active. Are you suggesting that every library and function should include code to color the objects it is rendering based on this config option? This seems somewhat backwards to me. Seems like it would be better to ask every function to leave its fingerprint on the objects it renders, and then put the ability to color items based on those tags into something else. ( If lilypond were an object oriented language, you could have a superclass that did the coloring, and then make every library function a descendent of that class, so they would get the ability to color for free. ) This would also allow for more flexibility. For example, I am using libraries A, B and C. Assume that they are coded to color the way you want. Can I only turn this on or off the coloring based on one setting? What if I want to color only the objects rendered by library B, and not those of A and C? What if I want to show library A's objects in red, library B's objects in green, and leave library C's objects alone? I might wonder if a better approach would be to ask libraries to instead tag their output, and then write a color-by-configuration engraver (if that is the right concept) to interpret the tags based on the configuration options. This could be a list of ((tagName1 color1) (tagName2 color2) ...) This approach has proven extremely useful and I'd be happy to promote this as a more general best-practice. Again, I am asking for clarity: is the utility for developing lilypond features, or useful for producing scores? (Of course, once you have features, you can more easily produce scores. But this mode seems immediately to be about producing the features. Later, you switch to score-production mode.) So what are your feelings about this mode of working *before* finishing an engraving to publication quality? I am still unclear on why this matters what stage of completion a score is in when you use this feature. When collecting that list I realized that entry mode got three votes - while I had already decided to settle on this term. I think this is the most generic and unbiased way of expressing the idea, although even this one is not perfect. What would perfectly match the essence would be edit mode - but that is highly ambiguous so it is practically useless. Again, I would enjoy some clarity on what you are editing. Is it music, or lilypond functions? Sounds like you have your mind made up. But if you are still on the fence, I would also vote for terms that are closer to development terminology like sandbox mode, debug mode, or something that actually
Re: \sustainOff\sustainOn produces inconsistent MIDI results
On Mon, Feb 02, 2015 at 05:34:56PM -0800, H. S. Teoh wrote: Hi All, I'm having some trouble with the MIDI output from lilypond for a new piano composition. I have a lot of \sustainOff\sustainOn sequences in the music, and while they show up fine on the score, the MIDI file appears to sometimes turn off sustain completely instead, instead of turning off previously sustained notes and starting new sustained notes. [...] I used a decompiler on the MIDI file and discovered that some of the sustain pedal controller events have been transposed. [...] P.S. I'm using lilypond 2.18.2. [...] So, I decided to try the latest git version of lilypond (2.19.16) to see if this glitch still exists, and I'm happy to report that it's now fixed!! Furthermore, the layout engine seems to have improved significantly -- an overfull page I had before is now correctly spilled over to adjacent pages so it no longer needs to be compressed. Hooray! I guess I'll be using 2.19.16 from now on. :-) T -- War doesn't prove who's right, just who's left. -- BSD Games' Fortune ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hungarian Gregorian
Dear Sister Judit, 2015-02-02 15:43 GMT+01:00 Rita Composer ritacompo...@gmail.com: lots of people started to be glad, and they are happy with us that we can creat such type of music. Great! For example, one of the professional musition (not such beginer like me) now they noticed that the connection between the noteheads which were curved in the first version, now straight. Can you make it curved again? Ok, I'll see what I can do. The problem with the former glyph was that it sometimes desapeared. Another proble happened with the dots I attached an example. Ok, I'll take a look at tonight. Cheers, Pierre ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hungarian Gregorian
Hi Sister Judit,
I slightly changed 'modernGregorian.ily' so that you could typset in any
langage note you'd like.
I also added a '\versus' and '\responsum' option.
Cheers,
Pierre
2015-02-01 14:31 GMT+01:00 Pierre Perol-Schneider
pierre.schneider.pa...@gmail.com:
And ragged-right = ##f is ok now.
See new attached files.
Cheers,
Pierre
2015-02-01 14:12 GMT+01:00 Pierre Perol-Schneider
pierre.schneider.pa...@gmail.com:
Oups...
2015-02-01 12:44 GMT+01:00 Pierre Perol-Schneider
pierre.schneider.pa...@gmail.com:
Simply add :
melisma = #(define-music-function (parser location mus)
(ly:music?)
#{
{ \neume { $mus } h }
#})
In your file (or replace it in modernGregorian.ily).
In fact:
melisma = #(define-music-function (parser location mus)
(ly:music?)
#{
{ \neume { $mus } \omit Accidental h }
#})
Cheers,
Pierre
\version 2.19.15
\include modernGregorian.ily
%\pointAndClickOff
\language deutsch
\paper {
indent = 0
top-margin = 15
left-margin = 20
right-margin = 20
tagline = ##f
}
myMelody = \transpose c c' {
\clef G
\key f\major
\omit Stem
\repeat volta 2 {
f f \melisma { g \lst a } a
\once\override Staff.BarLine.bar-extent = #'(0 . 2) \bar |
a g \melisma { \lst a g } \melisma { \lst e f }
g \melisma { \lst f e } d d \space #2
}
}
myLyrics = \lyricmode {
\override LyricHyphen.minimum-distance = #5
\override LyricSpace.minimum-distance = #5
\versus { A -- le -- lu -- ja. }
\responsum {
a -- le -- lu -- ja.
a -- le -- lu -- ja.
}
}
\score {
\cadenzaOn
\new Voice = MyMelody \myMelody
\new Lyrics \lyricsto MyMelody \myLyrics
\layout {
system-count = 1
ragged-right = ##f
\context {
\Lyrics
\override VerticalAxisGroup.staff-affinity = ##f
}
}
\header {
piece = \markup {
\lower #2.7 \fontsize #9 \bold 551
\column {
\bold Alleluja
(ÉE 432)
}
}
}
}
modernGregorian.ily
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hungarian Gregorian
2015-02-02 15:49 GMT+01:00 Pierre Perol-Schneider pierre.schneider.pa...@gmail.com: Another proble happened with the dots I attached an example. Ok, I'll take a look at tonight. Ok, that was easy (not sure if some strange issues will occur though...) Please try the attached file. Cheers Pierre modernGregorian.ily Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Nachschlag - Passing Appoggiatura - hook?
-Original Message- From: Hans Aberg On 29 Nov 2014, at 23:19, Javier Ruiz-Alma jav...@ruiz-alma.com wrote: I'm typesetting BWV 1055, which includes these so-called nachschlags (or passing appoggiaturas, accents) They can appear coming down or up to the following note (see attached). These are explained here: http://www.iment.com/maida/familytree/henry/music/bachnotation.htm#pas singa How to typeset these with LP? “Harvard concise” says it is attached to the main note, and writes it as a small 8th note with a slash and a slur to the note before it. So this would be \afterGrace, but Notation does not say if \slashedGrace can be used with it. Perhaps LilyPond should have a \nachschlag counterpart to \acciaccatura. These hooks appear before short (typically 8th or 16th) notes in runs. Small as these hooks are, the original typesetter placed these carefully, the mid-point resting between or crossing the line where a the notehead of the auxiliary note would land (even providing them with ledger lines). For now, I'm notating these with smaller-sized appoggiatura 8ths, to at least provide some contrast with the regular appoggiaturas attached to longer notes, which do explicitly appear on Bach's manuscript. Thoughts? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hungarian Gregorian
Dear Pierre! I can't believe my eyes, it's beautiful! It is better than I suspected this curve connection between noteheads is elegant. Great job! When it will be completed I will forward this notation to church music department of Hungary to use lilypond. Unfortunately I haven't got enough time to try it. I hope I can support you with some comments in the future. I hope the sisters will pray for you. :D Sanyi On 3 February 2015 at 00:43, Pierre Perol-Schneider pierre.schneider.pa...@gmail.com wrote: 2015-02-02 15:49 GMT+01:00 Pierre Perol-Schneider pierre.schneider.pa...@gmail.com: 2015-02-02 15:43 GMT+01:00 Rita Composer ritacompo...@gmail.com: Another proble happened with the dots I attached an example. Ok, I'll take a look at tonight. As promised, see attached files. This is more or less a draft with some ideas (with far too many issues), even if the output isn't that bad. Waiting for your comments, Goodnight, Pierre ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hungarian Gregorian
I can't believe my eyes, it's beautiful! Indeed! Well done, Pierre. However, I have one minor nitpick: For my taste the stems are too long in general. I guess this is something that can be easily adjusted in case other people think the same. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list
Re: Variables when compiling a book
On 2 Feb 2015, at 21:34, John McWilliam jsmcwill...@gmail.com wrote: I am compiling a collection of bagpipe tunes and am having a problem when the individual files are to be compiled into a book. Many of the tunes have sections of music defined in variables - these definitions lie outside the \score context and are causing errors when I try to compile the book. Have you tried LilyPond-Book, which admits collecting separate .ly files into a book? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Get current file
i don't have the complete answer but just to get you started. May be this will help. currentWorkingDir.ly http://lilypond.1069038.n5.nabble.com/file/n171344/currentWorkingDir.ly -- View this message in context: http://lilypond.1069038.n5.nabble.com/Get-current-file-tp171234p171344.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Naming convention brainstorming
Hi all, thank you for your feedback. I've got the following suggestions: * Content mode (as opposed to presentation) * Entry mode * Working mode * Crafting mode * Sandbox * Debug-structure When collecting that list I realized that entry mode got three votes - while I had already decided to settle on this term. I think this is the most generic and unbiased way of expressing the idea, although even this one is not perfect. What would perfectly match the essence would be edit mode - but that is highly ambiguous so it is practically useless. Best Urs Am 01.02.2015 um 00:41 schrieb Urs Liska: Hi all, for quite some time now I've been using a concept that is very useful, but finally I'd like to give it an authoritative name to be used in different places. I'm talking about the working, thinking and compiling mode when I'm working on the _content_ of a score and not it's final visual appearance. This mode is characterized for example by - not caring too much about layout - not caring too much about engraving quality - being interested in visual feedback about manual interventions (e.g. coloring annotations or the result of custom functions) Originally we talked about it as draft mode but this doesn't seem to hit the spot. Nor do devel mode or preview mode. I would really like to find the right term now because I want to make that kind of an authoritative term for a configuration option in a redesigned openLilyLib and sort of a general library specification in that context. There should be a common configuration option that library authors can (and are encouraged to) respect in their functions. Say I have a library function \crossVoiceTie that does all the work for me with a hidden voice etc. Then this should highlight that tie or the hidden noteheads when that special mode is active. This approach has proven extremely useful and I'd be happy to promote this as a more general best-practice. So what are your feelings about this mode of working *before* finishing an engraving to publication quality? Thanks for any opinions Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
