lilyjazz

[Menu Jacques]

Hello folks,

I’ve seen several posts and web pages regarding lilyjazz, but there seems to be 
several versions with different file names and contents.

Is there kind of a latest version?

Thanks for your help!

JM



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

tuplet bracket slope

[Gilberto Agostinho]

Hi all,

I am wondering if the way LilyPond's tuplet bracket algorithm works is
really ideal. It seems to me that the algorithm does not specify a maximum
slope for the brackets, and can produce things like this:

\version "2.19.37"

{
  \tuplet 5/4 { 16 d'4 }  
  \tuplet 5/4 { 16 d'4 }  
  \tuplet 5/4 { 16 d'4 }
  \tuplet 5/4 { 16 d'4 }
  \tuplet 5/4 { 16 d'4 }
  \tuplet 5/4 { 16 d'4 }
  \tuplet 5/4 { 16 d'4 }
  \tuplet 5/4 { 16 d'4 }
}

 

If there would be a maximum slope, the results could be something like this:

\version "2.19.37"

{
  \once \override TupletBracket.positions = #'(6 . 4)
  \tuplet 5/4 { 16 d'4 }  
  \once \override TupletBracket.positions = #'(6.5 . 4.5)
  \tuplet 5/4 { 16 d'4 }  
  \once \override TupletBracket.positions = #'(7 . 5)
  \tuplet 5/4 { 16 d'4 }
  \once \override TupletBracket.positions = #'(7.5 . 5.5)
  \tuplet 5/4 { 16 d'4 }
  \once \override TupletBracket.positions = #'(8 . 6)
  \tuplet 5/4 { 16 d'4 }
  \once \override TupletBracket.positions = #'(8.5 . 6.5)
  \tuplet 5/4 { 16 d'4 }
  \once \override TupletBracket.positions = #'(9 . 7)
  \tuplet 5/4 { 16 d'4 }
  \once \override TupletBracket.positions = #'(13 . 11)
  \tuplet 5/4 { 16 d'4 }
}

 

The latter seems like a more reasonable approach to me. Does anyone have
access to Elaine Gould's /Behind Bars/? If so, what does she says about the
bracket slope?

Cheers!
Gilberto



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/tuplet-bracket-slope-tp192294.html
Sent from the User mailing list archive at Nabble.com.

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

Re: tuplet bracket slope

[Gilberto Agostinho]

Brian Barker replied to me and to the list, but for some reason his reply
isn't showing here, so I quote:


Brian Barker wrote
> Angle of brackets
> Groups without beams
> Brackets may slant in the direction of the tuplet's outer pitches
> The angle of slant should not be too acute; match an equivalent beam slant
> Alternatively, brackets may remain horizontal. For a line of undulating
> groups this avoids the visual distraction of many sloping brackets
> (pp 196-7)
> 
> Beam angles should not deviate far from the horizontal because the eye
> perceives duration on the horizontal plane. Usually, they cross no more
> than one stave-line. Thus the wider the interval, the more flattened the
> beam angle becomes in relation to the size of the interval
> (p 19)
> 
> Beams outside the stave
> Some editions have steeper angles outside the staves since there is no
> need to take account of crossing stave-lines. However, matching angles
> look better
> (p 21)
> 
> Brian Barker 

So I would say that from Gould's opinion, there should indeed be a slope
limit to the tuplet brackets, and that slopes should never be too acute
anyway. Also, it would be great to have some way of forcing the brackets to
be always horizontal, similar to what can be achieved with beams by using
\override Beam.damping = #+inf.0

Cheers,
Gilberto



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/tuplet-bracket-slope-tp192294p192297.html
Sent from the User mailing list archive at Nabble.com.

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

LILYPOND VERSION

[rosros]

I would like to recover the value of the lilypond version statement to insert
it in the tagline.

With "\simple #(lilypond-version)" I can recover the current lilypond
version which is not necessarily the same string.

Is there a solution other than hard-coding it?

TIA
Rossano





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/LILYPOND-VERSION-tp192298.html
Sent from the User mailing list archive at Nabble.com.

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

Re: LILYPOND VERSION

[David Kastrup]

rosros  writes:

> I would like to recover the value of the lilypond version statement to insert
> it in the tagline.
>
> With "\simple #(lilypond-version)" I can recover the current lilypond
> version which is not necessarily the same string.
>
> Is there a solution other than hard-coding it?

Looking at the code in lexer.ll (and elsewhere), the answer is quite
definitely "no".  The version number never leaves the bowels of the
tokenizer and is never stored anywhere in any form.  Since it is a
reserved word, you cannot even redefine the \version statement.

It would be a reasonable extension to store the version number in
version-seen but at the current moment it is merely set to #t when the
\version statement is encountered.

You can write

ver = "2.18.0"
\version #ver

...

and output #ver at some point of time.  That's probably the best you can
currently hope for.

-- 
David Kastrup

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

Re: LILYPOND VERSION

[David Wright]

On Wed 06 Jul 2016 at 10:21:15 (-0700), rosros wrote:
> I would like to recover the value of the lilypond version statement to insert
> it in the tagline.
> 
> With "\simple #(lilypond-version)" I can recover the current lilypond
> version which is not necessarily the same string.
> 
> Is there a solution other than hard-coding it?

vrsion = "2.18.0"
\version "2.18.0"

at least allows you to see they're the same at a glance.
Then embed \vrsion in your tagline.

But there's a category error here, isn't there? The lilypond-version
is a property of the program and hence the run. So, like many, I have
\concat { "LilyPond version " $(lilypond-version) } embedded in my
typical tagline. The PDFs bearing that tagline were all run by that
lilypond-version.

OTOH the \version is a property of each individual file. A run might
include many files written in the syntax of different versions.
Understandably, files like (a trivial example)

%% Letter-landscape.ily
\version "2.18.0"
\paper {
  #(set-paper-size "letter" 'landscape)
}

don't get put through convert-ly very often.

So it's moot what an overall printed \version should be.

Cheers,
David.

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

Arpeggio across notes of differing lengths

[Joel C. Salomon]

In the score to Peter Pan I’ve come across what appears to be an
arpeggio with notes of different lengths.  I’ve come up with the kluge
below, but it doesn’t really look right (the hidden notes take up space,
and show up in the MIDI output).  What’s the correct way to achieve this?

\version "2.19.44"
\language "english"

lower = \relative c {
\clef bass
\key d \minor
\time 2/4
<<  {
\voiceOne
bf'2|
}
\new Voice {
\voiceTwo
f,4e|
}
\new Voice {
\voiceTwo
\hideNotes
\arpeggioParenthesis
4\arpeggio
\arpeggioNormal
\unHideNotes
}
>>
\oneVoice
}

\score {
\new Staff = "lower" \lower
\layout {}
}

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

Sustain pedals (newbie question)

[Joel C. Salomon]

The attached .ly is an attempt to recreate the score shown in the
attached PNG file, but the position of the pedal marks is different, and
I can’t figure out how to achieve this.  (My MIDI interface is also not
so great that I can tell whether the pedal is depressed in the correct
place.)

It’s entirely possible I’m completely missing the mark about how to use
the sustain pedals in Lilypond, but this is my best effort given my
reading of the manual.  Any pointers or corrections would be
appreciated; explanations even more so.

(The discussion “Piano pedal mark collision (\sustainOn, \sustainOff)”
from January of this year,
, is
likely related, but part of me not understanding Lilypond’s
sustain-pedal notation is that I don’t understand what Mr Pawelczyk is
doing in that thread.)

—Joel C. Salomon
\version "2.19.44"

\language "english"

upper = \relative c'' {
	\clef treble
	\key d \minor
	\time 2/4

	\grace s8
	c'16	a	g	f	|
	|
}

lower = \relative c {
	\clef bass
	\key d \minor
	\time 2/4

	\acciaccatura f,8 a'4->		\acciaccatura g,8 bf'4->	|
	\acciaccatura a,8 c'4->
	<<
		{ \voiceOne		a8		c		}
		\new Voice { \voiceTwo	d,4}
	>> \oneVoice			|
}

dynamics = {
	s2*16
}

pedal = {
	\grace s8 s4 \sustainOn	\grace 8 \sustainOff s4 \sustainOn
	\grace s8 \sustainOff s4 \sustainOn s4 \sustainOff
}

\score {
	\new PianoStaff <<
		\new Staff = "upper" \upper
		\new Dynamics = "dynamics" \dynamics
		\new Staff = "lower" \lower
		\new Dynamics = "pedal" \pedal
	>>
	\layout {
		\context {
			\PianoStaff
			\accepts Dynamics
		}
	}
}
\score {
	\new PianoStaff <<
		\new Staff = "upper" <<
			\upper
			\dynamics
		>>
		\new Staff = "lower" <<
			\lower
			\dynamics
		>>
		\new Dynamics = "pedal" \pedal
	>>
	\midi {
		\context {
			\type "Performer_group"
			\name Dynamics
			\consists "Piano_pedal_performer"
		}
		\context {
			\PianoStaff
			\accepts Dynamics
		}
	}
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Arpeggio across notes of differing lengths

[Robin Bannister]

Joel C. Salomon wrote:

In the score to Peter Pan I’ve come across what appears to be an
arpeggio with notes of different lengths.


This corresponds to the example
'Creating arpeggios across notes in different voices'
in NR 1.3.3.
http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-as-lines#arpeggio

but unfortunately its says further down
'The simple way of setting parenthesis-style arpeggio brackets does not 
work for cross-staff arpeggios'



This is because \arpeggioParenthesis assumes you are inside just one 
Voice, and so is ineffective for PianoStaff and even just Staff.

So you must do what it does, but for Staff, e.g.


\new Staff \with {
  \consists "Span_arpeggio_engraver"
}
\relative c' {
  \set Staff.connectArpeggios = ##t
  \once \override Staff.Arpeggio.stencil = #ly:arpeggio::brew-chord-slur
  \once \override Staff.Arpeggio.X-extent = #ly:grob::stencil-width
  <<
{ 4\arpeggio  2 }
\\
{ 2\arpeggio 2 }
  >>
}


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

Re: Sustain pedals (newbie question)

[Carl Sorensen]

On 7/6/16 2:17 PM, "Joel C. Salomon"  wrote:
>
>
>It¹s entirely possible I¹m completely missing the mark about how to use
>the sustain pedals in Lilypond, but this is my best effort given my
>reading of the manual.  Any pointers or corrections would be
>appreciated; explanations even more so.

I looked at the music.  Sustain on happened on each 1/4 note beat, sustain
off happened at the fourth  sixteenth note in each 1/4 note beat.  So I
just changed the pedal line to the following:

 pedal = {
 s8. \sustainOn s16 \sustainOff s8.\sustainOn s16\sustainOff
 s8. \sustainOn s16 \sustainOff s8.\sustainOn s16\sustainOff
}

And that worked perfectly from my point of view.

Thanks,

Carl


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

Re: Sorting out annotation interface questions (GSoC)

[Jeffery Shivers]

I suggest the distinction between annotation type (critical remark, etc.),
edition type (addition, emendation, etc.), and observation type (addition,
emendation, etc.). This is a fairly loose naming scheme, but I'll clarify
that it's all oriented to the usual annotations interface (so not referring
to new hooks independent of annotations yet, though I agree those
should/could be available as well at some point).

In context, and including the use of "category" as well:

\criticalRemark% annotation type
\with {
message = "This slur was later added by the composer."
observation = addition% observation of an addition; not our
application of it.
category = phrasing
}

\musicalIssue% annotation type
\with {
message = "I added the slur."
edition = addition% applies our edition
category = phrasing
}

Category and observation could both be used for filtering/sorting
annotations, so there's that additional benefit of having those
distinctions. Again, everything that goes into those lists can be set by
the user. Same for "edition", as well as for how the items are uniquely
affected (user decides the `foo` edition type will make slurs dashed,
noteheads parenthesized, etc.), if at all:

Perhaps `apply-edition` should rather be the property for automated
editions, and simply `edition` will *not* automate anything, but will still
indicate what the author has done and will be available and sortable as a
sort of static property, similar to category and observation. In the
critical reports, both `apply-edition` and `edition` could at that point
appear as `edition` (if chosen to be printed in the report at all, of
course).

Further down the road, we could also implement edition priorities
(separately from annotation priority, which is another upcoming feature for
general sorting/filtering annotations by priority), where certain
individual specified editions can *always* be applied/forced regardless of
mode/options. So this also brings up the idea that the printing/exporting
of annotations can be themselves sorted/filtered, while the application of
their editions (if any) are *independently* filtered/sorted, if desired.
This sort of does the same thing as I suggested with edition/apply-edition,
but from a different angle. Since the aim is to be as flexible as possible,
it may be wise to start with both angles as a possibility from the get-go.

On Mon, Jun 27, 2016 at 7:57 AM, Urs Liska  wrote:

> Hi Simon,
>
> thanks for the feedback.
>
>
> Am 27. Juni 2016 13:21:25 MESZ, schrieb Simon Albrecht <
> simon.albre...@mail.de>:
> >On 27.06.2016 00:55, Urs Liska wrote:
> >> \musicalIssue \with {
> >>author = "Urs Liska"
> >>context = "violin 1"
> >>message = "Slur obviously forgotten in original edition"
> >>apply = addition
> >> } Slur
> >>
> >> My question is: is this "application" the same as the type of
> >annotation
> >> action from the previous issue? Or could it occur that a project
> >wants
> >> to document types of editorial decisions independently from applying
> >> visual indications of that?
> >
> >A few unsystematic thoughts:
> >Well, there are limits to visual indication of critical matters. At
> >least in some projects it will be impossible for the score to contain
> >(or even hint to) every bit of information present in the Critical
> >Report.
> >I really think we should allow for great diversity in the possible
> >approaches, i.e. editorial policies.
>
> We certainly don't intend to impose editorial policies but to provide the
> tols to tailor project specific behaviour.
>
> By default annotations dob't have any impact on the layout (which is
> crucial) but just colorize objects while in draft mode.
>
> Additionally we'll provide generic commands that can be used to visually
> indicate certain types of editorial action.
>
> For example something like \editorialAddition can be used to indicate
> something that is missing in the source and has been added by the editor.
> By default this might make slurs dashed and parenthesize other types of
> elements. Of course the visual appearance will be configurable so only the
> semantic command is inserted in the music.
>
> Now annotations *can* trigger the application of such editorial commands
> (which can also be used independently from annitations).
> My question is: are the *type* of decision and the triggering oc commands
> inherently independent so we should implement both a property forvthe
> annotation type *and* the applied command or could they be "merged"?
>
> > In some cases it might be good to
> >have a simple switch (modernise lyrics or not);
> >in other cases everything must be decided on a case-by-case basis, with
> >
> >no automation being possible;
> >and the type of annotations one will have, as well as how to display
> >them in both the score and the critical apparatus, will be very
> >different depending on the project.
>
> Of course, 

Re: offset for lyrics does not offset the lyric hyphens

[Thomas Morley]

2016-07-06 4:26 GMT+02:00 Br. Gabriel-Marie | SSPX :
> Sorry, I didn't realize embedded images didn't show.  I've attached them
> this time.
>
> On 7/5/2016 9:10 PM, Br. Gabriel-Marie | SSPX wrote:
>
> Mr. Morley,
>
> I want to achieve the numbering to line up at the front of the lyrics.  The
> script that your other self created to number the stanza lines does not line
> them up - it does, indeed, get the numbering, but not the justification of
> the numbers.
>
> That's why I haven't given up using instrumentName for the numbering.
> instrumentName will line up the numbers at the front.  (Problem with this,
> as I've mentioned, is that if the clef does not have the extra spacing
> provided by the three sharps in the key signature, then the lyrics can
> overlap the numbers.  )
>
> You can see in the second attachment the difference here.  If the words are
> longer then the numbers move and don't line up with the numbers on the next
> staff.
>
>
> On 7/5/2016 2:08 PM, Thomas Morley wrote:
>
> It's not clear to me at which position exactly?
> Below (if any) the Clef, KeySignature/Cancellation, TimeSignature,
> BarLine or else?
> Righ-/center-/left-aligned?
>
> Let's clear that first and then look for a method to avoid collisions.
>
> Cheers,
>   Harm
>
>

Attached best I currently can think of.
Though, please always provide tiny examples matching the images you post.

-Harm
\version "2.19.44"

%% REMARK:
%% Using instrument-names _and_ setting an invisible stanza with a certain 
%% extent at line-begin to avoid collisions

%% Thanks to David Nalesnik
%% http://lists.gnu.org/archive/html/lilypond-user/2016-07/msg00028.html

#(define create-stanza-number-grob-engraver
;; puts out a StanzaNumber for every LyricText-grob
  (lambda (context)
(let ((stanza (ly:context-property context 'stanza)))
  `((acknowledgers
  (lyric-syllable-interface .
,(lambda (engraver grob source-engraver)
  (let ((new-stanza-grob 
  (ly:engraver-make-grob engraver 'StanzaNumber '(
  (ly:grob-set-property! new-stanza-grob 'text stanza)

#(define (at-line-beginning? grob)
   (let* ((col (ly:item-get-column grob))
  (ln (ly:grob-object col 'left-neighbor))
  (col-to-check (if (ly:grob? ln) ln col)))
 (and (eq? #t (ly:grob-property col-to-check 'non-musical))
  (= 1 (ly:item-break-dir col-to-check)

#(define (keep-at-line-begin grob)
   (if (and (ly:item? grob) (not (at-line-beginning? grob)))
   (ly:grob-suicide! grob)
   grob))

keepLineStartStanzaNumbers =
\layout {
  \context {
  \Lyrics
  \override StanzaNumber.after-line-breaking =
#keep-at-line-begin
  }
}

numberLyrics =
#(define-scheme-function (instr-name move)(number? number?)
"Return a context-modification setting @code{stanza} and consisting 
@code{create-stanza-number-grob-engraver}, as well as @code{instrumentName} and
@code{shortInstrumentName}.
The latter prints the numbering using @var{instr-name}, the first is used to 
push the lyrics to the right, using @var{move}.
"
#{
  \with {
%stanza = \markup \italic #(format #f "~a." nmbr)
stanza = \markup \combine \null \translate #(cons move  0) \null
\consists #create-stanza-number-grob-engraver
	instrumentName = #(format #f "~a." instr-name)
	shortInstrumentName = #(format #f "~a." instr-name)
  }
#})


%% EXAMPLE


\score {
  <<
\new Staff { \key cis \major \repeat unfold 6 {  c''4 d'' e'' } }
\new Lyrics 
  \with {
\numberLyrics 1 3.5
	  }
  \lyricmode {
\repeat unfold 6 {  foo -- bar -- buzz }
  }
  
\new Lyrics  
  \with {
\numberLyrics 2 3.5
	  }
  \lyricmode {
\repeat unfold 6 {  very-very-long-syllable bur -- buuuzz }
  }
  
\new Lyrics  
  \with {
\numberLyrics 3 3.5
	  }
  \lyricmode {
\repeat unfold 6 {  fuu -- bla -- blibbb }
  }
  >>
  \layout { 
  	  \keepLineStartStanzaNumbers 
  	  \context {
  	\Lyrics 
  	\override InstrumentName.X-offset = 2
  	  }
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Arpeggio across notes of differing lengths

[Joel C. Salomon]

On 2016-07-06 4:16 PM, Robin Bannister wrote:
> This corresponds to the example
> 'Creating arpeggios across notes in different voices'
> in NR 1.3.3.
> http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-as-lines#arpeggio
> 
> but unfortunately its says further down
> 'The simple way of setting parenthesis-style arpeggio brackets does not
> work for cross-staff arpeggios'
> 
> This is because \arpeggioParenthesis assumes you are inside just one
> Voice, and so is ineffective for PianoStaff and even just Staff.
> So you must do what it does, but for Staff, e.g.


Thank you; that worked. Interestingly, it is not documented there that
\arpeggio will work for notes which are not themselves chords.  Until
I’d added your code, putting \arpeggio there caused an error message
“warning: no heads for arpeggio found?”, which seemed to me to indicate
that this would not work; I’m glad to be wrong.

—Joel C. Salomon

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

Re: Sustain pedals (newbie question)

[Joel C. Salomon]

On 2016-07-06 5:12 PM, Carl Sorensen wrote:
> I looked at the music.  Sustain on happened on each 1/4 note beat, sustain
> off happened at the fourth  sixteenth note in each 1/4 note beat.  So I
> just changed the pedal line to the following:
> 
>  pedal = {
>s8. \sustainOn s16 \sustainOff s8.\sustainOn s16\sustainOff
>s8. \sustainOn s16 \sustainOff s8.\sustainOn s16\sustainOff
> }

For some reason, the way you wrote this made the `s32*31 \sustainOn s32
\sustainOff` trick make sense.  (But you’re probably right about how
this particular case is notated.)  Thank you.

—Joel C. Salomon

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

Re: tuplet bracket slope

[Andrew Bernard]

Hi Gilberto,

On 7 July 2016 at 3:07:25 AM, Gilberto Agostinho wrote:


> Beam angles should not deviate far from the horizontal because the eye
> perceives duration on the horizontal plane.

What nonsense Gould writes here. I perceive duration in notation on any
angle. The book is not always right in its justifications.



So I would say that from Gould's opinion, there should indeed be a slope
limit to the tuplet brackets, and that slopes should never be too acute
anyway. Also, it would be great to have some way of forcing the brackets to
be always horizontal, similar to what can be achieved with beams by using
\override Beam.damping = #+inf.0



Here’s how to set all tuplet brackets horizontal on one command:

horizontalTuplets =
\override TupletBracket #'stencil =
#(lambda (grob)
   (let* ((pos (ly:grob-property grob 'positions))
  (dir (ly:grob-property grob 'direction))
  (new-pos (if (= dir 1)
   (max (car pos)(cdr pos))
   (min (car pos)(cdr pos)
 (ly:grob-set-property! grob 'positions (cons new-pos new-pos))
 (ly:tuplet-bracket::print grob)))


Originally from Thomas Morley. I posted this recently along with the code
for the extremely useful \tupletAngles function which was then discussed in
detail.

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

PDF author metadata

[Federico Bruni]

Hi all

I'd like to edit this page of the documentation:
http://lilypond.org/doc/v2.19/Documentation/notation/creating-pdf-metadata.html

to add what I learned here:
https://lists.gnu.org/archive/html/bug-lilypond/2016-07/msg8.html

I have another question on this subject.
Who should be in your opinion the author of a LilyPond score PDF? The 
composer or the typesetter?

Of course the answer depends on the use case.
In my opinion having the composer (or arranger) as author is more 
useful, because you can filter the scores in your hard disk by author 
metadata if you use a document management software (such as Gnome 
Documents in Linux).


Do you think that it's worth adding a paragraph about it in the 
documentation? i.e. recomend using pdfauthor along with composer in the 
\header block.


The advantage of an application such as Gnome Documents is that you can 
quickly access a PDF score without having to browse through folders in 
the file manager.





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