Re: [Scheme coding] turning a list into a markup/string

[Urs Liska]

Am Dienstag, den 21.01.2020, 20:11 -0500 schrieb Kieren MacMillan:
> or the life of me, I can’t quite figure out where exactly such a
> construct would appear in the code. Everywhere I try throws
> [different] errors. =(

I can promise you, it will be that way for a very long time.
But I can also promise you that at some point (and if you continue at
that pace that may be rather sooner than later) the errors will stop
scaring you and rather point you in the right direction.

Remember when Mike coded the original function for you? He typed
something in to express an idea - and I think *every* such attempt
failed on first try. However, the error message made it immediately
clear to him where the mistake would be, he counted parenthesis and
directly fixed it.

I'm sure https://scheme-book.ursliska.de/scheme/expressions.html will
not give you any new information, but it may be worth reviewing it. The
topic was the "click" moment for me ...
Also, https://scheme-book.ursliska.de/scheme/concepts.html and
following/below might contain useful perspectives for you.

HTH
Urs

Re: Prall in a staff space

[Tyler Mitchell]

On Fri, Feb 15, 2019 at 12:58:03AM -0800, Tyler Mitchell wrote:
> I am attempting to put a prall within the staff, in spaces only,
> similar to how a tenuto works.
>
> [...]
> 
> How does LilyPond know to place the tenuto within the staff, but
> the prall outside of it? And how does it determine that the tenuto
> should be placed in a space, but the prall should be placed on a
> line?

I finally picked this up nearly a year later. After a bit of
reading of scm/script.scm I could see the differences between the
various articulations. The 'tenuto' definition itself was
particularly helpful.

Setting the 'quantize-position' property seems to do the trick,
combined with a reduction of padding, and a font-size that keeps
the glyph from touching the ledger lines.

This thread helped me to figure out how to define a new
articulation:


http://lilypond.1069038.n5.nabble.com/Creating-new-articulation-adding-to-an-internal-alist-td172689.html

The end result:

\version "2.19.83"
\layout {
  \context {
\Score
scriptDefinitions = #(append default-script-alist
   (list
`("quilisma"
   . (
   (script-stencil . (feta . ("prall" . 
"prall")))
   (font-size . -2.5)
   (padding . -0.05)
   (avoid-slur . inside)
   (quantize-position . #t)
   (direction . ,UP)
  }
  \context { \Staff \remove Time_signature_engraver }
}
quilisma = #(make-articulation "quilisma")
\score {
  {
\cadenzaOn \override Stem.length = #0 \slurDown \stemUp
g'^-( a'-\quilisma b')
a'^-( b'-\quilisma c'')
  }
}

Cheers,
Tyler

Re: [Scheme coding] turning a list into a markup/string

[Aaron Hill]

On 2020-01-21 7:02 pm, Kieren MacMillan wrote:

HOLD THE PRESSES!!

I think I have it:

  SNIPPET BEGINS
\version "2.19.83"

some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }

#(define-markup-list-command (diffints layout props mus) (ly:music?)
   (interpret-markup-list layout props
 (map (lambda (d) (string-append (if (positive? d) "+" "")
(number->string d)))
   (let ((muspst (map ly:pitch-semitones (music-pitches mus
 (map - (cdr muspst) muspst)

\markup \line \with-color #red \diffints #some-music
\markup \line  \with-color #red \diffints ##{ c' d' e' c' #}
  SNIPPET ENDS

Comments and code critique appreciated.


Instead of string-append and number->string, try (format #f "~@d" d).

  ~d formats an integer as a decimal value
   @ includes "+" for positive values

One caveat is it formats zero as "+0".

Perhaps:  (lambda (d) (if (zero? d) "0" (format #f "~@d" d)))


-- Aaron Hill

Weird behavior for after-line-breaking

[Paolo Prete]

Hello,

please consider the following snippet. The procedure called at
after-line-breaking doesn't do *anything*,  but a weird space is added
between staves.
If you remove the \override line OR the \tuplet, this doesn't happen
Why?? Is there a fix for this?
The error happens for both 2.18 and 2.19

Thanks!

%

#(define (afterLineBreakingfoo grob)
(let* ((origsten (ly:grob-property grob 'stencil)))
  (display "foobar")))

upper = {

\override TupletBracket.after-line-breaking = #(lambda (grob)
(afterLineBreakingfoo grob))
\tuplet 3/2 {c'4 \change Staff = "lower" c'' g''}

} %end upper



lower = { s4 s s}

\score {
  \new PianoStaff <<
\new Staff = "upper" \upper
\new Staff = "lower" \lower
  >>
  \layout { }
  \midi { }
}

%

turning a markuplist into a chain of [individual] markups or strings

[Kieren MacMillan]

Hi all,

Is there a way to turn a markuplist into individual markups or strings?

I have a markuplist of lyrics

(a b c)

and I’d like to turn that into a chain of markups

   \lyricmode { \markup a \markup b \markup c }

or strings

\lyricmode { "a" "b" "c" }

What function do I use?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

HOLD THE PRESSES!!

I think I have it:

  SNIPPET BEGINS
\version "2.19.83"

some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }

#(define-markup-list-command (diffints layout props mus) (ly:music?)
   (interpret-markup-list layout props
 (map (lambda (d) (string-append (if (positive? d) "+" "") (number->string 
d)))
   (let ((muspst (map ly:pitch-semitones (music-pitches mus
 (map - (cdr muspst) muspst)

\markup \line \with-color #red \diffints #some-music
\markup \line  \with-color #red \diffints ##{ c' d' e' c' #}
  SNIPPET ENDS

Comments and code critique appreciated.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi again (too soon?),

I’m trying to make the positive intervals have a + in front of them.

Q1. My intuition tells me I need to use a lambda function with append. Does 
that seem like a reasonable approach?

Regardless, assume for argument’s sake that it is… For the life of me, I can’t 
quite figure out where exactly such a construct would appear in the code. 
Everywhere I try throws [different] errors. =(

The following doesn’t throw an error, and I know why, and I know why it outputs 
what it does — so I’m not quite as stupid as I feel (and maybe appear?):

%%%
\version "2.19.83"
some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }
#(display
 ((lambda (d) (append d d))
  (map number->string
(let ((muspst (map ly:pitch-semitones (music-pitches some-music
  (map - (cdr muspst) muspst)
%%%

So this leads to my real question:

Q2. What is a good way to change

#(display
  (map number->string
(let ((muspst (map ly:pitch-semitones (music-pitches some-music
  (map - (cdr muspst) muspst

so that it outputs

(+1 +1 -3 -1 -6 +1 +1 +3 -1 -1 -4)

?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> # goes into Scheme, and #{ goes into music mode then.
>
> Yes, that makes sense in retrospect.
>
>> If you write #{ then # goes into Scheme and Scheme has no idea what {
>> is supposed to be.
>> 
>
> And tells you so, in no uncertain terms.  ;)

Oh, that would be better than what I'd expect.  Which would rather be
throwing a tantrum and making a big mess.  But the first words of the
tantrum might still make some sense if you manage focusing on them.

>> I've not fundamentally changed LilyPond's design.
>
> Sorry… That was not meant to be a comment on your work

I didn't really take it to be.  It was just pointing out that I am more
of an improver than a designer.  Two days ago Han-Wen was looking over
my shoulder and pointed out helpfully where I wrote

   \override NoteHead.style = #'mensural

instead of

   \override NoteHead style = #'mensural

or possibly

   \override Notehead #'style = #'mensural

and it was really jarring for me to realise just how quietly I have been
treading.  The LilyPond Han-Wen has been familiar with will still answer
him in the accustomed manner.

In Stanisław Lem's "Pilot Pirx" series there is a story "Terminus" where
a repair robot hammering lead as a sealant does it repeating Morse
sequences of previous cosmonauts who perished in a catastrophe it was
part of, and Commander Pirx on a whim knocks some question into the
mindless sequences of the robot and gets responses.

> — just pointing out that Scheme is daunting enough to start learning
> without hearing that the main thing you’re planning to wrestle with
> (at least in the short term) is made up of "icky things".
>
>> I've not really had much of a wrestling match with markup and their
>> commands yet.
>
> Perhaps once I’m more comfortable with Scheme I can start to wrestle
> with them, and you can "tag in" when I’m pinned.

Let's see where we get when.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> # goes into Scheme, and #{ goes into music mode then.

Yes, that makes sense in retrospect.

> If you write #{ then # goes into Scheme and Scheme has no idea what { is 
> supposed to be.

And tells you so, in no uncertain terms.  ;)

> I've not fundamentally changed LilyPond's design.

Sorry… That was not meant to be a comment on your work — just pointing out that 
Scheme is daunting enough to start learning without hearing that the main thing 
you’re planning to wrestle with (at least in the short term) is made up of 
"icky things".

> I've not really had much of a wrestling match with markup and their commands 
> yet.

Perhaps once I’m more comfortable with Scheme I can start to wrestle with them, 
and you can "tag in" when I’m pinned.

Thanks so much for all your help!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Well, ##{ c' d' e' c' #} would work.
>
> In the "Nearly, But Not Quite There" category: I tried
>
>   #{ c' d' e' c' #}
>
> which, of course, failed. I didn’t think to prepend a second #.

# goes into Scheme, and #{ goes into music mode then.  If you write #{
then # goes into Scheme and Scheme has no idea what { is supposed to be.

>> Markups are icky things.
>
> That is, perhaps, not the best thing to admit to someone on the first
> rung of the "Learning To Program In Scheme For Lilypond" ladder…

I've not fundamentally changed LilyPond's design.  I streamlined and
generalised a lot of stuff where things appear to make a whole lot more
sense now and have quite less of a tendency to bleed internals all over
you if you poke them wrong.  But consistent and logical is not the same
as simple even though it helps, and I've not really had much of a
wrestling match with markup and their commands yet.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> Well, ##{ c' d' e' c' #} would work.

In the "Nearly, But Not Quite There" category: I tried

  #{ c' d' e' c' #}

which, of course, failed. I didn’t think to prepend a second #.

> Markups are icky things.

That is, perhaps, not the best thing to admit to someone on the first rung of 
the "Learning To Program In Scheme For Lilypond" ladder…

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Thomas Morley  writes:

> Am Di., 21. Jan. 2020 um 23:13 Uhr schrieb David Kastrup :
>>
>> Thomas Morley  writes:
>
>> > David, you remember my suggestion to generate that "General Code
>> > Reference" with an Index ... ?
>>
>> Yes, that may have helped.  But it may also have delivered a haystack.
>>
>> I think we probably need a "good programming" corpus, but the snippets
>> are supposed to be that.  Navigating them still is too hard.
>
> If you think of the "Snippets Manual" or the LSR, then I doubt they
> are best suited to what I think we need.
> Their snippets are too much targeted at delivering ready to use tools
> for actual typesetting work.
>
> As an example:
> music-map has the problem that you can't really stop it recursing
> deeper. One reason why you wrote map-some-music and for-some-music.
> Alas, I always need to get to their doc-strings again, to understand
> the differences and which one to use for which case.

Like in Scheme, map returns something, for doesn't.  I think that early
designs had more arguments, requiring even more doc-string lookup to get
them right.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Thomas Morley  writes:

> Am Di., 21. Jan. 2020 um 23:13 Uhr schrieb David Kastrup :
>>
>> Thomas Morley  writes:
>
>> > David, you remember my suggestion to generate that "General Code
>> > Reference" with an Index ... ?
>>
>> Yes, that may have helped.  But it may also have delivered a haystack.
>>
>> I think we probably need a "good programming" corpus, but the snippets
>> are supposed to be that.  Navigating them still is too hard.
>
> If you think of the "Snippets Manual" or the LSR, then I doubt they
> are best suited to what I think we need.
> Their snippets are too much targeted at delivering ready to use tools
> for actual typesetting work.
>
> As an example:
> music-map has the problem that you can't really stop it recursing
> deeper. One reason why you wrote map-some-music and for-some-music.
> Alas, I always need to get to their doc-strings again, to understand
> the differences and which one to use for which case.
> And ofcourse their docstrings are not in any manual, afaict.
>
> Sometimes I look in our regression-tests, which contains nice coding
> examples, but you can't expect average user to look there.
> And sometimes even the regression-test don't say anything, as an
> example for no info at all:
> $ git grep "ly:broadcast"
> lily/dispatcher-scheme.cc:LY_DEFINE (ly_broadcast, "ly:broadcast",
> scm/define-music-callbacks.scm:  (ly:broadcast
> (ly:context-event-source context)
>
> Leading to IR entry:
>
> Function: ly:broadcast disp ev
>   Send the stream event ev to the dispatcher disp.
>
> Which is ununderstandable without any context.

Yes.  The CG might have a bit of info there, but if it is there, it is
likely very sketchy and does not really help a lot.

> Cheers,
>   Harm

Well, to some degree my "why don't you use $x" kind of advice results
from having had to fight through the code base in order to be able to
refactor parts I had to fix into something I could understand.  So I
have bit of a semantic network in my head that may give me a hunch what
to grep for in order to tackle some class of problem.

That's pretty lousy as a way of getting information suited to the task.
I don't like the bus factor impact that makes me have.  Gives me a bad
conscience.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[Thomas Morley]

Am Di., 21. Jan. 2020 um 23:13 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:

> > David, you remember my suggestion to generate that "General Code
> > Reference" with an Index ... ?
>
> Yes, that may have helped.  But it may also have delivered a haystack.
>
> I think we probably need a "good programming" corpus, but the snippets
> are supposed to be that.  Navigating them still is too hard.

If you think of the "Snippets Manual" or the LSR, then I doubt they
are best suited to what I think we need.
Their snippets are too much targeted at delivering ready to use tools
for actual typesetting work.

As an example:
music-map has the problem that you can't really stop it recursing
deeper. One reason why you wrote map-some-music and for-some-music.
Alas, I always need to get to their doc-strings again, to understand
the differences and which one to use for which case.
And ofcourse their docstrings are not in any manual, afaict.

Sometimes I look in our regression-tests, which contains nice coding
examples, but you can't expect average user to look there.
And sometimes even the regression-test don't say anything, as an
example for no info at all:
$ git grep "ly:broadcast"
lily/dispatcher-scheme.cc:LY_DEFINE (ly_broadcast, "ly:broadcast",
scm/define-music-callbacks.scm:  (ly:broadcast
(ly:context-event-source context)

Leading to IR entry:

Function: ly:broadcast disp ev
  Send the stream event ev to the dispatcher disp.

Which is ununderstandable without any context.



Cheers,
  Harm

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> The line below it is a 2.21.0 feature that cannot be used from a
>> LilyPond for which we have an installer.
>
> Ah. Thanks. (Note: feature/version disconnection is another thing that
> caused my past Scheme efforts to stumble, leading to becoming
> discouraged in my efforts.)
>
>> I wasn't aware that the line above is problematic but I see how it
>> could.  Maybe write #some-music instead.
>
> That works great. Is there a similar fix for the next input line?
>
> \markup \right-column \with-color #red { \buzz { c' d' e' c' } }

Well, ##{ c' d' e' c' #} would work.  Basically, almost everything that
is not either a markup or markup list in 2.20 has to start with # .

And I am not sure that the second line will survive eternally: it's
discomfortingly close to markup list syntax and thus would be tricky to
implement once markup commands get more intelligent predicate
interpretation, like music functions do now.

It's conceivable when { gets read to check whether the predicate would
accept '() (the simplest markup list) and only get into music mode when
it doesn't.

Markups are icky things.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> The line below it is a 2.21.0 feature that cannot be used from a
> LilyPond for which we have an installer.

Ah. Thanks. (Note: feature/version disconnection is another thing that caused 
my past Scheme efforts to stumble, leading to becoming discouraged in my 
efforts.)

> I wasn't aware that the line above is problematic but I see how it
> could.  Maybe write #some-music instead.

That works great. Is there a similar fix for the next input line?

\markup \right-column \with-color #red { \buzz { c' d' e' c' } }

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> I am glacially slow for almost everything because I am ridiculously
>> afraid of wasting time doing something wrong.  That turns to work out
>> better for teaching than getting anything done myself.
>
> That may be the best two-sentence description of me I’ve ever read.  =)
>
>> And music-pitches is also convenient to know.
>
> That’s the main one that jumped out at me as "Well, if I had known
> about that one…!" (For the record: Harm used event-chord-pitches in
> his attempt at my problem, and it seemed a wonderfully magical start
> out of the gate, but we were ultimately unable to take it to the
> goal-line. Also, I mixed my sportsing metaphors in that sentence; oh
> well.)
>
> Am I correct that music-functions.scm is the best dust-covered
> repository of arcane knowledge in which one can find "music-pitches"
> and a description of what it does?

It's not really dust-covered since it is frequently changed, but since
most of its contents continue to scroll by programmers occasionally,
there is some chance that much of it has had a chance to converge to a
reasonably smooth state.

Which does not mean that all of that is well-documented.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Thomas Morley  writes:

> Hi Kieren, hi David,
>
> Am Di., 21. Jan. 2020 um 22:45 Uhr schrieb David Kastrup :
>
>> And music-pitches is also convenient to know.
>
> David, you remember my suggestion to generate that "General Code
> Reference" with an Index ... ?

Yes, that may have helped.  But it may also have delivered a haystack.

I think we probably need a "good programming" corpus, but the snippets
are supposed to be that.  Navigating them still is too hard.

> Kieren showed me the problem in Salzburg and I suggested quick'n dirty
> event-chord-pitches, music-pitches feels a bit cleaner, though.

It's newer I think.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Of course you can also do
>> #(display (let ((res (map ly:pitch-semitones (music-pitches some-music
>> (map - (cdr res) res)))
>> 
>> Namely first convert to semitones and then do the difference.
>
> Ah! Perhaps I was on the right path with the first part of what I gave
> to Mike (which used the ly:pitch-semitones function).
>
>> #(display (let ((res (map ly:pitch-semitones (music-pitches some-music
>> (map - (cdr res) res)))
>> 
>> #(define-markup-list-command (buzz layout props mus) (ly:music?)
>>  (interpret-markup-list layout props
>>(map number->string
>>  (let ((res (map ly:pitch-semitones (music-pitches mus
>>(map - (cdr res) res)
>> 
>> \markup \right-column \with-color #red { \buzz \some-music \vspace #3 }
>> \markup \right-column \with-color #red { \buzz { c' d' e' c' } }
>
> I get errors when I try to compile that:
>
>  error: syntax error, unexpected MUSIC_IDENTIFIER
> \markup \right-column \with-color #red { \buzz 
>\some-music \vspace #3 }
> …
>
> Am I missing something? I cut-and-paste your code [from email into 
> Frescobaldi] several times…

The line below it is a 2.21.0 feature that cannot be used from a
LilyPond for which we have an installer.

I wasn't aware that the line above is problematic but I see how it
could.  Maybe write #some-music instead.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> I am glacially slow for almost everything because I am ridiculously
> afraid of wasting time doing something wrong.  That turns to work out
> better for teaching than getting anything done myself.

That may be the best two-sentence description of me I’ve ever read.  =)

> And music-pitches is also convenient to know.

That’s the main one that jumped out at me as "Well, if I had known about that 
one…!" (For the record: Harm used event-chord-pitches in his attempt at my 
problem, and it seemed a wonderfully magical start out of the gate, but we were 
ultimately unable to take it to the goal-line. Also, I mixed my sportsing 
metaphors in that sentence; oh well.)

Am I correct that music-functions.scm is the best dust-covered repository of 
arcane knowledge in which one can find "music-pitches" and a description of 
what it does?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> Of course you can also do
> #(display (let ((res (map ly:pitch-semitones (music-pitches some-music
> (map - (cdr res) res)))
> 
> Namely first convert to semitones and then do the difference.

Ah! Perhaps I was on the right path with the first part of what I gave to Mike 
(which used the ly:pitch-semitones function).

> #(display (let ((res (map ly:pitch-semitones (music-pitches some-music
>  (map - (cdr res) res)))
> 
> #(define-markup-list-command (buzz layout props mus) (ly:music?)
>  (interpret-markup-list layout props
>(map number->string
>  (let ((res (map ly:pitch-semitones (music-pitches mus
>(map - (cdr res) res)
> 
> \markup \right-column \with-color #red { \buzz \some-music \vspace #3 }
> \markup \right-column \with-color #red { \buzz { c' d' e' c' } }

I get errors when I try to compile that:

 error: syntax error, unexpected MUSIC_IDENTIFIER
\markup \right-column \with-color #red { \buzz 
   \some-music \vspace #3 }
…

Am I missing something? I cut-and-paste your code [from email into Frescobaldi] 
several times…

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[Thomas Morley]

Hi Kieren, hi David,

Am Di., 21. Jan. 2020 um 22:45 Uhr schrieb David Kastrup :

> And music-pitches is also convenient to know.

David, you remember my suggestion to generate that "General Code
Reference" with an Index ... ?
Kieren showed me the problem in Salzburg and I suggested quick'n dirty
event-chord-pitches, music-pitches feels a bit cleaner, though.

Cheers,
  Harm

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Mike is a genius that will reinvent three wheels
>> in the time it takes to learn about one.
>
> That might be a little bit of the pot calling the kettle black…?  ;)

I am glacially slow for almost everything because I am ridiculously
afraid of wasting time doing something wrong.  That turns to work out
better for teaching than getting anything done myself.

> Oh! So much to learn in there. Thank you.
>
> Any idea which (if either) is more expensive, yours or Mike’s (well,
> {Mike+David N.}’s)?

Clearly Mike's, but you are not likely to be able to notice a difference
for most applications.  Either will be quite faster than parsing the
music in the first place.

>> I find it great that you understand everything that Mike does here
>
> In fact, I may have sent him down this particular path by suggesting
> that we do essentially what I would do with a list of numbers in
> maxima:
>
>diff(nums) := rest(nums,1) - rest(nums,-1)
>
> He probably just took that idea and ran with it to the [Lily-Scheme]
> goal-line.

That may be.  Running is so little effort to him that he can just take a
route and follow it.

>> you are well-prepared to figure out what I am doing, and what may
>> be hidden away in some of the internals of the read-made tools I use.
>
> What tools are those exactly?

The main one is

  (map - (cdr res) res)

which relies on map (more exactly the (srfi srfi-1) version of it that
LilyPond input may depend on) working with a function taking more than
one argument, and not minding if the corresponding lists have different
length (it just runs until the shortest is exhausted).

And music-pitches is also convenient to know.

>> it is seminal for me to tackle problems with the simplest means I can
>> manage.
>
> I live (and die?) by the belief that "Every elegant question has an
> elegant answer".  =)

I guess in this case the answer is more blunt than elegant.  It refuses
to acknowledge the refinement of the problem.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

A few annotations:

David Kastrup  writes:

> Kieren MacMillan  writes:
>
>> As the next step, I want to turn this into a function and display the
>> result in a markup. Result: I spend several hours searching
>> documentation, trying different functions, and getting one (or more!)
>> errors per attempt, but no success. I literally cannot figure out how
>> to turn this into a string, save hand-coding a recursion/map that
>> takes each element of the list and appends it onto a string… and if
>> that’s actually the "correct"/"best" way to do it, then I deeply
>> question my desire to code in Scheme+Lilypond at all.  ;)
>
> You are letting yourself getting infected by Mike's coding style.  Mike
> is a genius that will reinvent three wheels in the time it takes to
> learn about one.
>
> Try the following:
>
> %%%  SNIPPET BEGINS
> \version "2.19.83"
>
> some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }
>
> #(display (let ((res (music-pitches some-music)))
>  (map ly:pitch-semitones (map ly:pitch-diff (cdr res) res

Of course you can also do
#(display (let ((res (map ly:pitch-semitones (music-pitches some-music
 (map - (cdr res) res)))

Namely first convert to semitones and then do the difference.

> buzz =
> #(define-scheme-function (mus) (ly:music?)
>   (map number->string
>(let ((res (music-pitches mus)))
> (map ly:pitch-semitones (map ly:pitch-diff (cdr res) res)
>
> \markup \right-column \with-color #red { \buzz \some-music }
>
> %%%  SNIPPET ENDS

You may want to do this as a markup list command instead.  Combining
both suggestions:

%%%  SNIPPET BEGINS
\version "2.19.83"

some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }

#(display (let ((res (map ly:pitch-semitones (music-pitches some-music
	   (map - (cdr res) res)))

#(define-markup-list-command (buzz layout props mus) (ly:music?)
  (interpret-markup-list layout props
(map number->string
  (let ((res (map ly:pitch-semitones (music-pitches mus
(map - (cdr res) res)


\markup \right-column \with-color #red { \buzz \some-music \vspace #3 }
\markup \right-column \with-color #red { \buzz { c' d' e' c' } }

%%%  SNIPPET ENDS

>> So someone please tell me what simple thing I’m missing here. In the
>> worst case scenario, you just give me a fish and I can eat for a
>> little while longer (read: not give up); best case senario, you teach
>> me (and anyone else reading this list, now or in the future in the
>> future) how to fish.

As musicians, we know that simplicity in execution is the way to go, but
getting there takes practice.  Being able to do it the hard way is the
first step.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> Mike is a genius that will reinvent three wheels
> in the time it takes to learn about one.

That might be a little bit of the pot calling the kettle black…?  ;)

> Try the following:
> 
> %%%  SNIPPET BEGINS
> \version "2.19.83"
> 
> some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }
> 
> #(display (let ((res (music-pitches some-music)))
>  (map ly:pitch-semitones (map ly:pitch-diff (cdr res) res
> 
> buzz =
> #(define-scheme-function (mus) (ly:music?)
>  (map number->string
>   (let ((res (music-pitches mus)))
>(map ly:pitch-semitones (map ly:pitch-diff (cdr res) res)
> 
> \markup \right-column \with-color #red { \buzz \some-music }
> 
> %%%  SNIPPET ENDS

Oh! So much to learn in there. Thank you.

Any idea which (if either) is more expensive, yours or Mike’s (well, 
{Mike+David N.}’s)?

> For teaching how to fish from scratch, Mike's demonstration may be 
> better-suited.
> My solution is more a demonstration of what you can do
> when you know your way around the fishing grounds.

There are definitely multiple plateaus in every learning mountain climb…

> I find it great that you understand everything that Mike does here

In fact, I may have sent him down this particular path by suggesting that we do 
essentially what I would do with a list of numbers in maxima:

   diff(nums) := rest(nums,1) - rest(nums,-1)

He probably just took that idea and ran with it to the [Lily-Scheme] goal-line.

> you are well-prepared to figure out what I am doing, and what may
> be hidden away in some of the internals of the read-made tools I use.

What tools are those exactly?

> it is seminal for me to tackle problems with the simplest means I can manage.

I live (and die?) by the belief that "Every elegant question has an elegant 
answer".  =)

Thanks!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: [Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi David,

> \version "2.19"
> 
> some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }
> 
> #(define (zip . xss) (apply map list xss))
> 
> #(define-markup-command (pitch-info layout props args) (ly:music?)
>   (let* ((res (map
>(lambda (foo) (ly:pitch-semitones (ly:music-property
> foo 'pitch)))
>(ly:music-property some-music 'elements)))
>  (top (reverse (cdr (reverse res
>  (bottom (cdr res))
>  (ls (map
>   (lambda (h) (- (cadr h) (car h)))
>   (zip top bottom)))
>  (markups (map
>(lambda (elt) (make-simple-markup (number->string elt)))
>ls)))
> (interpret-markup layout props #{ \markup \line #markups #})))
> 
> \markup \pitch-info #some-music

Okay, that’s basically what I was going to do "in the worst case situation".

1. I *was* hoping there was a "list->markup" macro/function somewhere…  ;)

2. I have to admit that the final "build", i.e. 

> (markups (map
>(lambda (elt) (make-simple-markup (number->string elt)))
>ls)))
> (interpret-markup layout props #{ \markup \line #markups #})))

is more compact than I had feared'; is usually true of the [good] Scheme code I 
come across.

3. I’m pretty sure I would have taken quite a while to find my way to 
"make-simple-markup" and "interpret-markup" — thanks for showing me that part 
of the fishing tackle box!

> Hope this gets you started with whatever dodecaphonic plans you have...

=)

This dodecaphonic stuff is just an offshoot of one of my Salzburg sessions, 
which I’m using (because of its familiarity and proximity) as a way to 
jumpstart my Scheme learning process.

Don’t worry: I’m not [currently] planning to rebuild Abjad in Scheme.  ;)

Thanks!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Detecting double accidentals

[David Kastrup]

SK  writes:

> Hello,
>
> I wrote a script for generating music theory worksheets for school. One
> feature is the generation of chords that should be named by the students.
> The way this function works is by simply transposing some predefined chords
> to a new randomly generated root. To keep the difficulty controllable, I
> would like to filter out double accidentals in some cases, e.g. to not
> produce an augmented F# chord.
> Does anybody know about a way to check in scheme if music has double
> accidentals, or can think of another smart way of doing this?
>
> I would not want to define all possible chords manually, and I think that
> filtering out certain root notes is quite complex, too, if you just want to
> avoid double accidentals.
>
> Kind regards!

#(define (has-doubles mus)
   (any (lambda (p) (not (< -1 (ly:pitch-alteration p) 1)))
 (music-pitches mus)))

#(display (map has-doubles
  (list #{ c'4 d' e' fis' g' a' b' #}
#{ cisis'4 d' e' #})))

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
> Here’s a perfect example of why I keep stumbling (and stopping) when trying 
> to learn Scheme+Lilypond…  =\
>
> With Mike S’s help — read: he did it all, actually! (though I fully 
> understand every part of the code) — I have the following:
>
> %%%  SNIPPET BEGINS
> \version "2.19.83"
>
> some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }
>
> #(define (zip . xss) (apply map list xss))
>
> #(display
>  (let* ((res (map
>   (lambda (foo) (ly:pitch-semitones (ly:music-property foo 
> 'pitch)))
>   (ly:music-property  some-music 'elements)))
> (top (reverse (cdr (reverse res
> (bottom (cdr res)))
>(map (lambda (h) (- (cadr h) (car h))) (zip top bottom)))
>  )
> %%%  SNIPPET ENDS
>
> Works great. Just what I want at this stage in the (multi-stage) procedure 
> I’m trying to code.
>
> As the next step, I want to turn this into a function and display the
> result in a markup. Result: I spend several hours searching
> documentation, trying different functions, and getting one (or more!)
> errors per attempt, but no success. I literally cannot figure out how
> to turn this into a string, save hand-coding a recursion/map that
> takes each element of the list and appends it onto a string… and if
> that’s actually the "correct"/"best" way to do it, then I deeply
> question my desire to code in Scheme+Lilypond at all.  ;)

You are letting yourself getting infected by Mike's coding style.  Mike
is a genius that will reinvent three wheels in the time it takes to
learn about one.

Try the following:

%%%  SNIPPET BEGINS
\version "2.19.83"

some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }

#(display (let ((res (music-pitches some-music)))
	   (map ly:pitch-semitones (map ly:pitch-diff (cdr res) res

buzz =
#(define-scheme-function (mus) (ly:music?)
  (map number->string
   (let ((res (music-pitches mus)))
(map ly:pitch-semitones (map ly:pitch-diff (cdr res) res)

\markup \right-column \with-color #red { \buzz \some-music }

%%%  SNIPPET ENDS

> So someone please tell me what simple thing I’m missing here. In the
> worst case scenario, you just give me a fish and I can eat for a
> little while longer (read: not give up); best case senario, you teach
> me (and anyone else reading this list, now or in the future in the
> future) how to fish.

For teaching how to fish from scratch, Mike's demonstration may be
better-suited.  My solution is more a demonstration of what you can do
when you know your way around the fishing grounds.  I find it great that
you understand everything that Mike does here: that's really involved
stuff, and understanding it means that you are well-prepared to figure
out what I am doing, and what may be hidden away in some of the
internals of the read-made tools I use.

At my advanced age, I tend to run into "eyes glaze over" territory
pretty fast, so it is seminal for me to tackle problems with the
simplest means I can manage.

-- 
David Kastrup

Re: [Scheme coding] turning a list into a markup/string

[David Nalesnik]

Hi Kieren!

On Tue, Jan 21, 2020 at 1:52 PM Kieren MacMillan
 wrote:
>
> Hi all,
>
> Here’s a perfect example of why I keep stumbling (and stopping) when trying 
> to learn Scheme+Lilypond…  =\
>
> With Mike S’s help — read: he did it all, actually! (though I fully 
> understand every part of the code) — I have the following:
>
> %%%  SNIPPET BEGINS
> \version "2.19.83"
>
> some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }
>
> #(define (zip . xss) (apply map list xss))
>
> #(display
>  (let* ((res (map
>   (lambda (foo) (ly:pitch-semitones (ly:music-property foo 
> 'pitch)))
>   (ly:music-property  some-music 'elements)))
> (top (reverse (cdr (reverse res
> (bottom (cdr res)))
>(map (lambda (h) (- (cadr h) (car h))) (zip top bottom)))
>  )
> %%%  SNIPPET ENDS
>
> Works great. Just what I want at this stage in the (multi-stage) procedure 
> I’m trying to code.
>
> As the next step, I want to turn this into a function and display the result 
> in a markup. Result: I spend several hours searching documentation, trying 
> different functions, and getting one (or more!) errors per attempt, but no 
> success. I literally cannot figure out how to turn this into a string, save 
> hand-coding a recursion/map that takes each element of the list and appends 
> it onto a string… and if that’s actually the "correct"/"best" way to do it, 
> then I deeply question my desire to code in Scheme+Lilypond at all.  ;)
>
> So someone please tell me what simple thing I’m missing here. In the worst 
> case scenario, you just give me a fish and I can eat for a little while 
> longer (read: not give up); best case senario, you teach me (and anyone else 
> reading this list, now or in the future in the future) how to fish.
>
> Thanks,
> Kieren.

Try this:

%%  SNIPPET BEGINS
\version "2.19"

some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }

#(define (zip . xss) (apply map list xss))

#(define-markup-command (pitch-info layout props args) (ly:music?)
   (let* ((res (map
(lambda (foo) (ly:pitch-semitones (ly:music-property
foo 'pitch)))
(ly:music-property some-music 'elements)))
  (top (reverse (cdr (reverse res
  (bottom (cdr res))
  (ls (map
   (lambda (h) (- (cadr h) (car h)))
   (zip top bottom)))
  (markups (map
(lambda (elt) (make-simple-markup (number->string elt)))
ls)))
 (interpret-markup layout props #{ \markup \line #markups #})))

\markup \pitch-info #some-music
%%%  SNIPPET ENDS

Hope this gets you started with whatever dodecaphonic plans you have...

David

Detecting double accidentals

[SK]

Hello,

I wrote a script for generating music theory worksheets for school. One
feature is the generation of chords that should be named by the students.
The way this function works is by simply transposing some predefined chords
to a new randomly generated root. To keep the difficulty controllable, I
would like to filter out double accidentals in some cases, e.g. to not
produce an augmented F# chord.
Does anybody know about a way to check in scheme if music has double
accidentals, or can think of another smart way of doing this?

I would not want to define all possible chords manually, and I think that
filtering out certain root notes is quite complex, too, if you just want to
avoid double accidentals.

Kind regards!

Re: license question

[Arle Lommel]

> From: David Nalesnik  >
> Subject: license question
> 
> Hi all,
> 
> I have a question concerning the GPL.  Is it permissible for an app
> under a GPL-incompatible license to provide output in LilyPond code?
> For example, could Finale provide a Finale->LilyPond converter even
> though the mechanics are shrouded in mystery?
> 
> Thanks,
> David



I am not a lawyer, but this question closely aligns with issues related to 
those currently before the US Supreme Court in Google v. Oracle.

With that preamble, here is my understanding:

A converter is not reproducing code. No license from the GLP project applies to 
it because you are not reproducing licensed code. The converter produces a 
textual representation of music, and this representation itself is not subject 
to the GPL terms. *Anything* can generate that code because no copyright 
applies to a method, which is what an abstract process for going from something 
like g4^. to a graphic representation of a staccato G quarter note is.

Also note that if someone wanted to write a clean-room interpreter or converter 
for Lilypond code that did not use any GPL code, that should be legal as well, 
because methods are not subject to copyright (although code is) and a Lilypond 
input file is a call to methods, not to code (although those methods are 
instantiated in code).

So there is really no reason you couldn’t create a Finale>Lilypond converter. 
The license of Lilypond itself wouldn’t matter to you in this regard because 
you wouldn’t be reproducing GPL code. You could in turn choose any license for 
the code of your converter.

-Arle

[Scheme coding] turning a list into a markup/string

[Kieren MacMillan]

Hi all,

Here’s a perfect example of why I keep stumbling (and stopping) when trying to 
learn Scheme+Lilypond…  =\

With Mike S’s help — read: he did it all, actually! (though I fully understand 
every part of the code) — I have the following:

%%%  SNIPPET BEGINS
\version "2.19.83"

some-music = { a'4 bes' b' aes' g' cis' d' ees' fis' f' e' c' }

#(define (zip . xss) (apply map list xss))

#(display
 (let* ((res (map
  (lambda (foo) (ly:pitch-semitones (ly:music-property foo 'pitch)))
  (ly:music-property  some-music 'elements)))
(top (reverse (cdr (reverse res
(bottom (cdr res)))
   (map (lambda (h) (- (cadr h) (car h))) (zip top bottom)))
 )
%%%  SNIPPET ENDS

Works great. Just what I want at this stage in the (multi-stage) procedure I’m 
trying to code.

As the next step, I want to turn this into a function and display the result in 
a markup. Result: I spend several hours searching documentation, trying 
different functions, and getting one (or more!) errors per attempt, but no 
success. I literally cannot figure out how to turn this into a string, save 
hand-coding a recursion/map that takes each element of the list and appends it 
onto a string… and if that’s actually the "correct"/"best" way to do it, then I 
deeply question my desire to code in Scheme+Lilypond at all.  ;)

So someone please tell me what simple thing I’m missing here. In the worst case 
scenario, you just give me a fish and I can eat for a little while longer 
(read: not give up); best case senario, you teach me (and anyone else reading 
this list, now or in the future in the future) how to fish.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: license question

[Urs Liska]

Am 21. Januar 2020 20:25:43 MEZ schrieb David Kastrup :
>David Nalesnik  writes:
>
>> Hi all,
>>
>> I have a question concerning the GPL.  Is it permissible for an app
>> under a GPL-incompatible license to provide output in LilyPond code?
>> For example, could Finale provide a Finale->LilyPond converter even
>> though the mechanics are shrouded in mystery?
>
>Most certainly so.  Making a combined application running in the same
>process space would be a problem, but calling LilyPond as an executable
>is pretty uncontroversial.  If you distribute it as an aggregate
>solution, you need to provide the source of the LilyPond component (as
>it is being used) on request or by default.  But running it as a server
>is unproblematic.
>
>But if you don't even include LilyPond but produce LilyPond output, no
>license comes into play.  I mean, unless your output contains
>copyrightable code taken from somewhere else.

I would put it like this: you can produce LilyPond input files/code with 
whatever you want, even your copyrighted brain.

Also  you can produce with GPLed software any content, the copyright in 
question is only thd content author's, not that of LilyPond.

Urs
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: license question

[David Kastrup]

David Nalesnik  writes:

> Hi all,
>
> I have a question concerning the GPL.  Is it permissible for an app
> under a GPL-incompatible license to provide output in LilyPond code?
> For example, could Finale provide a Finale->LilyPond converter even
> though the mechanics are shrouded in mystery?

Most certainly so.  Making a combined application running in the same
process space would be a problem, but calling LilyPond as an executable
is pretty uncontroversial.  If you distribute it as an aggregate
solution, you need to provide the source of the LilyPond component (as
it is being used) on request or by default.  But running it as a server
is unproblematic.

But if you don't even include LilyPond but produce LilyPond output, no
license comes into play.  I mean, unless your output contains
copyrightable code taken from somewhere else.

-- 
David Kastrup

Re: license question

[mason]

> I have a question concerning the GPL.  Is it permissible for an app
> under a GPL-incompatible license to provide output in LilyPond code?
> For example, could Finale provide a Finale->LilyPond converter even
> though the mechanics are shrouded in mystery?

IANAL, but I don't think this would be a problem.  Finale cannot
incorporate any of Lilypond's code in order to achieve this
functionality, but I don't thing anything would stop them from
implementing it themselves.

This reminds me of MATLAB and GNU Octave.  There this situation is
reversed, in that the proprietary program came before the GPL'd program,
but it is another example of two programs with incompatible licenses
using the same syntax.


signature.asc
Description: PGP signature

Re: license question

[Carl Sorensen]

On 1/21/20, 11:07 AM, "David Nalesnik"  wrote:

Hi all,

I have a question concerning the GPL.  Is it permissible for an app
under a GPL-incompatible license to provide output in LilyPond code?
For example, could Finale provide a Finale->LilyPond converter even
though the mechanics are shrouded in mystery?

Thanks,
David

Finale could provide a Finale->LilyPond converter, but it could not use 
LilyPond GPL code to do so.

The LilyPond language is not copyrighted; the LilyPond code is, as far as I 
understand.

Carl

Re: \offset Y-offset

[Carl Sorensen]

On 1/21/20, 2:29 AM, "Aaron Hill"  wrote:

On 2020-01-19 7:15 am, Paolo Prete wrote:
> I'm looking at your code and I don't understand what is it intended to 
> do.
> You write: "% Test with bracket that is positioned by Y-offset."
> but from what I see, the bracket is positioned by both
> outside-staff-padding and y-offset inside \shiftOttavaBracket.
> What do you mean, then?
> In addition, please can you write at the beginning of the snippet what 
> you
> are going to demonstrate? IIUC, what you are going to demonstrate is
> something that depends on the result of another snippet. Please, can 
> you
> put all in the same example? Otherwise all becomes too hard to be
> understood/used.

It seems that email might not be the best medium of communication for 
this.  I am taking a page out of Knuth's handbook with something akin to 
literate programming.  Lacking a suitable TeX environment that works 
with LilyPond, I chose to do everything in a monolithic LY file.

Aaron, this is a masterpiece!  Not only of coding, but also of explaining the 
spacing algorithms.

Thanks,

Carl

Re: license question

[Kieren MacMillan]

Hi David,

> I have a question concerning the GPL.  Is it permissible for an app
> under a GPL-incompatible license to provide output in LilyPond code?
> For example, could Finale provide a Finale->LilyPond converter even
> though the mechanics are shrouded in mystery?

I’m very interested to hear informed opinions/answers… but if it’s anything 
except "of course they can do that!" (which is my instinct), then I really 
don’t understand what "free" means.  =)

Best,
Kieren.

RE: metronome-mark-alignment

[Daniel Rosen]

Now that the Salzburg conference is over, I'm reiterating this question in 
hopes that someone may be able to help me with it now. :-)

> -Original Message-
> From: Daniel Rosen
> Sent: Sunday, January 12, 2020 4:20 PM
> To: 'Thomas Morley' ; David Nalesnik
> 
> Cc: lilypond-user Mailing List (lilypond-user@gnu.org)  u...@gnu.org>
> Subject: RE: metronome-mark-alignment
> 
> When Metronome_mark_engraver is part of a Score or Staff context,
> MetronomeMarks that coincide with TimeSignatures align by default to the
> TimeSignature. However, I have a couple of Dynamics contexts in my score
> so that I can have MetronomeMarks centered between staves; in those
> contexts, with David/Harm's function applied, MetronomeMarks that
> coincide with TimeSignatures align to the accidental. How can I have it
> behave the same way as in a Staff context?
> 
> Tiny example attached.

I also just made a discovery that I suspect is worth noting: this inconsistency 
exists even when David and Harm's function is taken away, as one can see by 
commenting out the two \overrides in the MWE.

DR


mwe.ly
Description: mwe.ly

license question

[David Nalesnik]

Hi all,

I have a question concerning the GPL.  Is it permissible for an app
under a GPL-incompatible license to provide output in LilyPond code?
For example, could Finale provide a Finale->LilyPond converter even
though the mechanics are shrouded in mystery?

Thanks,
David

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

[Kieren MacMillan]

Hi Urs (et al.),

> What is your stance on these peanut issues  Kieren?

I’ve not previously encountered the idiom "peanut issues"… but if you mean 
comparing the delay of a few minutes in a train ride within adjoining countries 
in the EU zone versus my "25 consecutive hours of being awake because of jet 
lag, three international flights, four shuttle rides, a crying baby, five 
passes through security, and 2½ official passport checks", then my stance is 
perhaps one of patronizing dismissal.  ;)

Warmest wishes (from Toronto, which is, perhaps ironically, much colder than 
Austria)!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: MEI to LilyPond conversion

[Jacques Menu]

Hello David,

Thanks for the link. Python is not my line though, I use plain C++ for my tools.

JM


> You can of course take a more circuitous route with MusicXML as an
> intermediary.  For MusicXML to MEI there exist packages like this:
> https://github.com/gburlet/musicxml-mei-conversion 
> 
> 
> David

Re: Specifying \language for a single book

[Sandro Santilli]

On Mon, Jan 20, 2020 at 01:45:41PM -0800, Aaron Hill wrote:

> \layout is your friend:

Thanks! Great stAff! :)

> \book {
>   \bookOutputSuffix "G"
>   \score {
> \transpose c b,
> \leadSheet
>   }
> }
> 
> \book {
>   \bookOutputSuffix "F-ita"
>   \score {
> \transpose c a,
> \leadSheet
> \layout { \context { \ChordNames \italianChords } }
>   }
> }

Re: \offset Y-offset

[Kieren MacMillan]

Aaron,

Brilliant and impressive!

1. You continue to be my patronus. Really amazing work here.

2. Modulo exhaustive testing in real-world situations, you seem (in the final 
attempt) to have solved the problem completely — bravo!

3. One thing your example/doc strongly reinforces is a long-requested feature 
(at least for me): the ability to set grob [outside-][staff-]padding parameters 
*per side* (and of course per axis, if applicable!). Perhaps this is a great 
place to start a thread/discussion on how that might be implemented globally, 
and which grobs might be included/excluded in such a global scheme.

Thanks!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Highlight the y reference point for the "padding" property

[Paolo Prete]

Hello,

Is there a way to draw a line on the reference point of the "padding"
property?

Aaron already wrote a snippet for obtaining that for the X-offset property
(where the x-ref-point is on the x-parent):


\version "2.19.83"
{
   \once \override DynamicText.after-line-breaking = #(lambda (grob)
 (let* ((x-parent (ly:grob-parent grob X))
(orig-sten (ly:grob-property x-parent 'stencil
 (ly:make-stencil '()
   (ly:grob-set-property! x-parent 'stencil
 (grob-interpret-markup x-parent #{
\markup \combine \stencil #orig-sten
  \with-dimensions #'(0 . 0) #'(0 . 0) \vcenter
  \with-color #red \draw-line #'(0 . 6) #}
   c'\mf
}



Now I wonder how to extend it to other props, starting with the "padding" one...


Thanks,

P

Re: \offset Y-offset

[Paolo Prete]

On Tue, Jan 21, 2020 at 10:30 AM Aaron Hill 
wrote:

> On 2020-01-19 7:15 am, Paolo Prete wrote:
> > I'm looking at your code and I don't understand what is it intended to
> > do.
> > You write: "% Test with bracket that is positioned by Y-offset."
> > but from what I see, the bracket is positioned by both
> > outside-staff-padding and y-offset inside \shiftOttavaBracket.
> > What do you mean, then?
> > In addition, please can you write at the beginning of the snippet what
> > you
> > are going to demonstrate? IIUC, what you are going to demonstrate is
> > something that depends on the result of another snippet. Please, can
> > you
> > put all in the same example? Otherwise all becomes too hard to be
> > understood/used.
>
> It seems that email might not be the best medium of communication for
> this.  I am taking a page out of Knuth's handbook with something akin to
> literate programming.  Lacking a suitable TeX environment that works
> with LilyPond, I chose to do everything in a monolithic LY file.
>
> May you find attached a compiled PDF with its LY source file.


Excellent job!
I have to meditate about it before answering. I'll let you know ASAP.

Best,
P

Re: MEI to LilyPond conversion

[David Nalesnik]

On Tue, Jan 21, 2020 at 3:17 AM Urs Liska  wrote:
>
> Am Dienstag, den 21.01.2020, 10:09 +0100 schrieb Jacques Menu:
> > Hello folks,
> >
> > MEI has been mentionned at the Salzburg conference as more and more
> > used in the academic circles.
> >
> > Jan-Peter said that an MEI to Lily translator would be useful, and
> > RISM’s Laurent Pugin presented Verovio (
> > https://www.verovio.org/index.xhtml), which features an XSL/XSLT such
> > translator named MEIler (MEI Lilypond Engraving Refinement,
> > https://github.com/rettinghaus/meiler).
> >
>
> MEIler is independent from Verovio, and developed by Klaus Rettinghaus
> privately.
>
> > My questions are: do you feel the need for a MEI to LilyPond
> > translator, and has anyone experience with MEIler?
>
> a)
> There is a *strong* need for a reliable and fast translator from MEI to
> LilyPond (and vice versa) to make LilyPond an acceptable tool in the
> digital edition community.

You can of course take a more circuitous route with MusicXML as an
intermediary.  For MusicXML to MEI there exist packages like this:
https://github.com/gburlet/musicxml-mei-conversion

David

Re: MEI to LilyPond conversion

[David Nalesnik]

On Tue, Jan 21, 2020 at 7:04 AM Urs Liska  wrote:
>
> Am Dienstag, den 21.01.2020, 07:03 -0600 schrieb David Nalesnik:
> > On Tue, Jan 21, 2020 at 3:17 AM Urs Liska 
> > wrote:
> > > Am Dienstag, den 21.01.2020, 10:09 +0100 schrieb Jacques Menu:
> > > > Hello folks,
> > > >
> > > > MEI has been mentionned at the Salzburg conference as more and
> > > > more
> > > > used in the academic circles.
> > > >
> > > > Jan-Peter said that an MEI to Lily translator would be useful,
> > > > and
> > > > RISM’s Laurent Pugin presented Verovio (
> > > > https://www.verovio.org/index.xhtml), which features an XSL/XSLT
> > > > such
> > > > translator named MEIler (MEI Lilypond Engraving Refinement,
> > > > https://github.com/rettinghaus/meiler).
> > > >
> > >
> > > MEIler is independent from Verovio, and developed by Klaus
> > > Rettinghaus
> > > privately.
> > >
> > > > My questions are: do you feel the need for a MEI to LilyPond
> > > > translator, and has anyone experience with MEIler?
> > >
> > > a)
> > > There is a *strong* need for a reliable and fast translator from
> > > MEI to
> > > LilyPond (and vice versa) to make LilyPond an acceptable tool in
> > > the
> > > digital edition community.
> >
> > You can of course take a more circuitous route with MusicXML as an
> > intermediary.  For MusicXML to MEI there exist packages like this:
> > https://github.com/gburlet/musicxml-mei-conversion
>
> But the issue right now is *from* MEI *to* LilyPond.
>
> Urs
>

Should have written "MEI to MusicXML to LilyPond".  Of course, just a
temporary step.  (And, BTW, that package I linked to is bi-directional
but looks horribly out-of-date...)

David

Re: MEI to LilyPond conversion

[Urs Liska]

Am Dienstag, den 21.01.2020, 07:03 -0600 schrieb David Nalesnik:
> On Tue, Jan 21, 2020 at 3:17 AM Urs Liska 
> wrote:
> > Am Dienstag, den 21.01.2020, 10:09 +0100 schrieb Jacques Menu:
> > > Hello folks,
> > > 
> > > MEI has been mentionned at the Salzburg conference as more and
> > > more
> > > used in the academic circles.
> > > 
> > > Jan-Peter said that an MEI to Lily translator would be useful,
> > > and
> > > RISM’s Laurent Pugin presented Verovio (
> > > https://www.verovio.org/index.xhtml), which features an XSL/XSLT
> > > such
> > > translator named MEIler (MEI Lilypond Engraving Refinement,
> > > https://github.com/rettinghaus/meiler).
> > > 
> > 
> > MEIler is independent from Verovio, and developed by Klaus
> > Rettinghaus
> > privately.
> > 
> > > My questions are: do you feel the need for a MEI to LilyPond
> > > translator, and has anyone experience with MEIler?
> > 
> > a)
> > There is a *strong* need for a reliable and fast translator from
> > MEI to
> > LilyPond (and vice versa) to make LilyPond an acceptable tool in
> > the
> > digital edition community.
> 
> You can of course take a more circuitous route with MusicXML as an
> intermediary.  For MusicXML to MEI there exist packages like this:
> https://github.com/gburlet/musicxml-mei-conversion

But the issue right now is *from* MEI *to* LilyPond.

Urs

> 
> David

Re: \offset Y-offset

[Pierre Perol-Schneider]

Wouahoo, nice job Aaron!
Cheers,
Pierre

Le mar. 21 janv. 2020 à 10:30, Aaron Hill  a
écrit :

> On 2020-01-19 7:15 am, Paolo Prete wrote:
> > I'm looking at your code and I don't understand what is it intended to
> > do.
> > You write: "% Test with bracket that is positioned by Y-offset."
> > but from what I see, the bracket is positioned by both
> > outside-staff-padding and y-offset inside \shiftOttavaBracket.
> > What do you mean, then?
> > In addition, please can you write at the beginning of the snippet what
> > you
> > are going to demonstrate? IIUC, what you are going to demonstrate is
> > something that depends on the result of another snippet. Please, can
> > you
> > put all in the same example? Otherwise all becomes too hard to be
> > understood/used.
>
> It seems that email might not be the best medium of communication for
> this.  I am taking a page out of Knuth's handbook with something akin to
> literate programming.  Lacking a suitable TeX environment that works
> with LilyPond, I chose to do everything in a monolithic LY file.
>
> May you find attached a compiled PDF with its LY source file.  I cannot
> promise the LY is the *most* readable, but I have tried to keep things
> as organized as possible.  Likewise, I have done a few passes of
> proof-reading over the document, but at this point I am unlikely to spot
> any typos that remain.  And rather than delay this further, I am sending
> out what I have, for better or worse.
>
> Due to the nature of this presentation, there are parts of the LY file
> that are not directly relevant to the subject--including a number of
> helper functions for overlaying graphics on grobs, as well as a kludgy
> solution for including the text of a code snippet in the final document
> while also executing it.  Between just reading the PDF by itself and
> then along side the LY source, I hope it will not be too difficult to
> sort the wheat from the chaff.
>
>
> -- Aaron Hill

Re: MEI to LilyPond conversion

[Jacques Menu]

Thanks Urs!

> Le 21 janv. 2020 à 10:25, Urs Liska  a écrit :
> 
> Am Dienstag, den 21.01.2020, 10:21 +0100 schrieb Jacques Menu:
>> Hello Urs,
>> 
>> Thanks for correcting me as to the relationship between MEIler and
>> Verovio.
>> 
>> In what respect is Verovio superior to Lily, 
> 
> It provides live rendering with automatic reflow and engraving inside a
> browser window, and it is blazingly fast at it. LilyPond will probably
> never achieve that kind of usability in an interactive setting.
> This comes at the inherent cost of making much cheaper design
> decisions. Verovio is astonishingly good at that, but I'd argue it will
> never get to LilyPond's level of automatic engraving quality.
> 
> That's why I've been lobbying for having both Verovio and LilyPond as
> two coequal rendering channels for MEI documents.
> 
>> and what do you mean by 'not really scalable’? 
> 
> For every little feature that one wants supported one has to *add* to
> the set of conversion rules. This makes it harder to maintain than
> necessary, and it will probably make it even slower if it should
> approach comprehensiveness.
> 
> Urs
> 

Re: Specifying \language for a single book

[Klaus Blum]

Aaron Hill wrote
> There is no need to change the definition of the variable.
> 
> \layout is your friend:
> 
>  \layout { \context { \ChordNames \italianChords } }

Hi Aaron, 

wow - thanks for that easy solution. 
Another lesson learned...  ;-)

Klaus



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

MusicXML to braille music conversion

[Jacques Menu]

Hello folks,

There have been posts in the past on this subject in the Lily users’ list.

I now have a first draft of such a translator producing braille music in Ascii 
BRF and Unicode files. It translates the basic elements, such as time 
signatures, measures, notes, etc.

This development was frozen some time ago though: the mail I sent to ask who 
could provide technical information about such files generation was mostly 
never answered by the various individuals and organisms I sent it to, and I got 
discouraged.

DAISY Consortium is very active in the field of braille music, see 
https://daisy.org/activities/projects/music-braille/. 
According to the contacts I’ve had with them, they aim at an integrated 
graphical braille score editor, that would take the score structure into 
account. They already have done work with Veia Progetti, see 
https://www.youtube.com/watch?v=Sf60CpZQ_Iw. Of course, they have resources I 
don’t have.

The good news on my side is that I met two interested people at the Salzburg 
conference. Also, the bicentenial of the first braille book published by Louis 
Braille himself will take place in 2025, and that could raise interest for 
braille music.

A former braille music teacher told me that he is pessimistic for braille music 
teaching in the future, though: it is quite difficult for the blind people to 
learn, and efforts to integrate the blind in society, such as providing music 
in audio format, may undermine it.

I’m interested in knowing what you think and maybe hope in this area.

A nice day!

JM

Re: MEI to LilyPond conversion

[Urs Liska]

Am Dienstag, den 21.01.2020, 10:21 +0100 schrieb Jacques Menu:
> Hello Urs,
> 
> Thanks for correcting me as to the relationship between MEIler and
> Verovio.
> 
> In what respect is Verovio superior to Lily, 

It provides live rendering with automatic reflow and engraving inside a
browser window, and it is blazingly fast at it. LilyPond will probably
never achieve that kind of usability in an interactive setting.
This comes at the inherent cost of making much cheaper design
decisions. Verovio is astonishingly good at that, but I'd argue it will
never get to LilyPond's level of automatic engraving quality.

That's why I've been lobbying for having both Verovio and LilyPond as
two coequal rendering channels for MEI documents.

> and what do you mean by 'not really scalable’? 

For every little feature that one wants supported one has to *add* to
the set of conversion rules. This makes it harder to maintain than
necessary, and it will probably make it even slower if it should
approach comprehensiveness.

Urs

> 
> JM
> 
> > Le 21 janv. 2020 à 10:16, Urs Liska  a écrit
> > :
> > 
> > Am Dienstag, den 21.01.2020, 10:09 +0100 schrieb Jacques Menu:
> > > Hello folks,
> > > 
> > > MEI has been mentionned at the Salzburg conference as more and
> > > more
> > > used in the academic circles. 
> > > 
> > > Jan-Peter said that an MEI to Lily translator would be useful,
> > > and
> > > RISM’s Laurent Pugin presented Verovio (
> > > https://www.verovio.org/index.xhtml), which features an XSL/XSLT
> > > such
> > > translator named MEIler (MEI Lilypond Engraving Refinement, 
> > > https://github.com/rettinghaus/meiler).
> > > 
> > 
> > MEIler is independent from Verovio, and developed by Klaus
> > Rettinghaus
> > privately.
> > 
> > > My questions are: do you feel the need for a MEI to LilyPond
> > > translator, and has anyone experience with MEIler?
> > 
> > a)
> > There is a *strong* need for a reliable and fast translator from
> > MEI to
> > LilyPond (and vice versa) to make LilyPond an acceptable tool in
> > the
> > digital edition community.
> > Currently Verovio is the community's darling, and while it is
> > superior
> > to LilyPond in one respect (and an important one for that
> > community) it
> > is succinctly inferior in another respect. Currently the tendency
> > in
> > the MEI community seems to be to accept this inferiority and be
> > sort-of 
> > happy with incomplete and suboptimal engraving, just like society
> > accepted awful matrix printers for the first DTP possibilities.
> > 
> > b)
> > I once did a larger project with it, and I'd say that while it is a
> > surprisingly good tool it is not a "real" solution to the problem:
> > it's
> > too slow and not really scalable.
> > 
> > Urs
> > 
> > > Thanks for your help!
> > > 
> > > JM
> > > 
> > > 

Re: MEI to LilyPond conversion

[Jacques Menu]

Hello Urs,

Thanks for correcting me as to the relationship between MEIler and Verovio.

In what respect is Verovio superior to Lily, and what do you mean by 'not 
really scalable’? 

JM

> Le 21 janv. 2020 à 10:16, Urs Liska  a écrit :
> 
> Am Dienstag, den 21.01.2020, 10:09 +0100 schrieb Jacques Menu:
>> Hello folks,
>> 
>> MEI has been mentionned at the Salzburg conference as more and more
>> used in the academic circles. 
>> 
>> Jan-Peter said that an MEI to Lily translator would be useful, and
>> RISM’s Laurent Pugin presented Verovio (
>> https://www.verovio.org/index.xhtml), which features an XSL/XSLT such
>> translator named MEIler (MEI Lilypond Engraving Refinement, 
>> https://github.com/rettinghaus/meiler).
>> 
> 
> MEIler is independent from Verovio, and developed by Klaus Rettinghaus
> privately.
> 
>> My questions are: do you feel the need for a MEI to LilyPond
>> translator, and has anyone experience with MEIler?
> 
> a)
> There is a *strong* need for a reliable and fast translator from MEI to
> LilyPond (and vice versa) to make LilyPond an acceptable tool in the
> digital edition community.
> Currently Verovio is the community's darling, and while it is superior
> to LilyPond in one respect (and an important one for that community) it
> is succinctly inferior in another respect. Currently the tendency in
> the MEI community seems to be to accept this inferiority and be sort-of 
> happy with incomplete and suboptimal engraving, just like society
> accepted awful matrix printers for the first DTP possibilities.
> 
> b)
> I once did a larger project with it, and I'd say that while it is a
> surprisingly good tool it is not a "real" solution to the problem: it's
> too slow and not really scalable.
> 
> Urs
> 
>> 
>> Thanks for your help!
>> 
>> JM
>> 
>> 
> 

Re: MEI to LilyPond conversion

[Urs Liska]

Am Dienstag, den 21.01.2020, 10:09 +0100 schrieb Jacques Menu:
> Hello folks,
> 
> MEI has been mentionned at the Salzburg conference as more and more
> used in the academic circles. 
> 
> Jan-Peter said that an MEI to Lily translator would be useful, and
> RISM’s Laurent Pugin presented Verovio (
> https://www.verovio.org/index.xhtml), which features an XSL/XSLT such
> translator named MEIler (MEI Lilypond Engraving Refinement, 
> https://github.com/rettinghaus/meiler).
> 

MEIler is independent from Verovio, and developed by Klaus Rettinghaus
privately.

> My questions are: do you feel the need for a MEI to LilyPond
> translator, and has anyone experience with MEIler?

a)
There is a *strong* need for a reliable and fast translator from MEI to
LilyPond (and vice versa) to make LilyPond an acceptable tool in the
digital edition community.
Currently Verovio is the community's darling, and while it is superior
to LilyPond in one respect (and an important one for that community) it
is succinctly inferior in another respect. Currently the tendency in
the MEI community seems to be to accept this inferiority and be sort-of 
happy with incomplete and suboptimal engraving, just like society
accepted awful matrix printers for the first DTP possibilities.

b)
I once did a larger project with it, and I'd say that while it is a
surprisingly good tool it is not a "real" solution to the problem: it's
too slow and not really scalable.

Urs

> 
> Thanks for your help!
> 
> JM
> 
> 

MEI to LilyPond conversion

[Jacques Menu]

Hello folks,

MEI has been mentionned at the Salzburg conference as more and more used in the 
academic circles. 

Jan-Peter said that an MEI to Lily translator would be useful, and RISM’s 
Laurent Pugin presented Verovio (https://www.verovio.org/index.xhtml), which 
features an XSL/XSLT such translator named MEIler (MEI Lilypond Engraving 
Refinement, https://github.com/rettinghaus/meiler).

My questions are: do you feel the need for a MEI to LilyPond translator, and 
has anyone experience with MEIler?

Thanks for your help!

JM