Re: Frescobaldi to default window layout

[Aaron Hill]

On 2018-06-30 19:54, Freeman Gilmore wrote:

​How do I restore Frescobaldi to the default window layout?
Thank you, ƒg


Probably silly for me to even attempt to field this question as I have 
never used Frescobaldi before.  Doing a quick search did not turn up 
anything about options for resetting the layout.  I would recommend 
filing an issue for this as a feature request: 
https://github.com/wbsoft/frescobaldi/issues


In the meantime, the best option might be to look for and manually 
delete the settings that have been persisted.  The location of these 
settings will depend on your platform, as PyQt4's QSettings attempts to 
generalize this away from the application.  Here is an excerpt from the 
docs:


http://pyqt.sourceforge.net/Docs/PyQt4/qsettings.html:

This information is often stored in the system registry on Windows,
and in XML preferences files on Mac OS X. On Unix systems, in the
absence of a standard, many applications (including the KDE
applications) use INI text files.


It should be noted that you should keep a backup of any settings files 
you change in case you need to revert.


-- Aaron Hill

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

Re: \unset with modified default properties

[Saul Tobin]

Unfortunately, for my use case, \once\set and \once\unset aren't enough.

On Sat, Jun 30, 2018 at 8:31 PM Aaron Hill  wrote:

> On 2018-06-30 17:50, Saul Tobin wrote:
> > In both 2.18 and 2.19, \unset appears to set a context property to the
> > built-in default, rather than the default set in the \with {} block:
> >
> > [ . . . ]
> >
> > In cases like this, I would find it useful to reset the property to the
> > custom default value without having to explicitly \set it every time.
> > Is
> > there a way to do this? Also, is this the most useful behavior of
> > \unset?
>
> While not a completely general solution, you may be able to use \once:
>
> 
>music = \relative c' {
>  \tuplet 3/2 {
>c8 c c d d d e e e f f f |
>  }
>  \once \set Staff.tupletSpannerDuration = #(ly:make-moment 1/2)
>  \tuplet 3/2 {
>c8 c c d d d e e e f f f |
>  }
>  \tuplet 3/2 {
>c8 c c d d d e e e f f f |
>  }
>}
> 
>
> -- Aaron Hill
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \unset with modified default properties

[Aaron Hill]

On 2018-06-30 17:50, Saul Tobin wrote:

In both 2.18 and 2.19, \unset appears to set a context property to the
built-in default, rather than the default set in the \with {} block:

[ . . . ]

In cases like this, I would find it useful to reset the property to the
custom default value without having to explicitly \set it every time. 
Is
there a way to do this? Also, is this the most useful behavior of 
\unset?


While not a completely general solution, you may be able to use \once:


  music = \relative c' {
\tuplet 3/2 {
  c8 c c d d d e e e f f f |
}
\once \set Staff.tupletSpannerDuration = #(ly:make-moment 1/2)
\tuplet 3/2 {
  c8 c c d d d e e e f f f |
}
\tuplet 3/2 {
  c8 c c d d d e e e f f f |
}
  }


-- Aaron Hill

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

Frescobaldi to default window layout

[Freeman Gilmore]

​How do I restore Frescobaldi to the default window layout?
Thank you, ƒg
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

\unset with modified default properties

[Saul Tobin]

In both 2.18 and 2.19, \unset appears to set a context property to the
built-in default, rather than the default set in the \with {} block:

music = \relative c' {
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
  \set Staff.tupletSpannerDuration = #(ly:make-moment 1/2)
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
  \unset Staff.tupletSpannerDuration
  \tuplet 3/2 {
c8 c c d d d e e e f f f |
  }
}

\new Staff \with {
  tupletSpannerDuration = #(ly:make-moment 1/4)
} \music

In cases like this, I would find it useful to reset the property to the
custom default value without having to explicitly \set it every time. Is
there a way to do this? Also, is this the most useful behavior of \unset?

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

Re: Opinions requested on deprecating "annotation" commands

[Urs Liska]

Hi Simon and Craig,

I think it's a good point. And since maybe I'll have to suffer more than 
anyone else ;-) I shouldn't wring my hands too much and just go for that.


There will be a Git tag referencing the latest state of the "old" 
interface, and it should be possible to use that for existing projects. 
Of course when someone wants to make use of the additional functionality 
they'd have to update their projects but for others this should at least 
work as long as LilyPond progress won't make things incompatible.


Best
Urs


Am 01.07.2018 um 00:04 schrieb Craig Dabelstein:
I'm happy to go with the consensus. Breaking any of my old documents 
won't be an issue for me, and I'm happy to defer to your expertise.


Craig

On Sat, 30 Jun 2018 at 23:13, Simon Albrecht > wrote:


On 30.06.2018 14:14, Urs Liska wrote:
> # Encourage people to use the new system and "deprecate" the old
syntax
> (but leave it alone and working). The downside is that the
*names* of
> the old commands are very much what one would want, so I
wouldn't want
> to discard them completely.
> # Make the old names wrappers around the new technology, so one can
> still say \criticalRemark.

I’d vote for the latter. Better to make a clean cut, and there’s
so much
potential in this, and the number of users seems to be limited
until now
in my perspective – I may be wrong.

Best, Simon

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



--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/


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

Re: Opinions requested on deprecating "annotation" commands

[Craig Dabelstein]

I'm happy to go with the consensus. Breaking any of my old documents won't
be an issue for me, and I'm happy to defer to your expertise.

Craig

On Sat, 30 Jun 2018 at 23:13, Simon Albrecht  wrote:

> On 30.06.2018 14:14, Urs Liska wrote:
> > # Encourage people to use the new system and "deprecate" the old syntax
> > (but leave it alone and working). The downside is that the *names* of
> > the old commands are very much what one would want, so I wouldn't want
> > to discard them completely.
> > # Make the old names wrappers around the new technology, so one can
> > still say \criticalRemark.
>
> I’d vote for the latter. Better to make a clean cut, and there’s so much
> potential in this, and the number of users seems to be limited until now
> in my perspective – I may be wrong.
>
> Best, Simon
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re:\bookparts and scaling (Karlin High)

[Cynthia Karl]

> 
> Message: 2
> Date: Fri, 29 Jun 2018 13:18:18 -0500
> From: Karlin High 
> To: lilypond-user@gnu.org, David Wright ,
>   crimsonsunr...@protonmail.com
> Cc: torsten.haemme...@web.de, David Kastrup 
> Subject: Re: \bookparts and scaling
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 6/29/2018 10:46 AM, David Wright wrote:
>> software is more like a work of art that has to be sculpted into perfection,
>> which takes time, trouble and effort.
> 
> Okay, moving in that direction.
> 
> The documentation could be updated to better reflect the current state 
> of these staff-size commands.
> 
> Or, would it be possible to have a command that does what the OP 
> expects? Namely, applying the effect of set-global-staff-size to 
> bookparts individually and independently, whether via 
> layout-set-staff-size or something else.
> 
> I can poke around some more at that 
> layout-set-absolute-staff-size-in-module thing in paper.scm, but it 
> would be nice to have some input from someone who actually understands 
> these internals, about whether that approach is likely to succeed.

Unfortunately, I cannot claim to be that someone who actually understands these 
internals.  However, ever since someone posted a scheme function called 
“staffSize”, I have no problems with staff sizes.

Here is the staffSize function:

% Define staves, e.g., so:  \new Staff \with {\staffSize #4 } 

staffSize = #(define-music-function (new-size) (number?)
#{
  \set fontSize = #new-size
  \override StaffSymbol #'staff-space = #(magstep new-size)
  \override StaffSymbol #'thickness = #(magstep new-size)
#})

An example of its usage:

music = { … }

\score {
  new StaffGroup \with { \staffSize #0 } <<
\new Staff \with { \staffSize #4 } \music
\new Staff \music
\new Staff \with { \staffSize #-4 } \music
  <<
}

This score block will produce a pdf with a group of three staves, the first one
at 24 pts, the second one at the default 20 pts (inherited from the StaffGroup 
\with
block), and the third one at 16 pts.

It appears that each occurrence of \score in a book resets the staff size to 
the default 20 pts.



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

Re: chord names - C Delta 7 chord?

[Reilly Farrell]

Thank you Thomas!  Works like a charm. :)

On Sat, Jun 30, 2018 at 1:08 AM, Thomas Morley 
wrote:

> 2018-06-30 8:37 GMT+02:00 Reilly Farrell :
> > Hi All,
> >
> > I'm looking for a solution for printing a C Delta 7 chord name (so that 7
> > prints clearly after the delta symbol).  I started off wth the failed
> > attempt below and haven't had much success anyway else:
> >
> > \version "2.18.2"
> >
> > \score {
> > <<
> > \relative c' {
> > c4 c c c |
> > }
> >
> > \chords {
> > c1:maj7.7
> > }
> >>>
> > \layout{}
> > \midi{}
> > }
> >
> > Any assistance or suggestion is appreciated.  Thank you!
>
>
> Usually the "delta symbol" _is_ the symbol for major seven.
> Admittedly, I know other notations as well. Though, I've never seen a
> "delta symbol" _and_ "7".
>
> Anyway, the context-property `majorSevenSymbol` could be adjusted to
> retrun as you wish.
>
> \layout {
>   \context {
> \Score
> %% whiteTriangleMarkup is the default, see engraver-init.ly
> majorSevenSymbol = \markup { #whiteTriangleMarkup 7 }
>   }
> }
>
> \chords {
>   c1:7+
> }
>
> HTH,
>   Harm
>



-- 
Reilly Farrell
reillycfarr...@gmail.com
(650) 787-2751
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

edition-engraver: multiple editions

[Mason Hock]

I'm slowly getting a handle on edition-engraver, largely thanks to this[1] 
guide, which very clearly explains basic usage for a single edition. However, 
neither the guide nor the usage examples in the repo demonstrate the use of 
multiple editions, and I'm confused as to how that would be done in a useful 
way. For example, these two snippets

--
\version "2.19.82"

\include "oll-core/package.ily"
\loadPackage edition-engraver

\addEdition first
\editionMod first 1 0/4 the-staff.Voice ^\markup { 1 }
\editionMod first 1 2/4 the-staff.Voice ^\markup { 2 }

\consistToContexts #edition-engraver Staff.Voice

\score {
  \new Staff \with { \editionID the-staff } {
\relative c' {
  c d e f
}
  }
}
--

--
\version "2.19.82"

\include "oll-core/package.ily"
\loadPackage edition-engraver

\addEdition first
\editionMod first 1 0/4 the-staff.Voice ^\markup { 1 }

\addEdition second
\editionMod second 1 2/4 the-staff.Voice ^\markup { 2 }

\consistToContexts #edition-engraver Staff.Voice

\score {
  \new Staff \with { \editionID the-staff } {
\relative c' {
  c d e f
}
  }
}
--

produce identical output, so, in the way I've been using edition-engraver so 
far, defining multiple editions does not appear to have a different effect from 
placing all edition-mods in one edition. It is true that I could put the 
edition-mods for each edition in a separate .ily file and only include the one 
I want to use when I compile, but even then there is no reason that the edition 
in each file could be called "first" instead of giving the editions different 
names.

My expectation would be that there is a way of specifying which editions(s) 
should have their edition-mods observed and which should be ignored, but I 
can't find any information about this. Can anyone provide an example of correct 
usage of edition-engraver to maintain multiple editions?

Thanks,

Mason


[1] https://lists.gnu.org/archive/html/lilypond-user/2018-01/msg00603.html


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

Re: Opinions requested on deprecating "annotation" commands

[Simon Albrecht]

On 30.06.2018 14:14, Urs Liska wrote:
# Encourage people to use the new system and "deprecate" the old syntax 
(but leave it alone and working). The downside is that the *names* of 
the old commands are very much what one would want, so I wouldn't want 
to discard them completely.
# Make the old names wrappers around the new technology, so one can 
still say \criticalRemark.


I’d vote for the latter. Better to make a clean cut, and there’s so much 
potential in this, and the number of users seems to be limited until now 
in my perspective – I may be wrong.


Best, Simon

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

Opinions requested on deprecating "annotation" commands

[Urs Liska]

Hi,

as you know I'm working on a number of features around the scholarLY 
package, and now I'm facing the need to deal with the existing interface.


The openLilyLIb module scholarly.annotate provides commands like 
\criticalRemark, \musicalIssue and a few more that attach an annotation 
to a score element.


Now, while implementing the commands \tagSpan and \editorialMarkup that 
"tag" some music as a finding or editorial decision I gave them the 
capability to also create and attach annotations. And since the function 
interface to \criticalRemark and friends is somewhat clumsy and limited 
in its capability to addressing the annotated music I would like to make 
the \tagSpan approach the new standard.


I see two options, both with disadvantages:

 * Encourage people to use the new system and "deprecate" the old
   syntax (but leave it alone and working). The downside is that the
   *names* of the old commands are very much what one would want, so I
   wouldn't want to discard them completely.
 * Make the old names wrappers around the new technology, so one can
   still say \criticalRemark.

The second solution would definitely be what I want the package to 
behave like. Basically the following two statements would then be 
equivalent:


 * \editorialMarkup annotation \with { ann-type = critical-remark
   message = "My comment" } { c' d' e' }
 * \criticalRemark \with { message = "My comment" } { c' d' e'}

The problem with this is that it would of course break existing 
documents. Of course package development is still in a version 0.X 
state, so breaking changes are definitely not "illegal", but I would 
actually prefer to get some feedback before going into that direction.


I think for most of the cases it would be possible to create a scripted 
solution to update instances (like convert-ly), but I'm reluctant to 
make any promises about that:


\criticalRemark \with {
  message = "Hey"
} NoteHead c'

=>

\critical
Remark \with {
  message = "Hey"
} c'

\musicalIssue \with {
  message = "Hey"
} Accidental cis'

=>
\musicalIssue \with {
  message = "Hey"
  item = Accidental
} cis'

but I'm not sure about the other valid syntax options, and not about all 
the things that could go wrong when comments in the \with block might 
confuse the parser.


Any opinions?

Best
Urs

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

Re: Collision with slash separator and measure numbers

[Ben]

On 6/30/2018 7:20 AM, Torsten Hämmerle wrote:

SoundsFromSound wrote

I've tried to fix this collision but I don't understand how I can avoid
it. I believe it has to do with either my Score.BarNumber stencil or
offsets of measure numbers, but I can't get the right combo with the
system padding.


Hi Ben,

I think this shouldn't solved by any padding at all but by adjusting the
distances between systems.
The separator will always be vertically centred between systems for optical
reasons, and if a bar number happens to collide with the separator, this
just means that the systems are too close together.

In your example, the bar numbers take considerable space (relatively large
font, boxed with lots of padding) so that they even may effectively serve as
a system separator.
As the bar numbers will always be present at the beginning of a system, the
best solution (in my opinion) would be just to increase the overall
system-system-spacing (in the \paper block) to give the score an evenly
spaced look.


%
\version "2.19.81"

\new Staff {
   \repeat unfold 100 { c1  }
}

\layout {
   \override Score.BarNumber.stencil = #(make-stencil-boxer 0.14 0.65
ly:text-interface::print)
   \override Score.BarNumber.Y-offset = #4
   \override Score.BarNumber.X-offset = #-0.3
}


\paper {
   #(set-paper-size "11x17")
   top-margin = 15\mm
   left-margin = 20\mm
   right-margin = 15\mm
   bottom-margin = 15\mm

   system-separator-markup = \slashSeparator
   system-system-spacing = #'((basic-distance . 18)
  (minimum-distance . 17)
  (padding . 1)
  (stretchability . 12))
}

%



HTH,
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


Torsten,

Thank you for explaining that perspective, that's what I was trying to 
make sense of...


Your code works beautifully, must be those magic numbers! ;)

Have a good weekend!


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

Re: Collision with slash separator and measure numbers

[Torsten Hämmerle]

SoundsFromSound wrote
> I've tried to fix this collision but I don't understand how I can avoid 
> it. I believe it has to do with either my Score.BarNumber stencil or 
> offsets of measure numbers, but I can't get the right combo with the 
> system padding.


Hi Ben,

I think this shouldn't solved by any padding at all but by adjusting the
distances between systems.
The separator will always be vertically centred between systems for optical
reasons, and if a bar number happens to collide with the separator, this
just means that the systems are too close together.

In your example, the bar numbers take considerable space (relatively large
font, boxed with lots of padding) so that they even may effectively serve as
a system separator.
As the bar numbers will always be present at the beginning of a system, the
best solution (in my opinion) would be just to increase the overall
system-system-spacing (in the \paper block) to give the score an evenly
spaced look.


%
\version "2.19.81"

\new Staff {
  \repeat unfold 100 { c1  }
}

\layout {
  \override Score.BarNumber.stencil = #(make-stencil-boxer 0.14 0.65
ly:text-interface::print)
  \override Score.BarNumber.Y-offset = #4
  \override Score.BarNumber.X-offset = #-0.3
}


\paper {
  #(set-paper-size "11x17")
  top-margin = 15\mm
  left-margin = 20\mm
  right-margin = 15\mm
  bottom-margin = 15\mm

  system-separator-markup = \slashSeparator
  system-system-spacing = #'((basic-distance . 18)
 (minimum-distance . 17)
 (padding . 1)
 (stretchability . 12))
}

%

 

HTH,
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: chord names - C Delta 7 chord?

[Thomas Morley]

2018-06-30 8:37 GMT+02:00 Reilly Farrell :
> Hi All,
>
> I'm looking for a solution for printing a C Delta 7 chord name (so that 7
> prints clearly after the delta symbol).  I started off wth the failed
> attempt below and haven't had much success anyway else:
>
> \version "2.18.2"
>
> \score {
> <<
> \relative c' {
> c4 c c c |
> }
>
> \chords {
> c1:maj7.7
> }
>>>
> \layout{}
> \midi{}
> }
>
> Any assistance or suggestion is appreciated.  Thank you!


Usually the "delta symbol" _is_ the symbol for major seven.
Admittedly, I know other notations as well. Though, I've never seen a
"delta symbol" _and_ "7".

Anyway, the context-property `majorSevenSymbol` could be adjusted to
retrun as you wish.

\layout {
  \context {
\Score
%% whiteTriangleMarkup is the default, see engraver-init.ly
majorSevenSymbol = \markup { #whiteTriangleMarkup 7 }
  }
}

\chords {
  c1:7+
}

HTH,
  Harm

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

Re: 2.19.82 manuals are very small!

[Phil Holmes]

- Original Message - 
From: "David Wright" 

To: "Lilypond-User" 
Sent: Saturday, June 30, 2018 4:13 AM
Subject: 2.19.82 manuals are very small!



The new 2.19.82 manuals make interesting reading, but the diagrams
leave something to be desired, namely most of the musical fonts:




This has been discussed (but unfortunately not fixed) on the -bug list.

--
Phil Holmes

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

Re: \chords and markup text?

[Jacques Menu Muzhic]

Same part of the doc as for your previous post.

A nice day!

JM

> Le 30 juin 2018 à 08:42, Reilly Farrell  a écrit :
> 
> Hi All,
> 
> Is there a simple way of modifying chord names in the \chords field with 
> markup text?  More specifically, I'm looking for a way to print C7alt as a 
> chord name (with alt printing clearly after the 7), and I'm having some 
> trouble figuring out the syntax.  
> 
> \version "2.18.2"
> 
> \score {
> <<
> \relative c' {
> c4 c c c |
> }
> 
> \chords {
> c1:alt.7
> }
> >>
> \layout{}
> \midi{}
> }
> 
> Any assistance is appreciated.  Thank you!
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: chord names - C Delta 7 chord?

[Jacques Menu Muzhic]

Hello Reilly,

chExceptions is you friend, look for « Customizing chord names » in the LP 
Notation Reference.

JM

> Le 30 juin 2018 à 08:37, Reilly Farrell  a écrit :
> 
> Hi All,
> 
> I'm looking for a solution for printing a C Delta 7 chord name (so that 7 
> prints clearly after the delta symbol).  I started off wth the failed attempt 
> below and haven't had much success anyway else:
> 
> \version "2.18.2"
> 
> \score {
> <<
> \relative c' {
> c4 c c c |
> }
> 
> \chords {
> c1:maj7.7
> }
> >>
> \layout{}
> \midi{}
> }
> 
> Any assistance or suggestion is appreciated.  Thank you!
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

\chords and markup text?

[Reilly Farrell]

Hi All,

Is there a simple way of modifying chord names in the \chords field with
markup text?  More specifically, I'm looking for a way to print C7alt as a
chord name (with alt printing clearly after the 7), and I'm having some
trouble figuring out the syntax.

\version "2.18.2"

\score {
<<
\relative c' {
c4 c c c |
}

\chords {
c1:alt.7
}
>>
\layout{}
\midi{}
}

Any assistance is appreciated.  Thank you!
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

chord names - C Delta 7 chord?

[Reilly Farrell]

Hi All,

I'm looking for a solution for printing a C Delta 7 chord name (so that 7
prints clearly after the delta symbol).  I started off wth the failed
attempt below and haven't had much success anyway else:

\version "2.18.2"

\score {
<<
\relative c' {
c4 c c c |
}

\chords {
c1:maj7.7
}
>>
\layout{}
\midi{}
}

Any assistance or suggestion is appreciated.  Thank you!
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user