Re: ScholarLY

[Craig Dabelstein]

\setOption stylesheets.span.use-colors ##f
did the trick.

Thanks Urs


On Wed, 17 Oct 2018 at 15:40, Urs Liska  wrote:

>
>
> Am 17.10.2018 um 03:00 schrieb Craig Dabelstein:
>
> Hi all,
>
> Is this the right code to use to turn off the colors in ScholarLy? I'm
> using the latest version, but I'm using the \editorialMarkup commands.
>
> This line is having no effect. I'm sure I'm doing something wrong
> somewhere.
>
> \setOption scholarly.annotate.use-colors ##f
>
>
> Does it really have *no* effect? I can't reproduce that, so you should
> provide a MWE.
> However, what you will probably want to do in addition is
>
> \setOption stylesheets.span.use-colors ##f
>
> because the span provides its own coloring. Concretely: the span colors
> the whole annotated music expression while the annotation colors the
> *anchor* element *on top* of that.
>
> HTH
> Urs
>
>
> Craig
>
> --
> *Craig Dabelstein*
> Maxime's Music
> craig.dabelst...@gmail.com
> *http://maximesmusic.com *
>
>
> ___
> lilypond-user mailing 
> listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY

[Urs Liska]

Am 17.10.2018 um 03:00 schrieb Craig Dabelstein:

Hi all,

Is this the right code to use to turn off the colors in ScholarLy? I'm 
using the latest version, but I'm using the \editorialMarkup commands.


This line is having no effect. I'm sure I'm doing something wrong 
somewhere.


\setOption scholarly.annotate.use-colors ##f


Does it really have *no* effect? I can't reproduce that, so you should 
provide a MWE.

However, what you will probably want to do in addition is

\setOption stylesheets.span.use-colors ##f

because the span provides its own coloring. Concretely: the span colors 
the whole annotated music expression while the annotation colors the 
*anchor* element *on top* of that.


HTH
Urs



Craig

--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/


___
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: Scholarly question

[Urs Liska]

Hi Craig,


Am 10.04.2018 um 01:01 schrieb Craig Dabelstein:

Hi all,

Is this the correct way to ignore critical remarks in the output file?

\ignoreAnnotationTypes #'()


No, it isn't. And while looking into the files I realize that this 
option isn't commented properly.


The proper command to ignore critical remarks (while producing the 
annotations) is


\setOption scholarly.annotate.ignored-types #'(critical-remark)

You set the corresponding option to a symbol list with all the 
annotation types you do *not* want to be included in the output, the 
values are those defined in module.ily: critical-remark, musical-issue, 
lilypond-issue, question, and todo.


I'll update the file to at least have this information present as 
comments to the option.


Urs




Thanks in advance,

Craig

--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/


___
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: ScholarLy and Latex

[Craig Dabelstein]

Urs,

The "temp-print-message" branch worked perfectly first time. You are
amazing! One small problem for me though -- the output is rendering the
measure and beat with the lilyglyphs ({1}{4.\,\crotchet}). How can I get it
back to just {1}{4} without the lilyglyph? I know I've seen how to do it
somewhere but I just can't find it.

All the best,

Craig


On 11 March 2018 at 09:22, Craig Dabelstein 
wrote:

> Hi Urs,
>
> Thanks very much for all that information. I'll check out the
> "temp-print-message" branch and let you know how I go.
>
> All the best,
>
> Craig
>
>
> On 8 March 2018 at 02:12, Urs Liska  wrote:
>
>> Hi Craig,
>>
>> sorry for the delay, but I had quite reduced capacities during the past
>> week.
>>
>> I'm even more sorry to inform you that what you experience is "expected
>> behaviour" and the result of incomplete implementation :-(
>>
>> The exported annotations put a number of information items (including the
>> message!) in one optional argument, followed by four mandatory arguments
>> with the curly braces.
>>
>>
>> However, in the .sty file the commands are defined to expect six
>> arguments, the first one being optional:
>>
>> \newcommand{\criticalRemark}[6][]{
>> \annotation[#1]{#2}{#3}{#4}{#5}{#6}
>>  {Critical Remark}}
>>
>> This makes \criticalRemark call \annotation, pass its six arguments to it
>> and one hard-coded "Critical Remark" argument as seventh.
>>
>> The code exported from scholarly does not export that sixth argument, and
>> consequently it is empty when it reaches \annotation.
>> As you have noticed, if you copy the entry to the end of the list of
>> arguments it will be printed correctly.
>>
>> I'm not sure what to advise you right now. Your are actually suffering
>> from the fact that I didn't manage to keep hold of the project. In addition
>> to what is "publicly" available there is an "initial LaTeX package" in the
>> repository, on the unmerged branch 'initial-latex-package' with substantial
>> code additions and unfortunately the lack of review on my part. Maybe this
>> branch is actually ready to be merged, but I simply don't really know.
>> And unfortunately I can't promise to change that immediately. Although I
>> should take your report as the incentive to finally get back to that, now
>> that lyluatex is also "out".
>>
>> I have pushed a temporary fix to the temp-print-message branch. If you
>> checkout that branch and recompile the LilyPond score the annotation
>> message will be added to the list of arguments, and your report.sty will
>> properly read in the message.
>> But I don't really like that hack, and you have to be aware that this
>> interface may not be stable.
>>
>> Sorry for not having much better info for you
>> Best
>> Urs
>>
>>
>> Am 02.03.2018 um 10:25 schrieb Craig Dabelstein:
>>
>> Hi Urs,
>>
>> I hope you can understand these files. I think the report.sty file was
>> borrowed from your Scores of Beauty post a long time ago (maybe). My
>> problem is trying to get the content of the "message" field to be
>> displayed.
>>
>> All the best,
>>
>> Craig
>>
>>
>> On 1 March 2018 at 19:05, Urs Liska  wrote:
>>
>>> Hi Craig,
>>>
>>> Am 23.02.2018 um 10:07 schrieb Craig Dabelstein:
>>>
>>> Hi Lilyponders,
>>>
>>> I'm having a minor problem with getting my ScholarLy inp file to work
>>> with Latex. The Latex output for each annotation looks like this:
>>>
>>> \criticalRemark
>>>[grob={DynamicText},
>>> grob-location={Can't display grob location yet},
>>> grob-type={DynamicText},
>>> input-file-name={fluteI.ily},
>>> context-id={Flauto 1},
>>> location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
>>> edition/Parts/../Notes/fluteI.ily 55:2:2},
>>> type={critical-remark},
>>> message={Added missing \lilyDynamics{p}}]
>>> {18}{6}
>>> {Flauto 1}
>>> {DynamicText}
>>>
>>> And within my Latex file each entry is displayed with this code:
>>>
>>> \noindent
>>> \theAnnotationNo\,)\\
>>> \textit{(#7)}\\
>>> \ifthenelse{\equal{#2}{\value{CurrentMeasure}}}
>>> {}{\textbf{M. #2},
>>> \setcounter{CurrentMeasure}{#2}}%
>>> beat #3\\
>>> #4\\
>>> Affects: #5\\
>>> ``#6''}
>>>
>>> My problem is that Latex won't display the #6 (the contents of the
>>> message field). It is displaying the quotation marks but just empty space
>>> in between. If I cut and paste the message field and add it to the bottom
>>> of the code it displays perfectly correctly:
>>>
>>> \criticalRemark
>>>[grob={DynamicText},
>>> grob-location={Can't display grob location yet},
>>> grob-type={DynamicText},
>>> input-file-name={fluteI.ily},
>>> context-id={Flauto 1},
>>> location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
>>> edition/Parts/../Notes/fluteI.ily 55:2:2},
>>> type={critical-remark},
>>> message={Added missing \lilyDynamics{p}}]
>>> {18}{6}
>>> {Flauto 1}
>>> {DynamicText}
>>> {Added missing \lilyDynamics{p}}
>>>
>>>
>>> Any ideas where I could be going wrong?
>>>

Re: ScholarLy and Latex

[Craig Dabelstein]

Hi Urs,

Thanks very much for all that information. I'll check out the
"temp-print-message" branch and let you know how I go.

All the best,

Craig


On 8 March 2018 at 02:12, Urs Liska  wrote:

> Hi Craig,
>
> sorry for the delay, but I had quite reduced capacities during the past
> week.
>
> I'm even more sorry to inform you that what you experience is "expected
> behaviour" and the result of incomplete implementation :-(
>
> The exported annotations put a number of information items (including the
> message!) in one optional argument, followed by four mandatory arguments
> with the curly braces.
>
>
> However, in the .sty file the commands are defined to expect six
> arguments, the first one being optional:
>
> \newcommand{\criticalRemark}[6][]{
> \annotation[#1]{#2}{#3}{#4}{#5}{#6}
>   {Critical Remark}}
>
> This makes \criticalRemark call \annotation, pass its six arguments to it
> and one hard-coded "Critical Remark" argument as seventh.
>
> The code exported from scholarly does not export that sixth argument, and
> consequently it is empty when it reaches \annotation.
> As you have noticed, if you copy the entry to the end of the list of
> arguments it will be printed correctly.
>
> I'm not sure what to advise you right now. Your are actually suffering
> from the fact that I didn't manage to keep hold of the project. In addition
> to what is "publicly" available there is an "initial LaTeX package" in the
> repository, on the unmerged branch 'initial-latex-package' with substantial
> code additions and unfortunately the lack of review on my part. Maybe this
> branch is actually ready to be merged, but I simply don't really know.
> And unfortunately I can't promise to change that immediately. Although I
> should take your report as the incentive to finally get back to that, now
> that lyluatex is also "out".
>
> I have pushed a temporary fix to the temp-print-message branch. If you
> checkout that branch and recompile the LilyPond score the annotation
> message will be added to the list of arguments, and your report.sty will
> properly read in the message.
> But I don't really like that hack, and you have to be aware that this
> interface may not be stable.
>
> Sorry for not having much better info for you
> Best
> Urs
>
>
> Am 02.03.2018 um 10:25 schrieb Craig Dabelstein:
>
> Hi Urs,
>
> I hope you can understand these files. I think the report.sty file was
> borrowed from your Scores of Beauty post a long time ago (maybe). My
> problem is trying to get the content of the "message" field to be
> displayed.
>
> All the best,
>
> Craig
>
>
> On 1 March 2018 at 19:05, Urs Liska  wrote:
>
>> Hi Craig,
>>
>> Am 23.02.2018 um 10:07 schrieb Craig Dabelstein:
>>
>> Hi Lilyponders,
>>
>> I'm having a minor problem with getting my ScholarLy inp file to work
>> with Latex. The Latex output for each annotation looks like this:
>>
>> \criticalRemark
>>[grob={DynamicText},
>> grob-location={Can't display grob location yet},
>> grob-type={DynamicText},
>> input-file-name={fluteI.ily},
>> context-id={Flauto 1},
>> location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
>> edition/Parts/../Notes/fluteI.ily 55:2:2},
>> type={critical-remark},
>> message={Added missing \lilyDynamics{p}}]
>> {18}{6}
>> {Flauto 1}
>> {DynamicText}
>>
>> And within my Latex file each entry is displayed with this code:
>>
>> \noindent
>> \theAnnotationNo\,)\\
>> \textit{(#7)}\\
>> \ifthenelse{\equal{#2}{\value{CurrentMeasure}}}
>> {}{\textbf{M. #2},
>> \setcounter{CurrentMeasure}{#2}}%
>> beat #3\\
>> #4\\
>> Affects: #5\\
>> ``#6''}
>>
>> My problem is that Latex won't display the #6 (the contents of the
>> message field). It is displaying the quotation marks but just empty space
>> in between. If I cut and paste the message field and add it to the bottom
>> of the code it displays perfectly correctly:
>>
>> \criticalRemark
>>[grob={DynamicText},
>> grob-location={Can't display grob location yet},
>> grob-type={DynamicText},
>> input-file-name={fluteI.ily},
>> context-id={Flauto 1},
>> location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
>> edition/Parts/../Notes/fluteI.ily 55:2:2},
>> type={critical-remark},
>> message={Added missing \lilyDynamics{p}}]
>> {18}{6}
>> {Flauto 1}
>> {DynamicText}
>> {Added missing \lilyDynamics{p}}
>>
>>
>> Any ideas where I could be going wrong?
>>
>>
>> Not yet, but could you please send a MWE, i.e. a complete file, with
>> maybe that critical remark just added in the file (instead of inputted)?
>> What exactly is context of the code that displays the annotation, i.e.
>> where's the complete definition of the "\criticalRemark" macro?
>>
>> Urs
>>
>> Thanks in advance,
>>
>> Craig
>>
>>
>> --
>> *Craig Dabelstein*
>> Maxime's Music
>> craig.dabelst...@gmail.com
>> *http://maximesmusic.com *
>>
>>
>> ___
>> lilypond-user m

Re: ScholarLy and Latex

[Urs Liska]

Hi Craig,

sorry for the delay, but I had quite reduced capacities during the past 
week.


I'm even more sorry to inform you that what you experience is "expected 
behaviour" and the result of incomplete implementation :-(


The exported annotations put a number of information items (including 
the message!) in one optional argument, followed by four mandatory 
arguments with the curly braces.



However, in the .sty file the commands are defined to expect six 
arguments, the first one being optional:


\newcommand{\criticalRemark}[6][]{
\annotation[#1]{#2}{#3}{#4}{#5}{#6}
{Critical Remark}}

This makes \criticalRemark call \annotation, pass its six arguments to 
it and one hard-coded "Critical Remark" argument as seventh.


The code exported from scholarly does not export that sixth argument, 
and consequently it is empty when it reaches \annotation.
As you have noticed, if you copy the entry to the end of the list of 
arguments it will be printed correctly.


I'm not sure what to advise you right now. Your are actually suffering 
from the fact that I didn't manage to keep hold of the project. In 
addition to what is "publicly" available there is an "initial LaTeX 
package" in the repository, on the unmerged branch 
'initial-latex-package' with substantial code additions and 
unfortunately the lack of review on my part. Maybe this branch is 
actually ready to be merged, but I simply don't really know.
And unfortunately I can't promise to change that immediately. Although I 
should take your report as the incentive to finally get back to that, 
now that lyluatex is also "out".


I have pushed a temporary fix to the temp-print-message branch. If you 
checkout that branch and recompile the LilyPond score the annotation 
message will be added to the list of arguments, and your report.sty will 
properly read in the message.
But I don't really like that hack, and you have to be aware that this 
interface may not be stable.


Sorry for not having much better info for you
Best
Urs

Am 02.03.2018 um 10:25 schrieb Craig Dabelstein:

Hi Urs,

I hope you can understand these files. I think the report.sty file was 
borrowed from your Scores of Beauty post a long time ago (maybe). My 
problem is trying to get the content of the "message" field to be 
displayed.


All the best,

Craig


On 1 March 2018 at 19:05, Urs Liska > wrote:


Hi Craig,


Am 23.02.2018 um 10:07 schrieb Craig Dabelstein:

Hi Lilyponders,

I'm having a minor problem with getting my ScholarLy inp file to
work with Latex. The Latex output for each annotation looks like
this:

\criticalRemark
   [grob={DynamicText},
    grob-location={Can't display grob location yet},
    grob-type={DynamicText},
    input-file-name={fluteI.ily},
    context-id={Flauto 1},
   
location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
edition/Parts/../Notes/fluteI.ily 55:2:2},
    type={critical-remark},
    message={Added missing \lilyDynamics{p}}]
    {18}{6}
    {Flauto 1}
    {DynamicText}

And within my Latex file each entry is displayed with this code:

\noindent
\theAnnotationNo\,)\\
\textit{(#7)}\\
\ifthenelse{\equal{#2}{\value{CurrentMeasure}}}
{}{\textbf{M. #2},
\setcounter{CurrentMeasure}{#2}}%
beat #3\\
#4\\
Affects: #5\\
``#6''}

My problem is that Latex won't display the #6 (the contents of
the message field). It is displaying the quotation marks but just
empty space in between. If I cut and paste the message field and
add it to the bottom of the code it displays perfectly correctly:

\criticalRemark
 [grob={DynamicText},
  grob-location={Can't display grob location yet},
  grob-type={DynamicText},
  input-file-name={fluteI.ily},
  context-id={Flauto 1},
 
location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
edition/Parts/../Notes/fluteI.ily 55:2:2},
  type={critical-remark},
  message={Added missing \lilyDynamics{p}}]
  {18}{6}
  {Flauto 1}
  {DynamicText}
  {Added missing \lilyDynamics{p}}


Any ideas where I could be going wrong?



Not yet, but could you please send a MWE, i.e. a complete file,
with maybe that critical remark just added in the file (instead of
inputted)? What exactly is context of the code that displays the
annotation, i.e. where's the complete definition of the
"\criticalRemark" macro?

Urs


Thanks in advance,

Craig


-- 
*Craig Dabelstein*

Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/


___
lilypond-user mailing list
lilypond-user@gnu.org 
https://lists.gnu.org/mailman/listinfo/lilypond-user




__

Re: ScholarLy and Latex

[Craig Dabelstein]

Hi Urs,

I hope you can understand these files. I think the report.sty file was
borrowed from your Scores of Beauty post a long time ago (maybe). My
problem is trying to get the content of the "message" field to be
displayed.

All the best,

Craig


On 1 March 2018 at 19:05, Urs Liska  wrote:

> Hi Craig,
>
> Am 23.02.2018 um 10:07 schrieb Craig Dabelstein:
>
> Hi Lilyponders,
>
> I'm having a minor problem with getting my ScholarLy inp file to work with
> Latex. The Latex output for each annotation looks like this:
>
> \criticalRemark
>[grob={DynamicText},
> grob-location={Can't display grob location yet},
> grob-type={DynamicText},
> input-file-name={fluteI.ily},
> context-id={Flauto 1},
> location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
> edition/Parts/../Notes/fluteI.ily 55:2:2},
> type={critical-remark},
> message={Added missing \lilyDynamics{p}}]
> {18}{6}
> {Flauto 1}
> {DynamicText}
>
> And within my Latex file each entry is displayed with this code:
>
> \noindent
> \theAnnotationNo\,)\\
> \textit{(#7)}\\
> \ifthenelse{\equal{#2}{\value{CurrentMeasure}}}
> {}{\textbf{M. #2},
> \setcounter{CurrentMeasure}{#2}}%
> beat #3\\
> #4\\
> Affects: #5\\
> ``#6''}
>
> My problem is that Latex won't display the #6 (the contents of the message
> field). It is displaying the quotation marks but just empty space in
> between. If I cut and paste the message field and add it to the bottom of
> the code it displays perfectly correctly:
>
> \criticalRemark
>[grob={DynamicText},
> grob-location={Can't display grob location yet},
> grob-type={DynamicText},
> input-file-name={fluteI.ily},
> context-id={Flauto 1},
> location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical
> edition/Parts/../Notes/fluteI.ily 55:2:2},
> type={critical-remark},
> message={Added missing \lilyDynamics{p}}]
> {18}{6}
> {Flauto 1}
> {DynamicText}
> {Added missing \lilyDynamics{p}}
>
>
> Any ideas where I could be going wrong?
>
>
> Not yet, but could you please send a MWE, i.e. a complete file, with maybe
> that critical remark just added in the file (instead of inputted)? What
> exactly is context of the code that displays the annotation, i.e. where's
> the complete definition of the "\criticalRemark" macro?
>
> Urs
>
> Thanks in advance,
>
> Craig
>
>
> --
> *Craig Dabelstein*
> Maxime's Music
> craig.dabelst...@gmail.com
> *http://maximesmusic.com *
>
>
> ___
> lilypond-user mailing 
> listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>


-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *

\NeedsTeXFormat{LaTeX2e} 
\ProvidesPackage{report}

\RequirePackage{ifthen}

\newcounter{CurrentMeasure}
\newcounter{AnnotationNo}

% Print an annotation
%
% Initial implementation is a quite hard-coded thing,
% just to get it started at all.
% It is intended to make the generation of output as modular as possible.
% The annotation should be put together from individual macros. This will
% enable users to
% a) renew the macros to change the appearance of individual parts
% b) renew the \annotation command to reorganize it by keeping the formatting
%of the individual building blocks.

% The macro is designed to take its data from output generated by LilyPond's
% (or rather ScholarLY's) \annotate function, but it can equally be used
% directly, from manually entered LaTeX code.
%
% It takes seven properties, the first one being an optional key=value set:
% #1: Additional arguments. Has to be parsed separately
%(not implemented yet)
% #2: Measure number
% #3: Beat string (currently not good enough yet)
% #4: Affected context (voice)
% #5: Affected type of notational element
%(currently not used, needs a nice lookup in the LilyPond part)
% #6: Annotation content (message)
% #7: Annotation type

\newcommand{\annotation}[7][]{%
\stepcounter{AnnotationNo}

\medskip
\noindent
\ifthenelse{\equal{#2}{\value{CurrentMeasure}}}
{--- }{\textbf{M.\,#2,}
\setcounter{CurrentMeasure}{#2}}%
beat #3, #4: ``#6'' \textit{(\theAnnotationNo)}}

% Several wrapper functions to typeset different kinds of annotations.
% For now these only differ through the label, but they could be
% extended in the future, e.g. through conditional coloring in draft mode etc.

% Intended for proper critical remarks
\newcommand{\criticalRemark}[6][]{
\annotation[#1]{#2}{#3}{#4}{#5}{#6}
{Critical Remark}}


% Intended for critical remarks that still have to be discussed.
% Usually the goal is to turn all into critical remarks.
\newcommand{\musicalIssue}[6][]{
\annotation[#1]{#2}{#3}{#4}{#5}{#6}
{

Re: ScholarLy and Latex

[Urs Liska]

Hi Craig,


Am 23.02.2018 um 10:07 schrieb Craig Dabelstein:

Hi Lilyponders,

I'm having a minor problem with getting my ScholarLy inp file to work 
with Latex. The Latex output for each annotation looks like this:


\criticalRemark
   [grob={DynamicText},
    grob-location={Can't display grob location yet},
    grob-type={DynamicText},
    input-file-name={fluteI.ily},
    context-id={Flauto 1},
location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical 
edition/Parts/../Notes/fluteI.ily 55:2:2},

    type={critical-remark},
    message={Added missing \lilyDynamics{p}}]
    {18}{6}
    {Flauto 1}
    {DynamicText}

And within my Latex file each entry is displayed with this code:

\noindent
\theAnnotationNo\,)\\
\textit{(#7)}\\
\ifthenelse{\equal{#2}{\value{CurrentMeasure}}}
{}{\textbf{M. #2},
\setcounter{CurrentMeasure}{#2}}%
beat #3\\
#4\\
Affects: #5\\
``#6''}

My problem is that Latex won't display the #6 (the contents of the 
message field). It is displaying the quotation marks but just empty 
space in between. If I cut and paste the message field and add it to 
the bottom of the code it displays perfectly correctly:


\criticalRemark
 [grob={DynamicText},
  grob-location={Can't display grob location yet},
  grob-type={DynamicText},
  input-file-name={fluteI.ily},
  context-id={Flauto 1},
location={/Users//Maximes_Music/Projects/MM0110/Hallager/critical 
edition/Parts/../Notes/fluteI.ily 55:2:2},

  type={critical-remark},
  message={Added missing \lilyDynamics{p}}]
  {18}{6}
  {Flauto 1}
  {DynamicText}
  {Added missing \lilyDynamics{p}}


Any ideas where I could be going wrong?



Not yet, but could you please send a MWE, i.e. a complete file, with 
maybe that critical remark just added in the file (instead of inputted)? 
What exactly is context of the code that displays the annotation, i.e. 
where's the complete definition of the "\criticalRemark" macro?


Urs


Thanks in advance,

Craig


--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/


___
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: Scholarly editorial functions

[Urs Liska]

Still not at my PC, but does that page help?

https://github.com/openlilylib/scholarly/blob/master/editorial-functions/README.md


Am 3. Februar 2018 22:18:47 MEZ schrieb Urs Liska :
>Hi Craig,
>
>first you should mention that you are using openLilyLib and the
>scholarly package. Most people will not recognise that.
>
>Second: I'll have to look up how that works (I'm not at my PC ATM)
>
>Urs
>
>Am 3. Februar 2018 22:11:26 MEZ schrieb Craig Dabelstein
>:
>>Hi all,
>>
>>I have two questions:
>>
>>[1] Is there an option I can add here to make dashed Hairpins?
>>
>>\setOption scholarly.editorial.functions.addition
>>#`((NoteHead . ,parenthesize)
>>   (Slur . ,slurDashed)
>>   (Tie . ,tieDashed)
>>   (PhrasingSlur . ,phrasingSlurDashed))
>>
>>[2] If I label a critical remark as an addition (apply = addition) but
>>I
>>don't need any kind of appearance change, is there something I can add
>>to
>>the above code to suppress the errors.
>>
>>Editorial command #f not set for Script
>>Editorial command #f not set for DynamicText
>>Editorial command #f not set for Hairpin
>>
>>Thanks in advance,
>>
>>Craig
>
>___
>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: Scholarly editorial functions

[Urs Liska]

Hi Craig,

first you should mention that you are using openLilyLib and the scholarly 
package. Most people will not recognise that.

Second: I'll have to look up how that works (I'm not at my PC ATM)

Urs

Am 3. Februar 2018 22:11:26 MEZ schrieb Craig Dabelstein 
:
>Hi all,
>
>I have two questions:
>
>[1] Is there an option I can add here to make dashed Hairpins?
>
>\setOption scholarly.editorial.functions.addition
>#`((NoteHead . ,parenthesize)
>   (Slur . ,slurDashed)
>   (Tie . ,tieDashed)
>   (PhrasingSlur . ,phrasingSlurDashed))
>
>[2] If I label a critical remark as an addition (apply = addition) but
>I
>don't need any kind of appearance change, is there something I can add
>to
>the above code to suppress the errors.
>
>Editorial command #f not set for Script
>Editorial command #f not set for DynamicText
>Editorial command #f not set for Hairpin
>
>Thanks in advance,
>
>Craig

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi all,

What about a radical alternative?

What if each non-reference part has an additional “tick” barline (numbered 
according to the reference context) whereever the barlines don’t line up?

Just a thought…
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[Graham King]

On Thu, 2015-11-19 at 13:57 +0100, Urs Liska wrote:


> > > > % ScholarLy options: see
> > > > 
> > > > https://github.com/openlilylib-archives/scholarly/wiki/Configuring-Annotations



> > > It looks like you ran into an undocumented change (although I
> > > can't remember). Please tell me where you did \colorAnnotations
> > > from.
> > 
> > Not sure I understand the question.  I did \colorAnnotations from
> > the top level of the .ly file for my score, as above.
> 
> 
> Sorry, my typo: I meant where you got the information from, see other
> messages between David and me.

Ah.  From the URL above.  My version of scholarly.annotate was certainly
downloaded with the rest of ScholarLy but I'm afraid I can't remember
when or whence.  Once this current score is out of the way, I must take
some time for a good cleanup and a refresh of ScholarLy from the new
location.

> 
> 
> > > 
> > > \setOption scholarly.colorize ##f
> > > 
> > > should give you what you want.
> > 
> > Brilliant! that works :)  It causes lilypond to exit with return
> > code 1 and the message
> > 
> > 2: error: unknown escaped string: `\scholarly'
> > \setOption 
> >\scholarly.colorize ##f
> > 
> > but I'm happy.
> > As ever: many thanks for your outstanding responsiveness.
> 
> 
> Well, I wrote
> scholarly.colorize
> not
> \scholarly.colorize


Doh!  (more haste, less speed on my part)

> 
> 
> > > 
> > > HTH
> > > Urs
> > > 
> > > > 
> > > > most grateful for any help
> > > > -- Graham 
> > > 
> > > 
> 
> 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[Urs Liska]

Am 19.11.2015 um 13:46 schrieb Graham King:
> On Thu, 2015-11-19 at 13:31 +0100, Urs Liska wrote:
>>
>>
>> Am 19.11.2015 um 13:01 schrieb Graham King:
>>
>>> Apologies for troubling you with this under-researched problem, but
>>> I've just hit it as a deadline looms.
>>>
>>> I'm trying to turn off the colouring of ScholarLy annotations,
>>> before final publication:
>>>
>>> \version "2.19.21"
>>>
>>> \include "openlilylib"
>>> \useLibrary ScholarLY
>>> \useModule scholarly.annotate
>>>
>>> #(display "ScholarLy loaded\n")
>>>
>>> % ScholarLy options: see
>>> 
>>> https://github.com/openlilylib-archives/scholarly/wiki/Configuring-Annotations
>>> \setOption scholarly.annotate.export-targets #'("plaintext" "latex")
>>> \colorAnnotations ##f % deactivate the coloring of the annotated
>>> items
>>> % \printAnnotations ##f % stop printing clickable messages to
>>> the console
>>> % (ScholarLy options end)
>>>
>>> and I get the following log message:
>>>
>>> \useModule utility.rhythmic-location
>>> 
>>> /Users/grahamk/Documents/lilypond/music/Carver_Missa_lhomme_arme/Carver_Lhomme_Arme_Agnus.ly:14:1:
>>> error: unknown escaped string: `\colorAnnotations'
>>>
>>> The annotations remain coloured.  What am I doing wrong?
>>
>> It looks like you ran into an undocumented change (although I can't
>> remember). Please tell me where you did \colorAnnotations from.
> Not sure I understand the question.  I did \colorAnnotations from the
> top level of the .ly file for my score, as above.

Sorry, my typo: I meant where you got the information from, see other
messages between David and me.

>>
>> \setOption scholarly.colorize ##f
>>
>> should give you what you want.
> Brilliant! that works :)  It causes lilypond to exit with return code
> 1 and the message
>
> 2: error: unknown escaped string: `\scholarly'
> \setOption
>\scholarly.colorize ##f
>
> but I'm happy.
> As ever: many thanks for your outstanding responsiveness.

Well, I wrote
scholarly.colorize
not
\scholarly.colorize

>>
>> HTH
>> Urs
>>>
>>> most grateful for any help
>>> -- Graham
>>

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[David Kastrup]

Graham King  writes:

> On Thu, 2015-11-19 at 13:31 +0100, Urs Liska wrote:
>
>> \setOption scholarly.colorize ##f
>> 
>> should give you what you want.
>
> Brilliant! that works :)  It causes lilypond to exit with return code 1
> and the message
>
> 2: error: unknown escaped string: `\scholarly'
> \setOption 
>\scholarly.colorize ##f
>
> but I'm happy.

LilyPond's error recovery for an unknown escaped string is to return the
string without preceding backslash.  It's probably rather rare that this
leads to useful results but you've hit the jackpot.

Still, it would make sense to remove that backslash.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[Graham King]

On Thu, 2015-11-19 at 13:31 +0100, Urs Liska wrote:

> 
> 
> 
> Am 19.11.2015 um 13:01 schrieb Graham King:
> 
> > 
> > Apologies for troubling you with this under-researched problem, but
> > I've just hit it as a deadline looms.
> > 
> > I'm trying to turn off the colouring of ScholarLy annotations,
> > before final publication:
> > 
> > 
> > \version "2.19.21"
> > 
> > \include "openlilylib"
> > \useLibrary ScholarLY
> > \useModule scholarly.annotate
> > 
> > #(display "ScholarLy loaded\n")
> > 
> > % ScholarLy options: see
> > 
> > https://github.com/openlilylib-archives/scholarly/wiki/Configuring-Annotations
> > \setOption scholarly.annotate.export-targets #'("plaintext"
> > "latex")
> > \colorAnnotations ##f % deactivate the coloring of the
> > annotated items
> > % \printAnnotations ##f % stop printing clickable messages
> > to the console
> > % (ScholarLy options end)
> > 
> > 
> > and I get the following log message:
> > 
> > 
> > \useModule utility.rhythmic-location
> > 
> > /Users/grahamk/Documents/lilypond/music/Carver_Missa_lhomme_arme/Carver_Lhomme_Arme_Agnus.ly:14:1:
> >  error: unknown escaped string: `\colorAnnotations'
> > 
> > 
> > The annotations remain coloured.  What am I doing wrong?
> 
> 
> It looks like you ran into an undocumented change (although I can't
> remember). Please tell me where you did \colorAnnotations from.

Not sure I understand the question.  I did \colorAnnotations from the
top level of the .ly file for my score, as above.

> 
> \setOption scholarly.colorize ##f
> 
> should give you what you want.

Brilliant! that works :)  It causes lilypond to exit with return code 1
and the message

2: error: unknown escaped string: `\scholarly'
\setOption 
   \scholarly.colorize ##f

but I'm happy.
As ever: many thanks for your outstanding responsiveness.

> 
> HTH
> Urs
> 
> > 
> > most grateful for any help
> > -- Graham 
> 
> 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[Urs Liska]

Am 19.11.2015 um 13:41 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 19.11.2015 um 13:01 schrieb Graham King:
>>> Apologies for troubling you with this under-researched problem, but
>>> I've just hit it as a deadline looms.
>>>
>>> I'm trying to turn off the colouring of ScholarLy annotations, before
>>> final publication:
> [...]
>
>>> % ScholarLy options: see
>>> 
>>> https://github.com/openlilylib-archives/scholarly/wiki/Configuring-Annotations
> [...]
>
>> It looks like you ran into an undocumented change (although I can't
>> remember). Please tell me where you did \colorAnnotations from.
> s/did/got/: See above.

I meant "did get" ;-)

Regarding the "outdatedness" of that information see also
https://github.com/openlilylib-archives/scholarly
>


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[David Kastrup]

Urs Liska  writes:

> Am 19.11.2015 um 13:01 schrieb Graham King:
>> Apologies for troubling you with this under-researched problem, but
>> I've just hit it as a deadline looms.
>>
>> I'm trying to turn off the colouring of ScholarLy annotations, before
>> final publication:

[...]

>> % ScholarLy options: see
>> 
>> https://github.com/openlilylib-archives/scholarly/wiki/Configuring-Annotations

[...]

> It looks like you ran into an undocumented change (although I can't
> remember). Please tell me where you did \colorAnnotations from.

s/did/got/: See above.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy: unknown escaped string: `\colorAnnotations'

[Urs Liska]

Am 19.11.2015 um 13:01 schrieb Graham King:
> Apologies for troubling you with this under-researched problem, but
> I've just hit it as a deadline looms.
>
> I'm trying to turn off the colouring of ScholarLy annotations, before
> final publication:
>
> \version "2.19.21"
>
> \include "openlilylib"
> \useLibrary ScholarLY
> \useModule scholarly.annotate
>
> #(display "ScholarLy loaded\n")
>
> % ScholarLy options: see
> 
> https://github.com/openlilylib-archives/scholarly/wiki/Configuring-Annotations
> \setOption scholarly.annotate.export-targets #'("plaintext" "latex")
> \colorAnnotations ##f % deactivate the coloring of the annotated items
> % \printAnnotations ##f % stop printing clickable messages to the
> console
> % (ScholarLy options end)
>
> and I get the following log message:
>
> \useModule utility.rhythmic-location
> 
> /Users/grahamk/Documents/lilypond/music/Carver_Missa_lhomme_arme/Carver_Lhomme_Arme_Agnus.ly:14:1:
> error: unknown escaped string: `\colorAnnotations'
>
> The annotations remain coloured.  What am I doing wrong?

It looks like you ran into an undocumented change (although I can't
remember). Please tell me where you did \colorAnnotations from.

\setOption scholarly.colorize ##f

should give you what you want.

HTH
Urs
>
> most grateful for any help
> -- Graham 

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy fails with \RemoveEmptyStaffContext

[David Kastrup]

Graham King  writes:

> This took a little while to nail down, but it seems that ScholarLy's
> annotation engine fails silently when \RemoveEmptyStaffContext is
> active.  Almost-minimal example attached.

>   \layout {
> %{ %Toggle this block comment to reveal problem:
> \context {
>   \RemoveEmptyStaffContext
> }
> %} 

What is that supposed to be?  I am not even sure what this does.  Maybe
we should check that case and flag an error: there is no context
specified to which this is supposed to apply.  You probably want
something like a

\Staff

before the \RemoveEmptyStaffContext.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy fails with \RemoveEmptyStaffContext

[Urs Liska]

Thank you for tracking that down, and sorry I didn't have time to reply
to your personal message.

Am 15.11.2015 um 12:15 schrieb Graham King:
> This took a little while to nail down, but it seems that ScholarLy's
> annotation engine fails silently when \RemoveEmptyStaffContext is
> active.  Almost-minimal example attached.
>

In a way it seems natural that this can interfere with an engraver like
the ones involved in the annotations. Unfortunately I'm at a loss as to
what that may mean and how to proceed.

> Is there anything I should be doing differently?

I don't think there's anything you could do better.

>
> And should I be filing ScholarLy issues here or on the openlilylib list?

There is no openLilyLib mailing list yet, and I don't think it makes
much sense to have one. I may do that if there should arise objections
about the respective discussions being off-topic here ...

So if you have questions you should post them on lilypond-user. However,
if you feel you are encountering a problem you can (should)
(additionally) open an issue at
https://github.com/openlilylib/snippets/issues

Best
Urs

>
> -- Graham
>
>
> ___
> 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: ScholarLy fails with \RemoveEmptyStaffContext

[Graham King]

On Mon, 2015-11-16 at 09:24 +0100, David Kastrup wrote:

> Graham King  writes:
> 
> > This took a little while to nail down, but it seems that ScholarLy's
> > annotation engine fails silently when \RemoveEmptyStaffContext is
> > active.  Almost-minimal example attached.
> 
> >   \layout {
> > %{ %Toggle this block comment to reveal problem:
> > \context {
> >   \RemoveEmptyStaffContext
> > }
> > %} 
> 
> What is that supposed to be?  I am not even sure what this does.  Maybe
> we should check that case and flag an error: there is no context
> specified to which this is supposed to apply.  You probably want
> something like a
> 
> \Staff
> 
> before the \RemoveEmptyStaffContext.

Apologies.  In my enthusiasm to boil this down to a minimal example,
I've created an oddball that just looks like Lilypond-abuse. Here it is
again with an extraneous staff restored.  
I don't think there is any problem with lilypond itself.  However,
either this user or Urs' ScholarLy annotation code has a
problem/limitation.
\version "2.19.21"

\include "openlilylib"
\useLibrary ScholarLY
\useModule scholarly.annotate

#(display "Scholarly loaded\n")

\setOption scholarly.annotate.export-targets #'("plaintext" "latex")

\score {
  \context ChoirStaff <<
\context Staff = staffI <<
  \set Staff.instrumentName = "S"
  \set Staff.shortInstrumentName = "S"
  \relative c'' {
\time 2/4
g4 g g g g
\musicalIssue \with {
  message = "last note, A. bar 3"
  context = "Some staff"
}
NoteHead
g
\break
R2*3
\break
g4 g g g g g
  }
>>
\context Staff = staffII <<
  \set Staff.instrumentName = "A"
  \set Staff.shortInstrumentName = "A"
  \relative c'' {
\time 2/4
\repeat unfold 18 c4
  }
>>
  >>

  \layout {
%%{ %Toggle this block comment to reveal problem:
\context {
  \RemoveEmptyStaffContext
}
%}
  }
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy fails with \RemoveEmptyStaffContext

[David Kastrup]

Graham King  writes:

> On Mon, 2015-11-16 at 09:24 +0100, David Kastrup wrote:
>
>> Graham King  writes:
>> 
>> > This took a little while to nail down, but it seems that ScholarLy's
>> > annotation engine fails silently when \RemoveEmptyStaffContext is
>> > active.  Almost-minimal example attached.
>> 
>> >   \layout {
>> > %{ %Toggle this block comment to reveal problem:
>> > \context {
>> >   \RemoveEmptyStaffContext
>> > }
>> > %} 
>> 
>> What is that supposed to be?  I am not even sure what this does.  Maybe
>> we should check that case and flag an error: there is no context
>> specified to which this is supposed to apply.  You probably want
>> something like a
>> 
>> \Staff
>> 
>> before the \RemoveEmptyStaffContext.
>> 
>
> thanks David, you've solved my problem (and probably saved Urs some work
> too).  Somehow I had missed that there is a new, better, way to remove
> empty staves.

Uh, actually it would appear that I got this wrong: I confused
\RemoveEmptyStaffContext (the old way of doing this which overwrites the
\Staff context definition with a fixed one) with \RemoveEmptyStaves (the
recommended way of doing this).

Maybe we should replace \RemoveEmptyStaffContext with a scheme function
referencing the current setting of \Staff.

And/or add a convert-ly rule to do that.  Either way is not as "backward
compatible" as the current code but I rather doubt that backward
compatibility is doing anybody a favor here.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy fails with \RemoveEmptyStaffContext

[Graham King]

On Mon, 2015-11-16 at 09:24 +0100, David Kastrup wrote:

> Graham King  writes:
> 
> > This took a little while to nail down, but it seems that ScholarLy's
> > annotation engine fails silently when \RemoveEmptyStaffContext is
> > active.  Almost-minimal example attached.
> 
> >   \layout {
> > %{ %Toggle this block comment to reveal problem:
> > \context {
> >   \RemoveEmptyStaffContext
> > }
> > %} 
> 
> What is that supposed to be?  I am not even sure what this does.  Maybe
> we should check that case and flag an error: there is no context
> specified to which this is supposed to apply.  You probably want
> something like a
> 
> \Staff
> 
> before the \RemoveEmptyStaffContext.
> 

thanks David, you've solved my problem (and probably saved Urs some work
too).  Somehow I had missed that there is a new, better, way to remove
empty staves.  With the new syntax the problem with ScholarLy goes away.
Thanks also to  Trevor Ba?a for his blog post at
http://lilypondbitsandpieces.blogspot.co.uk/2011/08/lilypond-remove-empty-staves.html
 .

Fixed example attached.

-- Graham
\version "2.19.21"

\include "openlilylib"
\useLibrary ScholarLY
\useModule scholarly.annotate

#(display "Scholarly loaded\n")

\setOption scholarly.annotate.export-targets #'("plaintext" "latex")

\score {
  \context ChoirStaff <<
\context Staff = staffI <<
  \set Staff.instrumentName = "S"
  \set Staff.shortInstrumentName = "S"
  \relative c'' {
\time 2/4
g4 g g g g
\musicalIssue \with {
  message = "last note, A. bar 3"
  context = "Some staff"
}
NoteHead
g
\break
R2*3
\break
g4 g g g g g
  }
>>
\context Staff = staffII <<
  \set Staff.instrumentName = "A"
  \set Staff.shortInstrumentName = "A"
  \relative c'' {
\time 2/4
\repeat unfold 18 c4
  }
>>
  >>

  \layout {
\context {
  \Staff \RemoveEmptyStaves
}
  }
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Thu, 2015-11-12 at 10:38 -0600, David Wright wrote:

> On Tue 10 Nov 2015 at 13:52:33 (+), Graham King wrote:
> > On Mon, 2015-11-09 at 21:53 -0600, David Wright wrote:
> > On Mon 09 Nov 2015 at 23:22:14 (+), Graham King wrote:
> > > On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote:
> > > On 11/09/2015 02:47 PM, Kieren MacMillan wrote:
> > > > The very first thing they said to me was, “Add measure numbers.”
> > > > That’s sufficient reason for me.  =)
> > > Good answer.
> > > In that case, I would pick one part, and force those measure 
> > numbers in
> > > as numeric rehearsal marks in the other parts.
> > > Otherwise, you’d need a translation guide...
> > > ~Chris
> > > I guess Gould has a point.  I've just realised that, under my system 
> > as I
> > > described it, a part could have the same bar number twice.  For 
> > example, in the
> > > attachment below, T has two bars "9".  But apart from an ill-chosen 
> > number (in
> > > this case), one could regard the "bar numbers" as "numeric rehearsal 
> > marks".
> > > Different mechanism, different formatting, same result.  In practice, 
> > for the
> > > sort of music I'm dealing with, the polymetric sections tend to be 
> > quite short
> > > so, for the most part, bar numbers are more helpful than rehearsal 
> > marks.
> > 
> > This is avoidable if each new bar is numbered with 1+(number of the
> > bar—looking across all the parts—that most recently finished). Not
> > something I could automate with my zero knowledge of scheme.
> > 
> > Very logical.
> > Advantages:
> > +1Might be amenable to automation.
> > +2Robust with respect to re-formatting.
> > +3Supports any variation of Staff.BarNumber.break-visibility (I think).
> > 
> > Disadvantages:
> > -1On a given line, bar numbers increase in strange and surprising ways,
> > giving potential for confusion.
> 
> That's unavoidable by any scheme. Where a player has a part that has
> many bars in one line (eg a slow-moving bass part where some other
> parts have many more notes), the player will see multiple jumps in
> their line, each where your "reference part" starts a new line in
> its score. These jumps could be forwards or backwards.

I see your point.  I'm dealing with a special case however, in which
there is just a vocal score (no separate parts).  Clearly, your scheme
is superior in the general case.

> 
> >  One cannot just count from the start of the
> > line and announce a bar number.
> 
> Oh, I don't think you can get away without labelling every bar in
> every part. We're just discussing what those labels will say.
> 
> > For that reason alone, I'm inclined to favour:
> > oCounting the bars of the top visible staff of the system, whilst
> > oAllowing discontinuity at the start of each line to accommodate other
> > parts that might have more bars in the previous line.
> 
> The "start of each line" will be different in each and every score:
> the full score, the vocal score, the choral score, and all the parts.
> *Their* discontinuities will be all over the place, with jumps
> backwards and forwards! Exciting stuff.
> 
> So I see further advantages than just those in your list:
> 
> +4 Bar numbers monotonically increase throughout every part.
> +5 Bar numbers are a defined and intrinsic property of the music,
>not an accident of one particular layout. In other words, the
>bar number of every bar is known *before* LP tries to calculate
>linebreaks and pagebreaks.
> 
> > But that's just a personal preference.  I wouldn't want to impose it on 
> > anyone
> > else!  (and I'm prepared to accept the need to fiddle with bar numbers 
> > manually
> > at a late stage in the editing process).
> 
> So what you're saying is (correct me if I'm wrong) you typeset the
> music *in it's final form*, then sit down with the printout and
> annotate the "reference part" bar numbers, then re-edit the source
> putting in all the \set Score.currentBarNumber commands for each and
> every line of the reference part.

not necessarily every line.  Different assumptions about the musical
material - see below.

> 
> Now comes the interesting bit: figuring out the bar numbers for all
> the other parts and forcing them to match the reference part.
> 
> And if a late correction has the effect of shifting a bar from one
> line to another in the reference part, you're scuppered.


Yes, all (mostly) correct, believe it or not!  For my purposes, that's
not a lot of work, since (i) the polymetric sections tend to be quite
short, (ii) the piece is never published other than in score form and,
(iii) re-working for corrections is rare (and if needed, a new set of
printouts can be run off).  I fully accept that this is a special case
of a much more difficult general problem to which your analysis applies.
I'm not trying to impose this 

Re: Scholarly footnotes

[Urs Liska]

Am 13. November 2015 13:29:30 MEZ, schrieb Graham King 
:
>On Thu, 2015-11-12 at 12:45 +0100, Urs Liska wrote:
>
>> 
>> Am 12.11.2015 um 09:09 schrieb Urs Liska:
>> > Having had a night over it I realized that there is an obvious
>first
>> > step towards b) and c) and that the infrastructure is already there
>for it!
>> > I will add support for writing out the raw Scheme object and simply
>> > integrate it as an additional export-target. I wouldn't mind if
>someone
>> > would give me a hint with regard to (de-)serializing a Scheme
>object to
>> > and from a file before I'll have the opportunity to look into it
>myself ;-)
>> >
>> > When that file is available I can then see at what point it's there
>so I
>> > can see if b) or c) or both are possible.
>> >
>> > Urs
>> >
>> 
>> Just for reference: I've added an issue and started work with an
>initial
>> commit:
>> https://github.com/openlilylib/openlilylib/issues/138
>> 
>
>Owing to  a technical problem (a glitch in the keyboard-seat
>interface at this end) I've only just seen the last three postings in
>this branch of the thread.  This looks very promising.  I might
>struggle
>a bit at first to get from Scheme to lilypond markup, but that's
>nothing
>compared to the heavy-lifting already done.

The problem is that so far the export isn't proper Scheme but a string 
representation that LilyPond won't even read in.

>
>-- Graham
>
>
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
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: Scholarly footnotes

[Simon Albrecht]

On 13.11.2015 13:29, Graham King wrote:

I might struggle a bit at first to get from Scheme to lilypond markup


In case you don’t know about that already: 
 
might help.


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Graham King]

On Thu, 2015-11-12 at 12:45 +0100, Urs Liska wrote:

> 
> Am 12.11.2015 um 09:09 schrieb Urs Liska:
> > Having had a night over it I realized that there is an obvious first
> > step towards b) and c) and that the infrastructure is already there for it!
> > I will add support for writing out the raw Scheme object and simply
> > integrate it as an additional export-target. I wouldn't mind if someone
> > would give me a hint with regard to (de-)serializing a Scheme object to
> > and from a file before I'll have the opportunity to look into it myself ;-)
> >
> > When that file is available I can then see at what point it's there so I
> > can see if b) or c) or both are possible.
> >
> > Urs
> >
> 
> Just for reference: I've added an issue and started work with an initial
> commit:
> https://github.com/openlilylib/openlilylib/issues/138
> 

Owing to  a technical problem (a glitch in the keyboard-seat
interface at this end) I've only just seen the last three postings in
this branch of the thread.  This looks very promising.  I might struggle
a bit at first to get from Scheme to lilypond markup, but that's nothing
compared to the heavy-lifting already done.

-- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[David Wright]

On Tue 10 Nov 2015 at 13:52:33 (+), Graham King wrote:
> On Mon, 2015-11-09 at 21:53 -0600, David Wright wrote:
> On Mon 09 Nov 2015 at 23:22:14 (+), Graham King wrote:
> > On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote:
> > On 11/09/2015 02:47 PM, Kieren MacMillan wrote:
> > > The very first thing they said to me was, “Add measure numbers.”
> > > That’s sufficient reason for me.  =)
> > Good answer.
> > In that case, I would pick one part, and force those measure 
> numbers in
> > as numeric rehearsal marks in the other parts.
> > Otherwise, you’d need a translation guide...
> > ~Chris
> > I guess Gould has a point.  I've just realised that, under my system as 
> I
> > described it, a part could have the same bar number twice.  For 
> example, in the
> > attachment below, T has two bars "9".  But apart from an ill-chosen 
> number (in
> > this case), one could regard the "bar numbers" as "numeric rehearsal 
> marks".
> > Different mechanism, different formatting, same result.  In practice, 
> for the
> > sort of music I'm dealing with, the polymetric sections tend to be 
> quite short
> > so, for the most part, bar numbers are more helpful than rehearsal 
> marks.
> 
> This is avoidable if each new bar is numbered with 1+(number of the
> bar—looking across all the parts—that most recently finished). Not
> something I could automate with my zero knowledge of scheme.
> 
> Very logical.
> Advantages:
> +1Might be amenable to automation.
> +2Robust with respect to re-formatting.
> +3Supports any variation of Staff.BarNumber.break-visibility (I think).
> 
> Disadvantages:
> -1On a given line, bar numbers increase in strange and surprising ways,
> giving potential for confusion.

That's unavoidable by any scheme. Where a player has a part that has
many bars in one line (eg a slow-moving bass part where some other
parts have many more notes), the player will see multiple jumps in
their line, each where your "reference part" starts a new line in
its score. These jumps could be forwards or backwards.

>  One cannot just count from the start of the
> line and announce a bar number.

Oh, I don't think you can get away without labelling every bar in
every part. We're just discussing what those labels will say.

> For that reason alone, I'm inclined to favour:
> oCounting the bars of the top visible staff of the system, whilst
> oAllowing discontinuity at the start of each line to accommodate other
> parts that might have more bars in the previous line.

The "start of each line" will be different in each and every score:
the full score, the vocal score, the choral score, and all the parts.
*Their* discontinuities will be all over the place, with jumps
backwards and forwards! Exciting stuff.

So I see further advantages than just those in your list:

+4 Bar numbers monotonically increase throughout every part.
+5 Bar numbers are a defined and intrinsic property of the music,
   not an accident of one particular layout. In other words, the
   bar number of every bar is known *before* LP tries to calculate
   linebreaks and pagebreaks.

> But that's just a personal preference.  I wouldn't want to impose it on anyone
> else!  (and I'm prepared to accept the need to fiddle with bar numbers 
> manually
> at a late stage in the editing process).

So what you're saying is (correct me if I'm wrong) you typeset the
music *in it's final form*, then sit down with the printout and
annotate the "reference part" bar numbers, then re-edit the source
putting in all the \set Score.currentBarNumber commands for each and
every line of the reference part.

Now comes the interesting bit: figuring out the bar numbers for all
the other parts and forcing them to match the reference part.

And if a late correction has the effect of shifting a bar from one
line to another in the reference part, you're scuppered.

Hm. I want LP to do the work for me, not the other way round.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Urs Liska]

Am 12.11.2015 um 09:09 schrieb Urs Liska:
> Having had a night over it I realized that there is an obvious first
> step towards b) and c) and that the infrastructure is already there for it!
> I will add support for writing out the raw Scheme object and simply
> integrate it as an additional export-target. I wouldn't mind if someone
> would give me a hint with regard to (de-)serializing a Scheme object to
> and from a file before I'll have the opportunity to look into it myself ;-)
>
> When that file is available I can then see at what point it's there so I
> can see if b) or c) or both are possible.
>
> Urs
>

Just for reference: I've added an issue and started work with an initial
commit:
https://github.com/openlilylib/openlilylib/issues/138


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Urs Liska]

Am 11.11.2015 um 19:16 schrieb Urs Liska:
> 
> 
> Am 10.11.2015 um 17:39 schrieb Urs Liska:
>>
>>
>> Am 10.11.2015 um 17:08 schrieb Graham King:
>>> ...  long snip ...
>>>
>>> I confess I'm a bit daunted by the LaTeX learning curve, and it is
>>> possible that I'm not uniquely inadequate in that respect.  So a
>>> Lilypond-only solution would be ideal for me, and would save others
>>> the prospect of learning yet-another-language.  
>>
>> OK, on the long run I will want to have both, but actually it doesn't
>> matter where to start ...
>>
>>> I'm brainstorming a bit here, but if, for example, ScholarLy could
>>> make its annotations available as a Scheme array for metadata and
>>> markup, the lilypond user could access that array in a \markup block
>>> after the end of the music.  Layout could then be left to the user,
>>> selecting just the desired elements of data.
>>>
>>> The array might look something like:
>>> (((author . "A.N.Other")
>>>   (bar . 2)
>>>   (beat . 1)
>>>   (text . "\markup { \note #"4" #1 } added")
>>>   ...)
>>> ((author . "F.Bloggs")
>>>   (bar . 5)
>>>   ...)
>>> ...))
>>
>> I haven't looked in the code right now, but I'm pretty sure there *is*
>> such a Scheme tree structure at some point. The question is if that is
>> available at the moment we'd need it.
>> While parsing the input annotations are built and added to an array,
>> and when parsing is finished they are processed, i.e. sorted,
>> (optionally) filtered and exported. I'm not sure if a reasonable
>> representation is already available when regular markup is used and
>> interpreted.
>>
>> One thing should definitely be possible: Writing that structure out to
>> a temporary file and read that in at a later moment. Maybe this would
>> allow to use the data only in another bookpart? But that's something
>> to be discussed with those people who know more about the process of
>> collecting elements of a book.
>>
> 
> Now I've looked into it *to some extent*, and it seems my assumption was
> quite appropriate.
> 
> 'annotate' works in two steps and has two separate engravers:
> \annotationCollector is (automatically) consisted to all the staff-like
> contexts. Whenever it comes across an annotation in the input it appends
> an object to a global 'annotations' list.
> 
> Later \annotationProcessor (which is consisted to the Score context)
> iterates over this list, applies filtering and sorting, and exports it
> to the desired targets.
> 
> It is possible to access the annotations list/array from within
> \annotationProcessor, and it is easy to create a command (like e.g.
> \printReport) that switches of a certain processing.
> 
> But when I try to access the 'annotations' object from LilyPond input
> (be it from a toplevel command before or after the score or whenever, or
> from within the music) this object seems to be empty.
> 
> So I assume that it's only possible to access the information from
> within the engraver and not from the user code.
> 
> This leaves two options, and I would like to get an opinion which of
> these is/are possible:
> 
> a)
> have that \annotationProcessor produce some markup in the current score,
> presumably (starting) on a new page at the end of the score or have it
> create a new bookpart consisting of such markup
> 
> b)
> write out the data to a temporary file (clearly possible) for another
> command. This would have to read in the data and produce the necessary
> markup. Would it be possible to place such a command in a new bookpart,
> i.e. have an engraver in one bookpart write out something to disk and
> sos me other function in a later bookpart read that in again?
> 
> c)
> as a last resort LilyPond could write the data to a temporary file and a
> second command could process that data from within *another* file that
> would have to be compiled separately.
> This would of course be quite hacky but still avoid having to use a
> second tool (LaTeX).
> 
> I'd be grateful for any opinions/suggestions/solutions.
> 
> Urs
> 

Having had a night over it I realized that there is an obvious first
step towards b) and c) and that the infrastructure is already there for it!
I will add support for writing out the raw Scheme object and simply
integrate it as an additional export-target. I wouldn't mind if someone
would give me a hint with regard to (de-)serializing a Scheme object to
and from a file before I'll have the opportunity to look into it myself ;-)

When that file is available I can then see at what point it's there so I
can see if b) or c) or both are possible.

Urs


-- 
Urs Liska
www.openlilylib.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Wed, 2015-11-11 at 18:44 +0100, Urs Liska wrote:

> 
> 
> 
> Am 11.11.2015 um 11:14 schrieb Graham King:
> 
> > 
> >  
> > 
> > > > > annotate "installs" itself in the Score context, and in polymetric
> > > > > scores the timing-translator has to be removed from that context.
> > > > > 
> > > > > So to approach the issue one would have to remove \annotationProcessor
> > > > > from the Score context and "consist" it in another context.
> > > > > 
> > > > > I don't know what would happen if it would be added to more than one
> > > > > context (I can't really imagine it would work).
> > > > > What would probably work *in principle* is adding that to the context
> > > > > Kieren would take as the "master" context.
> > > > 
> > > > This passeth my understanding.  
> > > 
> > > 
> > > Mine too :-) That's why I would like you to simply try it out ...
> > > 
> > > Best
> > > Urs
> > > 
> > > 
> > > > I'll play with contexts in the morning.  Thanks again. 
> > > > 
> > > > > I assume (can't test currently) that any annotation would then get the
> > > > > barnumber of the master context and the partial measure calculated 
> > > > > from
> > > > > there. Of course this wouldn't give very useful results but it would 
> > > > > be
> > > > > interesting to check out anyway ...
> > > > > 
> > > > > Good luck
> > > > > Urs
> > > > > 
> > > > > > I hope I'm making a valid test: Had a bit of trouble integrating
> > > > > > ScholarLy with a short test score, so I just plugged the \include
> > > > > > statements and a \criticalRemark stanza into the
> > > > > > Isaac_Confessoribus_Prosa2.ly (which is full of polyrhythms).  Will 
> > > > > > pick
> > > > > > up again late tonight or tomorrow, to check that \scaleDurations is 
> > > > > > not
> > > > > > messing things up.  Must dash now.
> > > > > >>
> > > > > >> Urs
> > > > > > 
> > 
> > OK, I think I have a reasonable test case (attached).  Toggling the
> > block comment at lines 66 & 79 shows the effect of moving
> > \annotationProcessor between the Score and Staff contexts.
> > Alas, in Staff context, it still gives "Sorry, rhythmic position
> > could not be determined." 
> 
> 
> OK, I looked into it a little bit (this actually *is* a good test
> case), and I think we're in a kind of dead end. At least I don't see a
> way out or any use investigating further without a very clear idea
> what we eventually want to achieve. Sorry.

Alas.  Many thanks for your help and support anyway.

I too have spent part of today delving into both the default
bar-numbering mechanism and the Measure_counter_engraver, but both seem
to be built on the same foundation, which appears not to allow for the
case where the Default_bar_line_engraver has been moved into the Staff
context.  But I might be a bit hard-of-thinking and hence wrong.

To the general audience on the list:
In case anyone can breathe life into the issue at some future date, my
objective (perhaps refined and stated too late to be presently helpful)
is: 

"to enable ScholarLy to report annotations to a polyrhythmic score in
such a way that the position in the score, to which each annotation
refers, can be clearly, concisely, and unambiguously stated (in the
endnotes). "

To that end, I have assumed that bar-numbering for polyrhythmic music is
required, even at the expense of both a non-standard approach and the
possible need for manual intervention at a late stage of score
preparation.  I believe, in any case, that bar numbers are generally
helpful to performers, at least among those with whom I work.  At risk
of turning this paragraph into a manifesto, let's add: It is true that
Renaissance music had no regular barlines, and indeed I sing it, with
friends, from facsimile editions in which we have to rely on the signum
congruentiae if everything falls apart.  However, in modern times most
singers require modern notation, and tackle a far larger repertoire of
polyphony on (arguably) less rehearsal than our fifteenth- and
sixteenth-century forebears.  So we need all the navigational help we
can get.  As for the polyrhythmic modern editions that cause the present
difficulty: part of the point is to help preserve the closest possible
link to the original mensuration and proportion, and thereby to mitigate
the inappropriate rhythmic straightjacket of the modern barlines.

So, for the time being, I'll continue to add ScholarLy annotations to
the source, against the day when the software might be able to process
them.  But I'll take the log output, add a manually-derived bar number,
and publish the result in a manually-maintained \markup block.

best regards
-- Graham

> 
> The "error" message is produced when formatting an annotation for
> export, and actually is a workaround for a situation that would
> otherwise crash annotate: The "rhythmic-location" that is present in
> the annotation pretends to be (0 0/0). From my source comments this
> seems to be a "workaround for a problem that sometimes the paperColumn
> gets lost along th

Re: Scholarly footnotes

[Urs Liska]

Am 10.11.2015 um 17:39 schrieb Urs Liska:
>
>
> Am 10.11.2015 um 17:08 schrieb Graham King:
>> ...  long snip ...
>>
>> I confess I'm a bit daunted by the LaTeX learning curve, and it is
>> possible that I'm not uniquely inadequate in that respect.  So a
>> Lilypond-only solution would be ideal for me, and would save others
>> the prospect of learning yet-another-language.  
>
> OK, on the long run I will want to have both, but actually it doesn't
> matter where to start ...
>
>> I'm brainstorming a bit here, but if, for example, ScholarLy could
>> make its annotations available as a Scheme array for metadata and
>> markup, the lilypond user could access that array in a \markup block
>> after the end of the music.  Layout could then be left to the user,
>> selecting just the desired elements of data.
>>
>> The array might look something like:
>> (((author . "A.N.Other")
>>   (bar . 2)
>>   (beat . 1)
>>   (text . "\markup { \note #"4" #1 } added")
>>   ...)
>> ((author . "F.Bloggs")
>>   (bar . 5)
>>   ...)
>> ...))
>
> I haven't looked in the code right now, but I'm pretty sure there *is*
> such a Scheme tree structure at some point. The question is if that is
> available at the moment we'd need it.
> While parsing the input annotations are built and added to an array,
> and when parsing is finished they are processed, i.e. sorted,
> (optionally) filtered and exported. I'm not sure if a reasonable
> representation is already available when regular markup is used and
> interpreted.
>
> One thing should definitely be possible: Writing that structure out to
> a temporary file and read that in at a later moment. Maybe this would
> allow to use the data only in another bookpart? But that's something
> to be discussed with those people who know more about the process of
> collecting elements of a book.
>

Now I've looked into it *to some extent*, and it seems my assumption was
quite appropriate.

'annotate' works in two steps and has two separate engravers:
\annotationCollector is (automatically) consisted to all the staff-like
contexts. Whenever it comes across an annotation in the input it appends
an object to a global 'annotations' list.

Later \annotationProcessor (which is consisted to the Score context)
iterates over this list, applies filtering and sorting, and exports it
to the desired targets.

It is possible to access the annotations list/array from within
\annotationProcessor, and it is easy to create a command (like e.g.
\printReport) that switches of a certain processing.

But when I try to access the 'annotations' object from LilyPond input
(be it from a toplevel command before or after the score or whenever, or
from within the music) this object seems to be empty.

So I assume that it's only possible to access the information from
within the engraver and not from the user code.

This leaves two options, and I would like to get an opinion which of
these is/are possible:

a)
have that \annotationProcessor produce some markup in the current score,
presumably (starting) on a new page at the end of the score or have it
create a new bookpart consisting of such markup

b)
write out the data to a temporary file (clearly possible) for another
command. This would have to read in the data and produce the necessary
markup. Would it be possible to place such a command in a new bookpart,
i.e. have an engraver in one bookpart write out something to disk and
sos me other function in a later bookpart read that in again?

c)
as a last resort LilyPond could write the data to a temporary file and a
second command could process that data from within *another* file that
would have to be compiled separately.
This would of course be quite hacky but still avoid having to use a
second tool (LaTeX).

I'd be grateful for any opinions/suggestions/solutions.

Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Urs Liska]

Am 11.11.2015 um 11:14 schrieb Graham King:
> 
 annotate "installs" itself in the Score context, and in polymetric
 scores the timing-translator has to be removed from that context.

 So to approach the issue one would have to remove \annotationProcessor
 from the Score context and "consist" it in another context.

 I don't know what would happen if it would be added to more than one
 context (I can't really imagine it would work).
 What would probably work *in principle* is adding that to the context
 Kieren would take as the "master" context.
>>> This passeth my understanding. 
>>
>> Mine too :-) That's why I would like you to simply try it out ...
>>
>> Best
>> Urs
>>
>>> I'll play with contexts in the morning.  Thanks again.
 I assume (can't test currently) that any annotation would then get the
 barnumber of the master context and the partial measure calculated from
 there. Of course this wouldn't give very useful results but it would be
 interesting to check out anyway ...

 Good luck
 Urs

 > I hope I'm making a valid test: Had a bit of trouble integrating
 > ScholarLy with a short test score, so I just plugged the \include
 > statements and a \criticalRemark stanza into the
 > Isaac_Confessoribus_Prosa2.ly (which is full of polyrhythms).
 Will pick
 > up again late tonight or tomorrow, to check that \scaleDurations
 is not
 > messing things up. Must dash now.
 >>
 >> Urs
 >
> OK, I think I have a reasonable test case (attached).  Toggling the
> block comment at lines 66 & 79 shows the effect of moving
> \annotationProcessor between the Score and Staff contexts.
> Alas, in Staff context, it still gives "Sorry, rhythmic position could
> not be determined."

OK, I looked into it a little bit (this actually *is* a good test case),
and I think we're in a kind of dead end. At least I don't see a way out
or any use investigating further without a very clear idea what we
eventually want to achieve. Sorry.

The "error" message is produced when formatting an annotation for
export, and actually is a workaround for a situation that would
otherwise crash annotate: The "rhythmic-location" that is present in the
annotation pretends to be (0 0/0). From my source comments this seems to
be a "workaround for a problem that sometimes the paperColumn gets lost
along the way" - and I must say that I'm completely at a loss here. And
as we don't really know what we're after I don't think it makes sense to
really dive into this.

Except if David Nalesnik (who has written major parts of this) would
take on the challenge. If you do, David, I'll give you the pointers
where the stuff is sitting.

Best
Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Wed, 2015-11-11 at 09:18 +0100, Urs Liska wrote:

> 
> 
> 
> Am 11.11.2015 um 01:32 schrieb Graham King:
> 
> > 
> > On Tue, 2015-11-10 at 22:50 +0100, Urs Liska wrote: 
> > 
> > > Am 10.11.2015 um 18:06 schrieb Graham King:
> > > > On Tue, 2015-11-10 at 10:09 +0100, Urs Liska wrote:



> > > >> I'm not so sure that it will be possible to implement a solution that
> > > >> really works automatically and is at the same time sufficiently
> > > >> general. But you'd be in any case to create a manual solution, if
> > > >> that's a viable approach given your material (that is: how many of
> > > >> these annotations do you expect, will the numbering be stable or will
> > > >> you have to expect any changes after the fact?)
> > > 
> > > > Very happy to intervene manually in bar numbering.  The remainder of
> > > > this thread is opening my eyes to the difficulty of automating that.
> > > 
> > > Just to avoid misunderstandings: What I am thinking about is an approach
> > > where you add a custom property passing a barnumber manually to the
> > > annotation. I don't think we'll be able to manually modify LilyPond's
> > > idea of barnumbers.
> > 
> > Thanks for the clarification.  I don't think it's a problem so long
> > as two aspects of the workflow are covered:
> > 1: during the preparation of the score, we'll need to be able to
> > capture the issues and display them somehow, and relate each issue
> > to its place in the score.  This does not need barnumbers as we
> > still have source code (and maybe an IDE).  Almost certainly not a
> > problem.  
> 
> 
> The annotations do have their connection to the originating objects,
> regardless of being able to determine a proper musical position. The
> messages printed to the console are linked to the input position, so
> clicking on a message will move the cursor to the annotation, and the
> objects are colored in the score so you have the same navigation
> available through point-and-click.
> 
> If you want to have something readable available I would suggest the
> following:
> (temporarily) move the \annotationProcessor from the Score to another
> context. Choose the one that you consider the "master" context (as per
> Kieren's concept). Then the annotations *should* (not tested yet) get
> the master context's barnumber and a partial measure starting from
> that context's last barline.
> 
> 
> > 2: Bar numbers need to crystallise only at the publication stage. 
> > 
> > > >> We would surely be able to taylor a solution using either a custom
> > > >> annotation type or a custom annotation property.
> > 
> > Now I get it.  The human being at the keyboard tells ScholarLy the
> > bar number.  I'm happy with that.  I might add a git hook to flash
> > at me a message: "Now go back and adjust the bar numbers in the
> > annotations!" :-)  Seriously: It will very rarely be an issue.
> 
> 
> Well, actually I would then do that as one single step towards the end
> of the edition process, when you're sufficiently sure that neither the
> music nor your bar numbering scheme will change anymore.
> It is a compromise, but so far I don't see a solution that could be
> completely automated (due to the conceptual difficulties, not the
> implementation).
> 
> 
> > > >>
> > > >> As a start you could try out and tell us what LilyPond/ScholarLY do by
> > > >> default if used in polymetric scores. I *assume* that LilyPond
> > > >> maintains individual bar numberings for each context
> > > 
> > > > Yes, that appears to be the case.
> > > 
> > > >> and that ScholarLY will just use the "local" barnumbers, without even
> > > >> knowing there's an issue. But it would be nice if you could verify 
> > > >> that.
> > > 
> > > > Scholarly gives the message: "Sorry, rhythmic position could not be
> > > > determined."
> > > 
> > > OK, I see why this happens 



> > > annotate "installs" itself in the Score context, and in polymetric
> > > scores the timing-translator has to be removed from that context.
> > > 
> > > So to approach the issue one would have to remove \annotationProcessor
> > > from the Score context and "consist" it in another context.
> > > 
> > > I don't know what would happen if it would be added to more than one
> > > context (I can't really imagine it would work).
> > > What would probably work *in principle* is adding that to the context
> > > Kieren would take as the "master" context.
> > 
> > This passeth my understanding.  
> 
> 
> Mine too :-) That's why I would like you to simply try it out ...
> 
> Best
> Urs
> 
> 
> > I'll play with contexts in the morning.  Thanks again. 
> > 
> > > I assume (can't test currently) that any annotation would then get the
> > > barnumber of the master context and the partial measure calculated from
> > > there. Of course this wouldn't give very useful results but it would be
> > > interesting to check out anyway ...
> > > 
> > > Good luck
> > > Urs
> > > 
> > > > I hope I'm making a valid test: Had a bit of trouble integrating
> > > > Sch

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Urs Liska]

Am 11.11.2015 um 01:32 schrieb Graham King:
> On Tue, 2015-11-10 at 22:50 +0100, Urs Liska wrote:
>> Am 10.11.2015 um 18:06 schrieb Graham King:
>> > On Tue, 2015-11-10 at 10:09 +0100, Urs Liska wrote:
>> >>
>> >>
>> >> Am 09.11.2015 um 17:34 schrieb Graham King:
>> >>
>> >>> (This note describes an issue arising from the separate thread,
>> >>> "Scholarly footnotes" [1])
>> >>>
>> >>> I would like to use Urs' annotate.ily[2] to add some footnotes to an
>> >>> edition of sixteenth-century polyphony. But, before investing too
>> >>> much time, I need to check whether there is now a way for it to cope
>> >>> with polymetric music[3].
>> >>
>> >> As the discussion in this thread clearly shows this is firstly a
>> >> conceptual problem. Only if it is clear what you want to achieve we
>> >> can even start thinking about a solution implementation-wise.
>> >>
>> >> I'm not so sure that it will be possible to implement a solution that
>> >> really works automatically and is at the same time sufficiently
>> >> general. But you'd be in any case to create a manual solution, if
>> >> that's a viable approach given your material (that is: how many of
>> >> these annotations do you expect, will the numbering be stable or will
>> >> you have to expect any changes after the fact?)
>>
>> > Very happy to intervene manually in bar numbering. The remainder of
>> > this thread is opening my eyes to the difficulty of automating that.
>>
>> Just to avoid misunderstandings: What I am thinking about is an approach
>> where you add a custom property passing a barnumber manually to the
>> annotation. I don't think we'll be able to manually modify LilyPond's
>> idea of barnumbers.
> Thanks for the clarification.  I don't think it's a problem so long as
> two aspects of the workflow are covered:
> 1: during the preparation of the score, we'll need to be able to
> capture the issues and display them somehow, and relate each issue to
> its place in the score.  This does not need barnumbers as we still
> have source code (and maybe an IDE).  Almost certainly not a problem.  

The annotations do have their connection to the originating objects,
regardless of being able to determine a proper musical position. The
messages printed to the console are linked to the input position, so
clicking on a message will move the cursor to the annotation, and the
objects are colored in the score so you have the same navigation
available through point-and-click.

If you want to have something readable available I would suggest the
following:
(temporarily) move the \annotationProcessor from the Score to another
context. Choose the one that you consider the "master" context (as per
Kieren's concept). Then the annotations *should* (not tested yet) get
the master context's barnumber and a partial measure starting from that
context's last barline.

> 2: Bar numbers need to crystallise only at the publication stage.
>> >> We would surely be able to taylor a solution using either a custom
>> >> annotation type or a custom annotation property.
> Now I get it.  The human being at the keyboard tells ScholarLy the bar
> number.  I'm happy with that.  I might add a git hook to flash at me a
> message: "Now go back and adjust the bar numbers in the annotations!"
> :-)  Seriously: It will very rarely be an issue.

Well, actually I would then do that as one single step towards the end
of the edition process, when you're sufficiently sure that neither the
music nor your bar numbering scheme will change anymore.
It is a compromise, but so far I don't see a solution that could be
completely automated (due to the conceptual difficulties, not the
implementation).

>> >>
>> >> As a start you could try out and tell us what LilyPond/ScholarLY do by
>> >> default if used in polymetric scores. I *assume* that LilyPond
>> >> maintains individual bar numberings for each context
>>
>> > Yes, that appears to be the case.
>>
>> >> and that ScholarLY will just use the "local" barnumbers, without even
>> >> knowing there's an issue. But it would be nice if you could verify
>> that.
>>
>> > Scholarly gives the message: "Sorry, rhythmic position could not be
>> > determined."
>>
>> OK, I see why this happens (did I ever say that it is cool that I can
>> inspect openLilyLib code on Github using my phone?).
> Sheesh Urs! I know you're bright, but I've just had this image of your
> whipping out the phone in a few bars rest, with the thought "I've just
> got time to fix the earthling's problem..."  :-)
>> annotate "installs" itself in the Score context, and in polymetric
>> scores the timing-translator has to be removed from that context.
>>
>> So to approach the issue one would have to remove \annotationProcessor
>> from the Score context and "consist" it in another context.
>>
>> I don't know what would happen if it would be added to more than one
>> context (I can't really imagine it would work).
>> What would probably work *in principle* is adding that to the context
>> Kieren would ta

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Tue, 2015-11-10 at 22:50 +0100, Urs Liska wrote:

> Am 10.11.2015 um 18:06 schrieb Graham King:
> > On Tue, 2015-11-10 at 10:09 +0100, Urs Liska wrote:
> >>
> >>
> >> Am 09.11.2015 um 17:34 schrieb Graham King:
> >>
> >>> (This note describes an issue arising from the separate thread,
> >>> "Scholarly footnotes" [1])
> >>>
> >>> I would like to use Urs' annotate.ily[2] to add some footnotes to an
> >>> edition of sixteenth-century polyphony.  But, before investing too
> >>> much time, I need to check whether there is now a way for it to cope
> >>> with polymetric music[3]. 
> >>
> >> As the discussion in this thread clearly shows this is firstly a
> >> conceptual problem. Only if it is clear what you want to achieve we
> >> can even start thinking about a solution implementation-wise.
> >>
> >> I'm not so sure that it will be possible to implement a solution that
> >> really works automatically and is at the same time sufficiently
> >> general. But you'd be in any case to create a manual solution, if
> >> that's a viable approach given your material (that is: how many of
> >> these annotations do you expect, will the numbering be stable or will
> >> you have to expect any changes after the fact?)
> 
> > Very happy to intervene manually in bar numbering.  The remainder of
> > this thread is opening my eyes to the difficulty of automating that.
> 
> Just to avoid misunderstandings: What I am thinking about is an approach
> where you add a custom property passing a barnumber manually to the
> annotation. I don't think we'll be able to manually modify LilyPond's
> idea of barnumbers.

Thanks for the clarification.  I don't think it's a problem so long as
two aspects of the workflow are covered:
1: during the preparation of the score, we'll need to be able to capture
the issues and display them somehow, and relate each issue to its place
in the score.  This does not need barnumbers as we still have source
code (and maybe an IDE).  Almost certainly not a problem.  2: Bar
numbers need to crystallise only at the publication stage.

> 
> >> We would surely be able to taylor a solution using either a custom
> >> annotation type or a custom annotation property.

Now I get it.  The human being at the keyboard tells ScholarLy the bar
number.  I'm happy with that.  I might add a git hook to flash at me a
message: "Now go back and adjust the bar numbers in the
annotations!" :-)  Seriously: It will very rarely be an issue.

> >>
> >> As a start you could try out and tell us what LilyPond/ScholarLY do by
> >> default if used in polymetric scores. I *assume* that LilyPond
> >> maintains individual bar numberings for each context
> 
> > Yes, that appears to be the case.
> 
> >> and that ScholarLY will just use the "local" barnumbers, without even
> >> knowing there's an issue. But it would be nice if you could verify that.
> 
> > Scholarly gives the message: "Sorry, rhythmic position could not be
> > determined."
> 
> OK, I see why this happens (did I ever say that it is cool that I can
> inspect openLilyLib code on Github using my phone?).

Sheesh Urs! I know you're bright, but I've just had this image of your
whipping out the phone in a few bars rest, with the thought "I've just
got time to fix the earthling's problem..."  :-)

> annotate "installs" itself in the Score context, and in polymetric
> scores the timing-translator has to be removed from that context.
> 
> So to approach the issue one would have to remove \annotationProcessor
> from the Score context and "consist" it in another context.
> 
> I don't know what would happen if it would be added to more than one
> context (I can't really imagine it would work).
> What would probably work *in principle* is adding that to the context
> Kieren would take as the "master" context.

This passeth my understanding.  I'll play with contexts in the morning.
Thanks again.

> I assume (can't test currently) that any annotation would then get the
> barnumber of the master context and the partial measure calculated from
> there. Of course this wouldn't give very useful results but it would be
> interesting to check out anyway ...
> 
> Good luck
> Urs
> 
> > I hope I'm making a valid test: Had a bit of trouble integrating
> > ScholarLy with a short test score, so I just plugged the \include
> > statements and a \criticalRemark stanza into the
> > Isaac_Confessoribus_Prosa2.ly (which is full of polyrhythms).  Will pick
> > up again late tonight or tomorrow, to check that \scaleDurations is not
> > messing things up.  Must dash now.
> >>
> >> Urs
> > 
> 
> 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Urs Liska]

Am 10.11.2015 um 18:06 schrieb Graham King:
> On Tue, 2015-11-10 at 10:09 +0100, Urs Liska wrote:
>>
>>
>> Am 09.11.2015 um 17:34 schrieb Graham King:
>>
>>> (This note describes an issue arising from the separate thread,
>>> "Scholarly footnotes" [1])
>>>
>>> I would like to use Urs' annotate.ily[2] to add some footnotes to an
>>> edition of sixteenth-century polyphony.  But, before investing too
>>> much time, I need to check whether there is now a way for it to cope
>>> with polymetric music[3]. 
>>
>> As the discussion in this thread clearly shows this is firstly a
>> conceptual problem. Only if it is clear what you want to achieve we
>> can even start thinking about a solution implementation-wise.
>>
>> I'm not so sure that it will be possible to implement a solution that
>> really works automatically and is at the same time sufficiently
>> general. But you'd be in any case to create a manual solution, if
>> that's a viable approach given your material (that is: how many of
>> these annotations do you expect, will the numbering be stable or will
>> you have to expect any changes after the fact?)

> Very happy to intervene manually in bar numbering.  The remainder of
> this thread is opening my eyes to the difficulty of automating that.

Just to avoid misunderstandings: What I am thinking about is an approach
where you add a custom property passing a barnumber manually to the
annotation. I don't think we'll be able to manually modify LilyPond's
idea of barnumbers.

>> We would surely be able to taylor a solution using either a custom
>> annotation type or a custom annotation property.
>>
>> As a start you could try out and tell us what LilyPond/ScholarLY do by
>> default if used in polymetric scores. I *assume* that LilyPond
>> maintains individual bar numberings for each context

> Yes, that appears to be the case.

>> and that ScholarLY will just use the "local" barnumbers, without even
>> knowing there's an issue. But it would be nice if you could verify that.

> Scholarly gives the message: "Sorry, rhythmic position could not be
> determined."

OK, I see why this happens (did I ever say that it is cool that I can
inspect openLilyLib code on Github using my phone?).
annotate "installs" itself in the Score context, and in polymetric
scores the timing-translator has to be removed from that context.

So to approach the issue one would have to remove \annotationProcessor
from the Score context and "consist" it in another context.

I don't know what would happen if it would be added to more than one
context (I can't really imagine it would work).
What would probably work *in principle* is adding that to the context
Kieren would take as the "master" context.
I assume (can't test currently) that any annotation would then get the
barnumber of the master context and the partial measure calculated from
there. Of course this wouldn't give very useful results but it would be
interesting to check out anyway ...

Good luck
Urs

> I hope I'm making a valid test: Had a bit of trouble integrating
> ScholarLy with a short test score, so I just plugged the \include
> statements and a \criticalRemark stanza into the
> Isaac_Confessoribus_Prosa2.ly (which is full of polyrhythms).  Will pick
> up again late tonight or tomorrow, to check that \scaleDurations is not
> messing things up.  Must dash now.
>>
>> 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
> 


-- 
Urs Liska
www.openlilylib.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Tue, 2015-11-10 at 10:09 +0100, Urs Liska wrote:

> 
> 
> 
> Am 09.11.2015 um 17:34 schrieb Graham King:
> 
> > 
> > (This note describes an issue arising from the separate thread,
> > "Scholarly footnotes" [1])
> > 
> > I would like to use Urs' annotate.ily[2] to add some footnotes to an
> > edition of sixteenth-century polyphony.  But, before investing too
> > much time, I need to check whether there is now a way for it to cope
> > with polymetric music[3].  
> 
> 
> As the discussion in this thread clearly shows this is firstly a
> conceptual problem. Only if it is clear what you want to achieve we
> can even start thinking about a solution implementation-wise.
> 
> I'm not so sure that it will be possible to implement a solution that
> really works automatically and is at the same time sufficiently
> general. But you'd be in any case to create a manual solution, if
> that's a viable approach given your material (that is: how many of
> these annotations do you expect, will the numbering be stable or will
> you have to expect any changes after the fact?)

Very happy to intervene manually in bar numbering.  The remainder of
this thread is opening my eyes to the difficulty of automating that.

> We would surely be able to taylor a solution using either a custom
> annotation type or a custom annotation property.
> 
> As a start you could try out and tell us what LilyPond/ScholarLY do by
> default if used in polymetric scores. I *assume* that LilyPond
> maintains individual bar numberings for each context

Yes, that appears to be the case.

>  and that ScholarLY will just use the "local" barnumbers, without even
> knowing there's an issue. But it would be nice if you could verify
> that.

Scholarly gives the message: "Sorry, rhythmic position could not be
determined."
I hope I'm making a valid test: Had a bit of trouble integrating
ScholarLy with a short test score, so I just plugged the \include
statements and a \criticalRemark stanza into the
Isaac_Confessoribus_Prosa2.ly (which is full of polyrhythms).  Will pick
up again late tonight or tomorrow, to check that \scaleDurations is not
messing things up.  Must dash now.

> 
> 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: Scholarly footnotes

[Urs Liska]

Am 10.11.2015 um 17:08 schrieb Graham King:
> ...  long snip ...
>
> I confess I'm a bit daunted by the LaTeX learning curve, and it is
> possible that I'm not uniquely inadequate in that respect.  So a
> Lilypond-only solution would be ideal for me, and would save others
> the prospect of learning yet-another-language.  

OK, on the long run I will want to have both, but actually it doesn't
matter where to start ...

> I'm brainstorming a bit here, but if, for example, ScholarLy could
> make its annotations available as a Scheme array for metadata and
> markup, the lilypond user could access that array in a \markup block
> after the end of the music.  Layout could then be left to the user,
> selecting just the desired elements of data.
>
> The array might look something like:
> (((author . "A.N.Other")
>   (bar . 2)
>   (beat . 1)
>   (text . "\markup { \note #"4" #1 } added")
>   ...)
> ((author . "F.Bloggs")
>   (bar . 5)
>   ...)
> ...))

I haven't looked in the code right now, but I'm pretty sure there *is*
such a Scheme tree structure at some point. The question is if that is
available at the moment we'd need it.
While parsing the input annotations are built and added to an array, and
when parsing is finished they are processed, i.e. sorted, (optionally)
filtered and exported. I'm not sure if a reasonable representation is
already available when regular markup is used and interpreted.

One thing should definitely be possible: Writing that structure out to a
temporary file and read that in at a later moment. Maybe this would
allow to use the data only in another bookpart? But that's something to
be discussed with those people who know more about the process of
collecting elements of a book.

With regard to layout I think at least a basic implementation should be
available with commands like

\criticalreport
(to print out a full default report)

\criticalRemark
(to print a single remark)

etc.

We would then have to discuss whether it's better (or feasible) to make
that stuff configurable or if we should simply leave it to the end user
to take them as a model for her own solutions.

Best
Urs

>
>
> I haven't looked in detail yet but, with luck, there will be a good
> correspondence between the lilyglyphs used in Latex and the notation
> elements available to \markup (Notation Reference, section 1.8.2)
>
> Maybe some default layout could be added later, for those dismayed
> equally by LaTeX and Scheme...
>>
>> I think 2) and 4) are principally equally appropriate, but to choose
>> one out of them we'd need a better idea of the concrete project (but
>> I can't ask specific questions about that).
>>
>> Both approaches would require additional development, either the
>> LaTeX code to handle the critical report or the same for LilyPond.
>>
>> I assume that making LaTeX do what you want is the lower hanging
>> fruit. And if development of a proper (i.e. generic) LaTeX package
>> turns out to be complicated or takes too long it will always be
>> possible to create a project-specific solution without serious
>> problems. With the LilyPond-only approach I wouldn't make a guarantee
>> yet if it's really achievable, although I assume so.
>>
>> On the other hand this will add a second tool and thus an additional
>> layer of complexity that may not be needed if you could achieve your
>> goal directly from within a LilyPond score.
>>
>> Then again, getting familiar with LaTeX may be a good investment anyway.
>>
>> Regarding some abstract "public interest" I'd say 2) and 4) are
>> similarly important and equally missing.
>>
>> HTH
>> Urs
>>
>>>
>>>  
>>> [1] From the Snippets Repository: http://lsr.di.unimi.it/LSR/Item?id=368
>>> [2] http://lilypondblog.org/2015/01/introducing-scholarly/
>>> [3] lilypond-user list, November 2015: "ScholarLy and polymetric
>>> music? (bar numbering, \RemoveEmptyStaffContext)"
>>> [4]
>>> http://www.lilypond.org/doc/v2.19/Documentation/usage/lilypond_002dbook
>>> [5]
>>> http://lilypondblog.org/2013/07/creating-songbooks-with-lilypond-and-latex/
>>> [6] http://openlilylib.org/musicexamples/index.html
>

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Graham King]

Hi Urs,
first, I'm deeply grateful for your time and thoughtful insights.

Further comments interjected, below...

all the best
-- Graham

On Tue, 2015-11-10 at 10:43 +0100, Urs Liska wrote:

> Hi Graham,
> 
> now I'll try to go into that somewhat more detailed.
> 
> 
> Am 09.11.2015 um 17:33 schrieb Graham King:
> 
> > 
> > I'm preparing an edition of sixteenth-century polyphony, using the
> > book-titling template[1].  The edition would benefit from some
> > footnotes/endnotes (the sort that say things like: "contratenor 1,
> > bar 99: semiminim A missing in MS").  How best to achieve this,
> > while preserving the "book-titling" appearance?  
> 
> 
> I've only looked at the description page of the book-titling template,
> but I don't see that it would affect any of this.
> With regard to footnote/endnotes you should first decide about what
> you want. Footnotes are something completely different from endnotes,
> both conceptually *and* technically.
> 
> As two rules of thumb I'd point out that
>   * numerous footnotes would seem quite distracting, so if you
> expect to have many annotations you'd put them in an appendix
>   * footnotes on the page itself have a quite high "visibility".
> 
> A common approach is to use endnotes for the commentary in general and
> use footnotes to indicate the really important comments (i.e. those
> you really want the performer to notice). Sometimes you even have
> footnotes that only point to the commentary at the end.

All fully agreed.  I'd be very happy with just endnotes.


> > 
> > Urs' marvellous work on ScholarLy[2] appears ideal, but outputs its
> > annotations in Latex,
> 
> 
> well, this is what is implemented so far ...
> 
> 
> > (and might have other problems - see separate thread[3]). 
> 
> 
> For the reference: This is now also in the archives, starting with
> http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00187.html
> 
> 
> > So I'm now wondering how best to integrate this with a published
> > score.  Several possibilities present themselves:
> > 



> > 
> > 2) Latex with \includepdf[5].
> 
> 
> I think this is the most straightforward approach. LaTeX would manage
> the volume as a whole, taking care of typesetting the textual parts
> and including the score(s). This wouldn't rule out having a
> LilyPond-created title page if you like that.
> 
> For your case that would mean you'd export the annotations to the
> LaTeX input file and use that from within the main LaTeX book file.
> However, this would still require writing a package to actually
> typeset the critical report. This is something that is still missing,
> and I'd be happy about the opportunity (and also some assistance) to
> do something about it. So far I've only used custom, project-specific
> code to typeset commentaries, but we'd need a general package that
> provides the infrastructure while still being configurable.
> 



> > 
> > 4) something else?
> 
> 
> Another good approach is very straightforward - apart from the fact
> that it isn't implemented yet. It would be good for ScholarLY to
> provide a way to produce a report by itself, as markup within a
> LilyPond score.
> I've never felt comfortable with writing markup in LilyPond so that
> would surely need significant advice from the list, but in principle
> it *should* be possible to write either
>   * a hook that outputs a report after the last page of the score
> or
>   * a command that inserts such a report at an arbitrary position
> (but I'm not sure if that can really be hooked in
> (what-information-is-present-at-what-stage-of-processing kind
> of question))
> 
> I think typesetting a report in LaTeX has some advantages regarding
> typsetting options and maybe versatility. But OTOH it would be good if
> ScholarLY could produce a proper report without forcing to have LaTeX
> to post-process it.
> 
> > 
> > I have used Latex (once!) and I'm prepared to do some learning, but
> > I'd welcome advice on the most efficient way to proceed, and the
> > pros-&-cons of each approach.

I confess I'm a bit daunted by the LaTeX learning curve, and it is
possible that I'm not uniquely inadequate in that respect.  So a
Lilypond-only solution would be ideal for me, and would save others the
prospect of learning yet-another-language.  I'm brainstorming a bit
here, but if, for example, ScholarLy could make its annotations
available as a Scheme array for metadata and markup, the lilypond user
could access that array in a \markup block after the end of the music.
Layout could then be left to the user, selecting just the desired
elements of data.

The array might look something like:
(((author . "A.N.Other")
  (bar . 2)
  (beat . 1)
  (text . "\markup { \note #"4" #1 } added")
  ...)
 ((author . "F.Bloggs")
  (bar . 5)
  ...)
 ...))


I haven't looked in detail yet but, with luck, there will be a good
correspondence between the lilyglyphs used in Latex and the notation
elements ava

Re: scholarly/annotate

[Urs Liska]

Hi Craig,

somehow I missed answering this one, and I only realized that after
writing several other posts about the topic earlier today ...

Am 05.11.2015 um 02:27 schrieb Craig Dabelstein:
> Hi Urs,
>
> Thanks for your detailed email. I agree wholeheartedly with your
> examples 1-4 above -- these would all be very useful for me. The score
> I'm working on (900-page handwritten manuscript from 1842) has natural
> horns and trumpets, and clarinets and flutes that change keys
> regularly throughout. I was going to include the original key of each
> instrument in the report to partially explain why the new transposed
> ranges are so high or low. For example using the current setup of
> annotate I'm creating a latex file that produces output like this:
>
> *M. 545,* beat 1, Flute 1: "Originally /Flauti in Es/ (which is a Db
> transposition)."
>
> or
>
> *M. 123,* beat 1, Horn 1: "Originally /Corni in Ab./"

OK, I think this is what I meant with a certain special case about your
particular score. If you don't convince me otherwise I would say this is
rather not a general use case and therefore it should be realized using
the custom properties just as you did and make sure that the LaTeX
commands understand them (see below for more details).

>
> On reflection this is probably fine, but I guess it could also be put
> into a footnote in the score (although there would be a lot of them.)

If that's not something the performer should be directed to notice I
wouldn't add numerous footnotes (but that is an *opinion*, not a rule).

>
> I don't know how using code such as the following would make this any
> easier or clearer when sending it to latex.
>
> \criticalRemark \with {
> message = "Originally \\textit{Flauti in F} which is an E\flat\
> transposition."
> original-instrument-key = \key ef \major
>   }

You're right.
If these transpositions and original keys have a significance that is
similar to other properties in your editorial situation they should be
encoded as properties.

Basically there are two approaches I can think of: Creating custom
annotation types (in LilyPond) or handle it in LaTeX commands.

As you've seen currently your custom properties end up in key=value
pairs in the optional argument. You can now "hand-code" a solution to
properly handle these keys to produce a meaningful result - or you can
help me implement a proper solution that can be generally useful (as
outlined in an earlier post today).

And maybe it would be useful to change the LaTeX export in general so
*all* properties end up in the optional argument and only the message as
the mandatory argument.

\criticalRemark

   [original-score-key={Key: #},

original-instrument-key={Key: #}]

{1184}{1}

{Flute 1}

{NoteHead}

{Originally \textit{Flauti in F} which is an E\flat\ transposition.}


would instead look something like:

\criticalRemark

   [measure=1184,
position-in-measure=1,
context={Flute 1},
item=NoteHead,
original-score-key={Key: #},

original-instrument-key={Key: #}]

{Originally \textit{Flauti in F} which is an E\flat\ transposition.}


That way one would have to implement one general approach to parsing the
keys, and maybe that would even give an opportunity to handle the
"templating" in a more consistent manner. I find the approach with named
properties cleaner than the current one that simply uses numbered
mandatory arguments.

One general thing: You pass along these custom properties as "music
expression". LilyPond accepts this and actually can interpret them but
the resulting LaTeX export is a string generated from the Scheme
representation. And this is something that LaTeX won't be easily able to
make any use of.

You should consider entering these fields in a format your intended
target platform can handle. Maybe split them into two fields, one for
the pitch and one for the mode, e.g.

\criticalRemark \with {
message = "Originally \\textit{Flauti in F} which is an E\flat\
transposition."
original-instrument-key = ef
original-instrument-mode = major
...
  }

This is not really concrete yet, but I do think we'll be able to figure
something out for you and improve the library for the general public
along the way.

Best
Urs

>
> Any ideas?
>
> Craig
>
>
>
> On Wed, 4 Nov 2015 at 21:39 Urs Liska  > wrote:
>
> OK, now I'm back again ...
>
> As said you should tell me what you want to achieve.
> - What do you want to communicate?
> - How (and where) do you think that should be visualized?
> - How do you think should it be encoded in the annotation?
>
> (This goes for your current example or any others you came across.)
>
> Then we can see if there's already a way or if it makes sense to
> implement something new.
>
> From your example  I'm not sure if it makes sense to approach it
> as you do.
> I suspect that 'original-instrument-key'  and 'original-score-key'
> aren't actually 

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Mon, 2015-11-09 at 21:53 -0600, David Wright wrote:

> On Mon 09 Nov 2015 at 23:22:14 (+), Graham King wrote:
> > On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote:
> > 
> > On 11/09/2015 02:47 PM, Kieren MacMillan wrote:
> > > The very first thing they said to me was, “Add measure numbers.”
> > >
> > > That’s sufficient reason for me.  =)
> > 
> > Good answer.
> > 
> > In that case, I would pick one part, and force those measure numbers in
> > as numeric rehearsal marks in the other parts.
> > 
> > Otherwise, you’d need a translation guide...
> > 
> > ~Chris
> > 
> > I guess Gould has a point.  I've just realised that, under my system as I
> > described it, a part could have the same bar number twice.  For example, in 
> > the
> > attachment below, T has two bars "9".  But apart from an ill-chosen number 
> > (in
> > this case), one could regard the "bar numbers" as "numeric rehearsal 
> > marks". 
> > Different mechanism, different formatting, same result.  In practice, for 
> > the
> > sort of music I'm dealing with, the polymetric sections tend to be quite 
> > short
> > so, for the most part, bar numbers are more helpful than rehearsal marks.
> 
> This is avoidable if each new bar is numbered with 1+(number of the
> bar—looking across all the parts—that most recently finished). Not
> something I could automate with my zero knowledge of scheme.


Very logical.
Advantages:
+1Might be amenable to automation.
+2Robust with respect to re-formatting.
+3Supports any variation of Staff.BarNumber.break-visibility (I
think).

Disadvantages:
-1On a given line, bar numbers increase in strange and surprising
ways, giving potential for confusion.  One cannot just count from the
start of the line and announce a bar number.

For that reason alone, I'm inclined to favour:
oCounting the bars of the top visible staff of the system, whilst
oAllowing discontinuity at the start of each line to accommodate
other parts that might have more bars in the previous line.

But that's just a personal preference.  I wouldn't want to impose it on
anyone else!  (and I'm prepared to accept the need to fiddle with bar
numbers manually at a late stage in the editing process).
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Urs Liska]

Am 10.11.2015 um 14:28 schrieb Kieren MacMillan:
> Hi Urs,
> 
>> I have no idea if it is also appropriate for ancient music.
> 
> Well, the absence of [any] barlines makes barline numbering more complex…  ;)

Of course it depends on the way an edition deals with that.


> 
>> Aren't there any useful references, how have others dealt with that 
>> challenge?
> 
> I can’t find any!

I'll be sitting in the musicological institute this afternoon and will
skim through a number of complete editions.

And maybe I'll ask around among a number of composers and music
theorists if they have an idea about barnumber handling in contemporary
polymetric scores.


Urs

> 
> Cheers,
> Kieren.
> 
> 
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 


-- 
Urs Liska
www.openlilylib.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi Urs,

> I have no idea if it is also appropriate for ancient music.

Well, the absence of [any] barlines makes barline numbering more complex…  ;)

> Aren't there any useful references, how have others dealt with that challenge?

I can’t find any!

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi Graham,

> On the positive side:
> +1This scheme guarantees a unique id for each bar.  The id increases in a 
> sensible manner.
> +2The scheme is robust with respect to re-formatting, if systems are 
> split or joined.
> +3Since Lilypond's default behaviour is to break lines only where 
> barlines co-incide and to number bars at the start of each line 
> (Staff.BarNumber.break-visibility = ##(#f #f #t)), it would work with that.
> 
> On the negative side:
> -1We have to introduce non-integers.  I don't think the current 
> bar-numbering engine will cope with that in cases where +3, above, does not 
> apply.

I didn’t really think of (or, to be honest, care about) Lilypond’s current 
bar-numbering engine; I was simply trying to solve a problem in notation. I can 
make the bar numbers appear however I want (by overriding the stencil, manually 
setting the barnumber counter, etc.).

> -2Where +3 does apply, musicians will get confused.  One will look at the 
> start of the line (bar "n") and count across in the conventional way (n+1, 
> n+2, ...) and announce the supposed bar number.  Everyone else will then look 
> on the wrong line entirely.

Sorry: I took it as self-evident [though, of course, it isn’t] that in 
polymetric music, bar numbers must appear on every bar, not just at the 
beginning of the line.

> On balance I don't think it would work.

Well, until I hear a superior suggestion, this is the one I’m going to use.  =)

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Urs Liska]

Hi Graham,

now I'll try to go into that somewhat more detailed.

Am 09.11.2015 um 17:33 schrieb Graham King:
> I'm preparing an edition of sixteenth-century polyphony, using the
> book-titling template[1].  The edition would benefit from some
> footnotes/endnotes (the sort that say things like: "contratenor 1, bar
> 99: semiminim A missing in MS").  How best to achieve this, while
> preserving the "book-titling" appearance? 

I've only looked at the description page of the book-titling template,
but I don't see that it would affect any of this.
With regard to footnote/endnotes you should first decide about what you
want. Footnotes are something completely different from endnotes, both
conceptually *and* technically.

As two rules of thumb I'd point out that

  * numerous footnotes would seem quite distracting, so if you expect to
have many annotations you'd put them in an appendix
  * footnotes on the page itself have a quite high "visibility".

A common approach is to use endnotes for the commentary in general and
use footnotes to indicate the really important comments (i.e. those you
really want the performer to notice). Sometimes you even have footnotes
that only point to the commentary at the end.



>
> Urs' marvellous work on ScholarLy[2] appears ideal, but outputs its
> annotations in Latex,

well, this is what is implemented so far ...

> (and might have other problems - see separate thread[3]).

For the reference: This is now also in the archives, starting with
http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00187.html

> So I'm now wondering how best to integrate this with a published
> score.  Several possibilities present themselves:
>
> 1) lilypond-book[4].  Requires extensive knowledge of Latex, and
> appears to be targetted at presenting small snippets within
> musicological papers, rather that large amounts of music with a small
> number of annotations.

Yes, I don't think that's what you need.

>
> 2) Latex with \includepdf[5].

I think this is the most straightforward approach. LaTeX would manage
the volume as a whole, taking care of typesetting the textual parts and
including the score(s). This wouldn't rule out having a LilyPond-created
title page if you like that.

For your case that would mean you'd export the annotations to the LaTeX
input file and use that from within the main LaTeX book file.
However, this would still require writing a package to actually typeset
the critical report. This is something that is still missing, and I'd be
happy about the opportunity (and also some assistance) to do something
about it. So far I've only used custom, project-specific code to typeset
commentaries, but we'd need a general package that provides the
infrastructure while still being configurable.

>
> 3) musicexamples.sty[6].

I don't think this is for you. musicexamples' target is quite similar to
lilypond-book. Or more concretely: you could use musicexamples' commands
and environment to include lilypond-book like music snippets in a LaTeX
document.

>
> 4) something else?

Another good approach is very straightforward - apart from the fact that
it isn't implemented yet. It would be good for ScholarLY to provide a
way to produce a report by itself, as markup within a LilyPond score.
I've never felt comfortable with writing markup in LilyPond so that
would surely need significant advice from the list, but in principle it
*should* be possible to write either

  * a hook that outputs a report after the last page of the score or
  * a command that inserts such a report at an arbitrary position
(but I'm not sure if that can really be hooked in
(what-information-is-present-at-what-stage-of-processing kind of
question))

I think typesetting a report in LaTeX has some advantages regarding
typsetting options and maybe versatility. But OTOH it would be good if
ScholarLY could produce a proper report without forcing to have LaTeX to
post-process it.


>
> I have used Latex (once!) and I'm prepared to do some learning, but
> I'd welcome advice on the most efficient way to proceed, and the
> pros-&-cons of each approach.

I think 2) and 4) are principally equally appropriate, but to choose one
out of them we'd need a better idea of the concrete project (but I can't
ask specific questions about that).

Both approaches would require additional development, either the LaTeX
code to handle the critical report or the same for LilyPond.

I assume that making LaTeX do what you want is the lower hanging fruit.
And if development of a proper (i.e. generic) LaTeX package turns out to
be complicated or takes too long it will always be possible to create a
project-specific solution without serious problems. With the
LilyPond-only approach I wouldn't make a guarantee yet if it's really
achievable, although I assume so.

On the other hand this will add a second tool and thus an additional
layer of complexity that may not be needed if you could achieve your
goal directly from within a LilyPon

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Urs Liska]

Am 09.11.2015 um 17:34 schrieb Graham King:
> (This note describes an issue arising from the separate thread,
> "Scholarly footnotes" [1])
>
> I would like to use Urs' annotate.ily[2] to add some footnotes to an
> edition of sixteenth-century polyphony.  But, before investing too
> much time, I need to check whether there is now a way for it to cope
> with polymetric music[3]. 

As the discussion in this thread clearly shows this is firstly a
conceptual problem. Only if it is clear what you want to achieve we can
even start thinking about a solution implementation-wise.

I'm not so sure that it will be possible to implement a solution that
really works automatically and is at the same time sufficiently general.
But you'd be in any case to create a manual solution, if that's a viable
approach given your material (that is: how many of these annotations do
you expect, will the numbering be stable or will you have to expect any
changes after the fact?)
We would surely be able to taylor a solution using either a custom
annotation type or a custom annotation property.

As a start you could try out and tell us what LilyPond/ScholarLY do by
default if used in polymetric scores. I *assume* that LilyPond maintains
individual bar numberings for each context and that ScholarLY will just
use the "local" barnumbers, without even knowing there's an issue. But
it would be nice if you could verify that.

Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Urs Liska]

Am 10.11.2015 um 00:56 schrieb Kieren MacMillan:
> Hi Graham,
>
>> I've just realised that, under my system as I described it, a part could 
>> have the same bar number twice.
> My proposed solution would be an “analytic continuation” (to borrow a 
> mathematical term) of the non-polymetric measure numbering scheme:
>
> 1. A “reference context” would be established (in the case of “The Country 
> Wife", the PianoStaff), and the base measure numbers would be generated in 
> that context;
>
> 2. All other contexts would use the base-context measure number when and only 
> when the barlines align; otherwise, each context would use (e.g.) 38A, 38B, … 
> to indicate measures which begin within the moment encompassed by the 
> reference measure.
>
> I think such a system would be >95% sufficient.
>
> Thoughts?

This sounds pretty reasonable (from a notational as well as from a
rehearsal POV).
At least I would find that appropriate for polymetric contemporary
music, but I have no idea if it is also appropriate for ancient music.

Aren't there any useful references, how have others dealt with that
challenge?

Urs

>
> Thanks,
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>
> ___
> 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: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[David Wright]

On Mon 09 Nov 2015 at 23:22:14 (+), Graham King wrote:
> On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote:
> 
> On 11/09/2015 02:47 PM, Kieren MacMillan wrote:
> > The very first thing they said to me was, “Add measure numbers.”
> >
> > That’s sufficient reason for me.  =)
> 
> Good answer.
> 
> In that case, I would pick one part, and force those measure numbers in
> as numeric rehearsal marks in the other parts.
> 
> Otherwise, you’d need a translation guide...
> 
> ~Chris
> 
> I guess Gould has a point.  I've just realised that, under my system as I
> described it, a part could have the same bar number twice.  For example, in 
> the
> attachment below, T has two bars "9".  But apart from an ill-chosen number (in
> this case), one could regard the "bar numbers" as "numeric rehearsal marks". 
> Different mechanism, different formatting, same result.  In practice, for the
> sort of music I'm dealing with, the polymetric sections tend to be quite short
> so, for the most part, bar numbers are more helpful than rehearsal marks.

This is avoidable if each new bar is numbered with 1+(number of the
bar—looking across all the parts—that most recently finished). Not
something I could automate with my zero knowledge of scheme.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Craig Dabelstein]

Hi Urs,

What can I do to help you advance ScholarLY (or any of your other
projects)? E.g. do I need to learn scheme? Do I play around with
incorporating ScholarLY into Latex? What would be the most helpful for you?

Craig


On Tue, 10 Nov 2015 at 03:42 Urs Liska  wrote:

> Just shortly:
>
> I do think we'll find a good way for you, and I also think this is a good
> opportunity to continue work on ScholarLY. Especially considering that just
> a  few days ago Craig Dabelstein also asked about ScholarLY.
>
>
> Urs
>
>
> Am 09.11.2015 um 17:33 schrieb Graham King:
>
> I'm preparing an edition of sixteenth-century polyphony, using the
> book-titling template[1].  The edition would benefit from some
> footnotes/endnotes (the sort that say things like: "contratenor 1, bar 99:
> semiminim A missing in MS").  How best to achieve this, while preserving
> the "book-titling" appearance?
>
> Urs' marvellous work on ScholarLy[2] appears ideal, but outputs its
> annotations in Latex (and might have other problems - see separate
> thread[3]).  So I'm now wondering how best to integrate this with a
> published score.  Several possibilities present themselves:
>
> 1) lilypond-book[4].  Requires extensive knowledge of Latex, and appears
> to be targetted at presenting small snippets within musicological papers,
> rather that large amounts of music with a small number of annotations.
>
> 2) Latex with \includepdf[5].
>
> 3) musicexamples.sty[6].
>
> 4) something else?
>
> I have used Latex (once!) and I'm prepared to do some learning, but I'd
> welcome advice on the most efficient way to proceed, and the pros-&-cons of
> each approach.
>
>
> [1] From the Snippets Repository: http://lsr.di.unimi.it/LSR/Item?id=368
> [2] http://lilypondblog.org/2015/01/introducing-scholarly/
> [3] lilypond-user list, November 2015: "ScholarLy and polymetric music?
> (bar numbering, \RemoveEmptyStaffContext)"
> [4]
> http://www.lilypond.org/doc/v2.19/Documentation/usage/lilypond_002dbook
> [5]
> http://lilypondblog.org/2013/07/creating-songbooks-with-lilypond-and-latex/
> [6] http://openlilylib.org/musicexamples/index.html
>
> ___
> lilypond-user mailing 
> listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> ___
> 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: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi Graham,

> I've just realised that, under my system as I described it, a part could have 
> the same bar number twice.

My proposed solution would be an “analytic continuation” (to borrow a 
mathematical term) of the non-polymetric measure numbering scheme:

1. A “reference context” would be established (in the case of “The Country 
Wife", the PianoStaff), and the base measure numbers would be generated in that 
context;

2. All other contexts would use the base-context measure number when and only 
when the barlines align; otherwise, each context would use (e.g.) 38A, 38B, … 
to indicate measures which begin within the moment encompassed by the reference 
measure.

I think such a system would be >95% sufficient.

Thoughts?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote:

> On 11/09/2015 02:47 PM, Kieren MacMillan wrote:
> > The very first thing they said to me was, “Add measure numbers.”
> >
> > That’s sufficient reason for me.  =)
> 
> Good answer.
> 
> In that case, I would pick one part, and force those measure numbers in 
> as numeric rehearsal marks in the other parts.
> 
> Otherwise, you’d need a translation guide...
> 
> ~Chris

I guess Gould has a point.  I've just realised that, under my system as
I described it, a part could have the same bar number twice.  For
example, in the attachment below, T has two bars "9".  But apart from an
ill-chosen number (in this case), one could regard the "bar numbers" as
"numeric rehearsal marks".  Different mechanism, different formatting,
same result.  In practice, for the sort of music I'm dealing with, the
polymetric sections tend to be quite short so, for the most part, bar
numbers are more helpful than rehearsal marks.


RemoveEmptyStaffContext.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Christopher R. Maden]

On 11/09/2015 02:47 PM, Kieren MacMillan wrote:

The very first thing they said to me was, “Add measure numbers.”

That’s sufficient reason for me.  =)


Good answer.

In that case, I would pick one part, and force those measure numbers in 
as numeric rehearsal marks in the other parts.


Otherwise, you’d need a translation guide...

~Chris
--
Chris Maden, text nerd  http://crism.maden.org/ >
“All I ask of living is to have no chains on me, and all I ask of
 dying is to go naturally.” —  Laura Nyro, “And When I Die”
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

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi Chris,

> What do you need the bar numbers for?  I suspect rehearsal marks would fit 
> the bill, no?  If not, why not?

The score runs 105 measures in the piano part. I have 9 rehearsal marks (A-I), 
for an average of ~12 measures per rehearsal mark.

In anticipation of officially [self-]publishing “The Country Wife” ASAP, I sat 
down just this past Friday with HAVEN Trio to see how I could improve the score 
and parts. HAVEN has been performing it the most often (~20 performances in the 
past year), and in fact were here in Toronto for new three performances.

The very first thing they said to me was, “Add measure numbers.”

That’s sufficient reason for me.  =)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Christopher R. Maden]

On 11/09/2015 01:47 PM, Kieren MacMillan wrote:

Is there a standard/convention/best practice on measure numbering in
polymetric scores? I’m running into an issue of that myself (in my
song “The Country Wife”), and can’t find anything definitive.

Note: Gould (p. 484) writes, “Bar numbers should not be used in music
in which individual performers have different numbers of bars or
where barlines do not coincide”… but I’d like to at least have a
non-recommended alternative.


What do you need the bar numbers for?  I suspect rehearsal marks would 
fit the bill, no?  If not, why not?


~Chris
--
Chris Maden, text nerd  http://crism.maden.org/ >
“All I ask of living is to have no chains on me, and all I ask of
 dying is to go naturally.” —  Laura Nyro, “And When I Die”
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

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Kieren MacMillan]

Hi all,

Is there a standard/convention/best practice on measure numbering in polymetric 
scores? I’m running into an issue of that myself (in my song “The Country 
Wife”), and can’t find anything definitive.

Note: Gould (p. 484) writes, “Bar numbers should not be used in music in which 
individual performers have different numbers of bars or where barlines do not 
coincide”… but I’d like to at least have a non-recommended alternative.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Scholarly footnotes

[Urs Liska]

Just shortly:

I do think we'll find a good way for you, and I also think this is a
good opportunity to continue work on ScholarLY. Especially considering
that just a  few days ago Craig Dabelstein also asked about ScholarLY.

Urs

Am 09.11.2015 um 17:33 schrieb Graham King:
> I'm preparing an edition of sixteenth-century polyphony, using the
> book-titling template[1].  The edition would benefit from some
> footnotes/endnotes (the sort that say things like: "contratenor 1, bar
> 99: semiminim A missing in MS").  How best to achieve this, while
> preserving the "book-titling" appearance? 
>
> Urs' marvellous work on ScholarLy[2] appears ideal, but outputs its
> annotations in Latex (and might have other problems - see separate
> thread[3]).  So I'm now wondering how best to integrate this with a
> published score.  Several possibilities present themselves:
>
> 1) lilypond-book[4].  Requires extensive knowledge of Latex, and
> appears to be targetted at presenting small snippets within
> musicological papers, rather that large amounts of music with a small
> number of annotations.
>
> 2) Latex with \includepdf[5].
>
> 3) musicexamples.sty[6].
>
> 4) something else?
>
> I have used Latex (once!) and I'm prepared to do some learning, but
> I'd welcome advice on the most efficient way to proceed, and the
> pros-&-cons of each approach.
>
>
> [1] From the Snippets Repository: http://lsr.di.unimi.it/LSR/Item?id=368
> [2] http://lilypondblog.org/2015/01/introducing-scholarly/
> [3] lilypond-user list, November 2015: "ScholarLy and polymetric
> music? (bar numbering, \RemoveEmptyStaffContext)"
> [4]
> http://www.lilypond.org/doc/v2.19/Documentation/usage/lilypond_002dbook
> [5]
> http://lilypondblog.org/2013/07/creating-songbooks-with-lilypond-and-latex/
> [6] http://openlilylib.org/musicexamples/index.html
>
>
> ___
> 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: scholarly/annotate

[Craig Dabelstein]

Hi Urs,

Thanks for your detailed email. I agree wholeheartedly with your examples
1-4 above -- these would all be very useful for me. The score I'm working
on (900-page handwritten manuscript from 1842) has natural horns and
trumpets, and clarinets and flutes that change keys regularly throughout. I
was going to include the original key of each instrument in the report to
partially explain why the new transposed ranges are so high or low. For
example using the current setup of annotate I'm creating a latex file that
produces output like this:

*M. 545,* beat 1, Flute 1: "Originally *Flauti in Es* (which is a Db
transposition)."

or

*M. 123,* beat 1, Horn 1: "Originally *Corni in Ab.*"

On reflection this is probably fine, but I guess it could also be put into
a footnote in the score (although there would be a lot of them.)

I don't know how using code such as the following would make this any
easier or clearer when sending it to latex.

\criticalRemark \with {
message = "Originally \\textit{Flauti in F} which is an E\flat\
transposition."
original-instrument-key = \key ef \major
  }

Any ideas?

Craig



On Wed, 4 Nov 2015 at 21:39 Urs Liska  wrote:

> OK, now I'm back again ...
>
> As said you should tell me what you want to achieve.
> - What do you want to communicate?
> - How (and where) do you think that should be visualized?
> - How do you think should it be encoded in the annotation?
>
> (This goes for your current example or any others you came across.)
>
> Then we can see if there's already a way or if it makes sense to implement
> something new.
>
> From your example  I'm not sure if it makes sense to approach it as you do.
> I suspect that 'original-instrument-key'  and 'original-score-key' aren't
> actually properties of the critical remark but rather properties of the
> message you want to communicate.
>
> I see it like this: I have an annotation, say, a critical remark.
> This has some properties, these may include things like
> - author
> - reference to a source
> - affected instrument and position in time
> - and of course the actual message
>
> Having a custom property 'original-instrument-key' would make sense if
> you'd have annotations that refer to different original-instrument-key's.
> I would think the two informations in your example should somehow be
> integrated in the 'message' property. But I may be mistaken, this very much
> depends on a more global context, i.e. if these original-key issues are
> something that you regularly have to comment on in your score(s).
>
> If you have a clear opinion on the matter we can see how to proceed with
> it. Anyway, I'll give you a few examples of features I would like to add to
> ScholarLY:
>
> 1)
> Insert music examples in the annotation. One would e.g. write something
> like
> \criticalRemark \with {
>   example-one = { a4 b c }
>   example-two = { a4. b8 c }
>   message = "Originally written as \example "example-one" but changed to
> \example "example-two".
> }
>
> 2)
> Have an annotation optionally produce a footnote in the score. This would
> use a dedicated field for the footnote text or the message if no footnote
> is specified.
>
> 3)
> Have an annotation automatically apply "editorial functions". That means:
> I can tell the annotation that it refers to an editorial addition and this
> produces a corresponding LilyPond command. This command could then be
> defined to make the affected item dashed or parenthesized or whatever,
> depending on its type.
>
> 4)
> Make it possible to have an annotation affect all or selected contexts.
> Often an annotation applies to all parts/voices equally. These should have
> to be entered only once and then affect the items in all voices. And they
> should also work when parts are engraved individually.
> It isn't acceptable to have to enter the same annotation for all the parts
> in a score.
>
> 5)
> Make it possible to define annotations externally using the
> edition-engraver (ideally it's to-be-developed evolution using IDs instead
> of/in addition to "musical moments").
> There are use cases where it is very nice to have the annotations directly
> in the input file but there are also use cases where it would be extremely
> helpful *not* to have content and annotations intertwined like that.
> Developing a dialog based interface for editing annotations would also
> benefit from such a separation.
> Actually such an interface (in Frescobaldi) is also on my wish/todo list.
>
> So any further ideas are very welcome, but you see there is much to be
> done. So I'd also be very grateful for any help.
>
> Best
>
> Urs
>
>
> Am 02.11.2015 um 23:36 schrieb Craig Dabelstein:
>
> No problem Urs. Thanks for all you do.
>
> Craig
>
>
> On Mon, 2 Nov 2015 at 17:54 Urs Liska  wrote:
>
>> Oops, sent instead of saved ...
>> I'll have to return to this later.
>>
>>
>> Am 2. November 2015 08:50:39 MEZ, schrieb Urs Liska :
>>
>>>
>>> Hi Craig,
>>>
>>> actually I see there's nothing *I* have to look into rig

Re: scholarly/annotate

[Urs Liska]

OK, now I'm back again ...

As said you should tell me what you want to achieve.
- What do you want to communicate?
- How (and where) do you think that should be visualized?
- How do you think should it be encoded in the annotation?

(This goes for your current example or any others you came across.)

Then we can see if there's already a way or if it makes sense to
implement something new.

>From your example  I'm not sure if it makes sense to approach it as you do.
I suspect that 'original-instrument-key'  and 'original-score-key'
aren't actually properties of the critical remark but rather properties
of the message you want to communicate.

I see it like this: I have an annotation, say, a critical remark.
This has some properties, these may include things like
- author
- reference to a source
- affected instrument and position in time
- and of course the actual message

Having a custom property 'original-instrument-key' would make sense if
you'd have annotations that refer to different original-instrument-key's.
I would think the two informations in your example should somehow be
integrated in the 'message' property. But I may be mistaken, this very
much depends on a more global context, i.e. if these original-key issues
are something that you regularly have to comment on in your score(s).

If you have a clear opinion on the matter we can see how to proceed with
it. Anyway, I'll give you a few examples of features I would like to add
to ScholarLY:

1)
Insert music examples in the annotation. One would e.g. write something like
\criticalRemark \with {
  example-one = { a4 b c }
  example-two = { a4. b8 c }
  message = "Originally written as \example "example-one" but changed to
\example "example-two".
}

2)
Have an annotation optionally produce a footnote in the score. This
would use a dedicated field for the footnote text or the message if no
footnote is specified.

3)
Have an annotation automatically apply "editorial functions". That
means: I can tell the annotation that it refers to an editorial addition
and this produces a corresponding LilyPond command. This command could
then be defined to make the affected item dashed or parenthesized or
whatever, depending on its type.

4)
Make it possible to have an annotation affect all or selected contexts.
Often an annotation applies to all parts/voices equally. These should
have to be entered only once and then affect the items in all voices.
And they should also work when parts are engraved individually.
It isn't acceptable to have to enter the same annotation for all the
parts in a score.

5)
Make it possible to define annotations externally using the
edition-engraver (ideally it's to-be-developed evolution using IDs
instead of/in addition to "musical moments").
There are use cases where it is very nice to have the annotations
directly in the input file but there are also use cases where it would
be extremely helpful *not* to have content and annotations intertwined
like that. Developing a dialog based interface for editing annotations
would also benefit from such a separation.
Actually such an interface (in Frescobaldi) is also on my wish/todo list.

So any further ideas are very welcome, but you see there is much to be
done. So I'd also be very grateful for any help.

Best
Urs

Am 02.11.2015 um 23:36 schrieb Craig Dabelstein:
> No problem Urs. Thanks for all you do.
>
> Craig
>
>
> On Mon, 2 Nov 2015 at 17:54 Urs Liska  wrote:
>
> Oops, sent instead of saved ...
> I'll have to return to this later.
>
>
> Am 2. November 2015 08:50:39 MEZ, schrieb Urs Liska
> mailto:u...@openlilylib.org>>:
>
> Hi Craig,
>
> actually I see there's nothing *I* have to look into right
> now. Rather you should tell me what you would like to achieve.
> Tell me what - from your experience with an actual project -
> would be good to have in ScholarLY. While not exactly rich in
> time I'm more than ready to bring this package further.
>
> So far custom properties are just translated into key-value
> properties to the LaTeX command. It's then the task of LaTeX
> to do something useful with them. As I said the current set-up
> simply guarantees that
>
> Am 29.10.2015 um 22:58 schrieb Craig Dabelstein:
>> Thanks Urs. I'm working on a 900-page score from 1842 and
>> scholarly/annotate is proving invaluable. Thanks for all your
>> hard work on this.
>>
>> Craig
>>
>>
>> On Thu, 29 Oct 2015 at 18:05 Urs Liska > > wrote:
>>
>> I'll have to try this on a PC, but for now two remarks:
>>
>> You seem to have misplaced the space before
>> \transposition so this can't be expected to produce
>> anything meaningful.
>>
>> The custom properties that end up in the optional
>> argument (square brackets) don't have any implementation
>> so 

Re: scholarly/annotate

[Craig Dabelstein]

No problem Urs. Thanks for all you do.

Craig


On Mon, 2 Nov 2015 at 17:54 Urs Liska  wrote:

> Oops, sent instead of saved ...
> I'll have to return to this later.
>
>
> Am 2. November 2015 08:50:39 MEZ, schrieb Urs Liska :
>>
>> Hi Craig,
>>
>> actually I see there's nothing *I* have to look into right now. Rather
>> you should tell me what you would like to achieve. Tell me what - from your
>> experience with an actual project - would be good to have in ScholarLY.
>> While not exactly rich in time I'm more than ready to bring this package
>> further.
>>
>> So far custom properties are just translated into key-value properties to
>> the LaTeX command. It's then the task of LaTeX to do something useful with
>> them. As I said the current set-up simply guarantees that
>>
>> Am 29.10.2015 um 22:58 schrieb Craig Dabelstein:
>>
>> Thanks Urs. I'm working on a 900-page score from 1842 and
>> scholarly/annotate is proving invaluable. Thanks for all your hard work on
>> this.
>>
>> Craig
>>
>>
>> On Thu, 29 Oct 2015 at 18:05 Urs Liska < 
>> u...@openlilylib.org> wrote:
>>
>>> I'll have to try this on a PC, but for now two remarks:
>>>
>>> You seem to have misplaced the space before \transposition so this can't
>>> be expected to produce anything meaningful.
>>>
>>> The custom properties that end up in the optional argument (square
>>> brackets) don't have any implementation so far. This is jzst a state where
>>> you can enter arbitrary stuff in the annotation and have *valid* LaTeX
>>> produced.
>>>
>>> Please remind me if I fail to come back to this.
>>>
>>> Urs
>>>
>>> Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein <
>>> craig.dabelst...@gmail.com>:
>>>
 Dear Urs (or any other Annotate experts),

 I have created this entry in my input file, taking the idea from the
 example given on git:

 \criticalRemark \with {
 message = "Originally \\textit{Flauti in F} which is an E\flat\
 transposition."
 original-instrument-key = \key ef \major
 original-score-key = \key c \major
   }

 Can anyone tell me how this should translate into the latex file? Is it
 expected to produce a real key signature in the latex file?

 The console output produces:

   \criticalRemark \with {

 Measure 1184, beat 1

 Context: Flute 1

 Affected Item: NoteHead

 Message: Originally \textit{Flauti in F} which is an E\flat\
 transposition.

 original-instrument-key: Key: #

 original-score-key: Key: #


 The .inp file produces:


 \criticalRemark

[original-score-key={Key: #},

 original-instrument-key={Key: #}]

 {1184}{1}

 {Flute 1}

 {NoteHead}

 {Originally \textit{Flauti in F} which is an E\flat\ transposition.}

 How would you have this display in your latex Critical report?

 I hope this makes sense.

 All the best,

 Craig



 *Craig Dabelstein*
 e: craig.dabelst...@gmail.com
 
 

>>> --

 lilypond-user mailing 
 listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user

 -- 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
>>
>>
> --
> 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: scholarly/annotate

[Urs Liska]

Oops,  sent instead of saved ...
I'll have to return to this later.

Am 2. November 2015 08:50:39 MEZ, schrieb Urs Liska :
>Hi Craig,
>
>actually I see there's nothing *I* have to look into right now. Rather
>you should tell me what you would like to achieve. Tell me what - from
>your experience with an actual project - would be good to have in
>ScholarLY. While not exactly rich in time I'm more than ready to bring
>this package further.
>
>So far custom properties are just translated into key-value properties
>to the LaTeX command. It's then the task of LaTeX to do something
>useful
>with them. As I said the current set-up simply guarantees that
>
>Am 29.10.2015 um 22:58 schrieb Craig Dabelstein:
>> Thanks Urs. I'm working on a 900-page score from 1842 and
>> scholarly/annotate is proving invaluable. Thanks for all your hard
>> work on this.
>>
>> Craig
>>
>>
>> On Thu, 29 Oct 2015 at 18:05 Urs Liska > > wrote:
>>
>> I'll have to try this on a PC, but for now two remarks:
>>
>> You seem to have misplaced the space before \transposition so
>this
>> can't be expected to produce anything meaningful.
>>
>> The custom properties that end up in the optional argument
>(square
>> brackets) don't have any implementation so far. This is jzst a
>> state where you can enter arbitrary stuff in the annotation and
>> have *valid* LaTeX produced.
>>
>> Please remind me if I fail to come back to this.
>>
>> Urs
>>
>> Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein
>> mailto:craig.dabelst...@gmail.com>>:
>>
>> Dear Urs (or any other Annotate experts),
>>
>> I have created this entry in my input file, taking the idea
>> from the example given on git:
>>
>> \criticalRemark \with {
>> message = "Originally \\textit{Flauti in F} which is an
>> E\flat\ transposition."
>> original-instrument-key = \key ef \major
>> original-score-key = \key c \major
>>   }
>>
>> Can anyone tell me how this should translate into the latex
>> file? Is it expected to produce a real key signature in the
>> latex file?
>>
>> The console output produces:
>>
>>   \criticalRemark \with {
>>
>> Measure 1184, beat 1
>>
>> Context: Flute 1
>>
>> Affected Item: NoteHead
>>
>> Message: Originally \textit{Flauti in F} which is an E\flat\
>> transposition.
>>
>> original-instrument-key: Key: #
>>
>> original-score-key: Key: #
>>
>>
>> The .inp file produces:
>>
>>
>> \criticalRemark
>>
>>[original-score-key={Key: #},
>>
>> original-instrument-key={Key: #}]
>>
>> {1184}{1}
>>
>> {Flute 1}
>>
>> {NoteHead}
>>
>> {Originally \textit{Flauti in F} which is an E\flat\
>> transposition.}
>>
>>
>> How would you have this display in your latex Critical
>report?
>>
>> I hope this makes sense.
>>
>> All the best,
>>
>> Craig
>>
>>
>>
>> *Craig Dabelstein*
>> e:craig.dabelst...@gmail.com
>
>> 
>
>>
>>
>
>>
>> lilypond-user mailing list
>> lilypond-user@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>> -- 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

-- 
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: scholarly/annotate

[Urs Liska]

Hi Craig,

actually I see there's nothing *I* have to look into right now. Rather
you should tell me what you would like to achieve. Tell me what - from
your experience with an actual project - would be good to have in
ScholarLY. While not exactly rich in time I'm more than ready to bring
this package further.

So far custom properties are just translated into key-value properties
to the LaTeX command. It's then the task of LaTeX to do something useful
with them. As I said the current set-up simply guarantees that

Am 29.10.2015 um 22:58 schrieb Craig Dabelstein:
> Thanks Urs. I'm working on a 900-page score from 1842 and
> scholarly/annotate is proving invaluable. Thanks for all your hard
> work on this.
>
> Craig
>
>
> On Thu, 29 Oct 2015 at 18:05 Urs Liska  > wrote:
>
> I'll have to try this on a PC, but for now two remarks:
>
> You seem to have misplaced the space before \transposition so this
> can't be expected to produce anything meaningful.
>
> The custom properties that end up in the optional argument (square
> brackets) don't have any implementation so far. This is jzst a
> state where you can enter arbitrary stuff in the annotation and
> have *valid* LaTeX produced.
>
> Please remind me if I fail to come back to this.
>
> Urs
>
> Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein
> mailto:craig.dabelst...@gmail.com>>:
>
> Dear Urs (or any other Annotate experts),
>
> I have created this entry in my input file, taking the idea
> from the example given on git:
>
> \criticalRemark \with {
> message = "Originally \\textit{Flauti in F} which is an
> E\flat\ transposition."
> original-instrument-key = \key ef \major
> original-score-key = \key c \major
>   }
>
> Can anyone tell me how this should translate into the latex
> file? Is it expected to produce a real key signature in the
> latex file?
>
> The console output produces:
>
>   \criticalRemark \with {
>
> Measure 1184, beat 1
>
> Context: Flute 1
>
> Affected Item: NoteHead
>
> Message: Originally \textit{Flauti in F} which is an E\flat\
> transposition.
>
> original-instrument-key: Key: #
>
> original-score-key: Key: #
>
>
> The .inp file produces:
>
>
> \criticalRemark
>
>[original-score-key={Key: #},
>
> original-instrument-key={Key: #}]
>
> {1184}{1}
>
> {Flute 1}
>
> {NoteHead}
>
> {Originally \textit{Flauti in F} which is an E\flat\
> transposition.}
>
>
> How would you have this display in your latex Critical report?
>
> I hope this makes sense.
>
> All the best,
>
> Craig
>
>
>
> *Craig Dabelstein*
> e:craig.dabelst...@gmail.com 
>  
> 
>
> 
> 
>
> lilypond-user mailing list
> lilypond-user@gnu.org 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> -- 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: scholarly/annotate

[Craig Dabelstein]

Thanks Urs. I'm working on a 900-page score from 1842 and
scholarly/annotate is proving invaluable. Thanks for all your hard work on
this.

Craig


On Thu, 29 Oct 2015 at 18:05 Urs Liska  wrote:

> I'll have to try this on a PC, but for now two remarks:
>
> You seem to have misplaced the space before \transposition so this can't
> be expected to produce anything meaningful.
>
> The custom properties that end up in the optional argument (square
> brackets) don't have any implementation so far. This is jzst a state where
> you can enter arbitrary stuff in the annotation and have *valid* LaTeX
> produced.
>
> Please remind me if I fail to come back to this.
>
> Urs
>
> Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein <
> craig.dabelst...@gmail.com>:
>
>> Dear Urs (or any other Annotate experts),
>>
>> I have created this entry in my input file, taking the idea from the
>> example given on git:
>>
>> \criticalRemark \with {
>> message = "Originally \\textit{Flauti in F} which is an E\flat\
>> transposition."
>> original-instrument-key = \key ef \major
>> original-score-key = \key c \major
>>   }
>>
>> Can anyone tell me how this should translate into the latex file? Is it
>> expected to produce a real key signature in the latex file?
>>
>> The console output produces:
>>
>>   \criticalRemark \with {
>>
>> Measure 1184, beat 1
>>
>> Context: Flute 1
>>
>> Affected Item: NoteHead
>>
>> Message: Originally \textit{Flauti in F} which is an E\flat\
>> transposition.
>>
>> original-instrument-key: Key: #
>>
>> original-score-key: Key: #
>>
>>
>> The .inp file produces:
>>
>>
>> \criticalRemark
>>
>>[original-score-key={Key: #},
>>
>> original-instrument-key={Key: #}]
>>
>> {1184}{1}
>>
>> {Flute 1}
>>
>> {NoteHead}
>>
>> {Originally \textit{Flauti in F} which is an E\flat\ transposition.}
>>
>> How would you have this display in your latex Critical report?
>>
>> I hope this makes sense.
>>
>> All the best,
>>
>> Craig
>>
>>
>>
>> *Craig Dabelstein*
>> e:craig.dabelst...@gmail.com
>> 
>> 
>>
>> --
>>
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>>
> --
> 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: scholarly/annotate

[Urs Liska]

I'll have to try this on a PC, but for now two remarks:

You seem to have misplaced the space before \transposition so this can't be 
expected to produce anything meaningful. 

The custom properties that end up in the optional argument (square brackets) 
don't have any implementation so far. This is jzst a state where you can enter 
arbitrary stuff in the annotation and have *valid* LaTeX produced.

Please remind me if I fail to come back to this. 

Urs

Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein 
:
>Dear Urs (or any other Annotate experts),
>
>I have created this entry in my input file, taking the idea from the
>example given on git:
>
>\criticalRemark \with {
>message = "Originally \\textit{Flauti in F} which is an E\flat\
>transposition."
>original-instrument-key = \key ef \major
>original-score-key = \key c \major
>  }
>
>Can anyone tell me how this should translate into the latex file? Is it
>expected to produce a real key signature in the latex file?
>
>The console output produces:
>
>  \criticalRemark \with {
>
>Measure 1184, beat 1
>
>Context: Flute 1
>
>Affected Item: NoteHead
>
>Message: Originally \textit{Flauti in F} which is an E\flat\
>transposition.
>
>original-instrument-key: Key: #
>
>original-score-key: Key: #
>
>
>The .inp file produces:
>
>
>\criticalRemark
>
>   [original-score-key={Key: #},
>
>original-instrument-key={Key: #}]
>
>{1184}{1}
>
>{Flute 1}
>
>{NoteHead}
>
>   {Originally \textit{Flauti in F} which is an E\flat\ transposition.}
>
>How would you have this display in your latex Critical report?
>
>I hope this makes sense.
>
>All the best,
>
>Craig
>
>
>
>*Craig Dabelstein*
>e:craig.dabelst...@gmail.com
>
>
>
>
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
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: ScholarLy newbie, running annotate.ly, gets error message

[Graham King]

On Mon, 2015-10-19 at 16:48 +0200, Urs Liska wrote:

> 
> 
> 
> Am 19.10.2015 um 16:36 schrieb Urs Liska:
> 
> > 
> > You didn't do anything wrong but stumbled over a stupid bug I didn't
> > have the time to look into. It seems that at some point I have
> > reversed the logic of an 'if' statement so it spits out that error
> > when everything is OK.
> > 
> > So if the results are what you expect please ignore *this* kind of
> > error message.
> > 
> > Urs
> 
> 
> Ok, for all those who have read that excuse from me lately: This was
> just one time too much. I *did* look into it and fixed it by moving
> one closing paren by one line. Oh I love that language ...
> 
> So please pull the latest changes from openLilyLib and *this* bug
> should be gone.


Done.  Fixed.  Many thanks Urs.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy newbie, running annotate.ly, gets error message

[Urs Liska]

Am 19.10.2015 um 16:53 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 19.10.2015 um 16:36 schrieb Urs Liska:
>>> You didn't do anything wrong but stumbled over a stupid bug I didn't
>>> have the time to look into. It seems that at some point I have
>>> reversed the logic of an 'if' statement so it spits out that error
>>> when everything is OK.
>>>
>>> So if the results are what you expect please ignore *this* kind of
>>> error message.
>>>
>>> Urs
>> Ok, for all those who have read that excuse from me lately: This was
>> just one time too much. I *did* look into it and fixed it by moving one
>> closing paren by one line. Oh I love that language ...
> Emacs' scheme-mode does a reasonably good job at making stuff clear with
> indentation (there is even a mode in ELPA that will cycle through
> different indentations when typing TAB just like python-mode does, but
> also maintaining the matching paren count while doing so).
>
> I would not want to edit Scheme code with an editor different from
> Emacs.  That's its home turf, and it shows.

Although different from the standard (as was discussed recently)
Frescobaldi works quite well too here. But it still doesn't prevent
making stupid errors, especially when manipulating things afterwards. In
this case I had to enclose the "error" branch of an if expression in a
(begin), and I managed to close that begin too late, thus including the
"success" branch in the begin. That way the error message printed
regardless of the result of the file-exists? test. Well, pretty original
use of an error message, isn't it? ;-/

>


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy newbie, running annotate.ly, gets error message

[David Kastrup]

Urs Liska  writes:

> Am 19.10.2015 um 16:36 schrieb Urs Liska:
>> You didn't do anything wrong but stumbled over a stupid bug I didn't
>> have the time to look into. It seems that at some point I have
>> reversed the logic of an 'if' statement so it spits out that error
>> when everything is OK.
>>
>> So if the results are what you expect please ignore *this* kind of
>> error message.
>>
>> Urs
>
> Ok, for all those who have read that excuse from me lately: This was
> just one time too much. I *did* look into it and fixed it by moving one
> closing paren by one line. Oh I love that language ...

Emacs' scheme-mode does a reasonably good job at making stuff clear with
indentation (there is even a mode in ELPA that will cycle through
different indentations when typing TAB just like python-mode does, but
also maintaining the matching paren count while doing so).

I would not want to edit Scheme code with an editor different from
Emacs.  That's its home turf, and it shows.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy newbie, running annotate.ly, gets error message

[Urs Liska]

Am 19.10.2015 um 16:36 schrieb Urs Liska:
> You didn't do anything wrong but stumbled over a stupid bug I didn't
> have the time to look into. It seems that at some point I have
> reversed the logic of an 'if' statement so it spits out that error
> when everything is OK.
>
> So if the results are what you expect please ignore *this* kind of
> error message.
>
> Urs

Ok, for all those who have read that excuse from me lately: This was
just one time too much. I *did* look into it and fixed it by moving one
closing paren by one line. Oh I love that language ...

So please pull the latest changes from openLilyLib and *this* bug should
be gone.

Best
Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLy newbie, running annotate.ly, gets error message

[Urs Liska]

You didn't do anything wrong but stumbled over a stupid bug I didn't
have the time to look into. It seems that at some point I have reversed
the logic of an 'if' statement so it spits out that error when
everything is OK.

So if the results are what you expect please ignore *this* kind of error
message.

Urs

Am 19.10.2015 um 16:33 schrieb Graham King:
> excuse the haiku!
>
> In my first attempt at using ScholarLy, I'm trying to compile the
> supplied example, openlilylib/ly/scholarly/usage-examples/annotate.ly
>
> The include path for Frescobaldi 2.18.1 is:
>
> /Users/grahamk/Documents/lilypond/include_gk
> /Users/grahamk/Documents/lilypond/music/openlilylib
> /Users/grahamk/Documents/lilypond/music/openlilylib/ly
> /Users/grahamk/lilypond/include
>
> At compile time, the lilypond log starts:
>
> Starting lilypond 2.19.21 [annotate.ly ]...
>
> Processing
> 
> `/Users/grahamk/Documents/lilypond/music/openlilylib/ly/scholarly/usage-examples/annotate.ly
> '
>
> Parsing...
>
> openLilyLib: library infrastructure successfully loaded.
>
> 
> /Users/grahamk/Documents/lilypond/music/openlilylib/ly/scholarly/usage-examples/annotate.ly:5:1
> <0>: warning: openLilyLib: Library main file
> 
> "/Users/grahamk/Documents/lilypond/music/openlilylib/ly/scholarly/__main__.ily"
> not found
>
> \useLibrary ScholarLY
>
> 
> /Users/grahamk/Documents/lilypond/music/openlilylib/ly/scholarly/annotate/__main__.ily:50:1
> <1>: warning: openLilyLib: Library main file
> 
> "/Users/grahamk/Documents/lilypond/music/openlilylib/ly/utility/__main__.ily"
> not found
>
> However, both files are there:
>
> $ ls -l
> 
> /Users/grahamk/Documents/lilypond/music/openlilylib/ly/{scholarly,utility}/__main__.ily
> -rw-r--r--  1 grahamk  staff  2140 17 Oct 22:36
> 
> /Users/grahamk/Documents/lilypond/music/openlilylib/ly/scholarly/__main__.ily
> -rw-r--r--  1 grahamk  staff37 17 Oct 22:36
> 
> /Users/grahamk/Documents/lilypond/music/openlilylib/ly/utility/__main__.ily
>
> Can anyone identify the no-doubt humiliatingly-obvious error that I've
> committed?
>
> TIA,
> -- Graham
>
>
> ___
> 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: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

It is now working ABSOLUTELY BRILLIANTLY!

Thanks for all your help.

Craig


On Tue Feb 03 2015 at 11:15:18 AM Urs Liska  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  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  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".
 >>>
 >>> 

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

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 
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 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
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 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

[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"

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  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  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 
>>> >> 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 
>>> >> 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

Re: ScholarLY - introduction and call for collaboration

[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 "part-init.ily"
\include "../Notes/flute.ily"

On Tue Feb 03 2015 at 9:51:03 AM Urs Liska  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  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 
>> >> 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 
>> >> 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 an

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

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 > wrote:


Am 31.01.2015 um 18:23 schrieb Urs Liska:
>
>
> Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein
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 >
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 mailto: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
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 pro

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Am 31.01.2015 um 18:23 schrieb Urs Liska:



Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein 
:

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 

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 

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 

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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-u

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein 
:
>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
>
>

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 
>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 
>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 
>>> >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

Re: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

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


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  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  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 
>> >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
>> >han

Re: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

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  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  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 
> >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
> >>> 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: ScholarLY - introduction and call for collaboration

[Urs Liska]

Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein 
:
>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  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 
>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
>>> 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: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

Thanks Urs,

And you put the "\include annotate" code in the main-init.ily file?

Craig


On Sat Jan 31 2015 at 8:05:57 AM Urs Liska  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  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
>> 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: ScholarLY - introduction and call for collaboration

[Urs Liska]

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 > 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
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: ScholarLY - introduction and call for collaboration

[Urs Liska]

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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Am 30.01.2015 um 09:35 schrieb Craig Dabelstein:

Hi Urs,

I put \include "scholarly/annotate.ily" in each of my 24 files -- one 
for each instrument.


In the score I put:
\include "scholarly/annotate.ily"
\setAnnotationExportTargets #'("plaintext" "latex")

I added 1 criticalremark and 1 musical issue to test it out.

The generated parts (both the log and the inp) are printing each of 
the issues 25 times. See inp file attached.




Could you please also send the LilyPond files (or at least a few of the 
part files and the score)?


Urs


Craig



On Fri Jan 30 2015 at 5:16:33 PM Urs Liska > wrote:



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




Philippe


___
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



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

Hi Urs,

I put \include "scholarly/annotate.ily" in each of my 24 files -- one for
each instrument.

In the score I put:
\include "scholarly/annotate.ily"
\setAnnotationExportTargets #'("plaintext" "latex")

I added 1 criticalremark and 1 musical issue to test it out.

The generated parts (both the log and the inp) are printing each of the
issues 25 times. See inp file attached.

Craig



On Fri Jan 30 2015 at 5:16:33 PM Urs Liska  wrote:

>
> 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
>
>
>
>
> Philippe
>
>
>
> ___
> lilypond-user mailing 
> listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
>
>  ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


Mendelssohn-01-score.annotations.inp
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[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






Philippe


___
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: ScholarLY - introduction and call for collaboration

[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 :



annotate.annotations.inp
Description: Binary data


annotate.ly
Description: Binary data



Philippe___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Am 30.01.2015 um 08:07 schrieb Philippe Massart:

Hello,

I’ tried the LaTeX package. Annotations are well included and it looks 
promising. But the beginning of the file causes an error due to the 
sharp symbol in the first part of the file (the part before the 
\musicalissue )


Error:
(./annotate.annotations.inp
./annotate.annotations.inp:1: You can't use `macro parameter character 
#' in ve

rtical mode.

Result:



Is there something I did wrong?



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


Philippe


___
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: ScholarLY - introduction and call for collaboration

[Philippe Massart]

Hello,

I’ tried the LaTeX package. Annotations are well included and it looks 
promising. But the beginning of the file causes an error due to the sharp 
symbol in the first part of the file (the part before the \musicalissue )

Error:
(./annotate.annotations.inp
./annotate.annotations.inp:1: You can't use `macro parameter character #' in ve
rtical mode.

Result:




Is there something I did wrong?

Philippe___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Dear Craig,

thank you for the report.

Am 30.01.2015 um 03:28 schrieb Craig Dabelstein:

Dear Urs,

I incorporated annotate into one of my current scores and it is 
fantastic. 


Great. Just to let me know: did you experience any troubles or is it as 
simple as I think to get it to run?



I can't wait for the Latex package to go along with it.


There is already a very basic stub in the /tex directory. You can try 
that out, simply use it in a document and \input the generated .inp file(s).


Best
Urs



Thanks for all you hard work.

Craig


On Wed Jan 28 2015 at 8:35:07 PM Noeck > wrote:


> I hope my other reply is a sufficient answer to this?

Yes, of course (and I agree).

___
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


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

Dear Urs,

I incorporated annotate into one of my current scores and it is fantastic.
I can't wait for the Latex package to go along with it.

Thanks for all you hard work.

Craig


On Wed Jan 28 2015 at 8:35:07 PM Noeck  wrote:

> > I hope my other reply is a sufficient answer to this?
>
> Yes, of course (and I agree).
>
> ___
> 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: ScholarLY - introduction and call for collaboration

[Noeck]

> I hope my other reply is a sufficient answer to this?

Yes, of course (and I agree).

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Am 28.01.2015 um 11:11 schrieb Noeck:

why we use so many discrete projects and repositories

I would like to second this. I am much more likely to check things out (and
perhaps contribute to things) that are in the openlilylib snippets as this is
the only repo I have checked out besides the lilypond git. All other repos would
be an extra step and need extra motivation to do so.
But of course you are free to organize GASP etc. however you want.


I hope my other reply is a sufficient answer to this?



Thanks for the blog post and the work behind it. From Urs’ questions on this
list, I guess that the second last post on the blog was not the last one on
partial compiling – which I find very exciting.


Yep. I definitely want to reach the state where I can recompile the 
currently edited system only - which would dramatically increase the 
responsiveness of editing LilyPond files.


Urs



Cheers,
Joram

___
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: ScholarLY - introduction and call for collaboration

[Urs Liska]

Hi Samuel,

thanks for your thoughts. They are not offending at all but express 
valid concerns.
However, I think there are good reasons to go the way I (and others) are 
going.


All these things have to be seen in the context of an idea/project you 
can't know yet - "specifications" for a common library infrastructure.


Libraries are a good way to extend LilyPond without having to add 
functionality to LilyPond itself. And I think everybody who reaches a 
certain productivity level will have his/her own library or libraries of 
some sort. Basically openLilyLib emerged from the wish to make such a 
personal library publicly available.
However, by now openlilylib is a rather unstructured mass of code and 
not much more than an arbitrary _collection_ of snippets. The main 
difference to the official LSR is that openlilylib is _includable_ while 
you have to _copy_ snippets from the LSR and integrate it with your own 
files. In a way this is good because it is suitable for its original 
idea, namely to be a place where interesting code can be stored and made 
available. But it's already quite unwieldy to see what is actually in 
there, and this will definitely not become better when it grows more.


So the idea is to reach a state where it is possible to create libraries 
in a consistent way and where it is very easy to "install" such 
libraries to make it available from LilyPond documents. This will make 
it possible to create libraries with specific "missions" (as you call 
it), for example scholarly editing, but also contemporary or ancient 
notation or whatever.
In a way this should be similar to packages/modules for programming 
languages or a LaTeX distribution. There you will know (or get directed 
to) that when you are looking for functionality X you should have a look 
at module/package Y. This may also encourage people to contribute their 
tools to a given library instead of only setting up their private toolkits.


One crucial part of that idea is creating a system of auto-generating 
documentation from the code files, also similar to how programming 
languages do it. Such a system will make the documentation and use of 
libraries much more convenient.


One more idea is to also develop a kind of "package manager" that would 
make it easy to get selected packages. But this is not thought through 
at all yet.
A compromise (which might actually be the perfect solution) could be to 
create one "meta" repository that _contains_ arbitrary libraries. That 
way one would only have to download/clone one repository and could 
access different libraries using some kind of namespace, e.g.


\include "oll/some/function.ily"
\include "scholarly/annotate.ily"

I can see that all this activity still looks kind of scattered but the 
idea is to have a quite consistent and coherent environment in the 
not-to-distant future.


Best
Urs

Am 28.01.2015 um 00:18 schrieb tyronicus:

I am all in favor of the collaboration, but I wonder if I might
pessimistically ask why we use so many discrete projects and repositories.

It seems to me that we could accomplish much more by using one git project
instead of having openlilylib, the LSR, and our newest projects, ScholarLY
and GASP. On top of all these projects, I've noticed that a few LP users
have their own repos of snippets and tools.

Wouldn't the beginning to intermediate user of LilyPond be benefited by the
ability to find all of these resources under one roof? Even the advanced
user might more willingly contribute to the various projects if they were
all right there in front of him/her.

Assuming it is an idea of the different projects having separate 'missions,'
why not broaden our horizons?

I hope I haven't angered anyone who fills differently than I do. These are
just the thoughts of an admitted beginner.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171149.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



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Noeck]

> why we use so many discrete projects and repositories

I would like to second this. I am much more likely to check things out (and
perhaps contribute to things) that are in the openlilylib snippets as this is
the only repo I have checked out besides the lilypond git. All other repos would
be an extra step and need extra motivation to do so.
But of course you are free to organize GASP etc. however you want.

Thanks for the blog post and the work behind it. From Urs’ questions on this
list, I guess that the second last post on the blog was not the last one on
partial compiling – which I find very exciting.

Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

Dear Urs,

Bravo! This is excellent work. I really appreciate all the time and effort
you put into Lilypond.

Craig
maximesmusic.com


On Wed Jan 28 2015 at 9:58:13 AM tyronicus  wrote:

> I must immediately excuse myself for not reading the blog post first and
> seeing that ScholarLY is a part of openlilylib. But I still wonder about
> the
> rest.
>
>
>
> --
> View this message in context: http://lilypond.1069038.n5.
> nabble.com/ScholarLY-introduction-and-call-for-
> collaboration-tp171140p171152.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
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ScholarLY - introduction and call for collaboration

[tyronicus]

I must immediately excuse myself for not reading the blog post first and
seeing that ScholarLY is a part of openlilylib. But I still wonder about the
rest.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171152.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

[tyronicus]

I am all in favor of the collaboration, but I wonder if I might
pessimistically ask why we use so many discrete projects and repositories.

It seems to me that we could accomplish much more by using one git project
instead of having openlilylib, the LSR, and our newest projects, ScholarLY
and GASP. On top of all these projects, I've noticed that a few LP users
have their own repos of snippets and tools.

Wouldn't the beginning to intermediate user of LilyPond be benefited by the
ability to find all of these resources under one roof? Even the advanced
user might more willingly contribute to the various projects if they were
all right there in front of him/her.

Assuming it is an idea of the different projects having separate 'missions,'
why not broaden our horizons?

I hope I haven't angered anyone who fills differently than I do. These are
just the thoughts of an admitted beginner.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171149.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