Re: arpeggioArrowUp
2015-01-29 18:08 GMT+01:00 tisimst :
> Noeck wrote
>> Dear Harm,
>>
>> Am 15.01.2015 um 03:22 schrieb Thomas Morley:
>>> arpeggioUp =
>>> -\tweak #'stencil #ly:arpeggio::print
>>> -\tweak #'X-extent #ly:arpeggio::width
>>> -\tweak #'arpeggio-direction #UP
>>> \arpeggio
>>
>> I came back to this today and I like this simple approach most.
>>
>> One more question: what are the first two tweaks needed for?
>> I see no difference if I omit them.
>
> +1*10!
> Oh! That is very nice!
>
> The first two tweaks revert the arpeggio to the squiggle when the user has
> otherwise used "\arpeggioBracket" or similar, like:
>
> %<-- SNIP -
>
> \version "2.18.2"
>
> arpeggioUp =
> -\tweak #'stencil #ly:arpeggio::print
> -\tweak #'X-extent #ly:arpeggio::width
> -\tweak #'arpeggio-direction #UP
> \arpeggio
>
> arpeggioDown =
> -\tweak #'stencil #ly:arpeggio::print
> -\tweak #'X-extent #ly:arpeggio::width
> -\tweak #'arpeggio-direction #DOWN
> \arpeggio
>
> \relative c'' {
> \arpeggioBracket
> 4\arpeggioUp
> q\arpeggio % <--- still uses the bracket
> q\arpeggioDown
> }
>
> %<-- SNIP -
>
> I really like this "-\tweak" approach because it automatically only applies
> the changes to the current chord and is easily repeatable without much extra
> typing. Nice work, Harm!
>
> Anyone willing to help get this (and similar code for "arpeggioDown") pushed
> into "property-init.ly"? Shouldn't be too hard to get through and would be a
> nice (i.e., more intuitive) syntax, especially for new users, IMHO.
>
> In fact, all the different arpeggio types could be converted to the
> "-\tweak" syntax and I think that it would make them all a little easier to
> use.
>
> -Abraham
Hi Abraham,
I've currently not the time to create a patch and write the necessary
documentation.
Though, I had once more a look at it and I'm not convinced that we
should change all the commands to tweak commands for some reasons:
%%%
1)
%%%
arpeggioArrowUp is currently defined as
arpeggioArrowUp = {
\revert Arpeggio.stencil
\revert Arpeggio.X-extent
\override Arpeggio.arpeggio-direction = #UP
}
That makes it possible to set it in layout, a tweak would not work.
I'm never a friend of _loosing_ functionality, although I've to admit
putting arpeggioArrowUp into layout may be a very rare case.
It could be _added_, though.
%%%
2)
%%%
To revert a previous user-command affecting the stencil I inserted the
_default_ procedure. (Same for X-extent)
This will not always lead to the same results compared with reverting
a previous stencil-_override_.
See the following example where I demonstrate stencil overrides and
reverts and a tweak (with default-stencil-procedure) for different
stencil-colors of Fingering.
You will see there's a difference between the tweak and the first revert.
\version "2.19.15"
clr-fing-stil-override =
#(define-music-function (parser location clr)(color?)
;; a shortcut for outputting a colored stencil
#{
\override Fingering.stencil =
#(lambda (grob)
(stencil-with-color
(ly:text-interface::print grob)
clr))
#})
\score {
\relative c' {
1
\temporary \clr-fing-stil-override #red
1
\revert Fingering.stencil
\revert Fingering.stencil
}
\layout {
\clr-fing-stil-override #green
}
}
I don't know a method to _revert_ an override from inside a tweak. I
doubt it's possible.
Ofcourse an entry to "known issues and warnings" could be created.
%%%
3)
%%%
It mixes affecting the printed output and music.
I'm not a friend of it.
Though, maybe acceptable as syntactic sugar ...
So far my concerns.
The way to proceed would be to discuss it on devel, imho.
Or to put up a patch for review.
Though again, I've not the time for it right now.
(If I can spare some time, I'll start to rewrite chord-namings...)
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Am 29.01.2015 um 18:08 schrieb tisimst: > Nice work, Harm! +1 > Anyone willing to help get this (and similar code for "arpeggioDown") pushed > into "property-init.ly"? Shouldn't be too hard to get through and would be a > nice (i.e., more intuitive) syntax, especially for new users, IMHO. +1 I also think this would make it easier and more intuitive. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Noeck wrote
> Dear Harm,
>
> Am 15.01.2015 um 03:22 schrieb Thomas Morley:
>> arpeggioUp =
>> -\tweak #'stencil #ly:arpeggio::print
>> -\tweak #'X-extent #ly:arpeggio::width
>> -\tweak #'arpeggio-direction #UP
>> \arpeggio
>
> I came back to this today and I like this simple approach most.
>
> One more question: what are the first two tweaks needed for?
> I see no difference if I omit them.
+1*10!
Oh! That is very nice!
The first two tweaks revert the arpeggio to the squiggle when the user has
otherwise used "\arpeggioBracket" or similar, like:
%<-- SNIP -
\version "2.18.2"
arpeggioUp =
-\tweak #'stencil #ly:arpeggio::print
-\tweak #'X-extent #ly:arpeggio::width
-\tweak #'arpeggio-direction #UP
\arpeggio
arpeggioDown =
-\tweak #'stencil #ly:arpeggio::print
-\tweak #'X-extent #ly:arpeggio::width
-\tweak #'arpeggio-direction #DOWN
\arpeggio
\relative c'' {
\arpeggioBracket
4\arpeggioUp
q\arpeggio % <--- still uses the bracket
q\arpeggioDown
}
%<-- SNIP -
I really like this "-\tweak" approach because it automatically only applies
the changes to the current chord and is easily repeatable without much extra
typing. Nice work, Harm!
Anyone willing to help get this (and similar code for "arpeggioDown") pushed
into "property-init.ly"? Shouldn't be too hard to get through and would be a
nice (i.e., more intuitive) syntax, especially for new users, IMHO.
In fact, all the different arpeggio types could be converted to the
"-\tweak" syntax and I think that it would make them all a little easier to
use.
-Abraham
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/arpeggioArrowUp-tp170464p171231.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Dear Harm, Am 15.01.2015 um 03:22 schrieb Thomas Morley: > arpeggioUp = > -\tweak #'stencil #ly:arpeggio::print > -\tweak #'X-extent #ly:arpeggio::width > -\tweak #'arpeggio-direction #UP > \arpeggio I came back to this today and I like this simple approach most. One more question: what are the first two tweaks needed for? I see no difference if I omit them. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Thank you Harm. Cheers, Pierre ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
2015-01-17 1:59 GMT+01:00 Thomas Morley :
> 2015-01-16 1:42 GMT+01:00 Thomas Morley :
>> 2015-01-16 0:26 GMT+01:00 Thomas Morley :
>>> 2015-01-15 15:02 GMT+01:00 tisimst :
On Wed, Jan 14, 2015 at 11:47 PM, Schneidy [via Lilypond] <[hidden email]>
wrote:
Hi Harm,
2015-01-15 3:22 GMT+01:00 Thomas Morley <[hidden email]>:
>
> foo =
> #(define-music-function (parser location mus)(ly:music?)
> (music-map
> (lambda (m)
> (if (music-is-of-type? m 'arpeggio-event)
> (make-music
> 'ArpeggioEvent
> 'tweaks
> (list
>(cons 'arpeggio-direction
> (ly:music-property m 'direction
> m))
> mus))
>
>
> \foo
> \relative c'' {
> \mark "sort of post-processing"
> 4\arpeggio
> 4^\arpeggio
> 4_\arpeggio
> }
I like this one.
Cheers,
Pierre
+1!
However, I'd rather not have to use another function (\foo) to do this.
Otherwise, I don't think there's any benefit over what is currently
required
with \arpeggioArrowUp. Can't it be put directly into a command that
supports
the direction indicators? I can't seem to find in the documentation where
the post-fix syntax is described.
-Abraham
>>>
>>>
>>>
>>> The direction indicators _ and ^ are setting the 'direction, as their
>>> name suggests ;).
>>> Though the arpeggio-arrow is printed, if the _'arpeggio-direction_ is set!
>>> Currently those are two different things. It may be discussable, if it
>>> _should_ be this way, but it has some logic, if you think about it.
>>> Nevertheless my 'foo'-function iterated through the music, setting
>>> 'arpeggio-direction to the value of 'direction.
>>> This is not very cheap, maybe better to use an engraver for this duty:
>>>
>>> \version "2.19.15"
>>>
>>> direction-to-arpeggio-direction-engraver =
>>> #(lambda (context)
>>> (let ((dir '()))
>>> `((listeners
>>> (arpeggio-event
>>>.
>>>,(lambda (engraver event)
>>> ;; Not sure about following 'set!'
>>> ;; Is it save?
>>> (set! dir (ly:event-property event 'direction)
>>> (acknowledgers
>>> (arpeggio-interface
>>>.
>>>,(lambda (engraver grob source-engraver)
>>> (set! (ly:grob-property grob 'arpeggio-direction) dir)
>>> (set! dir '(
>>>
>>
>>
>>
>> %% c/p error, here the whole example:
>>
>>
>> %% EXAMPLE
>>
>>
>> \layout {
>> \context {
>> \Score
>> \consists #direction-to-arpeggio-direction-engraver
>> }
>> }
>>
>> \relative c'' {
>> 4\arpeggio
>> 4^\arpeggio
>> 4_\arpeggio
>> }
>
> Here an improved version, works cross-context as well:
>
> \version "2.19.15"
>
> \paper { indent = 0 }
>
> direction-to-arpeggio-direction-engraver =
> #(lambda (context)
> (let ((dir '()))
> `((listeners
> (arpeggio-event
>.
>,(lambda (engraver event)
> ;; Not sure about following 'set!'
> ;; Is it save?
> (set! dir (ly:event-property event 'direction))
> ;; Is this needed?
> ;(ly:event-set-property! event 'direction '())
> )))
> (acknowledgers
> (arpeggio-interface
>.
>,(lambda (engraver grob source-engraver)
> (set! (ly:grob-property grob 'arpeggio-direction) dir)))
>
>
> %% EXAMPLES
>
>
> \new Staff \with { \consists #direction-to-arpeggio-direction-engraver }
> \relative c'' {
> 4\arpeggio
> 4^\arpeggio
> 4_\arpeggio
> }
>
> %% Note:
> %% If used cross-context, only the last direction-indicator
> %% for each time-step counts
> \new Staff
> \with {
> \consists "Span_arpeggio_engraver"
> \consists #direction-to-arpeggio-direction-engraver
> }
> \relative c' {
> \set Staff.connectArpeggios = ##t
> <<
> \new Voice { \voiceOne 4\arpeggio 2\arpeggio }
> \new Voice { \voiceTwo 2^\arpeggio 2_\arpeggio }
> >>
> }
>
> \new PianoStaff
> \with {
> \consists #direction-to-arpeggio-direction-engraver
> }
> <<
> \set PianoStaff.connectArpeggios = ##t
> \new Staff {
> \relative c' {
> \key b \major
> \time 6/8
> b8-.(^\arpeggio fis'-.\> cis-. e-. gis-. b-.)\!\fermata^\laissezVibrer
> \bar "||"
> }
> }
> \new Staff {
> \relative c' {
> \clef bass
> \key b \major
> <<
> {
> 2\arpeggio
> }
> \\
> {
> 2.^\arpeggio
> }
> >>
> }
> }
> >>
Delete the following. It's some syntax-testing, copied by accident
> \score {
> \relative c'' {
> \markLengthOn
>
> <>^"default"
> 4\arpeggio
>
> <>^"^ indicator"
> 4^\arpeggio
>
> <>
Re: arpeggioArrowUp
2015-01-16 1:42 GMT+01:00 Thomas Morley :
> 2015-01-16 0:26 GMT+01:00 Thomas Morley :
>> 2015-01-15 15:02 GMT+01:00 tisimst :
>>> On Wed, Jan 14, 2015 at 11:47 PM, Schneidy [via Lilypond] <[hidden email]>
>>> wrote:
>>>
>>> Hi Harm,
>>>
>>> 2015-01-15 3:22 GMT+01:00 Thomas Morley <[hidden email]>:
>>>
foo =
#(define-music-function (parser location mus)(ly:music?)
(music-map
(lambda (m)
(if (music-is-of-type? m 'arpeggio-event)
(make-music
'ArpeggioEvent
'tweaks
(list
(cons 'arpeggio-direction
(ly:music-property m 'direction
m))
mus))
\foo
\relative c'' {
\mark "sort of post-processing"
4\arpeggio
4^\arpeggio
4_\arpeggio
}
>>>
>>>
>>> I like this one.
>>> Cheers,
>>> Pierre
>>>
>>>
>>> +1!
>>>
>>> However, I'd rather not have to use another function (\foo) to do this.
>>> Otherwise, I don't think there's any benefit over what is currently required
>>> with \arpeggioArrowUp. Can't it be put directly into a command that supports
>>> the direction indicators? I can't seem to find in the documentation where
>>> the post-fix syntax is described.
>>>
>>> -Abraham
>>
>>
>>
>> The direction indicators _ and ^ are setting the 'direction, as their
>> name suggests ;).
>> Though the arpeggio-arrow is printed, if the _'arpeggio-direction_ is set!
>> Currently those are two different things. It may be discussable, if it
>> _should_ be this way, but it has some logic, if you think about it.
>> Nevertheless my 'foo'-function iterated through the music, setting
>> 'arpeggio-direction to the value of 'direction.
>> This is not very cheap, maybe better to use an engraver for this duty:
>>
>> \version "2.19.15"
>>
>> direction-to-arpeggio-direction-engraver =
>> #(lambda (context)
>> (let ((dir '()))
>> `((listeners
>> (arpeggio-event
>>.
>>,(lambda (engraver event)
>> ;; Not sure about following 'set!'
>> ;; Is it save?
>> (set! dir (ly:event-property event 'direction)
>> (acknowledgers
>> (arpeggio-interface
>>.
>>,(lambda (engraver grob source-engraver)
>> (set! (ly:grob-property grob 'arpeggio-direction) dir)
>> (set! dir '(
>>
>
>
>
> %% c/p error, here the whole example:
>
>
> %% EXAMPLE
>
>
> \layout {
> \context {
> \Score
> \consists #direction-to-arpeggio-direction-engraver
> }
> }
>
> \relative c'' {
> 4\arpeggio
> 4^\arpeggio
> 4_\arpeggio
> }
Here an improved version, works cross-context as well:
\version "2.19.15"
\paper { indent = 0 }
direction-to-arpeggio-direction-engraver =
#(lambda (context)
(let ((dir '()))
`((listeners
(arpeggio-event
.
,(lambda (engraver event)
;; Not sure about following 'set!'
;; Is it save?
(set! dir (ly:event-property event 'direction))
;; Is this needed?
;(ly:event-set-property! event 'direction '())
)))
(acknowledgers
(arpeggio-interface
.
,(lambda (engraver grob source-engraver)
(set! (ly:grob-property grob 'arpeggio-direction) dir)))
%% EXAMPLES
\new Staff \with { \consists #direction-to-arpeggio-direction-engraver }
\relative c'' {
4\arpeggio
4^\arpeggio
4_\arpeggio
}
%% Note:
%% If used cross-context, only the last direction-indicator
%% for each time-step counts
\new Staff
\with {
\consists "Span_arpeggio_engraver"
\consists #direction-to-arpeggio-direction-engraver
}
\relative c' {
\set Staff.connectArpeggios = ##t
<<
\new Voice { \voiceOne 4\arpeggio 2\arpeggio }
\new Voice { \voiceTwo 2^\arpeggio 2_\arpeggio }
>>
}
\new PianoStaff
\with {
\consists #direction-to-arpeggio-direction-engraver
}
<<
\set PianoStaff.connectArpeggios = ##t
\new Staff {
\relative c' {
\key b \major
\time 6/8
b8-.(^\arpeggio fis'-.\> cis-. e-. gis-. b-.)\!\fermata^\laissezVibrer
\bar "||"
}
}
\new Staff {
\relative c' {
\clef bass
\key b \major
<<
{
2\arpeggio
}
\\
{
2.^\arpeggio
}
>>
}
}
>>
\score {
\relative c'' {
\markLengthOn
<>^"default"
4\arpeggio
<>^"^ indicator"
4^\arpeggio
<>^"direction-tweak"
4-\tweak #'direction #RIGHT \arpeggio
<>^"direction-override"
\once \override Arpeggio.direction = #RIGHT
4\arpeggio
}
\layout {
ragged-right = ##f
}
}
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
2015-01-16 0:26 GMT+01:00 Thomas Morley :
> 2015-01-15 15:02 GMT+01:00 tisimst :
>> On Wed, Jan 14, 2015 at 11:47 PM, Schneidy [via Lilypond] <[hidden email]>
>> wrote:
>>
>> Hi Harm,
>>
>> 2015-01-15 3:22 GMT+01:00 Thomas Morley <[hidden email]>:
>>
>>>
>>> foo =
>>> #(define-music-function (parser location mus)(ly:music?)
>>> (music-map
>>> (lambda (m)
>>> (if (music-is-of-type? m 'arpeggio-event)
>>> (make-music
>>> 'ArpeggioEvent
>>> 'tweaks
>>> (list
>>>(cons 'arpeggio-direction
>>> (ly:music-property m 'direction
>>> m))
>>> mus))
>>>
>>>
>>> \foo
>>> \relative c'' {
>>> \mark "sort of post-processing"
>>> 4\arpeggio
>>> 4^\arpeggio
>>> 4_\arpeggio
>>> }
>>
>>
>> I like this one.
>> Cheers,
>> Pierre
>>
>>
>> +1!
>>
>> However, I'd rather not have to use another function (\foo) to do this.
>> Otherwise, I don't think there's any benefit over what is currently required
>> with \arpeggioArrowUp. Can't it be put directly into a command that supports
>> the direction indicators? I can't seem to find in the documentation where
>> the post-fix syntax is described.
>>
>> -Abraham
>
>
>
> The direction indicators _ and ^ are setting the 'direction, as their
> name suggests ;).
> Though the arpeggio-arrow is printed, if the _'arpeggio-direction_ is set!
> Currently those are two different things. It may be discussable, if it
> _should_ be this way, but it has some logic, if you think about it.
> Nevertheless my 'foo'-function iterated through the music, setting
> 'arpeggio-direction to the value of 'direction.
> This is not very cheap, maybe better to use an engraver for this duty:
>
> \version "2.19.15"
>
> direction-to-arpeggio-direction-engraver =
> #(lambda (context)
> (let ((dir '()))
> `((listeners
> (arpeggio-event
>.
>,(lambda (engraver event)
> ;; Not sure about following 'set!'
> ;; Is it save?
> (set! dir (ly:event-property event 'direction)
> (acknowledgers
> (arpeggio-interface
>.
>,(lambda (engraver grob source-engraver)
> (set! (ly:grob-property grob 'arpeggio-direction) dir)
> (set! dir '(
>
%% c/p error, here the whole example:
%% EXAMPLE
\layout {
\context {
\Score
\consists #direction-to-arpeggio-direction-engraver
}
}
\relative c'' {
4\arpeggio
4^\arpeggio
4_\arpeggio
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
2015-01-15 15:02 GMT+01:00 tisimst :
> On Wed, Jan 14, 2015 at 11:47 PM, Schneidy [via Lilypond] <[hidden email]>
> wrote:
>
> Hi Harm,
>
> 2015-01-15 3:22 GMT+01:00 Thomas Morley <[hidden email]>:
>
>>
>> foo =
>> #(define-music-function (parser location mus)(ly:music?)
>> (music-map
>> (lambda (m)
>> (if (music-is-of-type? m 'arpeggio-event)
>> (make-music
>> 'ArpeggioEvent
>> 'tweaks
>> (list
>>(cons 'arpeggio-direction
>> (ly:music-property m 'direction
>> m))
>> mus))
>>
>>
>> \foo
>> \relative c'' {
>> \mark "sort of post-processing"
>> 4\arpeggio
>> 4^\arpeggio
>> 4_\arpeggio
>> }
>
>
> I like this one.
> Cheers,
> Pierre
>
>
> +1!
>
> However, I'd rather not have to use another function (\foo) to do this.
> Otherwise, I don't think there's any benefit over what is currently required
> with \arpeggioArrowUp. Can't it be put directly into a command that supports
> the direction indicators? I can't seem to find in the documentation where
> the post-fix syntax is described.
>
> -Abraham
The direction indicators _ and ^ are setting the 'direction, as their
name suggests ;).
Though the arpeggio-arrow is printed, if the _'arpeggio-direction_ is set!
Currently those are two different things. It may be discussable, if it
_should_ be this way, but it has some logic, if you think about it.
Nevertheless my 'foo'-function iterated through the music, setting
'arpeggio-direction to the value of 'direction.
This is not very cheap, maybe better to use an engraver for this duty:
\version "2.19.15"
direction-to-arpeggio-direction-engraver =
#(lambda (context)
(let ((dir '()))
`((listeners
(arpeggio-event
.
,(lambda (engraver event)
;; Not sure about following 'set!'
;; Is it save?
(set! dir (ly:event-property event 'direction)
(acknowledgers
(arpeggio-interface
.
,(lambda (engraver grob source-engraver)
(set! (ly:grob-property grob 'arpeggio-direction) dir)
(set! dir '(
%% EXAMPLE
\layout {
\context {
\Score
\consists #direction-to-arpeggio-direction-engraver
}
}
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
On Wed, Jan 14, 2015 at 11:47 PM, Schneidy [via Lilypond]
wrote:
> Hi Harm,
>
> 2015-01-15 3:22 GMT+01:00 Thomas Morley <[hidden email]>:
>
>> foo =
>> #(define-music-function (parser location mus)(ly:music?)
>> (music-map
>> (lambda (m)
>> (if (music-is-of-type? m 'arpeggio-event)
>> (make-music
>> 'ArpeggioEvent
>> 'tweaks
>> (list
>>(cons 'arpeggio-direction
>> (ly:music-property m 'direction
>> m))
>> mus))
>>
>>
>> \foo
>> \relative c'' {
>> \mark "sort of post-processing"
>> 4\arpeggio
>> 4^\arpeggio
>> 4_\arpeggio
>> }
>
> I like this one.
> Cheers,
> Pierre
+1!
However, I'd rather not have to use another function (\foo) to do this.
Otherwise, I don't think there's any benefit over what is currently
required with \arpeggioArrowUp. Can't it be put directly into a command
that supports the direction indicators? I can't seem to find in the
documentation where the post-fix syntax is described.
-Abraham
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/arpeggioArrowUp-tp170464p170519.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Hi Harm,
2015-01-15 3:22 GMT+01:00 Thomas Morley :
> foo =
> #(define-music-function (parser location mus)(ly:music?)
> (music-map
> (lambda (m)
> (if (music-is-of-type? m 'arpeggio-event)
> (make-music
> 'ArpeggioEvent
> 'tweaks
> (list
>(cons 'arpeggio-direction
> (ly:music-property m 'direction
> m))
> mus))
>
>
> \foo
> \relative c'' {
> \mark "sort of post-processing"
> 4\arpeggio
> 4^\arpeggio
> 4_\arpeggio
> }
>
I like this one.
Cheers,
Pierre
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
2015-01-14 22:12 GMT+01:00 Noeck :
> Hi Abraham,
>
> Am 14.01.2015 um 17:24 schrieb tisimst:
>> P.S. I'm with Alistair, though. Is there any reason \arpeggioArrow[Up/Down]
>> isn't designed to work by itself rather than requiring another explicit
>> \arpeggio?
>
> I think, it is simply implemented in analogy to all the other Up/Down/Neutral
> settings: { \slurUp a( a) \slurNeutral a( a) } etc.
> In that sense it is very consistent: You set the direction before you use it
> and
> it is valid until you reset the direction to netural again. It is just a
> shortcut for overrides as the other direction settings are.
>
> However, I feel like the arpeggio is a bit odd in this list:
> arpeggio, slurs, phrasing slurs, stems, tuplet brackets, augmentation dots
> etc.
> first because it is more often than not a one-time thing and second because it
> is written in a long form anyway: '\arpeggio' and not like slurs '(' or
> implicitly by the duration '4.'. So writing '\arpeggioUp' would not hurt. And,
> in contrast to slur for example, the direction markers ^ and _ do not work to
> set the direction of the arpeggio arrow.
>
> So I understand why it works the way it is – and it has some logic – but at
> the
> same time I understand you, that there would be more straight forward (more
> easy
> to understand) solutions. It is perhaps a case where consistency is not the
> primary goal.
>
> Cheers,
> Joram
Some coding ideas, not all convincing, imho.
Just a little brain-storming:
\version "2.19.15"
\paper { indent = 0 }
\layout {
\markLengthOn
\override Score.RehearsalMark.self-alignment-X = #LEFT
}
arpeggioUp =
-\tweak #'stencil #ly:arpeggio::print
-\tweak #'X-extent #ly:arpeggio::width
-\tweak #'arpeggio-direction #UP
\arpeggio
\relative c'' {
\mark "\"default\""
2\arpeggio
\mark "\"some overrides applied\""
\override Arpeggio.stencil =
#(lambda (grob) (grob-interpret-markup grob "xy"))
\override Arpeggio.X-extent = #'(0 . 5)
\arpeggio
\mark
\markup
\column { "\"new short-cut\"" "\"previous overrides not in action\"" }
\arpeggioUp
\mark "\"overrides persists!\""
\arpeggio
\mark "\"arpeggioArrowUp clears overrides\""
\arpeggioArrowUp
\arpeggio
\arpeggio
}
foo =
#(define-music-function (parser location mus)(ly:music?)
(music-map
(lambda (m)
(if (music-is-of-type? m 'arpeggio-event)
(make-music
'ArpeggioEvent
'tweaks
(list
(cons 'arpeggio-direction
(ly:music-property m 'direction
m))
mus))
\foo
\relative c'' {
\mark "sort of post-processing"
4\arpeggio
4^\arpeggio
4_\arpeggio
}
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Hi Abraham,
Am 14.01.2015 um 17:24 schrieb tisimst:
> P.S. I'm with Alistair, though. Is there any reason \arpeggioArrow[Up/Down]
> isn't designed to work by itself rather than requiring another explicit
> \arpeggio?
I think, it is simply implemented in analogy to all the other Up/Down/Neutral
settings: { \slurUp a( a) \slurNeutral a( a) } etc.
In that sense it is very consistent: You set the direction before you use it and
it is valid until you reset the direction to netural again. It is just a
shortcut for overrides as the other direction settings are.
However, I feel like the arpeggio is a bit odd in this list:
arpeggio, slurs, phrasing slurs, stems, tuplet brackets, augmentation dots etc.
first because it is more often than not a one-time thing and second because it
is written in a long form anyway: '\arpeggio' and not like slurs '(' or
implicitly by the duration '4.'. So writing '\arpeggioUp' would not hurt. And,
in contrast to slur for example, the direction markers ^ and _ do not work to
set the direction of the arpeggio arrow.
So I understand why it works the way it is – and it has some logic – but at the
same time I understand you, that there would be more straight forward (more easy
to understand) solutions. It is perhaps a case where consistency is not the
primary goal.
Cheers,
Joram
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
tisimst and Hwaen - Thanks for your replies. Like may things, the answer is simple once it is pointed out to you. Alistair -- View this message in context: http://lilypond.1069038.n5.nabble.com/arpeggioArrowUp-tp170464p170478.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
Greetings Alistair,
The solution is actually quite simple. \arpeggioArrowUp is an override
setting of \arpeggio, so it must be entered before the chord you want
arpeggiated. Then, append \arpeggio to your chord, and all should be
fine. But remember then to revert to the arpeggio default with
\arpeggioNormal, otherwise, all future arpeggiated chords will be
altered!
Hwaen Ch'uqi
On 1/14/15, Alistair Millar wrote:
> I hope this is enough. Thanks
>
> \version "2.18.2"
>
> \language "english"
>
> \relative c'
>
> {
> \clef "treble"
> \time 4/4
> \key g \major
>
> 4\arpeggio
> 4\arpeggioArrowUp
>
> \bar "|."
>
> }
>
>
>
> --
> View this message in context:
> http://lilypond.1069038.n5.nabble.com/arpeggioArrowUp-tp170464p170466.html
> Sent from the User mailing list archive at Nabble.com.
>
> ___
> 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: arpeggioArrowUp
Alistair Millar wrote
> I hope this is enough. Thanks
>
> \version "2.18.2"
>
> \language "english"
>
> \relative c'
>
> {
> \clef "treble"
> \time 4/4
> \key g \major
>
>
>
> 4\arpeggio
>
>
> 4\arpeggioArrowUp
>
> \bar "|."
>
> }
Alistair,
It does work, just not in the way you (or I) think it should. Here's an
example of how you use it:
{ \arpeggioArrowUp \arpeggio }
Does that help? In words, you need both, putting the \arpeggioArrow[Up/Down]
PRIOR to the music where the actual arpeggio is.
Regards,
Abraham
P.S. I'm with Alistair, though. Is there any reason \arpeggioArrow[Up/Down]
isn't designed to work by itself rather than requiring another explicit
\arpeggio? I don't know. Looking at the internals, \arpeggioArrow[Up/Down]
are just a couple of overrides, so I don't know why it couldn't be wrapped
in a function like:
arpeggioUp = #(define-music-function (parser location music) (ly:music?)
#{
\arpeggioArrowUp $music\arpeggio
#})
But for some reason, this code isn't working. Any ideas of what I'm missing,
anyone? If it worked, it would be then as easy as:
\arpeggioUp
Though it would be preferred to have it be:
\arpeggioUp
but I haven't looked deeply enough into this. Just saying...
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/arpeggioArrowUp-tp170464p170468.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
I hope this is enough. Thanks
\version "2.18.2"
\language "english"
\relative c'
{
\clef "treble"
\time 4/4
\key g \major
4\arpeggio
4\arpeggioArrowUp
\bar "|."
}
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/arpeggioArrowUp-tp170464p170466.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: arpeggioArrowUp
- Original Message - From: "Alistair Millar" To: Sent: Wednesday, January 14, 2015 3:40 PM Subject: arpeggioArrowUp Can anyone tell me why \arpeggio works OK but \arpeggioArrowUp does not? When I use it, no arpeggio line is displayed, not even one without an arrow. Thanks Alistair Millar Edinburgh Could you provide a short, non-working example for us to see? -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp and polyphony
Oohhh!
Yes! Yes! Yes!
Thank you!
> No arrow on the arpeggio with 2.15.8 either, but you can use the following:
>
> \version "2.15.7"
>
> \paper { ragged-right = ##t }
>
> \new Staff
> \with
> {
> \consists "Span_arpeggio_engraver"
> }
>
> \relative c''
> {
> \set Staff.connectArpeggios = ##t
> \override Staff.Arpeggio #'arpeggio-direction = #UP
> <<
> { ces\arpeggio }
> \\
> { es,\arpeggio }
>
> }
--
oiram/bin/selom
MkarlM-HomePage
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp and polyphony
On 19/08/11 01:57, Mario Moles wrote:
> Your code compiles fine, giving a nice output with 2.14.2 ! ???
>
> Harm
You are sure? Your pdf output print the arrow?
In the mine no!
No arrow on the arpeggio with 2.15.8 either, but you can use the following:
\version "2.15.7"
\paper { ragged-right = ##t }
\new Staff
\with
{
\consists "Span_arpeggio_engraver"
}
\relative c''
{
\set Staff.connectArpeggios = ##t
\override Staff.Arpeggio #'arpeggio-direction = #UP
<<
{ ces\arpeggio }
\\
{ es,\arpeggio }
>>
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp and polyphony
> Your code compiles fine, giving a nice output with 2.14.2 ! ??? > > Harm You are sure? Your pdf output print the arrow? In the mine no! -- oiram/bin/selom MkarlM-HomePage ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp and polyphony
oiram73 wrote:
>
> Hi!
> \arpeggioArrowUp don't work in the polyphony!
> \version "2.15.7"
> \paper { ragged-right = ##t }
> \new Staff
> \with
> {
> \consists "Span_arpeggio_engraver"
> }
> \relative c''
> {
> \set Staff.connectArpeggios = ##t
> <<
> {\arpeggioArrowUp ces\arpeggio}
> \\
> {\arpeggioArrowUp es,\arpeggio }
> >>
> }
>
> --
> oiram/bin/selom
> MkarlM-HomePage
>
Your code compiles fine, giving a nice output with 2.14.2 ! ???
Harm
--
View this message in context:
http://old.nabble.com/%5CarpeggioArrowUp-and-polyphony-tp32288350p32288521.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Jonathan Wilkes wrote: > I guess I would have expected \arpeggioArrowUp to affect all the > following arpeggios, regardless of whether they are connected or not. > > What do you think? Ah, I put a "context" where I meant to put a "parent". This is why I need someone to test this stuff. You can fix it this way: In the block that starts #(define move-arpeggio-to-this-context a couple lines below that, there's a line that says (let* ((Arpeggio (ly:context-grob-definition context 'Arpeggio)) Change it to (let* ((Arpeggio (ly:context-grob-definition parent 'Arpeggio)) That should fix it (hopefully it doesn't break something else). Any other observations? This is helpful. Thanks so much for testing this. - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
--- On Mon, 8/3/09, Mark Polesky wrote:
> From: Mark Polesky
> Subject: Re: \arpeggioArrowUp across staves
> To: "Jonathan Wilkes" , "Mats Bengtsson"
> , "lilypond-user"
> Date: Monday, August 3, 2009, 2:05 AM
>
> Jonathan Wilkes wrote:
> > I think a note about "arrowed" arpeggios that cross
> staves would
> > be helpful under the Arpeggios->"Known issues and
> warnings"
> > subheading in NR 1.3.3. There's such a note
> about cross-staff
> > tremolos being tricky, which saved me from trying a
> bunch of
> > unnecessary tweaks to get them to work.
>
> Jonathan,
>
> I made an attempt to rewrite the arpeggio commands so
> they'd be
> more intuitive for the user, and I'd like to see of someone
> can
> test it out. You don't have to, but I'm hoping you'll be
> interested.
>
> Of course, if anyone else would like to experiment with
> this,
> that would be great. I'd be curious to know if anything
> comes out
> differently than you'd expect or if anything just comes out
> plain
> wrong. Feel free to try fancy things to see what the limits
> are.
>
> Also notice that the syntax has been simplified. So don't
> use
> these anymore:
> \set PianoStaff.connectArpeggios = ##t
> \set PianoStaff.connectArpeggios = ##f
>
> Use these instead:
> \connectArpeggiosOn
> \connectArpeggiosOff
>
> Also, don't use this type of thing anymore:
> \override PianoStaff.Arpeggio #'arpeggio-direction = #UP
>
> Use these commands in all situations (connected and
> unconnected):
> \arpeggioArrowUp
> \arpeggioArrowDown
> \arpeggioNormal
> \arpeggioBracket
>
> These are still not to be used in connected situations:
> \arpeggioParenthesis
> \arpeggioParenthesisDashed
>
> The file is here:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-08/txtDIrSYMGg1c.txt
>
> You can start with the example given at the bottom of that
> file
> and go from there.
>
> Thanks!
> - Mark
Hi Mark,
I just tried it, and made some changes to the demo to see what
happens:
\new PianoStaff \relative <<
\new Staff {
\arpeggioArrowDown
4\arpeggio
\connectArpeggiosOn
\arpeggioArrowUp
4\arpeggio
4\arpeggio
\connectArpeggiosOff
\arpeggio
}
\new Staff {
\clef bass
4\arpeggio
\arpeggio
\arpeggio
}
>>
I notice that \arpeggioArrowUp applies to both connected arpeggios.
Once you turn it back off, it reverts back to \arpeggioArrowDown.
I guess I would have expected \arpeggioArrowUp to affect all the following
arpeggios, regardless of whether they are connected or not.
What do you think?
I'll try messing with the brackets too when I get a chance.
-Jonathan
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Jonathan Wilkes wrote: > I think a note about "arrowed" arpeggios that cross staves would > be helpful under the Arpeggios->"Known issues and warnings" > subheading in NR 1.3.3. There's such a note about cross-staff > tremolos being tricky, which saved me from trying a bunch of > unnecessary tweaks to get them to work. Jonathan, I made an attempt to rewrite the arpeggio commands so they'd be more intuitive for the user, and I'd like to see of someone can test it out. You don't have to, but I'm hoping you'll be interested. Of course, if anyone else would like to experiment with this, that would be great. I'd be curious to know if anything comes out differently than you'd expect or if anything just comes out plain wrong. Feel free to try fancy things to see what the limits are. Also notice that the syntax has been simplified. So don't use these anymore: \set PianoStaff.connectArpeggios = ##t \set PianoStaff.connectArpeggios = ##f Use these instead: \connectArpeggiosOn \connectArpeggiosOff Also, don't use this type of thing anymore: \override PianoStaff.Arpeggio #'arpeggio-direction = #UP Use these commands in all situations (connected and unconnected): \arpeggioArrowUp \arpeggioArrowDown \arpeggioNormal \arpeggioBracket These are still not to be used in connected situations: \arpeggioParenthesis \arpeggioParenthesisDashed The file is here: http://lists.gnu.org/archive/html/lilypond-devel/2009-08/txtDIrSYMGg1c.txt You can start with the example given at the bottom of that file and go from there. Thanks! - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
> Why not add it to the LSR? > > /Mats > I think a note about "arrowed" arpeggios that cross staves would be helpful under the Arpeggios->"Known issues and warnings" subheading in NR 1.3.3. There's such a note about cross-staff tremolos being tricky, which saved me from trying a bunch of unnecessary tweaks to get them to work. -Jonathan ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Mats Bengtsson wrote: > > Yes, but this is tricky enough that I think something should be > > added to the docs. Maybe when I have some time I can do that, > Why not add it to the LSR? First I'd like to see what the general opinion is on this: http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00849.html - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Mark Polesky wrote: Yes, but this is tricky enough that I think something should be added to the docs. Maybe when I have some time I can do that, Why not add it to the LSR? /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Wow that was quick. Thanks!
-Jonathan
--- On Wed, 7/29/09, Mark Polesky wrote:
> From: Mark Polesky
> Subject: Re: \arpeggioArrowUp across staves
> To: "Jonathan Wilkes" , lilypond-user@gnu.org
> Date: Wednesday, July 29, 2009, 7:01 AM
>
> Jonathan Wilkes wrote:
>
> > I've tried every combination of \arpeggioArrowUp,
> connectArpeggios, and/or
> > arpeggio-direction to get a squiggly arpeggio with an
> upward arrow that
> > spans both staves of a PianoStaff, but nothing seems
> to work.
> >
> > Is it possible? I'm looking at the arpeggio
> examples in 1.3.3 as a guide.
>
> Yes, but this is tricky enough that I think something
> should be
> added to the docs. Maybe when I have some time I can do
> that, but
> in the meantime, here's the solution:
>
> - Mark
>
> \new PianoStaff \relative c'' <<
> \set PianoStaff.connectArpeggios = ##t
> \new Staff {
> \override PianoStaff.Arpeggio
> #'arpeggio-direction = #UP
> 4\arpeggio
> }
> \new Staff {
> \clef bass
> 4\arpeggio
> }
> >>
>
>
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Jonathan Wilkes wrote:
> I've tried every combination of \arpeggioArrowUp, connectArpeggios, and/or
> arpeggio-direction to get a squiggly arpeggio with an upward arrow that
> spans both staves of a PianoStaff, but nothing seems to work.
>
> Is it possible? I'm looking at the arpeggio examples in 1.3.3 as a guide.
Yes, but this is tricky enough that I think something should be
added to the docs. Maybe when I have some time I can do that, but
in the meantime, here's the solution:
- Mark
\new PianoStaff \relative c'' <<
\set PianoStaff.connectArpeggios = ##t
\new Staff {
\override PianoStaff.Arpeggio #'arpeggio-direction = #UP
4\arpeggio
}
\new Staff {
\clef bass
4\arpeggio
}
>>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \arpeggioArrowUp across staves
Oh, I'm using version 2.12.2 on winxp. --- On Wed, 7/29/09, Jonathan Wilkes wrote: > From: Jonathan Wilkes > Subject: \arpeggioArrowUp across staves > To: lilypond-user@gnu.org > Date: Wednesday, July 29, 2009, 6:50 AM > Hi, > > I've tried every combination of \arpeggioArrowUp, > connectArpeggios, and/or > arpeggio-direction to get a squiggly arpeggio with an > upward arrow that > spans both staves of a PianoStaff, but nothing seems to > work. > > Is it possible? I'm looking at the arpeggio examples > in 1.3.3 as a guide. > > Thanks, > Jonathan > > > > > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
