printing the current moment in a context

[Kieren MacMillan]

Hi all,

Is there a function (2.19.64) that will output the current context moment 
(e.g., measure number and beat) as markup?
In my polymetric scores, I need to target moments (using the edition-engraver), 
and it currently involves a bit too much trial-and-error…

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

Slide in guitar music (Sorry -- wrong keys :-/)

[Guy Stalnaker]

All,

I'm trying to notate a slide such that what I see is how I play it and I 
can't figure out how to do it. When I play it, I pluck the e' then slide 
to the fs' with a fair bit of rubato, then continue with the measure. 
I'd like this "slow slide" to be visible as a long slide symbol 
(\glissando?).


Right now I have this:


  e'8 g' b' e'' e' g' b' e'' |
  \grace{ e'8 \glissando } fs'8 _\markup { \italic { Rubato } } g' b' 
e'' fs' g' b' e'' |



What I want is for the slide symbol to be much longer, about the 
distance from one eighth note to another so that it is quite visible and 
obvious that the slide is audible and deliberate and not, really, a 
typical \grace (which I'm using here not knowing another way to do this).


What I've tried:

1. I know how to create space between the grace note e and the f-sharp,
   but the technique uses either an s4 or r4 and that breaks the
   \glissando.  I added "\once \override NoteColumn.glissando-skip =
   ##t" but that was ineffective in skipping the s4.
2. I did "\grace{ e'8-\markup \hspace #x \glissando } but that only
   killed the \glissando and no value for x seemed to do anything.
3. I've tried using "\once \override Glissando#'gap = #x.x" but that
   appears to change nothing.

Thanks,

Guy

--
“Happiness is the meaning and the purpose of life, the whole aim and end of 
human existence.”
― Aristotle

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

Slidein guitar music

[Guy Stalnaker]

All,

I'm trying to notate a slide such that what I see is how I play it and I 
can't figure out how to do it. Right now I have this:



  e'8 g' b' e'' e' g' b' e'' |
  \grace{ e'8 \glissando } fs'8 _\markup { \italic { Rubato } } g' b' 
e'' fs' g' b' e'' |



What I want is for the slide symbol to be much longer, about the 
distance from one eighth note to another so that it is quite visible ad 
obvious that the slide is audible and deliberate and not, really, a 
typical \grace (which I'm using here not knowing another way to do this).


What I've tried:

1. I know how to create space between the grace note and the f-sharp,
   but the technique uses either an s4 or r4 and that breaks the
   \glissando.  I added \once \override NoteColumn.glissando-skip = ##t

  \grace{ e'8\glissando s4 } fs'8 _\markup { \italic { Rubato } } g' b' 
e'' fs' g' b'


-\markup \hspace #6
I've tried using "\once \override Glissando#'gap = #x.x" but that 
appears to change nothing.


--
“Happiness is the meaning and the purpose of life, the whole aim and end of 
human existence.”
― Aristotle

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

improving Janek's \dynamic function (for combo dynamics)

[Kieren MacMillan]

Hello all,

The snippet below includes Janek's \dynamic function, which has a rather lovely 
interface.
Unfortunately, it doesn't align leading dynamics as expected (i.e., centered on 
the notehead).

What's the easiest way to fix the function so that it does?

Thanks,
Kieren.

%%%  SNIPPET BEGINS
\version "2.19.64"

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

dynamic =
#(define-event-function (text) (markup?)
   (if (string? text)
   (let* ((underscores-replaced
   (string-map
(lambda (x) (if (eq? x #\_) #\space x))
text))
  (split-text (string-split underscores-replaced #\space))
  (formatted (map
  (lambda (word)
(if (string-match "^[mrzfps]*$" word)
(markup #:dynamic word #:hspace 0.25)
(markup #:normal-text #:fontsize 0.625 #:italic 
word)))
  split-text)))
 #{
   -\tweak X-offset #0
   #(make-dynamic-script (make-line-markup formatted))
 #})

   ;; user provided a full-blown markup, so we don't mess with it:
   #{
 #(make-dynamic-script (markup #:normal-text #:fontsize 0.625 text))
   #}))

<<
  \new Staff { c''\dynamic "f testing" }
  \new Staff { c''\f }
>>
%%%  SNIPPET ENDS


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: functions to ignore grob during spacing calculations

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> It helps to actually test the programs: there are warnings about bad
>> values for horizontal-skylines and vertical-skylines because #f isn't
>> the same as ##f .
>
> When I run it, this is my log output:
>
> Starting lilypond 2.19.64 [tempTest3.ly]...
> Processing `/Users/kmac/Documents/01_music/Lilypond/tempTest3.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to
> `/var/folders/l3/8qtf8wts5kj93q4w13f4qdfcgn/T//lilypond-K8HrEC'...
> Converting to `tempTest3.pdf'...
> Deleting 
> `/var/folders/l3/8qtf8wts5kj93q4w13f4qdfcgn/T//lilypond-K8HrEC'...
> Success: compilation successfully completed
> Completed successfully in 0.7".
>
> Where would I locate the warnings you speak of?

You are correct: they aren't there.  They just kick in after my change.
I suppose that's a bug.  I'll see whether I can reasonably fix that.

>> You are probably not going to like it.
>
> Why wouldn't I like that solution?!?
> It does exactly what I want!!

Ah, but your original "naïve" proposal would have worked just fine
without

commit 269d0c6d104c40f75e225f93459fd827f4065905
Author: David Kastrup 
Date:   Sat Jul 18 17:30:26 2015 +0200

Issue 4533: Stop the generic \tweak command from working as override

The problem with letting the generic \tweak command work as an override
is that the tweaking of lyric events becomes awkward since plain lyrics
are hard to distinguish from property names.

This renames the combined tweak/override command into \propertyTweak and
changes all callers requiring the combined functionality to call
\propertyTweak (or its Scheme equivalent) rather than \tweak.

The original issue allowing \tweak to act as an override was issue 2929.
The issue allowing tweaks to function in \lyricmode is issue 2543.

present as of version 2.19.25.

> A small token of my appreciation has been sent separately.

Thank you.  To make this less awkward: the functionality you were glad
to be told about after I had hidden it away was created by me to start
with.  But then so was the music function argument parsing flexibility
that made it inadvisable to keep it under the name of \tweak ...

LilyPond's syntax' pliability is a mixed blessing where one has to find
the right compromises in order to avoid surprises.

-- 
David Kastrup

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

Re: XML import (WAS: A premiere by Daahoud Salim, typeset with LilyPond)

[Francisco Vila]

On 15/08/17 20:55, Francisco Vila wrote:
> All in all, one of the most usefulness of LilyPond is completely lost,
> which is to make beautifully typeset music automatically from a terse,
> meaningful symbolic language.
>
It must be said, however, that a blind Spanish user today told me that
something is far better than nothing, so the feature maybe is still
useful for some people.
-- 

Francisco Vila. Badajoz (Spain)
paconet.org , csmbadajoz.com


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

Re: XML import (WAS: A premiere by Daahoud Salim, typeset with LilyPond)

[Francisco Vila]

On 15/08/17 20:25, Jacques Menu Muzhic wrote:
> Hello Francisco,
>
>> - The converted code has \stemUp and \stemDown in every single note,
>> which had to be searched and replaced. Also all articulations are
>> forced up or down. 
>
> Don’t know why musicxml2ly recently enforced such behavior, without
> any option to prevent it.
> The same holds for \pointAndClickOff.
>>
>> - Bar number checks have to be searched as well to delete them. What
>> if you want to insert a measure? it's a nightmare. Even worse, bar
>> number checks are not fixed strings, so you have to compose regular
>> expressions to match them.
>>
> I’ve written a bash/awk script to offset measures numbers, leading to:

That is interesting.
>>
>> - Dynamics are not attached to the note it is meant to, if the author
>> moved them with the mouse.
>>
> Do you mean they’re attached to a rest? I get that frequently after
> scanning with PhotoScore Ultimate and exporting to MusicXML. Or have
> you experienced a thoroughly different phenomenon?

Usually a rest, if rests precede the dynamics, but also any note
preceding the dynamics, if this is in the middle of a measure full of
noteheads. It looks as if Finale users first put the dynamic anywhere in
the measure (thus being hardwired to the beginning), then reposition it
to the corresponding note. It is visually correct (for them), but
internally it loses the meaning.

>> - Just look at this converted block:
>>
>> #(set-global-staff-size 20.6625714286)
>>
>> \paper {
>> paper-width = 21.59\cm
>> paper-height = 27.93\cm
>> top-margin = 1.27\cm
>> bottom-margin = 1.27\cm
>> left-margin = 2.53\cm
>> right-margin = 1.27\cm
>> between-system-space = 2.19\cm
>> page-top-space = 1.27\cm
>> indent = 1.66076923077\cm
>> short-indent = 1.10717948718\cm
>>   }
>>
>> No comments. Except that you have to pay attention to it even if you
>> want to discard it completely, because it's between all else,
>> otherwise useful, code. The work of picking and editing the useful
>> parts is time-consuming.
>>
> The numerous decimal digits could easily be limited to 2 without a
> great loss IMHO.
Yes, eleven decimals look like a bit too many for me.

> The various settings in \paper seem to come from the MusicXML data
> itself, and having them there makes it easy for the user to adapt them
> to what he needs.
All in all, one of the most usefulness of LilyPond is completely lost,
which is to make beautifully typeset music automatically from a terse,
meaningful symbolic language.

-- 
Francisco Vila. Badajoz (Spain)
paconet.org , csmbadajoz.com

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

Re: XML import (WAS: A premiere by Daahoud Salim, typeset with LilyPond)

[Jacques Menu Muzhic]

Hello Francisco,

> - The converted code has \stemUp and \stemDown in every single note, which 
> had to be searched and replaced. Also all articulations are forced up or 
> down. 

Don’t know why musicxml2ly recently enforced such behavior, without any option 
to prevent it.
The same holds for \pointAndClickOff.
> - Bar number checks have to be searched as well to delete them. What if you 
> want to insert a measure? it's a nightmare. Even worse, bar number checks are 
> not fixed strings, so you have to compose regular expressions to match them.
> 
I’ve written a bash/awk script to offset measures numbers, leading to:

menu@macbookprojm > SubstractNFromLPEndOfLineBarNumbers -4
d2  d8 [  d8  e8
fis8 ] | % 2
g4.  fis8  g4.  a8 | % 3
bes1 | % 4
d,4.  c8  d4.  e8 | % 5
f2. r16  f16 [  es16  d16 ]
\myBreak | % 6
c4.  bes8  c4.  d8 | % 7
es1 | % 8
g,4.  fis8  g4.  a8 | % 9
bes4.  a8  bes4.  c8 |
\barNumberCheck #10



d2  d8 [  d8  e8
fis8 ] | % 6
g4.  fis8  g4.  a8 | % 7
bes1 | % 8
d,4.  c8  d4.  e8 | % 9
f2. r16  f16 [  es16  d16 ]
\myBreak | % 10
c4.  bes8  c4.  d8 | % 11
es1 | % 12
g,4.  fis8  g4.  a8 | % 13
bes4.  a8  bes4.  c8 |
\barNumberCheck # 14



menu@macbookprojm > 

Copy/paste the LP snippet, type some carriage returns followed by Ctrl-d, and 
copy the result back into your LP code.
I guess Frescobaldi could provide such a tool to act upon the current text 
selection.
> - Dynamics are not attached to the note it is meant to, if the author moved 
> them with the mouse.
> 
Do you mean they’re attached to a rest? I get that frequently after scanning 
with PhotoScore Ultimate and exporting to MusicXML. Or have you experienced a 
thoroughly different phenomenon?
> - Just look at this converted block:
> 
> #(set-global-staff-size 20.6625714286)
> 
> \paper {
> paper-width = 21.59\cm
> paper-height = 27.93\cm
> top-margin = 1.27\cm
> bottom-margin = 1.27\cm
> left-margin = 2.53\cm
> right-margin = 1.27\cm
> between-system-space = 2.19\cm
> page-top-space = 1.27\cm
> indent = 1.66076923077\cm
> short-indent = 1.10717948718\cm
>   }
> No comments. Except that you have to pay attention to it even if you want to 
> discard it completely, because it's between all else, otherwise useful, code. 
> The work of picking and editing the useful parts is time-consuming.
> 
The numerous decimal digits could easily be limited to 2 without a great loss 
IMHO. 
The various settings in \paper seem to come from the MusicXML data itself, and 
having them there makes it easy for the user to adapt them to what he needs.

JM


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

Re: Can \lyricmode be applied to specific measures and exempted from others?

[Kieren MacMillan]

Hi Reilly,

> I'm curious to know if there is a way to apply \lyricmode to a certain number 
> of measures and then terminate it.  My chief concern is that using lyricmode 
> creates excess space between the system and dynamic markings for measures 
> where no lyrics are present.

Can you give a [compilable] example of this happening?
I use dynamics and lyrics all the time, and don't remember seeing what you're 
describing…

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

Can \lyricmode be applied to specific measures and exempted from others?

[Reilly Farrell]

Hi All,

I'm curious to know if there is a way to apply \lyricmode to a certain
number of measures and then terminate it.  My chief concern is that using
lyricmode creates excess space between the system and dynamic markings for
measures where no lyrics are present.  Ideally, I would like to be able to
turn \lyricmode off for measures where no lyrics are needed to avoid adding
this excess space.  Any suggestions?
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: functions to ignore grob during spacing calculations

[Kieren MacMillan]

Hi David,

> It helps to actually test the programs: there are warnings about bad
> values for horizontal-skylines and vertical-skylines because #f isn't
> the same as ##f .

When I run it, this is my log output:

Starting lilypond 2.19.64 [tempTest3.ly]...
Processing `/Users/kmac/Documents/01_music/Lilypond/tempTest3.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to 
`/var/folders/l3/8qtf8wts5kj93q4w13f4qdfcgn/T//lilypond-K8HrEC'...
Converting to `tempTest3.pdf'...
Deleting `/var/folders/l3/8qtf8wts5kj93q4w13f4qdfcgn/T//lilypond-K8HrEC'...
Success: compilation successfully completed
Completed successfully in 0.7".

Where would I locate the warnings you speak of?

> You are probably not going to like it.

Why wouldn't I like that solution?!?
It does exactly what I want!!

A small token of my appreciation has been sent separately.

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: functions to ignore grob during spacing calculations

[David Kastrup]

Kieren MacMillan  writes:

> Hello all,
>
> In the following snippet, there are three macros which "trick" the
> spacing engine into ignoring a grob during horizontal and/or vertical
> spacing calculations:
>
>   SNIPPET BEGINS
> \version "2.19.64"
>
> ignoreH =
> \tweak horizontal-skylines #f
> \tweak extra-spacing-width #empty-interval
> \etc
>
> ignoreV =
> \tweak vertical-skylines #f
> \tweak extra-spacing-height #empty-interval
> \etc
>
> ignore = \ignoreH \ignoreV \etc
>
> { c''4\f c''-\f c''2\f }
>
> { c''4\f c''-\ignore -\f c''2\f }
>
> %{ \ignore DynamicText c''4\f c''-\f c''2\f } % uncomment
> this to see the problem
>   SNIPPET ENDS

It helps to actually test the programs: there are warnings about bad
values for horizontal-skylines and vertical-skylines because #f isn't
the same as ##f .

> I'd like to have a non-tweak version of this behaviour, which can be
> turned on and off (or used \once) in a given context. But I'm unsure
> of the best way of implementing it. (Uncommenting the last
> [pseudo-code] line of the snippet shows the problem with the naive
> approach.) I tried to create a music function, but couldn't figure out
> how to abstract the grob type (which is obviously essential, if this
> function is to be universally applicable).
>
> Any pointers or hints would be appreciated.

You are probably not going to like it.

  SNIPPET BEGINS
\version "2.19.64"

ignoreH =
\propertyTweak horizontal-skylines ##f
\propertyTweak extra-spacing-width #empty-interval
\etc

ignoreV =
\propertyTweak vertical-skylines ##f
\propertyTweak extra-spacing-height #empty-interval
\etc

ignore = \ignoreH \ignoreV \etc

{ c''4\f c''-\f c''2\f }

{ c''4\f c''-\ignore -\f c''2\f }

{ \ignore DynamicText c''4\f c''-\f c''2\f }
  SNIPPET ENDS

\propertyTweak is basically the same function as \tweak except that it
also works on grob specs.  The difference is particularly important in
\lyricsmode where grob specs are often indistinguishable from normal
text.  So \tweak does not admit them.

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

functions to ignore grob during spacing calculations

[Kieren MacMillan]

Hello all,

In the following snippet, there are three macros which "trick" the spacing 
engine into ignoring a grob during horizontal and/or vertical spacing 
calculations:

  SNIPPET BEGINS
\version "2.19.64"

ignoreH =
\tweak horizontal-skylines #f
\tweak extra-spacing-width #empty-interval
\etc

ignoreV =
\tweak vertical-skylines #f
\tweak extra-spacing-height #empty-interval
\etc

ignore = \ignoreH \ignoreV \etc

{ c''4\f c''-\f c''2\f }

{ c''4\f c''-\ignore -\f c''2\f }

%{ \ignore DynamicText c''4\f c''-\f c''2\f }  % uncomment this to 
see the problem
  SNIPPET ENDS

I'd like to have a non-tweak version of this behaviour, which can be turned on 
and off (or used \once) in a given context. But I'm unsure of the best way of 
implementing it. (Uncommenting the last [pseudo-code] line of the snippet shows 
the problem with the naive approach.) I tried to create a music function, but 
couldn't figure out how to abstract the grob type (which is obviously 
essential, if this function is to be universally applicable).

Any pointers or hints would be appreciated.

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: Git version control

[Francisco Vila]

On 10/08/17 23:11, Graham King wrote:
> \header {
>
>   tagline = \markup{  \center-column{
> \concat {"Music engraving by Lilypond "
> $(lilypond-version) "-www.lilypond.org
> "
> }
> \line { "Version control for this edition: gitrev "
> \gitrev " " \modts }
> }}
> }
>
>
> Now you can tell whether that paper copy is up-to-date.  Of course,
> you don't want this code cluttering up every lilypond score, so best
> put it in a separate file and \include it.
>

Nice. I have a simpler solution for those who launch a bash script for
rendering en masse. The script has this line:

echo "hash="\"Git version `git log --pretty="%h %s" | head -1`"\"" >
gitversion-header.ily

Then the same script calls lilypond on the files to compile as usual.

The lilypond file or your stylesheet \includes the file
gitversion-header.ily and prints the version with a \markup{\hash} or
similar.

-- 

Francisco Vila. Badajoz (Spain)
paconet.org , csmbadajoz.com

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

Re: XML import (WAS: A premiere by Daahoud Salim, typeset with LilyPond)

[Francisco Vila]

On 15/08/17 15:01, Richard Shann wrote:
> I agree with this advice, which is why Denemo's MusicXML is still so
> primitive. It has a few hiccups but it ignores most of what is not the
> the music per se but is instead decisions about how the music should
> look. I think LilyPond would be well served by a converter that takes
> all the pitches/durations and things like time signatures needed to make
> sense of them and ignores everything else. 

Yes, I'd like to hack the musicxml2ly, if I only could, to filter the
conversion, as we can't do anything on the export from to XML process
from the other side.

As an alternative, smart regular expressions could be of help to filter
out certain elements from the ly code after the conversion. I'll try to
post those I used.

-- 
Francisco Vila. Badajoz (Spain)
paconet.org , csmbadajoz.com


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

Re: tweaks don't apply to post-function grob

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> As long as you refuse to answer the question I have repeated
>> at least 3 times by now, there is no implementable specification.
>> 
>> You have again _completely_ failed to specify what you actually expect
>> self-alignment-X to do over its range of values in the context of \dynText .
>
> I expect (have *always* expected) self-alignment-X to do exactly what
> it currently does over its range of values in the context of \dynText:
> LEFT should left-align the grob, CENTER should center-align the grob,
> and RIGHT should right-align the grob.

To quote from the original mail starting this thread:

Hi all,

In the snippet below, I want to tweak a dynamic grob created using
Shevek's dynText function
(cf. http://lists.gnu.org/archive/html/lilypond-user/2017-07/msg00043.html).
But unfortunately, tweaks don't seem to affect it.

How can I change the function such that I can still apply tweaks
(X-offset, self-alignment-X, etc.) to the combined dynamic-text grob
"at runtime"?

%%%  SNIPPET BEGINS
\version "2.19.64"

[...]

{ c''1-\tweak self-alignment-X #RIGHT \dynText "mp" "test" }
%%%  SNIPPET ENDS


> If that doesn't answer your question, I too must give up.

That makes two of us.

-- 
David Kastrup

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

Re: tweaks don't apply to post-function grob

[Kieren MacMillan]

Hi David,

> As long as you refuse to answer the question I have repeated
> at least 3 times by now, there is no implementable specification.
> 
> You have again _completely_ failed to specify what you actually expect
> self-alignment-X to do over its range of values in the context of \dynText .

I expect (have *always* expected) self-alignment-X to do exactly what it 
currently does over its range of values in the context of \dynText: LEFT should 
left-align the grob, CENTER should center-align the grob, and RIGHT should 
right-align the grob.

If that doesn't answer your question, I too must give up.

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: tweaks don't apply to post-function grob

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> you still fail to specify _what_ you actually want.
>
> Sigh. I have specified exactly what I want. Several times. I'll do it
> again, in yet another wording, hoping you find this more clear:

I give up.  As long as you refuse to answer the question I have repeated
at least 3 times by now, there is no implementable specification.

You have again _completely_ failed to specify what you actually expect
self-alignment-X to do over its range of values in the context of
\dynText .

> (Note that I have intentionally left out the post-hoc "tweak using the
> edition-engraver" portion of my process, since that part seems to be
> confusing you.)

Rather I suspect that it excites you to a degree where you again and
again and again forget what I am asking.  It's irrelevant to the issue
at hand.

>> Without such a specification, there will be no code doing what you
>> want because you just leave far too much in the open.
>
> It seems pretty cut and dried to me. What is unclear about the 2-point
> specification I gave, above?

It doesn't specify what the different possible values of
self-alignment-X are supposed to do, and your request was that
self-alignment-X was to be heeded.

-- 
David Kastrup

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

Re: tweaks don't apply to post-function grob

[Kieren MacMillan]

Hi David,

> you still fail to specify _what_ you actually want.

Sigh. I have specified exactly what I want. Several times. I'll do it again, in 
yet another wording, hoping you find this more clear:

1. I want a function which combines text and dynamics (as both \dynamic and 
\dynText do).

2. I want that function to set the [default] alignment such that combo dynamics 
with leading *dynamic* text are aligned as if there was no appended text (which 
\dynText does well, but \dynamic does not), and combo dynamics which have 
leading *normal" text are left-aligned with the left-edge of the notehead 
(which both functions do well).

Essentially, I want the dynamic alignment as given by \dynText with the 
interface given by \dynamic.

(Note that I have intentionally left out the post-hoc "tweak using the 
edition-engraver" portion of my process, since that part seems to be confusing 
you.)

> Without such a specification, there will be no code doing what you want 
> because you just leave far too much in the open.

It seems pretty cut and dried to me. What is unclear about the 2-point 
specification I gave, above?

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: tweaks don't apply to post-function grob

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>  I have no idea how you actually call "seems to work",
>
>  namely just _how_ you want self-alignment-X to get factored in,
>
>  considering that the whole point of the dynText function is
>  to figure out an alignment yielding a text-dependent reference point.
>
> Sorry I haven't been clear.
>
> Here is a concrete description/example of what I want, and what I
> would say "works":
>
> 1. Attached is a screenshot of a current score I'm engraving.
>
> 2. I've used \dynText to create the dynamic "mp intensely".
>
> 3. Since the layout is such that this falls at the very end of a
> system, it messes up the horizontal spacing.
>
> 4. Using the edition-engraver, I'd like to set self-alignment-X =
> #RIGHT (which would allow the note spacing to normalize) and then use
> either X-offset or extra-offset to nudge the dynamic back to the right
> (to approximate the "proper" alignment). If I can do that, the
> mechanism (i.e., function + post-hoc tweak) "works".

Sigh.  I repeat: _what_ values of self-alignment-X should move the
reference point _where_ in "somewhat f"?  The default would be to have
-1 be the left border of the whole text, +1 the right border, 0 the
_center_ (and _not_ the middle of t and f).

You say you want self-alignment-X as +1 refer to the right border.  You
can already have that by just reverting X-offset to its default and then
using self-alignment-X in the old manner.

So apparently that is _not_ what you want, but you still fail to specify
_what_ you actually want.  Without such a specification, there will be
no code doing what you want because you just leave far too much in the
open.

> Although I clearly did not communicate my intention well enough, I
> knew *exactly* what I wanted before I started poking around.

You have a hand-waving idea about a border case and want to be able to
fudge your way around from that.  That's too vague for casting into a
computer-comprehensible form.

-- 
David Kastrup

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

Re: tweaks don't apply to post-function grob

[Kieren MacMillan]

Hello David (et al.),

> Using the edition-engraver, I'd like to set self-alignment-X = #RIGHT (which 
> would allow the note spacing to normalize) and then use either X-offset or 
> extra-offset to nudge the dynamic back to the right (to approximate the 
> "proper" alignment). If I can do that, the mechanism (i.e., function + 
> post-hoc tweak) "works".

As it turns out, I can get the same effect by setting X-extent = 
#empty-interval (so that the note-spacing ignores it) and then using 
extra-offset to nudge the dynamic back [almost] in place. That will do for my 
current needs… though I will continue to poke around and see if I can improve 
the \dynamic and \dynText function(s) in any way.

Thanks for the help,
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: tweaks don't apply to post-function grob

[Kieren MacMillan]

Hi David,

> I have no idea how you actually call "seems to work",
> namely just _how_ you want self-alignment-X to get factored in,
> considering that the whole point of the dynText function is
> to figure out an alignment yielding a text-dependent reference point.

Sorry I haven't been clear.

Here is a concrete description/example of what I want, and what I would say 
"works":

1. Attached is a screenshot of a current score I'm engraving.

2. I've used \dynText to create the dynamic "mp intensely".

3. Since the layout is such that this falls at the very end of a system, it 
messes up the horizontal spacing.

4. Using the edition-engraver, I'd like to set self-alignment-X = #RIGHT (which 
would allow the note spacing to normalize) and then use either X-offset or 
extra-offset to nudge the dynamic back to the right (to approximate the 
"proper" alignment). If I can do that, the mechanism (i.e., function + post-hoc 
tweak) "works".

> that is something you need to figure out before even starting to "poke 
> around".

Although I clearly did not communicate my intention well enough, I knew 
*exactly* what I wanted before I started poking around.

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: tweaks don't apply to post-function grob

[David Kastrup]

Kieren MacMillan  writes:

> Hi David (et al.),
>
>>> Can \dynText or similar be fashioned in such a way that leaves open
>>> the possibility of [effectively] tweaking the grob later in the
>>> process?
>> 
>> I repeat: If you want self-alignment-X to be heeded in there in some
>> manner, you need to incorporate it in the callback for the offset.
>
> I do appreciate the "teach a man to fish" approach…
>
> I've poked around at the \dynText function, and the \dynamic function
> in OpenLilyLib (see snippet, below, for original version), but have
> been as yet unable to incorporate self-alignment-X into the
> callback(s) for the offset in a way that seems to work.

I don't see what you tried.  And I have no idea how you actually call
"seems to work", namely just _how_ you want self-alignment-X to get
factored in, considering that the whole point of the dynText function is
to figure out an alignment yielding a text-dependent reference point.

So maybe you should say just what values of self-alignment-X you want to
lead to what alignment points when given a text like "somewhat f".

So far I have seen nothing in the way of spelling out what you actually
_want_.  Well, you want a dial to fiddle with, but just what values
should lead to what results without losing the whole point of dynText's
calculation is nothing you bothered to specify.

And of course that is something you need to figure out before even
starting to "poke around".

-- 
David Kastrup

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

Re: tweaks don't apply to post-function grob

[Kieren MacMillan]

Hi David (et al.),

>> Can \dynText or similar be fashioned in such a way that leaves open
>> the possibility of [effectively] tweaking the grob later in the
>> process?
> 
> I repeat: If you want self-alignment-X to be heeded in there in some
> manner, you need to incorporate it in the callback for the offset.

I do appreciate the "teach a man to fish" approach…

I've poked around at the \dynText function, and the \dynamic function in 
OpenLilyLib (see snippet, below, for original version), but have been as yet 
unable to incorporate self-alignment-X into the callback(s) for the offset in a 
way that seems to work.

Any further help or pointers (e.g., to a callback function which *does* 
incorporate self-alignment-X) would be welcome.

Thanks,
Kieren.

%%%  SNIPPET BEGINS
\version "2.19.64"

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

dynamic =
#(define-event-function (text) (markup?)
   (if (string? text)
   (let* ((underscores-replaced
   (string-map
(lambda (x) (if (eq? x #\_) #\space x))
text))
  (split-text (string-split underscores-replaced #\space))
  (formatted (map
  (lambda (word)
(if (string-match "^[mrzfps]*$" word)
(markup #:dynamic word)
(markup #:normal-text #:fontsize 0.625 #:italic 
word)))
  split-text)))
 #{
   -\tweak X-offset #0
   #(make-dynamic-script (make-line-markup formatted))
 #})

   ;; user provided a full-blown markup, so we don't mess with it:
   #{
 #(make-dynamic-script (markup #:normal-text text))
   #}))

{ c''1-\tweak self-alignment-X #RIGHT -\dynamic "p (non cresc.)" }
%%%  SNIPPET ENDS



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: XML import (WAS: A premiere by Daahoud Salim, typeset with LilyPond)

[Richard Shann]

On Tue, 2017-08-15 at 13:25 +0200, Francisco Vila wrote:
> From my work on Daahoud Salim's sextet, I can tell to those interested
> some things to do and some not to. Today I am focusing on the XML
> import alone.
> 
> Long story short: avoid it.
[...]
> 
> My advice to all copyists is: unless you can extract naked pitches and
> rhythms from the XML, it is better to forget it.
> 
I agree with this advice, which is why Denemo's MusicXML is still so
primitive. It has a few hiccups but it ignores most of what is not the
the music per se but is instead decisions about how the music should
look. I think LilyPond would be well served by a converter that takes
all the pitches/durations and things like time signatures needed to make
sense of them and ignores everything else. Meantime, Denemo can provide
a rather clunky route to get the bulk of the notes of a piece from
MusicXML into LilyPond notation.

Richard






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

Re: tweaks don't apply to post-function grob

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> The tweak applies fine but self-alignment-X is consulted in the normal
>> callback for X-offset which has been replaced by a callback using the
>> formula (- 1 (/ width 2)) .  If you want self-alignment-X to be heeded
>> in there in some manner, you need to incorporate it in the callback for
>> the offset.
>
> Thanks for the explanation.
>
> The problem is, I want to eat my cake and have it too: I want a
> function (cf. \dynText) which combines a dynamic text with a piece of
> normal text and automatically sets the correct alignment (i.e., with
> the dynamic portion aligned as if there were no subsequent normal
> text), but I want to be able to manually tweak it afterwards (to avoid
> collisions, improve score aesthetics, etc.). Unfortunately, that
> "layout-time" tweak — which may be different for different "editions"
> — cannot be cooked into the function without (e.g.) tagging or similar
> content-presentation mixing, which I'd desperately like to avoid.
>
> Can \dynText or similar be fashioned in such a way that leaves open
> the possibility of [effectively] tweaking the grob later in the
> process?

I repeat: If you want self-alignment-X to be heeded in there in some
manner, you need to incorporate it in the callback for the offset.

-- 
David Kastrup

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

Re: tweaks don't apply to post-function grob

[Kieren MacMillan]

Hi David,

> The tweak applies fine but self-alignment-X is consulted in the normal
> callback for X-offset which has been replaced by a callback using the
> formula (- 1 (/ width 2)) .  If you want self-alignment-X to be heeded
> in there in some manner, you need to incorporate it in the callback for
> the offset.

Thanks for the explanation.

The problem is, I want to eat my cake and have it too: I want a function (cf. 
\dynText) which combines a dynamic text with a piece of normal text and 
automatically sets the correct alignment (i.e., with the dynamic portion 
aligned as if there were no subsequent normal text), but I want to be able to 
manually tweak it afterwards (to avoid collisions, improve score aesthetics, 
etc.). Unfortunately, that "layout-time" tweak — which may be different for 
different "editions" — cannot be cooked into the function without (e.g.) 
tagging or similar content-presentation mixing, which I'd desperately like to 
avoid.

Can \dynText or similar be fashioned in such a way that leaves open the 
possibility of [effectively] tweaking the grob later in the process?

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

XML import (WAS: A premiere by Daahoud Salim, typeset with LilyPond)

[Francisco Vila]

>From my work on Daahoud Salim's sextet, I can tell to those interested
some things to do and some not to. Today I am focusing on the XML import
alone.

Long story short: avoid it.

This is a very small piece when compared to dozens of huge works we all
in the list have seen on the years, but it is decent-sized for me, at
least big enough so that some mistakes can have a deep effect on the
workflow.

What is obviuos is that a version control system of any kind is
absolutley needed. In my case that saved me from the disaster two or
more times. Branches are very useful, too. But this is well known by git
users. All ponders, do become git users! Some also use Make for
building. I used it for my LaTeX thesis. _My_ problem with Make is that
syntax of makefiles is very hard to read.

The piano part looked cumbersome to type; I knew the composer could give
me exported XMLs from Finale and I thought this was going to make me
save some time. It was rather the opposite. MusicXML puts too many
layout details forced.

- The converted code has \stemUp and \stemDown in every single note,
which had to be searched and replaced. Also all articulations are forced
up or down. Beams are also fixed.

- Page and line breaks are there and you don't want them.

- Tuplet fractions are often almost impossible to understand.

- Line breaks in the code itself are nonsense, e.g. in the middle of a
<> chord or a tuplet.

- Bar number checks have to be searched as well to delete them. What if
you want to insert a measure? it's a nightmare. Even worse, bar number
checks are not fixed strings, so you have to compose regular expressions
to match them.

- Dynamics are not attached to the note it is meant to, if the author
moved them with the mouse.

- Page size is usually US Letter.

- Just look at this converted block:

#(set-global-staff-size 20.6625714286)

\paper {
paper-width = 21.59\cm
paper-height = 27.93\cm
top-margin = 1.27\cm
bottom-margin = 1.27\cm
left-margin = 2.53\cm
right-margin = 1.27\cm
between-system-space = 2.19\cm
page-top-space = 1.27\cm
indent = 1.66076923077\cm
short-indent = 1.10717948718\cm
  }

No comments. Except that you have to pay attention to it even if you
want to discard it completely, because it's between all else, otherwise
useful, code. The work of picking and editing the useful parts is
time-consuming.

My advice to all copyists is: unless you can extract naked pitches and
rhythms from the XML, it is better to forget it.

===

> Hello; as promised, here is the link: https://goo.gl/oauPWL but please
bear in mind > that the composer has found some changes to be done and
therefore the version > is not final. Read the history.txt file to know
what latest changes are.

Grachtenfestival Amsterdam Poem: History of Peoples
https://www.grachtenfestival.nl/concert_detail.vm?id=3379

Sunday 13 August / 20:30
Muziek
Salim, D.: Poem: History of Peoples
Chausson, E: Poème
Ravel, M.: Violin Sonata no. 2 in G major

Daahoud Salim
piano, composer
https://www.grachtenfestival.nl/musician_detail.vm?mus=43576=en

Rosanne Philippens
violin
https://www.grachtenfestival.nl/musician_detail.vm?mus=7906
http://www.rosannephilippens.com/

Aristos Quartet
https://www.grachtenfestival.nl/musician_detail.vm?ens=8711=en
http://aristosquartet.nl/home/
Evelien Jaspers - Dmitry Ivanov - Sylvain Dessane - Otto Bakker

-- 

Francisco Vila. Badajoz (Spain)
paconet.org , csmbadajoz.com

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

Re: Remove all occurrencies of "0" fingerings

[Marc Hohl]

Am 15.08.2017 um 10:15 schrieb David Kastrup:

Marc Hohl  writes:
[...]

For the record: First, I used the solution with grob-transformer, but
then I found out that removing the grob completely yields to problems
with glissando lines between fingerings, so I switched to the solution
given above.


Your description did not imply that you actually wanted to use that
point for positioning purposes.  However, I think glissandi are between
noteheads rather than fingerings.  It's conceivable that they try taking
fingerings into account in some manner: in that case, it would make
sense if they ignored empty stencils.


Yes, of course. I wasn't aware of the implications either – putting
glissando lines between fingerings is quite straightforward, but I had
to use glissandoMap and some trickery to create a satisfactory result.

My current project includes a book with a violin and a guitar staff, and
an additional handout for guitar-only purposes with tablature added. My
focus was primarily on the first part, which has to be finished in terms
of the layout as soon as possible for the illustrator to start to draw
the pictures to be added later. Therefore I missed the glissando line
suddenly pointing to nowhere in the tablature part.

Interestingly, I didn't see the spurious line on screen, but in a 
printoutthat I am currently using for practicing the guitar part that 
will be

recorded in a couple of days. I don't know whether others have made
similar experiences, but on screen nearly everything seems to look
correct.


At any rate, it is sort of amusing that your choice between two complex
solutions hinges on whether they use point-stencil or empty-stencil
internally: interchanging those two is not all that hard.  At least
Thomas documented his solution better.


Well, IIRC you were the first who mentioned the recursion error (which I
should have found myself – silly me).  But I have to admit that Harm's
solution works with scheme functions I understood at first glance,
whereas the grob-transformer stuff was not that easy for me to cope
with.

Conclusion: the list is great, and the fact that there are multiple
solutions to a problem makes it easier to find the most suitable
workaround ;-)

Regards,

Marc





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

Re: Remove all occurrencies of "0" fingerings

[David Kastrup]

Marc Hohl  writes:

> Am 08.08.2017 um 12:35 schrieb Thomas Morley:
>> 2017-08-08 11:46 GMT+02:00 Marc Hohl :
> [...]
>> Hi Marc,
>>
>> your initial code had two problems, comments inline:
>>
>> \override Fingering.stencil =
>>#(lambda (grob)
>>   (let* ((text (ly:grob-property grob 'text))
>>  (stencil (if (equal? text "0")
>>   ;; to avoid the warning go for point-stencil
>>   ;; not empty-stencil
>>   point-stencil
>>   ;; return a stencil yourself, don't call the
>>   ;; property which is created by the stencil-prop
>>   ;; it's a cycle and I'm somewhat surprised it 
>> failed
>>   ;; not more spectaculary
>>   (ly:text-interface::print grob
>> stencil))
>
>
> For the record: First, I used the solution with grob-transformer, but
> then I found out that removing the grob completely yields to problems
> with glissando lines between fingerings, so I switched to the solution
> given above.

Your description did not imply that you actually wanted to use that
point for positioning purposes.  However, I think glissandi are between
noteheads rather than fingerings.  It's conceivable that they try taking
fingerings into account in some manner: in that case, it would make
sense if they ignored empty stencils.

At any rate, it is sort of amusing that your choice between two complex
solutions hinges on whether they use point-stencil or empty-stencil
internally: interchanging those two is not all that hard.  At least
Thomas documented his solution better.

-- 
David Kastrup

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

Re: Remove all occurrencies of "0" fingerings

[Marc Hohl]

Am 08.08.2017 um 12:35 schrieb Thomas Morley:

2017-08-08 11:46 GMT+02:00 Marc Hohl :

[...]

Hi Marc,

your initial code had two problems, comments inline:

\override Fingering.stencil =
   #(lambda (grob)
  (let* ((text (ly:grob-property grob 'text))
 (stencil (if (equal? text "0")
  ;; to avoid the warning go for point-stencil
  ;; not empty-stencil
  point-stencil
  ;; return a stencil yourself, don't call the
  ;; property which is created by the stencil-prop
  ;; it's a cycle and I'm somewhat surprised it failed
  ;; not more spectaculary
  (ly:text-interface::print grob
stencil))



For the record: First, I used the solution with grob-transformer, but
then I found out that removing the grob completely yields to problems
with glissando lines between fingerings, so I switched to the solution
given above.

Thanks a lot!

Marc

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

Re: in-stave / between notes spacing?

[Malte Meyn]

Am 15.08.2017 um 00:15 schrieb Vlad Kudelin:

Hello,
thank you again everybody for the fantastic tool! I enjoy it more and more, 
most things become easier every day, except for those few that become harder ) 
Hope asking questions once in a while is all right.
...I've found a lot about vertical spacing between staves / systems... but 
seems there is no clear way (to me at least) on how to increase vertical 
distance between lines / notes in a staff/chord, so some of my writing looks 
pretty hard to read (see the example, Ver. 1).
See how the tie on aes in the Ver. 1 is almost invisible. (_
I tried using voicing (Ver. 2 & 3). In Ver. 2 it gets worse:  there is visually an 
error –– the quarter notes 4 look like 8ths (__
And with "\StemUp/down" it gets really messy to write.
Can this be improved visually?  I think making the staff a bit taller could 
just do the trick


For polyphony (Version 2 & 3) you wouldn’t use \stemUp and \stemDown but 
\voiceOne and \voiceTwo (and, if you have more voices, also \voiceThree 
etc.).


But for

<< { \voiceOne A } { \voiceTwo B } >>

there is the shortcut

<< { A } \\ { B } >>

so you don’t need these commands in this situation.

To improve your Version 1 you can manually change the direction of the ties.

The following code shows three possible solutions to your problem:
• Version 4 is like Version 1 but changes the tie direction.
• Version 5 uses << \\ >> for polyphony as described above.
• Version 6 is how I would notate it: use polyphony only where necessary 
(i. e. only the second beat).


I couldn’t resist to clean up your code a bit before trying to find 
better solutions ;) I find it very confusing to use \relative outside of 
\new Staff although it seems to work. And it’s not necessary to write 
“” instead of “< c e, >” but I find the latter confusing, same as 
headers, \score blocks and context names that aren’t necessary to 
understand the problem. So I hope these changes don’t distract you from 
the original problem.


\version "2.18.2"

% Version 4
\new PianoStaff <<
  \new Staff \relative {
\clef treble
 8  2\fermata |
\bar "|."
  }
  \new Staff \relative {
\clef bass
f,4 g4 r8 4. |
\bar "|."
  }
>>

% Version 5
\new PianoStaff <<
  \new Staff \relative {
\clef treble
<<
  {
4 8 8
  } \\ {
4 4
  }
>>
2\fermata |
\bar "|."
  }
  \new Staff \relative {
\clef bass
f,4 g4 r8 4. |
\bar "|."
  }
>>

% Version 6
\new PianoStaff <<
  \new Staff \relative {
\clef treble
4
<<
  {
8 8
  } \\ {
4
  }
>>
2\fermata |
\bar "|."
  }
  \new Staff \relative {
\clef bass
f,4 g4 r8 4. |
\bar "|."
  }
>>

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