GSoC update; Q's about final/draft modes, and triggering footnotes
Hi fellow LP users,
Firstly, thanks to Urs for all his guidance in the project so far. The
LaTeX package for scholarLY is inching forward still, and hopefully I
will share an initial version after a few more kinks have been worked
out with a couple of the features. I'll have more substantial details
soon, and ideally all will be wrapped in some sort of early
documentation along with the package and example docs.
I would like to ask for some feedback regarding two general topics.
***Footnotes***
Currently, in the annotation interface, we can set an `ann-footnote`
property which is sent to LaTeX as a footnote for the entire
annotation message (and not realized in LilyPond as an in-score
footnote). That is particularly useful/necessary for making sure that,
if used, the superscript would be placed *after* punctuation and
quotes (or whatever else might be used). Additionally any `\fn...`
used in a message property, such as `\fnSpecialNote` will link to the
value associated with `fn-special-note-text` if set (which is also
only applied in LaTeX and *not* lilypond, i.e. the score itself). So,
in use:
\criticalRemark \with {
message = "My message with\fnUnique two footnotes."
fn-unique-text = "A footnote within the message."
ann-footnote = "A footnote for the entire message."
} NoteHead c4
My question, since another aim is to actually trigger lilypond/score
footnotes from within annotations as well, is *how* you would
want/expect that to be implemented, including the nomenclature. My
initial thought is to add `score-footnote` as an additional (optional)
property in the annotation interface, and automatically link it to the
corresponding grob. It seems straightforward enough, but I want to be
sure I am not overlooking some other way of approaching this that
would be more intuitive.
***Final/"draft" Modes***
OpenLilyLib will ideally be used in final/draft/etc. modes in order to
toggle between fancy/plain settings, or really whatever the user
decides to work out. The idea is to be able to set/compile settings in
either mode at the individual package level (i.e. scholarLY, etc.),
and also to be able to toggle all-at-once by directing OLL's mode. And
individual packages will have an additional optional setting to *keep*
whatever mode regardless of OLL's mode, if so desired.
The question here is about naming mostly. A `final` mode is ideally
the *implicit* mode, so it doesn't have to be explicitly set (though
it still could be). An alternative mode, `draft` would need to be
turned on explicitly. There have apparently been discussions in the
past particularly about the name "draft" (though I haven't found them
in my search); in any case, I'd like to know what others think about
that now, and of course the concept of this feature in general.
Looking forward to your thoughts about these things, and to
following-up with some test-drivable results in the near future.
all best,
Jeffery
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: #(define (bookGenerator please))
2016-06-28 0:52 GMT+02:00 Thomas Morley :
> 2016-06-27 18:56 GMT+02:00 Pierre-Luc Gauthier :
>> Greetings,
>>
>> Sorry about the late follow up (about 7 months later).
>>
>> The orchestra I work with came down to a halt for the summer and I now
>> have some time to set stuff up for the next season.
>>
>> Many thanks to you Urs and David; your explanations certainly helped
>> me understand more of what was going on especially about quasi-quotes.
>>
>> Here is what I got so far.
>>
>> %
>>
>> \version "2.19.44"
>>
>> \language "english"
>>
>> \header {title = "Such title."}
>>
>> scoreA = \score {\header {piece = "Piece A"} a'4}
>>
>> scoreB = \score {\header {piece = "Piece B"} b'4}
>>
>> scores = #(list scoreA scoreB)
>>
>> #(define bookGenerator
>>(define-void-function
>> (
>> scoreList
>> bookSuffix
>> ;; header
>> paperBlock
>> layoutBlock
>> )
>> (list? string? scheme? scheme?) ;; add scheme? here
>> (let* (
>> (book (apply ly:make-book
>> paperBlock
>> #f ;; header
>> (reverse scoreList)))
>> )
>> (ly:book-process book paperBlock layoutBlock bookSuffix))
>> ))
>>
>> \bookGenerator
>> \scores
>> "violinI"
>> %\header {instrument = "Violin I"}
>> \paper {}
>> \layout {}
>>
>> %
>>
>> It works fine and I am pretty excited about this
>> ¡¡¡So long, 500+ lines of inflexible and unmaintainable book definitions!!!
>> Well, my problem is with the header.
>> I have not found a way to pass a header to the function ly:make-book.
>> I found #f to make the function compile... which obviously is not much
>> of a suitable header.
>>
>> How can I pass a header (and the global header) to ly:make-book?
>
>
> Below two different codings which you may find helpful
>
> (1) %
>
> \version "2.19.44"
>
> \language "english"
>
> bookGenerator =
> #(define-void-function (scoreList bookSuffix) (list? string?)
> (let* ((book (apply ly:make-book
> $defaultpaper
> $defaultheader
> (reverse scoreList
> (ly:book-process book $defaultpaper $defaultlayout bookSuffix)))
>
> book-header
> %% referenced as $defaultheader
> %% needs to be defined before new settings are done
> \header { title = "Such title." }
>
> %% header-settings added via scheme:
> %% settings stored in an alist:
> my-header-entries =
> #'((subtitle . "SUBTITLE")
>(dedication . "DEDICATION")
>(composer . "MYSELF"))
>
> %% apply them:
> #(for-each
> (lambda (e) (module-define! $defaultheader (car e) (cdr e)))
> my-header-entries)
>
> %% print header-settings to terminal
> %#(pretty-print (ly:module->alist $defaultheader))
>
> book-layout
> %% referenced as $defaultlayout
> \layout {
> \context {
> \Staff
> \override TimeSignature.color = #green
> }
> }
>
> book-paper
> %% referenced as $defaultpaper
> \paper { ragged-right = ##f }
>
> %% score-definitions with scoreheader-settings
> scoreA = \score { \header { piece = "Piece A" } a'4 }
> scoreB = \score { \header { piece = "Piece B" } b'4 }
>
> scores = #(list scoreA scoreB)
>
> %% print the book:
> \bookGenerator
> \scores
> "violinI"
>
> (2) %
>
> %% you can do a lot with those powerful functions, here another method
> %% `add-score` is a nice function as well
>
> \version "2.19.44"
>
> \language "english"
>
> scoreA = \score { \header { piece = "Piece A" } a'4 }
> scoreB = \score { \header { piece = "Piece B" } b'4 }
>
> \paper { ragged-right = ##f }
>
> \header { title = "Such title two." }
>
> \layout {
> \context {
> \Staff
> \override TimeSignature.color = #green
> }
> }
>
> bk = \book {}
>
> %% not really needed in this situation :
> #(ly:book-set-header! bk $defaultheader)
>
> %% you could use this in a book-generating function:
> #(for-each
> add-score
> (list scoreA scoreB))
>
> \bookOutputName "violinI"
or
(3) %%%
my-other-header-entries =
#'((title . "title")
(subtitle . "subtitlw")
(dedication . "dedication")
(composer . "myself"))
#(define my-defaultheader (make-module))
#(for-each
(lambda (e)
(module-define! my-defaultheader (car e) (cdr e)))
my-other-header-entries)
bookGeneratorTwo =
#(define-void-function (scoreList custom-header bookSuffix)
(list? module? string?)
(let* ((book (apply ly:make-book
$defaultpaper
custom-header
(reverse scoreList
(ly:book-process book $defaultpaper $defaultlayout bookSuffix)))
scoreA = \score { \header { piece = "Piece A-bis" } ais'4 }
scoreB = \score { \header { piece = "Piece B-bis" } bis'4 }
scores = #(list scoreA scoreB)
\bookGeneratorTwo
\scores
#my-defaultheader
"violinI-bis"
A plethora of possibilities ...
Cheers,
Harm
Re: #(define (bookGenerator please))
2016-06-27 18:56 GMT+02:00 Pierre-Luc Gauthier :
> Greetings,
>
> Sorry about the late follow up (about 7 months later).
>
> The orchestra I work with came down to a halt for the summer and I now
> have some time to set stuff up for the next season.
>
> Many thanks to you Urs and David; your explanations certainly helped
> me understand more of what was going on especially about quasi-quotes.
>
> Here is what I got so far.
>
> %
>
> \version "2.19.44"
>
> \language "english"
>
> \header {title = "Such title."}
>
> scoreA = \score {\header {piece = "Piece A"} a'4}
>
> scoreB = \score {\header {piece = "Piece B"} b'4}
>
> scores = #(list scoreA scoreB)
>
> #(define bookGenerator
>(define-void-function
> (
> scoreList
> bookSuffix
> ;; header
> paperBlock
> layoutBlock
> )
> (list? string? scheme? scheme?) ;; add scheme? here
> (let* (
> (book (apply ly:make-book
> paperBlock
> #f ;; header
> (reverse scoreList)))
> )
> (ly:book-process book paperBlock layoutBlock bookSuffix))
> ))
>
> \bookGenerator
> \scores
> "violinI"
> %\header {instrument = "Violin I"}
> \paper {}
> \layout {}
>
> %
>
> It works fine and I am pretty excited about this
> ¡¡¡So long, 500+ lines of inflexible and unmaintainable book definitions!!!
> Well, my problem is with the header.
> I have not found a way to pass a header to the function ly:make-book.
> I found #f to make the function compile... which obviously is not much
> of a suitable header.
>
> How can I pass a header (and the global header) to ly:make-book?
Below two different codings which you may find helpful
(1) %
\version "2.19.44"
\language "english"
bookGenerator =
#(define-void-function (scoreList bookSuffix) (list? string?)
(let* ((book (apply ly:make-book
$defaultpaper
$defaultheader
(reverse scoreList
(ly:book-process book $defaultpaper $defaultlayout bookSuffix)))
book-header
%% referenced as $defaultheader
%% needs to be defined before new settings are done
\header { title = "Such title." }
%% header-settings added via scheme:
%% settings stored in an alist:
my-header-entries =
#'((subtitle . "SUBTITLE")
(dedication . "DEDICATION")
(composer . "MYSELF"))
%% apply them:
#(for-each
(lambda (e) (module-define! $defaultheader (car e) (cdr e)))
my-header-entries)
%% print header-settings to terminal
%#(pretty-print (ly:module->alist $defaultheader))
book-layout
%% referenced as $defaultlayout
\layout {
\context {
\Staff
\override TimeSignature.color = #green
}
}
book-paper
%% referenced as $defaultpaper
\paper { ragged-right = ##f }
%% score-definitions with scoreheader-settings
scoreA = \score { \header { piece = "Piece A" } a'4 }
scoreB = \score { \header { piece = "Piece B" } b'4 }
scores = #(list scoreA scoreB)
%% print the book:
\bookGenerator
\scores
"violinI"
(2) %
%% you can do a lot with those powerful functions, here another method
%% `add-score` is a nice function as well
\version "2.19.44"
\language "english"
scoreA = \score { \header { piece = "Piece A" } a'4 }
scoreB = \score { \header { piece = "Piece B" } b'4 }
\paper { ragged-right = ##f }
\header { title = "Such title two." }
\layout {
\context {
\Staff
\override TimeSignature.color = #green
}
}
bk = \book {}
%% not really needed in this situation :
#(ly:book-set-header! bk $defaultheader)
%% you could use this in a book-generating function:
#(for-each
add-score
(list scoreA scoreB))
\bookOutputName "violinI"
> %
>
> A few side questions,
>
> Also, How can I make my function be more "indentable" by using, for
> example, curly braces e.g. \bookGenerator { stuff } ?
No idea what you mean.
>
> Why do I have to pass a paperBlock to ly:make-book AND to ly:book-process ?
> Is there a way to only have one?
> Doesn't the ly:make-book already contains the paperBlock ?
ly:make-book creates the book. Now you could add this and that ...
After you finished your work on the probably modified book you need to
print it with ly:book-process
> OT discussion; Frescobaldi can not, currently, get a hold of those PDF
> generated with lower level commands
> As this [1] comment stated, the LilyPond output could be a fail-safe
> way to track down every generated PDFs instead of reverse engineering
> the generated filenames as it is (I think) currently the case.
Can't say anything here, I don't use Frescobaldi
>
> [1] https://github.com/wbsoft/frescobaldi/issues/546#issuecomment-155148714
>
>
> --
> Pierre-Luc Gauthier
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
_
Re: #(define (bookGenerator please))
Greetings,
Sorry about the late follow up (about 7 months later).
The orchestra I work with came down to a halt for the summer and I now
have some time to set stuff up for the next season.
Many thanks to you Urs and David; your explanations certainly helped
me understand more of what was going on especially about quasi-quotes.
Here is what I got so far.
%
\version "2.19.44"
\language "english"
\header {title = "Such title."}
scoreA = \score {\header {piece = "Piece A"} a'4}
scoreB = \score {\header {piece = "Piece B"} b'4}
scores = #(list scoreA scoreB)
#(define bookGenerator
(define-void-function
(
scoreList
bookSuffix
;; header
paperBlock
layoutBlock
)
(list? string? scheme? scheme?) ;; add scheme? here
(let* (
(book (apply ly:make-book
paperBlock
#f ;; header
(reverse scoreList)))
)
(ly:book-process book paperBlock layoutBlock bookSuffix))
))
\bookGenerator
\scores
"violinI"
%\header {instrument = "Violin I"}
\paper {}
\layout {}
%
It works fine and I am pretty excited about this
¡¡¡So long, 500+ lines of inflexible and unmaintainable book definitions!!!
Well, my problem is with the header.
I have not found a way to pass a header to the function ly:make-book.
I found #f to make the function compile... which obviously is not much
of a suitable header.
How can I pass a header (and the global header) to ly:make-book?
%
A few side questions,
Also, How can I make my function be more "indentable" by using, for
example, curly braces e.g. \bookGenerator { stuff } ?
Why do I have to pass a paperBlock to ly:make-book AND to ly:book-process ?
Is there a way to only have one?
Doesn't the ly:make-book already contains the paperBlock ?
OT discussion; Frescobaldi can not, currently, get a hold of those PDF
generated with lower level commands
As this [1] comment stated, the LilyPond output could be a fail-safe
way to track down every generated PDFs instead of reverse engineering
the generated filenames as it is (I think) currently the case.
[1] https://github.com/wbsoft/frescobaldi/issues/546#issuecomment-155148714
--
Pierre-Luc Gauthier
\version "2.19.44"
\language "english"
\header {title = "Such title."}
scoreA = \score {\header {piece = "Piece A"} a'4}
scoreB = \score {\header {piece = "Piece B"} b'4}
scores = #(list scoreA scoreB)
#(define bookGenerator
(define-void-function
(
scoreList
bookSuffix
;; header
paperBlock
layoutBlock
)
(list? string? scheme? scheme?) ;; add scheme? here
(let* (
(book (apply ly:make-book
paperBlock
#f ;; header
(reverse scoreList)))
)
(ly:book-process book paperBlock layoutBlock bookSuffix))
))
\bookGenerator
\scores
"violinI"
%\header {instrument = "Violin I"}
\paper {}
\layout {}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Flute Accompaniment
Nathan,
That worked like a charm! Thank you very much!
On 6/26/2016 1:23 PM, Nathan Ho wrote:
Hello,
Try adding the following \with block to your Staff:
\new Staff \with {
fontSize = #-3
\override StaffSymbol.staff-space = #(magstep -3)
\override StaffSymbol.thickness = #(magstep -3)
} {
% Music follows here
}
it's been a while since I used LilyPond so this knowledge
might be a bit out of date... I think in the development
version there's a new way to do this.
Nathan
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sorting out annotation interface questions (GSoC)
Hi Simon,
thanks for the feedback.
Am 27. Juni 2016 13:21:25 MESZ, schrieb Simon Albrecht :
>On 27.06.2016 00:55, Urs Liska wrote:
>> \musicalIssue \with {
>>author = "Urs Liska"
>>context = "violin 1"
>>message = "Slur obviously forgotten in original edition"
>>apply = addition
>> } Slur
>>
>> My question is: is this "application" the same as the type of
>annotation
>> action from the previous issue? Or could it occur that a project
>wants
>> to document types of editorial decisions independently from applying
>> visual indications of that?
>
>A few unsystematic thoughts:
>Well, there are limits to visual indication of critical matters. At
>least in some projects it will be impossible for the score to contain
>(or even hint to) every bit of information present in the Critical
>Report.
>I really think we should allow for great diversity in the possible
>approaches, i.e. editorial policies.
We certainly don't intend to impose editorial policies but to provide the tols
to tailor project specific behaviour.
By default annotations dob't have any impact on the layout (which is crucial)
but just colorize objects while in draft mode.
Additionally we'll provide generic commands that can be used to visually
indicate certain types of editorial action.
For example something like \editorialAddition can be used to indicate something
that is missing in the source and has been added by the editor. By default this
might make slurs dashed and parenthesize other types of elements. Of course the
visual appearance will be configurable so only the semantic command is inserted
in the music.
Now annotations *can* trigger the application of such editorial commands (which
can also be used independently from annitations).
My question is: are the *type* of decision and the triggering oc commands
inherently independent so we should implement both a property forvthe
annotation type *and* the applied command or could they be "merged"?
> In some cases it might be good to
>have a simple switch (modernise lyrics or not);
>in other cases everything must be decided on a case-by-case basis, with
>
>no automation being possible;
>and the type of annotations one will have, as well as how to display
>them in both the score and the critical apparatus, will be very
>different depending on the project.
Of course, as commented on above.
>Perhaps that at one time our footnotes engine will be sophisticated
>enough to be used for such purposes, and include the apparatus in the
>actual musical text. It would be good to have hooks for such an
>approach.
Triggering footnotes from annotations is on the GSoC task list. As is the
possibility to insert scores in annotations (to be printed in a footnote for
example, or in the LaTeX critical report).
Best
Urs
>
>I’m sorry I don’t have the time to take a deeper dive into this, but I
>really appreciate your efforts!
>
>Best, Simon
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sorting out annotation interface questions (GSoC)
On 27.06.2016 00:55, Urs Liska wrote:
\musicalIssue \with {
author = "Urs Liska"
context = "violin 1"
message = "Slur obviously forgotten in original edition"
apply = addition
} Slur
My question is: is this "application" the same as the type of annotation
action from the previous issue? Or could it occur that a project wants
to document types of editorial decisions independently from applying
visual indications of that?
A few unsystematic thoughts:
Well, there are limits to visual indication of critical matters. At
least in some projects it will be impossible for the score to contain
(or even hint to) every bit of information present in the Critical Report.
I really think we should allow for great diversity in the possible
approaches, i.e. editorial policies. In some cases it might be good to
have a simple switch (modernise lyrics or not);
in other cases everything must be decided on a case-by-case basis, with
no automation being possible;
and the type of annotations one will have, as well as how to display
them in both the score and the critical apparatus, will be very
different depending on the project.
Perhaps that at one time our footnotes engine will be sophisticated
enough to be used for such purposes, and include the apparatus in the
actual musical text. It would be good to have hooks for such an approach.
I’m sorry I don’t have the time to take a deeper dive into this, but I
really appreciate your efforts!
Best, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: (unknown)
Scott Lawrence writes:
> So I downloaded lilypond... All I get when I start the application is
> the following message: "%{
> Welcome to LilyPond
> ===
>
> Congratulations, LilyPond has been installed successfully.
>
> Now to take it for the first test run.
>
> 1. Save this file
>
> 2. Select
>
> Compile > Typeset file
>
> from the menu.
>
> The file is processed, and
>
> 3. The PDF viewer will pop up. Click one of the noteheads.
>
>
> That's it. For more information, visit http://lilypond.org .
>
> %}
>
> \header{
> title = "A scale in LilyPond"
> }
>
> \relative {
> c d e f g a b c
> }
>
>
> \version "2.18.2" % necessary for upgrading to future LilyPond versions."
>
> I saved it like it said but I see no musical things
Saving it was "1." in the list. The list also contains "2." and "3.".
The list is not a list of alternatives but is rather a _sequence_ of
steps to perform.
Have you tried following up step "1." with steps "2." and "3."? If you
did, how did you fare with those?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
[no subject]
So I downloaded lilypond... All I get when I start the application is the
following message: "%{
Welcome to LilyPond
===
Congratulations, LilyPond has been installed successfully.
Now to take it for the first test run.
1. Save this file
2. Select
Compile > Typeset file
from the menu.
The file is processed, and
3. The PDF viewer will pop up. Click one of the noteheads.
That's it. For more information, visit http://lilypond.org .
%}
\header{
title = "A scale in LilyPond"
}
\relative {
c d e f g a b c
}
\version "2.18.2" % necessary for upgrading to future LilyPond versions."
I saved it like it said but I see no musical things
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
