Re: Interactive PDF Link to Notes in Preview

[Federico Bruni]

Il giorno lun 9 lug 2018 alle 7:26, Mats Behre 
<"mb.maillists"@gmail.com> ha scritto:

On 2018-07-08 19:56, Federico Bruni wrote:


I found this: 
https://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x 
and downloaded SwiftDefaultApps. It works on High Sierra, don't know 
about El Capitan, but if not it seems that RCDefaultApp should do 
the trick for you.


Can you be more specific?
What do you mean with "it works"?
Which command did you assign for textedit protocol?

Yesterday I read a similar answer and installed RVDefaultApp. Now I 
can set which application should open textedit:// URIs.
However I cannot set the text editor directly, as the text editor 
cannot handle this protocol.


I guess I should use lilypond-invoke-editor but, as I've already 
reported, I could not make it work on either Mac or Windows.


It looks like it's the last step to get what I want.



OK, then you are in more or less the same situation as me - you need 
a small helper app that takes the URI and invokes your editor.
I have a small AppleScript app which does this (I think I got the 
base for it from the LilyPond site ages ago):


You may simply use the same bash script that works in Linux:

$ ls -l /usr/local/bin/lilypond-invoke-editor
lrwxrwxrwx 1 root root 37  1 ago 16.06 
/usr/local/bin/lilypond-invoke-editor -> 
/usr/local/bin/lilypond-wrapper.guile


$ cat /usr/local/bin/lilypond-wrapper.guile
#!/bin/sh
export 
PYTHONPATH="/usr/local/lilypond/usr/lib/lilypond/current/python:/usr/local/lilypond/usr/share/lilypond/current/python:$PYTHONPATH"

export GUILE_LOAD_PATH="/usr/local/lilypond/usr/share/lilypond/current"
export LD_LIBRARY_PATH="/usr/local/lilypond/usr/lib:$LD_LIBRARY_PATH"
me=`basename $0`
exec "/usr/local/lilypond/usr/bin/guile" 
"/usr/local/lilypond/usr/bin/$me" "$@"


I adapted it above file to the correct path in Mac and I can now launch:

lilypond-invoke-editor textedit://path/to/file.ly:1:2:3

Last step left is how to tell the system to use lilypond-invoke-editor 
to open textedit URIs.
I've created a new app containing the bash script to launch 
lilypond-invoke-editor, but I cannot find a way to associate it to the 
textedit URIs. See below.





My problem now is that SwiftDefaultApps silently fails to set this as 
the textedit target, possibly because my info.plist is too old (it 
has worked in the past):




I got a silent fail also with RCDefaultApp.
Today I installed SwiftDefaultApps, but when I try to open it, it says 
it doesn't work with Intel processors.


I tried a simplified version of below Info.plist (I copied, as you did, 
the relevant part from LilyPond Info.plist).
Unfortunately I could not find an easy tutorial to write your own 
Info.plist from scratch. It seems that normal procedure is building it 
in Xcode...





"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>



CFBundleAllowMixedLocalizations

CFBundleDevelopmentRegion
English
CFBundleExecutable
applet
CFBundleIconFile
applet
CFBundleIdentifier

com.apple.ScriptEditor.id.1A1CE0AF-AC45-4636-9B72-8CBBFCDA88F5
CFBundleInfoDictionaryVersion
6.0
CFBundleName
lilypoint
CFBundlePackageType
APPL
CFBundleSignature
aplt
CFBundleURLTypes


CFBundleTypeRole
Editor
CFBundleURLName
text editor via url
CFBundleURLSchemes

textedit



LSMinimumSystemVersionByArchitecture

x86_64
10.6

LSRequiresCarbon

WindowState

bundleDividerCollapsed

bundlePositionOfDivider
0.0
dividerCollapsed

eventLogLevel
2
name
ScriptWindowState
positionOfDivider
680
savedFrame
1238 373 1015 944 0 0 2560 1417 
selectedTab
log




I have not yet had time to find out what the problem is - you may be 
luckier.


/mb



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

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Simon Albrecht-2 wrote
> I went to the issue tracker so this doesn’t get lost – it seems to be 
> related to or a subset of 
> ;.

Hi Simon,

While the descriptive title "Fingering collision with accidentals" of issue
3692 more or less describes our current problem, I think this has to be
technically separated.


Fingering positions at the left concerned:
1. Why aren't the numbers placed below the accidental even if there's plenty
of space?
2. Why do numbers above an accidental overlap?

This strange effect can be perfectly explained when assuming that horizontal
positioning is done in a state where the numbers still sit on their
baselines and these baselines are at the height of their corresponding
notehead.
After horizontal positioning, these numbers will be centred vertically, i.e.
shifted down by half a staff-space (because they happen to be about a
staff-space high).
This shift will make them either overlap an accidental below or create an
unnecessary gap.

I've tried to illustrate this in the following PDF:
test-accidental-fingering2.pdf

  

I think this should get its own tracker issue.

All the best,
Torsten






--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Thomas Morley]

2018-08-02 12:10 GMT+02:00 Torsten Hämmerle :
> Simon Albrecht-2 wrote
>> I went to the issue tracker so this doesn’t get lost – it seems to be
>> related to or a subset of
>> ;.
>
> Hi Simon,
>
> While the descriptive title "Fingering collision with accidentals" of issue
> 3692 more or less describes our current problem, I think this has to be
> technically separated.
>
>
> Fingering positions at the left concerned:
> 1. Why aren't the numbers placed below the accidental even if there's plenty
> of space?
> 2. Why do numbers above an accidental overlap?
>
> This strange effect can be perfectly explained when assuming that horizontal
> positioning is done in a state where the numbers still sit on their
> baselines and these baselines are at the height of their corresponding
> notehead.
> After horizontal positioning, these numbers will be centred vertically, i.e.
> shifted down by half a staff-space (because they happen to be about a
> staff-space high).
> This shift will make them either overlap an accidental below or create an
> unnecessary gap.
>
> I've tried to illustrate this in the following PDF:
> test-accidental-fingering2.pdf
> 
>
> I think this should get its own tracker issue.
>
> All the best,
> Torsten


Hi Torsten,

I tried to Y-center the Fingering-stencil.

Though, with the example below the result is not all that convincing.
If fingerings are 'right the default is already inconsistent, for
different numbers.
Additionally, if fingeringOrientations contains 'left or 'right a
FingeringColumn is built at Staff-level, so the 'snap-radius-property
comes into play.

No real clue how to proceed...

Here my testings:

yCenterFingeringStil =
  \override Fingering.stencil =
#(lambda (grob)
  (ly:stencil-aligned-to (ly:text-interface::print grob) Y CENTER))

mus = {
4. r8
4. r8
}

{
\time 2/4
\mark "Fingerings left"
\set fingeringOrientations = #'(left)
<>^"default"
\mus
\yCenterFingeringStil
<>^"tweaked"
\mus
<>^"snap-radius tweaked as well"
\override Staff.FingeringColumn.snap-radius = 1
\mus
}

{
\time 2/4
\mark "Fingerings right"
\set fingeringOrientations = #'(right)
<>^"default"
\mus
\yCenterFingeringStil
<>^"tweaked"
\mus
<>^"snap-radius tweaked as well"
\override Staff.FingeringColumn.snap-radius = 1
\mus
}


Cheers,
  Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: layout of markup text (Peter Gentry)

[Simon Albrecht]

On 02.08.2018 10:43, Peter wrote:
Thanks Simon yes sometimes I am not sure what environment the 
interpreter is in, especially when it is expecting a music
Element or not. It's obvious in the simple case but can be confusing 
in a more (unessessaryily?) complex file.


With variable definitions it is a little simpler because they are only 
allowed at toplevel [1], so you just have to make sure that every single 
{} or <<>> or #() has been closed before you include the file with the 
variable assignment.


Best, Simon

[1] Well, except for \paper, \layout and \header, which have their own 
scope IIUC.




Thanks.

On 2 August 2018 00:59:09 BST, Simon Albrecht  
wrote:


On 23.07.2018 16:22, Peter Gentry wrote:

It looks as though in this case the compiler is treating each
"addTextSpannerText.ly" in the parts as music rather than scheme. 



\include acts in a way that is completely indistinguishable from just
pasting the content of the file instead of the include. So you need to
organise your input files in a way that allows for this, and that’s
nearly always just a matter of thinking it all the way through and
finding the right setup.
If the variable definition in your include file throws a mistake, then
apparently at the point where you write \include you’re still in an
environment where variable definitions aren’t possible.
Since it’s superfluous to include a file multiple times, you might also
look at the openlilylib/oll-core module, which implements a function to
only include a file if it hasn’t been included yet.

Best, Simon


--
Sent from my Android device with K-9 Mail. Please excuse my brevity. 



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

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Simon Albrecht]

On 02.08.2018 12:10, Torsten Hämmerle wrote:

I think this should get its own tracker issue.


I created one and tried to include all the analyses yet presented.


Best, Simon

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

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Hi Harm,

Yes, fingerings are quite a large construction zone (and right hand
fingerings or string numbers as well).
Issue 3692 hasn't been solved yet, and your examples show that there is also
a general dot collision problem for right fingerings.

When increasing snap-radius, fingerings may overlap when forced into one
vertical column.



Thomas Morley-2 wrote
> I tried to Y-center the Fingering-stencil.
> […]

This is pretty much what I did (using a much more primitive hard-coded
markup just to see the effect).
This centering at least solves the accidental interaction problem, but it is
only one step of many.

And of course the LilyPond coding should be corrected without having to
manipulate the stencil.

All in all, fingering placement is awfully challenging, using standard
interfaces and avoiding collisions with anything that might get into the way
(other fingerings, right hand fingerings, string numbers, accidentals, dots,
scripts, ties, slurs, …)

In any case, your examples add another level of difficulties, as the close
notehead positions require additional vertical shifting of fingerings and
dots. Phew...

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Simon Albrecht-2 wrote
> I created one and tried to include all the analyses yet presented.
> ;

Thanks, Simon. I think makes sense trying to improve the fingering placement
step by step.
And everything that can get ...Orientations (fingeringOrientations,
strokeFingerOrientations, stringNumberOrientations) is affected.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: layout of markup text (Peter Gentry)

[Noeck]

The idea that included files are indistinguishable from copy-and-paste,
even goes to extreme levels. This works:


---  included.ly  
title = "title"
composer = "composer"
}
--


---  main.ly  
\header {
  \include "included.ly"

{ a }
--

Cheers,
Joram

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

Re: layout of markup text (Peter Gentry)

[David Kastrup]

Noeck  writes:

> The idea that included files are indistinguishable from copy-and-paste,
> even goes to extreme levels. This works:
>
>
> ---  included.ly  
> title = "title"
> composer = "composer"
> }
> --
>
>
> ---  main.ly  
> \header {
>   \include "included.ly"
>
> { a }

I think there is at least a barrier between main input and its invoking
LilyPond core code so that mismatched delimiters in the main file do not
cause error messages pointing to the core code.

At least I think I put some code to that effect into LilyPond.

-- 
David Kastrup

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

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Thomas Morley-2 wrote
> […]
>   \mark "Fingerings right"
>   \set fingeringOrientations = #'(right)
> […]


Hi Harm,

When setting fingeringOrientations to #'(right), the occasional collision of
fingering and dots are a result of dots moving vertically away too far from
their noteheads.

Intervals of a second in combinations with "quantized" dot placements
between lines may lead to 1 staff-space Y distance between notehead and dot,
i.e. the fingering does not collide with the dot of its own notehead, but
runs into a neighbouring dot:

 

I'll try to to also take care of the neighbouring dots (i.e. make them known
to the side-position-interface...

Let's see,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

partcombine for choir and piano?

[Noeck]

Hi,

reading about \partcombine recently stirs up some questions. I always
considered it a tool for orchestra scores (violins of flutes). But
perhaps it's not limited to that.


My questions (and some short reasoning):

1. Does \partcombine make sense for combining *soprano and alto* into
one staff or should I use voices? I see pros (+) and cons (-):

 - The fact that I would prefer the 'apart' style everywhere makes me
   think that it's perhaps not what \partcombine is intended for.
 = From a quick test, \partcombineApart is equivalent to two voices.
   Are there exceptions?
 + The positioning of dynamics is better for partcombine.
   Why are all dynamics below the staff for the voices-setup by default?


2. Does \partcombine make sense for *piano music* with different voices
starting here and there?

 - Probably not as the 2...n voices are never used independently, so
   I'd be better off writing voices explicitly as necessary.


Best,
Joram




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

Re: partcombine for choir and piano?

[Simon Albrecht]

On 02.08.2018 23:15, Noeck wrote:

My questions (and some short reasoning):

1. Does \partcombine make sense for combining *soprano and alto* into
one staff or should I use voices? I see pros (+) and cons (-):

  - The fact that I would prefer the 'apart' style everywhere makes me
think that it's perhaps not what \partcombine is intended for.
It certainly isn’t; surely nobody ever considered vocal writing while 
working on the part combiner. But that doesn’t necessarily mean that it 
doesn’t work; since the part combiner always uses the same internal 
voice names, I can even imagine (without ever having tried it) that in a 
clever setup one could find a convenient way to flexibly attach lyrics, 
coordinated with the modes of the part combiner.



  = From a quick test, \partcombineApart is equivalent to two voices.
Are there exceptions?

Don’t know about that – I’d guess not, but I haven’t used partcombine much.

  + The positioning of dynamics is better for partcombine.
Why are all dynamics below the staff for the voices-setup by default?
I’m not sure what you mean. If there are lyrics below the staff, 
dynamics (and possibly a number of other things) need to go above the staff.
This somewhat spectacular Breitkopf&Härtel 1961 engraving comes to mind 
as an example for two vocal parts on one staff, with separate dynamics 
and often lyrics: 

But that’s extremely difficult to pull of well and if one isn’t going to 
invest a huge amount of time in details of placement, it’s probably 
better to use more staves.

2. Does \partcombine make sense for *piano music* with different voices
starting here and there?

  - Probably not as the 2...n voices are never used independently, so
I'd be better off writing voices explicitly as necessary.


As you know, piano engraving always has its very own challenges, with 
which the part combiner definitely won’t help.


Best, Simon

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

Re: Opinions: expressive text and markup sizes

[Noeck]

Btw, the factor is probably

  2^(1/6) ≈ 1.122462048309373

as Lilyponds scales the fonts in a way that 6 steps double the font size.

Cheers,
Joram

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

Re: partcombine for choir and piano?

[Noeck]

Hi Simon,

thanks for your helpful answer.

Am 02.08.2018 um 23:37 schrieb Simon Albrecht:
>>   + The positioning of dynamics is better for partcombine.
>> Why are all dynamics below the staff for the voices-setup by default?
> I’m not sure what you mean. 

Here is what I mean: When I combine two voice in one staff like this:

 <<
  \new Staff <<
\new Voice { \voiceOne a'\f b' }
\new Voice { \voiceTwo f'\f g' }
  >>
  \new Lyrics \lyricmode { a b }
 >>

There are two forte signs (one would be enough) below the staff (above
would be better). I understand that I have to take care because of the
lyrics. But why isn't the upper voices' dynamics above the staff - as
\voiceOne does set the direction for so many other things?

\partcombine is better by default - still the dynamics are below the staff.

Is this a reasonable way to combine the two voices?

 <<
  \new Staff <<
\new Voice { \voiceOne \dynamicUp a'\f b' }
\new Voice { \voiceTwo \omit DynamicText f'\f g' }
  >>
  \new Lyrics \lyricmode { a b }
 >>

Best,
Joram

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

Re: partcombine for choir and piano?

[David Kastrup]

Noeck  writes:

> Hi,
>
> reading about \partcombine recently stirs up some questions. I always
> considered it a tool for orchestra scores (violins of flutes). But
> perhaps it's not limited to that.
>
>
> My questions (and some short reasoning):
>
> 1. Does \partcombine make sense for combining *soprano and alto* into
> one staff or should I use voices?

Voices in my opinion.

> I see pros (+) and cons (-):
>
>  - The fact that I would prefer the 'apart' style everywhere makes me
>think that it's perhaps not what \partcombine is intended for.
>  = From a quick test, \partcombineApart is equivalent to two voices.
>Are there exceptions?
>  + The positioning of dynamics is better for partcombine.
>Why are all dynamics below the staff for the voices-setup by default?
>
>
> 2. Does \partcombine make sense for *piano music* with different voices
> starting here and there?
>
>  - Probably not as the 2...n voices are never used independently, so
>I'd be better off writing voices explicitly as necessary.

I think it makes sense for piano _extracts_.  For original piano scores,
you usually want to be in control of the voicing.

-- 
David Kastrup

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

Re: partcombine for choir and piano?

[Karlin High]

On 8/2/2018 4:37 PM, Simon Albrecht wrote:

On 02.08.2018 23:15, Noeck wrote:

1. Does \partcombine make sense for combining *soprano and alto* into
one staff or should I use voices? I see pros (+) and cons (-):

  - The fact that I would prefer the 'apart' style everywhere makes me
    think that it's perhaps not what \partcombine is intended for.

>
It certainly isn’t; surely nobody ever considered vocal writing while 
working on the part combiner. But that doesn’t necessarily mean that it 
doesn’t work; since the part combiner always uses the same internal 
voice names, I can even imagine (without ever having tried it) that in a 
clever setup one could find a convenient way to flexibly attach lyrics, 
coordinated with the modes of the part combiner.


Almost all of my LilyPond projects are SATB or TTBB hymns or choral 
music. I use \partcombine unless I have a more-complex work that needs 
each part on its own staff. This is because my audiences are not used to 
the "apart" style.


Since you prefer the "apart" style, you could just use separate 
simultaneous voices. My experience with \partcombine makes me doubt that 
it would be a big improvement for handling dynamics, but instead would 
likely have its own set of problems. For example, voices get de-combined 
at dynamics, might need a separate simultaneous dynamics context.


For lyrics on a multi-voice staff, associating them with a simultaneous 
NullVoice is often the way to go.

--
Karlin High
Missouri, USA

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

Re: partcombine for choir and piano?

[Simon Albrecht]

On 02.08.2018 23:58, Noeck wrote:

There are two forte signs (one would be enough) below the staff (above
would be better). I understand that I have to take care because of the
lyrics. But why isn't the upper voices' dynamics above the staff - as
\voiceOne does set the direction for so many other things?


I don’t know, and it doesn’t appear to make sense…
<< c''\f \\ c'\p >>
is completely ambiguous with both dynamic texts below the staff.

I recently started using the attached custom contexts for vocal music 
and it seems to be working very well.


Best, Simon
\version "2.19.80"

% always include this file _after_ all other modifications
% to the Staff and Voice contexts

\layout {
  \context {
\Staff
\name VocalStaff
\alias Staff
\override AccidentalSuggestion.direction = #UP
\dynamicUp
\override LigatureBracket.direction = #UP
\override PhrasingSlur.direction = #UP
\override Script.direction = #UP
%\override Slur.direction = #UP
\override TextScript.direction = #UP
\override TupletBracket.direction = #UP
\override TrillSpanner.direction = #UP
  }
  \context {
\Voice
\name VocalVoice
\alias Voice
autoBeaming = ##f
  }
  \inherit-acceptability "VocalStaff" "Staff"
  \inherit-acceptability "VocalVoice" "Voice"
}

%{
suggestion by Harm:

foo =
#(define-music-function (mus)(ly:music?)
 (music-map
   (lambda (m)
 (if (music-is-of-type? m 'override-property-event)
 (begin
   (ly:music-set-property! m 'pop-first '())
   m)
 m))
   mus))

myVoiceOne = \foo \voiceOne
myVoiceTwo = \foo \voiceTwo
myVoiceThree = \foo \voiceThree
myVoiceFour = \foo \voiceFour
%}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

changing symbols used by Measure_grouping_engraver

[Flaming Hakama by Elaine]

>
> > >



\version "2.19.81"

%{
I wonder if anyone can point me in the right direction.

I'd like to modify the sybols used by the Measure_grouping_engraver
http://lilypond.org/doc/v2.19/Documentation/snippets/rhythms#rhythms-conducting-signs-measure-grouping-signs

In particular, how to change the symbol used to denote the dotted 8th value
in compund time:
instead of a triangle, how do I get a vertical bar (or slash)?

%}
\score {
\new Voice \relative c'' {

\time 9/8
%  The default beat grouping is fine.
%  But I'd like a vertical bar instead of the triangle
%\set Timing.beatStructure = #'(3 3 3)
d4. d d |
}
\layout {
\context {
\Staff
\consists "Measure_grouping_engraver"
}
}
}


Please let me know if you have any thoughts.


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Interactive PDF Link to Notes in Preview

[Federico Bruni]

Il giorno gio 2 ago 2018 alle 9:28, Federico Bruni  
ha scritto:



Il giorno lun 9 lug 2018 alle 7:26, Mats Behre 
<"mb.maillists"@gmail.com> ha scritto:





My problem now is that SwiftDefaultApps silently fails to set this 
as the textedit target, possibly because my info.plist is too old 
(it has worked in the past):




I got a silent fail also with RCDefaultApp.
Today I installed SwiftDefaultApps, but when I try to open it, it 
says it doesn't work with Intel processors.




Upgrading High Sierra fixed the problem:
https://github.com/Lord-Kamina/SwiftDefaultApps/issues/1#issuecomment-409895914


I tried a simplified version of below Info.plist (I copied, as you 
did, the relevant part from LilyPond Info.plist).
Unfortunately I could not find an easy tutorial to write your own 
Info.plist from scratch. It seems that normal procedure is building 
it in Xcode...




I'm trying to figure this out with SwiftDefaultApps developer:
https://github.com/Lord-Kamina/SwiftDefaultApps/issues/4




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