Re: Fedora 31, Python3, Frescobaldi

2019-11-04 Thread Martin Tarenskeen




On Sun, 3 Nov 2019, Federico Bruni wrote:

See 
https://src.fedoraproject.org/rpms/frescobaldi/c/f7fd91a956649f3015eb7332922fcf2f861a730e?branch=master


Those commits are in master but may be merged also in f31 branch?
Contact the maintainer if you want to know more.


-- Comment #10 from Fedora Update System  ---
frescobaldi-3.0.0-14.fc31 has been pushed to the Fedora 31 testing 
repository.

If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1ef4102e8a

--

MT



Re: Graphic lines create

2019-11-04 Thread Pierre Perol-Schneider
Hi Reggie,
As Andrew pointed, see:
http://lilypond.1069038.n5.nabble.com/Off-topics-vibrato-td145006.html#a145087
Cheers,
Pierre

Le mar. 5 nov. 2019 à 03:14, Reggie  a écrit :

> Hi. I cannot find how to create graphic lines anywhere in LilyPond like
> this.
> I find basic shapes but nothing like this modern style. How do you provide
> the angle and length to adjust for score? Please suggest code for this.
> Thanks!
>
> 752ddda41273_10157508106580761_7457284070309888000_o.jpg
> <
> http://lilypond.1069038.n5.nabble.com/file/t5625/752ddda41273_10157508106580761_7457284070309888000_o.jpg>
>
>
>
>
> --
> Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
>
>
\version "2.19.64"

%% https://raw.githubusercontent.com/mwitmer/LyUtil/master/ly/expressive_markings/vibrato.ly
%% Original author: Mark Witmer
%% Rewritten version by Harm

% Returns the width of a grob
#(define (grob-width grob)
  (let ((x-ext (ly:grob-property grob 'X-extent)))
(if (interval-sane? x-ext)
(- (cdr x-ext) (car x-ext))
0)))

#(define (apply-proc-to-leading-two-args proc ls rl)
  (if (null? (cdr ls))
  (reverse rl)
  (apply-proc-to-leading-two-args
proc
(cdr ls)
(cons (proc (car ls) (cadr ls)) rl

#(define (make-amplitudes-list amplitudes total-span wavelength)
"Makes a list of amplitudes for the vibrato"
  (let* (
 ;; how many waves for the entire total-span
 (lngth (/ total-span wavelength))
 ;; the total-span is divided into parts:
 (parts (1- (length amplitudes)))
 ;; each part gets that much waves
 (partial-length (/ lngth parts))
 ;; get a list of amplitude-pairs, i.e.:
 ;; '(1 2 3 4) -> '((1 . 2) (2 . 3) (3 . 4))
 (amp-pairs
   (apply-proc-to-leading-two-args
 cons
 amplitudes
 '()))
 ;; calculate the amplitudes
 (amplitudes-list
   (append-map
 (lambda (amp-pair)
   (map
 (lambda (n)
   (+ (car amp-pair) 
   (* (/ n partial-length)
  (- (cdr amp-pair) (car amp-pair)
 (iota (ceiling partial-length
  amp-pairs)))
  ;; don't forget last amplitude
  (append amplitudes-list (list (last amplitudes)

#(define (wave-line-stencil left-bound x-span thick amplitude-list wave-length) 
"Creates the wave-line for one system of the vibrato using 
@code{make-path-stencil}.
@var{x-span} is the length of the line to do, @var{thick} the thickness of the
drawn line.
Each wave of the resulting line follows the settings provided by 
@var{amplitude-list} for the extent in y-axis and @var{wave-length} for x-axis.
@var{wave-length} is scaled in order to warrant exact matching extents of the
resulting line and @var{x-span}.
"
;; TODO take thickness of line into account?
  (if (zero? x-span)
  empty-stencil
  (let* (;; get the amount of waves which will be needed
 (waves-amount (length amplitude-list))
 ;; the added waves would result in a line with length
 (raw-line-length (* waves-amount wave-length))
 ;; get the factor to scale the provided wave-length to ensure
 ;; matching lengths
 (corr (/ raw-line-length x-span))
 ;; calculate the scaled wave-length
 (scaled-wave-length (/ wave-length corr)))
 (make-path-stencil
   (append
 `(moveto ,left-bound 0.0)
 (append-map
   (lambda (amp)
 `(rcurveto
   ,(/ scaled-wave-length 3.0) ,amp 
   ,(* 2 (/ scaled-wave-length 3.0)) ,(- amp)
   ,scaled-wave-length 0.0))
   amplitude-list))
thick
1
1
#f

#(define (make-wavy-vibrato-stencil grob amplitudes wave-length)
"Creates a stencil that draws a wavy line for vibrato based on @var{amplitudes},
a list of vertival lengths, and @var{wave-length} for the horizontal extent.
"
  (let* ((orig (ly:grob-original grob))
 (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '()))
 (thick (ly:grob-property grob 'thickness 0.2))
 ;; length of the actual grob
 (xspan (grob-width grob))
 ;; add the length of all siblings
 (total-span
   (if (null? siblings)
   (grob-width grob)
   (reduce + 0 (map (lambda (g) (grob-width g)) siblings
 ;; get the x-position for the start
 (left-bound 
   (if (or (null? siblings) (eq? (car siblings) grob)) 
   ;; compensate thickness of the line
   (* thick -2)
   ;; start a little left
   (1- (assoc-get 'X (ly:grob-property grob 'left-bound-info)
 ;; get the length of the already done parts of the wavy line
 (span-so-far 
   (if 

Re: Graphic lines create

2019-11-04 Thread Andrew Bernard
HI Reggie,

If you want to draw all sorts of freeform curves, then that's a whole topic
of it's own. compared to the algorithmic code for the vibrato.

Let us know.

Andrew


Re: Graphic lines create

2019-11-04 Thread Andrew Bernard
The code for which came from Mark Witmer, many thanks to him.

Andrew


Re: Graphic lines create

2019-11-04 Thread Andrew Bernard
Hi Reggie,

I have a vibrato function that is highly parameterized. If the picture here
gives you some idea, I can post the code. Using the right arguments you can
achieve pretty close to what you have. And you can rotate objects easily,
as per your picture.

An alternative is to code the oscillating path in PostScript, which
lilypond supports just fine (but then you can't output it to SVG, in case
that is an issue.)

But no, this sort of graphical gesture is not available in lilypond as a
built in. But lilypond can be made to do anything.

Andrew



On Tue, 5 Nov 2019 at 13:14, Reggie  wrote:

> Hi. I cannot find how to create graphic lines anywhere in LilyPond like
> this.
>
>


Graphic lines create

2019-11-04 Thread Reggie
Hi. I cannot find how to create graphic lines anywhere in LilyPond like this.
I find basic shapes but nothing like this modern style. How do you provide
the angle and length to adjust for score? Please suggest code for this.
Thanks!

752ddda41273_10157508106580761_7457284070309888000_o.jpg

  



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



Re: How to use optional arguments / parameters in a define-markup-command

2019-11-04 Thread Urs Liska
Hi Karsten,

4. November 2019 17:59, "Karsten Reincke"  schrieb:

> Dear friends
> 
> A few days ago, I asked whether anyone knows how one can use variable 
> parameter
> lists = optional arguments = flexible argumentlists in a markup function. I 
> was
> told that such an opportunity does not exist (Thomas Morley) resp. must be
> simulated by some embedded property features (Urs Liska). Many thanks for 
> these
> quick answers. They preserved me from doing unnecessary work.
> 
> Here is a pure scheme / guile solution using lisp association lists (demoed by
> using the box example from the extend tutorial). 

I see one major issue with your approach: it pollutes the namespace with a 
multitude of global variables.

I don't want to push you towards using openLilyLib ;-) but oll-core includes a 
macro "with-options" (created by Stéfano Troncaro) that allows the modification 
of define-music-function (I'm not sure about markup functions right now) so 
that the function accepts an optional \with { } clause, performs validation 
against mandatory and optional arguments (optionally along with their types) 
and can provide default values - all without necessarily using #(define XXX) 
and creating global variables.

The code starts here: 
https://github.com/openlilylib/oll-core/blob/master/internal/options.ily#L245

and here is an example function that is defined that way (all my functions 
using that macro are still in private repositories). It prints text centered 
above and below a given music (in my case it was a measure.

The define-music-function clause is modified by the with-option macro 
(available after \include "oll-core/package.ily").
Then there's one additional list where the options are defined, in this case 
there are three options, "above", "below" and "horizontal-padding", defined as 
markups and number, with default values. Inside the function they are available 
through an alist with the name of props (which is admittedly incosistent and 
should be changed).

The function could for example be used like

\annotateCenteredMusic \with { above = "Hello" } { c'1 }
or even

\annotateCenteredMusic { c'1 }
(which would not make any sense in this specific case because the defaults are 
empty markups).

annotateCenteredMusic =
#(with-options define-music-function (music)(ly:music?)
   `(strict
 (? above ,markup? ,(markup #:null))
 (? below ,markup? ,(markup #:null))
 (? horizontal-padding ,number? 2)
 )
   ;; Store data in a closure to drag it over from the music-function stage
   ;; to before-line-breaking and stencil
   (let ((upper
  ;; apply \Xg (ascender/descender placeholder) for non-null markups
  ;; NOTE:
  ;; in multiline markups the \Xg markup command has to be applied
  ;; manually at one point in the last line if that last line
  ;; doesn't contain a descender!
  (let ((original (assq-ref props 'above)))
(if (equal? original (markup #:null))
original
(markup #:Xg original
 (lower
  (let ((original (assq-ref props 'below)))
(if (equal? original (markup #:null))
original
(markup #:Xg original
 (music-stil #f)
 (upper-stil #f)
 (lower-stil #f)
 (upper-padding (getOption '(mozart centered staff-padding-up)))
 (lower-padding (getOption '(mozart centered staff-padding-down)))
 (horizontal-padding (assq-ref props 'horizontal-padding)))
 #{
   \tweak before-line-breaking
   #(lambda (grob)
  ;; Create the three markup stencils *now* and store it in the closure
  ;; so we can use its dimensions to affect the layout.
  (set! music-stil #{ \getBareScoreMarkupStencil #grob #music #})
  (set! upper-stil (grob-interpret-markup grob upper))
  (set! lower-stil (grob-interpret-markup grob lower))
  (let*
   ((max-text-width
 (max
  (interval-length (ly:stencil-extent upper-stil X))
  (interval-length (ly:stencil-extent lower-stil X
(music-width (interval-length (ly:stencil-extent music-stil X)))
(width-diff
 (abs (/ (- max-text-width music-width) 2)))
(dummy (ly:message "Music width: ~a" width-diff))
)

  (ly:grob-set-property! grob 'Y-extent
;; Include the markups in the Y-extent of the MMR
;; so it won't get cut off the page
(cons
 (min
  (- 0 2 lower-padding (interval-length (ly:stencil-extent 
lower-stil Y)))
  (car (ly:stencil-extent music-stil Y)))
 (max
  (+ 2 upper-padding (interval-length (ly:stencil-extent upper-stil 
Y)))
  (cdr (ly:stencil-extent music-stil Y)))
  ))

  (ly:grob-set-property! grob 'minimum-length
;; widen the measure to encompass music content, upper, 

Re: scheme-question: matrix-operation

2019-11-04 Thread Thomas Morley
Am Mo., 4. Nov. 2019 um 01:05 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > lets say I've a list of sublists like '((1 2 3)(4 5 6))
> > I want to modify it, the result should be '((1 3 5)(2 4 6))
> >
> > This is a matrix-operation (not sure whether matrix is the correct
> > english term), on could write it graphically:
> > 1 2 3
> > 4 5 6
> > ->
> > 1 3 5
> > 2 4 6
> >
> > What's the best scheme-way to get it?
>
> What is it that you are doing?  I don't see the principle you apply
> here.  Changing '((1 2 3)(4 5 6)) to '((1 4) (2 5) (3 6)) is an obvious
> transformation, but your single example does not really give much of an
> idea of what you do.

While trying to write a reply I came across some bad thinking of mine.
I don't need this at all.

Sorry for the noise,
  Harm



Re: How to use optional arguments / parameters in a define-markup-command

2019-11-04 Thread Thomas Morley
Am Mo., 4. Nov. 2019 um 18:00 Uhr schrieb Karsten Reincke :
>
> Dear friends
>
> A few days ago, I asked whether anyone knows how one can use variable 
> parameter
> lists = optional arguments = flexible argumentlists in a markup function. I 
> was
> told that such an opportunity does not exist (Thomas Morley)

Let me quote another part of my reply:

Am Fr., 1. Nov. 2019 um 16:01 Uhr schrieb Thomas Morley
:

> For variable amount of args I'd go for list? (or the like) and let the
> body of your code sort it out.

And that's basically what you do in your example-code.

> resp. must be
> simulated by some embedded property features (Urs Liska).

That's not exactly what Urs wrote...

> #(define (assign keyValue assocList defaultValue)
>   (string? list?)
^^
As far as I can tell this line is superfluous, returning #f.

>   (let* ((localPair (assoc keyValue assocList)))
> (if localPair (cdr localPair) defaultValue)
>   )
> )

Check for assoc-get resp. ly:assoc-get doing.


Cheers,
  Harm



Re: Scoped variables

2019-11-04 Thread Timothy Lanfear

On 04/11/2019 19:57, David Wright wrote:

Well, the NR §3.1.5 does say:
"A .ly file may contain any number of toplevel expressions, where a
 toplevel expression is one of the following: …

 • A \score block. This score will be collected with other toplevel
   scores, and combined as a single \book. …

 • A \book block logically combines multiple movements (i.e.,
   multiple \score blocks) in one document. If there are a number
   of \scores, one output file will be created for each \book block,
   in which all corresponding movements are concatenated."

So I assume you are depending on the first bullet, the implicit \book
block, to concatenate the scores. (I'm not sure what the \bookpart buys
you apart from a page-throw. Try commenting out your \bookpart lines.)

The NR goes on:

  "The only reason to explicitly specify \book blocks in a .ly file
   is if you wish to create multiple output files from a single
   input file."

That's what I use \book sections for, so the my output files can be
explicitly named (with \bookOutputSuffix) in a more systematic manner.
Editing your MWE with s/\bookpart/\book/ would demonstrate.
(I've never used bookparts myself.)

My surprise was caused by the difference in behaviour between an 
explicit \book block (variables cannot be redefined within a \book) and 
the implicit book created when there is no explicit \book statement -- 
see NR 3.1.1 on the implicit \book block


--

Timothy Lanfear, Bristol, UK.




Re: Centering wordwrap-lines text?

2019-11-04 Thread Solomon Foster
>
> Message: 2
> Date: Mon, 04 Nov 2019 09:42:57 -0800
> From: Aaron Hill 
> To: lilypond-user@gnu.org
> Subject: Re: Centering wordwrap-lines text?
> Message-ID: <3aacb64353fe6e665f5fe68e0aa7a...@hillvisions.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On 2019-11-04 9:18 am, Solomon Foster wrote:
> > Hi all,
> >
> > Next problem to tackle for my tunebook project is one which seems
> > simple
> > and small but has utterly stumped me.  If I've got a block of text,
> > something like this:
> >
> > \markuplist {
> > \wordwrap-lines {
> > Composed while playing the fiddle on board an airplane.
> > }
> > }
> >
> > How do I center the text under the tune?  (The text may be long enough
> > that
> > wordwrap is actually needed, BTW.)
> >
> > My few attempts at this that seem to have correct syntax seem to center
> > it
> > on the edge of the page or something weird like that.
>
> 
> \version "2.19.83"
>
> \markup \fill-line {
>\center-column \override #'(line-width . 50) \wordwrap-lines
>{ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer
>  volutpat tincidunt libero, a malesuada sapien scelerisque sed.
>  Phasellus sed placerat est. Mauris fringilla dignissim nulla.
>  Cras vitae elit a tellus egestas aliquam. }
> }
> 
>
> While \center-column will take care of aligning the individual markups
> from \wordwrap-lines, it is the use of \fill-line that will ensure the
> overall markup is centered on the page.
>

Thanks!

 And the  \override #'(line-width . 50) is just to make the lines shorter?
It looks like it works without it, centered but much wider.

-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com


Re: Scoped variables

2019-11-04 Thread David Wright
On Mon 04 Nov 2019 at 18:46:05 (+), Timothy Lanfear wrote:
> On 04/11/2019 09:28, Peter Toye wrote:
> > Re: Scoped variables On further consideration I think that Timothy
> > Lanfear has, probably inadvertently, made my point for me.
> > 
> > If a publisher wanted to collect Mr. Lanfear's string quartets
> > (assuming that he has written more than one) into a single volume,
> > the Lilypond code would have to be changed to rename all of the
> > variables to something like QiIViolinI (using Roman numerals to
> > keep to the published convention of alphabetic characters only -
> > I'm surprised that Mr. Lanfear's version works at all). Using my
> > idea, and assuming that the variables were defined within the
> > score, noting has to change apart from the book and possibly
> > bookpart sections. Much easier and less error-prone. Also, if each
> > staff's content is in its own file in the same directory as its
> > score, the same code will serve for all movements:
> >   \score {
> >   \include "ViolinI.ly"
> >   \include "ViolinII.ly"
> >   \include "Viola.ly"
> >   \include "Cello.ly"
> >   }
> > 
> > Now you can have a directory/file structure like:
> > 
> > Book
> >   Book.ly
> >   Quartet1
> >     Movement1
> >       Score.ly
> >       Violin1.ly
> >       ...
> >     Movement2
> >       Score.ly
> > 
> > etc.
> > 
> > *
> > *
> 
> I was surprised to find that provided there is no explicit \book
> statement, variables can be redefined between bookparts and behave as
> desired.
> 
> \version "2.19.83"
> 
> I.Violin.1 = { \clef "treble" b'1 }
> I.Violin.2 = { \clef "treble" g' }
> I.Viola = { \clef "alto" d' }
> I.Cello = { \clef "bass" g1 }
> 
> \bookpart {
>   \score {
>   <<
>     \new Staff { \I.Violin.1 }
>     \new Staff { \I.Violin.2 }
>     \new Staff { \I.Viola }
>     \new Staff { \I.Cello }
>   >>
>   }
> }
> 
> I.Violin.1 = { \clef "treble" \key d\major cis''1 }
> I.Violin.2 = { \clef "treble" \key d\major a' }
> I.Viola = { \clef "alto" \key d\major e' }
> I.Cello = { \clef "bass" \key d\major a1 }
> 
> \bookpart {
>   \score {
>   <<
>     \new Staff { \I.Violin.1 }
>     \new Staff { \I.Violin.2 }
>     \new Staff { \I.Viola }
>     \new Staff { \I.Cello }
>   >>
>   }
> }

Well, the NR §3.1.5 does say:

   "A .ly file may contain any number of toplevel expressions, where a
toplevel expression is one of the following: …

• A \score block. This score will be collected with other toplevel
  scores, and combined as a single \book. …

• A \book block logically combines multiple movements (i.e.,
  multiple \score blocks) in one document. If there are a number
  of \scores, one output file will be created for each \book block,
  in which all corresponding movements are concatenated."

So I assume you are depending on the first bullet, the implicit \book
block, to concatenate the scores. (I'm not sure what the \bookpart buys
you apart from a page-throw. Try commenting out your \bookpart lines.)

The NR goes on:

 "The only reason to explicitly specify \book blocks in a .ly file
  is if you wish to create multiple output files from a single
  input file."

That's what I use \book sections for, so the my output files can be
explicitly named (with \bookOutputSuffix) in a more systematic manner.
Editing your MWE with s/\bookpart/\book/ would demonstrate.
(I've never used bookparts myself.)

The NR goes on:

 "One exception is within lilypond-book documents, where you
  explicitly have to add a \book block if you want more than a
  single \score or \markup in the same example. …"

But it's not clear whether the OP is needing lilypond-book, because
their post concentrates only on Scoped Variables, which would seem to
involve a major code rewrite.
(I've never used lilypond-book seriously myself, preferring a workflow
using PDF fragments, their tools, and LuaLaTeX for final assembly.)

Cheers,
David.



Re: Scoped variables

2019-11-04 Thread Peter Toye
Hmm. Interesting.

But I still prefer properly scoped variables!

Peter



-
Monday, November 4, 2019, 6:46:05 PM, Timothy Lanfear wrote:

I was surprised to find that provided there is no explicit \book statement, 
variables can be redefined between bookparts and behave as desired.
\version "2.19.83"

I.Violin.1 = { \clef "treble" b'1 }
I.Violin.2 = { \clef "treble" g' }
I.Viola = { \clef "alto" d' }
I.Cello = { \clef "bass" g1 }

\bookpart {
  \score {
  <<
\new Staff { \I.Violin.1 }
\new Staff { \I.Violin.2 }
\new Staff { \I.Viola }
\new Staff { \I.Cello }
  >>
  }
}

I.Violin.1 = { \clef "treble" \key d\major cis''1 }
I.Violin.2 = { \clef "treble" \key d\major a' }
I.Viola = { \clef "alto" \key d\major e' }
I.Cello = { \clef "bass" \key d\major a1 }

\bookpart {
  \score {
  <<
\new Staff { \I.Violin.1 }
\new Staff { \I.Violin.2 }
\new Staff { \I.Viola }
\new Staff { \I.Cello }
  >>
  }
}

-- 
Timothy Lanfear, Bristol, UK.

Re: Scoped variables

2019-11-04 Thread Timothy Lanfear


On 04/11/2019 09:28, Peter Toye wrote:
Re: Scoped variables On further consideration I think that Timothy 
Lanfear has, probably inadvertently, made my point for me.


If a publisher wanted to collect Mr. Lanfear's string quartets 
(assuming that he has written more than one) into a single volume, the 
Lilypond code would have to be changed to rename all of the variables 
to something like QiIViolinI (using Roman numerals to keep to the 
published convention of alphabetic characters only - I'm surprised 
that Mr. Lanfear's version works at all). Using my idea, and assuming 
that the variables were defined within the score, noting has to change 
apart from the book and possibly bookpart sections. Much easier and 
less error-prone. Also, if each staff's content is in its own file in 
the same directory as its score, the same code will serve for all 
movements:

  \score {
  \include "ViolinI.ly"
  \include "ViolinII.ly"
  \include "Viola.ly"
  \include "Cello.ly"
  }

Now you can have a directory/file structure like:

Book
  Book.ly
  Quartet1
    Movement1
      Score.ly
      Violin1.ly
      ...
    Movement2
      Score.ly

etc.

*
*


I was surprised to find that provided there is no explicit \book 
statement, variables can be redefined between bookparts and behave as 
desired.


\version "2.19.83"

I.Violin.1 = { \clef "treble" b'1 }
I.Violin.2 = { \clef "treble" g' }
I.Viola = { \clef "alto" d' }
I.Cello = { \clef "bass" g1 }

\bookpart {
  \score {
  <<
    \new Staff { \I.Violin.1 }
    \new Staff { \I.Violin.2 }
    \new Staff { \I.Viola }
    \new Staff { \I.Cello }
  >>
  }
}

I.Violin.1 = { \clef "treble" \key d\major cis''1 }
I.Violin.2 = { \clef "treble" \key d\major a' }
I.Viola = { \clef "alto" \key d\major e' }
I.Cello = { \clef "bass" \key d\major a1 }

\bookpart {
  \score {
  <<
    \new Staff { \I.Violin.1 }
    \new Staff { \I.Violin.2 }
    \new Staff { \I.Viola }
    \new Staff { \I.Cello }
  >>
  }
}

--
Timothy Lanfear, Bristol, UK.



Re: Centering wordwrap-lines text?

2019-11-04 Thread Aaron Hill

On 2019-11-04 9:18 am, Solomon Foster wrote:

Hi all,

Next problem to tackle for my tunebook project is one which seems 
simple

and small but has utterly stumped me.  If I've got a block of text,
something like this:

\markuplist {
\wordwrap-lines {
Composed while playing the fiddle on board an airplane.
}
}

How do I center the text under the tune?  (The text may be long enough 
that

wordwrap is actually needed, BTW.)

My few attempts at this that seem to have correct syntax seem to center 
it

on the edge of the page or something weird like that.



\version "2.19.83"

\markup \fill-line {
  \center-column \override #'(line-width . 50) \wordwrap-lines
  { Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer
volutpat tincidunt libero, a malesuada sapien scelerisque sed.
Phasellus sed placerat est. Mauris fringilla dignissim nulla.
Cras vitae elit a tellus egestas aliquam. }
}


While \center-column will take care of aligning the individual markups 
from \wordwrap-lines, it is the use of \fill-line that will ensure the 
overall markup is centered on the page.



-- Aaron Hill



Centering wordwrap-lines text?

2019-11-04 Thread Solomon Foster
Hi all,

Next problem to tackle for my tunebook project is one which seems simple
and small but has utterly stumped me.  If I've got a block of text,
something like this:

\markuplist {
\wordwrap-lines {
Composed while playing the fiddle on board an airplane.
}
}

How do I center the text under the tune?  (The text may be long enough that
wordwrap is actually needed, BTW.)

My few attempts at this that seem to have correct syntax seem to center it
on the edge of the page or something weird like that.

Thanks,
Sol

-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com


How to use optional arguments / parameters in a define-markup-command

2019-11-04 Thread Karsten Reincke
Dear friends

A few days ago, I asked whether anyone knows how one can use variable parameter
lists = optional arguments = flexible argumentlists in a markup function. I was
told that such an opportunity does not exist (Thomas Morley) resp. must be
simulated by some embedded property features (Urs Liska). Many thanks for these
quick answers. They preserved me from doing unnecessary work.

Here is a pure scheme / guile solution using lisp association lists (demoed by
using the box example from the extend tutorial). The target is, that the users 
of
our function may insert the arguments they really need (without having to deal
with those, they do not need) and that they may insert the arguments they want 
to
use in the order they prefer [The running version is attached as a file. Each
substantial portions of the code is distributed under the terms of the MIT
license. I assume that the function shall be interpreted on the lilypond 
level]: 

First, we should define the keys, we want to use (they must be communicated to 
the
users of our function)

#(define ka "k1")
#(define kb "k2")
#(define kc "k3")
#(define kd "k4")
#(define ke "k5")

Second, we should define the respective default values

#(define dva "blank") ; a filled string
#(define dvb "") ; an empty string
#(define dvc '()) ; a null value
#(define dvd "blank") ; 
#(define dve "") ; 

Third, we need a function - let us name it "assign" (you will understand in a
short time, why) - which takes a key, an associationlist (alist) and a default
value. If the alist contains any pair with the same key, then function shall
return the corresponding value, otherwise the given default value

#(define (assign keyValue assocList defaultValue)
  (string? list?)
  (let* ((localPair (assoc keyValue assocList)))
(if localPair (cdr localPair) defaultValue)
  )
)

Based on this pre-work, we can now define a markup function. In the beginning we
define the local parameter variables and let them be instantiated by our assign
function. Then we manipulate the given values in any way. And finally we return 
-
as a markup 'object' - a box containing the result of our manipulation:

#(define-markup-command (mybox layout props AL)
  (list?)
  (let*
( (la (assign ka AL dva))
  (lb (assign kb AL dvb))
  (lc (assign kc AL dvc))
  (ld (assign kd AL dvd))
  (le (assign ke AL dve))
  (lresult "result")
)
;  because we used an empty list (nil) as default value
(if (eq? lc '()) (set! lc ""))
; our 'manupilation' is norhing else but a concatenation ;-)
(set! lresult (string-append la lb lc ld le))

(interpret-markup layout props
  #{
\markup \box { #lresult }
  #}
)
   )
 )  

This function can be called in any markup context like

\markup \mybox #'(("k5" . "V5")("k1" . "V1"))

The result is a box containing the text "V1blankV5": V1 is given by the second
(sic!) argument - the values of the possible keys k2 and k3 are ignored, because
their default values are "" and an empty list = null - the blank is default 
value
of the unused key k4, and V5 is given by the first (sic!) argument.


best regards Karsten


-- 
  Karsten Reincke/\/\   (+49|0) 170 / 927 78 57
 Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
60431 Frankfurt a.M.  \/http://www.fodina.de/kr/

\version "2.18.2"

% A pure scheme / guile solution to define a LilyPond markup
% command with a variable list of arguments by using a
% technique of lisp scheme / guile called association lists 
% (demoed by using the box example from the extend tutorial). 

% The target is, that the users of the function may insert 
% the arguments they really need (without having to deal with 
% those, they do not need) and that they may insert the arguments
% they want to use in the order they prefer 

% feel free to adopt this example under the following terms:

% Copyright 2019 Karsten Reincke, Frankfurt

% Permission is hereby granted, free of charge, to any person 
% obtaining a copy of this software and associated documentation 
% files (the "Software"), to deal in the Software without 
% restriction, including without limitation the rights to use, 
% copy, modify, merge, publish, distribute, sublicense, and/or sell 
% copies of the Software, and to permit persons to whom the 
% Software is furnished to do so, subject to the following conditions:

% The above copyright notice and this permission notice shall be 
% included in all copies or substantial portions of the Software.

% THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
% EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES 
% OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
% NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 
% HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
% WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
% FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE 
% OR OTHER DEALINGS IN THE SOFTWARE.
 
% 1) 

Re: Fermata with text

2019-11-04 Thread Simon Albrecht

On 04.11.19 15:58, Andrew Bernard wrote:
What is the best way to create some sort of command or function to 
make a fermata with arbitrary text above, passed as a parameter?


See attached image for example. I have many of these, with variable 
text, and it would be great to streamline this, especially when I have 
to offset the position for various reasons.



How about this for a start?

\version "2.19.83"

fermataWithMarkup =
#(define-event-function (mrkp) (markup?)
   #{ ^\markup\center-column { $mrkp \musicglyph #"scripts.ufermata" } #})

{ 1\fermataWithMarkup "2" }

Best, Simon




Fermata with text

2019-11-04 Thread Andrew Bernard
What is the best way to create some sort of command or function to make a
fermata with arbitrary text above, passed as a parameter?

See attached image for example. I have many of these, with variable text,
and it would be great to streamline this, especially when I have to offset
the position for various reasons.

Andrew


Re: Scoped variables

2019-11-04 Thread Kieren MacMillan
Hi Peter,

> If a publisher wanted to collect Mr. Lanfear's string quartets (assuming that 
> he has written more than one) into a single volume, the Lilypond code would 
> have to be changed to rename all of the variables to something like QiIViolinI

In the engraving of my larger works (operas, musicals, multi-movement concert 
works, etc.), I’ve done exactly that. It’s only a small bit of extra effort.

> Now you can have a directory/file structure like:
> 
> Book
>   Book.ly
>   Quartet1
> Movement1
>   Score.ly
>   Violin1.ly
>   ...
> Movement2
>   Score.ly
>  
> etc.

Have you looked at Jan-Peter’s templating system (cf. 
http://lilypondblog.org/2014/07/trees-music-and-lilypond/ and other links)? I 
think it does exactly what you’re talking about.

Hope that helps!
Kieren.





kierencom
‣ email: kieren...@sympatico.ca
‣ phone: (416) 763-3984




Re: Scoped variables

2019-11-04 Thread Jan-Peter Voigt
Peter,

in the article Kieren mentioned, I tried to summarize some thoughts
around the multi-movement issue and some more.
You can find the corresponding templating engine at:
https://github.com/openlilylib/lalily-templates

That framework does a lot to do things automagically. But probably this
is too much for your needs. So one key point is that a template is
basically a music-function. If one defines variables like timothy proposed:

I.violinI = { ... }
I.violinII = { ... }
II.violinI = { ... }
II.violinII = { ... }

and defines a music-function

TwoVlns = #(define-music-function (mvt)(list?)
 #{
   <<
 \new Staff { $(assoc-get 'violinI mvt) }
 \new Staff { $(assoc-get 'violinII mvt) }
   >>
 #})

the music can instantiated like the following:

\score {
\TwoVlns #I
}
\score {
\TwoVlns #II
}

In the framework are functions defined for storing and getting music
that prevent a failure if some music is not defined (yet), but logs a
warning about missing music.

So if you have questions don't hesitate to contact me!

Best regards
Jan-Peter


Am 04.11.19 um 13:03 schrieb Peter Toye:
> Kieren,
>
> That looks great at a first skim-through. Thanks.
>
> Best regards,
>
> Peter
> mailto:lilyp...@ptoye.com
> www.ptoye.com 
>
> -
> Monday, November 4, 2019, 11:06:55 AM, Kieren MacMillan wrote:
>
> *> Hi Peter,
>
>>> If a publisher wanted to collect Mr. Lanfear's string quartets (assuming 
>>> that he has written more than one) into a single volume, the Lilypond code 
>>> would have to be changed to rename all of the variables to something like 
>>> QiIViolinI
>
>> In the engraving of my larger works (operas,
>> musicals, multi-movement concert works, etc.),
>> I’ve done exactly that. It’s only a small bit of extra effort.
>
>>> Now you can have a directory/file structure like:
>
>>> Book
>>>   Book.ly
>>>   Quartet1
>>>     Movement1
>>>       Score.ly
>>>       Violin1.ly
>>>       ...
>>>     Movement2
>>>       Score.ly
>>>      
>>> etc.
>
>> Have you looked at Jan-Peter’s templating
>> system (cf.
> *> http://lilypondblog.org/2014/07/trees-music-and-lilypond/
> 
> *> and other links)? I think it does exactly what you’re talking about.
>
>> Hope that helps!
>> Kieren.
>



Re: Scoped variables

2019-11-04 Thread Peter Toye
Kieren,

That looks great at a first skim-through. Thanks.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Monday, November 4, 2019, 11:06:55 AM, Kieren MacMillan wrote:

> Hi Peter,

>> If a publisher wanted to collect Mr. Lanfear's string quartets (assuming 
>> that he has written more than one) into a single volume, the Lilypond code 
>> would have to be changed to rename all of the variables to something like 
>> QiIViolinI

> In the engraving of my larger works (operas,
> musicals, multi-movement concert works, etc.),
> I’ve done exactly that. It’s only a small bit of extra effort.

>> Now you can have a directory/file structure like:

>> Book
>>   Book.ly
>>   Quartet1
>> Movement1
>>   Score.ly
>>   Violin1.ly
>>   ...
>> Movement2
>>   Score.ly
>>  
>> etc.

> Have you looked at Jan-Peter’s templating
> system (cf.
> http://lilypondblog.org/2014/07/trees-music-and-lilypond/
> and other links)? I think it does exactly what you’re talking about.

> Hope that helps!
> Kieren.



> 

> kierencom
> ‣ email: kieren...@sympatico.ca
> ‣ phone: (416) 763-3984

Re: Scoped variables

2019-11-04 Thread Peter Toye
On further consideration I think that Timothy Lanfear has, probably 
inadvertently, made my point for me.

If a publisher wanted to collect Mr. Lanfear's string quartets (assuming that 
he has written more than one) into a single volume, the Lilypond code would 
have to be changed to rename all of the variables to something like QiIViolinI 
(using Roman numerals to keep to the published convention of alphabetic 
characters only - I'm surprised that Mr. Lanfear's version works at all). Using 
my idea, and assuming that the variables were defined within the score, noting 
has to change apart from the book and possibly bookpart sections. Much easier 
and less error-prone. Also, if each staff's content is in its own file in the 
same directory as its score, the same code will serve for all movements:
  \score {
  \include "ViolinI.ly"
  \include "ViolinII.ly"
  \include "Viola.ly"
  \include "Cello.ly"
  }

Now you can have a directory/file structure like:

Book
  Book.ly
  Quartet1
Movement1
  Score.ly
  Violin1.ly
  ...
Movement2
  Score.ly
  
etc.  

I would offer to help with the programming, but I gave up professional 
programming many years ago. My last contact with Lisp was at university in the 
late 1960s.  I realise that this would not be a trivial job.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, November 3, 2019, 2:24:10 PM, David Kastrup wrote:

> Peter Toye  writes:

>> Is there a case for introducing scoped variables into Lilypond? 

>> As I understand it (please correct me if I'm wrong), variables have to be 
>> declared at the top of the document, before any music expression. I'm trying 
>> to work on a document with many different scores, each if which is in its 
>> own file. According to what I gather is best practice I use variables to 
>> hold the basic music text: one variable for each staff. When engraving each 
>> individual score, I need to put its variable declarations at the head of its 
>> file. But when I want to gather them all together into a book or bookpart, 
>> this doesn't work, so each score has to be edited to remove the definitions.

>> One way round this would be to allow Lilypond variables to be defined
>> within bookparts and/or scores, and to give them a scope confined to
>> that section. See the following MNWE.

> So what happens with

> bla = c'
> sc = \score { \bla }

> \book {
>   bla = f'
>   \sc
> }

> There are similar considerations for defining and using bookparts
> outside of books: basically the question is
> what scopes you even want to
> be talking about, lexical or dynamical, and how the two would be
> supposed to interact.