Re: Single entry font

[Mark Theodoropoulos via LilyPond user discussion]

Sigh, only just now realized that I replied only to Aaron rather than the list, 
which is no help to Calvin, or anyone else. Fairly old now, but perhaps of use 
to someone.




On 2021-03-23 7:54 PM, Aaron Hill wrote:
> On 2021-03-23 7:24 pm, Calvin Ransom wrote:
>> I am trying to use the attached font for my title but I am not able to get
>> the title to switch to Odin Rounded, but it can switch to my other
>> installed fonts. I am using windows 10. I am also unsure how to run
>> "lilypond -dshow-available-fonts"
>
> You just run that command from the terminal.  [. . .]

Also be aware that, at least on Windows, this prints to standard error rather 
than standard output; if you wish to save it to a file (so that the list is 
actually usable if you have more than a dozen or so installed fontfiles), you 
need to tack on an additional redirection, e.g.,


lilypond -dshow-available-fonts > my_lily_fonts.txt 2>&1

Otherwise you'll get a zero-length file. Hope this saves a few hairs for 
someone.

Regards,
M. Theo












--
m. theo / surtitles & program notes · typography · music engraving
classics without walls, 1992–2011 | 998 broadcasts | 26,347 miles
: recordings are not music; they’re only the sound that it makes :

Note stem centered if font.name changed in EasyHeads

[Viktor Mastoridis]

\version "2.20.0"
\relative c'' {
  \easyHeadsOn
  \override NoteHead.font-name = #"Ubuntu"
  a b c d}

Hello,

If I try to change the font.name in EasyHeads, the stem gets to the middle
of the note-head (see attached image).
And Lilypond says: "none of note heads `noteheads.s' or `noteheads.d' found"

Any clues?

Re: Note stem centered if font.name changed in EasyHeads

[Jean Abou Samra]

Le 02/04/2021 à 12:03, Viktor Mastoridis a écrit :


\version "2.20.0"
\relative c'' {
  \easyHeadsOn
  \override NoteHead.font-name = #"Ubuntu"
  a b c d}

Hello,

If I try to change the font.name  in EasyHeads, the 
stem gets to the middle of the note-head (see attached image).
And Lilypond says: "none of note heads `noteheads.s' or `noteheads.d' 
found"


Any clues?



Hello,

This qualifies as a bug -- I am forwarding your report to the bug list.

Here is a workaround:

\version "2.22.0"

\relative c'' {
  \easyHeadsOn
  \override NoteHead.font-name = "Ubuntu"
  \override NoteHead.stem-attachment = #'(1.05 . 0)
  a b c d
}

Technically, the problem is that ly:note-head::calc-stem-attachment
uses the glyph that would be printed without \easyHeadsOn, and
the font-size override confuses that code since note heads require
a music font.

Best,
Jean

Re: AW: Custom Format

[David Kastrup]

antlists  writes:

> On 01/04/2021 09:50, Kevin Barry wrote:
>> On Wed, Mar 31, 2021 at 11:47:05PM +0100, antlists wrote:
>>> On 31/03/2021 20:20, Callum Cassidy-Nolan wrote:
 You are correct, there is no distinction between these two notes,
 because in terms of pitch they are the same.
>>>
>>> Actually, they're not ...
>>>
>>> If you're talking about "well-tempered" instruments - basically keyboard -
>>> then IN PRACTICE they are the same note, but the whole well-tempered system
>>> is a bodge to make sure instruments sound "okay" in any modern scale.
>> I assume by "well-tempered" you mean equally tempered.
>
> Isn't Bach's 48 called "The WELL-tempered Klavier"?

Well, it's probably a confusion about "any modern scale" in connection
to Bach.  Like most people are surprised when one calls Shakespeare's
English "Early Modern".  Because what then would be Old English?  Nobody
expects something like "and on ðam seofoðan dæge hé geendode his weorc,
and geswac ða and gehalgode þone seofoðan dæg, forðan ðe hé on ðam dæge
his weorc geendode" even though it contains words like "and", "hé",
"on", "his".

> And here you prove my point. You seem to be talking about keyboard
> instruments. I play brass. There's no such thing as "well-tempered"
> for brass instruments - with just four or five adjustment points
> there's no way you can adjust the 36 or so notes that your instrument
> typically produces (and a good player can probably get more notes than
> that out of it).
>
> As for the tuning systems before equal temperament, which instruments
> would they have applied to? Brass, strings, which are incapable of
> equal temperament!

Why would strings be incapable of equal temperament?  Granted, bowed
strings are commonly tuned in pure fifths (but then you avoid playing
open strings most of the time), but tuning a guitar in unequal
temperament is a recipe for trouble, particularly since the frets are
evenly spaced and not adjustable.

Typically the sanest way to tune it is using flageolet notes (which tell
you pure intervals) but distributing the tuning errors towards slightly
sharp fourths.

> Apart from the organ (which I was shocked to discover, in its MODERN
> form, first appeared about 600BC!!!),

Herr Gottlieb Silbermann would like to have a word with you.  Because he
invested an awful lot of work to get organs to the state we call modern
and where they will, for example, do

diddlediddlediddlediddlediddlediddlediddlediddle
BO BO BO BO BO BO WHOM
diddlediddlediddlediddlediddlediddlediddlediddle

without the second row of diddles starting totally overblown because of
the inertia of the bellows weight continuing to press air through
suddenly tiny pipes.

> equal temperament appeared, I believe, at about the same time as
> instruments capable of taking advantage of it such as the ?clavichord,
> harpsichord, spinet, forte-piano etc.

Well, the forte-piano is typically stretch-tuned, so any tuning theories
need some adaptation to reality anyway.

It's a wonder different instruments manage to play together at all.

-- 
David Kastrup

Re: Slurs and multiple voice writing in piano music

[Valentin Petzel]

Hello Gabriel,

You need to be mindful of this: In Lilypond a tie or a slur has to remain in 
the Voice it started in. Now, the problem ist that

<< A \\ B >>

does in fact create two new Voices. Thus you cannot really tie to it from the 
outside. The thing you want to do is to continue the voice that should get the 
tie, so you’d do something like

Stuff stuff stuff ~
<<
 \new Voice {\voiceOne A}
 {\voiceTwo B}
>>
\oneVoice
Rest rest rest

Cheers, Valentin

signature.asc
Description: This is a digitally signed message part.

How to stretch one single line?

[Thomas Breuss]

Hello,

Is it possible to stretch one single line with lilypond like so?




The first example is what I try to achieve.
The second exampe is what I have right now in Lilypond.

Please note that I have several snippets. These snippets will be embedded as 
SVGs in an Asciidoctor document for final rendering.

Best,
Thomas

Re: How to stretch one single line?

[Jean Abou Samra]

Le 02/04/2021 à 14:04, Thomas Breuss a écrit :

Hello,

Is it possible to stretch one single line with lilypond like so?


[Image]

The first example is what I try to achieve.
The second exampe is what I have right now in Lilypond.

Please note that I have several snippets. These snippets will be 
embedded as SVGs in an Asciidoctor document for final rendering.


Best,
Thomas



Hello,

I think you want

\paper {
  ragged-right = ##f
}

Please refer to

http://lilypond.org/doc/v2.22/Documentation/notation/line-width.html

Regards,
Jean

Re: How to stretch one single line?

[Phil Holmes]

Something like this should do it:

\layout {
  ragged-right = ##f
}

{\clef bass e1 a d g}

On 02/04/2021 13:04, Thomas Breuss wrote:

Hello,

Is it possible to stretch one single line with lilypond like so?



The first example is what I try to achieve.
The second exampe is what I have right now in Lilypond.

Please note that I have several snippets. These snippets will be embedded as 
SVGs in an Asciidoctor document for final rendering.

Best,
Thomas


--
Phil Holmes

Re: How to stretch one single line?

[Thomas Breuss]

> Something like this should do it:
> 
> \layout {
>   ragged-right = ##f
> }
> 
Thanks. It works!

I was sure that I tried this before, but maybe with wrong syntax or so.

Best,
Thomas

Re: How to stretch one single line?

[bobr...@centrum.is]

You can also do:


  \layout {
indent = #
line-width = #
ragged-last = ##f
  }

To adjust the left and right endpoints of your snippet.

-David

- Original Message -
> From: "Thomas Breuss" 
> To: "Phil Holmes" 
> Cc: "Lillypond Users Mailing List" 
> Sent: Friday, April 2, 2021 12:18:59 PM
> Subject: Re: How to stretch one single line?

>> Something like this should do it:
>> 
>> \layout {
>>   ragged-right = ##f
>> }
>> 
> Thanks. It works!
> 
> I was sure that I tried this before, but maybe with wrong syntax or so.
> 
> Best,
> Thomas

Re: How to stretch one single line?

[Thomas Breuss]

Thanks all. It works.

Unbelievable fast answers. Great to have such a mailing list.

Regards from Switzerland,
Thomas

horizontal distance from notehead to augmentation dot ; mensural notation : dots inside ligatures

[98123981293 1293812397123]

Dear list,

1) Can someone please clarify to me how to increase the distance between a
notehead and its augmentation dot in general? I'm trying to use
extra-spacing-width property, and while setting the cdr of the pair induces
the expected space between the dot and the next notehead, setting the car
to similarly extreme values seems to have no effect. See snippet below.

2) Augmentation dots inside ligatures seem to be totally insulated from dot
engraver overrides, even when placing the override inside the ligature
bracket in question. Is there a solution to this?

As a small aside, I'm wondering: in mensural notation inside Lilypond, is
there already a built in tool for distinguishing augmentation dots from
so-called 'dots of division'? From the documentation, it appeared not,
hence my attempts to override the dot position, but if there is an easier
way please let me know. In general I've been extremely impressed with the
output of the mensural syntax; thank you to developers responsible for
these features.

\version "2.23.1"
  \new MensuralVoice {
  \override NoteHead.style = #'blackpetrucci
  \override Dots.extra-spacing-width = #'(10 . 10 )%%% placing this
override inside the ligature has no effect
\[ a'1 b'1. \] b'2 b'1. b'1
  }

Re: AW: Custom Format

[Wols Lists]

On 02/04/21 11:57, David Kastrup wrote:
>> Apart from the organ (which I was shocked to discover, in its MODERN
>> > form, first appeared about 600BC!!!),

> Herr Gottlieb Silbermann would like to have a word with you.  Because he
> invested an awful lot of work to get organs to the state we call modern
> and where they will, for example, do

Depends on what we think of as "form" :-)

For example, I wouldn't call the natural horn the modern form, because
the French Horn is keyed and most of the others horns have valves - both
modern inventions.

But the trombone and violins haven't changed much going a lot further
back - the sackbut may have a narrow bore and small bell, but the
resemblance to the modern trombone is pretty close. Likewise I don't
know how far the violin goes back, but I guess it's very close to the
folk fiddle that probably existed in the middle ages, if not long before.

But - as I understand it - the organ (consisting of air blown through
pipes and controlled by keys) was invented that long ago. The technology
for blowing the air has changed a lot since then ... :-)

Cheers,
Wol

Re: 2.19.59: Bad horizontal spacing when \override LyricText#'X-offset

[Dmytro O. Redchuk]

Hi,

as for me, this issue has been fixed in 2.22 in some way.

https://sourceforge.net/p/testlilyissues/issues/5129/

пн, 16 бер. 2020 о 19:59 Dmytro O. Redchuk  пише:
>
> Hi,
>
> unfortunately (for me at least), this regression persists in 2.20.0 too.
>
> Thank you anyway, lilypond is really great :)
>
> вт, 2 лип. 2019 о 09:13 Dmytro O. Redchuk  пише:
> >
> > Thank you, Pierre, for your suggestion.
> >
> > Unfortunately it is not always possible, there might be some
> > "Pneumonoultramicroscopicsilicovolcanoconiosis" instead of "Блаженні
> > голодні й спрагнені правди". And the more syllables collected in one
> > with quotes, the more visible this regression is.
> >
> > Thank you anyway, i will test more.
> >
> > On Mon, Jul 1, 2019 at 5:18 PM Pierre Perol-Schneider
> >  wrote:
> > >
> > > Hi Dmytro,
> > >
> > > Not nice but works:
> > >
> > > \version "2.19.83"
> > > {
> > >   r4
> > >   %a
> > >   a4*1/8 \hideNotes a a a a a a a\unHideNotes
> > >   a2 a4 a2 s4
> > > }
> > > \addlyrics {
> > >   \override LyricText #'X-offset = #0
> > >   Блаженні голодні й спрагнені правди, бо вони на -- си -- тять -- ся.
> > > }
> > >
> > > HTH, cheers,
> > > Pierre
> > >
> > > Le lun. 1 juil. 2019 à 15:06, Dmytro O. Redchuk  
> > > a écrit :
> > >>
> > >> Hi,
> > >>
> > >> is there any progress with this issue or any suggestions on how to 
> > >> workaround?
> > >>
> > >> Thanks.
> > >>
> > >> On Sat, Apr 29, 2017 at 11:53 PM Trevor Daniels  
> > >> wrote:
> > >> >
> > >> >
> > >> > Dmytro, you wrote Saturday, April 29, 2017 8:06 PM
> > >> >
> > >> > >> please, dear 'ponders, let me know what's wrong here in my email.
> > >> > >>
> > >> > >> Should I post this in bug-lilypond? Or is this spacing correct?
> > >> > > Oh SORRY, your replies were dropped by my gmail.
> > >> >
> > >> > No need to apologise.  We've noted this as a regression introduced
> > >> > in 2.19.10; see https://sourceforge.net/p/testlilyissues/issues/5129/
> > >> >
> > >> > If you have an earlier release available maybe that could be used as
> > >> > a work-around for this piece.  It seems unlikely there is an easy fix.
> > >> >
> > >> > Trevor

-- 
  Dmytro O. Redchuk

Re: Enharmonically override key signature

[Kieren MacMillan]

Hi Jean,

> Something like the attached?

It breaks when I abstract the keys:

%%%
global = {
  \key aeses \major
  s1
  \key cis \minor
  s1
}

notes = \relative {
  aeses'8 beses ces deses eeses fes ges aeses
  cis, dis e fis gis a bis cis
}

music = <<
  << \global \notes >>
  \transpose ees c << \global \notes >>
>>
%%%

Any thoughts about that?

Thanks,
Kieren.


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

Re: Enharmonically override key signature

[Jean Abou Samra]

Hello,

Le 30/03/2021 à 03:33, Kieren MacMillan a écrit :

Hi Craig,


That worked for my over-simplified MWE. But here's my real-world problem with 
multiple key changes. There are only some that need to be over-ridden 
enharmonically. See bar 2 of the Alto Sax where I'd like to override this key 
signature without changing the whole global setup. Is this possible?


I have to say that in 99.99% of cases, "Is this
possible?" is a rhetorical question in LilyPond.


If it is, I can’t wait to see the solution… As the composer and arranger of 
musical theatre and other multi-instrumentalist music, Lilypond’s awkward 
handling of key signatures and transposition is a long-time thorn in my side.

David K once devised a rather brilliant almost-solution (cf. 
),
 but it wasn’t able to handle the high abstraction of my Lilypond code. There was a 
suggestion that an “enharmonize-engraver” might solve the problem, but I don’t think 
anyone tackled that.



Something like the attached? While admittedly ugly and
in need for more testing, it should provide
a start. I would be curious of better approaches
others may think of.

There is a big drawback: \relative changes behavior
in the naturalized version. I haven't investigated
how to fix it yet.

Regards,
Jean

\version "2.22.0"

#(use-modules (ice-9 receive))

#(define possible-naturalizations
   (list
 #{ deses #}
 #{ bis #}))

#(define no-naturalization
   #{ c #})


#(define (key-alterations context pitch-alist)
   "Compute alterations in the key, based on the pitch-alist.

This replicates the action of Key_engraver::read_event in lily/key-engraver.cc."
   (let loop ((alist (list-copy pitch-alist))
  (order (ly:context-property context 'keyAlterationOrder))
  (accidentals '()))
 (if (or (null? alist)
 (null? order))
 (append
   (filter-map
 (lambda (entry)
   (and (not (zero? (cdr entry)))
; No, don't warn, because we may get very
; weird accidentals in the process of finding
; the best key.
entry))
 alist)
   (reverse! accidentals))
 (let* ((entry (car order))
(head (member entry alist))
(found (and head (car head)))
(remaining-order (cdr order)))
   (if found
   (loop (delete! found alist)
 remaining-order
 (cons found accidentals))
   (loop alist
 remaining-order
 accidentals))


#(define (alteration-number accidentals)
   "Compute the number of accidentals in this key, taking double accidentals into account."
   (* 2 (apply + (map abs (map cdr accidentals)

#(define (best-naturalization context tonic pitch-alist alterations)
   "Determine best tonic to minimize the number of alterations.

Receives pre-computed alterations for the base tonic, to avoid calculating
them again.  Returns the best alterations found, for the same reason.

This applies a very simple-minded algorithm: try two possible ways to
naturalize, changing flats to sharps or sharps to flats, and return the
best one among the default and these two."
   (let loop ((best-naturalization-found tonic)
  (best-alterations-found alterations)
  (changed #f)
  (naturalizations-to-try possible-naturalizations))
 (if (null? naturalizations-to-try)
 (values best-naturalization-found best-alterations-found changed)
 (let* ((naturalization (car naturalizations-to-try))
(remaining-naturalizations (cdr naturalizations-to-try))
(new-pitch (ly:pitch-transpose tonic naturalization))
(new-pitch-alist (ly:transpose-key-alist pitch-alist naturalization))
(new-alterations (key-alterations context new-pitch-alist)))
   (if (< (alteration-number new-alterations)
  (alteration-number best-alterations-found))
   (loop naturalization
 new-alterations
 #t
 remaining-naturalizations)
   (loop best-naturalization-found
 best-alterations-found
 changed
 remaining-naturalizations))


#(define (naturalize-note! event naturalization)
   (ly:event-set-property!
 event
 'pitch
 (ly:pitch-transpose (ly:event-property event 'pitch)
 naturalization)))


#(define (reset-naturalization! context)
   (ly:context-set-property! context 'currentNaturalization no-naturalization))


#(set-object-property! 'currentNaturalization 'translation-type? ly:pitch?)

#(define (Naturalize_engraver context)
   (let ((notes-with-original-pitches '()))
 (make-engraver
   

Re: Enharmonically override key signature

[Jean Abou Samra]

Le 02/04/2021 à 22:15, Kieren MacMillan a écrit :

Hi Jean,


Something like the attached?

It breaks when I abstract the keys:

%%%
global = {
   \key aeses \major
   s1
   \key cis \minor
   s1
}

notes = \relative {
   aeses'8 beses ces deses eeses fes ges aeses
   cis, dis e fis gis a bis cis
}

music = <<
   << \global \notes >>


Well, you need \new Voice here or separate staves
are created. Other than that, it seems to work
fine -- amended input and output attached. Is
there anything wrong with it, other than the
aforementioned \relative issue?

Best,
Jean
\version "2.22.0"

#(use-modules (ice-9 receive))

#(define possible-naturalizations
   (list
 #{ deses #}
 #{ bis #}))

#(define no-naturalization
   #{ c #})


#(define (key-alterations context pitch-alist)
   "Compute alterations in the key, based on the pitch-alist.

This replicates the action of Key_engraver::read_event in lily/key-engraver.cc."
   (let loop ((alist (list-copy pitch-alist))
  (order (ly:context-property context 'keyAlterationOrder))
  (accidentals '()))
 (if (or (null? alist)
 (null? order))
 (append
   (filter-map
 (lambda (entry)
   (and (not (zero? (cdr entry)))
; No, don't warn, because we may get very
; weird accidentals in the process of finding
; the best key.
entry))
 alist)
   (reverse! accidentals))
 (let* ((entry (car order))
(head (member entry alist))
(found (and head (car head)))
(remaining-order (cdr order)))
   (if found
   (loop (delete! found alist)
 remaining-order
 (cons found accidentals))
   (loop alist
 remaining-order
 accidentals))


#(define (alteration-number accidentals)
   "Compute the number of accidentals in this key, taking double accidentals into account."
   (* 2 (apply + (map abs (map cdr accidentals)

#(define (best-naturalization context tonic pitch-alist alterations)
   "Determine best tonic to minimize the number of alterations.

Receives pre-computed alterations for the base tonic, to avoid calculating
them again.  Returns the best alterations found, for the same reason.

This applies a very simple-minded algorithm: try two possible ways to
naturalize, changing flats to sharps or sharps to flats, and return the
best one among the default and these two."
   (let loop ((best-naturalization-found tonic)
  (best-alterations-found alterations)
  (changed #f)
  (naturalizations-to-try possible-naturalizations))
 (if (null? naturalizations-to-try)
 (values best-naturalization-found best-alterations-found changed)
 (let* ((naturalization (car naturalizations-to-try))
(remaining-naturalizations (cdr naturalizations-to-try))
(new-pitch (ly:pitch-transpose tonic naturalization))
(new-pitch-alist (ly:transpose-key-alist pitch-alist naturalization))
(new-alterations (key-alterations context new-pitch-alist)))
   (if (< (alteration-number new-alterations)
  (alteration-number best-alterations-found))
   (loop naturalization
 new-alterations
 #t
 remaining-naturalizations)
   (loop best-naturalization-found
 best-alterations-found
 changed
 remaining-naturalizations))


#(define (naturalize-note! event naturalization)
   (ly:event-set-property!
 event
 'pitch
 (ly:pitch-transpose (ly:event-property event 'pitch)
 naturalization)))


#(define (reset-naturalization! context)
   (ly:context-set-property! context 'currentNaturalization no-naturalization))


#(set-object-property! 'currentNaturalization 'translation-type? ly:pitch?)

#(define (Naturalize_engraver context)
   (let ((notes-with-original-pitches '()))
 (make-engraver
   (listeners
 ((note-event engraver event)
(set! notes-with-original-pitches
  (cons
(cons event
  (ly:event-property event 'pitch))
notes-with-original-pitches))
(naturalize-note! event
  (ly:context-property context 'currentNaturalization)))
 ((key-change-event engraver event)
(let* ((tonic (ly:event-property event 'tonic))
   (pitch-alist (ly:event-property event 'pitch-alist))
   (default-alterations
 (key-alterations context pitch-alist)))
  ; Find the best key to minimize accidentals.  If it
  ; is different from what we had (that is, we managed
   

Re: Enharmonically override key signature

[Kieren MacMillan]

Hi Jean,

> you need \new Voice here or separate staves are created.

D'oh! Just wasn’t thinking… Thanks.

> Other than that, it seems to work fine -- amended input and output attached.

Nice!

> Is there anything wrong with it

I’ll go back to some of my more complicated multi-instrumentalist pieces and 
see if it solves those. If not, I’ll send an MWCE (Minimal Working 
Counter-Example).

> other than the aforementioned \relative issue?

Oh, imma gonna keep my mouth shut about that…  ;)

Thanks,
Kieren.


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

Re: Note stem centered if font.name changed in EasyHeads

[Viktor Mastoridis]

Thank you very much, Jean.
The hack does the job for now.

-- 
📱Viktor.Mastoridis.co.uk

-Original Message-
Re: Note stem centered if font.name changed in EasyHeads
From: Jean Abou Samra 
To: Viktor Mastoridis ,lilypond-user <
lilypond-user@gnu.org>
Cc: 
Friday, 2 April 2021 at 11:18

Le 02/04/2021 à 12:03, Viktor Mastoridis a écrit :

\version "2.20.0"
\relative c'' {
  \easyHeadsOn
  \override NoteHead.font-name = #"Ubuntu"
  a b c d}

Hello,

If I try to change the font.name in EasyHeads, the stem gets to the middle
of the note-head (see attached image).
And Lilypond says: "none of note heads `noteheads.s' or `noteheads.d' found"

Any clues?


Hello,

This qualifies as a bug -- I am forwarding your report to the bug list.

Here is a workaround:

\version "2.22.0"

\relative c'' {
  \easyHeadsOn
  \override NoteHead.font-name = "Ubuntu"
  \override NoteHead.stem-attachment = #'(1.05 . 0)
  a b c d
}

Technically, the problem is that ly:note-head::calc-stem-attachment
uses the glyph that would be printed without \easyHeadsOn, and
the font-size override confuses that code since note heads require
a music font.

Best,
Jean

Re: LilyPond 2.21.80 installer on MacOS 10.15 (Hans Åberg)

[Jacques Menu]

Hello Hans,

Sorry if the question has already raised and I missed it.

Marnen’s 2.20 release works fine here with Frescobaldi 3.1.3 on Big Sur 11.2.3.

My question is: SimpleSynth seems to be 32 bits only, how can I get the MIDI 
output played? 

I’ve installed brew and timidity, but I don’t know how to use it  from within 
Frescobaldi:

menu@macbookprojm: /usr/local > ./Cellar/timidity/2.15.0_1/bin/timidity
TiMidity++ version 2.15.0 -- MIDI to WAVE converter and player
Copyright (C) 1999-2018 Masanao Izumo 
Copyright (C) 1995 Tuukka Toivonen 

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Thanks for your help!

JM

> Le 2 déc. 2020 à 20:04, Hans Åberg  a écrit :
> 
> 
>> On 2 Dec 2020, at 18:33, Carl Sorensen  wrote:
>> 
>> Marnen's application bundle is available on his web site:
>> 
>> https://bintray.com/marnen/lilypond-darwin-64
> 
> This is for the stable release.
> 
>> Because Marnen's build is MacOS native, rather than GUB, …
> 
> The GUB is not used anymore, I believe: Apart from the license issue, there 
> is a problem with getting a working cross compilation SDK. There used to be a 
> problem with it using clang, but that should be fixed.
> 
>> I assume that his build recipe will build ARM apps as well.  But it will 
>> likely need to be run on an ARM-based system.
> 
> The universal binaries are just separate compiles bundled together:
> https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary
> 
> 
> 

Re: LilyPond 2.21.80 installer on MacOS 10.15 (Hans Åberg)

[Hans Åberg]

> On 3 Apr 2021, at 00:02, Jacques Menu  wrote:
> 
> Hello Hans,
> 
> Sorry if the question has already raised and I missed it.
> 
> Marnen’s 2.20 release works fine here with Frescobaldi 3.1.3 on Big Sur 
> 11.2.3.
> 
> My question is: SimpleSynth seems to be 32 bits only, how can I get the MIDI 
> output played? 

One can use GarageBand, just put it into a track in a project file. Perhaps a 
bit cumbersome, but provides opportunity for further editing.

Re: LilyPond 2.21.80 installer on MacOS 10.15 (Hans Åberg)

[田村淳]

Regarding 64-bit SimpleSynth, here is some discussion:
https://github.com/notahat/simplesynth/issues/4 


and 64-bit binary built by matlimatli:
https://github.com/matlimatli/simplesynth/releases 


> 2021/04/03 7:17、Hans Åberg のメール:
> 
> 
>> On 3 Apr 2021, at 00:02, Jacques Menu  wrote:
>> 
>> Hello Hans,
>> 
>> Sorry if the question has already raised and I missed it.
>> 
>> Marnen’s 2.20 release works fine here with Frescobaldi 3.1.3 on Big Sur 
>> 11.2.3.
>> 
>> My question is: SimpleSynth seems to be 32 bits only, how can I get the MIDI 
>> output played? 
> 
> One can use GarageBand, just put it into a track in a project file. Perhaps a 
> bit cumbersome, but provides opportunity for further editing.
> 
> 
> 

Re: LilyPond 2.21.80 installer on MacOS 10.15 (Hans Åberg)

[Jean Abou Samra]

Le 03/04/2021 à 00:02, Jacques Menu a écrit :

Hello Hans,

Sorry if the question has already raised and I missed it.

Marnen’s 2.20 release works fine here with Frescobaldi 3.1.3 on Big 
Sur 11.2.3.


My question is: SimpleSynth seems to be 32 bits only, how can I get 
the MIDI output played?


I’ve installed brew and timidity, but I don’t know how to use it  from 
within Frescobaldi:


*menu@macbookprojm*: /usr/local > ./Cellar/timidity/2.15.0_1/bin/timidity
TiMidity++ version 2.15.0 -- MIDI to WAVE converter and player
Copyright (C) 1999-2018 Masanao Izumo >

Copyright (C) 1995 Tuukka Toivonen mailto:t...@cgs.fi>>

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Thanks for your help!

JM



Hi Jacques,

Does this help?

https://lists.gnu.org/archive/html/lilypond-user/2021-01/msg00240.html

For me, it worked just fine (under Ubuntu).

Hope that helps,
Jean