Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Paul Morris]

> On Dec 27, 2015, at 7:25 PM, David Kastrup  wrote:
> 
>> (2)
>> The doc-string for `stencil-whiteout' implies that @var{thickness} is
>> optional. As far as I understand it's not.

You’re right that the doc-string is misleading.  @var{thickness} is required as 
an argument but if its value is not a number then an appropriate value is 
selected based on @var{style}.  If the user hasn’t explicitly specified a 
number for the thickness of the whiteout, then this procedure is called with an 
empty/null/non-number value for @var{thickness}.

> Should it be?  Would that have saved us from the error?

I don’t think it would have prevented this error but it probably makes sense to 
make it an optional argument.  I’ll prepare a patch for that so the code will 
match the doc string.

-Paul



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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2015-12-28 23:13 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> Though I'm not sure with the following one. May I ask: curried or not?
>> (define (foo a b)
>>   (let ((x2 (lambda (arg) (* 2 arg
>> (map x2 (list a b
>
> Why would that one be curried?  It's completely boring, returns a list,
> and its internal function x2 is totally straightforward (not even a
> closure) and is invisible to the caller.
>
> Slightly more interesting is
>
> (define (fie a)
>   (lambda (x) (+ x a)))
>
> which is equivalent to the curried definition
>
> (define ((fie a) x) (+ x a))
>
> However, the currying is not a feature of the semantics (the semantics
> of returning a function or more often a closure, namely a function with
> an environment in the form of variables imported into its scope) but of
> the syntax.
>
> So while the second definition of fie is a curried definition, the first
> equivalent definition isn't.
>
> --
> David Kastrup

Indeed interesting.

Thanks again,
  Harm

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[David Kastrup]

Thomas Morley  writes:

> Though I'm not sure with the following one. May I ask: curried or not?
> (define (foo a b)
>   (let ((x2 (lambda (arg) (* 2 arg
> (map x2 (list a b

Why would that one be curried?  It's completely boring, returns a list,
and its internal function x2 is totally straightforward (not even a
closure) and is invisible to the caller.

Slightly more interesting is

(define (fie a)
  (lambda (x) (+ x a)))

which is equivalent to the curried definition

(define ((fie a) x) (+ x a))

However, the currying is not a feature of the semantics (the semantics
of returning a function or more often a closure, namely a function with
an environment in the form of variables imported into its scope) but of
the syntax.

So while the second definition of fie is a curried definition, the first
equivalent definition isn't.

-- 
David Kastrup

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2015-12-28 1:25 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> (1)
>> stencil-whiteout-box uses define*-public and optional arguments, I
>> thought it's broken in guilev2
>
> Only in connection with currying.  So
>
> (define*-public ((...
>
> is (possibly) going to cause trouble while
>
> (define*-public (...
>
> is ok.
>
Thanks for the hint.

Iiuc, than the following is a curried definition:
(define (curry-list-a a) b) c) d) e)
  (list a b c d e))

It could be rewritten as:
(define curry-list-b
  (lambda (a)
(lambda (b)
  (lambda (c)
(lambda (d)
  (lambda (e) (list a b c d e)))

guilev2 may have problems with:
(define*-public (curry-list-c a) b) c) d) e #:optional (f "x"))
  (list a b c d e f))

Though I'm not sure with the following one. May I ask: curried or not?
(define (foo a b)
  (let ((x2 (lambda (arg) (* 2 arg
(map x2 (list a b


Best,
  Harm

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Kieren MacMillan]

Hello, all!

> the bug is a consequence of issue 2504 
> .
> To fix it, just change line 89 of your attached file into
> (stencil-whiteout new-sim-stil 'outline thickness 1)

Ah! Hoisted by my own petard, as they say…
(I personally sponsored that feature!)

Thanks for the quick fix!
Kieren.


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


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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[David Kastrup]

Thomas Morley  writes:

> (1)
> stencil-whiteout-box uses define*-public and optional arguments, I
> thought it's broken in guilev2

Only in connection with currying.  So

(define*-public ((...

is (possibly) going to cause trouble while

(define*-public (...

is ok.

> If it's not ok, it should be fixed, ofcourse. Though in general, would
> dotted syntax be an alternative?
> Like (define-public (stencil-whiteout-box stil . rest) ...)

Works but may end up in less readable code where "rest" is actually
being used.

> (2)
> The doc-string for `stencil-whiteout' implies that @var{thickness} is
> optional. As far as I understand it's not.

Should it be?  Would that have saved us from the error?

-- 
David Kastrup

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2015-12-27 23:32 GMT+01:00 Kieren MacMillan :
> Argh! Here’s the attachment.
>
> Sorry for the noise,
> Kieren.
>
>
>
>
> On Dec 27, 2015, at 5:31 PM, Kieren MacMillan  
> wrote:
>
>> Hello Harm (et al.),
>>
>> Attached is the pedal stencil-altering function you wrote for me back in 
>> 2013 (v. 2.17.20).
>> (BTW: I use this function all the time. Thanks!)

Honestly, I didn't remember I wrote it. Though, I found it on my hard-disk...

>>
>> Recently, I’ve been thinking about generalizing it and submitting it as a 
>> patch, with a few small improvements (e.g., it would be great to have 
>> parameters for the trailing text and padding).

I think it'll be possible. Ofcourse as a music-function.

>> But before I got around to that, I upgraded to 2.19.34, and it’s stopped 
>> working:
>>In procedure stencil-whiteout in expression (stencil-whiteout 
>> new-sim-stil) […]
>>Wrong number of arguments to #> thickness line-thickness)>
>>
>> It seems to work fine with 2.19.31, if that helps narrow down the issue.
>> n.b. Applying convert-ly didn’t seem to fix the problem.
>>
>> If you could fix it for me, I would greatly appreciate it.
>> Even more appreciated would be to add those arbitrary text and padding 
>> parameters.  ;)


Well, the problem is quite obvious.
Paul implemented some nice whiteout-functions, though the amount of
needed arguments is different now.

Which one do you want?
You can replace stencil-whiteout with `stencil-whiteout-box' and it
should work. `stencil-whiteout' itself takes more arguments now, among
them a `style'-argument, which may be set to 'outline or 'rounded-box
and some padding is possible.

Though, I have a problem with it, thus cc-ing Paul and David

(1)
stencil-whiteout-box uses define*-public and optional arguments, I
thought it's broken in guilev2
If it's ok here I have not understood the subtletyies when usage is ok
and when not. I would appreciate any hint (link) helping me to
understand.
If it's not ok, it should be fixed, ofcourse. Though in general, would
dotted syntax be an alternative?
Like (define-public (stencil-whiteout-box stil . rest) ...)

(2)
The doc-string for `stencil-whiteout' implies that @var{thickness} is
optional. As far as I understand it's not.

Cheers,
  Harm

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Simon Albrecht]

Hello Kieren,

the bug is a consequence of issue 2504 
.

To fix it, just change line 89 of your attached file into
(stencil-whiteout new-sim-stil 'outline thickness 1)

Yours, Simon

On 27.12.2015 23:32, Kieren MacMillan wrote:

Argh! Here’s the attachment.

Sorry for the noise,
Kieren.




On Dec 27, 2015, at 5:31 PM, Kieren MacMillan  
wrote:


Hello Harm (et al.),

Attached is the pedal stencil-altering function you wrote for me back in 2013 
(v. 2.17.20).
(BTW: I use this function all the time. Thanks!)

Recently, I’ve been thinking about generalizing it and submitting it as a 
patch, with a few small improvements (e.g., it would be great to have 
parameters for the trailing text and padding). But before I got around to that, 
I upgraded to 2.19.34, and it’s stopped working:
In procedure stencil-whiteout in expression (stencil-whiteout new-sim-stil) 
[…]
Wrong number of arguments to #

It seems to work fine with 2.19.31, if that helps narrow down the issue.
n.b. Applying convert-ly didn’t seem to fix the problem.

If you could fix it for me, I would greatly appreciate it.
Even more appreciated would be to add those arbitrary text and padding 
parameters.  ;)

Thanks,
Kieren.



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



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



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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Kieren MacMillan]

Argh! Here’s the attachment.

Sorry for the noise,
Kieren.



PianoPedal_sim.ly
Description: Binary data


On Dec 27, 2015, at 5:31 PM, Kieren MacMillan  
wrote:

> Hello Harm (et al.),
> 
> Attached is the pedal stencil-altering function you wrote for me back in 2013 
> (v. 2.17.20).
> (BTW: I use this function all the time. Thanks!)
> 
> Recently, I’ve been thinking about generalizing it and submitting it as a 
> patch, with a few small improvements (e.g., it would be great to have 
> parameters for the trailing text and padding). But before I got around to 
> that, I upgraded to 2.19.34, and it’s stopped working:
>In procedure stencil-whiteout in expression (stencil-whiteout 
> new-sim-stil) […]
>Wrong number of arguments to # thickness line-thickness)>
> 
> It seems to work fine with 2.19.31, if that helps narrow down the issue.
> n.b. Applying convert-ly didn’t seem to fix the problem.
> 
> If you could fix it for me, I would greatly appreciate it.
> Even more appreciated would be to add those arbitrary text and padding 
> parameters.  ;)
> 
> Thanks,
> Kieren.


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

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Kieren MacMillan]

Hello Harm (et al.),

Attached is the pedal stencil-altering function you wrote for me back in 2013 
(v. 2.17.20).
(BTW: I use this function all the time. Thanks!)

Recently, I’ve been thinking about generalizing it and submitting it as a 
patch, with a few small improvements (e.g., it would be great to have 
parameters for the trailing text and padding). But before I got around to that, 
I upgraded to 2.19.34, and it’s stopped working:
In procedure stencil-whiteout in expression (stencil-whiteout new-sim-stil) 
[…]
Wrong number of arguments to #

It seems to work fine with 2.19.31, if that helps narrow down the issue.
n.b. Applying convert-ly didn’t seem to fix the problem.

If you could fix it for me, I would greatly appreciate it.
Even more appreciated would be to add those arbitrary text and padding 
parameters.  ;)

Thanks,
Kieren.


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


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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2013/6/14 Thomas Morley 

>
>
> 2013/6/14 Kieren MacMillan 
>
>> Hi Harm,
>>
>> it's not completely clear to me what you want to achieve.
>>
>>
>> I want this:
>>
>> 1. Best Option = adjust the stencil of the bracket so that \sustainOff
>> would print the entire grouping  "/\_  sim."
>>
>>
>> Please look at the output from the code below and tell what's good/wrong.
>>
>>
>> The "sim." is in the wrong place, and there should be an up and down and
>> small horizontal line right before it (as if the pedal bracket was
>> continuing). Here's a (horrible) example:
>>
>>
>>
>> Thanks!
>> Kieren.
>>
>
> Hi Kieran,
>
> thanks for the image. I think I understand now, will try this evening.
>
> -Harm
>

Hi Kieran,

please try the code below (same attached).
Note that the \pedalSim has to be inserted before the PianoPedalBracket
starts.
Behaviour at line-break is supported, though not widely tested.
Several comments in code.

\version "2.17.20"

\paper {
ragged-right = ##t
%% To watch the behaviour at line-break uncomment next line.
%line-width = 80
}

pedalSim =
\once \override Staff.PianoPedalBracket #'stencil =
  #(lambda (grob)
   (let* (;; have we been split?
 (orig (ly:grob-original grob))
 ;; if yes, get the split pieces (our siblings)
 (siblings (if (ly:grob? orig)
   (ly:spanner-broken-into orig)
   '(
   ;; Modify the unbroken grob-stencil or the first part of the broken
   ;; grob-stencil.
   (if (or (null? siblings)
   (and (>= (length siblings) 2)
(eq? (car siblings) grob)))
   (let* (;; Get the default-stencil and its x-dimension and x-length.
  (stil (ly:piano-pedal-bracket::print grob))
  (stil-x-extent (ly:stencil-extent stil X))
  (stil-x-length (interval-length stil-x-extent))
  ;; Create a stencil to be added to the default-stencil.
  ;; Gets its x-dimension and x-length.
  (sim-stil
 (grob-interpret-markup grob
(markup #:fontsize -1 #:italic "sim.")))
  (sim-stil-x-extent (ly:stencil-extent sim-stil X))
  (sim-stil-x-length (interval-length sim-stil-x-extent))
  (thickness (max (layout-line-thickness grob) 0.1))
  ;; The value to shorten the default-stencil from the right
side.
  ;; 0.8 will shorten about 80%.
  ;; Hard-coded, could be turned into a music-function.
  (amount 0.8))

 ;; Print a warning if the length of the default-stencil would not
 ;; warrant a sufficient output.
 (if (> sim-stil-x-length stil-x-length)
 (ly:warning "PianoPedalBracket is too short"))

 ;; Shorten the default-stencil.
 (ly:grob-set-property!
grob
'shorten-pair
(cons 0 (* amount stil-x-length)))

 ;; Calculate the final stencil.
 (let* (;; Get the shortened (default-)stencil
;; and its y-dimension.
(shortened-stil (ly:piano-pedal-bracket::print grob))
(shortened-stil-y-ext (ly:stencil-extent shortened-stil Y))
;; Modify the sim-stil to gain a little gap to the left and
;; enlarge it downwards a little (otherwise the
stencil-whiteout
;; will not work sufficient.
(new-sim-stil
  (ly:make-stencil
(ly:stencil-expr sim-stil)
(interval-widen sim-stil-x-extent (* 2 thickness))
(cons (- (car shortened-stil-y-ext) thickness)
  (cdr shortened-stil-y-ext)

   (ly:stencil-add
   shortened-stil
   (ly:stencil-translate-axis
  (stencil-whiteout new-sim-stil)
  (* (- 1 amount) (- stil-x-length sim-stil-x-length))
  X
   ;; TODO:
   ;; Is there any need to return #f explicitly?
   ;; Deleting it seems to make no difference.
   ;#f
   )))

\relative c' {
\set Staff.pedalSustainStyle = #'bracket
c4\sustainOn a e' f
\pedalSim
c\sustainOff\sustainOn a e' f'
c4\sustainOff a e' f
}


Please shout if something is wrong.


HTH,
  Harm
<>

pedal-sim-02.ly
Description: Binary data
<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2013/6/14 Kieren MacMillan 

> Hi Harm,
>
> it's not completely clear to me what you want to achieve.
>
>
> I want this:
>
> 1. Best Option = adjust the stencil of the bracket so that \sustainOff
> would print the entire grouping  "/\_  sim."
>
>
> Please look at the output from the code below and tell what's good/wrong.
>
>
> The "sim." is in the wrong place, and there should be an up and down and
> small horizontal line right before it (as if the pedal bracket was
> continuing). Here's a (horrible) example:
>
>
>
> Thanks!
> Kieren.
>

Hi Kieran,

thanks for the image. I think I understand now, will try this evening.

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

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Kieren MacMillan]

Hi Harm,it's not completely clear to me what you want to achieve.I want this:1. Best Option = adjust the stencil of the bracket so that \sustainOff would print the entire grouping  "/\_  sim."Please look at the output from the code below and tell what's good/wrong.The "sim." is in the wrong place, and there should be an up and down and small horizontal line right before it (as if the pedal bracket was continuing). Here's a (horrible) example:Thanks!Kieren.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: adding a markup ("sim.") to the end of a SustainPedalBracket

[Thomas Morley]

2013/6/13 Kieren MacMillan :
> Hello all!
>
> I would like to explicitly indicate piano pedalling (using brackets) in the 
> first measure of my score, and then put a "sim." (or similar ;) right after 
> the /\ (i.e., "up+down") marking on the downbeat of the second measure.
>
> I was hoping to do one of the two following things:
> 1. Best Option = adjust the stencil of the bracket so that \sustainOff would 
> print the entire grouping  "/\_  sim."
> 2. Acceptable = adjust the text of the \sustainOff so that it says "sim.", 
> and space it out a few skips beyond the downbeat.
>
> The docs (e.g., 
> http://www.lilypond.org/doc/v2.17/Documentation/snippets/keyboards#keyboards-changing-the-text-for-sustain-markings)
>  seem to indicate that neither is possible (e.g., "the only valid strings are 
> those found in the list of pedal glyphs").
>
> Any assistance would be appreciated.
>
> Thanks!
> Kieren.
>
> p.s. I always use the latest development version.
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

Hi Kieran,

you can always modify the stencil.
Though, it's not completely clear to me what you want to achieve.
Please look at the output from the code below and tell what's good/wrong.

\version "2.17.20"

\paper { ragged-right = ##f }

pedalSim =
\once \override Staff.PianoPedalBracket #'stencil =
  #(lambda (grob)
(let* ((sim-stil (grob-interpret-markup grob " sim"))
   (sim-stil-x-length
 (interval-length
   (ly:stencil-extent sim-stil X)))
   )

  (ly:grob-set-property! grob 'shorten-pair (cons 0 (+ 2
sim-stil-x-length)))

  (let ((stil (ly:piano-pedal-bracket::print grob)))
(ly:stencil-combine-at-edge
  stil
  X
  RIGHT
  sim-stil
  0

\relative c' {
\set Staff.pedalSustainStyle = #'bracket
\pedalSim
c4\sustainOn d e\sustainOff\sustainOn f\sustainOff
}


Cheers,
  Harm

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

adding a markup ("sim.") to the end of a SustainPedalBracket

[Kieren MacMillan]

Hello all!

I would like to explicitly indicate piano pedalling (using brackets) in the 
first measure of my score, and then put a "sim." (or similar ;) right after the 
/\ (i.e., "up+down") marking on the downbeat of the second measure.

I was hoping to do one of the two following things:
1. Best Option = adjust the stencil of the bracket so that \sustainOff would 
print the entire grouping  "/\_  sim."
2. Acceptable = adjust the text of the \sustainOff so that it says "sim.", and 
space it out a few skips beyond the downbeat.

The docs (e.g., 
http://www.lilypond.org/doc/v2.17/Documentation/snippets/keyboards#keyboards-changing-the-text-for-sustain-markings)
 seem to indicate that neither is possible (e.g., "the only valid strings are 
those found in the list of pedal glyphs").

Any assistance would be appreciated.

Thanks!
Kieren.

p.s. I always use the latest development version.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user