Re: pdf orientation not displayed correctly in 2.19.63

[Juan Cristóbal Cerrillo]

Thanks Andrew,

Will look in lilypond-devel next time.

Setting paper size to
 #(set-paper-size "letterlandscape”)
solves it. 

(caution other users only for 2.19.62!)

jc

> On Jun 13, 2017, at 8:28 PM, Andrew Bernard  wrote:
> 
> Hi Juan,
> 
> There is a thread I started on the devel mailing list recently that
> discusses and explains this.
> 
> http://lists.gnu.org/archive/html/lilypond-devel/2017-05/msg00017.html
> 
> Andrew
> 
> 


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

Re: lyrics hyphens question

[David Nalesnik]

On Jun 13, 2017 9:55 PM, "Kieren MacMillan" 
wrote:

Hi David (et al.),

> It's not suitable as is, but easily remedied.  The grob LyricWord is
> defined in a hackish way so that it can fit in an LY file.

So in C++, it would be non-hackish…?


No, just parceling out the chunks to various .scm files.  Not hard at all.


> it's potentially useful to have a grob which organizes whole Lyric words,
> so lyrics are not simply a collection of isolated syllables.

Agreed.

> I can't say what problems there are with the compression routine.
> I know there have been complaints, but I haven't looked into them.

I’ve just discovered that using lyric-word-compressor makes the last line
of my score unexpectedly (and unpredictably) shorter, as if I had set
ragged-last = ##t. I'll see if I can make an MWE that demonstrates this
issue; in the meantime, I'll have to crank out this score without it…

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lyrics hyphens question

[Kieren MacMillan]

Hi David (et al.),

> It's not suitable as is, but easily remedied.  The grob LyricWord is
> defined in a hackish way so that it can fit in an LY file.

So in C++, it would be non-hackish…?

> it's potentially useful to have a grob which organizes whole Lyric words,
> so lyrics are not simply a collection of isolated syllables.

Agreed.

> I can't say what problems there are with the compression routine.
> I know there have been complaints, but I haven't looked into them.

I’ve just discovered that using lyric-word-compressor makes the last line of my 
score unexpectedly (and unpredictably) shorter, as if I had set ragged-last = 
##t. I'll see if I can make an MWE that demonstrates this issue; in the 
meantime, I'll have to crank out this score without it…

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

RE: pdf orientation not displayed correctly in 2.19.63

[Andrew Bernard]

Hi Juan,

There is a thread I started on the devel mailing list recently that
discusses and explains this.

http://lists.gnu.org/archive/html/lilypond-devel/2017-05/msg00017.html

Andrew



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

pdf orientation not displayed correctly in 2.19.63

[Juan Cristóbal Cerrillo]

Hello,

The pdf is created with the correct orientation, however in 2.19.63 the pdf 
document is not displayed with the correct orientation as in previous versions 
(2.18.2).

jc


\version "2.18.2"
%\version "2.19.62"

\paper {
  #(set-paper-size "letter" 'landscape)
}

<< {c'1 c'1} >>


orientation-problem-2-18.pdf
Description: Adobe PDF document



orientation-problem-2-19.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: accordion notation - counter bass note

[Simon Albrecht]

On 13.06.2017 23:18, David Kastrup wrote:

Simon Albrecht  writes:

On 13.06.2017 18:51, Gianmaria Lari wrote:

What's \etc? Any link to this command?

A great, unfortunately yet undocumented new feature.



You'll also find it listed in
.


Ouch – my apologies!
Best, Simon

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

Re: accordion notation - counter bass note

[Gianmaria Lari]

Thank you David and Simon! (and Brian!)

On 13 June 2017 at 23:18, David Kastrup  wrote:

> Simon Albrecht  writes:
>
> > On 13.06.2017 18:51, Gianmaria Lari wrote:
> >> What's \etc? Any link to this command?
> >
> > A great, unfortunately yet undocumented new feature.
>
>  substitution-function-examples#index-_005cetc>
>
> You'll also find it listed in
> .
>
> --
> David Kastrup
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lyrics hyphens question

[David Nalesnik]

Hi Kieren,

On Tue, Jun 13, 2017 at 3:21 PM, Kieren MacMillan
 wrote:
> Hi David (et al.),
>
> These are questions regarding the "lyric-word-reconstituter" in the thread 
> which includes the post 
> .
>
> I'd love to use it (or something like it) in my engravings going forward.
>
> 1. It doesn't seem to work with 2.19.61 (at least), and convert-ly doesn't 
> seem to help. The error is
>
> warning: type check for `LyricWord' failed; value `#' 
> must be of type `list'
>
> My instinct (and a quick search on -user) led me to believe that changing
>
> (set-object-property! grob-name 'translation-type? list?)
>
> to
>
> (set-object-property! grob-name 'translation-type? ly:grob-properties?)
>
> might fix the problem. The file/example now compiles without error. Did I fix 
> it correctly?

Yes, that's right.

>
> 2. This is a workaround/hack/fix from 2014. At the time, there was some 
> question as to whether Janek might roll this (or similar) into the GSoC Lyric 
> project… but that is, I believe, dead in the water. Is there any hope of 
> getting this into the codebase? I'm happy to take this "stub" (much more than 
> a stub, of course!) and shepherd it through the dev process to the goal line 
> — but I don't want to start down a track that will ultimately lead to 
> frustration or nowhere at all.
>

>

It's not suitable as is, but easily remedied.  The grob LyricWord is
defined in a hackish way so that it can fit in an LY file.

In my opinion, it's potentially useful to have a grob which organizes
whole Lyric words, so lyrics are not simply a collection of isolated
syllables.  (Makes short work of the compression in this instance.)

I can't say what problems there are with the compression routine.  I
know there have been complaints, but I haven't looked into them.  (See
openlilylib, I believe.)

DN

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

Re: accordion notation - counter bass note

[David Kastrup]

Simon Albrecht  writes:

> On 13.06.2017 18:51, Gianmaria Lari wrote:
>> What's \etc? Any link to this command?
>
> A great, unfortunately yet undocumented new feature.



You'll also find it listed in
.

-- 
David Kastrup

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

Re: lyrics hyphens question

[David Kastrup]

Kieren MacMillan  writes:

> Hi David (et al.),
>
> These are questions regarding the "lyric-word-reconstituter" in the
> thread which includes the post
> .
>
> I'd love to use it (or something like it) in my engravings going forward.
>
> 1. It doesn't seem to work with 2.19.61 (at least), and convert-ly
> doesn't seem to help. The error is
>
> warning: type check for `LyricWord' failed; value
> `#' must be of type `list'
>
> My instinct (and a quick search on -user) led me to believe that changing
>
> (set-object-property! grob-name 'translation-type? list?)
>
> to
>
> (set-object-property! grob-name 'translation-type? ly:grob-properties?)
>
> might fix the problem. The file/example now compiles without
> error. Did I fix it correctly?

Sounds like you had the right idea for moving an ugly hack forward in
time.

> 2. This is a workaround/hack/fix from 2014. At the time, there was
> some question as to whether Janek might roll this (or similar) into
> the GSoC Lyric project… but that is, I believe, dead in the water. Is
> there any hope of getting this into the codebase? I'm happy to take
> this "stub" (much more than a stub, of course!) and shepherd it
> through the dev process to the goal line — but I don't want to start
> down a track that will ultimately lead to frustration or nowhere at
> all.

I don't currently have an idea about the overall viability.  David N?

-- 
David Kastrup

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

Re: accordion notation - counter bass note

[Simon Albrecht]

On 13.06.2017 18:51, Gianmaria Lari wrote:

What's \etc? Any link to this command?


A great, unfortunately yet undocumented new feature. Essentially it’s a 
shorthand notation for defining music functions (and markup commands, 
IIRC) without using scheme syntax. Bogus example: instead of writing


lowRelative =
#(define-music-function (mus) (ly:music?)
  #{ \relative c,,, $mus #})

you can write

lowRelative = \relative c,,, \etc

HTH, Simon

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

Re: lyrics hyphens question

[Kieren MacMillan]

Hi David (et al.),

These are questions regarding the "lyric-word-reconstituter" in the thread 
which includes the post 
.

I'd love to use it (or something like it) in my engravings going forward.

1. It doesn't seem to work with 2.19.61 (at least), and convert-ly doesn't seem 
to help. The error is

warning: type check for `LyricWord' failed; value `#' must 
be of type `list'

My instinct (and a quick search on -user) led me to believe that changing

(set-object-property! grob-name 'translation-type? list?)

to

(set-object-property! grob-name 'translation-type? ly:grob-properties?)

might fix the problem. The file/example now compiles without error. Did I fix 
it correctly?

2. This is a workaround/hack/fix from 2014. At the time, there was some 
question as to whether Janek might roll this (or similar) into the GSoC Lyric 
project… but that is, I believe, dead in the water. Is there any hope of 
getting this into the codebase? I'm happy to take this "stub" (much more than a 
stub, of course!) and shepherd it through the dev process to the goal line — 
but I don't want to start down a track that will ultimately lead to frustration 
or nowhere at all.

Thanks,
Kieren.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Ivan,

>> How is it "wrong" for the chord  to [additionally]
>> include the information 'root = a'?
> 
> In some instances the root could be C and the A would be a passing tone.
> In other instances, calling any of those four tones a root would
> have no meaning.  It would depend on the context.

Correct.

> As I read through this thread though, the sense I get is that
> "chord semantics" are to be additional information optional
> added by the user, so that my fear of lilypond doing ad-hoc
> amateur musical analysis will not be happening (I hope not).

I believe the intention — at least initially — is, as you say, to only have 
user-added semantics.

However, once a structure is in place to store and respond to such semantic 
information, there is nothing to stop someone from trying to program Lilypond 
to do "ad-hoc amateur musical analysis". And I hope they *do* (though I may 
never use it myself). Certainly, with additional semantic information, any 
analysis Lilypond attempts can only be better than it would be currently 
(without such semantic information).

> I would hate to see parts of lilypond break because of the addition of 
> musical analysis.

Well, I believe we're all on the same page there: Charles has been engaged 
specifically to *improve* the chord system, not break it.  ;)

> if the idea is for lilypond to do popular/amateur music
> analysis (calling every "a e g a" chord an a minor 7 chord
> regardless of contexts)

Again, with the addition of semantic information, Lilypond will be able to 
ascertain the context of a chord (and vice versa) without any (or at least with 
much less) manual/human input — this, in my opinion, can only be a good thing.

> that task/goal is going to have
> little meaning for most music.

I suppose that depends on you (or another user’s) definition of "most"… I have 
friends who use Lilypond only for their pop music charts and lead sheets — for 
them, a really good, context-sensitive chord generation and analysis tool would 
have meaning on literally ALL of their music.

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[David Kastrup]

Ivan Kuznetsov  writes:

> Kieren MacMillan  wrote:
>>
>> How is it "wrong" for the chord  to [additionally] include the
>> information 'root = a'?
>
> In some instances the root could be C and the A would be a passing tone.
> In other instances, calling any of those four tones a root would
> have no meaning.  It would depend on the context.
>
> As I read through this thread though, the sense I get is that
> "chord semantics" are to be additional information optional
> added by the user, so that my fear of lilypond doing ad-hoc
> amateur musical analysis will not be happening (I hope not).

The ChordNames context is already doing ad-hoc amateur musical
analysis.  When the music has been entered in \chordmode, additional
information is placed into the notes that makes the ad-hoc analysis much
more likely to come up with something approximating the sense of the
original input.

This project basically is about being able to preserve more of the
original sense and thus cause ChordNames and its ilk to do _less_ rather
than more ad-hoc amateur musical analysis.

-- 
David Kastrup

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

Re: Chords in LilyPond

[Ivan Kuznetsov]

Kieren MacMillan  wrote:
>
> How is it "wrong" for the chord  to [additionally] include the
> information 'root = a'?

In some instances the root could be C and the A would be a passing tone.
In other instances, calling any of those four tones a root would
have no meaning.  It would depend on the context.

As I read through this thread though, the sense I get is that
"chord semantics" are to be additional information optional
added by the user, so that my fear of lilypond doing ad-hoc
amateur musical analysis will not be happening (I hope not).

> > Ultimately, giving a chord a name is "analysis" of music, it is not a part 
> > of
> > music notation.
>
> Again, I must disagree: I included chord names in much of the score and piano
> part of my most recent full-length concert drama [...], and both the conductor
> and pianist were deeply appreciative of their presence in the places I chose
> to include them.

Yes, but that was your choice to _include_ chord information in _your_notation_.
You felt that the conveying this information, would help the performers perform
this music.  You did not engage in analysis.  But if a person or a
program were to assign chord/harmony information to your score after you
composed it, they would be engaging in analysis.

> Even if you are correct, why should Lilypond be artificially limited to 
> pre-hoc
> notation only? Why shouldn't we expand Lilypond's power to support and
> encourage musical analysis?

I would hate to see parts of lilypond break because of the addition
 of musical analysis.


> > What you are suggesting is "naive" musical analysis which should not be a
> > part of such a powerful notation program as lilypond.
>
> So having additional power in the form of expanded analysis functions would
> somehow make Lilypond *less* powerful as a notation program? I'm not sure I 
> see
> how that follows…

If the analysis is going to be brute force added by the listener, I
don't see a problem, except for adding a complexity to the program
that does not have to do with notation.

However, if the idea is for lilypond to do popular/amateur music
analysis (calling every "a e g a" chord an a minor 7 chord
regardless of contexts) that task/goal is going to have
little meaning for most music.

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

Re: Chords in LilyPond

[Kieren MacMillan]

Hi Ivan,

Thanks for your input on this important thread.

> This "every chord can/should be given a name" hypothesis
> is a popular/amateur musician idea that does not exist
> in the concert/conservatory musician world.

Not every chord can or should be given a name, of course.

That being said, I must disagree with your implication that there is no room 
for improvement in the way Lilypond handles chords and their naming — and I say 
that as a full-time professional composer, arranger, and performer who makes 
most of my income from the "concert" world.

> Having lilypond chord structures contain this information will
> burden lilypond with a lot of useless and even _wrong_ information.

How is it "wrong" for the chord  to [additionally] include the 
information 'root = a'?

> Ultimately, giving a chord a name is "analysis" of music,
> it is not a part of music notation.

Again, I must disagree: I included chord names in much of the score and piano 
part of my most recent full-length concert drama (commissioned by a leading new 
music ensemble in the United States), and both the conductor and pianist were 
deeply appreciative of their presence in the places I chose to include them.

Even if you are correct, why should Lilypond be artificially limited to pre-hoc 
notation only? Why shouldn't we expand Lilypond's power to support and 
encourage musical analysis?

> What you are suggesting is "naive" musical analysis which
> should not be a part of such a powerful notation program as lilypond.

So having additional power in the form of expanded analysis functions would 
somehow make Lilypond *less* powerful as a notation program? I'm not sure I see 
how that follows…

Best regards,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Chords in LilyPond

[Ivan Kuznetsov]

I realize I am late on this thread, and I have not even read
the other responses, but I will try to explain why adding
"semantics" to a chord data structure is a mistake.

This "every chord can/should be given a name" hypothesis is a
popular/amateur musician idea that does not exist in the
concert/conservatory musician world.  Having lilypond chord
structures contain this information will burden lilypond
with a lot of useless and even _wrong_ information.
Ultimately, giving a chord a name is "analysis" of music,
it is not a part of music notation.


This does not mean that some notation does not include
chord names, of course it does.  In this case though,
the chord name is a part of the notation that specifies
to the read what notes to play.


Getting back to the original point,  how is this semantic
information going to get into the data structure?:

> root note
> quality (major, minor, augmented, diminished)
> extension (7, 9, 11, 13, etc.)
> added notes (6, 9, etc.)
> suspensions (sus4, sus2, etc.)
> alterations (flat-5, sharp-9, etc.)
> omitted notes
> added bass note
> inversions

Is lilypond going to "on the fly" do analysis and supply
this information?  With much music I notate, the above
terms have no meaning.  Even with late 19th century chromatic
music, assigning the above terms to chords can be
a complex process that can be open to debate.

To conclude:

Charles Winston  wrote:
>
> Here is a rough
> list of semantic information I believe should be included in the data
> structure:
>
> root note
> quality (major, minor, augmented, diminished)
> extension (7, 9, 11, 13, etc.)
> added notes (6, 9, etc.)
> suspensions (sus4, sus2, etc.)
> alterations (flat-5, sharp-9, etc.)
> omitted notes
> added bass note
> inversions

You belief is incorrect on this.  What you are suggesting is
"naive" musical analysis which should not be a part of
such a powerful notation program as lilypond.

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

Re: Adjusting OttavaBracket parameters (was "Re: can't seem to apply tweaks on tweaks")

[Peter Crighton]

2016-01-02 23:37 GMT+01:00 Thomas Morley :
>
> Please look at the attached png and test the attached code.
> Tell me what isn't sufficient.
>
> Cheers,
>   Harm
>

Hi Harm,

I just found your solution to the problem I had been having for a long time
– it helped tremendously, thank you!

Only problem I am having now with that:
While removing the parentheses and changing a few values to place the
number directly above the note, I noticed the pacement is different if
there is a repeat sign at the beginning of a line with a broken octava
bracket. (See attachments.)

Is there either a way to automatically alter the placement if there is a
repeat sign present (some formatBrokenRepeatOttavaText procedure that
triggers only if there is a repeat sign), or to manually override the
placement of the broken bracket? (I had no luck with \alterBroken
shorten-pair.)

Thanks,
Peter

--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de
\version "2.19.59"

%%%  SNIPPET BEGINS

#(define-markup-command (single-pad layout props axis-dir amount arg)
  (pair? number? markup?)
  #:category align
"
@cindex padding text horizontally

Add padding @var{amount} to @var{arg} in the direction of 
@code{(car axis-dir)}, but only at the edge specified by @code{(cdr axis-dir)}.

@lilypond[verbatim,quote]
\\markup {
  \\box {
 \\single-pad #'(1 . -1) #2 XY
 \\single-pad #(cons Y  UP) #2 XY
 \\single-pad #'(0 . -1) #2 XY
 \\single-pad #`(,X . ,RIGHT) #2 XY
 }
}
@end lilypond"
  (let* ((m (interpret-markup layout props arg))
 (x (ly:stencil-extent m X))
 (y (ly:stencil-extent m Y))
 (new-x
   (cond ((and (= (car axis-dir) X)
   (= (cdr axis-dir) RIGHT))
  (cons (car x) (+ amount (cdr x
 ((and (= (car axis-dir) X)
   (= (cdr axis-dir) LEFT))
  (cons (- (car x) amount) (cdr x)))
 (else x)))
 (new-y
   (cond ((and (= (car axis-dir) Y)
   (= (cdr axis-dir) UP))
  (cons (car y) (+ amount (cdr y
 ((and (= (car axis-dir) Y)
   (= (cdr axis-dir) DOWN))
  (cons (- (car y) amount) (cdr y)))
 (else y
(ly:make-stencil
  (ly:stencil-expr m)
  new-x
  new-y)))

%% markup-commands adding space to one predifined edge
#(define-markup-command (pad-left layout props amount arg)
  (number? markup?)
  #:category align
  (interpret-markup layout props
(make-single-pad-markup `(,X . ,LEFT) amount arg)))

#(define-markup-command (pad-right layout props amount arg)
  (number? markup?)
  #:category align
  (interpret-markup layout props
(make-single-pad-markup `(,X . ,RIGHT) amount arg)))

#(define-markup-command (pad-up layout props amount arg)
  (number? markup?)
  #:category align
  (interpret-markup layout props
(make-single-pad-markup `(,Y . ,UP) amount arg)))

#(define-markup-command (pad-down layout props amount arg)
  (number? markup?)
  #:category align
  (interpret-markup layout props
(make-single-pad-markup `(,Y . ,DOWN) amount arg)))

%% Examples for pad-whatever markup-commands
% \markup \column \box {
%   \pad-left #2 "pad-left"
%   \pad-right #2 "pad-right"
%   \pad-up #2 "pad-up"
%   \pad-down #2 "pad-down"
% }

%% markup-commands formatting a string like "8va"
%% depending on the direction it will appear bottom or top aligned
%% a little adjustable, space is added before the last two characters
#(define-markup-command (format-ottava layout props arg)(markup?)
#:properties ((arg-padding 0.25)
  (direction 1))
  (ly:stencil-aligned-to
(interpret-markup layout props
  (if (and (string? arg) (>= (string-length arg) 3))
  (let* ((nmbr (list->string (drop-right (string->list arg) 2)))
 (up-down (list->string (take-right (string->list arg) 2)))
 (dir (if (= 1 direction) UP DOWN)))
 #{
   \markup
 \override #`(word-space . ,arg-padding)
 \line { \general-align #Y #dir { $nmbr $up-down } }
 #}
 )
   arg))
 Y
 DOWN))

%% like format-ottava, but adding "(" and ")" around the argument
%% those parentheses are per default 'roman, but overridable as well as th
%% padding used after "(" and before ")"
#(define-markup-command (format-parenthesized-ottava layout props arg)(markup?)
#:properties ((par-padding '(0 . 0))
  (par-font-shape 'roman)
  (arg-padding 0.25))
  (interpret-markup layout props
#{
  \markup
\concat {
  \pad-right #(car par-padding)
  \override #`(font-shape . ,par-font-shape) "("
  \override #`(word-space . ,arg-padding) \format-ottava  $arg
  \pad-left #(cdr par-padding)
  \override #`(font-shape . ,par-font-shape) ")"
}
#}

Re: accordion notation - counter bass note

[Gianmaria Lari]

It works perfectly thank you David.

What's \etc? Any link to this command?

Thank you!!!
g.

On 13 June 2017 at 18:43, David Kastrup  wrote:

> Gianmaria Lari  writes:
>
> > Perfect!!! Thank you David!
> >
> > Now, because they are a bit verbose, I would like to create a function
> with
> > parameter.
> > This is without parameter:
> >
> > \version "2.19.60"
> > newFinger = \markup \underline \finger 3
> > {\clef bass e,_\newFinger }
> >
> >
> > How can I write somethingl ike:
> >
> > \newFinger #3
> >
> >
> > ?
>
> Well, version 2.19.60 has \etc but it does not work for mixtures of
> incomplete music functions and markup commands.  So you'd need to do it
> the hard way:
>
> newFinger =
> #(define-event-function (arg) (number-or-markup?)
>   #{ -\markup \underline \finger
>  #(if (number? arg) (number->string arg) arg)
>   #})
>
>
> --
> David Kastrup
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: accordion notation - counter bass note

[David Kastrup]

Gianmaria Lari  writes:

> Perfect!!! Thank you David!
>
> Now, because they are a bit verbose, I would like to create a function with
> parameter.
> This is without parameter:
>
> \version "2.19.60"
> newFinger = \markup \underline \finger 3
> {\clef bass e,_\newFinger }
>
>
> How can I write somethingl ike:
>
> \newFinger #3
>
>
> ?

Well, version 2.19.60 has \etc but it does not work for mixtures of
incomplete music functions and markup commands.  So you'd need to do it
the hard way:

newFinger =
#(define-event-function (arg) (number-or-markup?)
  #{ -\markup \underline \finger
 #(if (number? arg) (number->string arg) arg)
  #})


-- 
David Kastrup

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

Re: accordion notation - counter bass note

[Gianmaria Lari]

Perfect!!! Thank you David!

Now, because they are a bit verbose, I would like to create a function with
parameter.
This is without parameter:

\version "2.19.60"
newFinger = \markup \underline \finger 3
{\clef bass e,_\newFinger }


How can I write somethingl ike:

\newFinger #3


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

Re: encapsulating woodwind diagrams

[caagr98]

Try removing the brackets ({ ... }) around the \markup.

On 06/13/2017 04:46 PM, Jaime Oliver La Rosa wrote:

Hi all,

I am using the following code to place diagrams in a score:

c^\markup
 \center-column {
\override #'(size . .75)
\override #'(thickness . 0.05){
\woodwind-diagram
   #'flute-b-extension
   #'((cc . (one1h three))
  (lh . (b  gis))
  (rh . (d dis ees cis c b)))
 }
   }

however, since I have several of these, I'd like to store them as 
separate encapsulated commands that I'd like to call such as


position1 = {\markup
 \center-column {
\override #'(size . .75)
\override #'(thickness . 0.05){
\woodwind-diagram
   #'flute-b-extension
   #'((cc . (one1h three))
  (lh . (b  gis))
  (rh . (d dis ees cis c b)))
 }
   }

}

And then call it in the score with

c^\position1

but I get all sorts of errors. Not sure how to proceed. Can anyone point 
me to some information?


best,

J


___
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: encapsulating woodwind diagrams

[Jaime Oliver La Rosa]

that works! thanks...
J

On 06/13/2017 09:51 AM, caag...@gmail.com wrote:

Try removing the brackets ({ ... }) around the \markup.

On 06/13/2017 04:46 PM, Jaime Oliver La Rosa wrote:

Hi all,

I am using the following code to place diagrams in a score:

c^\markup
 \center-column {
\override #'(size . .75)
\override #'(thickness . 0.05){
\woodwind-diagram
   #'flute-b-extension
   #'((cc . (one1h three))
  (lh . (b  gis))
  (rh . (d dis ees cis c b)))
 }
   }

however, since I have several of these, I'd like to store them as 
separate encapsulated commands that I'd like to call such as


position1 = {\markup
 \center-column {
\override #'(size . .75)
\override #'(thickness . 0.05){
\woodwind-diagram
   #'flute-b-extension
   #'((cc . (one1h three))
  (lh . (b  gis))
  (rh . (d dis ees cis c b)))
 }
   }

}

And then call it in the score with

c^\position1

but I get all sorts of errors. Not sure how to proceed. Can anyone 
point me to some information?


best,

J


___
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



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

Hal Leonard fretboard style

[Kieren MacMillan]

Hi all,

Before I reinvent this particular wheel…

Has anyone worked up a stylesheet which exactly (or at least closely) mimics 
the style seen in most Hal Leonard (or Williamson Music) piano/vocal/guitar 
publications?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

encapsulating woodwind diagrams

[Jaime Oliver La Rosa]

Hi all,

I am using the following code to place diagrams in a score:

c^\markup
\center-column {
   \override #'(size . .75)
   \override #'(thickness . 0.05){
   \woodwind-diagram
  #'flute-b-extension
  #'((cc . (one1h three))
 (lh . (b  gis))
 (rh . (d dis ees cis c b)))
}
  }

however, since I have several of these, I'd like to store them as 
separate encapsulated commands that I'd like to call such as


position1 = {\markup
\center-column {
   \override #'(size . .75)
   \override #'(thickness . 0.05){
   \woodwind-diagram
  #'flute-b-extension
  #'((cc . (one1h three))
 (lh . (b  gis))
 (rh . (d dis ees cis c b)))
}
  }

}

And then call it in the score with

c^\position1

but I get all sorts of errors. Not sure how to proceed. Can anyone point 
me to some information?


best,

J


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

Re: accordion notation - counter bass note

[David Kastrup]

Gianmaria Lari  writes:

> On the accordion to indicate that a note is to be played in the counter
> bass we put a small dash *under* the number of the finger (see attached
> file capture.png). How can I do it?
>
> * * *
>
> Another convention for counter bass (that my teacher uses) is to put an x
> in front of the number of the finger. I tried with this code
>
> \version "2.19.60"
> {\clef bass c,_3 d,_"3x" }
>
> but as you can see in the attached file capture2.png the result is not ok
> because the font size is different. I imagine I can change the font size
> but I wonder if I'm doing the right things in this way.

Here are a few versions:

\version "2.19.60"
{\clef bass c,_3 d,_\finger "3x" e,_\markup \underline \finger 3 }

-- 
David Kastrup

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

accordion notation - counter bass note

[Gianmaria Lari]

On the accordion to indicate that a note is to be played in the counter
bass we put a small dash *under* the number of the finger (see attached
file capture.png). How can I do it?

* * *

Another convention for counter bass (that my teacher uses) is to put an x
in front of the number of the finger. I tried with this code

\version "2.19.60"
{\clef bass c,_3 d,_"3x" }

but as you can see in the attached file capture2.png the result is not ok
because the font size is different. I imagine I can change the font size
but I wonder if I'm doing the right things in this way.

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

Re: FYI: OpenScore

[Johan Vromans]

Please note that I am just relaying this message. I'm not affiliated with
this project in any way.

On Tue, 13 Jun 2017 08:12:41 +0200, Johan Vromans 
wrote:

> Quote: "OpenScore wants to digitise and liberate all public domain sheet
> music, including the great classics of Mozart, Beethoven and Bach. Our
> community aims to transfer history’s most influential pieces from paper
> into interactive scores which you can listen to, edit and share. Together,
> we can make sheet music accessible to everyone. For free, for any purpose,
> for evermore."
> 
> https://www.kickstarter.com/projects/openscore/openscore-join-the-sheet-music-revolution

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

Re: Changing vertical spacing on lyrics

[spadey88]

Thanks Kieran - yes that was what I was after

Many thanks!


> On 13 Jun 2017, at 5:57 AM, Kieren MacMillan  wrote:
> 
> Hi Adrian,
> 
>> That helps in moving the single line of lyrics (which will be helpful 
>> elsewhere - thanks!), however what I want is to increase the spacing between 
>> stanzas, i.e.
> 
> The same page/concepts applies, e.g.
> 
>  \override Lyrics.VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = #20
> 
> Hope that helps,
> Kieren.
> 
> 
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 

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

Re: FYI: OpenScore

[Simon Albrecht]

On 13.06.2017 08:12, Johan Vromans wrote:

Quote: "OpenScore wants to digitise and liberate all public domain sheet
music, including the great classics of Mozart, Beethoven and Bach. Our
community aims to transfer history’s most influential pieces from paper
into interactive scores which you can listen to, edit and share. Together,
we can make sheet music accessible to everyone. For free, for any purpose,
for evermore."

https://www.kickstarter.com/projects/openscore/openscore-join-the-sheet-music-revolution


This appears unfortunately to be far too naïve with regard to questions 
like code quality, textual critique, and data representation…


Best, Simon

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