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

2020-06-27 Thread Paolo Prete
On Sat, Jun 27, 2020 at 4:33 PM Carl Sorensen  wrote:

> Type:Defect means that LilyPond intends to do something, but does it wrong.
>
>
>
> Type:Enhancement means that the capability of LilyPond would expanded to
> cover things it currently doesn’t cover.
>
>
>
> In this case, LilyPond does not intend to present pedal bracket
> cautionaries, so it’s not a defect.
>
>
>

This crearly shows, IMHO, that another Type::xxx  should be added, in
general.
I would call it: Type::CommonPractice or something similar.

Which doesn't show a bug, nor a required enhancement, but highlights what
Lilypond can't do for an implemented feature compared to the common
practice of the engravers.

For example, a tuplet without the optional bracket support would fall in
that case.

I'll list some of these cases in the next few days.


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

2020-06-27 Thread Carl Sorensen
Type:Defect means that LilyPond intends to do something, but does it wrong.

Type:Enhancement means that the capability of LilyPond would expanded to cover 
things it currently doesn’t cover.

In this case, LilyPond does not intend to present pedal bracket cautionaries, 
so it’s not a defect.

If LilyPond had pedal bracket cautionaries and it put una corda cautionaries on 
a sostenuto bracket, it would be a defect.

Adding pedal bracket cautionaries (and changing pedal indications to 
textSpanners) would constitute an enhancement, according to the LilyPond 
nomenclature.

It may be that the particular type of score you wish to print is defective when 
LilyPond creates it (I’m not arguing that), but LilyPond doesn’t claim to print 
that type of score, so from the LilyPond point of view, LilyPond’s output is 
not defective, it’s just limited.

Type:Defect would have a generated output that is different from the intended 
output.  In this case the generated output is nothing, and the intended output 
is nothing, so there is no difference.

Thanks,

Carl


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

2020-06-27 Thread David Rogers



I should point out my own mistake: Breitkopf & Härtel did a great 
deal of very good work, and (from a pianist's point of view 
anyway) they don't belong in the same paragraph as PWM or Kalmus.


--
David Rogers



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

2020-06-27 Thread David Rogers

"Mark Stephen Mrotek"  writes:


Paolo,

 


A quick examination of pieces in my collection showed that the
following editions did not use brackets for the pedal, rather 
Ped. *

was used.

Paragon, Fryderyka Chopin Institute, Breitkopf & Hartel, and 
Edwin F.

Kalmus.


Unfortunately for the current discussion, these are (by Lilypond's 
own standards) some of the truly run-of-the-mill publishers, if 
they manage to achieve even that standard. That edition of Chopin 
does carry the name of a former celebrity on the cover, it's true; 
he may have been an excellent man (I can't say), but his 
music-publishing efforts were second-rate at best. (It's clear he 
was only lending his name for the celebrity cachet anyway; all the 
PWM Chopin books have the decency to name the real editors at 
least, and Paderewski wasn't among them.) Bad editing, bad 
printing, substandard paper, brittle glue that only holds the book 
together long enough to get it home... well, you can't say they 
were inconsistent. :)


I guess my position as a pianist is that while Paolo seems to be 
mistaken about software politics, musically he's correct. There's 
no musical justification for claiming that Lilypond's sloppy and 
inconsistent handling of piano pedalling is acceptable. (There's 
also no social/political justification for claiming that that fact 
obliges any particular person or group to fix it at any particular 
time.)


--
David Rogers



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

2020-06-26 Thread Paolo Prete
On Sat, Jun 27, 2020 at 2:25 AM David Rogers 
wrote:

> Paolo Prete  writes:
>
> > 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
>
> Certainly you're right that it's an "enhancement" only in a
> self-referential context. But that was already the meaning of
> Jean's message; when you decide to use *any* complex software
> that's developed by volunteers, you must accept that this same
> self-referential point of view is going to prevail. It's just part
> of the way humans are. The main exception is when someone is
> bothered by an irritating defect that he cares about, in some
> software that he cares about; he refuses to accept that the
> situation might stay this way, and finally he gets so impatient or
> angry that he learns the necessary programming language and fixes
> the problem himself. (Who knows? That example might be you!)
>

I understand what you write.
But, as said before, doing the hack "fake pedal with a sustain spanner +
hidden real pedal" solves all for me.
I already have accepted that the situation will stay in this way, and this
is absolutely no problem for me. Really.
I have worked on open source projects since so many years that I consider
even too much what we already have with Lilypond.

Best,
P


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

2020-06-26 Thread Paolo Prete
On Sat, Jun 27, 2020 at 1:29 AM Mark Stephen Mrotek 
wrote:

> Paolo,
>
>
>
> A quick examination of pieces in my collection showed that the following
> editions did not use brackets for the pedal, rather Ped. * was used.
>
> Paragon, Fryderyka Chopin Institute, Breitkopf & Hartel, and Edwin F.
> Kalmus.
>
>
>
> Mark
>
>
>


Hi Mark,

this is expected. The pedal bracket is a relatively recent practice in
music engraving, and the "/\"  is even newer (I suspect this last one is a
standard "de facto" after Finale or Sibelius).
Then a research is not easy, because it has to focus on the last, let's
say, 20 years.
I don't know exactly the state of the art of it. It could be that it is not
so wanted if you use only one pedal (but IMHO it would be bad to see as
well, because all the other spanners normally have a cautionary string)
But as soon as you use different pedals (sostenuto or una corda),
regardless if you use one or multiple spanners at the same time, I would
really be surprised to see no cautionary.

Best,
P


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

2020-06-26 Thread David Rogers

Paolo Prete  writes:

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


Certainly you're right that it's an "enhancement" only in a 
self-referential context. But that was already the meaning of 
Jean's message; when you decide to use *any* complex software 
that's developed by volunteers, you must accept that this same 
self-referential point of view is going to prevail. It's just part 
of the way humans are. The main exception is when someone is 
bothered by an irritating defect that he cares about, in some 
software that he cares about; he refuses to accept that the 
situation might stay this way, and finally he gets so impatient or 
angry that he learns the necessary programming language and fixes 
the problem himself. (Who knows? That example might be you!)


There's an old joke: When free software is defective, the users 
are entitled to a full refund. :)


--
David Rogers



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

2020-06-26 Thread Mark Stephen Mrotek
Paolo,

 

A quick examination of pieces in my collection showed that the following 
editions did not use brackets for the pedal, rather Ped. * was used.

Paragon, Fryderyka Chopin Institute, Breitkopf & Hartel, and Edwin F. Kalmus. 

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of Paolo PreteykaSent: Thursday, June 25, 2020 2:17 PM
To: Flaming Hakama by Elaine 
Cc: Lilypond-User Mailing List 
Subject: Re: Pedal cautionary after a line break (current status and 
improvements)

 

 

 

 

 



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 <mailto:ela...@flaminghakama.com> 

 



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

2020-06-26 Thread Paolo Prete
On Fri, Jun 26, 2020 at 10:35 AM Valentin Villenave 
wrote:

> On 6/25/20, Paolo Prete  wrote:
> > 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)
>
> Greetings Paolo,
> determining whether this issue is a “Defect” or an “Enhancement” is
> largely inconsequential; as Jean said (and we should be thankful to
> him for opening a tracker page on your behalf, by the way), that does
> not imply a different priority.
>
> That being said, can you please document your claims? As a pianist
> myself (and although I did specialize in contemporary music), I can’t
> remember _any_ score where I’ve seen a pedal reminder after a system
> break, off the top of my head. But that’s just me.
>
>

Hi Valentine,

as I said before, I can't document my claim, of course. Therefore I asked
for feedback.
I said to Kieren that "I am not aware of [professional] scores that do not
use it" (a bracket without a cautionary string), then I asked for examples,
which would be useful for me.
And then I added, in another post (I quote myself):

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

Here is what I also wrote:

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

That's all. The pedal bracket is a relatively recent practice. I'm
convinced that not writing a cautionary string would be a really bad
practice in *any* professional score, for many reasons, for any spanner.
But the fact that I consider it a bad practice (and I add: a really bad
one) has nothing to do with the urgency of fixing the issue. This urgency
can be evaluated with a sort of average on the modern scores.

Hope this clarifies.

Best,

P




>


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

2020-06-26 Thread Valentin Villenave
On 6/25/20, Paolo Prete  wrote:
> 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)

Greetings Paolo,
determining whether this issue is a “Defect” or an “Enhancement” is
largely inconsequential; as Jean said (and we should be thankful to
him for opening a tracker page on your behalf, by the way), that does
not imply a different priority.

That being said, can you please document your claims? As a pianist
myself (and although I did specialize in contemporary music), I can’t
remember _any_ score where I’ve seen a pedal reminder after a system
break, off the top of my head. But that’s just me.

As you correctly point out, LilyPond’s aim of producing high-quality
music scores closely tracks what well-established engravers do;
obviously we’ve been mainly following 19th-century engraving practices
though, and pedal brackets have evolved a *lot* since then -- though
I’m not sure it could be argued that any “standard” pedal notation has
emerged in the past 70 years.

If you can provide us with (scanned) examples of several mainstream
editions that use these reminders, then indeed either Jean or I will
add these to the GitLab page, and relabel it as a Defect rather than
an Enhancement. As Jean said, this will be a crucial first step
towards implementing that feature (and, to begin with, acknowledging
that it is objectively something LilyPond needs).

Cheers,
-- V.



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

2020-06-25 Thread 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: Pedal cautionary after a line break (current status and improvements)

2020-06-25 Thread 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: Pedal cautionary after a line break (current status and improvements)

2020-06-25 Thread 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: Pedal cautionary after a line break (current status and improvements)

2020-06-25 Thread 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: Pedal cautionary after a line break (current status and improvements)

2020-06-25 Thread 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


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

2020-06-25 Thread 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



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

2020-06-24 Thread Paolo Prete
On Wed, Jun 24, 2020 at 10:53 PM Thomas Morley 
wrote:

> Am Di., 23. Juni 2020 um 20:33 Uhr schrieb Paolo Prete <
> paolopr...@gmail.com>:
> >
> > On Tue, Jun 23, 2020 at 6:36 PM Pierre Perol-Schneider
> > A this point:
> >
> > 1) I gently ask Harm (is Harm the snippet's maintainer ? ) to update the
> > snippet at least by adding a warning (--> something like "no midi is
> > produced")
>
> Hi Paolo,
>
> I'm not the admin of the LSR, though, among others I've the
> privilegies to (un)approve, change, delete snippets.
> That said, you may ask the snippet-author to add such a warning.
> The LSR is a user-driven possibility to extend LilyPond by
> custom-code. This also means the author of a snippet is responsible
> for his code.
> If not available _then_ people like me will step in.
>
> At any rate, the snippets clearly states "This workaround uses
> TextSpanner instead of SustainPedal/PianoPedalBracket."
> A TextSpanner never creates midi-output, thus the warning is not needed,
> imho.
>
>
Hi Harm,

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

Best,
P


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

2020-06-24 Thread Thomas Morley
Am Di., 23. Juni 2020 um 20:33 Uhr schrieb Paolo Prete :
>
> On Tue, Jun 23, 2020 at 6:36 PM Pierre Perol-Schneider
> A this point:
>
> 1) I gently ask Harm (is Harm the snippet's maintainer ? ) to update the
> snippet at least by adding a warning (--> something like "no midi is
> produced")

Hi Paolo,

I'm not the admin of the LSR, though, among others I've the
privilegies to (un)approve, change, delete snippets.
That said, you may ask the snippet-author to add such a warning.
The LSR is a user-driven possibility to extend LilyPond by
custom-code. This also means the author of a snippet is responsible
for his code.
If not available _then_ people like me will step in.

At any rate, the snippets clearly states "This workaround uses
TextSpanner instead of SustainPedal/PianoPedalBracket."
A TextSpanner never creates midi-output, thus the warning is not needed, imho.

Cheers,
  Harm



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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 10:26 PM Carl Sorensen 
wrote:

> On Tue, Jun 23, 2020 at 2:18 PM Paolo Prete  wrote:
>
>

> >
> > (Also in response to Carl)
> > In Italy, we call this approach "fare la morale".
> > C's answer made P's words look like:
> >
> > "Hey, please develop this for me." And the answer was, more or less
> (---> do the moral):
> > "If you want it to develop, collect the money."
> >
>
> I'm sorry I gave that impression.  I did not intend to do so.
>
>
>
No problem.



> >
>
> I must have misinterpreted your words.  I considered your words to say
> that if nobody responded to your post, the thread would be wasted.
>
> I don't believe anybody that I'm aware of right now is likely to jump
> on changing pedals from TextScript to TextSpanner, so I don't think
> anything is likely to come from your request in the near future.  I
> was merely trying to keep you from being disappointed when nobody took
> up the issue.
>
>
Now I see the issue.
I thought that overriding the function was trivial for the developer of
that part, then I wrote my memo.
Your words prevent me too to analyze/hack the chain of overrides, it would
be too long.
At the current state, then, I don't see at the moment any better solution
than Pierre's one, having care to include a hidden pedal so to not corrupt
the midi
(again: I gently ask Harm if he can add a two-words-warning to the snippet,
so that other users won't have a surprise)


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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 10:32 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Paolo,
>
> > I don't understand what you mean exactly, in the choral pieces.
>
> A cappella choral pieces don’t include piano music, and therefore don’t
> include any piano pedal markings, and therefore don’t use or need the
> feature you’re describing — therefore, they are one of the [uncountable!]
> number of scores that are counterexamples to your claim that this feature
> is "an essential feature for any score".
>
>

Hi Kieren,

This observation is pleonastic. When I wrote "any score" I intended the
context of the thread (cuationary pedals on brackets). Words must always be
interpreted on the basis of what the context suggests.


>
> I would estimate that I see cautionary markings in less than 50% of the
> [professional, published] scores in which the only pedal used is the
> sustain pedal. And of course, if no pedal brackets are used (e.g., if the
> piece simply states "Ped ad lib." or something similar), the feature you
> describe is again unnecessary/unessential.
>
>
Of course the thread was about a cautionary pedal on a bracket, as the
snippets show, and I am not aware of scores that do not use it. Could you
point out some of them? (In any case it would be a *really* bad editorial
practice)

Best,

P


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

2020-06-23 Thread Kieren MacMillan
Hi Paolo,

> I don't understand what you mean exactly, in the choral pieces.

A cappella choral pieces don’t include piano music, and therefore don’t include 
any piano pedal markings, and therefore don’t use or need the feature you’re 
describing — therefore, they are one of the [uncountable!] number of scores 
that are counterexamples to your claim that this feature is "an essential 
feature for any score".

> But be sure that for any keyboard piece, not having the cautionary pedal 
> makes the score unpresentable, and not only when there are multiple spanners.

I would estimate that I see cautionary markings in less than 50% of the 
[professional, published] scores in which the only pedal used is the sustain 
pedal. And of course, if no pedal brackets are used (e.g., if the piece simply 
states "Ped ad lib." or something similar), the feature you describe is again 
unnecessary/unessential.

Summary: I’m pointing out that you are making sweeping generalizations that are 
easily disproven. The strength of your request/argument is likely not 
well-served by over-exaggeration. Simply state the [true and scope-limited] use 
case, and move on.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info




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

2020-06-23 Thread Carl Sorensen
On Tue, Jun 23, 2020 at 2:18 PM Paolo Prete  wrote:

>
>
>
> (Also in response to Carl)
> In Italy, we call this approach "fare la morale".
> C's answer made P's words look like:
>
> "Hey, please develop this for me." And the answer was, more or less (---> do 
> the moral):
> "If you want it to develop, collect the money."
>

I'm sorry I gave that impression.  I did not intend to do so.

In fact, your collecting money would have no affect on my desire to
work on this issue.

> This is absolutely the opposite of my intentions.
> Instead, I pointed out that the lack of a cautionary pedal is not simply 
> something that can be improved. And I have no problem using ugly workaround 
> to solve it (I'm in control of my code).
> Instead, it is a general problem that makes the pedal ** unusable *** in any 
> professional score.
> And it's not a problem for me, but it's a problem especially for novice users.
>
> In any case, I reported the problem to the developers. Just as I reported to 
> Harm that there is an error on the snippet's Midi.
> They will decide what to do, according to the time they can or want to 
> dedicate to the thing.
>

I must have misinterpreted your words.  I considered your words to say
that if nobody responded to your post, the thread would be wasted.

I don't believe anybody that I'm aware of right now is likely to jump
on changing pedals from TextScript to TextSpanner, so I don't think
anything is likely to come from your request in the near future.  I
was merely trying to keep you from being disappointed when nobody took
up the issue.

Again, I am sorry for sounding harsh and polemical.  I certainly did
not intend to.

Carl



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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 10:13 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Paolo,
>
> > This issue is not *important for me*. It is an *essential* feature for
> any score.
>
> At best, one could argue that it‘s "an essential feature" for any score
> with multiple pedal spanners [of different types] that cross line breaks.
> It’s demonstrably false that it’s "an essential feature" for any score —
> any a cappella choir piece is a counterexample to the claim.
>
> Therefore, it’s effectively not important to anyone who doesn’t engrave
> keyboard music with multiple pedal spanners [of different types] that cross
> line breaks.
>
>
Hi Kieren,

I don't understand what you mean exactly, in the choral pieces.
But be sure that for any keyboard piece, not having the cautionary pedal
makes the score unpresentable, and not only when there are multiple
spanners.

 Cheers,

P


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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 9:53 PM Jean Abou Samra  wrote:

> Paolo,
>
>
> I really think Carl did not intend to be harsh. He even explicitely tried
> to
> avoid making you taking it as an offence:
>
> > I'm trying not to be mean in this answer, but to explain the way
> > LilyPond development works.
>
> It is a confusion in my eyes. Look,
> > If you really want this worked on, here are a few ideas:
> Carl told you what you needed in the gentlest possible way. Written
> communication tends to be ambiguous, but I assure you, Carl is
> really not the kind of person that could reply brutally.
>
> Best,
> Jean
>


(Also in response to Carl)
In Italy, we call this approach "fare la morale".
C's answer made P's words look like:

"Hey, please develop this for me." And the answer was, more or less (--->
do the moral):
"If you want it to develop, collect the money."

This is absolutely the opposite of my intentions.
Instead, I pointed out that the lack of a cautionary pedal is not simply
something that can be improved. And I have no problem using ugly workaround
to solve it (I'm in control of my code).
Instead, it is a general problem that makes the pedal ** unusable *** in
any professional score.
And it's not a problem for me, but it's a problem especially for novice
users.

In any case, I reported the problem to the developers. Just as I reported
to Harm that there is an error on the snippet's Midi.
They will decide what to do, according to the time they can or want to
dedicate to the thing.


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

2020-06-23 Thread Carl Sorensen
On Tue, Jun 23, 2020 at 1:32 PM Paolo Prete  wrote:
>
>
>
> On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen  
> wrote:
>>
>> Paolo,
>>
>> On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete  wrote:
>> >
>>
>> >
>> > 2) Considering that a Pedal cautionary is *essential* in *every* serious
>> > score, I really encourage the developers to fix this in the development
>> > branch. I forward this post to the devel ml.
>>
>> There is no way to "encourage the developers to fix this".  The
>> developers are all volunteers, and work on what they find interesting.
>>
>
> [CUT.]
>  I don't agree at all.
> Please don't use harsh words without a reason.
> I know the workflow of open source projects very well. For years and as an 
> active volunteer.
> What I meant with "encouraging" is simply: "consider that a cautionary pedal 
> is *essential* for  *any* professional score".
> This simply means that the fact that a cautionary pedal is essential may have 
> simply been left out casually, and consequently I find it useful to remember 
> it.
>
> Of course then it will be the reader's decision to consider what I write.
>
> If it is taken into consideration, I will be happy.
>
> If it is not taken into consideration, it is okay as well, and I will find an 
> alternative solution.
>
> Again: please, stop using harsh/polemic words without a reason.

I'm sorry my words sounded harsh/polemic to you.  I didn't intend them that way.

Please help me understand how my words were harsh or polemic, so I can
do better in the future.

Thanks,

Carl



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

2020-06-23 Thread Kieren MacMillan
Hi Paolo,

> This issue is not *important for me*. It is an *essential* feature for any 
> score.

At best, one could argue that it‘s "an essential feature" for any score with 
multiple pedal spanners [of different types] that cross line breaks. It’s 
demonstrably false that it’s "an essential feature" for any score — any a 
cappella choir piece is a counterexample to the claim.

Therefore, it’s effectively not important to anyone who doesn’t engrave 
keyboard music with multiple pedal spanners [of different types] that cross 
line breaks.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info




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

2020-06-23 Thread Jean Abou Samra

Paolo,

Le 23/06/2020 à 21:32, Paolo Prete a écrit :

On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen 
wrote:


Paolo,

On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete  wrote:


2) Considering that a Pedal cautionary is *essential* in *every* serious
score, I really encourage the developers to fix this in the development
branch. I forward this post to the devel ml.

There is no way to "encourage the developers to fix this".  The
developers are all volunteers, and work on what they find interesting.



[CUT.]
  I don't agree at all.
Please don't use harsh words without a reason.
I know the workflow of open source projects very well. For years and as an
active volunteer.
What I meant with "encouraging" is simply: "consider that a cautionary
pedal is *essential* for  *any* professional score".
This simply means that the fact that a cautionary pedal is essential may
have simply been left out casually, and consequently I find it useful to
remember it.

Of course then it will be the reader's decision to consider what I write.

If it is taken into consideration, I will be happy.

If it is not taken into consideration, it is okay as well, and I will find
an alternative solution.

Again: please, stop using harsh/polemic words without a reason.


I really think Carl did not intend to be harsh. He even explicitely tried to
avoid making you taking it as an offence:


I'm trying not to be mean in this answer, but to explain the way
LilyPond development works.


It is a confusion in my eyes. Look,

If you really want this worked on, here are a few ideas:

Carl told you what you needed in the gentlest possible way. Written
communication tends to be ambiguous, but I assure you, Carl is
really not the kind of person that could reply brutally.

Best,
Jean



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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 9:32 PM Jean Abou Samra  wrote:

> Hi Paolo,
>
> Le 23/06/2020 à 21:09, Carl Sorensen a écrit :
> > Paolo,
> >
> > On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete 
> wrote:
> >> 2) Considering that a Pedal cautionary is *essential* in *every* serious
> >> score, I really encourage the developers to fix this in the development
> >> branch. I forward this post to the devel ml.
> > There is no way to "encourage the developers to fix this".  The
> > developers are all volunteers, and work on what they find interesting.
> >
> > If you really want this worked on, here are a few ideas:
> >
> > 1) Ask if there are any developers who are willing to do it as work
> > for hire.  And then either pay the developer or try to get together a
> > group of users to collectively pay the developer.
> >
> > 2) Learn about LilyPond development and provide your own patch.  This
> > is one of the benefits of open source projects.  You can "scratch your
> > own itch".
> >
> > 3) Try to find somebody else who might make the change, either out of
> > interest or for money.  For example, you might find a computer science
> > student at a local school who is interested in music.
> I think filling an issue on https://gitlab.com/lilypond/lilypond/
> (with Type::Enhancement) would be a good starting point.This will
> sort-of officialize that this feature is desired and create a place
> to discuss it. Then, if that issue is really important to you,
>


This issue is not *important for me*. It is an *essential* feature for any
score.
If it won't be implemented, then I'll find a way to fix it on myself (and
then share the result, as I always did).

Best,
P



>


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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen 
wrote:

> Paolo,
>
> On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete  wrote:
> >
>
> >
> > 2) Considering that a Pedal cautionary is *essential* in *every* serious
> > score, I really encourage the developers to fix this in the development
> > branch. I forward this post to the devel ml.
>
> There is no way to "encourage the developers to fix this".  The
> developers are all volunteers, and work on what they find interesting.
>
>
[CUT.]
 I don't agree at all.
Please don't use harsh words without a reason.
I know the workflow of open source projects very well. For years and as an
active volunteer.
What I meant with "encouraging" is simply: "consider that a cautionary
pedal is *essential* for  *any* professional score".
This simply means that the fact that a cautionary pedal is essential may
have simply been left out casually, and consequently I find it useful to
remember it.

Of course then it will be the reader's decision to consider what I write.

If it is taken into consideration, I will be happy.

If it is not taken into consideration, it is okay as well, and I will find
an alternative solution.

Again: please, stop using harsh/polemic words without a reason.

P


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

2020-06-23 Thread Jean Abou Samra

Hi Paolo,

Le 23/06/2020 à 21:09, Carl Sorensen a écrit :

Paolo,

On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete  wrote:

2) Considering that a Pedal cautionary is *essential* in *every* serious
score, I really encourage the developers to fix this in the development
branch. I forward this post to the devel ml.

There is no way to "encourage the developers to fix this".  The
developers are all volunteers, and work on what they find interesting.

If you really want this worked on, here are a few ideas:

1) Ask if there are any developers who are willing to do it as work
for hire.  And then either pay the developer or try to get together a
group of users to collectively pay the developer.

2) Learn about LilyPond development and provide your own patch.  This
is one of the benefits of open source projects.  You can "scratch your
own itch".

3) Try to find somebody else who might make the change, either out of
interest or for money.  For example, you might find a computer science
student at a local school who is interested in music.

I think filling an issue on https://gitlab.com/lilypond/lilypond/
(with Type::Enhancement) would be a good starting point.This will
sort-of officialize that this feature is desired and create a place
to discuss it. Then, if that issue is really important to you,
you may want to dive into the code for SustainPedal and try to figure 
out how to

add a boolean property to switch on parentheses on cautionary pedal signs.
--Or, even better, make pedals spanners, which will solve other issues 
along the
way (e.g., to-barline setting).-- You will certainly get help if you ask 
questions
on the issue. But in order to make something implemented, you generally 
need to invest

resources yourself (that is, energy or, if you want, money).

Best,
Jean




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

2020-06-23 Thread Carl Sorensen
Paolo,

On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete  wrote:
>

>
> 2) Considering that a Pedal cautionary is *essential* in *every* serious
> score, I really encourage the developers to fix this in the development
> branch. I forward this post to the devel ml.

There is no way to "encourage the developers to fix this".  The
developers are all volunteers, and work on what they find interesting.

If you really want this worked on, here are a few ideas:

1) Ask if there are any developers who are willing to do it as work
for hire.  And then either pay the developer or try to get together a
group of users to collectively pay the developer.

2) Learn about LilyPond development and provide your own patch.  This
is one of the benefits of open source projects.  You can "scratch your
own itch".

3) Try to find somebody else who might make the change, either out of
interest or for money.  For example, you might find a computer science
student at a local school who is interested in music.

Repeatedly asking for this functionality to be provided on the devel
list is not likely to get anything done, and in fact may turn off some
developers.

I'm trying not to be mean in this answer, but to explain the way
LilyPond development works.  There is nobody who controls what is to
be worked on next -- every developer chooses for themselves what they
will do.

Thanks,

Carl



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

2020-06-23 Thread Kieren MacMillan
Hi Paolo,

> Maybe a better approach is a fake pedal with the TextSpanner interface that 
> implements the cautionary markup and which overlays a hidden pedal.

No… as I said in a previous thread, overloading TextSpanner to do what a pedal 
spanner should do isn’t the best choice.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info




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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 6:36 PM Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Hi Paolo,
> See: http://lsr.di.unimi.it/LSR/Item?id=1023
> Cheers,
> PIerre
>
>

Hi Pierre,

I already saw your workaround but, as said in the previous email, it has
unwanted side effects.
The first one is that no pedal is produced in the midi file. The second one
is that the SustainPedal API is skipped, and this leads to messy code.
A hidden *real* sustain pedal could be added to your functions (so that the
midi file includes it), but this would lead to more huge and messy code.

A this point:

1) I gently ask Harm (is Harm the snippet's maintainer ? ) to update the
snippet at least by adding a warning (--> something like "no midi is
produced")

2) Considering that a Pedal cautionary is *essential* in *every* serious
score, I really encourage the developers to fix this in the development
branch. I forward this post to the devel ml.

Hope this thread will not be wasted and hope to obtain feedback.

Thank you all!

Best,
P


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

2020-06-23 Thread Pierre Perol-Schneider
Hi Paolo,
See: http://lsr.di.unimi.it/LSR/Item?id=1023
Cheers,
PIerre

Le mar. 23 juin 2020 à 17:25, Paolo Prete  a écrit :

>
>
> On Tue, Jun 23, 2020 at 3:47 PM Kieren MacMillan <
> kieren_macmil...@sympatico.ca> wrote:
>
>> Hi Paolo,
>>
>> > It is very important, IMHO, to have a sustain pedal cautionary after a
>> line break.
>>
>> Did you look at the LSR?
>> 
>>
>> Does that not do what you need?
>>
>> Cheers,
>> Kieren.
>> __
>
>
> Hi Kieren,
>
> Yes, I already looked at it, but as said in the previous email, this is
> not good IMHO because it breaks the common syntax for spanners
> (\startSpanner , \endSpanner ), which is much more easy and clean.
> When there is more than one pedal, it is even worse.
> Maybe a better approach is a fake pedal with the TextSpanner interface
> that implements the cautionary markup and which overlays a hidden pedal.
> But I would like to have some feedback about this, so I can avoid possible
> side effects.
>
> Best,
> P
>
>
>
>
>
>
>
>
>
>> __
>>
>> Kieren MacMillan, composer (he/him/his)
>> ‣ website: www.kierenmacmillan.info
>> ‣ email: i...@kierenmacmillan.info
>>
>>


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

2020-06-23 Thread Paolo Prete
On Tue, Jun 23, 2020 at 3:47 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Paolo,
>
> > It is very important, IMHO, to have a sustain pedal cautionary after a
> line break.
>
> Did you look at the LSR?
> 
>
> Does that not do what you need?
>
> Cheers,
> Kieren.
> __


Hi Kieren,

Yes, I already looked at it, but as said in the previous email, this is not
good IMHO because it breaks the common syntax for spanners (\startSpanner ,
\endSpanner ), which is much more easy and clean.
When there is more than one pedal, it is even worse.
Maybe a better approach is a fake pedal with the TextSpanner interface that
implements the cautionary markup and which overlays a hidden pedal.
But I would like to have some feedback about this, so I can avoid possible
side effects.

Best,
P









> __
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>


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

2020-06-23 Thread Kieren MacMillan
Hi Paolo,

> It is very important, IMHO, to have a sustain pedal cautionary after a line 
> break.

Did you look at the LSR?


Does that not do what you need?

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info




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

2020-06-14 Thread Paolo Prete
Hello,

It is very important, IMHO, to have a sustain pedal cautionary after a line
break.
Otherwise, when we use two simultaneous pedal brackets the music becomes
absolutely unreadable.

Looking at this thread:
http://lilypond.1069038.n5.nabble.com/Sustain-pedal-cautionary-after-line-break-td186551.html

1) can you tell me if the feature has been implemented since then (the
thread is dated 2016)?

2) Kieren's solution seems the best one to me, because it preserves the
lilypond syntax for the pedal functions. However, is there a way to alert
the user if there is a line break during a pedal?
In this way I can be pretty sure I won't forget to add Kieren's tweak at
this break. Otherwise, it's very easy to mess up the score, because you
have to check *all* the pedals manually, which is strongly error-prone,
especially when the systems are modified. A better approach would be to
warn the user if there is a break during a pedal AND there's not a
cautionary text at that point.
Any other suggestion is *really* welcome
Thanks very much for your help.

P