Re: Flex on macOS

[Hans Åberg]

> On 1 Aug 2023, at 10:24, Jean Abou Samra  wrote:
> 
> pre,code,address { margin: 0px; } h1,h2,h3,h4,h5,h6 { margin-top: 0.2em; 
> margin-bottom: 0.2em; } ol,ul { margin-top: 0em; margin-bottom: 0em; } 
> blockquote { margin-top: 0em; margin-bottom: 0em; } 
> Le lundi 31 juillet 2023 à 22:29 +0200, Hans Åberg a écrit :
>> 
>> 
>> Apple has patched their version of Flex so that the generated .cc file must 
>> be used with their header FlexLexer.h.
> 
> I don't think this is the problem. Before I installed Flex from Homebrew, the 
> only Flex installation was the system one, so it must have been using the 
> system FlexLexer.h.

It depends on where the compiler looks. In addition, the header has changed 
between the Flex versions, for some time it was broken. The fact that 
FlexLexer.h is system installed, as opposed in the source directory, as in the 
case of Bison, causes problems.

Re: Flex on macOS

[Hans Åberg]

> On 31 Jul 2023, at 01:15, Jean Abou Samra  wrote:
> 
> I noticed that the macOS-provided flex version (on the MacStadium node 
> provided
> by Marnen, which runs the unsupported macOS Catalina) was ~10 years old, so I
> installed Flex from Homebrew (required setting CPPFLAGS + LDFLAGS + PATH as
> advised in the Homebrew log messages), and it went fine.

Apple has patched their version of Flex so that the generated .cc file must be 
used with their header FlexLexer.h.

Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail

[Hans Åberg]

> On 5 Feb 2023, at 13:54, Werner LEMBERG  wrote:
> 
> I see the following error:
> 
> rational.cc:68:33: error: call to 'abs' is ambiguous
>  num_ = static_cast (::abs (n));
>^
> /usr/include/stdlib.h:129:6: note: candidate function
> int  abs(int) __pure2;
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:664:1: 
> note: candidate function
> abs(float __lcpp_x) _NOEXCEPT {return fabsf(__lcpp_x);}
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:668:1: 
> note: candidate function
> abs(double __lcpp_x) _NOEXCEPT {return fabs(__lcpp_x);}
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:672:1: 
> note: candidate function
> abs(long double __lcpp_x) _NOEXCEPT {return fabsl(__lcpp_x);}
> ^

> I'm not a C++ expert, but maybe there is a simple fix
> available?

The ::abs you use, instead of std::abs, is a C compatibility function that the 
C++ allows to be defined in the global namespace, and what I can see the effect 
depends on the compiler. Older compilers may only have the function int 
abs(int) there, and use type conversion before the call, like converting 
int64_t to int. When testing the latest GCC and Clang, there seems to be no 
difference. Also, include the proper C++ headers,  instead of 
, as results also may depend on the compiler.

Re: Turkish makam

[Hans Åberg]

> On 18 Jan 2023, at 05:07, Adam Good  wrote:
> 
> Let's take the makam Rast:
> 
> g a bfc c d e fb
> 
> the pitch g just happens to be the finalis...every song or instrumental
> composition will have a melody that must end on that pitch. And the
> accidentals say "b one koma flat" and "f four koma sharp" so I'll add those
> in my key signature which, using turkish-makam.ly
> 
> \key g \rast

One issue is that if wanting to use different finalis, then they might prefer 
to give another name. LilyPond, on the other hand, requires the note to be 
indicated.

So extension might be to have the signature note as default. Say
or
  \key \rast
  \signature \rast
expanding to
  \key g \rast
  

Re: Turkish makam

[Hans Åberg]

> On 16 Jan 2023, at 10:30, Luca Fascione  wrote:
> 
>> On Sun, Jan 15, 2023 at 3:49 PM Hans Åberg  wrote:
>> As the full number of Turkish makam is very large, perhaps too many to have 
>> in this file, there might be a turkish-makam-extended for the less common 
>> ones.
> Being it said that I'm not clear what the harm is when a file of this kind(*) 
> gets big,
> I would like to bring up that "-extended" is a naming pattern that is likely 
> to create trouble, 
> because there's no obvious rule, given makam "X" to know in which file it 
> belongs.
> In turn this will make the separation annoying for users, and will create 
> potentially annoying
> discussion among contributors when a missing makam needs to be added.
> 
> If the file must be broken up (and again, I'm doubtful it has to), it seems 
> to me that it
> would serve everybody much better if the naming was more descriptive of the 
> content

Adam Good said he put them in the new file, and that seems best unless other 
issues arise.

> --> I don't know anything about Turkish music, …

Rather than transposing existing makam, they prefer to give new names, and in 
addition, in the common AEU notation system, the symbols ♯ and 턪 are not the 
sharp and doublesharp of Pythagorean tuning, but microtonal accidentals, so the 
accidentals of key signatures and otherwise will transpose in peculiar manner. 
Also, one may not write out all accidentals in the key signature, but it is 
common to write the name of the makam above it.

I described the theoretical background in the post below:
https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00187.html

Re: Turkish makam

[Hans Åberg]

> On 16 Jan 2023, at 02:29, Adam Good  wrote:
> 
> On Sun, Jan 15, 2023 at 9:49 AM Hans Åberg  wrote:
> 
> As the full number of Turkish makam is very large, perhaps too many to have 
> in this file, there might be a turkish-makam-extended for the less common 
> ones.
> 
> The turkish-makam.ly file contains if I remember correctly, key signature 
> definitions for just over 200 different makams. These I grabbed via various 
> sources (books and online) and contain many (mostly?) less known makams. If 
> anyone finds anything that's not in there let me know!

Fine! —Having them all in a single file is easier to use, and computers are so 
fast these days, it likely does not matter.

If one would wants to transition from the original “makam.ly 
<http://makam.ly/>” to ”turkish-makam.ly <http://turkish-makam.ly/>", what 
changes would be needed to be done (disregarding the MIDI tuning)? —There is 
“convert-ly” that might do the changes. It could then be deprecated and removed.

Re: Turkish makam

[Hans Åberg]

> On 15 Jan 2023, at 14:45, Adam Good  wrote:
> 
> Hans and Werner,
> For a couple reasons, I deliberately used the name turkish-makam.ly to make
> a distinction and clarity between the Arabic and Turkish varieties of
> (respectively) maqam and makam theory and notation systems. Also I do have
> ideas for another .ly file in the future turkish-usul.ly which will give
> defintions for rhythmic aspects of Turkish classical music. "Usul" is
> basically the rhythmic equivalent in study and theory to "makam". The two
> files would conveniently live right next to one another in the ly
> directory. And the usul file will be large enough that I'd much rather not
> use that material in the turkish-makam file.
> 
> Though I'm forever grateful for the original makam.ly include file. I'd
> much prefer to use the name turkish-makam.ly and could easily see makam.ly
> simply disappear for the next release. turkish-makam is a huge upgrade.

As the full number of Turkish makam is very large, perhaps too many to have in 
this file, there might be a turkish-makam-extended for the less common ones.

Re: Turkish makam

[Hans Åberg]

> On 14 Jan 2023, at 08:06, Werner LEMBERG  wrote:
> 
>>> Too bad that `makam.ly` is essentially undocumented...
>> 
>> From what I can see, makam.ly is the original faulty file, only
>> there for backwards compatibility, which might be removed if there
>> is no need for that.
> 
> We could make it become deprecated in the next release, to be
> completely removed in the release after.

If there are no compatibility issues, perhaps turkish-makam.ly 
 might be renamed makam.ly . Adam 
Good might give his view.

Re: Turkish makam

[Hans Åberg]

> On 13 Jan 2023, at 19:03, Werner LEMBERG  wrote:
> 
>> [...] a possible future change could be, say,
>> 
>>  \include "arabic.ly"
>>  \language "arabic-hel"
>> 
>> but I don't see much benefit for that.
> 
> Hmm, probably it *is* the way to go – this is exactly what is done in
> `makam.ly` and `turkish-makam.ly`.  Too bad that `makam.ly` is
> essentially undocumented...

From what I can see, makam.ly is the original faulty file, only there for 
backwards compatibility, which might be removed if there is no need for that. 
The file turkish-makam.ly  is the corrected one 
written by Adam Good.

I described the theoretical background in the post below:
https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00187.html

Re: Oriental microtonal music

[Hans Åberg]

> On 29 Dec 2022, at 23:35, Karlin High  wrote:
> 
> My email address was in the To: header.
> 
> In Cc: were the other people I had mentioned here:
> 
> 
> 
> Therefore, I understood that post as a response to my question about which 
> available participants in the LilyPond community could advise on code reviews 
> for Oriental microtonal music.
> 
> A threading disconnect at worst.

Deliberately a new thread, as it is a wholly different topic:

I supplied the information the LilyPond developers might need for doing code 
reviews on their own, in view of that the people mentioned there, including me, 
and the two others, cc-ed here, likely do not want to be involved with that.

Oriental microtonal music

[Hans Åberg]

Graham Breed wrote a file regular.ly  that allows for 
retuning into any ET (around C4, not A4), but Adam Good is expert on Turkish 
music specifically.

There are some issues with Turkish, Persian and Arabic music that must be dealt 
with when adapting for LilyPond: Notation system limitations, transposability, 
and MIDI output.

Because of those issues, I would prefer to use Helmholtz-Ellis notation. There, 
LilyPond does not have the double arrowhead accidentals.

Though Persian music is transposed, in Turkish makam and Arabic maqam, one may 
rename. In LilyPond, transposability is hard wired, so some care must be taken 
here: Turkish music has different notation systems, but the common AEU 
(Arel–Ezgi–Uzdilek) is not transposable, as its sharp ♯ and and doublesharp 턪 
represents microtonal accidentals, not the ordinary ones. AEU also writes the 
pitch a 4th above the sounding pitch.

As for MIDI, the traditional tuning is Pythagorean tuning with Pythagorean 
commas for microtonal alterations in Turkish music, though with departures in 
actual performance. In Arabic and Persian music, these have drifted 
considerably, the double is a possibility.

LilyPond does not support exact Pythagorean tuning, but it could be replaced by 
E₅₃ (53 ET) by the use of regular.ly  if included in the 
distribution. An alternative that does not require this file is E₇₂ (72 ET), 
which relative E₅₃ and Pythagorean tuning changes the diatonic scale into E₁₂ 
(12 ET), but alters the microtonal neutral seconds only with a few cents.

I believe that Adam Good used E₇₂ for the rewritten Turkish makam file.

The original LilyPond makam file had an error making it not transposable:

E₅₃ has minor second m = 4, major second M = 9 commas (E₅₃ tonesteps), so that 
the sharp ♯ = 9 - 4 = 5 commas, and the Pythagorean comma is approximated by 1 
E₅₃ tonestep, also called a comma. Therefore, in E₅₃, one arrives at the 
microtonal alteration of one comma by dividing the E₅₃ M by 9 or the E₅₃ ♯ by 5.

A type of error one sees though, is that these last rules are not applied to 
E₅₃ but to E₁₂:

In the original LilyPond file, they reasoned to divide the M of E₁₂ further in 
form of the LilyPond accidental, which is internally represented as a rational 
number where ♯ is 1/2. So the doublesharp 턪, which has a value 1, is divided by 
9, but unfortunately the ♯  of 1/2 is not then an integral multiple of that. 
The new one by Adam Good corrects this issue.

If the ♯ of E₁₂ is divided to 5 parts, one arrives at E₆₀, which is done in a 
suggested Persian file. The Arabic files written so far use E₂₄, possibly 
because LilyPond did not have the rational accidentals originally, but only 
this 24 ET.

Re: Prefer luatex for documentation

[Hans Åberg]

> On 19 Nov 2022, at 11:19, Werner LEMBERG  wrote:
> 
> In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I
> suggest that we prefer luatex for building the documentation.  What do
> people think?

The people that developed LuaTeX also developed ConTeXt, but the latter has now 
switched to LMTX (LuaMetaTeX). This means that the font support has been varied 
between the two. I found it difficult to extract the ConTeXt parts for use with 
LuaTeX only, but that may be how LaTeX does it.

Re: Mac Unofficial bundle

[Hans Åberg]

> On 12 Nov 2022, at 20:16, Jeremiah Benham  wrote:
> 
> Does anyone here know how the unofficial Mac bundle was created? I assume
> it was not created using gub. Was it macports? Is there a script you guys
> use to slurp up all the files into a bundle or how are you crating it?

The current one at the site is not MacPorts, which creates an installer. I made 
one at some past point in time, but it turns out that not all references are 
within the installation itself, into /opt/lilypond/, so it is better to use 
proper MacPorts. Also, see the User list discussion below on that the package 
at the site does not have all Ghostscript stuff in it found in MacPorts or 
TexLive.

https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00045.html

Re: 64-bit MacBook Air M2 problems

[Hans Åberg]

> On 15 Aug 2022, at 17:57, Jean Abou Samra  wrote:
> 
> Also, when you enter the apostrophe from the keyboard, is it really
> a straight apostrophe  ->   '   <-  or could it be that macOS does
> you the “favor” to replace it with a curly apostrophe ->’ <- ?
> LilyPond expects straight apostrophes. If this is the problem, you need
> to fix your macOS settings somewhere to prevent those “smart quotes”.

One can turn those off at System Preferences → Keyboard → Text → Use smart 
quotes and dashes. Those are reachable at least from the keyboard map I am 
using, so I decided to type them by hand at need.

Also, one can add custom text replacements, which I use for example for the 
arrows above.

MacPorts clang dependency

[Hans Åberg]

The MacPorts page below says that lilypond-devel (and also lilypond) depends on 
clang-13, however, clang-14 has now been released. Curiously, 'port info 
lilypond-devel' does not mention clang at all. Also, the dependency on Guile is 
listed as guile, which I figure will be Guile 3 when updated in MacPorts.

https://ports.macports.org/port/lilypond-devel/details/

Re: compiling MacOS application in LilyDev

[Hans Åberg]

> On 9 Nov 2021, at 19:06, Kieren MacMillan  
> wrote:
> 
>> The intent is probably to create an app.
> 
> Yes, for me to run (personally).
> 
>> One can make installers with MacPorts, I posted some on the users list.
> 
> I found that thread — helpful!
> 
> I tried, and got:
> 
> Error: Failed to activate dbus: Image error: 
> /Library/LaunchAgents/org.freedesktop.dbus-session.plist already exists and 
> does not belong to a registered port.  Unable to activate port dbus. Use 
> 'port -f activate dbus' to force the activation.
> 
> I tried that, …

I do not have dbus. A net search on that error line gives various suggestions.

If you want reinstall MacPorts, this command lists the requested installs:
  port echo requested | cut -d ' ' -f 1 | uniq
It is from
  https://trac.macports.org/wiki/Migration

Re: compiling MacOS application in LilyDev

[Hans Åberg]

> On 9 Nov 2021, at 19:06, Kieren MacMillan  
> wrote:
> 
> Hi Hans,
> 
>> The intent is probably to create an app.
> 
> Yes, for me to run (personally).
> 
>> One can make installers with MacPorts, I posted some on the users list.
> 
> I found that thread — helpful!
> 
> I tried, and got:
> 
> Error: Failed to activate dbus: Image error: 
> /Library/LaunchAgents/org.freedesktop.dbus-session.plist already exists and 
> does not belong to a registered port.  Unable to activate port dbus. Use 
> 'port -f activate dbus' to force the activation.
> 
> I tried that, and got
> 
> dlopen(/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib, 6): Symbol 
> not found: _iconv
>  Referenced from: /usr/lib/libcups.2.dylib
>  Expected in: /opt/local/lib/libiconv.2.dylib
> in /usr/lib/libcups.2.dylib
>while executing
> "load /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib"
>("package ifneeded macports 1.0" script)
>invoked from within
> "package require macports"
>(file "/opt/local/bin/port" line 46)
> 
> Advice?


The link [1] suggests it has to do with some DYLD_* environment variables. I 
have /opt/local/* additions only to PATH, and optionally to MANPATH and 
INFOPATH.

1. 
https://stackoverflow.com/questions/30420695/dyld-symbol-not-found-iconv-when-using-javac-to-compile-on-macos

Re: compiling MacOS application in LilyDev

[Hans Åberg]

> On 9 Nov 2021, at 19:06, Kieren MacMillan  
> wrote:
> 
> Hi Hans,
> 
>> One can make installers with MacPorts, I posted some on the users list.
> 
> I found that thread — helpful!
> 
> I tried, and got:
> 
> Error: …

You tried what? Making your own installer from MacPorts? —The ones I do install 
in /opt/lilypond/, and you use /opt/lilypond/ it looked like. The location I 
use is suggested by the FHS (file hierarchy standard) and Werner.

One issue is that /opt/lilypond/bin/ must be in PATH, otherwise some programs 
like 'gs' will not be called.

I can post the steps I use to make the installer if you so want.

It might be of interest if you try making a universal installer, but it would 
likely involve getting touch with the MacPorts people for help.

Re: compiling MacOS application in LilyDev

[Hans Åberg]

> On 9 Nov 2021, at 00:50, Karlin High  wrote:
> 
> On 11/8/2021 4:55 PM, Kieren MacMillan wrote:
>> I’m on 10.13.6 (High Sierra)
> 
> High Sierra can still run 32-bit, right? That could allow for using GUB on 
> LilyDev to produce a standard macOS installer.

The intent is probably to create an app. One can make installers with MacPorts, 
I posted some on the users list. They are for a specific MacOS version. One can 
also make universal installers, but some component did not compile when I 
tried. Also, LilyPond can overflow on 32-bit: some issue resolved when I 
switched to the MacPorts version which is 64-bit. So only use the 32-bit 
version if 64-bit is not available, I think.

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 26 Sep 2021, at 10:16, Jean Abou Samra  wrote:
> 
> Le 26/09/2021 à 09:57, Hans Åberg a écrit :
>>> On 26 Sep 2021, at 06:49, Werner LEMBERG  wrote:
>>> 
>>> You might provide a MR, maybe it gets accepted.  I still doubt that it
>>> would be a good idea.
>> There is a conflict in some contexts between {SYMBOL} and {COMMAND}, so may 
>> not work. To get a regular COMMAND syntax, they should start with something 
>> that SYMBOL does not.
>> 
>> Otherwise you might replace the function YYText_utf8 with proper UTF-8 
>> patterns, a variation of:
>> 
>> /* UTF-8 character with valid Unicode code point. */
>> utf8char
>> [\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF]([\x80-\xBF]{2})|\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|[\xF1-\xF3]([\x80-\xBF]{3})|\xF4[\x80-\x8F]([\x80-\xBF]{2})
> 
> I concur with Werner.I don't think special characters like ×
> are easier to type than a backslash, and they are an annoyance if
> you don't have keyboard shortcuts at hand (like on a computer that
> is not your primary work device). They require more effort
> for beginners and memory of keyboard input methods for everyone.
> Plus, it's not clear how to make them work in lyrics mode and
> markup given that something like \lyricmode { ×8 } is already
> valid syntax and has legitimate uses.

I use text substitutions, which I have found to be fastest both to create and 
use. For example, I have set ".x" to translate to "×".

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 26 Sep 2021, at 06:49, Werner LEMBERG  wrote:
> 
 The idea here is different, it is for identifiers, and in the
 input syntax only, does not change the internal semantics at all.
 It is good not having to type backslash when a command is used.
>>> 
>>> Really?  I highly doubt that.  In particular, what about lyrics
>>> mode?
>> 
>> The idea would be to change the file lexer.ll by adding U and
>> UCOMMAND:
>> 
>> A[a-zA-Z\200-\377]
>> U[\200-\377]
>> AA   {A}|_
>> N[0-9]
>> ANY_CHAR (.|\n)
>> SYMBOL   {A}([-_]{A}|{A})*
>> COMMAND  \\{SYMBOL}
>> UCOMMAND {U}{SYMBOL}
>> 
>> Then in select places, that is context switches, add {UCOMMAND}:
>>  {COMMAND}   {
>>  return scan_escaped_word (YYText_utf8 () + 1);
>>  }
>>  {UCOMMAND}  {
>>  return scan_escaped_word (YYText_utf8 ());
>>  }
> 
> You might provide a MR, maybe it gets accepted.  I still doubt that it
> would be a good idea.

There is a conflict in some contexts between {SYMBOL} and {COMMAND}, so may not 
work. To get a regular COMMAND syntax, they should start with something that 
SYMBOL does not.

Otherwise you might replace the function YYText_utf8 with proper UTF-8 
patterns, a variation of:

/* UTF-8 character with valid Unicode code point. */
utf8char
[\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF]([\x80-\xBF]{2})|\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|[\xF1-\xF3]([\x80-\xBF]{3})|\xF4[\x80-\x8F]([\x80-\xBF]{2})

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 25 Sep 2021, at 19:25, Werner LEMBERG  wrote:
> 
 Perhaps the LilyPond syntax might be tweaked so that identifiers
 starting with a UTF-8 multi-byte (high bit set) character do not
 need the backslash.  Then simply ×2 would look good.
>>> 
>>> This reminds me of TeX's 'active characters'.  I think we shouldn't
>>> go this route.  IMHO, a command should always be introduced with a
>>> backslash.
>> 
>> The idea here is different, it is for identifiers, and in the input
>> syntax only, does not change the internal semantics at all.  It is
>> good not having to type backslash when a command is used.
> 
> Really?  I highly doubt that.  In particular, what about lyrics mode?

The idea would be to change the file lexer.ll by adding U and UCOMMAND:
A   [a-zA-Z\200-\377]
U   [\200-\377]
AA  {A}|_
N   [0-9]
ANY_CHAR(.|\n)
SYMBOL  {A}([-_]{A}|{A})*
COMMAND \\{SYMBOL}
UCOMMAND{U}{SYMBOL}

Then in select places, that is context switches, add {UCOMMAND}:
{COMMAND}   {
return scan_escaped_word (YYText_utf8 () + 1); 
}
{UCOMMAND}  {
return scan_escaped_word (YYText_utf8 ());
}

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 25 Sep 2021, at 18:37, Werner LEMBERG  wrote:
> 
>>> And I think it would be nice to have an even more natural variant
>>> for that; I think it's reasonable to provide & show/recommend
>>> convenient solutions for standard tasks (rather than say "you can
>>> define your own abbreviation here if you know how to do so") - for
>>> example,
>>> 
>>> \*2 ""or\x2 ""
>>> 
>>> which would be my favourite.
>> 
>> Perhaps the LilyPond syntax might be tweaked so that identifiers
>> starting with a UTF-8 multi-byte (high bit set) character do not
>> need the backslash.  Then simply ×2 would look good.
> 
> This reminds me of TeX's 'active characters'.  I think we shouldn't go
> this route.  IMHO, a command should always be introduced with a
> backslash.

The idea here is different, it is for identifiers, and in the input syntax 
only, does not change the internal semantics at all. It is good not having to 
type backslash when a command is used.

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 25 Sep 2021, at 17:47, Lukas-Fabian Moser  wrote:
> 
> And I think it would be nice to have an even more natural variant for that; I 
> think it's reasonable to provide & show/recommend convenient solutions for 
> standard tasks (rather than say "you can define your own abbreviation here if 
> you know how to do so") - for example,
> 
> \*2 ""or\x2 ""
> 
> which would be my favourite.

Perhaps the LilyPond syntax might be tweaked so that identifiers starting with 
a UTF-8 multi-byte (high bit set) character do not need the backslash. Then 
simply ×2 would look good.

As for typing such characters, I found text substitutions efficient, which is 
supported by some editors and OS text services. So in my system, if I type ".x" 
it translates into ×.

Re: SMuFL name mapping update, 9 July

[Hans Åberg]

I suspected that. :-) It would be good if one could use the Bravura font 
without external files, which perhaps should be integrated into the LilyPond 
distribution.


> On 11 Jul 2021, at 01:33, Owen Lamb  wrote:
> 
> Thanks for the suggestion, Hans!
> 
> Unfortunately, I have next to zero experience actually designing new glyphs, 
> so I'm not (yet?) the guy to ask about that. Right now, my number-one 
> priority is making our existing font SMuFL-compliant and giving LilyPond 
> SMuFL support, after which (I stress: I can make no promises) I *might* try 
> my hand at expanding Emmentaler in a couple areas.
> 
> Owen
> 
> On 7/10/2021 6:29 AM, Hans Åberg wrote:
>>> On 10 Jul 2021, at 04:09, Owen Lamb  wrote:
>>> 
>>> A bit of news on the SMuFL front. I've dropped in the next few Emmentaler 
>>> categories (Default Noteheads, Special Noteheads, and Shape-note 
>>> Noteheads), so feel free to give it a look at 
>>> https://wolfgangsta.github.io/emmentaler-bravura/. Please let me know what 
>>> you think, especially regarding the red "contentious" cells!
>> It would be nice with the Helmholtz-Ellis accidentals with one and two 
>> arrows up and down. They fill up the microtonal accidentals in E72 (and also 
>> E53), in addition to exact quartertones, which can be used with LilyPond.
>> https://w3c.github.io/smufl/latest/tables/extended-helmholtz-ellis-accidentals-just-intonation.html
>> 
>> There was a proposal, but was not realized.
>> https://lists.gnu.org/archive/html/lilypond-devel/2018-10/msg00097.html
>> 
>> 
> 

Re: SMuFL name mapping update, 9 July

[Hans Åberg]

> On 10 Jul 2021, at 04:09, Owen Lamb  wrote:
> 
> A bit of news on the SMuFL front. I've dropped in the next few Emmentaler 
> categories (Default Noteheads, Special Noteheads, and Shape-note Noteheads), 
> so feel free to give it a look at 
> https://wolfgangsta.github.io/emmentaler-bravura/. Please let me know what 
> you think, especially regarding the red "contentious" cells!

It would be nice with the Helmholtz-Ellis accidentals with one and two arrows 
up and down. They fill up the microtonal accidentals in E72 (and also E53), in 
addition to exact quartertones, which can be used with LilyPond.
https://w3c.github.io/smufl/latest/tables/extended-helmholtz-ellis-accidentals-just-intonation.html

There was a proposal, but was not realized.
https://lists.gnu.org/archive/html/lilypond-devel/2018-10/msg00097.html

Re: lilypond on Apple silicon

[Hans Åberg]

> On 16 Jan 2021, at 13:05, Werner LEMBERG  wrote:
> 
> According to
> 
>  https://ports.macports.org/port/lilypond/summary
> 
> the problems with the dependencies have been fixed; this means that
> lilypond should now install fine using MacPorts on Apple silicon.

I tried building lilypond-devel with +universal, first editing 
/opt/local/etc/macports/macports.conf, setting universal_archs, but it failed 
on some x86_64 component even without arm64, I think. It would seem possible to 
make a fat installer for more MacOS versions, but some of the MacPorts people 
would have to help out on that.

Re: tie over clef change

[Hans Åberg]

> On 28 Sep 2020, at 00:26, Lukas-Fabian Moser  wrote:
> 
>>> However, this gets *never* notated as such.
>>> 
>> I gave the example of augment sixth chords, that seem to never be notated as 
>> diminished sevenths.
>> 
>> https://en.wikipedia.org/wiki/Augmented_sixth_chord
> I assume you meant "dominant sevenths"?

Right. Typo.

> (Augmented sixth chords, at least "Italian" and "German" augmented sixths, 
> are identical to dominant sevenths without or with fifth on a modern 
> keyboard, e.g. c-e-[g]-a♯ vs. c-e-[g]-b♭, but none of them yield diminished 
> sevenths.)

They are equal in E12, but not in the staff system or in an orchestra.

> But anyway, I'm not sure that your statement holds true invariably: I'm 
> pretty sure that in late 19th century composers like Bruckner, the difference 
> between both chords becomes blurry. I will see if I can find an example, 
> maybe even older than Bruckner.

Some composers though seem to be careful about the difference, and it is a bit 
curious why.

> On a related but different note, I always found it funny how certain editors 
> of Mozart's Requiem, of all things, tried to "improve" Mozart's 
> chromatic/enharmonic spelling. See the old Peters vocal scores on IMSLP at 
> the end of the "Confutatis maledictis"
> 
> 
> 
> vs. the original Mozart spelling (which Süßmayr preserved faithfully):
> 
> 

Because of such a practise, one would have to go back to originals or use 
Urtext which have footnotes about the changes.

> I would not claim that this change generates any measurable difference in 
> what the musicians actually play and sing, but I imagine it changes the way 
> they _think_ their lines.

This is an important point, I think. One should notate the musical intent, not 
merely as a line of notes. For example, ornaments do not necessarily become 
clearer if written out explicitly, but the converse may happen.

There is a difference between the type of music: Jazz is pretty much E12, and 
the Mehegan Jazz Improvisation books use enharmonic equivalents without 
discrimination, if I remember it correctly.

> In particular, I like Mozart's notation for the clarity with which he 
> expresses that he uses the diminished seventh as a triple-leading tone 
> neighbour to the ensuing dominant seventh - not to mention the fact that this 
> exact device is all over the place in the second half of the Confutatis, and 
> it's frankly silly to change it just once, only to avoid a double flat...

I did try to measure a dominant 7th chord in some Beethoven's orchestral work, 
I think it was, and from what I could see, they just play stacked thirds. Not 
the 7th partial, as has been suggested. Also, I used to play along with a 
meantone tuning with some Balkan piece, it may have been a Paidushko with Petko 
Radev on clarinet, and I found that it did not blend well. So when I measured 
the clarinet, I found it was a comma off, suggesting he is playing in 
Pythagorean tuning.

As for spelling, the violin pizzicato in the tune below is in F♯ harmonic 
minor, so when written out, one gets an E♯, not an F. If one plays along with 
an E12 instrument, it sounds a bit of tune, even adjusted for pitch as it is an 
original analog recording. I originally thought it might be because of the 
pizzicato, which stretches the octave, but perhaps it is because there are no 
other good pitch references on the violins.

https://www.youtube.com/watch?v=wvSNAfSaezk=PLJ2I_U9XF3oDMwyVjAULrShxZKWlmHOGy=6

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 22:17, Werner LEMBERG  wrote:
> 
>>> It is common, for example, for a composer to write D sharp for some
>>> instruments and E flat for others.
>> 
>> A composer should write so that it becomes easy for the musician to
>> perform, otherwise they will have to edit the score, which costs
>> time and money.  The musicians then listens to the other musicians
>> and adapt so it sounds right—this is what one of my flute teachers
>> said, who sits in an opera here.  Or modern composers just haven't
>> checked it out. Some do, though.
> 
> Well, almost all orchestra musicians think linearly, this is,
> horizontally, not vertically.  Consequently, composers (at least up to
> the late romantic era) write music that can be easily read linearly.
> This is what sometimes leads to have d sharp and e flat at the same
> time.

Right. For example, on older clarinets, it was difficult to switch between 
flats and sharps, having B♭ and A clarinets, so it must be written for that. 
With modern mechanics, it does not matter so much.

> Hans, please note that your opinion is that of a minority IMHO.  

You are free to implement whatever you like, as you are ones doing it.

> In
> all classical, romantic, or impressionistic scores that I'm aware of,
> pitches of enharmonic changes are completely insignificant.  Musicians
> are expected to automatically adjust the pitch so that it sounds ok
> within chords.  

They will adjust even if it is written it enharmonically wrong. But if one is 
choosing it wrong on an instrument that can play it accurately, one gets a wolf 
interval, which sounds like it is named.

> However, this gets *never* notated as such.

I gave the example of augment sixth chords, that seem to never be notated as 
diminished sevenths.
https://en.wikipedia.org/wiki/Augmented_sixth_chord

> Consequently, we have ties between enharmonic changes and not slurs.

Whatever.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 22:01, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser  wrote:
>>> 
>>>> I seem to remember that even in Bach's B minor mass (where E12 was not
>>>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>>>> in the transition from "Confiteor" to "Et expecto".  I mean, that
>>>> transition is a tonal center nightmare anyway.
>>>> 
>>> In bar 138:
>>> 
>>> 
>>> 
>>> Basically that is an example of enharmonic equivalence of diminished
>>> 7th chords: The tonal centre in the preceding bars is clearly d (d
>>> major with hints of d minor), so the diminished chord in bar 138 is
>>> most probably first heard as f♯-a-c-e♭ (with expected resolution to
>>> g minor), but is then being re-interpreted (and written) as
>>> f♯-a-b♯-d♯, resolving to c♯ major functioning as a dominant to f♯
>>> minor.
>>> My point is: Even without E12 tuning, this is clearly an example of
>>> fully exploited enharmonic equivalence used as a "wormhole" in an
>>> otherwise purely diatonic tonal system. There can be no question
>>> that this is semantically a tie.
>>> 
>>> (One might raise the objection that, maybe, when performing the
>>> piece, a slight adjustment in intonation might be needed in the
>>> transition from c to b♯. But this can also happen for bona fide ties
>>> in purely diatonic music, so that does not yield an argument against
>>> the tie being a tie.)
>> 
>> I think it is the last, because E12 was not in use is the music that
>> J.S. Bach wrote. The CPP (Common Practise Period) composers are
>> careful distingushing between an augmented 6th a minor 7th in
>> chords. There is a slight adjustment from the formal point of view,
>> but for a violin to be able to express that, there needs to be some
>> pitch references, like the open strings or intervals derived from
>> that, so it may be a way to just adhere to formal writing.
> 
> The tonal center collapse is done purely vocally in an a cappella
> passage and when the instruments come back in, it's in a resurrection
> key and instrument groups (like brass) that are typical for it.
> 
> Really, you need to listen to it before sorting it into the context of
> its period.  This passage is completely out of whack with its time while
> it is arrived at from a grandiosely conservative fugue in full ars
> antiqua.
> 
> Here is a link <https://www.youtube.com/watch?v=ixFCKKIMvkk> to a
> Herreweghe version.  The piano extract displayed in parallel would
> suggest that there is, after all, an instrumental part even in the 2:30
> and finally 3:00 (or so) locations which is a bit surprising to me since
> I remember how we fought keeping the intonation in line so that the
> resurrection trumpets could fall right in.  I cannot hear instruments
> there right now but I have only builtin speakers at low volume right now
> so I may be wrong about that.

The choirs here have a high number of performers with absolute pitch. By 
contrast, most orchestral musicians don't have it, and it is easier to play 
pitches exactly with musical instruments. Some singing, like barbershop, use 
Just Intonation, and if the chords are pivoted, the pitches must slide in some 
common harmony transitions.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 20:59, Kevin Barry  wrote:
> 
>> Both cases were discussed. For an orchestra they are not the same pitch, 
>> thus formally a slur.
> 
> You cannot make this assumption. It is exceptional to distinguish D
> sharp and E flat since most performed orchestral music is equally
> tempered.

Orchestral music is in what microtonalists call adaptive 5-limit Just 
Intonation; Hindemith calls it the natural tuning. A measurement of a 
performance of a string quartet that should have been (atonal) E12 showed that 
it in reality it was in something like Pythagorean. There are not references 
for playing in E12, unless there are som such instruments added, and using 
would make the harmonies sound less focused.

> It is common, for example, for a composer to write D sharp
> for some instruments and E flat for others.

A composer should write so that it becomes easy for the musician to perform, 
otherwise they will have to edit the score, which costs time and money. The 
musicians then listens to the other musicians and adapt so it sounds right—this 
is what one of my flute teachers said, who sits in an opera here. Or modern 
composers just haven't checked it out. Some do, though.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser  wrote:
> 
>> I seem to remember that even in Bach's B minor mass (where E12 was not
>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>> in the transition from "Confiteor" to "Et expecto".  I mean, that
>> transition is a tonal center nightmare anyway.
>> 
> In bar 138:
> 
> 
> 
> Basically that is an example of enharmonic equivalence of diminished 7th 
> chords: The tonal centre in the preceding bars is clearly d (d major with 
> hints of d minor), so the diminished chord in bar 138 is most probably first 
> heard as f♯-a-c-e♭ (with expected resolution to g minor), but is then being 
> re-interpreted (and written) as f♯-a-b♯-d♯, resolving to c♯ major functioning 
> as a dominant to f♯ minor.
> My point is: Even without E12 tuning, this is clearly an example of fully 
> exploited enharmonic equivalence used as a "wormhole" in an otherwise purely 
> diatonic tonal system. There can be no question that this is semantically a 
> tie.
> 
> (One might raise the objection that, maybe, when performing the piece, a 
> slight adjustment in intonation might be needed in the transition from c to 
> b♯. But this can also happen for bona fide ties in purely diatonic music, so 
> that does not yield an argument against the tie being a tie.)

I think it is the last, because E12 was not in use is the music that J.S. Bach 
wrote. The CPP (Common Practise Period) composers are careful distingushing 
between an augmented 6th a minor 7th in chords. There is a slight adjustment 
from the formal point of view, but for a violin to be able to express that, 
there needs to be some pitch references, like the open strings or intervals 
derived from that, so it may be a way to just adhere to formal writing.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 20:20, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 27 Sep 2020, at 19:31, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
>>>>> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
>>>>> 
>>>>>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>>>>>> 
>>>>>> On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Despite Gould's “incorrect” verdict, here is an example from an old UE
>>>>>>> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
>>>>>>> over clef changes *do* happen and make sense sometimes...
>>>>>>> 
>>>>>>> I still think that LilyPond should support that, handling the tie like
>>>>>>> a slur in this case.
>>>>>> 
>>>>>> That's a very good example.  It's hard to imagine any reasonable 
>>>>>> alternative.
>>>>>> 
>>>>>> What kind of grob would an editor expect here? a Tie because it
>>>>>> connects notes of the same pitch, or a Slur because it connects
>>>>>> notes at different staff positions? (or something else?)
>>>>> 
>>>>> I'll answer my own question.  A tie from d♯ to e♭ generates a Tie
>>>>> grob, so for consistency, this should be a Tie that looks like a
>>>>> slur.
>>>> 
>>>> The notes d♯ to e♭ have different pitches in the staff notation
>>>> system, which cannot express E12 enharmonic equivalents, so this is
>>>> slur. So it should be a slur that looks like slur.
>>> 
>>> We are talking about a piano here.  It has no different keys for d♯ and
>>> e♭ and only a single manual.  A slur even across the same pitch will be
>>> executed with a separate keypress as opposed to a tie.
>> 
>> If you look down the thread, there are two different questions, when
>> expressing it in the staff notation as is, and when forcing E12
>> enharmonic equivalents onto it.
>> 
>> And not all pianos are tuned in E12, as in the case of meantone
>> tunings.
> 
> I repeat: It has no different keys for d♯ and e♭ and only a single
> manual.  Yes, I know about historical split-key instruments but that is
> not what a modern piano composer is writing for.

Both cases were discussed. For an orchestra they are not the same pitch, thus 
formally a slur.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 19:31, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
>>> 
>>>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>>>> 
>>>> On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:
>>>>> 
>>>>> 
>>>>> Despite Gould's “incorrect” verdict, here is an example from an old UE
>>>>> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
>>>>> over clef changes *do* happen and make sense sometimes...
>>>>> 
>>>>> I still think that LilyPond should support that, handling the tie like
>>>>> a slur in this case.
>>>> 
>>>> That's a very good example.  It's hard to imagine any reasonable 
>>>> alternative.
>>>> 
>>>> What kind of grob would an editor expect here? a Tie because it
>>>> connects notes of the same pitch, or a Slur because it connects
>>>> notes at different staff positions? (or something else?)
>>> 
>>> I'll answer my own question.  A tie from d♯ to e♭ generates a Tie
>>> grob, so for consistency, this should be a Tie that looks like a
>>> slur.
>> 
>> The notes d♯ to e♭ have different pitches in the staff notation
>> system, which cannot express E12 enharmonic equivalents, so this is
>> slur. So it should be a slur that looks like slur.
> 
> We are talking about a piano here.  It has no different keys for d♯ and
> e♭ and only a single manual.  A slur even across the same pitch will be
> executed with a separate keypress as opposed to a tie.

If you look down the thread, there are two different questions, when expressing 
it in the staff notation as is, and when forcing E12 enharmonic equivalents 
onto it.

And not all pianos are tuned in E12, as in the case of meantone tunings.

> I seem to remember that even in Bach's B minor mass (where E12 was not
> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
> in the transition from "Confiteor" to "Et expecto".  I mean, that
> transition is a tonal center nightmare anyway.
> 
> I'd have to consult my score to pick out the details.

It would be of interest.

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 20:58, Kevin Barry  wrote:
> 
> On Sat, 26 Sep 2020 at 19:30, Hans Åberg  wrote:
>>>>>> The notes d♯ to e♭ have different pitches in the staff notation
>>>>>> system, which cannot express E12 enharmonic equivalents, so this
>>>>>> is slur. So it should be a slur that looks like slur.
>>> 
>>> I disagree.  For all practical purposes in standard classical music,
>>> enharmonic equivalents *do* sound the same.  What you are referring to
>>> IMHO is a special case that might be controlled by a flag.
>> 
>> They do not, and the string section, that primarily stands for the pitch
>> reference, trains to slide the pitch appropriately:
> 
> In some contexts a notated D sharp and E flat are the same pitch (e.g.
> equally tempered piano music) and in some they are not (as you pointed
> out). Since this is a discussion about ties, where the note is the
> same by definition, we can assume we are dealing with the same pitch.

The staff notation pitches are different in the case of an enharmonic tie, as 
in Dan's example d♯ to e♭. You might want to have a tie here to make the 
enharmonic change explicit. —That is perhaps what you meant, but I find it 
confusing saying that d♯ to e♭ are the same pitch, because in the case of staff 
notation, they are not, even though in some music, they can be played the same.

> The question isn't whether it's a tie or a slur, but how LilyPond
> should render a tie when the two notes are not aligned (i.e. the user
> has entered a "~" indicating that it's a tie).

Say the ties are rendered as usual, but the slurs are dotted lines, and the 
phrase marks are square brackets. How do you want the output to be then?

> I agree with Gould that ties across clef changes should be avoided (I
> personally wouldn't even do it in the Liszt example posted), but I
> think LilyPond needs to handle it. I think it's quite acceptable to
> detect this situation and switch to using a slur (but I haven't looked
> at the code).

So if one makes them radically different, substituting ties and slurs for each 
other in the output would not work.

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 19:36, Dan Eble  wrote:
> 
> On Sep 26, 2020, at 13:11, Hans Åberg  wrote:
>> 
>>> 
>>> On 26 Sep 2020, at 18:50, Dan Eble  wrote:
>>> 
>>> On Sep 26, 2020, at 12:34, Hans Åberg  wrote:
>>>> 
>>>>> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
>>>>> 
>>>>>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>>>>>> 
>>>>>> What kind of grob would an editor expect here? a Tie because it connects 
>>>>>> notes of the same pitch, or a Slur because it connects notes at 
>>>>>> different staff positions? (or something else?)
> ...
>> 
>> I think the question is answered from the musical point of view: Werner's 
>> example is a tie since it is the same pitch, the same note with longer 
>> value. In your example, the pitches are formally different, and the 
>> difference is a comma in the Pythagorean tone system, so it must be a slur.
> 
> This sounds like an answer to a question I didn't ask.  I don't doubt that 
> the arc in Werner's example is semantically a tie.  What I am wondering is 
> what kind of LilyPond grob should represent the arc, and I'm thinking that it 
> should be a Slur because of its shape, not a Tie because of its purpose.

I think that slurs and ties may be rendered equally because of the legacy of 
drawing them by hand. But suppose they are different, then it should also have 
a tie look.

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 19:56, Werner LEMBERG  wrote:
> 
 The notes d♯ to e♭ have different pitches in the staff notation
 system, which cannot express E12 enharmonic equivalents, so this
 is slur. So it should be a slur that looks like slur.
> 
> I disagree.  For all practical purposes in standard classical music,
> enharmonic equivalents *do* sound the same.  What you are referring to
> IMHO is a special case that might be controlled by a flag.

They do not, and the string section, that primarily stands for the pitch 
reference, trains to slide the pitch appropriately:

In the video below, time 10:43, Brett mentions that the E (on the D string) 
against the open G, the sixth, is a bit lower than against the open A; the pure 
fourth. This is the syntonic comma 81/80, the difference between the Just 
Intonation major third 5/4, and the higher Pythagorean major third.
  https://www.youtube.com/watch?v=dW9t7Nrin_c=643

This is for adjusting towards Just Intonation, but it is necessary for 
enharmonic equivalents too, as the Pythagorean comma is the microtonal amount 
they use in Turkish music. A melody line will not sound right if not adjusted.

>> I can think of special cases: Perhaps the tie and the slur are
>> rendered slightly differently, say of different thickness, so in
>> Werner's example it should be a tie in style.  Somebody might want
>> to indicate an E12 enharmonic equivalence, as in your example, even
>> though it is not so in the staff notation system, and then it should
>> be a tie in style.
> 
> As mentioned above: This might be controlled by a flag.  Or maybe a
> special “E12_tie_slur” engraver can handle this.

You probably think of how to handle it internally, because syntactically one 
might just write a tie between enharmonic equivalents.

Re: tie over clef change

[Hans Åberg]

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
> 
>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>> 
>> On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:
>>> 
>>> 
>>> Despite Gould's “incorrect” verdict, here is an example from an old UE
>>> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
>>> over clef changes *do* happen and make sense sometimes...
>>> 
>>> I still think that LilyPond should support that, handling the tie like
>>> a slur in this case.
>> 
>> That's a very good example.  It's hard to imagine any reasonable alternative.
>> 
>> What kind of grob would an editor expect here? a Tie because it connects 
>> notes of the same pitch, or a Slur because it connects notes at different 
>> staff positions? (or something else?)
> 
> I'll answer my own question.  A tie from d♯ to e♭ generates a Tie grob, so 
> for consistency, this should be a Tie that looks like a slur.

The notes d♯ to e♭ have different pitches in the staff notation system, which 
cannot express E12 enharmonic equivalents, so this is slur. So it should be a 
slur that looks like slur.

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 14:55, Werner LEMBERG  wrote:
> 
> Despite Gould's “incorrect” verdict, here is an example from an old UE
> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
> over clef changes *do* happen and make sense sometimes...
> 
> I still think that LilyPond should support that, handling the tie like
> a slur in this case.

A tie indicates that it is a note whose (time) value (normally) otherwise 
cannot be expressed in the notational system, thus having the same pitch, 
whereas a slur indicates an articulation of notes of different pitch, that they 
should be played together. What do you think it is in your example? :-)

Re: Language selection

[Hans Åberg]

> On 20 Aug 2020, at 15:22, Phil Holmes  wrote:
> 
> If I go to http://lilypond.org/doc/v2.21/Documentation/notation/index.html 
> and click any of the links, I get a page in Spanish, which I'm not.
> 
> Anyone know why?

Probably because your parents weren't Spanish.

Re: collision \breathe with accidentals

[Hans Åberg]

> On 7 Aug 2020, at 08:17, Werner LEMBERG  wrote:
> 
> As the attached images show, the breathing sign *sometimes* collides
> with accidentals.  Looks like a bug.  If you agree I'll add it to the
> tracker.
> 
> Any idea how to circumvent that?

In addition to that, I place the breath mark above the ledger lines, and all 
sources I could find do likewise.

Re: Almost, but not quite: C++ STL in LilyPond

[Hans Åberg]

> On 6 May 2020, at 08:21, Han-Wen Nienhuys  wrote:
> 
> Regarding GC, once we leave behind GUILE 1.x, we could adorn all SCM
> containing structures with a operator new/operator delete, which calls
> scm_gc_alloc()/scm_gc_free(). That would get rid of marking functions.
> For vectors, we could introduce a scm_vector, which is an STL vector
> with a custom allocator. Or, we could globally map new/delete to
> GC_malloc and GC_free.

One can define the standard operator new/delete to call 
GC_malloc_uncollectable/GC_free, and the C++ standard guarantees that all 
allocations will use them (the linker will replace all occurrences).

Then for objects of indeterminate lifetime, I have user defined operator 
new/delete for GC_malloc, and no GC_free, with which I use a reference class 
similar to std::shared_ptr, but calling these operators instead.

> We might need finalizers where the smobs refer to outside data
> structures, like freetype and pango fonts, but I think we could even
> get away with never deallocating them at all.

As for the Boehm GC finalizers, I could not find that they take up significant 
time, but I had to rewrite the C++ code they suggest.

Re: Almost, but not quite: C++ STL in LilyPond

[Hans Åberg]

> On 5 May 2020, at 18:57, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 5 May 2020, at 17:09, David Kastrup  wrote:
>>> 
>>> One reason is that we want to get rid of finalisers particularly in
>>> connection with the Boehm GC.  Finalisers are called when garbage is
>>> collected, the collection of garbage is typically indicative of the
>>> expected lifetime of our objects (there are a few that might be
>>> unambiguously dead before), and thus it will cause C++ destructors to be
>>> called.  And those trigger, among other things, the deallocation of
>>> memory resources, but we'd rather want the deallocation to be determined
>>> by Scheme mechanisms and not have any resources in need of destruction
>>> other than falling into oblivion.
>> 
>> For the GC objects, I use operator new/delete with an extra argument,
>> the latter with empty body, wrapped in structure similar to
>> std:shared_ptr. Then the memory resources of those objects are only
>> handled by the GC, regardless of finalizers.
> 
> That does not sound like it has anything to do with SCM garbage
> collection.  

Sorry, I sent the message by mistake: I thought I clicked “Delete”, but it was 
“Send”, so if you so like, just forget about it.

> Nor is it phrased in a manner where I would understand what
> you are talking about.  It is not clear what a "GC object" is supposed
> to be, it is not clear what "I use" is supposed to mean with regard to
> where and how it is being used, "operator new/delete with an extra
> argument, the latter with empty body" presumably means that operator
> delete rather than the extra argument have an empty body.  It is not
> clear what it is supposed to buy us if operator delete has an empty body
> when calling operator delete is something triggered by the destructor
> and not having to call the destructor is a prerequisite for the life
> time being determined by garbage collection without finalisation hook.

C++ operator new/delete are called in pairs, so if the GC allocated objects 
have a pair of their own, then one can set a no-op delete.

> It is not clear _what_ is "wrapped in structure similar to
> std:shared_ptr" and how that is supposed to interact with Scheme.

This class use reference counting; instead use the GC allocating operator new. 
Don’t know about the Scheme part, though, but it uses something similar, I 
think.

>>> I've tried to come up with a clever callback scheme where the first
>>> use of a structure causes fake nodes to be created with a "Pointer"
>>> type that actually calls back with its address to its caller that
>>> then constructs a layout of SCM elements within its governed class.
>>> However, I have found no way to make this "parallel construction"
>>> where I could then swap out this specific "Pointer" behavior for
>>> regular SCM.
>> 
>> Similarly, it is necessary to call GC_INIT() on the first use on
>> MacOS, which can happen before ‘main’ is called. So for that, I let
>> operator new/delete call a function pointer which on the first call
>> initializes, and also changes the pointer to the ordinary function
>> pointer on future calls.
> 
> The ordinary function pointer.  I see.

Right. GC_malloc and GC_malloc_uncollectable.

Re: Almost, but not quite: C++ STL in LilyPond

[Hans Åberg]

> On 5 May 2020, at 17:09, David Kastrup  wrote:
> 
> One reason is that we want to get rid of finalisers particularly in
> connection with the Boehm GC.  Finalisers are called when garbage is
> collected, the collection of garbage is typically indicative of the
> expected lifetime of our objects (there are a few that might be
> unambiguously dead before), and thus it will cause C++ destructors to be
> called.  And those trigger, among other things, the deallocation of
> memory resources, but we'd rather want the deallocation to be determined
> by Scheme mechanisms and not have any resources in need of destruction
> other than falling into oblivion.

For the GC objects, I use operator new/delete with an extra argument, the 
latter with empty body, wrapped in structure similar to std:shared_ptr. Then 
the memory resources of those objects are only handled by the GC, regardless of 
finalizers.

> I've tried to come up with a clever callback scheme where the first use
> of a structure causes fake nodes to be created with a "Pointer" type
> that actually calls back with its address to its caller that then
> constructs a layout of SCM elements within its governed class.  However,
> I have found no way to make this "parallel construction" where I could
> then swap out this specific "Pointer" behavior for regular SCM.

Similarly, it is necessary to call GC_INIT() on the first use on MacOS, which 
can happen before ‘main’ is called. So for that, I let operator new/delete call 
a function pointer which on the first call initializes, and also changes the 
pointer to the ordinary function pointer on future calls.

Re: Make operator= private in Scheme_hash_table (issue 557680043 by hanw...@gmail.com)

[Hans Åberg]

> On 13 Apr 2020, at 17:15, hanw...@gmail.com wrote:
> 
> On 2020/04/13 14:55:12, hahnjo wrote:
>> If the function is not meant to be implemented / used, it should be
> explicitly
>> deleted (C++11).
> 
> Done.
> 
> https://codereview.appspot.com/557680043/

One might prefer having a deleted operator public, as to avoid additional 
potentially confusing error messages.

Re: How do I change LOCALEDIR?

[Hans Åberg]

> On 2 Mar 2020, at 01:46, Marnen Laibow-Koser  wrote:
> 
> On Sun, Mar 1, 2020 at 7:04 PM Hans Åberg  wrote:
> 
> > On 1 Mar 2020, at 23:45, Marnen Laibow-Koser  wrote:
> > 
> > One question as I continue to work on 64-bit Mac packaging: how do I set
> > LOCALEDIR (in this case, to match the packaged app bundle rather than the
> > build-time path)?  Unlike everything else of this nature, neither the
> > .reloc files nor environment variables work (and I've tried setting both
> > LOCALEDIR and LILYPOND_LOCALEDIR in both places): when I use the .reloc
> > file, it clearly finds the setting in the file, but then later blithely
> > prints out LOCALEDIR="the/old/value/I/didn't/want".  How should I deal with
> > this?
> 
> I use a script, see [1]. It may work in an app bundle, too.
> 
> 1. https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00425.html
> 
> Your script appears to set the LC_* locale variables, but not LOCALEDIR, 
> which is what I was asking about.  Am I wrong?

Yes, but I see from Werner’s post it wouldn’t work in our case.

Re: How do I change LOCALEDIR?

[Hans Åberg]

> On 1 Mar 2020, at 23:45, Marnen Laibow-Koser  wrote:
> 
> One question as I continue to work on 64-bit Mac packaging: how do I set
> LOCALEDIR (in this case, to match the packaged app bundle rather than the
> build-time path)?  Unlike everything else of this nature, neither the
> .reloc files nor environment variables work (and I've tried setting both
> LOCALEDIR and LILYPOND_LOCALEDIR in both places): when I use the .reloc
> file, it clearly finds the setting in the file, but then later blithely
> prints out LOCALEDIR="the/old/value/I/didn't/want".  How should I deal with
> this?

I use a script, see [1]. It may work in an app bundle, too.

1. https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00425.html

Re: lilypond-darwin-64 app doesn't work on Mac OS Lion

[Hans Åberg]

> On 17 Feb 2020, at 17:04, Werner LEMBERG  wrote:
> 
> 
> For fun I tried to execute
> 
>  
> https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449
> 
> on my old MacOS Lion box, with the following error.
> 
>  Traceback (most recent call last):
> …
> ImportError: dlopen(.../LilyPond 
> 2.app/Contents/Resources/lib/python2.7/lib-dynload/ob
> jc/_objc.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
>Referenced from: .../LilyPond 
> 2.app/Contents/Resources/lib/python2.7/lib-dynload/obj
> c/_objc.so
>Expected in: /usr/lib/libobjc.A.dylib
>   in .../LilyPond 
> 2.app/Contents/Resources/lib/python2.7/lib-dynload/objc/_objc.so
>  LilyPond Error

Does it ship with Python, or using the native? The 2.19.83 from the site uses 
2.6, not 2.7.

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[Hans Åberg]

> On 9 Feb 2020, at 15:09, Graham King  wrote:
> 
> From a speed-reading of Gould, it appears that she uses the verb "alter" and 
> the adjective "altered", but _not_ the noun "alteration" in this context.
> 
> It is worth noting that "alteration" has a very specific and well-established 
> meaning in early music.  This meaning has nothing whatsoever to do with 
> pitch.  I've, ahem, altered that Wikipedia disambiguation page accordingly.
> 
> The original section header in the LM seemed fine to me, but if it needs to 
> change, how about "Note names and use of accidentals" ?  It seems to me that 
> a user wanting to use the document to figure out how to specify an 
> accidental, is quite likely to search for that word.

In the Harvard Concise: Accidentals are symbols used to indicated pitch 
alterations. There are altered chords and rhythm alterations in early music.

Re: Mac 64-bit builds: Guile segfault?

[Hans Åberg]

> On 8 Feb 2020, at 13:51, Marnen Laibow-Koser  wrote:
> 
> From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
> working well for most people.  However, one user—one only one of two Macs
> he has access to—is consistently getting a segfault with these builds right
> around the time that it loads Guile and/or lily.scm (he says the 32-bit
> builds work).  There are detailed logs and troubleshooting info at
> https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
> of ideas to try.  Can someone help?  Thanks so much!

Not knowing if it is related, but on MacOS, the Boehm GC must be initialized 
before the first allocation, and the latter may in C++ happen before ‘main' is 
called.

Re: Disable C++ exceptions (issue 571430048 by jonas.hahnf...@gmail.com)

[Hans Åberg]

> On 28 Jan 2020, at 23:28, hanw...@gmail.com wrote:
> 
> I don't think there is any chance of ever using exceptions in LilyPond,
> because we can't mix them with the GUILE call stack.

One can combine C++ and Guile exceptions, by converting back and forth between 
them. Even though GCC admits throwing C++ exceptions through a C stack by some 
option, somebody mentioned there are complications with that, and better 
avoided.

Re: GUILE 2/3 and string encoding cost

[Hans Åberg]

> On 24 Jan 2020, at 10:03, Han-Wen Nienhuys  wrote:
> 
> On Thu, Jan 23, 2020 at 10:39 PM David Kastrup  wrote:
> 
>> 
>>> on mozart-hrn-3, over 3 runs, we get
>>> 
>>> 2.0.14  - avg 2.1s
>>> 1.8.8 - avg 0.31s
>>> 
>>> so the new GC is about 5-10x slower than the old one. With GUILE 1.8,
>>> garbage collection covers typically is 10% of the runtime, so all things
>>> equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total.
>>> 
>>> It would be good to see how the JITting of code impacts Scheme
>>> execution.
>> 
>> Boehm GC can work in a background thread I think.  And Guile-v2
>> applications typically just let all their data be treated as pointers
>> rather than using a smob-marking algorithm like we do, and it is
>> conceivable that Boehm GC's individual mark function does not scale.
>> 
> 
> Do you mean our mechanism to call user-defined mark functions? I doubt that
> there are obvious BGC scalability problems in BGC's mark functoin.

The Boehm GC collects in separate threads, however, when the program is 
threaded, it puts locks around every allocation, which is very time consuming.

> However, considering everything a pointer for a 32bit application that
>> can eat a significant ratio of the total address space is a nightmare:
>> there would be just too much memory pinned down due to conservative
>> garbage collection.
>> 
>> 
> GUILE 1.8 already scanned the stack conservatively, so large scores would
> probably never work on 32 bits. Was this a concern in the past?  How do
> score sizes (in pages) translates to memory usage (in megabytes)?
> 
> I think it is reasonable for us to start assuming people run lilypond on a
> 64-bit machines.
> 
> 
>> On a 64bit application, this would be somewhat more tenable, but we'd
>> need to override operator new for smobs.
>> 
>> Or do we?  Maybe the heap is collected by default, and we need to switch
>> that off?
>> 
> What do you mean with "heap is collected”?

The Boehm GC also has a malloc/free pair that keeps track of pointers into the 
GC heap. One can use them to define global operator new/delete, which the C++ 
standard guarantees that the linker will use them for all allocations. This can 
combined with GC allocations. 

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[Hans Åberg]

> On 23 Jan 2020, at 13:43, lemzwerg--- via Discussions on LilyPond development 
>  wrote:
> 
>> Why is this ugly? std::string is really the name of the class.
> 
> No question, but I would prefer
> 
>  struct xxx {
>using std:string;
> 
>string foo;
>string bar;
>string baz;
>  }
> }
> 
> to
> 
>  struct xxx {
>std::string foo;
>std::string bar;
>std::string baz;
>  }
> 
> for example, to increase legibility if there are many strings.

When using ones own namespace reusing names of std, then the external object 
must be qualified. For example,

namespace lly {

  class string {
  public:
string(const std::string&);

explicit operator std::string() const;
  };

  …

  inline string operator+(string& x, string& y) {
return std::string(x) + std::string(y);
  }

} // namespace lly

Re: MacOS 64-bit build

[Hans Åberg]

> On 9 Jan 2020, at 18:00, Werner LEMBERG  wrote:
> 
>>> There is no guarantee that `FlexLexer.h` found during compilation
>>> is the one that is used by a recent flex version.  Unfortunately,
>>> `FlexLexer.h` doesn't contain any version information, so it is
>>> really impossible to protect against this situation automatically.
>> 
>> Akim Demaille made a patch for it, see:
>> https://lists.gnu.org/archive/html/bug-bison/2018-09/msg00020.html
> 
> Nope, he didn't.  This patch is for something completely different, as
> far as I can see – LilyPond doesn't use `FlexLexer.hh`, it rather uses
> `FlexLexer.h` that comes with flex.

I did not look so careful at it, but I get the impression he makes his own 
header that depends on the Flex version.

> If you look into the git repository of flex you can see that even the
> most recent version of `FlexLexer.h` doesn't have any version
> information.

You can’t get around that, so one way around it is to make ones own header and 
include that. Then the .cc uses system includes, so either that should be 
patched too, or an option passed to the compiler.

Re: MacOS 64-bit build

[Hans Åberg]

> On 9 Jan 2020, at 13:34, Werner LEMBERG  wrote:
> 
>> `configure` should warn or bail on incompatible flex versions.  I
>> suggest we add a version check in configure.ac to ensure that flex
>> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
>> actually works).
> 
> What you suggest wouldn't work as expected.  There is no guarantee
> that `FlexLexer.h` found during compilation is the one that is used by
> a recent flex version.  Unfortunately, `FlexLexer.h` doesn't contain
> any version information, so it is really impossible to protect against
> this situation automatically.

Akim Demaille made a patch for it, see:
https://lists.gnu.org/archive/html/bug-bison/2018-09/msg00020.html

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 23:21, Marnen Laibow-Koser  wrote:
> 
>>> Also, of course, the point is to do this in a way that doesn’t require
>> the end users to have MacPorts.
>> 
>> The Emacs.app seemed to be working when put in /Applications/ so it might
>> be distributed independently.
> 
> Right, unless it contains absolute paths to MacPorts-installed libraries
> outside the bundle (which would be horrible practice but I think is
> allowed).

Yes, it does, so MacPorts is required for it to work.

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 22:35, Jonas Hahnfeld via Discussions on LilyPond 
> development  wrote:
> 
> By far no Mac expert, but if dynamic libraries are problematic would it
> help to have a static executable? I experimented with such a setup for
> Linux, and I eventually got it to build. Not sure what the status of my
> script is, I can try to dig it up…

Dynamic libraries have long been the default on MacOS, but the paths are 
hardcoded into the binary. So I figure an app needs relative paths to its 
resources.

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 22:20, Marnen Laibow-Koser  wrote:
> 
> On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg  wrote:
> [...]
> 
> FYI, it is possible to build apps using MacPorts, for example, there is 
> emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems 
> working if copied out of that directory.
> 
> Thanks, I looked for something like that but didn’t see a general method.  Do 
> you have any idea how this is done?

No.

> Also, of course, the point is to do this in a way that doesn’t require the 
> end users to have MacPorts. 

The Emacs.app seemed to be working when put in /Applications/ so it might be 
distributed independently.

But Frescobaldi seems a good choice. It needs a lilypond binary. By suggestions 
of the FHS standard I and Werner Lemberg decided to put in 
/opt/lilypond/bin/lilypond.

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 21:52, Marnen Laibow-Koser  wrote:
> 
> Some updates.  For the time being, at least, I've changed approaches.
> Since I couldn't understand much of GUB's OS detection logic, and no one
> seemed able to help with that, I abandoned GUB entirely for my latest
> attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
> Werner!).
> 
> My current plan is now to build a 64-bit build of LilyPad.app and put the
> LilyPond binary in there, then use
> https://github.com/auriamg/macdylibbundler or some similar tool to package
> the dylib dependencies in the app bundle.  While it's overcomplicated
> thanks to poor documentation and obsolescent ways of doing things, this
> seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
> bundle that will run on Catalina.

FYI, it is possible to build apps using MacPorts, for example, there is 
emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems 
working if copied out of that directory.

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

[Hans Åberg]

> On 14 Dec 2019, at 09:54, lemzwerg--- via Discussions on LilyPond development 
>  wrote:
> 
> LGTM, thanks!
> 
> https://codereview.appspot.com/553310045/
> 

The C++11 range for statement is nice too, if the iterator self is not 
addressed. For example, in beam.cc:
  for (auto& s: stems) {
Interval positions = Stem::head_positions(s);
…
  }

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

[Hans Åberg]

> On 14 Dec 2019, at 13:07, d...@gnu.org wrote:
> 
> I don't want to get your enthusiasm up prematurely, but I think that the
> GUB GCC versions we need(?)/use for PowerPC might not be entirely great
> with C++11 though they'll likely support it when given explicitly on the
> command line.

From what I recall, GCC never supported C++11 as default, but skipped directly 
to C++14, which is the current default. The implementation of C++11 was long 
and troublesome, and would be better to avoid if possible on earlier compilers.

Helmholtz-Ellis accidentals

[Hans Åberg]

> On 21 Oct 2018, at 10:56, Torsten Hämmerle  wrote:
> 
> If I understand it correctly, the main reason for switching to Bravura are
> missing Emmentaler accidental glyphs (obviously the multi-arrowed ones, if I
> look at your definition files).
> 
> Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near
> future directly after issue #3356 has been fixed (in two weeks latest).

What is the state of these accidentals? —This notation recently came up on the 
users list.


> In the course of issue #3356 "add triple flats/sharps" I've unified and
> considerably generalized the Metafont accidental glyph definitions so that
> it is now possible to create a whole variety of arrowed accidentals (the
> existing standard arrows as well as new stacked smaller arrows, "black"
> flats (with filled-in counters), etc.
> The Metafont overhaul was, among others, the reason why it took so long (but
> it's in the final internal testing phase now, struggling with
> spacing/positioning issues for big-arrow-up doublesharp).
> 
> The new glyph names for the tiny-arrowed accidentals (just the ones you
> currently use are mentioned here) will be
> 
>  accidentals.flatflat.1up
>  accidentals.flatflat.2up
>  accidentals.flatflat.1down
>  accidentals.flatflat.2down
>  accidentals.flat.1up
>  accidentals.flat.2up
>  accidentals.flat.1down
>  accidentals.flat.2down
>  accidentals.natural.1up
>  accidentals.natural.2up
>  accidentals.natural.1down
>  accidentals.natural.2down
>  accidentals.sharp.1up
>  accidentals.sharp.2up
>  accidentals.sharp.1down
>  accidentals.sharp.2down
>  accidentals.doublesharp.1up
>  accidentals.doublesharp.2up
>  accidentals.doublesharp.1down
>  accidentals.doublesharp.2down
> 

Re: Frescobaldi on MacOS 10.15 with MacPorts

[Hans Åberg]

> On 21 Oct 2019, at 01:24, Davide Liessi  wrote:
> 
> Il giorno sab 19 ott 2019 alle ore 20:31 Hans Åberg
>  ha scritto:
>> Instead I experienced further corruption, and decided to reinstall the whole 
>> of MacPorts from scratch. I do not want to try it again.
> 
> 10.15 is new, so it is expected that problems are being discovered in
> these first weeks.
> That said, the errors you had for librsvg and py37-poppler-qt5 (which
> are now solved) cannot have corrupted your whole installation, so I am
> inclined to believe there was some other (unrelated) problem with your
> MacPorts installation.

First xorg-server broke, and libxml2, and removing the latter and its 
dependencies also removed gcc9, so pretty much everything essential was gone. 
Unclear what caused it.

https://trac.macports.org/ticket/59377

> I understand that you don't want to risk wasting more time, especially
> now that a 10.15 builder is not available yet (so MacPorts needs to
> compile everything on your machine).
> Once the builder is in place, it will build all ports, which means
> that most problems will be spotted and that most dependencies of
> frescobaldi-devel will be available as prebuilt binary packages.
> If at that (or any previous or later) point you want to try again,
> feel free to contact me (on or off list) and let me know of any
> problems.

In MacPorts 2.6.1 and 2.6.2 there are now checksum errors for 
frescobaldi-.tar.gz. Also there is a somewhat mysterious call for 32-bit 
in the log file:
  :debug:sysinfo macOS 10.15 (darwin/19.0.0) arch i38

In addition, another X11 program is mysteriously slow on MacOS 10.15. So 
perhaps it is better to focus on the Application. The reason MacPorts came into 
focus for lilypond is that it is hard to get it otherwise.


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

Re: Frescobaldi on MacOS 10.15 with MacPorts

[Hans Åberg]

> On 19 Oct 2019, at 19:53, Davide Liessi  wrote:
> 
> Dear Hans,
> 
> Il giorno sab 19 ott 2019 alle ore 19:01 Hans Åberg
>  ha scritto:
>> For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS 
>> 10.15, and a ticket could not resolve it. So perhaps somebody here might 
>> want giving it a try.
> 
> I'm the maintainer of the frescobaldi{,-devel} ports and of its
> dependencies py-poppler-qt{4,5}.
> I have already committed a fix for your ticket
> https://trac.macports.org/ticket/59370 two days ago.
> Please update the port definitions, clean the failed port and try
> again to install frescobaldi-devel, i.e. run
> 
> sudo port selfupdate
> sudo port clean py37-poppler-qt5
> sudo port install frescobaldi-devel
> 
> (Cleaning the port should not be necessary, MacPorts should discard
> the previous build attempt since the port was changed, but cleaning it
> explicitly does no harm.)

It did not help.

> If the original problem persists, please report on the original ticket.
> If you encounter any other problems, please open corresponding tickets.

Instead I experienced further corruption, and decided to reinstall the whole of 
MacPorts from scratch. I do not want to try it again.



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

Frescobaldi on MacOS 10.15 with MacPorts

[Hans Åberg]

For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS 
10.15, and a ticket could not resolve it. So perhaps somebody here might want 
giving it a try.



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

Re: macOS 64-bit

[Hans Åberg]

> On 19 Oct 2019, at 17:30, Jahrme Risner  wrote:
> 
> On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser  wrote:
> 
>> Awesome, thanks; I’ll try it when I get a chance. I still want to get an 
>> .app bundle built, but it’s good to know that the mdmg approach actually 
>> works as advertised. :)
> 
> If you would like to see for yourself how the MacPorts build works, I have 
> included a script to automate the entire process. I haven’t tested it in the 
> last couple weeks (currently I’m away from my Mac), but I’m not aware of 
> anything that should have changed.
> 
> I would actually be quite interested in how long it takes on the MacStadium 
> image. I have also been toying with the idea of trying to get some automated 
> builds created using Tavis CI, but haven’t had time what with a new job and 
> moving, plus I think as it is now it might not fall into the allotted time 
> for free builds.

As port knows how to use full paths, it suffices to use ${install_dir}/port to 
selfupdate and mpkg on; then the export PATH seems unnecessary. In addition, 
more than one selfupdate may be required.  Otherwise, normally the local path 
should be ahead of the system paths, making sure to override the typically 
older system software.

> Script:
> 
> #!/bin/sh
… 


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

Re: macOS 64-bit

[Hans Åberg]

> On 18 Oct 2019, at 00:30, Marnen Laibow-Koser  wrote:
> 
> On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg  wrote:
> 
>> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
>> try out.
> 
> 
> With port mdmg/mpkg, or some other way?

Yes, see
https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html

> How do I try this out?

Try this link:
https://web2.storegate.com/share/oCQjV4r



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

Re: macOS 64-bit

[Hans Åberg]

> On 17 Oct 2019, at 09:21, Werner LEMBERG  wrote:
> 
> I have a 64bit Mac OS 10.7.5 machine at home;

I made an installer into /opt/lilypond/ on MacOS 10.15, which you might try out.

> theoretically, this
> should do the compilation job too, right?

It takes a very long time to do it as one has to do a new MacPorts installation 
and compile all from scratch.


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

Re: 64 bit

[Hans Åberg]

[Moving to lilypond-devel]

> On 16 Oct 2019, at 18:02, Werner LEMBERG  wrote:
> 
 Maybe if a compiler is not listed as a dependency, it will just
 take what is currently installed.
>>> 
>>> Yes.
>> 
>> So perhaps it suffices to remove it from the lilypond-devel
>> dependency list to get it to install.
> 
> What dependency?

The port lilypond-devel has been updates now to using gcc9 as a build 
dependency; earlier today, it was gcc8. But port lilypond does not have any 
gcc, nor libgcc as library dependency. The latter is perhaps required for a 
standalone package.


% port info lilypond
lilypond @2.18.2_10 (textproc)
Variants: [+]docs, universal

Description:  Lilypond is a unix-based automated engraving system that 
generates beautiful sheet music from input files. Lilypond uses its own input
  format, .ly, which in many ways is similar to LaTeX. 
Lilypond can export sheet music to PDF, EPS, SVG, and PNG formats, and can also
  create MIDI files.
Homepage: http://lilypond.org/

Build Dependencies:   bison, t1utils, texi2html, pkgconfig
Library Dependencies: fontconfig, fontforge, freetype, gettext, gmp, glib2, 
ghostscript, mftrace, guile18, texinfo, pango, flex, t1utils, 
texlive-lang-cyrillic,
  texlive-metapost, dblatex, urw-fonts, libtool, 
xorg-server, python27, netpbm
Conflicts with:   lilypond-devel
Platforms:darwin
License:  GPL-3+
Maintainers:  Email: s...@macports.org, GitHub: nerdling
  Policy: openmaintainer

% port info lilypond-devel
lilypond-devel @2.19.83_2 (textproc)
Variants: mactex

Description:  Lilypond is a unix-based automated engraving system that 
generates beautiful sheet music from input files. Lilypond uses its own input
  format, .ly, which in many ways is similar to LaTeX. 
Lilypond can export sheet music to PDF, EPS, SVG, and PNG formats, and can also
  create MIDI files.
Homepage: http://lilypond.org/

Build Dependencies:   autoconf, bison, dblatex, flex, fontforge, libtool, 
netpbm, pkgconfig, texinfo, texi2html, texlive, texlive-fonts-recommended,
  texlive-lang-cyrillic, texlive-metapost, t1utils, 
urw-core35-fonts, gcc9
Library Dependencies: glib2, pango, fontconfig, freetype, gettext, ghostscript, 
guile18, python27, libgcc
Conflicts with:   lilypond
Platforms:darwin
License:  GPL-3+
Maintainers:  Email: s...@macports.org, GitHub: nerdling
  Policy: openmaintainer


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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 07:21, Eric Benson  wrote:
> 
> gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build for me
> on Thursday. There was a MacPorts release on Friday, but I haven’t tried it
> yet. Maybe the problem has been fixed. I never got lilypond to build with
> gcc8 because I couldn’t build gcc8. I just modified the Portfile so it used
> gcc9 instead. As far as I know, there’s no reason to think that lilypond
> would have a dependency on any particular version of gcc, or even on gcc at
> all.

In case you are curios about making a binary distribution, I did that [1]. 
Werner suggested to put the stuff in /opt/lilypond/ instead of /usr/local/.

1. https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html



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

Re: Compiling instructions for macOS 10.15 Catalina

[Hans Åberg]

> On 13 Oct 2019, at 06:02, tansongchen  wrote:
> 
> I tried to follow this, but I encountered another problem: dependency
> "libgcc9" is not able to be built. Here is the log:  main.log
>   

Make ticket with the log attached at
  https://guide.macports.org/#project.tickets

When resolved, 'port selfupdate’ might be required before retrying. You can 
also try this first, to see if it has been resolved.


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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 14:28, Werner LEMBERG  wrote:
> 
>> But on the hand, I have never seen anything installing in /opt/
>> besides MacPorts on MacOS. And also packages are put in /usr/local/.
> 
> Well, that homebrew occupies `/usr/local' is far from optimal.

It decided to avoid it because of that. I have used /usr/local/ mainly to 
override older system installations, such as bison, which is the intended 
purpose then, but also other packages that are compiled and typically use that 
as the default installation location.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 13:43, Werner LEMBERG  wrote:
> 
> What about `/opt/lilypond’?
 
 The location /usr/local/ is for user installations on BSD systems,
 there is for example /usr/local/texlive, so it seems natural.
>>> 
>>> Well, I don't care enough to argue :-)
>> 
>> Why not? :-) Here are some links:
>> 
>> http://www.pathname.com/fhs/pub/fhs-2.3.html
>> https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local
>> https://www.linuxjournal.com/magazine/pointcounterpoint-opt-vs-usrlocal
> 
> Well, the links you give just prove my point that `/opt/lilypond'
> would be a better choice than `/usr/local/lilypond' – I don't want
> mpkg to install into `/usr/local/bin', `/usr/local/lib', etc.
> Instead, we have a complete bundle, with a separate directory
> hierarchy.

Not better necessarily, but what the standard suggests. But let’s follow it and 
put it into /opt/lilypond/.

> Normally, the directory structure below `/usr/local' mimics `/usr'.
> Having stuff like `/usr/local/texlive' is thus an exception, basically
> violating FHS.  Not everyone likes it; see the thread starting at
> 
>  https://tug.org/pipermail/tex-live/2015-September/037361.html

The standard explicitly says it should not be there, but in /opt/. Also, 
MacPorts is in /opt/local/ but should have been in /opt/macports/, as it 
suggests /opt≮provider>/.

But on the hand, I have never seen anything installing in /opt/ besides 
MacPorts on MacOS. And also packages are put in /usr/local/.


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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 12:09, Werner LEMBERG  wrote:
> 
> 
 I think I put it into /usr/local/lilypond or
 /usr/local/lilypond-devel.  Which location would you prefer?
>>> 
>>> What about `/opt/lilypond’?
>> 
>> The location /usr/local/ is for user installations on BSD systems,
>> there is for example /usr/local/texlive, so it seems natural.
> 
> Well, I don't care enough to argue :-)

Why not? :-) Here are some links:

http://www.pathname.com/fhs/pub/fhs-2.3.html
https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local
https://www.linuxjournal.com/magazine/pointcounterpoint-opt-vs-usrlocal



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 10:55, Werner LEMBERG  wrote:
> 
>> I think I put it into /usr/local/lilypond or
>> /usr/local/lilypond-devel.  Which location would you prefer?
> 
> What about `/opt/lilypond’?

The location /usr/local/ is for user installations on BSD systems, there is for 
example /usr/local/texlive, so it seems natural.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 07:21, Eric Benson  wrote:
> 
> gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build for me 
> on Thursday. There was a MacPorts release on Friday, but I haven’t tried it 
> yet. Maybe the problem has been fixed. I never got lilypond to build with 
> gcc8 because I couldn’t build gcc8. I just modified the Portfile so it used 
> gcc9 instead. As far as I know, there’s no reason to think that lilypond 
> would have a dependency on any particular version of gcc, or even on gcc at 
> all.

This is good to know. It would be better with gcc9, but another package called 
for llvm7 and the latest is llvm9, so it is not a big deal to have multiple 
versions installed.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 12 Oct 2019, at 07:00, Werner LEMBERG  wrote:
> 
> 
>>> Well, right now you have to build MacPorts from source on MacOS
>>> 10.15 – I guess this takes almost a day of compilation.  (I don't
>>> have such an OS, by the way).
>> 
>> The link I gave has an installer for MacOS 10.15, and it works. :-)
>>   https://www.macports.org/install.php
> 
> This is irrelevant.  To build a distributable `mpkg', you have to
> install MacPorts with a *different* prefix (i.e., not `/opt/local') so
> that it doesn't interfere with the `standard' MacPorts a user might
> have installed.  And for such custom MacPorts installations only
> building from source works.

I made one such distribution, and even sent to a listing of its contents, 
remember?

I think I put it into /usr/local/lilypond or /usr/local/lilypond-devel. Which 
location would you prefer?

>>> And note also that I haven't looked into how and what can get
>>> stripped of from the mpkg bundle.
>> 
>> I got the impression that is what the link you gave was about:
>>  https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00047.html
> 
> As mentioned there, a script has to be written that does this
> stripping, and I haven't done so.


OK.

>> Also, lilypond-devel has not been updated to use gcc9.  I am using
>> it for other things, so it would be good not having to install gcc8.
> 
> This will take some time – contrary to Joe User the developers *are*
> interested why building with gcc8 fails.
> 
> I thus ask Catalina users who already have a *completely*
> *regenerated* MacPorts installation[*] to check whether using gcc8
> really fails to build LilyPond.  If it does, please file a MacPorts
> bug ticket with all the details.
> 
> 
>Werner
> 
> 
> [*]: This is essentially a complete re-installation of MacPorts from
> scratch, also installing the newest version of XCode and its
> command line tools before doing that.

I am doing that right now, but there are build errors.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 11 Oct 2019, at 21:43, Werner LEMBERG  wrote:
> 
 A problem with the [MacPorts] lilypond-devel package is that it
 listed all dependencies for the build as required for the
 installer, including GCC, making it very large, so it should be
 slimmed down.
>>> 
>>> This is not correct any more, I think.  See
>>> 
>>> https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00047.html
>> 
>> Then it is maybe time to test it: I see that MacPorts now has been
>>  updated for MacOS 10.15.
> 
> Well, right now you have to build MacPorts from source on MacOS 10.15
> – I guess this takes almost a day of compilation.  (I don't have such
> an OS, by the way).

The link I gave has an installer for MacOS 10.15, and it works. :-)
   https://www.macports.org/install.php

> Note that `port mpkg ...' rebuilds a package and *all* of its
> dependencies from scratch (so that you can pass variants).

I did that before, but I do not remember the details.

> And note also that I haven't looked into how and what can get stripped
> of from the mpkg bundle.

I got the impression that is what the link you gave was about:
  https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00047.html

Also, lilypond-devel has not been updated to use gcc9. I am using it for other 
things, so it would be good not having to install gcc8.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 11 Oct 2019, at 19:16, Eric Benson  wrote:
> 
> > I see that MacPorts now has been updated for MacOS 10.15.
> 
> Hah! If only I had waited one more day!

It was not a waste of time — I have also done such package chasing, but a 
package manager is of course more convenient. :-)



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 11 Oct 2019, at 18:41, Werner LEMBERG  wrote:
> 
> 
>> A problem with the [MacPorts] lilypond-devel package is that it
>> listed all dependencies for the build as required for the installer,
>> including GCC, making it very large, so it should be slimmed down.
> 
> This is not correct any more, I think.  See
> 
>  https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00047.html

Then it is maybe time to test it: I see that MacPorts now has been updated for 
MacOS 10.15.
  https://www.macports.org/install.php



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 11 Oct 2019, at 18:41, Werner LEMBERG  wrote:
> 
> See
> 
>  https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00047.html

The dependency has not yet been update to GCC 9, it seems:
  https://ports.macports.org/port/lilypond-devel/summary



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 10 Oct 2019, at 17:41, Eric Benson  wrote:
> 
> I haven't tried to build the Mac OS application, Lilypond.app, because I
> don't use it myself. I only use the command line lilypond.

I believe it is deprecated, as there are better alternatives, Frescobaldi was 
one suggestion I think.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 10 Oct 2019, at 17:41, Eric Benson  wrote:
> 
> sudo port install lilypond-devel
> 
> That should work, after which you will have /opt/local/bin/lilypond
> installed. You have to make sure that /opt/local/bin is on your $PATH.

MacPorts adds it to $PATH, though not correctly first: I have /opt/local/bin/ 
after /usr/local/bin/ but before /usr/bin/, so that one can install more 
up-to-date packages in /usr/local/. Also, lilypond got confused at some point 
by the locale environment variables, so I use script:

export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
exec /opt/local/bin/lilypond "$@"


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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 10 Oct 2019, at 18:45, Carl Sorensen  wrote:
> 
> I think that we are going to need to move to having somebody with a Mac build 
> and provide an OSX 64-bit build for lilypond, rather than using GUB for the 
> 64-bit build.

MacPorts can create a standalone installer, one can choose installation 
location, and installations in the same location will be merged, so one can 
have binaries and docs in two installers if one so likes. A problem with the 
lilypond-devel package is that it listed all dependencies for the build as 
required for the installer, including GCC, making it very large, so it should 
be slimmed down.



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 10 Oct 2019, at 17:55, Eric Benson  wrote:
> 
> > This is good, but I think GCC 8 was kept deliberately as it was unclear if 
> > GCC 9 would work.
> 
> gcc8 failed to build on MacPorts on Catalina on the latest Xcode. Rather than 
> try to understand why, I switched to gcc9 and it seems to work fine.

I do not have objection to that. :-)



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 10 Oct 2019, at 9:01:57 AM, Eric Benson  wrote:
> 
> I was able to build Lilypond on Catalina, using the newest Xcode. MacPorts 
> does not yet have a distribution for Catalina, so I built it from source as 
> well. It seems to work fine. I did have to make one change to the Portfile 
> for lilypond-devel. I added macports-gcc-9 at the top of the 
> compiler.fallback-append list, because MacPorts was mistakenly trying and 
> failing to build gcc8 as a dependency.

This is good, but I think GCC 8 was kept deliberately as it was unclear if GCC 
9 would work.

> I know there is a political controversy about the GNU License and the latest 
> Xcode, but there don't seem to be any technical challenges to building from 
> source on the current Mac OS and Xcode.

It is only for cross builds.

> I'm using a 64-bit-compiled Lilypond 2.19.83 on Catalina now.

Me too: The MacPorts version seems to work if installing before the update to 
MacOS 10.15. :-)



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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Hans Åberg]

> On 8 Oct 2019, at 09:57, Maria-Angeles Casares-de-Cal via lilypond-devel 
>  wrote:
> 
> For the attention of the Lilypond Developer Team:
> 
> Lilypond is an remarkable app, but now Lilypond does not work with the new 
> Mac operating system (macOS 10.15 Catalina).
> 
> Will we have news soon of the new Lilypond (64 bits) to work in macOS 10.15?

It seems that the MacPorts version can be run if installed before the MacOS 
update. It cannot be updated, though, but hopefully a new MacPorts version will 
come soon enough.

Specifically:

First install MacPorts on MacOS 10.14. See their site for instructions. Then run
  sudo port install lilypond-devel
When checking that it works, update to MacOS 10.16. After that, the new default 
shell is zsh, so copy .bashrc to .zshrc, and hopefully the shells are 
compatible enough for that to work.


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

Re: 64-bit version of Lilypond?

[Hans Åberg]

[Please keep the cc to the list, so that others can follow the issue.]

For MacOS 10.14 or earlier, install MacPorts, and issue in Terminal the command
  port install lilypond-devel

There is probably no MacPorts for 10.15, though.


> On 17 Jul 2019, at 16:53, Yentl Tijssens  wrote:
> 
> Yes I read about the slow updating, but I guess that’s better than having 
> nothing. Is there a place that I could download that build?
> 
>> On 1 Jul 2019, at 00:11, Hans Åberg  wrote:
>> 
>> 
>>> On 30 Jun 2019, at 22:49, Yentl Tijssens  wrote:
>>> 
>>> Hey,
>>> 
>>> I’m a bit of a nooby tech enthusiast and upgraded to the Catalina Beta. Of 
>>> course Lilypond doesn’t work on that version because it is a 32-bit 
>>> application.
>>> I saw your post and was wondering if you could provide me your way to use a 
>>> functional lilypond 64-bit version with Frescobaldi. 
>> 
>> I added the devel list, as there is an issue to consider when using MacPorts 
>> for LilyPond, namely that it tends to be slow updating with the new MacOS’s, 
>> typically some month after the official public release.
>> 
>> 
> 


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

Re: Executable options style question

[Hans Åberg]

> On 11 Jul 2019, at 09:32, Jacques Menu  wrote:
> 
> I’ve wondering about command line options with multiple values.
> 
> Which one of the following in preferable in your opinion:
> 
> DESSUS="Cor anglais"
> xml2ly -msr-part-rename "P1 = ${DESSUS}" 
> 
> or:
> 
> DESSUS="Cor anglais"
> xml2ly -msr-part-rename P1 "${DESSUS}”

POSIX, Guideline 8 [1] says that they should be presented as a single argument 
to the option, separated with comma or blanks within that argument. GNU [2] 
does not mention that explicitly.

1. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
2. https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html



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

Re: 64-bit version of Lilypond?

[Hans Åberg]

> On 30 Jun 2019, at 22:49, Yentl Tijssens  wrote:
> 
> Hey,
> 
> I’m a bit of a nooby tech enthusiast and upgraded to the Catalina Beta. Of 
> course Lilypond doesn’t work on that version because it is a 32-bit 
> application.
> I saw your post and was wondering if you could provide me your way to use a 
> functional lilypond 64-bit version with Frescobaldi. 

I added the devel list, as there is an issue to consider when using MacPorts 
for LilyPond, namely that it tends to be slow updating with the new MacOS’s, 
typically some month after the official public release.



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

Re: macOS 64-bit

[Hans Åberg]

> On 18 May 2019, at 02:58, Carl Sorensen  wrote:
> 
> I'm a Mac user and would love to get to 64 bit.

It is already in MacPorts, both lilypond and lilypond-devel, and at least the 
latter seems to be working fine, though some systematic testing would be good.



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

Re: macOS 64-bit

[Hans Åberg]

> On 17 May 2019, at 21:37, Daniel Johnson  wrote:
> 
> I had to manually download, build and install the following:
> - TeX Gyre font
> - Flex 2.5.37

Later version of Flex have broken C++ generation. Akim Demaille found a way 
around this, maybe here:
  http://lists.gnu.org/archive/html/help-bison/2019-05/msg00014.html



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

Re: macOS 64-bit

[Hans Åberg]

> On 17 May 2019, at 21:48, Marnen Laibow-Koser  wrote:
> 
> On Fri, May 17, 2019 at 3:27 PM Hans Åberg  wrote:
> 
> > On 17 May 2019, at 21:14, Marnen Laibow-Koser  wrote:
> > 
> > On Fri, May 17, 2019 at 3:06 PM Hans Åberg  wrote:
> > 
> >> LilyPond uses Guile 1.8, not the latest, and the lilypond in MacPorts uses 
> >> gcc8, not the latest supported gcc9.
> >> 
> > Will it build with GCC 9?
> 
> That would need to be tested, but Werner said gcc9 does not build on earlier 
> MacOS,
> 
> Does that matter? We already have a build process that works for earlier Mac 
> OS.  It sounds like as long as both GCC 8 and 9 are supported, we might be 
> OK.  But I’m sort of speculating. 

Werner will have to tune in on that.

> and I saw somebody complaining it having clang listed as a dependency.
> 
> LilyPond having Clang listed as a dependency, or GCC having Clang as a 
> dependency?

GCC 9 and maybe 8 too; I do not know if it is important.


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

Re: macOS 64-bit

[Hans Åberg]

> On 17 May 2019, at 21:14, Marnen Laibow-Koser  wrote:
> 
> On Fri, May 17, 2019 at 3:06 PM Hans Åberg  wrote:
> 
>> LilyPond uses Guile 1.8, not the latest, and the lilypond in MacPorts uses 
>> gcc8, not the latest supported gcc9.
>> 
> Will it build with GCC 9?

That would need to be tested, but Werner said gcc9 does not build on earlier 
MacOS, and I saw somebody complaining it having clang listed as a dependency.

>> As for the SDK, the one they use is the latest having a true GCC, which is 
>> gcc4, I think, and what is called gcc after that is instead clang, not the 
>> official version, but an inhouse version, and lilypond does not compile with 
>> any of them.
>> 
> Hmm.  If LilyPond won’t compile with Clang/LLVM, I wonder if that would be a 
> problem for 64-bit Mac builds, because I don’t know if the macOS SDK will 
> build with GCC.  (It certainly might; I haven’t checked.)

One problem was different interpretation of some C++ templates, so that would 
have to be rewritten in LilyPond.



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

Re: macOS 64-bit

[Hans Åberg]

> On 17 May 2019, at 16:10, Marnen Laibow-Koser  wrote:
> 
>> Given that MacPorts supports more packages than Homebrew this is a
>> very bold statement.
> 
> Homebrew supports enough packages, and it’s really easy to add new ones, so
> that’s pretty much irrelevant.

Somebody said it had problems with choosing versions. For example, LilyPond 
uses Guile 1.8, not the latest, and the lilypond in MacPorts uses gcc8, not the 
latest supported gcc9.

As for the SDK, the one they use is the latest having a true GCC, which is 
gcc4, I think, and what is called gcc after that is instead clang, not the 
official version, but an inhouse version, and lilypond does not compile with 
any of them.



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

Re: macOS 64-bit

[Hans Åberg]

> On 17 May 2019, at 00:26, Marnen Laibow-Koser  wrote:
> 
> Perhaps I don’t understand.  If GUB merely calls out to Xcode, how is this
> a GPL3 issue?

One needs to extract the SDK, and that has only been done for an old XCode 
version that is 32-bit, so it wouldn’t help anyway.



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

Re: macOS 64-bit

[Hans Åberg]

> On 17 May 2019, at 00:06, Jahrme Risner  wrote:
> 
> There is not, AFAIK, *any* elegant
> solution to the usage of texlive on macOS.

TeXLive is in MacPorts, and one can choose the components. Also, one can have 
different installers for the program and docs and merge the stuff.



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

Re: 64-bit version of Lilypond?

[Hans Åberg]

> On 15 Mar 2019, at 13:06, Karlin High  wrote:
> 
> On 3/15/2019 4:44 AM, Han-Wen Nienhuys wrote:
>> I have been following this thread with half an eye. What is the
> problem exactly?
> Here's my understanding so far.
> 
> * The next version of macOS will only run 64-bit software. (The current 
> "Mojave" version runs 32-bit, but gives a warning.)
> 
> * LilyPond has no macOS 64-bit version now. Unless one is made, users of the 
> next macOS will need Homebrew or MacPorts to get LilyPond, much less 
> convenient than the current macOS installer from lilypond.org.

The MacPorts version is 64-bit. Werner is looking into cutting down the 
standalone binary it can create to a suitable size:
  https://lists.macports.org/pipermail/macports-users/2019-March/046530.html

> * Newer SDK versions with 64-bit support have license requirements to only 
> run on Apple-branded hardware.

That may not be a new requirement: you have recently discovered it. :-)

> * Having a separate build process for a macOS installer will need more effort 
> from the person doing the builds.

A distributed build might be a workaround.



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

Re: 64-bit version of Lilypond?

[Hans Åberg]

> On 15 Mar 2019, at 10:44, Han-Wen Nienhuys  wrote:
> 
> If Apple and their lawyers think it is fine to redistribute GPL
> binaries made with XCode, then we should be fine too.

The one you use now provides GCC4.2 I think it is, but later versions only 
provides Clang, not the real one but an Apple inhouse version of unknown 
relation. So if using that, either you'll have to make it compile with this 
Clang, or get GCC from elsewhere.



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