Re: lyrics hyphens question

[David Nalesnik]

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

Hi David (et al.),

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

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


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


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

Agreed.

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

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

Thanks,
Kieren.


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

Re: lyrics hyphens question

[Kieren MacMillan]

Hi David (et al.),

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

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

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

Agreed.

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

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

Thanks,
Kieren.


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


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

Re: regression introduced with issue 5122 "Fix not scaling stem in note-by-number-markup"

[Thomas Morley]

2017-06-13 11:24 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> As of
>> https://sourceforge.net/p/testlilyissues/issues/5122/#99dc
>>
>> commit eee677c480c78d58a5215e246575aa94ba2d1897
>>
>> introduced a regression.
>>
>> Not sure when I have the time to look deeper into it.
>> At first sight I've no good idea for a proper fix.
>
> Do you have an idea about the underlying problem?

Not yet.
But while investigating:
(1)
There are many properties/procedures with impact on the font size. Among them:
the grob-property 'font-size,
the context-property 'fontSize
the markup-command \fontsize
the procedure layout-set-staff-size
the procedure set-global-staff-size

Even disregarding those for internal use only I'm not sure I listed all of them.

Sometimes they influence eachother...
Looks like a mess.

As a vague guess, I think I should find out which of the above changes
'text-font-size , 'pt, 'staff-height in to which amount.
I'll keep investigating, not much time those days though.

(2)
Probably not related to the issue here, but:
Why does below fail?

\new Score \with { #(layout-set-staff-size 40) }
\new Staff
{ \tempo 8=120 c'2 c' }

-->
error: GUILE signaled an error for the expression beginning here
\new Score \with { #
(layout-set-staff-size 40) }
Unbound variable: pt

This works:
\score {
  \new Staff
  { \tempo 8=120 c'2 c' }
  \layout { #(layout-set-staff-size 40) }
}

Cheers,
 Harm

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

Re: lyrics hyphens question

[David Nalesnik]

Hi Kieren,

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

Yes, that's right.

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

>

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

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

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

DN

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

Re: lyrics hyphens question

[David Kastrup]

Kieren MacMillan  writes:

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

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

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

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

-- 
David Kastrup

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

Re: lyrics hyphens question

[Kieren MacMillan]

Hi David (et al.),

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

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

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

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

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

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

to

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

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

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

Thanks,
Kieren.



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


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

Re: What is the point of \on-the-fly ?

[Paul]

On 06/13/2017 11:16 AM, David Kastrup wrote:


(define-markup-command bla)

does not define bla, but rather bla-markup, make-bla-markup and bits and
pieces used for signatures and the markup macro.

Even then, creating music functions on the fly _and_ using them requires
use of $(define-music-function ...) since #(define-music-function ...)
does not call the generated music function (would be hard assigning a
music function if it got called right away...).


Ah ok, thanks for the explanation.  (I need to brush up on my $ vs #.)


I actually just proposed an issue where you _can_ call markup functions
on the fly when defined properly.


Sounds good.  This is the $ one.


But the process of assigning a markup
command with all that it entails cannot be done in the same manner.

Since we can generate markup commands "on the fly" with \markup
... \etc, assigning them in a manner corresponding to
define-markup-command might be nice.

I suggested

\markup bla = ...

for it without being all too clear about whether this implied \markup
mode, allowing for

\markup bla = \bold \large \etc

rather than

\markup bla = \markup \bold \large \etc

There were no real comments (and I am fuzzy on the details of the
ensuing non-discussion as far as I remember it) so this proposal petered
out.


Hmm, I must have missed this, but sounds promising.

-Paul

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

Re: What is the point of \on-the-fly ?

[David Kastrup]

Paul  writes:

> On 06/12/2017 01:00 AM, David Kastrup wrote:
>
>> The use case is similar to that of lambda: creating a procedure on the
>> fly without giving it a name.
>
> Ah, got it.  Then makes sense to avoid having to use on-the-fly, by
> converting those named on-the-fly procedures into actual markup
> commands.
>
> Just thinking out loud, but if define-markup-command worked like
> define-music-function and friends (i.e. like lambda) so that they
> returned a procedure, like this:
>
>   command-name = #(define-markup-command (layout props args...) ...
>
>   (define command-name (define-markup-command (layout props args...) ...
>
> Rather than the current form:
>
>   (define-markup-command (command-name layout props args...) ...
>
> Would that remove the need for on-the-fly or am I missing something?
> I'm sure that would not be a trivial change -- again just thinking out
> loud.

(define-markup-command bla)

does not define bla, but rather bla-markup, make-bla-markup and bits and
pieces used for signatures and the markup macro.

Even then, creating music functions on the fly _and_ using them requires
use of $(define-music-function ...) since #(define-music-function ...)
does not call the generated music function (would be hard assigning a
music function if it got called right away...).

I actually just proposed an issue where you _can_ call markup functions
on the fly when defined properly.  But the process of assigning a markup
command with all that it entails cannot be done in the same manner.

Since we can generate markup commands "on the fly" with \markup
... \etc, assigning them in a manner corresponding to
define-markup-command might be nice.

I suggested

\markup bla = ...

for it without being all too clear about whether this implied \markup
mode, allowing for

\markup bla = \bold \large \etc

rather than

\markup bla = \markup \bold \large \etc

There were no real comments (and I am fuzzy on the details of the
ensuing non-discussion as far as I remember it) so this proposal petered
out.

-- 
David Kastrup

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

Re: What is the point of \on-the-fly ?

[Paul]

On 06/12/2017 01:00 AM, David Kastrup wrote:


The use case is similar to that of lambda: creating a procedure on the
fly without giving it a name.


Ah, got it.  Then makes sense to avoid having to use on-the-fly, by 
converting those named on-the-fly procedures into actual markup commands.


Just thinking out loud, but if define-markup-command worked like 
define-music-function and friends (i.e. like lambda) so that they 
returned a procedure, like this:


  command-name = #(define-markup-command (layout props args...) ...

  (define command-name (define-markup-command (layout props args...) ...

Rather than the current form:

  (define-markup-command (command-name layout props args...) ...

Would that remove the need for on-the-fly or am I missing something?  
I'm sure that would not be a trivial change -- again just thinking out loud.


-Paul

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

Re: Initial work to support opentype font features (issue 323850043 by horndud...@gmail.com)

[trueroad]

On 2017/06/12 10:43:53, trueroad wrote:

On 2017/06/05 05:01:28, horndude77 wrote:
> Update minimum pango version



If I understand correctly, LilyDev 4.1 cannot compile this patch.



In my humble opinion, it is necessary that LilyDev 4.1 can compile it.
I want to hear the opinions of LilyDev 4.1 users.



If it is necessary, shall I create an additional patch that can be

compiled by

LilyDev 4.1?



Jay, would you send us the git format-patch file?
Then, I can commit your patch my the additional patch.


I've uploaded the additional patch as Issue 5147.
https://sourceforge.net/p/testlilyissues/issues/5147/

https://codereview.appspot.com/323850043/

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

Re: regression introduced with issue 5122 "Fix not scaling stem in note-by-number-markup"

[David Kastrup]

Thomas Morley  writes:

> As of
> https://sourceforge.net/p/testlilyissues/issues/5122/#99dc
>
> commit eee677c480c78d58a5215e246575aa94ba2d1897
>
> introduced a regression.
>
> Not sure when I have the time to look deeper into it.
> At first sight I've no good idea for a proper fix.

Do you have an idea about the underlying problem?

> So I suggest to revert it.
> At least it should not go into 2.20 in the current state.

Noted.

-- 
David Kastrup

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

Don't use \line in the implementation of \concat (issue 325860043 by d...@gnu.org)

[lemzwerg]

LGTM

https://codereview.appspot.com/325860043/

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