Re: [partcombine] honouring Voice context name

[Kieren MacMillan]

Hi Dan (et al.),

> It is worth investigating the possibility of changing the part combiner from 
> an event router to a property setter.  If that is feasible, Kieren’s concerns 
> about voice naming would still need to be addressed, but without the 
> complication of the extra voices that exist only as an implementation 
> artifact.

It's a very interesting idea. Whether it is scalable is possibly a separate 
concern… but even as an intentionally-limited mechanism (e.g., \combineTwo, 
which can only combine two parts/voices), there could be great benefits. I'll 
poke around and report back.

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: [partcombine] honouring Voice context name

[Dan Eble]

> On Jun 7, 2017, at 19:48, Carl Sorensen  wrote:
> 
> On 6/7/17 5:30 PM, "Kieren MacMillan" 
> wrote:
> 
>>> Could it not leave the parts where they are (continuous parts in
>>> exactly one voice context per part) and change their context properties
>>> instead?
>> 
>> Not sure I quite understand what you're suggestingŠ
> 
> So the current partcombine creates the named voices (if they don't already
> exist) and puts the music events into the appropriate voices.
> 
> but I think that my most common
> use case is not continuous parts in exactly one Voice context per part.  I
> think my most common use case is two sequential music expressions that are
> not yet assigned to any Voice context.

I think we’re just looking at it differently.  You’re considering the arguments 
to partcombine.  My perspective was that eventually the events in those 
expressions are interpreted in a voice context.

I was trying to explain that there are two related aspects of the current 
implementation that might be unnecessary:

  * using more voices than there are parts
  * distributing fragments of a part to different voices

It is worth investigating the possibility of changing the part combiner from an 
event router to a property setter.  If that is feasible, Kieren’s concerns 
about voice naming would still need to be addressed, but without the 
complication of the extra voices that exist only as an implementation artifact.
— 
Dan


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

Re: [partcombine] honouring Voice context name

[Carl Sorensen]

On 6/7/17 5:30 PM, "Kieren MacMillan" 
wrote:

>Hi Dan,
>
>> If we¹re going to ask that kind of question, let¹s mention a more
>>radical redesign.
>
>I would be happy with a "radical redesign", if that's what it takes to
>(a) solve some of the problems I face with partcombine on a daily basis,
>or (b) establish a good base for future development/improvement, or (c)
>both of the above.
>
>> The context properties of a part, such as stem direction, need to
>>change as the part¹s relationship with other parts changes.  The current
>>part combiner accomplishes this with a set of voices with fixed
>>properties.  It slices the part into pieces and distributes them to the
>>voice with the appropriate properties.
>> 
>> Could it not leave the parts where they are (continuous parts in
>>exactly one voice context per part) and change their context properties
>>instead?
>
>Not sure I quite understand what you're suggestingŠ

It seems to me that one of the issues that muddies the water here is the
definition of what a "part" is that is to be combined by partcombine.

Currently partcombine works on music expressions, IIUC.  And the music
expressions need not have contexts assigned.  Therefore there are no
context properties available in the items to be combined.

So the current partcombine creates the named voices (if they don't already
exist) and puts the music events into the appropriate voices.

I don't want to contradict Dan, because he has done stuff with partcombine
that is clearly beyond my contributions, but I think that my most common
use case is not continuous parts in exactly one Voice context per part.  I
think my most common use case is two sequential music expressions that are
not yet assigned to any Voice context.

Is there something in partcombine that has the arguments be music in a
Voice context?  If so, I am not aware of it (but as I said before, my
understanding of partcombine is fuzzy enough that this is certainly a
question, not a statement).

Thanks,

Carl
 


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

Re: [partcombine] honouring Voice context name

[Kieren MacMillan]

Hi Dan,

> If we’re going to ask that kind of question, let’s mention a more radical 
> redesign.

I would be happy with a "radical redesign", if that's what it takes to (a) 
solve some of the problems I face with partcombine on a daily basis, or (b) 
establish a good base for future development/improvement, or (c) both of the 
above.

> The context properties of a part, such as stem direction, need to change as 
> the part’s relationship with other parts changes.  The current part combiner 
> accomplishes this with a set of voices with fixed properties.  It slices the 
> part into pieces and distributes them to the voice with the appropriate 
> properties.
> 
> Could it not leave the parts where they are (continuous parts in exactly one 
> voice context per part) and change their context properties instead?

Not sure I quite understand what you're suggesting…

> I’m not sure I was clear.  Those are examples of things I’ve actually 
> accomplished using most of the scheme parts of the part combiner as shipped 
> with Lilypond.  I was trying to point out that there is already more internal 
> flexibility than meets the eye.  Depending on your use cases, you might 
> already be able to take advantage of it.

Well, in regard to at least one of the problems I'm facing, David K has 
indicated that "the principles of the mechanisms are incompatible" 
(translation: can't use what's shipped with Lilypond).

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: [partcombine] honouring Voice context name

[Dan Eble]

> On Jun 7, 2017, at 09:34, Kieren MacMillan  
> wrote:
> 
> As a first step, I would offer that we should figure out how (if?) the "one" 
> context can be funnelled seamlessly into the "shared" and "solo" contexts — 
> as I see it, that's the main problem with lyrics getting disconnected (etc.).

If we’re going to ask that kind of question, let’s mention a more radical 
redesign.

The context properties of a part, such as stem direction, need to change as the 
part’s relationship with other parts changes.  The current part combiner 
accomplishes this with a set of voices with fixed properties.  It slices the 
part into pieces and distributes them to the voice with the appropriate 
properties.

Could it not leave the parts where they are (continuous parts in exactly one 
voice context per part) and change their context properties instead?

>> If you do want to impact the algorithm, it is possible to define a music 
>> function that uses the deeper parts of the part combiner with your own state 
>> machine.  Variations I’ve tried:
>> 1) never enter solo mode
> 
> That doesn't sound quite right to me…
> 
>> 2) add force commands \partcombineRovingI and ~II and corresponding voices 
>> “rovingOne” and “rovingTwo” to support staff splitting (I hoped to 
>> contribute this, but I haven’t had time.)
> 
> I'll look at that. Thanks.

I’m not sure I was clear.  Those are examples of things I’ve actually 
accomplished using most of the scheme parts of the part combiner as shipped 
with Lilypond.  I was trying to point out that there is already more internal 
flexibility than meets the eye.  Depending on your use cases, you might already 
be able to take advantage of it.
— 
Dan



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

Re: Releasing 2.20

[Hans Aikema]

David,

Make sure that your main focus will be getting back into good shape.

If schedule and energy levels allow for starting of a 2.20 branch I think it 
would be good to update ghostscript to a version that has the PNG-transparency 
glitches fixed that surfaced in 2.19.51.
Ghostscript has made a release with the fix for the issue that was created by 
Masamichi Hosoda as a result of the discovery of the PNG-transparency bug in 
the 2.19.51 Lilypond build) 

I guess not picking the ghostscript update from the 2.19 branch would be 
senseless, but keeping the current status of the 2.19 branch would not fit a 
stable release IMO

Hans Aikema, direct vanuit de iCloud

> Op 7 jun. 2017 om 22:34 heeft David Kastrup  het volgende 
> geschreven:
> 
> 
> Ok folks,
> 
> tomorrow I am leaving for physical therapy.  I expect 3 weeks without
> extension since the problematic areas have boiled down considerably in
> the last two weeks already: swallowing is an ongoing nuisance, balance
> is pretty well but looking back when bicycling still is precarious in
> particular when something _is_ creeping up.  And temperature and pain
> insensitivity on the left side and the mouth is something that also
> requires adaption.  I am dealing reasonably well with my right hand
> though using it in "independent parts" like for finicky mechanical feats
> and for playing button accordion still shows some disposition for
> cramping up.
> 
> But all in all I'm down to somewhat particular complaints so it's my
> guess that 3 weeks of fulltime institutionalization will be sufficient
> for getting things on track sufficiently in order to revert to parttime
> afterwards.
> 
> A number of people have wished me well, voiced their concerns and sent
> personal support.  Most of them I haven't answered individually and
> apologize for that: I have a lot on my mind right now and the mind is
> not all that well-focused yet (and honestly, it wasn't all that
> well-focused before the stroke either).  So putting out individual and
> appropriate responses well a bit through the cracks.
> 
> I have to see how much of a taxation therapy will turn out to be.  I got
> my computer with me and I have installed a WWAN card and got some data
> plan that should at least be good for email and issue updates.
> Reception is pretty bad out in the woods here (I don't really have a
> dedicated antenna but have instead sacrificed a Wifi antenna in the
> laptop) but my expectation is that the institution will likely have a
> cell tower close enough for Email to get in and out reliably enough.
> 
> So I should be able to do some reasonably straightforward work.
> 
> So how is it going to end up?  Barring objections, I'll probably branch
> off a stable release branch early next week.  I'll have to see what to
> cherry-pick into this branch as fixes proceed, and possibly what to
> revert when it is not clear that functionality provided by recent
> patches/changes can be considered stable in use and interface.
> 
> I don't think that we should need much more than the 3-week maturing
> period corresponding to the expected physical therapy duration.
> 
> The alternative of releasing 2.18.3 since 2.18.2 does not even compile
> using gcc-7 anymore is something I want to avoid.
> 
> So I'd rather pitch for a timely release of 2.20.  There have been a few
> critical bugs flagged, however.  I'll take a look at them eventually but
> if someone else has a good idea...
> 
> -- 
> David Kastrup
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Re: [Issue #3947] fixing \huge et al.

[Thomas Morley]

2017-06-07 21:53 GMT+02:00 Carl Sorensen :

>
> Is there any place else in the codebase where we include lilypond examples
> in the doc strings?  It seems like we ought to try for consistency; either
> use lilypond examples in all of the doc strings (maybe at least for markup
> functions) or in none of them.  I don't know the right answer; I'm just
> raising the question.

>From the comment on top of define-markup-commands.scm:
[...]
;;;
;;; Each markup command definition shall have a documentation string
;;; with description, syntax and example.

Cheers,
  Harm

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

Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi David,

> Maybe check the effects that super- and subscripts cause on a block of text?

Good thought. Doesn't seem to have a negative effect.

Other thoughts?
Or should I start moving towards a submittable patch?

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

Releasing 2.20

[David Kastrup]

Ok folks,

tomorrow I am leaving for physical therapy.  I expect 3 weeks without
extension since the problematic areas have boiled down considerably in
the last two weeks already: swallowing is an ongoing nuisance, balance
is pretty well but looking back when bicycling still is precarious in
particular when something _is_ creeping up.  And temperature and pain
insensitivity on the left side and the mouth is something that also
requires adaption.  I am dealing reasonably well with my right hand
though using it in "independent parts" like for finicky mechanical feats
and for playing button accordion still shows some disposition for
cramping up.

But all in all I'm down to somewhat particular complaints so it's my
guess that 3 weeks of fulltime institutionalization will be sufficient
for getting things on track sufficiently in order to revert to parttime
afterwards.

A number of people have wished me well, voiced their concerns and sent
personal support.  Most of them I haven't answered individually and
apologize for that: I have a lot on my mind right now and the mind is
not all that well-focused yet (and honestly, it wasn't all that
well-focused before the stroke either).  So putting out individual and
appropriate responses well a bit through the cracks.

I have to see how much of a taxation therapy will turn out to be.  I got
my computer with me and I have installed a WWAN card and got some data
plan that should at least be good for email and issue updates.
Reception is pretty bad out in the woods here (I don't really have a
dedicated antenna but have instead sacrificed a Wifi antenna in the
laptop) but my expectation is that the institution will likely have a
cell tower close enough for Email to get in and out reliably enough.

So I should be able to do some reasonably straightforward work.

So how is it going to end up?  Barring objections, I'll probably branch
off a stable release branch early next week.  I'll have to see what to
cherry-pick into this branch as fixes proceed, and possibly what to
revert when it is not clear that functionality provided by recent
patches/changes can be considered stable in use and interface.

I don't think that we should need much more than the 3-week maturing
period corresponding to the expected physical therapy duration.

The alternative of releasing 2.18.3 since 2.18.2 does not even compile
using gcc-7 anymore is something I want to avoid.

So I'd rather pitch for a timely release of 2.20.  There have been a few
critical bugs flagged, however.  I'll take a look at them eventually but
if someone else has a good idea...

-- 
David Kastrup

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

Re: [Issue #3947] fixing \huge et al.

[David Kastrup]

Kieren MacMillan  writes:

> Hi Carl,
>
>> You have not yet tested your baseline-skip parameter with a different
>> default-staff-size.  I think that you will probably need to include the
>> default baseline-skip when determining the new baseline-skip.  Font sizes
>> avoid this problem by using a scale parameter.  I don't know that it's
>> possible to use a scale parameter for baseline-skip.
>
> In my exchange with David K on -user, I asked why there are so many
> different functions for font sizing… Now I see that the existing
> \fontsize automagically adjusts both baseline-skip *and* word-space
> (which I hadn't even considered).
>
> In light of that, doesn't it make sense to just redefine \huge et
> al. to call \fontsize directly?  cf. snippet (below, with comment
> strings removed here)
>
> Why would it not have been this way to begin with? Is there some
> side-effect that I can't predict?

Maybe check the effects that super- and subscripts cause on a block of
text?  I'd not be able to tell offhand whether that's a concern, nor
whether it possibly being a concern might have changed due to
line-spacing changes in the last stable versions.

-- 
David Kastrup

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

Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi Carl,

> You have not yet tested your baseline-skip parameter with a different
> default-staff-size.  I think that you will probably need to include the
> default baseline-skip when determining the new baseline-skip.  Font sizes
> avoid this problem by using a scale parameter.  I don't know that it's
> possible to use a scale parameter for baseline-skip.

In my exchange with David K on -user, I asked why there are so many different 
functions for font sizing… Now I see that the existing \fontsize automagically 
adjusts both baseline-skip *and* word-space (which I hadn't even considered).

In light of that, doesn't it make sense to just redefine \huge et al. to call 
\fontsize directly?
cf. snippet (below, with comment strings removed here)

Why would it not have been this way to begin with? Is there some side-effect 
that I can't predict?

Thanks,
Kieren.

%%%  SNIPPET BEGINS
\version "2.19.61"

#(define-markup-command (huge layout props arg)
  (markup?)
  #:category font
  (interpret-markup layout props
(markup #:fontsize 2 arg)))

#(define-markup-command (teeny layout props arg)
  (markup?)
  #:category font
  (interpret-markup layout props
(markup #:fontsize -3 arg)))

loremIpsum = \markup \wordwrap {
  Lorem ipsum dolor sit amet, consectetur adipisicing elit,
  sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
  Ut enim ad minim veniam, quis nostrud exercitation ullamco
  laboris nisi ut aliquip ex ea commodo consequat.
  Duis aute irure dolor in reprehenderit in voluptate
  velit esse cillum dolore eu fugiat nulla pariatur.
  Excepteur sint occaecat cupidatat non proident,
  sunt in culpa qui officia deserunt mollit anim id est laborum.
}

\markup \loremIpsum
\markup \vspace #2
\markup \huge \loremIpsum
\markup \vspace #2
\markup \teeny \loremIpsum
%%%  SNIPPET ENDS


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: [Issue #3947] fixing \huge et al.

[Carl Sorensen]

On 6/7/17 2:01 PM, "Kieren MacMillan" 
wrote:


>> Is there any place else in the codebase where we include lilypond
>>examples
>> in the doc strings?  It seems like we ought to try for consistency;
>>either
>> use lilypond examples in all of the doc strings (maybe at least for
>>markup
>> functions) or in none of them.  I don't know the right answer; I'm just
>> raising the question.
>
>It's a good question. I simply copied this code from
>define-markup-commands.scm. On quick glance, it appears that most of
>those functions have Lilypond examples in their doc string(s). In any
>case, I'll leave it as a different question, to be handled separately
>from the improvement of \huge et al.

It's a perfect answer -- that's what is currently being done in
define-markup-commands.scm, so we should continue doing that.

Thanks,

Carl


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

Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi Carl,

Thanks for the helpful response.

> The spacing appears pretty good to me.

Excellent.

> Seems like an abstracted function with two parameters (magstep and
> baselineskip) would be about right.  Of course, if you can determine
> baselineskip from magstep, you would only need one parameter.

I'm optimistic I can.

> You have not yet tested your baseline-skip parameter
> with a different default-staff-size.

No indeed. Thanks for the tip!

> I don't know that it's possible to use a scale parameter for baseline-skip.

Hmmm… Well, since it seems that [roughly]

   staff-size #20 @ font size #0 => baseline-skip 3

I would hope I'd be able to work out some formula.

> Is there any place else in the codebase where we include lilypond examples
> in the doc strings?  It seems like we ought to try for consistency; either
> use lilypond examples in all of the doc strings (maybe at least for markup
> functions) or in none of them.  I don't know the right answer; I'm just
> raising the question.

It's a good question. I simply copied this code from 
define-markup-commands.scm. On quick glance, it appears that most of those 
functions have Lilypond examples in their doc string(s). In any case, I'll 
leave it as a different question, to be handled separately from the improvement 
of \huge et al.

> Looks like a great start.

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: [Issue #3947] fixing \huge et al.

[Carl Sorensen]

On 6/7/17 12:17 PM, "lilypond-devel on behalf of Kieren MacMillan"
 wrote:

>Hello all,
>
>Thanks to some help (on the user-list) from David K, I've started to
>attack issue #3947.
>(I figured this would be a nice, relatively painless way to get my feet
>wet in the dev/git/patch process.)
>
>The snippet included below is what I have so far. It appears to work as
>hoped.
>
>Two questions:
>
>1. Does the skip appear *roughly* right to people? (I plan to use a
>mathematical interpolation/model/formula, but wanted to get
>approval/concensus/comments first.)

The spacing appears pretty good to me.

>
>2. Seems like a lot of redundant coding hereŠ Should I add an abstracted
>function (e.g., fontsizer), which is then called by \huge et al.?

Seems like an abstracted function with two parameters (magstep and
baselineskip) would be about right.  Of course, if you can determine
baselineskip from magstep, you would only need one parameter.


You have not yet tested your baseline-skip parameter with a different
default-staff-size.  I think that you will probably need to include the
default baseline-skip when determining the new baseline-skip.  Font sizes
avoid this problem by using a scale parameter.  I don't know that it's
possible to use a scale parameter for baseline-skip.


>
>#(define-markup-command (huge layout props arg)
>  (markup?)
>  #:category font
>  "Set font size to +2.
>
>@lilypond[verbatim,quote]
>\\markup {
>  default
>  \\hspace #2
>  \\huge
>  huge
>}
>@end lilypond"
>  (interpret-markup layout (prepend-alist-chain 'baseline-skip 4
>(prepend-alist-chain 'font-size 2 props)) arg))

Is there any place else in the codebase where we include lilypond examples
in the doc strings?  It seems like we ought to try for consistency; either
use lilypond examples in all of the doc strings (maybe at least for markup
functions) or in none of them.  I don't know the right answer; I'm just
raising the question.


Looks like a great start.

Thanks,

Carl


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

[Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hello all,

Thanks to some help (on the user-list) from David K, I've started to attack 
issue #3947.
(I figured this would be a nice, relatively painless way to get my feet wet in 
the dev/git/patch process.)

The snippet included below is what I have so far. It appears to work as hoped.

Two questions:

1. Does the skip appear *roughly* right to people? (I plan to use a 
mathematical interpolation/model/formula, but wanted to get 
approval/concensus/comments first.)

2. Seems like a lot of redundant coding here… Should I add an abstracted 
function (e.g., fontsizer), which is then called by \huge et al.?

Thanks,
Kieren.

%%%  SNIPPET BEGINS
\version "2.19.61"


#(define-markup-command (huge layout props arg)
  (markup?)
  #:category font
  "Set font size to +2.

@lilypond[verbatim,quote]
\\markup {
  default
  \\hspace #2
  \\huge
  huge
}
@end lilypond"
  (interpret-markup layout (prepend-alist-chain 'baseline-skip 4 
(prepend-alist-chain 'font-size 2 props)) arg))

#(define-markup-command (large layout props arg)
  (markup?)
  #:category font
  "Set font size to +1.

@lilypond[verbatim,quote]
\\markup {
  default
  \\hspace #2
  \\large
  large
}
@end lilypond"
  (interpret-markup layout (prepend-alist-chain 'baseline-skip 3.625 
(prepend-alist-chain 'font-size 1 props)) arg))

#(define-markup-command (normalsize layout props arg)
  (markup?)
  #:category font
  "Set font size to default.

@lilypond[verbatim,quote]
\\markup {
  \\teeny {
this is very small
\\hspace #2
\\normalsize {
  normal size
}
\\hspace #2
teeny again
  }
}
@end lilypond"
  (interpret-markup layout (prepend-alist-chain 'baseline-skip 3 
(prepend-alist-chain 'font-size 0 props)) arg))

#(define-markup-command (small layout props arg)
  (markup?)
  #:category font
  "Set font size to -1.

@lilypond[verbatim,quote]
\\markup {
  default
  \\hspace #2
  \\small
  small
}
@end lilypond"
  (interpret-markup layout (prepend-alist-chain 'baseline-skip 2.5 
(prepend-alist-chain 'font-size -1 props)) arg))

#(define-markup-command (tiny layout props arg)
  (markup?)
  #:category font
  "Set font size to -2.

@lilypond[verbatim,quote]
\\markup {
  default
  \\hspace #2
  \\tiny
  tiny
}
@end lilypond"
  (interpret-markup layout (prepend-alist-chain 'baseline-skip 2.3 
(prepend-alist-chain 'font-size -2 props)) arg))

#(define-markup-command (teeny layout props arg)
  (markup?)
  #:category font
  "Set font size to -3.

@lilypond[verbatim,quote]
\\markup {
  default
  \\hspace #2
  \\teeny
  teeny
}
@end lilypond"
  (interpret-markup layout (prepend-alist-chain 'baseline-skip 2.125 
(prepend-alist-chain 'font-size -3 props)) arg))

loremIpsum = \markup \wordwrap {
  Lorem ipsum dolor sit amet, consectetur adipisicing elit,
  sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
  Ut enim ad minim veniam, quis nostrud exercitation ullamco
  laboris nisi ut aliquip ex ea commodo consequat.
  Duis aute irure dolor in reprehenderit in voluptate
  velit esse cillum dolore eu fugiat nulla pariatur.
  Excepteur sint occaecat cupidatat non proident,
  sunt in culpa qui officia deserunt mollit anim id est laborum.
}

\markup \loremIpsum
\markup \vspace #2
\markup \huge \loremIpsum
\markup \vspace #2
\markup \large \loremIpsum
\markup \vspace #2
\markup \normalsize \loremIpsum
\markup \vspace #2
\markup \small \loremIpsum
\markup \vspace #2
\markup \tiny \loremIpsum
\markup \vspace #2
\markup \teeny \loremIpsum
%%%  SNIPPET ENDS


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: VirtualBox error

[Wols Lists]

On 07/06/17 00:54, Kieren MacMillan wrote:
> Hi all,
> 
>> Got what?
> 
> Hmmm… Looks like the list didn't accept my screenshot…  =(
> 
> Anyway, it was a fatal error.
> I have apparently fixed it (?) by uninstalling and doing the whole procedure 
> again from scratch.
> 
Dunno whether it's what you had, but you always need to install the
correct kernel modules, which means if you try and install then run it
without rebooting, that could have been your problem.

I run gentoo, and upgrading VBox is always a pain because I keep on
forgetting to update the modules. Of course, knowing about the problem,
I usually recognise it instantly now but it was quite a nuisance initially.

Cheers,
Wol


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

Fix typos in \offset documentation (issue 322040043 by david.nales...@gmail.com)

[david . nalesnik]

Reviewers: ,

Description:
Fix typos in \offset documentation

- Fix errors in description of OttavaBracket example
- Minor improvements in wording

Please review this at https://codereview.appspot.com/322040043/

Affected files (+5, -4 lines):
  M Documentation/notation/changing-defaults.itely


Index: Documentation/notation/changing-defaults.itely
diff --git a/Documentation/notation/changing-defaults.itely  
b/Documentation/notation/changing-defaults.itely
index  
7fad344bb6ee3cc4d281e36d49e55bbf77363115..5373e4f399fa3fcb17d7775032be5b7d801894c6  
100644

--- a/Documentation/notation/changing-defaults.itely
+++ b/Documentation/notation/changing-defaults.itely
@@ -2783,10 +2783,11 @@ The following example displaces the @q{broken}  
@code{OttavaBracket}

 object through its @code{staff-padding} property.  Since the property
 takes a @code{number}, @var{offsets} is provided with a list of
 @code{number}s to account for the two segments created by the line
-break.  The slur piece on the first line is effectively untouched since
-@code{0} is added to its default value.  The segment on the second
-line is raised two staff-spaces from its default height.  The default
-height happens to be @code{2}, though it is not necesssary to know this.
+break.  The bracket piece on the first line is effectively untouched
+since @code{0} is added to its default value of @code{staff-padding}.
+The segment on the second line is raised three staff-spaces from its
+default height.  The default height happens to be @code{2}, though it is
+not necessary to know this to achieve the desired positioning.

 @lilypond[quote,verbatim]
 {



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

Re: [partcombine] honouring Voice context name

[Kieren MacMillan]

Hi Dan,

> The part combiner can also route events to “shared”, “solo”, and “null” 
> contexts.  If you took the step you’re proposing, the next question would be 
> why can’t a person control those other names too?  If there is going to be 
> user control, should it be more comprehensive?

Absolutely.

As a first step, I would offer that we should figure out how (if?) the "one" 
context can be funnelled seamlessly into the "shared" and "solo" contexts — as 
I see it, that's the main problem with lyrics getting disconnected (etc.).

> If it should be more comprehensive, the next question is will it scale if 
> someone finally buckles down and makes the part combiner work with more than 
> two parts?

An excellent question. I would love to be that [swash]buckler, but given the 
combinatorial growth rate of the possible multi-voice interactions, I currently 
don't have an inkling how to scale the partcombiner to *three* voices, let 
alone "arbitrary". I'm hoping tackling and perfecting [sic] the two-voice 
version will give me better insights in that direction.

> On the contrary, your suggestion seems aesthetic.  Whether the up-stem voice 
> is “one” or “fred” does not impact the algorithm.  You'd still have one part 
> jumping around between “fred”, “shared”, and “solo”.

See above; I'm hoping the voice names *will* impact the algorithm (in a 
positive sense).

> If you do want to impact the algorithm, it is possible to define a music 
> function that uses the deeper parts of the part combiner with your own state 
> machine.  Variations I’ve tried:
> 1) never enter solo mode

That doesn't sound quite right to me…

> 2) add force commands \partcombineRovingI and ~II and corresponding voices 
> “rovingOne” and “rovingTwo” to support staff splitting (I hoped to contribute 
> this, but I haven’t had time.)

I'll look at that. Thanks.

> Getting back to your idea: the state machine definition has voice names, so 
> if you wanted to make the voice names flexible, I suppose you would either
> 1) use the existing state machine as a template: make a copy, replace the 
> names, pass it on to the part combiner; OR 
> 2) give the part combiner a map from the state-machine voice names to the 
> user's voice names
> 
> I’m not a good judge of which is more lispy.  (1) strikes me as more 
> complicated but probably better performing.

I'll try (1), unless I hear or find something that suggests I should do 
otherwise.

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