Re: [LSR 2.20] what to do with #280

[Torsten Hämmerle]

Hi Harm,

It's the New_fingering_engraver!
It will also activate the Script_engraver, that's why the scripts are there
from the beginning in newer LilyPond versions, even before explicitly adding
the Scrip_engraver.  And as long as there are no stems, you get the "script
direction not yet known" messages.


*Remedy 1:*
Remove 
  \consists "New_fingering_engraver"
from the initial MyVoice definition.


Another thing is the localKeySignature translation-type property check
warning.

*Remedy 2:*
localKeySignature is obsolete now and can be junked.

After these adaptions, the snippet will run as it should without complaining
in recent LilyPond versions..

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: [LSR 2.20] what to do with #280

[Valentin Villenave]

On 3/14/20, Thomas Morley  wrote:
> Currently
> "Engravers one-by-one"
> http://lsr.di.unimi.it/LSR/Item?id=280
> returns several times:
> programming error: script direction not yet known
> What to do?

Would it be a good idea to add
  \override Script.direction = #UP
in the definition of MyVoice?
This removes the progerror and has no visible effect on the output.
(Granted, it does depart from engraver-init.ly though, contrary to the
stated purpose of the snippet.)

That’s not the only question with that snippet; there are several
unused variables, and a puzzling "Guru-only" comment. (Well, puzzling
to me at least.) I’m not entirely sure why all this shouldn’t be
thrown away.

Cheers,
V.

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

[hanwenn]

https://codereview.appspot.com/553700043/diff/555460043/mf/invoke-mf2pt.sh
File mf/invoke-mf2pt.sh (right):

https://codereview.appspot.com/553700043/diff/555460043/mf/invoke-mf2pt.sh#newcode18
mf/invoke-mf2pt.sh:18: # which no longer dump a .mem file
On 2020/03/16 06:16:22, lemzwerg wrote:
> We could probably get rid of the .mem file support, which is obsolete
since
> about 10 years.

sure. Followup change?

https://codereview.appspot.com/553700043/diff/555460043/mf/invoke-mf2pt.sh#newcode31
mf/invoke-mf2pt.sh:31: --fullname=$name \
On 2020/03/16 06:16:22, lemzwerg wrote:
> spaces vs. tabs?

no idea. Whatever?

https://codereview.appspot.com/553700043/

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

[David Kastrup]

Han-Wen Nienhuys  writes:

> I am not asking you for a review of a new build system. I am asking
> for the review of this change.
>
> I think we can do without the sarcasm about my capabilities, given
> that you are working on a project that I largely wrote, and has
> survived for 22 years.

With all due respect, I think characterizing the phases of the project
without your input as mere survival, even if you consider yourself the
sole relevant author for those of the times you were active on it, is
not exactly being a fair characterization of the work of dozens of
contributors.

-- 
David Kastrup

Re: [LSR 2.20] #114 (a doc-tagged partcombine-snippet) complains

[Torsten Hämmerle]

By the way: this is  Issue 5389: partcombine warns about unterminated slur
  

Cheers,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Lilypond API

[Urs Liska]

Hello Brahim,

Am Montag, den 16.03.2020, 10:31 + schrieb brahim.pro via
Discussions on LilyPond development:
> Hello,
> 
> I would like to use lilypond parser in my own application.
> I can't find any API or external library to do that.

There is no such thing.

> What is the correct approach you would advice me to follow?

That very much depends on what you are actually trying to achieve. The
typical way to use LilyPond from the outside is generate some input for
it (or have users write that) and than pass it to LilyPond for
compilation. This can be either by writing a file and give that to
LilyPond or by directly passing it the content in a string through the
shell.

For some applications it may also be a way to use the python-ly library
that powers the Frescobaldi (text) editor (
https://python-ly.readthedocs.io/en/latest/).

But you should really clarify what you're after.

Urs

> 
> Thanks
> Brahim
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: [LSR 2.20] #114 (a doc-tagged partcombine-snippet) complains

[Torsten Hämmerle]

Hi Harm,

I can't comment on the unterminated slur at the moment, but I think the
"Solo II" should never have been there.


Thomas Morley-2 wrote
> Also, the "Solo II"-text vanishes, see attached images.

Why should there be a "Solo II" text at all?  Both voices are still present
and in action, there is no rest in voice I.  The more recent LilyPond
versions now correctly recognize this and so you even don't need the
\stemDown command anymore.
As a result, the automatically maintained polyphonic stem down direction and
no "Solo II" text are perfectly alright, aren't they?

As to the slur problem, obviously two slurs are being started but only one
of them is being ended, thus producing the "unterminated slur" error
message.
I haven't got a clue, but starting with one single note and ending with a
"chord" will result in an "unterminated slur" warning, whereas starting with
a "chord" and ending with one single note will result in an "cannot end
slur" warning.

Cheers,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: [LSR 2.20] #114 (a doc-tagged partcombine-snippet) complains

[Davide Liessi]

Dear Harm,

Il giorno lun 16 mar 2020 alle ore 13:57 Thomas Morley
 ha scritto:
> warning: unterminated slur

I don't know how to get rid of this warning, but...

> Also, the "Solo II"-text vanishes, see attached images.

... the disappearance of "Solo II" is definitely correct: at that
point both parts are still playing.
If it is desirable to demonstrate also "Solo II", you can simply add
another bar with notes only in musicDown and rests in musicUp.

Best wishes.
Davide

Lilypond API

[brahim.pro]

Hello,

I would like to use lilypond parser in my own application.
I can't find any API or external library to do that.
What is the correct approach you would advice me to follow?

Thanks
Brahim

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Mon, Mar 16, 2020 at 8:29 AM  wrote:
>
> On 2020/03/15 21:46:38, hanwenn wrote:
> > On Sun, Mar 15, 2020 at 8:44 PM 
> wrote:
> > > Using whatever makes sense from the GNU build system and reduce the
> > > maintenance burden of the build system as much as possible. FWIW I
> fully
> > > agree with David that the current shortcomings originate from what
> > > LilyPond builds around Autoconf, GNU make et al. Using standard
> > > solutions (aclocal, possibly Automake for dependencies of C++ files)
> > > should enable us to reuse what others have already solved.
> >
> > I don't disagree with the analysis of the root cause, but getting rid
> > of the recursive make for a non-recursive one means a complete
> > rewrite, and not one that can be done incrementally. When you do a
> > complete rewrite, you might as well reconsider the fundamental
> > assumptions, one of which is "use the GNU build stack".
> >
> > I have plenty of experience with Automake, GNU make, building
> > lilypond, and build systems in general. My conclusion of this
> > experience is that it is a pretty poor stack,
>
> ... which has led to the invention of Stepmake in the past ...
>
> > and for that reason I am
> > experimenting with something that is completely different.
>
> So we start another cycle of writing a custom build system. Fabulous!
> 

I am not asking you for a review of a new build system. I am asking
for the review of this change.

I think we can do without the sarcasm about my capabilities, given
that you are working on a project that I largely wrote, and has
survived for 22 years.

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

[jonas . hahnfeld]

On 2020/03/15 21:46:38, hanwenn wrote:
> On Sun, Mar 15, 2020 at 8:44 PM 
wrote:
> > Using whatever makes sense from the GNU build system and reduce the
> > maintenance burden of the build system as much as possible. FWIW I
fully
> > agree with David that the current shortcomings originate from what
> > LilyPond builds around Autoconf, GNU make et al. Using standard
> > solutions (aclocal, possibly Automake for dependencies of C++ files)
> > should enable us to reuse what others have already solved.
> 
> I don't disagree with the analysis of the root cause, but getting rid
> of the recursive make for a non-recursive one means a complete
> rewrite, and not one that can be done incrementally. When you do a
> complete rewrite, you might as well reconsider the fundamental
> assumptions, one of which is "use the GNU build stack".
> 
> I have plenty of experience with Automake, GNU make, building
> lilypond, and build systems in general. My conclusion of this
> experience is that it is a pretty poor stack,

... which has led to the invention of Stepmake in the past ...

> and for that reason I am
> experimenting with something that is completely different.

So we start another cycle of writing a custom build system. Fabulous!


https://codereview.appspot.com/553700043/

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

LGTM


https://codereview.appspot.com/553700043/diff/555460043/mf/invoke-mf2pt.sh
File mf/invoke-mf2pt.sh (right):

https://codereview.appspot.com/553700043/diff/555460043/mf/invoke-mf2pt.sh#newcode18
mf/invoke-mf2pt.sh:18: # which no longer dump a .mem file
We could probably get rid of the .mem file support, which is obsolete
since about 10 years.

https://codereview.appspot.com/553700043/diff/555460043/mf/invoke-mf2pt.sh#newcode31
mf/invoke-mf2pt.sh:31: --fullname=$name \
spaces vs. tabs?

https://codereview.appspot.com/553700043/