Re: Pedal cautionary after a line break (current status and improvements)

[Paolo Prete]

>
>>>
>>> By the way, the Type::Enhancement label expresses no judgement about
>>> wether the
>>> issue is a major one. It's to be understood as opposed to Type::Defect:
>>> this ticket
>>> is about an enhancement because the current output is consistent and
>>> there is
>>> no crash.
>>>
>>> I opened https://gitlab.com/lilypond/lilypond/-/issues/6005 .
>>>
>>>
>> I would not proceed in this way.
>> The lack of a cautionary pedal on a bracket could be seen as an
>> enhancement only in a self-referential context, which doesn't make sense to
>> me. A proper way to proceed is to check what modern professional engravers
>> do with it, and check as a consequence if Lilypond is coherent with them
>> (-> common practice)
>> AFAIK nobody uses a bracket without a starting word in professional
>> engraving, it would have too many bad side effects. And opening an issue as
>> an enhancement IMHO will weaken the urgency of fixing this.
>>
>> Best,
>>
>> P
>>
>>
> Not that anyone asked my opinion, but I feel compelled to point out:
>
> 1) There should NOT be any sense of urgency, since nothing is broken.  It
> just doesn't work the way you want to, it's not as good as it could be.
> There are workarounds.  It is something that is needed in surely less than
> 1% of all sheet music, so it is practically speaking, irrelevant.
>
>
This percentage is meaningless for me. I would ask, instead: "how many
scores published by professional engravers do use a pedal bracket with a
cautionary text? "
AFAIK, 100%, not 1%.
But this is what I know, and I could be wrong. Then I asked
for counterexamples (to Kieren, in the previous post).

If I'm right, then the pedal brackets are pretty unusable, at the moment,
without a hack.

If I'm wrong, I agree there should not be any sense of urgency, as you
wrote.


2) Your complaining about the lilypond community process for how the issue
> was tagged will probably reduce anyone's interest in working on it.  So,
> even if you do succeed in getting it tagged as more urgent, it will likely
> be a pyrrhic victory.
>
>
I won't see the thing like a battle of someone against someone else. It's
an interesting question which deserves further study, IMHO.

Best,
P






>
> Elaine Alt
> ela...@flaminghakama.com
>
>

Re: Snippet "Clef change and repeat barline"

[Thomas Morley]

Am Do., 25. Juni 2020 um 10:55 Uhr schrieb Pierre Perol-Schneider
:
>
> Hi Harm,
>
> Le mer. 24 juin 2020 à 23:26, Thomas Morley  a 
> écrit :
>>
>> To the author of said snippet.
>> lsr.di.unimi.it/LSR/Item?u=1=1110
>>
>> I will not approve it in it's current state.
>
>
> Ok.
>
>> This sounds like default LilyPond being wrong in this regard. If so,
>> it's a bug, needed to be reported, probably discussed and finally
>> fixed.
>
>
> Ok, will do.
>
>>
>> Tbh, I don't think LilyPond is wrong. Ofcourse I'd could be proven wrong.
>
>
> See: E. Gould/ Behind bars (ed. 2011, pp. 234-235)
> (and: 
> http://lilypond-french-users.1298960.n2.nabble.com/Clef-apres-signe-de-reprise-td7589673.html)
>
> Cheers,
> Pierre

Hi Pierre,

ok, I'm convinced.
Please change the description to something at the lines of:
"According to Elaine Gould, Behind Bars, pp ..., changes of  ...
should be printed after the closing repeat-sign.
This is currently not the default in Lily.
This snippet provides a manual workaround."

Syntax, wording, grammar could surely be improved...

Nevertheless, I don't think it should be doc-tagged.
If it's an issue then an entry in "known issues and warnings" seems to
be more appropriate, imho.

And thanks for the bug-report, cheers,
  Harm

Re: Pedal cautionary after a line break (current status and improvements)

[Flaming Hakama by Elaine]

>
>
> -- Forwarded message --
> From: Paolo Prete 
> To: Jean Abou Samra 
> Cc: Thomas Morley , Lilypond-User Mailing List <
> lilypond-user@gnu.org>, lilypond-devel , Pierre
> Perol-Schneider 
> Bcc:
> Date: Thu, 25 Jun 2020 21:07:27 +0200
> Subject: Re: Pedal cautionary after a line break (current status and
> improvements)
>
>
> On Thu, Jun 25, 2020 at 6:00 PM Jean Abou Samra 
> wrote:
>
>> So, in order to produce a concrete result, at least the point 2) should
>> be accepted / understood. This is what I tried to do, but the thread seems
>> to go in the opposite way. This is why I think that opening a ticket would
>> be unuseful for now and I did not open it. But if you think it could be
>> useful, be free (of course) to open it ...
>>
>> This is precisely the heart of the question. LilyPond development is
>> (mostly) not driven by the importance of issues but rather by pleasure and
>> interest. Which means that you just need one person willing to spend time
>> on
>> piano pedals − and skilled enough for that − regardless of the issue's
>> weight. That can happen now, or in months or in years, who knows. In the
>> most extreme cases, issues can be resolved a decade after they were
>> reported. Look at the one David Stephen Grant fixed just two weeks ago:
>>
>> https://gitlab.com/lilypond/lilypond/-/issues/1722
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/119
>> This is why issues are so essential. They help organize work on a long
>> time frame.
>>
>> By the way, the Type::Enhancement label expresses no judgement about
>> wether the
>> issue is a major one. It's to be understood as opposed to Type::Defect:
>> this ticket
>> is about an enhancement because the current output is consistent and
>> there is
>> no crash.
>>
>> I opened https://gitlab.com/lilypond/lilypond/-/issues/6005 .
>>
>>
> I would not proceed in this way.
> The lack of a cautionary pedal on a bracket could be seen as an
> enhancement only in a self-referential context, which doesn't make sense to
> me. A proper way to proceed is to check what modern professional engravers
> do with it, and check as a consequence if Lilypond is coherent with them
> (-> common practice)
> AFAIK nobody uses a bracket without a starting word in professional
> engraving, it would have too many bad side effects. And opening an issue as
> an enhancement IMHO will weaken the urgency of fixing this.
>
> Best,
>
> P
>
>
Not that anyone asked my opinion, but I feel compelled to point out:

1) There should NOT be any sense of urgency, since nothing is broken.  It
just doesn't work the way you want to, it's not as good as it could be.
There are workarounds.  It is something that is needed in surely less than
1% of all sheet music, so it is practically speaking, irrelevant.

2) Your complaining about the lilypond community process for how the issue
was tagged will probably reduce anyone's interest in working on it.  So,
even if you do succeed in getting it tagged as more urgent, it will likely
be a pyrrhic victory.


Elaine Alt
ela...@flaminghakama.com

Re: detecting the start and end of a polyphonic passage from scheme

[Maurits Lamers]

Hi, 

Great solution, thanks a lot!

cheers

Maurits


> On 2020-06-25 7:01 am, Maurits Lamers wrote:
> Hi all,
> 
> I am trying to build a system based on the listener system which can
> identify voices in a piece of music.
> I use a listener to the Voice context to give me the note events.
> 
> In the following passage I can use (ly:context-id
> (ly:translator-context engraver) to get the id, which is empty for c4,
> "1" for the first voice, "2" for the second voice, and empty again for
> d4 at the end.
> 
> time 4/4 \relative c' {  c4 << { c8 d e4 } \\ { c8 b c4 } >> d4 | }
> 
> 
> However in the following passage the context-id cannot be used because
> it is not set.
> 
> \relative c' {
>   \new Voice {
> c4
> <<
>   \new Voice {
> c8 d e4
>   }
>   \new Voice {
> c8 b c4
>   }
> >>
> d4
>   }
> }
> 
> I am currently using object properties to follow these voices by
> setting a unique value for that voice context object, but that doesn't
> help me
> to detect properly the start and end of the polyphonic passage. The
> main voice gets 1, the first nested voice will be 2, the second nested
> voice will be 3.
> For transcription purposes it would be very helpful to detect the
> start and end of the polyphonic passage. Is this possible?
> The initialize and finalize procedures of an engraver will run when the 
> context in which it is \consisted begins and ends. Consider:
> 
> \version "2.20.0"
> 
> #(define custom-uid
>   (let ((custom-uid-prop (make-object-property))
> (last-uid 0))
> (lambda (obj)
>   (or (custom-uid-prop obj)
>   (begin
> (set! last-uid (1+ last-uid))
> (set! (custom-uid-prop obj) last-uid)
> last-uid)
> 
> handle-init-and-final =
> #(lambda (context)
>   (make-engraver
> ((initialize engraver)
>   (let* ((ctxt (ly:translator-context engraver))
>  (id (ly:context-id ctxt))
>  (uid (custom-uid ctxt))
>  (now (ly:context-now ctxt)))
> (format #t "\ninitialize: ~s, id=~s, uid=~s, now=~s"
>   ctxt id uid now)))
> ((finalize engraver)
>   (let* ((ctxt (ly:translator-context engraver))
>  (id (ly:context-id ctxt))
>  (uid (custom-uid ctxt))
>  (now (ly:context-now ctxt)))
> (format #t "\nfinalize: ~s, id=~s, uid=~s, now=~s"
>   ctxt id uid now)
> 
> \layout { \context { \Voice \consists \handle-init-and-final } }
> 
> { \relative c' { \new Voice { c4
>   << \new Voice = foo { \voiceOne c8 d e4 }
>  \new Voice { \voiceTwo c8 b c4 } >> d4 } } }
> 
> 
> 
> . . .
> Parsing...
> Interpreting music...
> initialize: #, id="", uid=1, now=#
> initialize: #, id="foo", uid=2, now=#
> initialize: #, id="", uid=3, now=#
> finalize: #, id="foo", uid=2, now=#
> finalize: #, id="", uid=3, now=#
> finalize: #, id="", uid=1, now=#
> Preprocessing graphical objects...
> . . .
> 
> 
> NOTE: I am using Scheme object properties to attach a custom unique 
> identifier to the contexts as they are seen, so it is possible to discern 
> which context is which even when they are not named.
> 
> -- Aaron Hill
> 
> 

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Hi Jean,
Am Donnerstag, den 25.06.2020, 18:22 +0200 schrieb Jean Abou Samra:
> 
>   
> > Hi all,
> > there's a method of harmonic analysis (»Bassstufen« in German)
> > thatworks by having numbers in a main layer plus option bass
> > figures ontop. There are at least two flavours or this analysis
> > markup: theoriginal one from the 18th century with bare numbers for
> > the basssteps, and at least one modern variant with additional
> > markup. Attachedyou'll find one example.
> > For a proper handling I need to combine this into *one* command
> > (theexample was created with separate Lyrics and BassFigures
> > contexts).
> > Is there a way to add arbitrary markup to bass figures or to add
> > bassfigures to markup (maybe the easier way round)? Of course I
> > know how toadd the music font numbers to a markup, but it would be
> > nice (and lesserror-prone) not having to reimplement LilyPond's
> > bass figuretypesetting.
> > Has anyone done that already? Thoughts?
> > BestUrs
> >   
> 
>   
> 
>   Hi Urs,
> 
> Not exactly sure that's what you're looking for, but
> bass figures
> 
> can contain surprisingly complex expressions, including
> markups.
> 
> 
> 
>   \figures {
> 
> <6 4 \markup { \vspace #1 \circle \number 5 }>

Hey, that looks promising - I didn't know that.Now I'd only need a way
to properly do the vertical alignment against the baseline of the
lowest markup:
\figures {  <6 4 \markup { \circle \number 5 }>  <3+ \markup { \circle
\number 6 }>}
Best
Urs
>   }
> Best,
> 
> Jean
> 
>   
>   
> 

Re: Pedal cautionary after a line break (current status and improvements)

[Paolo Prete]

On Thu, Jun 25, 2020 at 6:00 PM Jean Abou Samra  wrote:

> So, in order to produce a concrete result, at least the point 2) should be
> accepted / understood. This is what I tried to do, but the thread seems to
> go in the opposite way. This is why I think that opening a ticket would be
> unuseful for now and I did not open it. But if you think it could be
> useful, be free (of course) to open it ...
>
> This is precisely the heart of the question. LilyPond development is
> (mostly) not driven by the importance of issues but rather by pleasure and
> interest. Which means that you just need one person willing to spend time
> on
> piano pedals − and skilled enough for that − regardless of the issue's
> weight. That can happen now, or in months or in years, who knows. In the
> most extreme cases, issues can be resolved a decade after they were
> reported. Look at the one David Stephen Grant fixed just two weeks ago:
>
> https://gitlab.com/lilypond/lilypond/-/issues/1722
> https://gitlab.com/lilypond/lilypond/-/merge_requests/119
> This is why issues are so essential. They help organize work on a long
> time frame.
>
> By the way, the Type::Enhancement label expresses no judgement about
> wether the
> issue is a major one. It's to be understood as opposed to Type::Defect:
> this ticket
> is about an enhancement because the current output is consistent and there
> is
> no crash.
>
> I opened https://gitlab.com/lilypond/lilypond/-/issues/6005 .
>
>
I would not proceed in this way.
The lack of a cautionary pedal on a bracket could be seen as an enhancement
only in a self-referential context, which doesn't make sense to me. A
proper way to proceed is to check what modern professional engravers do
with it, and check as a consequence if Lilypond is coherent with them (->
common practice)
AFAIK nobody uses a bracket without a starting word in professional
engraving, it would have too many bad side effects. And opening an issue as
an enhancement IMHO will weaken the urgency of fixing this.

Best,

P

Re: Snippet "Clef change and repeat barline"

[Pierre Perol-Schneider]

Le mer. 24 juin 2020 à 23:26, Thomas Morley  a
écrit :
 ...

> Please check whether there's an issue about it already, if not report
> it on the bug-list.
>

Done:
http://lilypond.1069038.n5.nabble.com/Clef-change-and-repeat-sign-td234226.html

Cheers,
Pierre

Combine Text/Lyrics with bass figures

[Jean Abou Samra]

Hi all,

there's a method of harmonic analysis (»Bassstufen« in German) that
works by having numbers in a main layer plus option bass figures on
top. There are at least two flavours or this analysis markup: the
original one from the 18th century with bare numbers for the bass
steps, and at least one modern variant with additional markup. Attached
you'll find one example.

For a proper handling I need to combine this into *one* command (the
example was created with separate Lyrics and BassFigures contexts).

Is there a way to add arbitrary markup to bass figures or to add bass
figures to markup (maybe the easier way round)? Of course I know how to
add the music font numbers to a markup, but it would be nice (and less
error-prone) not having to reimplement LilyPond's bass figure
typesetting.

Has anyone done that already? Thoughts?

Best
Urs


Hi Urs,

Not exactly sure that's what you're looking for, butbass figures
can contain surprisingly complex expressions, including markups.

\figures {
  <6 4 \markup { \vspace #1 \circle \number 5 }>
}

Best,
Jean

Re: Pedal cautionary after a line break (current status and improvements)

[Jean Abou Samra]

Hi Paolo,

Le 25/06/2020 à 16:10, Paolo Prete a écrit :

On Thursday, June 25, 2020, Jean Abou Samra > wrote:



Hi Paolo,

I still highly encourage you to fill an issue at
https://gitlab.com/lilypond/lilypond/-/issues


Judging from piano-pedal-engraver.cc, the main authors of the code
used for piano pedals are Jan, Erik Sandberg and Chris Jackson. None
of them is currently active on LilyPond as far as I know. It certainly
isn't a blocker, but the issue isn't trivial either as you mentioned.
Mailing list threads are volatile: people who are currently on
holiday, or
busy, or who will join development in months or years won't read them.
This is why an issue is the way to go. I didn't open one because I
thought
you'd want to do it, but someone else can go ahead if you prefer.

Cheers,
Jean

Hi Jean,

Given that

1) fixing this issue requires a not trivial change and the authours of 
the code are no longer active


2) this issue, as the replies of this thread show, is not considered a 
major one (as I instead do; and I'm still convinced that a pedal 
Bracket without a cautionary text is unusable / unpresentable) but it 
appears more or less as an "enhancement"


If you sum 1 + 2 chances that the reported issue will be developed

… are 3!
But joking aside …
So, in order to produce a concrete result, at least the point 2) 
should be accepted / understood. This is what I tried to do, but the 
thread seems to go in the opposite way. This is why I think that 
opening a ticket would be unuseful for now and I did not open it. But 
if you think it could be useful, be free (of course) to open it ...



This is precisely the heart of the question. LilyPond development is
(mostly) not driven by the importance of issues but rather by pleasure and
interest. Which means that you just need one person willing to spend time on
piano pedals − and skilled enough for that − regardless of the issue's
weight. That can happen now, or in months or in years, who knows.In the
most extreme cases, issues can be resolved a decade after they were
reported. Look at the one David Stephen Grant fixed just two weeks ago:

https://gitlab.com/lilypond/lilypond/-/issues/1722
https://gitlab.com/lilypond/lilypond/-/merge_requests/119

This is why issues are so essential. They help organize work on a long 
time frame.


By the way, the Type::Enhancement label expresses no judgement about 
wether the
issue is a major one. It's to be understood as opposed to Type::Defect: 
this ticket
is about an enhancement because the current output is consistent and 
there is

no crash.

I opened https://gitlab.com/lilypond/lilypond/-/issues/6005.

Cheers,
Jean


Best,
P

Re: detecting the start and end of a polyphonic passage from scheme

[Aaron Hill]

On 2020-06-25 7:01 am, Maurits Lamers wrote:

Hi all,

I am trying to build a system based on the listener system which can
identify voices in a piece of music.
I use a listener to the Voice context to give me the note events.

In the following passage I can use (ly:context-id
(ly:translator-context engraver) to get the id, which is empty for c4,
"1" for the first voice, "2" for the second voice, and empty again for
d4 at the end.

time 4/4 \relative c' {  c4 << { c8 d e4 } \\ { c8 b c4 } >> d4 | }


However in the following passage the context-id cannot be used because
it is not set.

\relative c' {
  \new Voice {
c4
<<
  \new Voice {
c8 d e4
  }
  \new Voice {
c8 b c4
  }
>>
d4
  }
}

I am currently using object properties to follow these voices by
setting a unique value for that voice context object, but that doesn't
help me
to detect properly the start and end of the polyphonic passage. The
main voice gets 1, the first nested voice will be 2, the second nested
voice will be 3.
For transcription purposes it would be very helpful to detect the
start and end of the polyphonic passage. Is this possible?


The initialize and finalize procedures of an engraver will run when the 
context in which it is \consisted begins and ends.  Consider:



\version "2.20.0"

#(define custom-uid
  (let ((custom-uid-prop (make-object-property))
(last-uid 0))
(lambda (obj)
  (or (custom-uid-prop obj)
  (begin
(set! last-uid (1+ last-uid))
(set! (custom-uid-prop obj) last-uid)
last-uid)

handle-init-and-final =
#(lambda (context)
  (make-engraver
((initialize engraver)
  (let* ((ctxt (ly:translator-context engraver))
 (id (ly:context-id ctxt))
 (uid (custom-uid ctxt))
 (now (ly:context-now ctxt)))
(format #t "\ninitialize: ~s, id=~s, uid=~s, now=~s"
  ctxt id uid now)))
((finalize engraver)
  (let* ((ctxt (ly:translator-context engraver))
 (id (ly:context-id ctxt))
 (uid (custom-uid ctxt))
 (now (ly:context-now ctxt)))
(format #t "\nfinalize: ~s, id=~s, uid=~s, now=~s"
  ctxt id uid now)

\layout { \context { \Voice \consists \handle-init-and-final } }

{ \relative c' { \new Voice { c4
  << \new Voice = foo { \voiceOne c8 d e4 }
 \new Voice { \voiceTwo c8 b c4 } >> d4 } } }



. . .
Parsing...
Interpreting music...
initialize: #, id="", uid=1, now=#
initialize: #, id="foo", uid=2, now=#
initialize: #, id="", uid=3, now=#
finalize: #, id="foo", uid=2, now=#
finalize: #, id="", uid=3, now=#
finalize: #, id="", uid=1, now=#
Preprocessing graphical objects...
. . .


NOTE: I am using Scheme object properties to attach a custom unique 
identifier to the contexts as they are seen, so it is possible to 
discern which context is which even when they are not named.



-- Aaron Hill

Re: Pedal cautionary after a line break (current status and improvements)

[Paolo Prete]

On Thursday, June 25, 2020, Jean Abou Samra  wrote:

> Le 25/06/2020 à 00:58, Paolo Prete a écrit :
>
> Hi Harm,
>
> Then Pierre, who is the creator of the snippet and joined this thread, will
> decide what to do.
>
> Best,
> P
>
> Hi Paolo,
>
> I still highly encourage you to fill an issue at
> https://gitlab.com/lilypond/lilypond/-/issues
>
> Judging from piano-pedal-engraver.cc, the main authors of the code
> used for piano pedals are Jan, Erik Sandberg and Chris Jackson. None
> of them is currently active on LilyPond as far as I know. It certainly
> isn't a blocker, but the issue isn't trivial either as you mentioned.
> Mailing list threads are volatile: people who are currently on holiday, or
> busy, or who will join development in months or years won't read them.
> This is why an issue is the way to go. I didn't open one because I thought
> you'd want to do it, but someone else can go ahead if you prefer.
>
> Cheers,
> Jean
>
>

 Hi Jean,

Given that

1) fixing this issue requires a not trivial change and the authours of the
code are no longer active

2) this issue, as the replies of this thread show, is not considered a
major one (as I instead do; and I'm still convinced that a pedal Bracket
without a cautionary text is unusable / unpresentable) but it appears more
or less as an "enhancement"

If you sum 1 + 2 chances that the reported issue will be developed are ~ 0.

So, in order to produce a concrete result, at least the point 2) should be
accepted / understood. This is what I tried to do, but the thread seems to
go in the opposite way. This is why I think that opening a ticket would be
unuseful for now and I did not open it. But if you think it could be
useful, be free (of course) to open it ...

Best,
P

detecting the start and end of a polyphonic passage from scheme

[Maurits Lamers]

Hi all,

I am trying to build a system based on the listener system which can identify 
voices in a piece of music.
I use a listener to the Voice context to give me the note events.

In the following passage I can use (ly:context-id (ly:translator-context 
engraver) to get the id, which is empty for c4,
"1" for the first voice, "2" for the second voice, and empty again for d4 at 
the end.

time 4/4 \relative c' {  c4 << { c8 d e4 } \\ { c8 b c4 } >> d4 | }


However in the following passage the context-id cannot be used because it is 
not set.

\relative c' {
  \new Voice {
c4
<<
  \new Voice {
c8 d e4
  }
  \new Voice {
c8 b c4
  }
>>
d4
  }
}

I am currently using object properties to follow these voices by setting a 
unique value for that voice context object, but that doesn't help me
to detect properly the start and end of the polyphonic passage. The main voice 
gets 1, the first nested voice will be 2, the second nested voice will be 3.
For transcription purposes it would be very helpful to detect the start and end 
of the polyphonic passage. Is this possible?

cheers

Maurits

Re: Pedal cautionary after a line break (current status and improvements)

[Jean Abou Samra]

Le 25/06/2020 à 00:58, Paolo Prete a écrit :

Hi Harm,
Then Pierre, who is the creator of the snippet and joined this thread, will
decide what to do.

Best,
P

Hi Paolo,

I still highly encourage you to fill an issue at
https://gitlab.com/lilypond/lilypond/-/issues


Judging from piano-pedal-engraver.cc, the main authors of the code
used for piano pedals are Jan, Erik Sandberg and Chris Jackson. None
of them is currently active on LilyPond as far as I know. It certainly
isn't a blocker, but the issue isn't trivial either as you mentioned.
Mailing list threads are volatile: people who are currently on holiday, or
busy, or who will join development in months or years won't read them.
This is why an issue is the way to go. I didn't open one because I thought
you'd want to do it, but someone else can go ahead if you prefer.

Cheers,
Jean

Combine Text/Lyrics with bass figures

[Urs Liska]

Hi all,

there's a method of harmonic analysis (»Bassstufen« in German) that
works by having numbers in a main layer plus option bass figures on
top. There are at least two flavours or this analysis markup: the
original one from the 18th century with bare numbers for the bass
steps, and at least one modern variant with additional markup. Attached
you'll find one example.

For a proper handling I need to combine this into *one* command (the
example was created with separate Lyrics and BassFigures contexts).

Is there a way to add arbitrary markup to bass figures or to add bass
figures to markup (maybe the easier way round)? Of course I know how to
add the music font numbers to a markup, but it would be nice (and less
error-prone) not having to reimplement LilyPond's bass figure
typesetting.

Has anyone done that already? Thoughts?

Best
Urs

Re: Better support for Bravura in LilyPond

[Daniel Benjamin Miller]

I agree. Having choice in this respect is wonderful and important. 
Abraham's work in this regard was great, though, as I am a staunch user 
of what is free and open-source (in large part because I want /anyone/ 
to be able to modify and re-compile my scores), I am a bit saddened that 
he moved to proprietary fonts. You will notice that I use his (still 
OFL, though old) Profondo brace font (a conversion of Bravura; I 
replaced his Profondo music font because it was out of date, being based 
on an early pre-release of Bravura).


Adding SMuFL support will enhance our ability to add new fonts by a lot. 
Right now a big issue is that it is extremely difficult to create the 
proper special tables (LILY and so on) in fonts so that LilyPond can 
actually use them. And most fonts are not METAFONT-designed like 
Emmentaler, so the accessible infrastructure for font building for 
LilyPond is abysmal. So to me the advantage of SMuFL is not only that 
we'll be able to use fonts from elsewhere, but the creation of fonts 
becomes orders of magnitude less difficult too (as the tools for 
developing SMuFL fonts are in place).


Of course, between Abraham Lee's conversion of the pre-release Bravura, 
and the existing Bravura support that had been put together before, this 
is not the first time that Bravura was made to be used in LilyPond. But 
I think it's finally ready for actual publication-quality usage now! So 
while Owen does his work on SMuFL support, we have another good choice 
for the present!


On 6/25/20 5:16 AM, Urs Liska wrote:

Am Donnerstag, den 25.06.2020, 04:37 -0400 schrieb Daniel Benjamin
Miller:

You're right, it does essentially replicate Dorico's style.

I don't think LilyPond should change what its default style is;

I think what you suggested with this wasn't to change the defaults. But
I really like the idea of having choice. It is good that out-of-the-box
scores are immediately recognizble (although I have the impression that
the *text* font is even more notable in this respect).

But people shouldn't be limited to that "personality" but have the
option to tweak the output to what they like. Generally speaking scores
shouldn't necessarily have the personality of the program but that of
the author/editor/publisher. Abraham Lee's efforts in making
alternative fonts properly available at all, and his collection of
fonts, was a huge step forware IMHO, and I really hope that Owen Lamb's
work of making LilyPond SMuFL-compliant will make that possibility of
choice even more fundmental.

Urs


I don't
like the Emmentaler font myself (Simon Tatham put it best, though I
actually feel the same about Gonville:
https://www.chiark.greenend.org.uk/~sgtatham/gonville/ - "I designed
it
because Lilypond's standard font (Feta) was not to my taste: I found
it
to be (variously) over-ornate, strangely proportioned, and subtly
not
like the music I was used to reading. Music set in Feta looks to me
like
strangely stylised music; music set in Gonville just looks to me
like
music, so I can read it without being distracted so much.)

But I also think that we should not try to change the defaults. But
I
also think that almost nobody actually cares much about music
typography, really: only LilyPond and Dorico have really put effort
into
creating their default fonts and appearances; MuseScore borrows its
fonts from both, and Finale and Sibelius' fonts are really clearly
not
that seriously taken.

LilyPond is not static, but it should not really change in terms of
its
defaults either. Much like TeX, we should not change the default
fonts,
in my opinion (though of course Emmentaler and Feta are being
expanded
as new features are added to LilyPond, and slight tweaks and
improvements are all well and good).

On 6/25/20 3:06 AM, Martin Tarenskeen wrote:

On Thu, 25 Jun 2020, Daniel Benjamin Miller wrote:


I'd like to share something:
https://github.com/dbenjaminmiller/bmusicfonts
I personally prefer the Bravura design to Emmentaler/Feta, and
there'd been

Thanks for this, I am going to try it for sure. I like Dorico's
output, and this will sort of give a similar result for LilyPond if
I
understand correctly?

Which leads to a more philosophic question. Do we want LilyPond
scores
to have an immediately recognizable "personality" or are we slowly
moving to a situation where everyone, including LilyPond, is trying
to
look the same (when using default settings), and it will be hard
to
see if a score was typeset in LilyPond, MuseScore, Dorico, Finale,
or
Sibelius?

I hope LilyPond will always try to keep a distinct personality in
the
default output, which is not a static thing but can be discussed
in
the Lilypond user and developers community, changed, and improved
continuously. But let not all our efforts go to looking as much as
possible like "the other ones".

I know LilyPond is (almost) flexible and tweakable enough to have
it
all, but what I am talking about is the default output.

Re: Better support for Bravura in LilyPond

[Urs Liska]

Am Donnerstag, den 25.06.2020, 04:37 -0400 schrieb Daniel Benjamin
Miller:
> You're right, it does essentially replicate Dorico's style.
> 
> I don't think LilyPond should change what its default style is; 

I think what you suggested with this wasn't to change the defaults. But
I really like the idea of having choice. It is good that out-of-the-box 
scores are immediately recognizble (although I have the impression that
the *text* font is even more notable in this respect).

But people shouldn't be limited to that "personality" but have the
option to tweak the output to what they like. Generally speaking scores
shouldn't necessarily have the personality of the program but that of
the author/editor/publisher. Abraham Lee's efforts in making
alternative fonts properly available at all, and his collection of
fonts, was a huge step forware IMHO, and I really hope that Owen Lamb's
work of making LilyPond SMuFL-compliant will make that possibility of
choice even more fundmental.

Urs

> I don't 
> like the Emmentaler font myself (Simon Tatham put it best, though I 
> actually feel the same about Gonville: 
> https://www.chiark.greenend.org.uk/~sgtatham/gonville/ - "I designed
> it 
> because Lilypond's standard font (Feta) was not to my taste: I found
> it 
> to be (variously) over-ornate, strangely proportioned, and subtly
> not 
> like the music I was used to reading. Music set in Feta looks to me
> like 
> strangely stylised music; music set in Gonville just looks to me
> like 
> music, so I can read it without being distracted so much.)
> 
> But I also think that we should not try to change the defaults. But
> I 
> also think that almost nobody actually cares much about music 
> typography, really: only LilyPond and Dorico have really put effort
> into 
> creating their default fonts and appearances; MuseScore borrows its 
> fonts from both, and Finale and Sibelius' fonts are really clearly
> not 
> that seriously taken.
> 
> LilyPond is not static, but it should not really change in terms of
> its 
> defaults either. Much like TeX, we should not change the default
> fonts, 
> in my opinion (though of course Emmentaler and Feta are being
> expanded 
> as new features are added to LilyPond, and slight tweaks and 
> improvements are all well and good).
> 
> On 6/25/20 3:06 AM, Martin Tarenskeen wrote:
> > 
> > On Thu, 25 Jun 2020, Daniel Benjamin Miller wrote:
> > 
> > > I'd like to share something: 
> > > https://github.com/dbenjaminmiller/bmusicfonts
> > > I personally prefer the Bravura design to Emmentaler/Feta, and 
> > > there'd been
> > 
> > Thanks for this, I am going to try it for sure. I like Dorico's 
> > output, and this will sort of give a similar result for LilyPond if
> > I 
> > understand correctly?
> > 
> > Which leads to a more philosophic question. Do we want LilyPond
> > scores 
> > to have an immediately recognizable "personality" or are we slowly 
> > moving to a situation where everyone, including LilyPond, is trying
> > to 
> > look the same (when using default settings), and it will be hard
> > to 
> > see if a score was typeset in LilyPond, MuseScore, Dorico, Finale,
> > or 
> > Sibelius?
> > 
> > I hope LilyPond will always try to keep a distinct personality in
> > the 
> > default output, which is not a static thing but can be discussed
> > in 
> > the Lilypond user and developers community, changed, and improved 
> > continuously. But let not all our efforts go to looking as much as 
> > possible like "the other ones".
> > 
> > I know LilyPond is (almost) flexible and tweakable enough to have
> > it 
> > all, but what I am talking about is the default output.
> > 

Re: Snippet "Clef change and repeat barline"

[Pierre Perol-Schneider]

Hi Harm,

Le mer. 24 juin 2020 à 23:26, Thomas Morley  a
écrit :

> To the author of said snippet.
> lsr.di.unimi.it/LSR/Item?u=1=1110
>
> I will not approve it in it's current state.
>

Ok.

This sounds like default LilyPond being wrong in this regard. If so,
> it's a bug, needed to be reported, probably discussed and finally
> fixed.
>

Ok, will do.


> Tbh, I don't think LilyPond is wrong. Ofcourse I'd could be proven wrong.
>

See: E. Gould/ Behind bars (ed. 2011, pp. 234-235)
(and:
http://lilypond-french-users.1298960.n2.nabble.com/Clef-apres-signe-de-reprise-td7589673.html
)

Cheers,
Pierre

Re: Single bass notes in chordmode

[Henning Hraban Ramm]

> Am 24.06.2020 um 16:07 schrieb Henning Hraban Ramm :
> 
> 
>> Am 24.06.2020 um 15:01 schrieb David Kastrup :
>> 
>> Henning Hraban Ramm  writes:
>> 
>>> In some of my songbooks, the chord line (for guitar) is interrupted by
>>> single bass notes, i.e. you are supposed to play only these strings.
>>> 
>>> The notation is mostly a smallcaps letter with a bar above (or a small
>>> x below), but a simple /G would be enough if it isn’t possible
>>> otherwise.
>>> 
>>> And I’d like to have that bass note also in MIDI output.
>>> 
>>> Is this possible, and how?
>>> 
>>> Preferred syntax: r/g or s/g
>> 
>> Try  .  You'll still need to fiddle with the chord naming function.
> 
> Ah, thanks for the hint.
> 
> I found a snippet to add brackets to a chord:
> ...
> 
> Now, how can I use markup like \tiny or \circle within that (markup ...) ?

Ok, I found
http://lilypond.org/doc/v2.20/Documentation/extending/markup-construction-in-scheme

That lead me to:

#(define (bassNote grob)
   "mark chord as single bass note"
   (let* (
  ; Get current text
  (currentText (ly:grob-property grob 'text))
  (markedText (markup #:small #:fraction "" currentText )))
 ; Store the marked text back
 (ly:grob-set-property! grob 'text markedText)
 )
   ; and print it
   (ly:text-interface::print grob))

% bnC = bass note "chord"
bnC = \once \override ChordNames.ChordName.stencil = #bassNote

Now my syntax is: \bnC 4 \bnC 

A bit verbose, but since I need it only for a few songs, it’s good enough.


Hraban

Re: Better support for Bravura in LilyPond

[Daniel Benjamin Miller]

You're right, it does essentially replicate Dorico's style.

I don't think LilyPond should change what its default style is; I don't 
like the Emmentaler font myself (Simon Tatham put it best, though I 
actually feel the same about Gonville: 
https://www.chiark.greenend.org.uk/~sgtatham/gonville/ - "I designed it 
because Lilypond's standard font (Feta) was not to my taste: I found it 
to be (variously) over-ornate, strangely proportioned, and subtly not 
like the music I was used to reading. Music set in Feta looks to me like 
strangely stylised music; music set in Gonville just looks to me like 
music, so I can read it without being distracted so much.)


But I also think that we should not try to change the defaults. But I 
also think that almost nobody actually cares much about music 
typography, really: only LilyPond and Dorico have really put effort into 
creating their default fonts and appearances; MuseScore borrows its 
fonts from both, and Finale and Sibelius' fonts are really clearly not 
that seriously taken.


LilyPond is not static, but it should not really change in terms of its 
defaults either. Much like TeX, we should not change the default fonts, 
in my opinion (though of course Emmentaler and Feta are being expanded 
as new features are added to LilyPond, and slight tweaks and 
improvements are all well and good).


On 6/25/20 3:06 AM, Martin Tarenskeen wrote:



On Thu, 25 Jun 2020, Daniel Benjamin Miller wrote:

I'd like to share something: 
https://github.com/dbenjaminmiller/bmusicfonts
I personally prefer the Bravura design to Emmentaler/Feta, and 
there'd been


Thanks for this, I am going to try it for sure. I like Dorico's 
output, and this will sort of give a similar result for LilyPond if I 
understand correctly?


Which leads to a more philosophic question. Do we want LilyPond scores 
to have an immediately recognizable "personality" or are we slowly 
moving to a situation where everyone, including LilyPond, is trying to 
look the same (when using default settings), and it will be hard to 
see if a score was typeset in LilyPond, MuseScore, Dorico, Finale, or 
Sibelius?


I hope LilyPond will always try to keep a distinct personality in the 
default output, which is not a static thing but can be discussed in 
the Lilypond user and developers community, changed, and improved 
continuously. But let not all our efforts go to looking as much as 
possible like "the other ones".


I know LilyPond is (almost) flexible and tweakable enough to have it 
all, but what I am talking about is the default output.