Re: harmonyli.ly beta 0.91 released

[mason]

On 11/10, Karsten Reincke wrote:
> I've just tried to test your version. But it does not work, because my
> LilyPond version 2.18.2, offered by Ubuntu 19.10, does not contain a
> function \overlay. I have the hope, that the coming LTS Ubuntu version
> 20.04 will contain the newer 2.19.x  - LilyPond. 

Ubuntu is based on snapshots of Debian's unstable branch.  Lilypond
2.19.83 is currently in Debian's experimental branch, but the unstable
branch has 2.18.2, and this will presumably remain the case until
Lilypond 2.20 is released.  If Lilypond 2.20 is released in time to make
it into Debian unstable before Ubuntu freezes its package versions for
20.04, then Lilypond 2.20 might be available in the next Ubuntu LTS, but
otherwise it will still have 2.18.2.  The easiest way to install
Lilypond 2.19.83 on a Debian-based distro like Ubuntu is probably to
grab the deb from Debian experimental.

Assuming that your architecture is amd64:

$ wget
http://ftp.us.debian.org/debian/pool/main/l/lilypond/lilypond_2.19.83-1~exp1_amd64.deb

$ sudo dpkg -i lilypond_2.19.83-1~exp1_amd64.deb


signature.asc
Description: PGP signature

Re: How stable is 2.21?

[Peter Toye]

Phil,

There's a slight problem here - LP doesn't seem to allow me to have two 
versions installed on the machine at the same time. I found this when I was 
pointed towards the unofficial release of 2.21 on gnu.org.

And another point - when I installed this I found that the 
layout-set-staff-size function is giving wrong results - staff size 15 is 
larger than 16! So there seems to be a different bug in that version. I'd like 
to provide an MWE but the bug doesn't show up, and the score that I've got is 
far too long to post here. Whom should I tell about this (if they don't already 
know)?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, November 10, 2019, 4:42:56 PM, Phil Holmes wrote:

 

If this is the only thing you want to have fixed, you could try 2.18, which 
does not have the problem.

--
Phil Holmes
 
 

- Original Message -
From: Peter Toye
To: Urs Liska; Andrew Bernard; Lukas-Fabian Moser
Cc: lilypond-user Mailinglist
Sent: Sunday, November 10, 2019 3:55 PM
Subject: Re: How stable is 2.21?

Thanks all for the comments.

As I'm running Windows it looks like I'm stuffed until 2.21 is released. Any 
ideas when this might happen?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, November 10, 2019, 1:19:38 PM, Urs Liska wrote:



> Am 10. November 2019 13:40:11 MEZ schrieb Peter
> Toye :
>> Andrew,

>> Thanks. I'll give it a whirl. But where do I download it from? The LP
>> web site doesn't offer anything more advances than 2.19.83.

> That seems to be a misunderstanding. 2.21 has
> not been released yet and can only be compiled from source.

> Ur

>> Best regards,

>> Peter
>>mailto:lilyp...@ptoye.com
>>www.ptoye.com

>>-
>> Sunday, November 10, 2019, 12:18:16 PM, Andrew Bernard wrote:


>> Hi Peter,

>> It's pretty good. Lilypond suffers from the overly false modesty that
>> all open source projects have, which is to declare development versions
>> 'unstable'. Technically this may be accurate to say, but in practice I
>> have found the development versions over many years to always be
>> outstandingly good, a real tribute to the excellence of our developers.
>> It's the same with version numbering in open source: modesty demands
>> that some programs sit at version 0.9 or so for up to even decades
>> until proved utterly error free beyond all earthly standards.

>> Where's the harm in it? You can always install multiple versions side
>> by side.

>> Andrew



>> On Sun, 10 Nov 2019 at 23:04, Peter Toye  wrote:

>> I'm asking because I need to assemble a score with different staff
>> sizes (page-turning issues in piano music) and the bug I asked about
>> yesterday is reportedly corrected. But I hate working with unstable
>> software - I wrote enough of that in my programming days :)  And even
>> more debugging someone else's software (reason - ditto).

Re: midiPanPosition in midi context block

[Matt Wallis]

On 08/11/2019 14:30, David Kastrup wrote:

Matt Wallis  writes:


But it doesn't work if I try to set the midiPanPosition inside a midi
context block like this:

\version "2.19.83"

\include "english.ly"
sopStaff = \new Staff = "sop" {
   \relative c' { e4 f g a }
}
altoStaff = \new Staff = "alto" {
   \relative c' { c4 d e f }
}
\score {
   <<
     \sopStaff
     \altoStaff
   >>
   \midi {
     \context Staff = "sop" {
   \set Staff.midiPanPosition = #1.0
   \set Staff.midiBalance = #1.0
     }
     \context Staff = "alto" {
   \set Staff.midiPanPosition = #-1.0
   \set Staff.midiBalance = #-1.0
     }
   }
}

This is terrible.  Really, really terrible.  \context Staff = "xxx"
should never be allowed in an output block since setting name-specific
context defs is not supported and does not make sense, either.  I'll see
whether I can stop the parser from accepting this abomination.


Strong words! My code,  above,  was the result of an error in pasting. 
What I had meant to do is this:


\score {
  <<
    \sopStaff
    \altoStaff
    \context Staff = "sop" {
  \set Staff.midiPanPosition = #1.0
    }
    \context Staff = "alto" {
  \set Staff.midiPanPosition = #-1.0
    }
  >>
 \midi { }

... which works. But now I'm worried, because the example I copied was 
from other code I have written. Is this another abomination?


I look forward to the day when I understand enough about how lilypond 
works internally in order to avoid abominations that happen to get past 
the parser.


Perhaps someone could point me to the relevant syntax reference docs 
that say (or at least imply) that my original abomination is illegal 
syntax, and to check that my amendment (above) is valid syntactically. 
I've had a look for some reference material, and found this 
(http://lilypond.org/doc/v2.19/Documentation/notation/contexts-explained):


   "Output definitions define the relation between contexts as well as
   their respective default settings. While most changes will usually
   be made inside of a|\layout|block, Midi-related settings will only
   have an effect when made within a|\midi|block."

This does little to discourage my abomination. Also, itmakes me suspect 
that my code above (with the context block within the score) is also 
working only by accident (because it sets midi settings outside the midi 
block). So, am I right in thinking that the only legal place for midi 
settings for a Staff as inside the original definition of that Staff?



Furthermore, the result of doing this is that both staffs are played
through the left, and nothing on the right.

Am I doing something wrong?

As a rule, changing syntax until something passes the parser instead of
working from documented syntax and examples is a bad idea.

I couldn't agree more.

Most of the
time, you'll trigger error messages pinpointing the problem.

But sometimes there are oversights.


I want to do the setting in the midi context block because I require
different pan positions for a staff depending on which score it
appears in.

Then create different variables/expressions for that purpose.  But the
\midi block cannot sensibly differentiate between differently named
contexts.

Thanks for the advice. I shall use variables.

Re: midiPanPosition in midi context block

[David Kastrup]

Matt Wallis  writes:

> On 08/11/2019 14:30, David Kastrup wrote:
>> Matt Wallis  writes:
>>
>>> But it doesn't work if I try to set the midiPanPosition inside a midi
>>> context block like this:
>>>
>>> \version "2.19.83"
>>>
>>> \include "english.ly"
>>> sopStaff = \new Staff = "sop" {
>>>    \relative c' { e4 f g a }
>>> }
>>> altoStaff = \new Staff = "alto" {
>>>    \relative c' { c4 d e f }
>>> }
>>> \score {
>>>    <<
>>>      \sopStaff
>>>      \altoStaff
>>>    >>
>>>    \midi {
>>>      \context Staff = "sop" {
>>>    \set Staff.midiPanPosition = #1.0
>>>    \set Staff.midiBalance = #1.0
>>>      }
>>>      \context Staff = "alto" {
>>>    \set Staff.midiPanPosition = #-1.0
>>>    \set Staff.midiBalance = #-1.0
>>>      }
>>>    }
>>> }
>> This is terrible.  Really, really terrible.  \context Staff = "xxx"
>> should never be allowed in an output block since setting name-specific
>> context defs is not supported and does not make sense, either.  I'll see
>> whether I can stop the parser from accepting this abomination.
>
> Strong words! My code,  above,  was the result of an error in
> pasting.

Nevertheless it was accepted by LilyPond.

> What I had meant to do is this:
>
> \score {
>   <<
>     \sopStaff
>     \altoStaff
>     \context Staff = "sop" {
>   \set Staff.midiPanPosition = #1.0
>     }
>     \context Staff = "alto" {
>   \set Staff.midiPanPosition = #-1.0
>     }
>   >>
>  \midi { }
>
> ... which works. But now I'm worried, because the example I copied was
> from other code I have written. Is this another abomination?

Normally, I'd not use \context here but \new .  Mind you: the issue with
\new inside of the \midi block would have been the same.

> I look forward to the day when I understand enough about how lilypond
> works internally in order to avoid abominations that happen to get
> past the parser.

Me too.

> Perhaps someone could point me to the relevant syntax reference docs
> that say (or at least imply) that my original abomination is illegal
> syntax, and to check that my amendment (above) is valid syntactically.

I don't think that we spell out "illegal syntax" a lot since, well,
there is more invalid syntax than valid syntax in general.  Where things
are less than clear, using copy&paste examples preserving structure
tends to be more on the safer side.

> I've had a look for some reference material, and found this
> (http://lilypond.org/doc/v2.19/Documentation/notation/contexts-explained):
>
>"Output definitions define the relation between contexts as well as
>their respective default settings. While most changes will usually
>be made inside of a|\layout|block, Midi-related settings will only
>have an effect when made within a|\midi|block."
>
> This does little to discourage my abomination.

You seem to be hung a bit on my strong verbiage.  It wasn't supposed to
be a personal criticism but rather expressed my dismay that the
combination of what LilyPond flags as problematic and what our manuals
and examples suggest led to a result that I had not expected to see.  I
wasn't blaming you for it.

> Also, itmakes me suspect that my code above (with the context block
> within the score) is also working only by accident (because it sets
> midi settings outside the midi block). So, am I right in thinking that
> the only legal place for midi settings for a Staff as inside the
> original definition of that Staff?

Well, "legal" is a strong word.  You are not going to get arrested.
It's more about "dependable", and you have already noticed that it
doesn't do what you expect.

>> Then create different variables/expressions for that purpose.  But the
>> \midi block cannot sensibly differentiate between differently named
>> contexts.
> Thanks for the advice. I shall use variables.

Harm already showed how to "unsensibly differentiate" but I think it is
really weird to go via that route.  Using variables seems like a better
fit.

-- 
David Kastrup

Re: How stable is 2.21?

[Phil Holmes]

Re: How stable is 2.21? 
No point in telling anyone really, since it won't be fixed in 2.18.



I run Windows and have over 50 versions installed.  I wrote a little 
application to select which one is run, but you should be able to do the same 
with a full directory specification for which version you want to run.  Just 
install them in slightly different locations.


--
Phil Holmes




 - Original Message - 

From: Peter Toye 



To: Phil Holmes 



Cc: lilypond-user Mailinglist 



Sent: Monday, November 11, 2019 12:48 PM

 Subject: Re: How stable is 2.21?
 


Phil,
 
There's a slight problem here - LP doesn't seem to allow me to have two 
versions installed on the machine at the same time. I found this when I was 
pointed towards the unofficial release of 2.21 on gnu.org.
 
And another point - when I installed this I found that the 
layout-set-staff-size function is giving wrong results - staff size 15 is 
larger than 16! So there seems to be a different bug in that version. I'd like 
to provide an MWE but the bug doesn't show up, and the score that I've got is 
far too long to post here. Whom should I tell about this (if they don't already 
know)?
 
Best regards,
 
Peter
 mailto:lilyp...@ptoye.com
 www.ptoye.com
 
-
 Sunday, November 10, 2019, 4:42:56 PM, Phil Holmes wrote:
 

 

  

  
  
  If this is the only thing you want to have fixed, you could try 2.18, which 
does not have the problem.
   
  --
   Phil Holmes


   





- Original Message -
 From: Peter Toye
 To: Urs Liska; Andrew Bernard; Lukas-Fabian Moser
 Cc: lilypond-user Mailinglist
 Sent: Sunday, November 10, 2019 3:55 PM
 Subject: Re: How stable is 2.21?
 
Thanks all for the comments.
 
As I'm running Windows it looks like I'm stuffed until 2.21 is released. 
Any ideas when this might happen?
 
Best regards,
 
Peter
 mailto:lilyp...@ptoye.com
 www.ptoye.com
 
-
 Sunday, November 10, 2019, 1:19:38 PM, Urs Liska wrote:
 


> Am 10. November 2019 13:40:11 MEZ schrieb Peter
 > Toye :
 >> Andrew,
 
>> Thanks. I'll give it a whirl. But where do I download it from? The LP
 >> web site doesn't offer anything more advances than 2.19.83.
 
> That seems to be a misunderstanding. 2.21 has
 > not been released yet and can only be compiled from source.
 
> Ur
 
>> Best regards,
 
>> Peter
 >>mailto:lilyp...@ptoye.com
 >>www.ptoye.com
 
>>-
 >> Sunday, November 10, 2019, 12:18:16 PM, Andrew Bernard wrote:
 

>> Hi Peter,
 
>> It's pretty good. Lilypond suffers from the overly false modesty that
 >> all open source projects have, which is to declare development versions
 >> 'unstable'. Technically this may be accurate to say, but in practice I
 >> have found the development versions over many years to always be
 >> outstandingly good, a real tribute to the excellence of our developers.
 >> It's the same with version numbering in open source: modesty demands
 >> that some programs sit at version 0.9 or so for up to even decades
 >> until proved utterly error free beyond all earthly standards.
 
>> Where's the harm in it? You can always install multiple versions side
 >> by side.
 
>> Andrew
 


>> On Sun, 10 Nov 2019 at 23:04, Peter Toye  wrote:
 
>> I'm asking because I need to assemble a score with different staff
 >> sizes (page-turning issues in piano music) and the bug I asked about
 >> yesterday is reportedly corrected. But I hate working with unstable
 >> software - I wrote enough of that in my programming days :)  And even
 >> more debugging someone else's software (reason - ditto).
 
  

Re: How stable is 2.21?

[Peter Toye]

Sorry I wasn't clear. The bug was in 2.21 (unofficial release). I wouldn't 
expect retrospective bug fixes.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Monday, November 11, 2019, 2:01:14 PM, Phil Holmes wrote:

 

No point in telling anyone really, since it won't be fixed in 2.18.
 
I run Windows and have over 50 versions installed.  I wrote a little 
application to select which one is run, but you should be able to do the same 
with a full directory specification for which version you want to run.  Just 
install them in slightly different locations.

--
Phil Holmes
 
 

- Original Message -
From: Peter Toye
To: Phil Holmes
Cc: lilypond-user Mailinglist
Sent: Monday, November 11, 2019 12:48 PM
Subject: Re: How stable is 2.21?

Phil,

There's a slight problem here - LP doesn't seem to allow me to have two 
versions installed on the machine at the same time. I found this when I was 
pointed towards the unofficial release of 2.21 on gnu.org.

And another point - when I installed this I found that the 
layout-set-staff-size function is giving wrong results - staff size 15 is 
larger than 16! So there seems to be a different bug in that version. I'd like 
to provide an MWE but the bug doesn't show up, and the score that I've got is 
far too long to post here. Whom should I tell about this (if they don't already 
know)?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, November 10, 2019, 4:42:56 PM, Phil Holmes wrote:



If this is the only thing you want to have fixed, you could try 2.18, which 
does not have the problem.

--
Phil Holmes
 
 

- Original Message -
From: Peter Toye
To: Urs Liska; Andrew Bernard; Lukas-Fabian Moser
Cc: lilypond-user Mailinglist
Sent: Sunday, November 10, 2019 3:55 PM
Subject: Re: How stable is 2.21?

Thanks all for the comments.

As I'm running Windows it looks like I'm stuffed until 2.21 is released. Any 
ideas when this might happen?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, November 10, 2019, 1:19:38 PM, Urs Liska wrote:



> Am 10. November 2019 13:40:11 MEZ schrieb Peter
> Toye :
>> Andrew,

>> Thanks. I'll give it a whirl. But where do I download it from? The LP
>> web site doesn't offer anything more advances than 2.19.83.

> That seems to be a misunderstanding. 2.21 has
> not been released yet and can only be compiled from source.

> Ur

>> Best regards,

>> Peter
>>mailto:lilyp...@ptoye.com
>>www.ptoye.com

>>-
>> Sunday, November 10, 2019, 12:18:16 PM, Andrew Bernard wrote:


>> Hi Peter,

>> It's pretty good. Lilypond suffers from the overly false modesty that
>> all open source projects have, which is to declare development versions
>> 'unstable'. Technically this may be accurate to say, but in practice I
>> have found the development versions over many years to always be
>> outstandingly good, a real tribute to the excellence of our developers.
>> It's the same with version numbering in open source: modesty demands
>> that some programs sit at version 0.9 or so for up to even decades
>> until proved utterly error free beyond all earthly standards.

>> Where's the harm in it? You can always install multiple versions side
>> by side.

>> Andrew



>> On Sun, 10 Nov 2019 at 23:04, Peter Toye  wrote:

>> I'm asking because I need to assemble a score with different staff
>> sizes (page-turning issues in piano music) and the bug I asked about
>> yesterday is reportedly corrected. But I hate working with unstable
>> software - I wrote enough of that in my programming days :)  And even
>> more debugging someone else's software (reason - ditto).

Re: harmonyli.ly beta 0.91 released

[David Wright]

On Mon 11 Nov 2019 at 00:11:53 (-0800), ma...@masonhock.com wrote:
> On 11/10, Karsten Reincke wrote:
> > I've just tried to test your version. But it does not work, because my
> > LilyPond version 2.18.2, offered by Ubuntu 19.10, does not contain a
> > function \overlay. I have the hope, that the coming LTS Ubuntu version
> > 20.04 will contain the newer 2.19.x  - LilyPond. 
> 
> Ubuntu is based on snapshots of Debian's unstable branch.  Lilypond
> 2.19.83 is currently in Debian's experimental branch, but the unstable
> branch has 2.18.2, and this will presumably remain the case until
> Lilypond 2.20 is released.  If Lilypond 2.20 is released in time to make
> it into Debian unstable before Ubuntu freezes its package versions for
> 20.04, then Lilypond 2.20 might be available in the next Ubuntu LTS, but
> otherwise it will still have 2.18.2.  The easiest way to install
> Lilypond 2.19.83 on a Debian-based distro like Ubuntu is probably to
> grab the deb from Debian experimental.
> 
> Assuming that your architecture is amd64:
> 
> $ wget
> http://ftp.us.debian.org/debian/pool/main/l/lilypond/lilypond_2.19.83-1~exp1_amd64.deb
> 
> $ sudo dpkg -i lilypond_2.19.83-1~exp1_amd64.deb

Add 
http://ftp.us.debian.org/debian/pool/main/l/lilypond/lilypond-data_2.19.83-1~exp1_all.deb
to that.

But the disadvantage of installing that way is that the distribution
only supports one version of LilyPond, and there are advantages to
being able to run more than one.

If you download the program from lilypond.org, install with
$ bash …path-to/lilypond-2.19.83-1.linux-64.sh --prefix 
lilypond-2.19.83-1.linux-64
and run with lilypond-2.19.83-1.linux-64/bin/lilypond …,
you can have several versions available.

Cheers,
David.

Re: harmonyli.ly beta 0.91 released

[mason]

On 11/11, David Wright wrote:
> On Mon 11 Nov 2019 at 00:11:53 (-0800), ma...@masonhock.com wrote:
> > Assuming that your architecture is amd64:
> > 
> > $ wget
> > http://ftp.us.debian.org/debian/pool/main/l/lilypond/lilypond_2.19.83-1~exp1_amd64.deb
> > 
> > $ sudo dpkg -i lilypond_2.19.83-1~exp1_amd64.deb
> 
> Add 
> http://ftp.us.debian.org/debian/pool/main/l/lilypond/lilypond-data_2.19.83-1~exp1_all.deb
> to that.

Good catch, thanks.

> But the disadvantage of installing that way is that the distribution
> only supports one version of LilyPond, and there are advantages to
> being able to run more than one.
> 
> If you download the program from lilypond.org, install with
> $ bash …path-to/lilypond-2.19.83-1.linux-64.sh --prefix 
> lilypond-2.19.83-1.linux-64
> and run with lilypond-2.19.83-1.linux-64/bin/lilypond …,
> you can have several versions available.

Yes, this is probably the easiest way to install 2.19 without going
through the package manager.

Mason


signature.asc
Description: PGP signature

Re: 64 bit

[Eric]

On the assumption that it would have been pointed out if this link was
dangerous phished spam (apologies, Mr Sorensen!!) I have decided to install
this development version to replace my slashed-out 32-bit Lilyponds. Has
anyone else - or are others who use Mac Catalina waiting for Lilypond 2.20
to possibly include a 64-bit version (if even then) linked from the
Lilypond site? I can't seem to find much followup on this topic, and
nothing? in our mailing list (maybe I need to search better) that mentions
the below (rather unusually large, maybe because 64-bit?) unofficial
development update.

On Thu, Oct 17, 2019 at 10:47 PM  wrote:

> Send lilypond-user mailing list submissions to
> lilypond-user@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> or, via email, send a message with subject or body 'help' to
> lilypond-user-requ...@gnu.org
>
> You can reach the person managing the list at
> lilypond-user-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lilypond-user digest..."
> Today's Topics:
>
>1. Re:Lilypond on OS X Catalina (Chris Crossen)
>2. Re:Lilypond on OS X Catalina (Chris Crossen)
>3. Re:Lilypond on OS X Catalina (Carl Sorensen)
>4. Re:64 bit (Carl Sorensen)
>
>
>
> -- Forwarded message --
> From: Chris Crossen 
> To: Allan Kinnaird 
> Cc: Carl Sorensen , "lilypond-user@gnu.org" <
> lilypond-user@gnu.org>
> Bcc:
> Date: Thu, 17 Oct 2019 17:29:39 -0700
> Subject: Re: Lilypond on OS X Catalina
>
>
> > On Oct 17, 2019, at 4:48 PM, Allan Kinnaird via lilypond-user <
> lilypond-user@gnu.org> wrote:
> >
> > Thanks, Carl - I haven’t upgraded to Catalina myself for exactly that
> reason (and Lilypond is my only significant 32-bit app!). I’ll see if I can
> work out how to use Hans’s version.
> > Allan
>
> I have Catalina installed on a Mac laptop. I downloaded the installer and
> am running it now. I’ll report back when I have some results to share.
>
>
>
>
>
>
>
>
> -- Forwarded message --
> From: Chris Crossen 
> To: Allan Kinnaird , Carl Sorensen <
> c_soren...@byu.edu>, "lilypond-user@gnu.org" 
> Cc:
> Bcc:
> Date: Thu, 17 Oct 2019 18:46:46 -0700
> Subject: Re: Lilypond on OS X Catalina
>
>
> > On Oct 17, 2019, at 5:29 PM, Chris Crossen  wrote:
> >
> >> Thanks, Carl - I haven’t upgraded to Catalina myself for exactly that
> reason (and Lilypond is my only significant 32-bit app!). I’ll see if I can
> work out how to use Hans’s version.
> >> Allan
> >
> > I have Catalina installed on a Mac laptop. I downloaded the installer
> and am running it now. I’ll report back when I have some results to share.
>
> The install was successful. I didn’t know where it installed, but found it
> in /opt/lilypond .
>
> It successfully generated a correct-looking pdf and midi (I’ll verify them
> tomorrow) from a single source file (no includes but english.ly). The
> file was already version 2.19. I’ll try using convert-ly and more complex
> files tomorrow.
>
> Since this may not be of general interest, please give me some guidance on
> whether to continue posting to the group or confine it to those interested.
>
>
>
>
>
>
>
>
>
>
>
>
> -- Forwarded message --
> From: Carl Sorensen 
> To: Chris Crossen , Allan Kinnaird <
> akinna...@icloud.com>, "lilypond-user@gnu.org" 
> Cc:
> Bcc:
> Date: Fri, 18 Oct 2019 02:42:37 +
> Subject: Re: Lilypond on OS X Catalina
>
>
> On 10/17/19, 7:46 PM, "Chris Crossen"  wrote:
>
>
>
> > On Oct 17, 2019, at 5:29 PM, Chris Crossen 
> wrote:
> >
> >> Thanks, Carl - I haven’t upgraded to Catalina myself for exactly
> that reason (and Lilypond is my only significant 32-bit app!). I’ll see if
> I can work out how to use Hans’s version.
> >> Allan
> >
> > I have Catalina installed on a Mac laptop. I downloaded the
> installer and am running it now. I’ll report back when I have some results
> to share.
>
> The install was successful. I didn’t know where it installed, but
> found it in /opt/lilypond .
>
> That's where it was supposed to be.
>
> It successfully generated a correct-looking pdf and midi (I’ll verify
> them tomorrow) from a single source file (no includes but english.ly).
> The file was already version 2.19. I’ll try using convert-ly and more
> complex files tomorrow.
>
> Yes, it was made from the latest development release, 2.19.83
>
> Since this may not be of general interest, please give me some
> guidance on whether to continue posting to the group or confine it to those
> interested.
>
>
>  Please report your experiences.
>
> Here's some test code that has been known to fail on 32-bit lilypond
> executables, but succeed on 64-bit linux executables.
>
>  Start of code
>
> \version "2.19.82"
> {
>   \time 4/4
>   \repeat unfold 1000 { c4 d e f } % TEN PAGES of music
>   \repeat unfold 1000 { f1 } % + SIX MORE P

Very weird output on any compilation

[David Menéndez Hurtado]

I am having trouble compiling even the simplest of scores. For example,
this is the template from Frescobaldi, compiled with lilypond from the
command line:

[image: Untitled.png]

The output is the same for PNG and PDF. The same problem happens with any
other score from Mutopia. Does anyone know what is going on? I have
installed lilypond 2.19.83 from the Fedora repositories, and I am sure that
is what is being used:
$ which lilypond
/bin/lilypond

I have not messed with dynamic linking:
$ echo $LD_LIBRARY_PATH

(that is an empty string)


I am attaching the compilation log when using loglevel DEBUG. For
completeness, the template I used is also attached.

Can anyone spot what is wrong here? Is there a way to keep the temporary
files? That may hint what is wrong.


Thank you

/David.
Log level set to 287
GNU LilyPond 2.19.83
Relocation: from PATH=/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/libexec/python3-sphinx:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/lib/snapd/snap/bin
argv0=lilypond
PATH=/usr/bin (prepend)
Setting PATH to /usr/bin:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/libexec/python3-sphinx:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/lib/snapd/snap/bin
Relocation: compile datadir=, new datadir=/usr/share/lilypond//2.19.83
Relocation: framework_prefix=/usr/bin/..
Setting INSTALLER_PREFIX to /usr/bin/..
PATH=/usr/bin/../bin (prepend)
Setting PATH to /usr/bin/../bin:/usr/bin:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/libexec/python3-sphinx:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/lib/snapd/snap/bin
Setting GUILE_MIN_YIELD_1 to 65
Setting GUILE_MIN_YIELD_2 to 65
Setting GUILE_MIN_YIELD_MALLOC to 65
Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760
Setting GUILE_MAX_SEGMENT_SIZE to 104857600

LILYPOND_DATADIR="/usr/share/lilypond/2.19.83"
LOCALEDIR="/usr/share/locale"

Effective prefix: "/usr/share/lilypond/2.19.83"
PATH="/usr/bin/../bin:/usr/bin:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/libexec/python3-sphinx:/home/david/.virtualenv/py36/bin:/home/david/.local/bin:/home/david/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/var/lib/snapd/snap/bin"
[]
Guile 1.8
[/usr/share/lilypond/2.19.83/scm/lily-library.scm]
[/usr/share/lilypond/2.19.83/scm/output-lib.scm]
[/usr/share/lilypond/2.19.83/scm/markup-macros.scm]
[/usr/share/lilypond/2.19.83/scm/parser-ly-from-scheme.scm]
[/usr/share/lilypond/2.19.83/scm/file-cache.scm]
[/usr/share/lilypond/2.19.83/scm/define-event-classes.scm]
[/usr/share/lilypond/2.19.83/scm/define-music-callbacks.scm]
[/usr/share/lilypond/2.19.83/scm/define-music-types.scm]
[/usr/share/lilypond/2.19.83/scm/define-note-names.scm]
[/usr/share/lilypond/2.19.83/scm/c++.scm]
[/usr/share/lilypond/2.19.83/scm/chord-entry.scm]
[/usr/share/lilypond/2.19.83/scm/skyline.scm]
[/usr/share/lilypond/2.19.83/scm/markup.scm]
[/usr/share/lilypond/2.19.83/scm/define-markup-commands.scm]
[/usr/share/lilypond/2.19.83/scm/stencil.scm]
[/usr/share/lilypond/2.19.83/scm/modal-transforms.scm]
[/usr/share/lilypond/2.19.83/scm/chord-generic-names.scm]
[/usr/share/lilypond/2.19.83/scm/chord-ignatzek-names.scm]
[/usr/share/lilypond/2.19.83/scm/music-functions.scm
[/usr/share/lilypond/2.19.83/scm/define-music-display-methods.scm]
]
[/usr/share/lilypond/2.19.83/scm/part-combiner.scm]
[/usr/share/lilypond/2.19.83/scm/autochange.scm]
[/usr/share/lilypond/2.19.83/scm/define-music-properties.scm]
[/usr/share/lilypond/2.19.83/scm/time-signature.scm]
[/usr/share/lilypond/2.19.83/scm/time-signature-settings.scm]
[/usr/share/lilypond/2.19.83/scm/auto-beam.scm]
[/usr/share/lilypond/2.19.83/scm/chord-name.scm]
[/usr/share/lilypond/2.19.83/scm/bezier-tools.scm]
[/usr/share/lilypond/2.19.83/scm/define-context-properties.scm]
[/usr/share/lilypond/2.19.83/scm/translation-functions.scm]
[/usr/share/lilypond/2.19.83/scm/script.scm]
[/usr/share/lilypond/2.19.83/scm/midi.scm]
[/usr/share/lilypond/2.19.83/scm/layout-beam.scm]
[/usr/share/lilypond/2.19.83/scm/parser-clef.scm]
[/usr/share/lilypond/2.19.83/scm/layout-slur.scm]
[/usr/share/lilypond/2.19.83/scm/font.scm]
[/usr/share/lilypond/2.19.83/scm/encoding.scm]
[/usr/share/lilypond/2.19.83/scm/bar-line.scm]
[/usr/share/lilypond/2.19.83/scm/flag-styles.scm]
[/usr/share/lilypond/2.19.83/scm/fret-diagrams.scm]
[/usr/share/lilypond/2.19.83/scm/tablature.scm]
[/usr/share/lilypond/2.19.83/scm/harp-pedals.scm]
[/usr/share/lilypond/2.19.83/scm/define-woodwind-diagrams.scm]
[/usr/share/lilypond/2.19.83/scm/d

Re:64 bit

[Mario Bolognani]

I am a LilyPond user on MacOsX and am anxiously waiting for a 64bit version of 
LilyPond, before installing Catalina. I am managing a baroque music site 
(baroque music.it) with many followers and at present I can’t evolve my 
transcription platform for this 64bit problem. 

Best wishes

Mario Bolognani
email:  mario.bologn...@gmail.com
www.baroquemusic.it

Re: 64 bit

[Jonathan Armitage]

On 11/11/2019 15:32, Eric wrote:
On the assumption that it would have been pointed out if this link was 
dangerous phished spam (apologies, Mr Sorensen!!) I have decided to 
install this development version to replace my slashed-out 32-bit 
Lilyponds. Has anyone else - or are others who use Mac Catalina waiting 
for Lilypond 2.20 to possibly include a 64-bit version (if even then) 
linked from the Lilypond site?


I took the plunge and upgraded my Mac Mini to Catalina (not without 
other difficulties which are still coming out of the woodwork) and 
installed Hans's package, which seems to work perfectly well, apart from 
convert-ly as mentioned elsewhere.


I am a Homebrew user, I do not have MacPorts installed.

I did have to recompile Qsynth myself. I cannot (so far) build Lilypond, 
possibly because I cannot compile Guile 1.8.8. This is not a big deal 
for me, I am only a casual Lilypond user.


Thank you, Hans.

Jon

Invisible midi layer for specific measures

[Paolo Prete]

Hello,

please, consider this snippet:

http://lilybin.com/ttlid3/1

I would like to add an invisible midi layer of notes to the previous ones so 
that I can obtain, when required, effects (for example: the tremolo) that are 
not provided by default, without using the "articulate" script.

In the previous snippet I want to generate the following midi notes for measure 
2:

\repeat unfold 4 {d'32 f'} g'4 g' g'

And I want the default generated midi for the other measures.
Is there a way/hack to obtain that? I remember that someone else asked a 
similar question in the past, but I can't find the post...

Many thanks for your help.

Paolo

Re: 64 bit

[Carl Sorensen]

From: Eric 
Date: Monday, November 11, 2019 at 8:32 AM
To: 
Subject: Re: 64 bit

On the assumption that it would have been pointed out if this link was 
dangerous phished spam (apologies, Mr Sorensen!!) I have decided to install 
this development version to replace my slashed-out 32-bit Lilyponds. Has anyone 
else - or are others who use Mac Catalina waiting for Lilypond 2.20 to possibly 
include a 64-bit version (if even then) linked from the Lilypond site? I can't 
seem to find much followup on this topic, and nothing? in our mailing list 
(maybe I need to search better) that mentions the below (rather unusually 
large, maybe because 64-bit?) unofficial development update.


Eric,

I’m not sure what you are waiting for.

Right now, we are at the point where there is no way for us to make a lilypond 
64-bit version because we need the Apple Xcode software, and the license allows 
it to be only used on Apple hardware.  We do not have Apple build hardware, and 
as a GNU project, it’s unlikely that using Apple build hardware for all of our 
distributions would be acceptable to the team.

I think  it’s possible that we could get an approved binary eventually hosted 
on the LilyPond website.  A couple of developers are trying to make that happen.

In the meantime, Hans has provided an installable distributable package created 
in MacPorts, which is at the link referred to below.  I’ve mirrored that link 
on a site that might be considered to be less dangerous for spam or phishing:

  https://www.et.byu.edu/~sorensen/lilypond-devel-2.19.83_2.mpkg

I’m only aware of one person who has installed that package, and they found 
that it works and it is a 64-bit package.

You can read more about this on the lilypond-devel archives:

https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00059.html
https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00272.html

https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00063.html

I think our best hope going forward is for Marnen to succeed in making a 64-bit 
lilypond.app.  I really hope he’s successful.

Thanks,

Carl



On Thu, Oct 17, 2019 at 10:47 PM 
mailto:lilypond-user-requ...@gnu.org>> wrote:
Send lilypond-user mailing list submissions to
lilypond-user@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/lilypond-user
or, via email, send a message with subject or body 'help' to
lilypond-user-requ...@gnu.org

You can reach the person managing the list at
lilypond-user-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lilypond-user digest..."
Today's Topics:

   1. Re:Lilypond on OS X Catalina (Chris Crossen)
   2. Re:Lilypond on OS X Catalina (Chris Crossen)
   3. Re:Lilypond on OS X Catalina (Carl Sorensen)
   4. Re:64 bit (Carl Sorensen)



-- Forwarded message --
From: Chris Crossen mailto:ch...@crossen.net>>
To: Allan Kinnaird mailto:akinna...@icloud.com>>
Cc: Carl Sorensen mailto:c_soren...@byu.edu>>, 
"lilypond-user@gnu.org" 
mailto:lilypond-user@gnu.org>>
Bcc:
Date: Thu, 17 Oct 2019 17:29:39 -0700
Subject: Re: Lilypond on OS X Catalina


> On Oct 17, 2019, at 4:48 PM, Allan Kinnaird via lilypond-user 
> mailto:lilypond-user@gnu.org>> wrote:
>
> Thanks, Carl - I haven’t upgraded to Catalina myself for exactly that reason 
> (and Lilypond is my only significant 32-bit app!). I’ll see if I can work out 
> how to use Hans’s version.
> Allan

I have Catalina installed on a Mac laptop. I downloaded the installer and am 
running it now. I’ll report back when I have some results to share.








-- Forwarded message --
From: Chris Crossen mailto:ch...@crossen.net>>
To: Allan Kinnaird mailto:akinna...@icloud.com>>, Carl 
Sorensen mailto:c_soren...@byu.edu>>, 
"lilypond-user@gnu.org" 
mailto:lilypond-user@gnu.org>>
Cc:
Bcc:
Date: Thu, 17 Oct 2019 18:46:46 -0700
Subject: Re: Lilypond on OS X Catalina


> On Oct 17, 2019, at 5:29 PM, Chris Crossen 
> mailto:ch...@crossen.net>> wrote:
>
>> Thanks, Carl - I haven’t upgraded to Catalina myself for exactly that reason 
>> (and Lilypond is my only significant 32-bit app!). I’ll see if I can work 
>> out how to use Hans’s version.
>> Allan
>
> I have Catalina installed on a Mac laptop. I downloaded the installer and am 
> running it now. I’ll report back when I have some results to share.

The install was successful. I didn’t know where it installed, but found it in 
/opt/lilypond .

It successfully generated a correct-looking pdf and midi (I’ll verify them 
tomorrow) from a single source file (no includes but 
english.ly). The file was already version 2.19. I’ll try 
using convert-ly and more complex files tomorrow.

Since this may not be of general int

Re: Invisible midi layer for specific measures

[karl]

Paolo:
...
> I would like to add an invisible midi layer of notes to the
> previous ones
...

Use this template:

\score {
  <<
% displayed music
  >>
  \layout {
  }
}


\score {
  \unfoldRepeats
  <<
% midi music
  >>
  \midi { }
}

Re: Very weird output on any compilation

[David Wright]

On Mon 11 Nov 2019 at 17:17:00 (+0100), David Menéndez Hurtado wrote:
> I am having trouble compiling even the simplest of scores. For example,
> this is the template from Frescobaldi, compiled with lilypond from the
> command line:
> 
> [image: Untitled.png]
> 
> The output is the same for PNG and PDF. The same problem happens with any
> other score from Mutopia. Does anyone know what is going on? I have
> installed lilypond 2.19.83 from the Fedora repositories, and I am sure that
> is what is being used:
> $ which lilypond
> /bin/lilypond
> 
> I have not messed with dynamic linking:
> $ echo $LD_LIBRARY_PATH
> 
> (that is an empty string)
> 
> 
> I am attaching the compilation log when using loglevel DEBUG. For
> completeness, the template I used is also attached.
> 
> Can anyone spot what is wrong here? Is there a way to keep the temporary
> files? That may hint what is wrong.

Perhaps an old thread like this might help:

https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00521.html

Cheers,
David.

Re: Very weird output on any compilation

[Pierre Perol-Schneider]

Hi David,

Le lun. 11 nov. 2019 à 18:46, David Menéndez Hurtado 
a écrit :
[...]

> The output is the same for PNG and PDF. The same problem happens with any
> other score from Mutopia. Does anyone know what is going on?
>
[...]

Are you sure that the scores are in v.2.19 (many scores frome Mutopia are
in v2.14, v2.16 and v2.18)?
Have you tried to update before compiling?

Cheers,
Pierre

Re: Invisible midi layer for specific measures

[Paolo Prete]

 Thank you Karl for your help.
However, in the way you suggested, I have to repeat the music of the first 
\score block into the second \score block for the first and third measure of my 
snippet. I would like to avoid this redundancy, and I would like to specify the 
notes of "custom" generated midi only for for a subset of specific measures.



Il lunedì 11 novembre 2019, 20:37:34 CET, k...@aspodata.se 
 ha scritto:  
 
 Paolo:
...
> I would like to add an invisible midi layer of notes to the
> previous ones
...

Use this template:

\score {
  <<
    % displayed music
  >>
  \layout {
  }
}


\score {
  \unfoldRepeats
  <<
    % midi music
  >>
  \midi { }
}



  

RE: Very weird output on any compilation

[Mark Stephen Mrotek]

David,

 

It compiled perfect from Frescobaldi for me.

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of David Menéndez Hurtado
Sent: Monday, November 11, 2019 8:17 AM
To: lilypond-user@gnu.org
Subject: Very weird output on any compilation

 

I am having trouble compiling even the simplest of scores. For example, this is 
the template from Frescobaldi, compiled with lilypond from the command line:

 



 

The output is the same for PNG and PDF. The same problem happens with any other 
score from Mutopia. Does anyone know what is going on? I have installed 
lilypond 2.19.83 from the Fedora repositories, and I am sure that is what is 
being used:

$ which lilypond
/bin/lilypond

 

I have not messed with dynamic linking:

$ echo $LD_LIBRARY_PATH

 

(that is an empty string)

 

 

I am attaching the compilation log when using loglevel DEBUG. For completeness, 
the template I used is also attached.

 

Can anyone spot what is wrong here? Is there a way to keep the temporary files? 
That may hint what is wrong.

 

 

Thank you

 

/David.

 

Re: 64 bit

[Hans Åberg]

> On 11 Nov 2019, at 19:04, Jonathan Armitage  
> wrote:
> 
> On 11/11/2019 15:32, Eric wrote:
>> On the assumption that it would have been pointed out if this link was 
>> dangerous phished spam (apologies, Mr Sorensen!!) I have decided to install 
>> this development version to replace my slashed-out 32-bit Lilyponds. Has 
>> anyone else - or are others who use Mac Catalina waiting for Lilypond 2.20 
>> to possibly include a 64-bit version (if even then) linked from the Lilypond 
>> site?
> 
> I took the plunge and upgraded my Mac Mini to Catalina (not without other 
> difficulties which are still coming out of the woodwork) and installed Hans's 
> package, which seems to work perfectly well, apart from convert-ly as 
> mentioned elsewhere.
> 
> I am a Homebrew user, I do not have MacPorts installed.
> 
> I did have to recompile Qsynth myself. I cannot (so far) build Lilypond, 
> possibly because I cannot compile Guile 1.8.8. This is not a big deal for me, 
> I am only a casual Lilypond user.
> 
> Thank you, Hans.

You are welcome. It is a self-contained installer that install into 
/opt/lilypond/, made from MacPorts lilypond-devel without requiring it, 
maintained by Walter, who helped cutting down on the installer size.

Re: Invisible midi layer for specific measures

[Aaron Hill]

On 2019-11-11 12:16 pm, Paolo Prete wrote:

Thank you Karl for your help.
However, in the way you suggested, I have to repeat the music of the
first \score block into the second \score block for the first and
third measure of my snippet. I would like to avoid this redundancy,
and I would like to specify the notes of "custom" generated midi only
for for a subset of specific measures.


Variables and tags are helpful.  Consider:


\version "2.19.83"

asdf = \fixed c' {
  | c4 d e2
  | \tag #'display { 1_\trill }
\tag #'midi { \repeat unfold 4 { f8 g } }
  | a4 b c'2
}

\score { \keepWithTag #'display \asdf \layout {} }
\score { \keepWithTag #'midi \asdf \midi { \tempo 1 = 60 } }



-- Aaron Hill

m7.5- transposed to sus#4 b3 ??

[Sandro Santilli]

I transcribed an A major song with this chords snippet:

  ees:m7.5- | aes:7 | aes:m7.5- | des:7 |

When transposing it to Eb major it is rendered as:

  Bbbø | Ebb7 | Ebb7sus#4 b3 | Abb7

I don't understand why the third chord (m7.5-)
gets rendered as a "7sus#4 b3" chord, very hard
to read ...

Ideally I'd also like to avoid the double flats,
but what strikes me is the "sus#4 b3" part, is it
a bug ? I'm using GNU LilyPond 2.18.2 and the
.ly file has a \version "2.18.2" header.

--strk; 

Re: m7.5- transposed to sus#4 b3 ??

[Malte Meyn]

Am 11.11.19 um 21:38 schrieb Sandro Santilli:

I transcribed an A major song with this chords snippet:

   ees:m7.5- | aes:7 | aes:m7.5- | des:7 |


Are you sure you want those chords instead of

dis:m7.5- gis:7 gis:m7.5- cis:7

? Who wants to read a a-flat half-diminished chord (a-flat c-flat 
e-doubleflat g-flat)?




When transposing it to Eb major it is rendered as:

   Bbbø | Ebb7 | Ebb7sus#4 b3 | Abb7

I don't understand why the third chord (m7.5-)
gets rendered as a "7sus#4 b3" chord, very hard
to read ...


The bigger problem is that while a-flat half-diminished is at least hard 
to read, e-doubleflat half-diminished is just insane.


LilyPond 2.18.2 did the most sane thing it could do and changed the 
b-tripleflat to a a-flat in that chord. You can see this if you output 
not only as ChordNames but also as regular notes:


%%
\version "2.18.2"

C = \chordmode {
  ees:m7.5-  aes:7 aes:m7.5- des:7
}

<<
\new Staff \C
\new ChordNames \C
\new Staff \transpose a es \C
\new ChordNames \transpose a es \C
>>
%%


Ideally I'd also like to avoid the double flats,


You definitely should do that. Ideally by not using the single flat 
chords in the a major version in the first place … But if you really 
want to keep them, try transposing to d-sharp instead of e-flat.



but what strikes me is the "sus#4 b3" part, is it
a bug ? I'm using GNU LilyPond 2.18.2 and the
.ly file has a \version "2.18.2" header.


LilyPond 2.19.83 can handle triple flats (but cannot show them as notes 
because it doesn’t really know how a triple flat accidental should look 
like) so the output of the snippet above is “correct” with that version.

Re: m7.5- transposed to sus#4 b3 ??

[Thomas Morley]

Am Mo., 11. Nov. 2019 um 21:38 Uhr schrieb Sandro Santilli :
>
> I transcribed an A major song with this chords snippet:
>
>   ees:m7.5- | aes:7 | aes:m7.5- | des:7 |
>
> When transposing it to Eb major it is rendered as:
>
>   Bbbø | Ebb7 | Ebb7sus#4 b3 | Abb7
>
> I don't understand why the third chord (m7.5-)
> gets rendered as a "7sus#4 b3" chord, very hard
> to read ...
>
> Ideally I'd also like to avoid the double flats,
> but what strikes me is the "sus#4 b3" part, is it
> a bug ? I'm using GNU LilyPond 2.18.2 and the
> .ly file has a \version "2.18.2" header.
>
> --strk;
>

If you transpose the note eeses down an augmented 4th the note beseses results.

If you let the chords display in \new Staff you get a warning:
2.18.2:
warning: Transposing eeses'' by ges makes alteration larger than double
2.19.83:
warning: Could not find glyph-name for alteration -3/2

2.18.2 uses aes instead of beseses, thus the strange chord-name.

To circumvent, you could do \transpose a dis instead.


Though, tbh I doubt chords based on ees, aes, des _in_ a-major are
correct at all.
Probably some modulation/key-change before? Or copy from a weird source?

Cheers,
  Harm

Re: Very weird output on any compilation

[Carl Sorensen]

On 11/11/19, 12:59 PM, "David Wright"  wrote:

On Mon 11 Nov 2019 at 17:17:00 (+0100), David Menéndez Hurtado wrote:
> I am having trouble compiling even the simplest of scores. For example,
> this is the template from Frescobaldi, compiled with lilypond from the
> command line:
> 
> [image: Untitled.png]
> 
> The output is the same for PNG and PDF. The same problem happens with any
> other score from Mutopia. Does anyone know what is going on? I have
  
> 
> Can anyone spot what is wrong here? Is there a way to keep the temporary
> files? That may hint what is wrong.

Perhaps an old thread like this might help:

https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00521.html

Cheers,
David.


Here’s a solution that worked in the past -- it describes how DPI settings get 
set in fonconfig to 96 dpi, instead of 1200 (the lilypond default):

https://lists.gnu.org/archive/html/bug-lilypond/2017-01/msg00022.html

Carl

Re: Invisible midi layer for specific measures

[Paolo Prete]

 Thanks Aaron,
it worked perfectly.
Il lunedì 11 novembre 2019, 21:29:36 CET, Aaron Hill 
 ha scritto:  
 
 On 2019-11-11 12:16 pm, Paolo Prete wrote:
> Thank you Karl for your help.
> However, in the way you suggested, I have to repeat the music of the
> first \score block into the second \score block for the first and
> third measure of my snippet. I would like to avoid this redundancy,
> and I would like to specify the notes of "custom" generated midi only
> for for a subset of specific measures.

Variables and tags are helpful.  Consider:


\version "2.19.83"

asdf = \fixed c' {
  | c4 d e2
  | \tag #'display { 1_\trill }
    \tag #'midi { \repeat unfold 4 { f8 g } }
  | a4 b c'2
}

\score { \keepWithTag #'display \asdf \layout {} }
\score { \keepWithTag #'midi \asdf \midi { \tempo 1 = 60 } }



-- Aaron Hill

  

Re: midiPanPosition in midi context block

[Thomas Morley]

Hi Matt,

I had a hard time to compile your code, because your email-client
inserts not common spacers at line-begin, but something else. I didn't
bother to identify...
Please: Use plain text !!!

Here your _compilable_ example:


sopStaff = \new Staff = "sop" {
  \relative c' { e4 f g a }
}
altoStaff = \new Staff = "alto" {
  \relative c' { c4 d e f }
}
\score {
  <<
\sopStaff
\altoStaff
\context Staff = "sop" {
  \set Staff.midiPanPosition = #1.0
}
\context Staff = "alto" {
  \set Staff.midiPanPosition = #-1.0
}
  >>
  \midi { }
}

What happens is: you create two named Staffs. In score you use
simultaneous-music, i.e. << ... >>
Inside of the simultaneous-music you continue or amend or ... (don't
know the correct english term) the already started Staffs.
That's the meaning of
\context Staff = "foo" ...
If a Staff-context named "foo" exists continue with it otherwise
create a new one, named "foo"

Thus, \set Staff.midiPanPosition is added to the relevant Staff

Am Mo., 11. Nov. 2019 um 14:03 Uhr schrieb Matt Wallis :
>
> On 08/11/2019 14:30, David Kastrup wrote:

> ... which works. But now I'm worried, because the example I copied was from 
> other code I have written. Is this another abomination?

No abomination, LilyPond is fine with it, but I'd never code it that way.
Context-settings for the whole context belog into \with or the score-
or even book-layout, imho.
Ofcourse \with ... can be stored in a variable.

> Perhaps someone could point me to the relevant syntax reference docs that say 
> (or at least imply) that my original abomination is illegal syntax, and to 
> check that my amendment (above) is valid syntactically. I've had a look for 
> some reference material, and found this 
> (http://lilypond.org/doc/v2.19/Documentation/notation/contexts-explained):
>
> "Output definitions define the relation between contexts as well as their 
> respective default settings. While most changes will usually be made inside 
> of a \layout block, Midi-related settings will only have an effect when made 
> within a \midi block."

I think there's a misunderstanding.
The command \context can be used at different places with different
syntax and meaning.
Look at:

\score {
  <<
\context Voice = "foo" { R1*2 }
\new Voice {
  R1
  \break
  \context Score
  \applyContext
#(lambda (ctx)
   (pretty-print ctx)
   (ly:context-set-property! ctx 'barAlways #t))
  \repeat unfold 8 b8
}
  >>

  \layout {
\context {
  \Voice
  \override MultiMeasureRest.color = #green
}
  }
}

The first occurrence is done to initiate a certain named context (if
not already  there), as explained above.
The second occurrence specifies the context the procedure should be
applied to. Comment "\context Score" and it will not work any more.
Admittedly this whole command could be written more easily, I used
this way to demonstrate a certain aspect of \context.
With the third occurence in score-layout, first the definition for
Voice is copied and then amended with the override.

Your example code relies only on the first mentioned possibility, as
far as the \context-command is meant, actually the context is modified
by the \set-command.

> This does little to discourage my abomination. Also, it makes me suspect that 
> my code above (with the context block within the score)

Well, what's a context-block?
You modify the contexts there with \set
Else, see above.

> is also working only by accident (because it sets midi settings outside the 
> midi block). So, am I right in thinking that the only legal place for midi 
> settings for a Staff as inside the original definition of that Staff?

Contexts can be modified by setting context-properties (among others).
They can be specified in book- or score-layout/midi. Syntax:
\layout {
  \context {
\WhatEverContext
whatEverContextProperty = 
  }
}

Or in \with... Syntax:
\new/context WhatEverContext \with { whatEverContextProperty =  }

Or "on the fly". Syntax:
{
  
  \set WhatEverContext.whatEverContextProperty = 
  
}

Actually your example demonstrated only the last case.
I recommend to reread the docs. Probably the examples above help ...

HTH,
  Harm

P.S. Did I mention:
Please always use plain text !!

lilyglyphs: Python 2 deprecation

[Werner LEMBERG]

On the TeXLive mailing list, Norbert Preining , one
of the maintainers of TeXLive posted the following today.

  With the end of 2019, Python2 will be deprecated and not receive any
  security updates.  Most distributions will throw out Python2
  completely.  (Don't ask me about my opinion on the whole Py2/Py3
  mess ...)

  We have quite a lot of scripts in TeX Live that are Python2 only,
  and we should seriously do some work on getting that fixed, rather
  soon.

  I have started a list of packages/scripts I found that require python,
  and tried to check which version they need, see below list.
 
  If you are the maintainer of any of these packages, and still are using
  Python2, please try to update to Python3 as soon as possible.

...
lilyglyphs/
  py2 only
  lilyglyphs/lily-glyph-commands.py
  lilyglyphs/lily-image-commands.py
  lilyglyphs/lily-rebuild-pdfs.py
  lilyglyphs/lilyglyphs_common.py
...

This package is written by Urs Liska , who is
quite busy these days.  In case you have experience with Python 2 to 3
conversion, please help produce a new version!


Werner

Re: lilyglyphs: Python 2 deprecation

[Martin Tarenskeen]

On Tue, 12 Nov 2019, Werner LEMBERG wrote:


 If you are the maintainer of any of these packages, and still are using
 Python2, please try to update to Python3 as soon as possible.

   ...
   lilyglyphs/
 py2 only
 lilyglyphs/lily-glyph-commands.py
 lilyglyphs/lily-image-commands.py
 lilyglyphs/lily-rebuild-pdfs.py
 lilyglyphs/lilyglyphs_common.py
   ...

This package is written by Urs Liska , who is
quite busy these days.  In case you have experience with Python 2 to 3
conversion, please help produce a new version!


Should it still be backwards compatible with Python 2.7 if possible or is 
it ok to drop Python2 backwards compatibility completely? Option one is 
possible, option two gives cleaner code, and is easier to maintain in 
future.


MT