Re: cross-staff versions of \arpeggioArrowUp etc.
On Thu, 2009-08-06 at 07:11 -0700, Mark Polesky wrote: > Joe Neeman wrote: > > > There doesn't seem to be. As a workaround, you could add a context > > property called, say, "spanArpeggioInThisContext" and document somewhere > > that the \connectArpeggiosOn command works in the lowermost context > > where spanArpeggioInThisContext is true. This preserves the ability of > > the user to define their own contexts and it also allows the user to > > switch the arpeggio-connecting-context from, say, PianoStaff to Staff > > and back again while using mostly predefined commands. > > I assume StaffGroup, PianoStaff, and GrandStaff would all have such > a context property set to #t as a default? That was my intention, yes. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Joe Neeman wrote: > There doesn't seem to be. As a workaround, you could add a context > property called, say, "spanArpeggioInThisContext" and document somewhere > that the \connectArpeggiosOn command works in the lowermost context > where spanArpeggioInThisContext is true. This preserves the ability of > the user to define their own contexts and it also allows the user to > switch the arpeggio-connecting-context from, say, PianoStaff to Staff > and back again while using mostly predefined commands. I assume StaffGroup, PianoStaff, and GrandStaff would all have such a context property set to #t as a default? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
On Tue, 2009-08-04 at 21:23 -0700, Mark Polesky wrote: > Neil Puttock wrote: > > (let* ((Arpeggio > > arpeggio (or something else without the capital letter) > > What's bad about the capital letter? I capitalized it because it's > a grob-name and grob-names are capitalized. Does the same problem > extend to the X-extent binding one line below? Grob names are capitalized in lilypond code, but not in scheme code. X-extent (and X-offset and other such things) are capitalized for consistency with existing code. > Joe Neeman wrote: > > > I'd like to second Neil's objection regarding the hard-coding of > > GrandStaff/PianoStaff/StaffGroup as contexts containing > > Span_arpeggio_engraver. Given the flexibility of contexts and engravers > > in lilypond, it isn't a good idea to assume that certain contexts are > > the only ones to provide a particular functionality. > > Is there a scheme procedure to test if a given context contains > a particular engraver? Like... > (context-has-engraver? context 'Span_arpeggio_engraver) > If not, is there a way to test that? I agree, my current solution > there isn't ideal. There doesn't seem to be. As a workaround, you could add a context property called, say, "spanArpeggioInThisContext" and document somewhere that the \connectArpeggiosOn command works in the lowermost context where spanArpeggioInThisContext is true. This preserves the ability of the user to define their own contexts and it also allows the user to switch the arpeggio-connecting-context from, say, PianoStaff to Staff and back again while using mostly predefined commands. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Neil Puttock wrote:
> Sorry to throw a spanner in the works, but have you considered what
> will happen if an innocent user adds the Span_arpeggio_engraver to the
> Staff context in order to span voices on one stave?
Can you give an example that fails? (You may want to read my reply to
Joe first before you spend any time concocting something - see below)
At least the example from the docsworks:
\new Staff \with {
\consists "Span_arpeggio_engraver"
}
\relative c' {
\set Staff.connectArpeggios = ##t
<<
\arpeggioArrowDown
{ 4\arpeggio 2 } \\
{ 2\arpeggio 2 }
>>
}
> A few nitpicks:
>
> (not (null? parent))
> (not (null? origin))
> ly:context?
Changed - thanks.
> (let* ((Arpeggio
> arpeggio (or something else without the capital letter)
What's bad about the capital letter? I capitalized it because it's
a grob-name and grob-names are capitalized. Does the same problem
extend to the X-extent binding one line below?
Thanks Neil!
Joe Neeman wrote:
> I'd like to second Neil's objection regarding the hard-coding of
> GrandStaff/PianoStaff/StaffGroup as contexts containing
> Span_arpeggio_engraver. Given the flexibility of contexts and engravers
> in lilypond, it isn't a good idea to assume that certain contexts are
> the only ones to provide a particular functionality.
Is there a scheme procedure to test if a given context contains
a particular engraver? Like...
(context-has-engraver? context 'Span_arpeggio_engraver)
If not, is there a way to test that? I agree, my current solution
there isn't ideal.
> Also, one other minor comment:
>
> you've written out the recursion twice: it should be
> (let ((parent (ly:context-parent context)))
> (if parent
> (find-spannable-context parent)
> #f))
Thanks. That was code from an earlier version that I forgot to
remove once it became redundant.
Thanks guys. Looking forward to the next round...
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
On Tue, 2009-08-04 at 14:01 -0700, Mark Polesky wrote: > Mark Polesky wrote: > > > Otherwise, does this look good? > > I'm sorry to keep doing this, but I keep finding ways of > improving this. Now I think users should find this very > intuitive, although the internal workings are more complex. > > I've attached the most recent version, which includes an > annotated example at the bottom, which explains the behind- > the-scenes operations. > > Anyone want to have a look at it? > Anyone have any comments/suggestions? I'd like to second Neil's objection regarding the hard-coding of GrandStaff/PianoStaff/StaffGroup as contexts containing Span_arpeggio_engraver. Given the flexibility of contexts and engravers in lilypond, it isn't a good idea to assume that certain contexts are the only ones to provide a particular functionality. Also, one other minor comment: > #(define (find-spannable-context context) > (let ((spannable-contexts '(GrandStaff PianoStaff StaffGroup))) > (if (member (ly:context-name context) spannable-contexts) > context > (let ((parent (ly:context-parent context))) > (if parent > (let ((parent-name (ly:context-name parent))) > (if (member parent-name spannable-contexts) > parent > (find-spannable-context parent))) > #f) you've written out the recursion twice: it should be (let ((parent (ly:context-parent context))) (if parent (find-spannable-context parent) #f)) Cheers, Joe > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
2009/8/4 Mark Polesky : > Anyone have any comments/suggestions? Sorry to throw a spanner in the works, but have you considered what will happen if an innocent user adds the Span_arpeggio_engraver to the Staff context in order to span voices on one stave? A few nitpicks: (not (null? parent)) (not (null? origin)) ly:context? (let* ((Arpeggio arpeggio (or something else without the capital letter) Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky writes: > Mark Polesky wrote: > >> Otherwise, does this look good? > > I'm sorry to keep doing this, but I keep finding ways of > improving this. Now I think users should find this very > intuitive, although the internal workings are more complex. > > I've attached the most recent version, which includes an > annotated example at the bottom, which explains the behind- > the-scenes operations. > > Anyone want to have a look at it? > Anyone have any comments/suggestions? Ok, since I was the one originally complaining, it seems appropriate to say something here: I have to admit that I have never needed an arpeggio, let alone a cross-staff one. I have, more or less, reacted in a keyword-triggered manner: the original proposal sounded like something that was rather hard and unintuitive to use, and like something that required so much manual tweaking that it would not adapt itself well to changed conditions (autocombined staffs/voices and similar). Lilypond should IMO aim to describe more the music than its representation, since the act of casting the music into a representation is conceptually Lilypond's task. It would appear that your work has improved the user interface considerably, where it looks like an implemented feature rather than a bunch of twiddling knobs sticking out. I have no idea how robust this feature will work in combination with other features and/or extensions, and how well the internals of Lilypond have lent themselves to the implementation, or resisted. So I don't have enough of a clue to figure out further areas of queasiness. Since this construct is not used all that often, it is my guess that worthwhile feedback will trickle in rather slowly after the feature has been published and documented, from the rare user that actually needs to exercise it. I am glad to know that it will be there in a reasonably user-comprehensible way, should the need arise for me. And it is, after all, something which meets a need particularly in piano music (I don't play piano), so the current dearth of feedback does not mean that doing this well was merely an academic exercise. All the best -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote:
> Otherwise, does this look good?
I'm sorry to keep doing this, but I keep finding ways of
improving this. Now I think users should find this very
intuitive, although the internal workings are more complex.
I've attached the most recent version, which includes an
annotated example at the bottom, which explains the behind-
the-scenes operations.
Anyone want to have a look at it?
Anyone have any comments/suggestions?
- Mark
\version "2.13.3"
%% begin property-init.ly revision %%
#(define (arpeggio-generic pushpops)
(lambda (context)
(let* ((parent
(ly:context-property-where-defined context
'connectArpeggios))
(target
(if (and (not (null? parent))
(eq? #t (ly:context-property parent
'connectArpeggios)))
parent
context)))
(for-each
(lambda (pushpop)
(if (pair? pushpop)
(ly:context-pushpop-property target
'Arpeggio
(car pushpop)
(cdr pushpop))
(ly:context-pushpop-property target
'Arpeggio
pushpop)))
pushpops
#(define (find-spannable-context context)
(let ((spannable-contexts '(GrandStaff PianoStaff StaffGroup)))
(if (member (ly:context-name context) spannable-contexts)
context
(let ((parent (ly:context-parent context)))
(if parent
(let ((parent-name (ly:context-name parent)))
(if (member parent-name spannable-contexts)
parent
(find-spannable-context parent)))
#f)
#(define (move-arpeggio-generic origin destination)
;; origin and destination are contexts
(let* ((Arpeggio (ly:context-grob-definition origin 'Arpeggio))
(X-extent (assoc 'X-extent Arpeggio))
(stencil(assoc 'stencilArpeggio))
(arpeggio-direction (assoc 'arpeggio-direction Arpeggio))
(direction (assoc 'direction Arpeggio))
(dash-definition(assoc 'dash-definitionArpeggio))
(props `((X-extent . ,X-extent)
(stencil. ,stencil)
(arpeggio-direction . ,arpeggio-direction)
(direction . ,direction)
(dash-definition. ,dash-definition
(for-each
(lambda (prop)
;; copy .Arpeggio props to .Arpeggio
(if (cdr prop)
(ly:context-pushpop-property destination
'Arpeggio
(cadr prop)
(cddr prop))
(ly:context-pushpop-property destination
'Arpeggio
(car prop)))
;; revert .Arpeggio props
(ly:context-pushpop-property origin 'Arpeggio (car prop)))
props)))
#(define (move-arpeggio-to-spannable-context context)
;; move the active arpeggio properties to the closest GrandStaff,
;; PianoStaff, or StaffGroup parent that can be found.
(let ((target (find-spannable-context context)))
(if target (move-arpeggio-generic context target
#(define (move-arpeggio-to-this-context context)
;; move any arpeggio props, active in a parent context where
;; 'connectArpeggios is #t, to this context (usually Voice).
(let ((origin (ly:context-property-where-defined context
'connectArpeggios)))
(if (and (not (null? origin))
(eq? #t (ly:context-property origin 'connectArpeggios)))
(move-arpeggio-generic origin context
#(define (connect-arpeggios-switch value)
(lambda (context)
(let ((target (find-spannable-context context)))
(if target
(ly:context-set-property! target 'connectArpeggios value)
(ly:warning "No viable context found for connectArpeggios")
connectArpeggiosOn = {
\applyContext #move-arpeggio-to-spannable-context
\applyContext #(connect-arpeggios-switch #t)
}
connectArpeggiosOff = {
\applyContext #move-arpeggio-to-this-context
\applyContext #(connect-arpeggios-switch #f)
}
arpeggioArrowUp =
\applyContext
#(arpeggio-generic `(stencil
X-extent
(arpeggio-direction . ,UP)))
arpeggioArrowDown =
\applyContext
#(arpeggio-generic `(stencil
X-extent
(arpeggio-direction . ,DOWN)))
arpeggioNormal =
\applyContext
#(arpeggio-generic '(stencil
X-extent
arpeggio-
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote: > Hopefully there are no more snafus, but I need you guys to test this. > Let me know if you find any problems. I'd like to apply this if the > developers approve. In the file attached to the previous post http://lists.gnu.org/archive/html/lilypond-devel/2009-08/txtDIrSYMGg1c.txt one small (but important) correction needs to be made. In the definition for "move-arpeggio-to-this-context", 8 lines down, this line: (let* ((Arpeggio (ly:context-grob-definition context 'Arpeggio)) should instead read: (let* ((Arpeggio (ly:context-grob-definition parent 'Arpeggio)) Thanks to Jonathan Wilkes for catching this (on -user). http://lists.gnu.org/archive/html/lilypond-user/2009-08/msg00059.html Otherwise, does this look good? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote: > Okay, this is not ready yet. I found a confusing problem. When setting > connectArpeggios to #f after it has been #t, there's some issue with > the unreverted PianoStaff stencil somehow overriding the new Voice > stencil. Or something. I'm not really sure -- it's confusing. Oh man, that was rough. But I think I solved it. The problem was that the macro was looking for a context where 'connectArpeggios was set to #t to set and revert the properties. This worked fine when it was set to #t, but once it was set to #f, the macro couldn't find the old properties to revert. So the old PianoStaff properties, defined in one staff, were overriding the old Voice properties defined in the other staff. Confusing, but I got it. I've rewritten it so that now it should all work. If you're curious, the procedure called "move-arpeggio-to-this-context" is what does the trick. This is called just before setting 'connectArpeggios to #f. Also, to ease the burden on the user, I went ahead and made two new commands, \connectArpeggiosOn and \connectArpeggiosOff. Without these, the user would have to manually call "move-arpeggio-to-this-context" just before setting 'connectArpeggios to #f. The new \connectArpeggiosOff command automates this. So now, I *think*, all the built-in arpeggio commands such work intuitively, regardless of the connectArpeggios value. Hopefully there are no more snafus, but I need you guys to test this. Let me know if you find any problems. I'd like to apply this if the developers approve. (see the attached file) Thanks. - Mark \version "2.13.3" %% begin property-init.ly revision %% #(define (arpeggio-generic context pushpops) (let* ((parent (ly:context-property-where-defined context 'connectArpeggios)) (target (if (and (not (null? parent)) (eq? #t (ly:context-property parent 'connectArpeggios))) parent context))) (for-each (lambda (pushpop) (if (pair? pushpop) (ly:context-pushpop-property target 'Arpeggio (car pushpop) (cdr pushpop)) (ly:context-pushpop-property target 'Arpeggio pushpop))) pushpops))) #(define move-arpeggio-to-this-context ;; if the active arpeggio properties are set in GrandStaff, PianoStaff, ;; or StaffGroup, move them into this context (usually Voice). (lambda (context) (let ((parent (ly:context-property-where-defined context 'connectArpeggios))) (if (and (not (null? parent)) (eq? #t (ly:context-property parent 'connectArpeggios))) (let* ((Arpeggio (ly:context-grob-definition context 'Arpeggio)) (X-extent (assoc 'X-extent Arpeggio)) (stencil(assoc 'stencilArpeggio)) (arpeggio-direction (assoc 'arpeggio-direction Arpeggio)) (direction (assoc 'direction Arpeggio)) (dash-definition(assoc 'dash-definitionArpeggio)) (props `((X-extent . ,X-extent) (stencil. ,stencil) (arpeggio-direction . ,arpeggio-direction) (direction . ,direction) (dash-definition. ,dash-definition (for-each (lambda (prop) ;; copy .Arpeggio props to .Arpeggio (if (cdr prop) (ly:context-pushpop-property context 'Arpeggio (cadr prop) (cddr prop)) (ly:context-pushpop-property context 'Arpeggio (car prop))) ;; revert .Arpeggio props (ly:context-pushpop-property parent 'Arpeggio (car prop))) props)) #(define (connect-arpeggios-switch value) (lambda (context) (define target-list '(GrandStaff PianoStaff StaffGroup)) (define (find-target context) (if (member (ly:context-name context) target-list) context (let ((parent (ly:context-parent context))) (if parent (let ((parent-name (ly:context-name parent))) (if (member parent-name target-list) parent (find-target parent))) #f (let ((target (find-target context))) (
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote:
> Any objections? How close is this to being acceptable? I'll wait for
> approval.
Okay, this is not ready yet. I found a confusing problem. When setting
connectArpeggios to #f after it has been #t, there's some issue with
the unreverted PianoStaff stencil somehow overriding the new Voice
stencil. Or something. I'm not really sure -- it's confusing.
You can see it in action below (note that you need the definitions
from the previous post for this to make sense).
Maybe it's because I'm so tired, but this is so confusing to me that I
feel that anyone who is able to explain this ought to get a special
prize. Unfortunately, I don't have any special prizes to give.
Sometimes computer programming reminds me of this:
http://www.puzzlemethis.com/cgi-bin/puzzle/scan/st=db/ml=33/co=yes/sf=category/se=Disentangle%20%26%20Blacksmith/op=eq.html
Does anyone else feel like this from time to time?
I think I'd feel better if I knew that you guys did!
- Mark
\new PianoStaff \relative <<
\new Staff {
4\arpeggio
\set PianoStaff.connectArpeggios = ##t
%% bizarre...
%% \arpeggioBracket persists in lower staff after setting
%% connectArpeggios to #f; \arpeggioArrowUp doesn't do this.
\arpeggioBracket
%\arpeggioArrowUp
\arpeggio
\set PianoStaff.connectArpeggios = ##f
\arpeggio
}
\new Staff {
\clef bass
\arpeggioArrowDown
4\arpeggio
\arpeggio
\arpeggio
}
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Joe Neeman wrote:
> Have you tried using ly:context-property-where-defined instead of
> searching for PianoStaff explicitly? There are non-PianoStaff contexts
> containing Span_arpeggio_engraver, after all. Other than that, this is a
> very cool trick!
Joe,
Thanks for the tip. I rewrote arpeggio-generic with ly:context-
property-where-defined and also made some changes to arpeggioNormal.
Also, line 281 of property-init.ly says this:
% For drawing vertical chord brackets with \arpeggio
% This is a shorthand for the value of the print-function property
% of either Staff.Arpeggio or PianoStaff.Arpeggio, depending whether
% cross-staff brackets are desired.
This is completely false, right? Otherwise these commands would work
without the \applyContext gymnastics I've been coding in this thread.
If my code (below) gets approved, I think I'll either remove the
comment it or change it to:
% These commands look for 'connectArpeggios (cross-staff arpeggios)
% to determine the proper context in which to operate.
Any objections? How close is this to being acceptable? I'll wait for
approval.
Thanks.
- Mark
*
\version "2.13.3"
%% begin property-init.ly revision %%
#(define (arpeggio-generic context pushpops)
(let* ((parent (ly:context-property-where-defined context
'connectArpeggios))
(target (if (null? parent) context parent)))
(for-each
(lambda (pushpop)
(if (pair? pushpop)
(ly:context-pushpop-property target
'Arpeggio
(car pushpop)
(cdr pushpop))
(ly:context-pushpop-property target
'Arpeggio
pushpop)))
pushpops)))
arpeggioArrowUp =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,UP
arpeggioArrowDown =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,DOWN
arpeggioNormal =
\applyContext
#(lambda (context)
(let ((Staff (ly:context-find context 'Staff)))
(if (and Staff (not (eq? context Staff)))
(arpeggio-generic Staff
`(stencil X-extent arpeggio-direction dash-definition)))
(arpeggio-generic context
`(stencil X-extent arpeggio-direction dash-definition
arpeggioBracket =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(X-extent (stencil . ,ly:arpeggio::brew-chord-bracket
%% end property-init.ly revision %%
%% demonstration %%
\new PianoStaff \relative <<
\new Staff {
\arpeggioArrowUp
4\arpeggio
\arpeggioNormal
\arpeggio
\set PianoStaff.connectArpeggios = ##t
\arpeggioArrowUp
\arpeggio
\arpeggioBracket
\arpeggio
\set PianoStaff.connectArpeggios = ##f
\arpeggioNormal
\arpeggio
}
\new Staff {
\clef bass
\arpeggioArrowDown
4\arpeggio
\arpeggio
\arpeggio
\arpeggio
\arpeggio
}
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
On Fri, 2009-07-31 at 18:58 -0700, Mark Polesky wrote: > Mark Polesky wrote: > > > Interesting idea. As a first attempt, I tried making the functionality > > of the \arpeggioArrowUp command dependent on the 'connectArpeggios > > context property, but obviously I'm doing something wrong. Does anyone > > know why this doesn't work? Can anyone see how to make this work? If > > not, are there other oppositions to my earlier solution of defining new > > commands? > > I think I might have figured out how to make \arpeggioArrowUp and > its kin select the appropriate context depending on whether > 'connectArpeggios is set. Can someone look at this and check to > make sure it's legit? Have you tried using ly:context-property-where-defined instead of searching for PianoStaff explicitly? There are non-PianoStaff contexts containing Span_arpeggio_engraver, after all. Other than that, this is a very cool trick! Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote: > ;; not sure if the conditional tests are necessary > (if PianoStaff > (arpeggio-generic PianoStaff > `(stencil X-extent arpeggio-direction dash-definition))) > (if Staff > (arpeggio-generic Staff > `(stencil X-extent arpeggio-direction dash-definition))) One small thing - just figured out that the above conditional tests *are* necessary. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote:
> Interesting idea. As a first attempt, I tried making the functionality
> of the \arpeggioArrowUp command dependent on the 'connectArpeggios
> context property, but obviously I'm doing something wrong. Does anyone
> know why this doesn't work? Can anyone see how to make this work? If
> not, are there other oppositions to my earlier solution of defining new
> commands?
I think I might have figured out how to make \arpeggioArrowUp and
its kin select the appropriate context depending on whether
'connectArpeggios is set. Can someone look at this and check to
make sure it's legit?
Thanks!
- Mark
*
\version "2.13.3"
#(define (arpeggio-generic context pushpops)
(let* ((PianoStaff (ly:context-find context 'PianoStaff))
(target (if (and PianoStaff
(eq? #t
(ly:context-property PianoStaff
'connectArpeggios)))
PianoStaff
context)))
(for-each
(lambda (pushpop)
(if (pair? pushpop)
(ly:context-pushpop-property target
'Arpeggio
(car pushpop)
(cdr pushpop))
(ly:context-pushpop-property target
'Arpeggio
pushpop)))
pushpops)))
arpeggioArrowUp =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,UP
arpeggioArrowDown =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,DOWN
arpeggioNormal =
\applyContext
#(lambda (context)
(let ((PianoStaff (ly:context-find context 'PianoStaff))
(Staff (ly:context-find context 'Staff)))
;; not sure if the conditional tests are necessary
(if PianoStaff
(arpeggio-generic PianoStaff
`(stencil X-extent arpeggio-direction dash-definition)))
(if Staff
(arpeggio-generic Staff
`(stencil X-extent arpeggio-direction dash-definition)))
(arpeggio-generic context
`(stencil X-extent arpeggio-direction dash-definition
arpeggioBracket =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(X-extent (stencil . ,ly:arpeggio::brew-chord-bracket
\new PianoStaff \relative <<
\new Staff {
\arpeggioArrowUp
4\arpeggio
\arpeggioNormal
\arpeggio
\set PianoStaff.connectArpeggios = ##t
\arpeggioArrowUp
\arpeggio
\arpeggioBracket
\arpeggio
\set PianoStaff.connectArpeggios = ##f
\arpeggioNormal
\arpeggio
}
\new Staff {
\clef bass
\arpeggioArrowDown
4\arpeggio
\arpeggio
\arpeggio
\arpeggio
\arpeggio
}
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
David Kastrup wrote:
> This sounds to me like giving users a low-level manual way to fudge
> around a bug/design mistake. This sounds like something that should
> happen automatically in most cases.
Interesting idea. As a first attempt, I tried making the functionality
of the \arpeggioArrowUp command dependent on the 'connectArpeggios
context property, but obviously I'm doing something wrong. Does anyone
know why this doesn't work? Can anyone see how to make this work? If
not, are there other oppositions to my earlier solution of defining new
commands?
Thanks.
- Mark
\version "2.13.3"
arpeggioArrowUp = {
\applyContext
#(lambda (x)
(if (eq? #t (ly:context-property x 'connectArpeggios))
#{
\revert PianoStaff.Arpeggio #'stencil
\revert PianoStaff.Arpeggio #'X-extent
\override PianoStaff.Arpeggio #'arpeggio-direction = #UP
#}
#{
\revert Arpeggio #'stencil
\revert Arpeggio #'X-extent
\override Arpeggio #'arpeggio-direction = #UP
#}))
}
\new PianoStaff \relative c'' <<
\new Staff {
\arpeggioArrowUp
4\arpeggio
\arpeggioNormal
4\arpeggio
\set PianoStaff.connectArpeggios = ##t
\arpeggioArrowUp
4\arpeggio
}
\new Staff {
\clef bass
4\arpeggio
4\arpeggio
4\arpeggio
}
>>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Patrick McCarty writes:
> On Tue, Jul 28, 2009 at 10:42:47PM -0700, Mark Polesky wrote:
>>
>> \arpeggioArrowUp etc. doesn't work with cross-staff arpeggios
>> because the arpeggio-direction property is overridden at the
>> Voice level, and not the PianoStaff level. To facilitate this
>> situation for users, I propose adding these four commands to
>> ly/property-init.ly:
>>
>> connectArpeggioArrowUp = {
>> \revert PianoStaff.Arpeggio #'stencil
>> \revert PianoStaff.Arpeggio #'X-extent
>> \override PianoStaff.Arpeggio #'arpeggio-direction = #UP
>> }
>> connectArpeggioArrowDown = {
>> \revert PianoStaff.Arpeggio #'stencil
>> \revert PianoStaff.Arpeggio #'X-extent
>> \override PianoStaff.Arpeggio #'arpeggio-direction = #DOWN
>> }
>> connectArpeggioNormal = {
>> \revert PianoStaff.Arpeggio #'stencil
>> \revert PianoStaff.Arpeggio #'X-extent
>> \revert PianoStaff.Arpeggio #'arpeggio-direction
>> \revert PianoStaff.Arpeggio #'dash-definition
>> }
>> connectArpeggioBracket = {
>> \revert PianoStaff.Arpeggio #'X-extent
>> \override PianoStaff.Arpeggio #'stencil = #ly:arpeggio::brew-chord-bracket
>> }
>>
>> [snip]
>>
>> Good idea? Bad idea? Support? Opposition?
>
> Sure! I wasn't aware of this limitation, and I think users would
> greatly benefit from having these predefined commands.
This sounds to me like giving users a low-level manual way to fudge
around a bug/design mistake. This sounds like something that should
happen automatically in most cases.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
On Tue, Jul 28, 2009 at 10:42:47PM -0700, Mark Polesky wrote:
>
> \arpeggioArrowUp etc. doesn't work with cross-staff arpeggios
> because the arpeggio-direction property is overridden at the
> Voice level, and not the PianoStaff level. To facilitate this
> situation for users, I propose adding these four commands to
> ly/property-init.ly:
>
> connectArpeggioArrowUp = {
> \revert PianoStaff.Arpeggio #'stencil
> \revert PianoStaff.Arpeggio #'X-extent
> \override PianoStaff.Arpeggio #'arpeggio-direction = #UP
> }
> connectArpeggioArrowDown = {
> \revert PianoStaff.Arpeggio #'stencil
> \revert PianoStaff.Arpeggio #'X-extent
> \override PianoStaff.Arpeggio #'arpeggio-direction = #DOWN
> }
> connectArpeggioNormal = {
> \revert PianoStaff.Arpeggio #'stencil
> \revert PianoStaff.Arpeggio #'X-extent
> \revert PianoStaff.Arpeggio #'arpeggio-direction
> \revert PianoStaff.Arpeggio #'dash-definition
> }
> connectArpeggioBracket = {
> \revert PianoStaff.Arpeggio #'X-extent
> \override PianoStaff.Arpeggio #'stencil = #ly:arpeggio::brew-chord-bracket
> }
>
> [snip]
>
> Good idea? Bad idea? Support? Opposition?
Sure! I wasn't aware of this limitation, and I think users would
greatly benefit from having these predefined commands.
I think the names are great too, but let's see what others think.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
cross-staff versions of \arpeggioArrowUp etc.
\arpeggioArrowUp etc. doesn't work with cross-staff arpeggios
because the arpeggio-direction property is overridden at the
Voice level, and not the PianoStaff level. To facilitate this
situation for users, I propose adding these four commands to
ly/property-init.ly:
connectArpeggioArrowUp = {
\revert PianoStaff.Arpeggio #'stencil
\revert PianoStaff.Arpeggio #'X-extent
\override PianoStaff.Arpeggio #'arpeggio-direction = #UP
}
connectArpeggioArrowDown = {
\revert PianoStaff.Arpeggio #'stencil
\revert PianoStaff.Arpeggio #'X-extent
\override PianoStaff.Arpeggio #'arpeggio-direction = #DOWN
}
connectArpeggioNormal = {
\revert PianoStaff.Arpeggio #'stencil
\revert PianoStaff.Arpeggio #'X-extent
\revert PianoStaff.Arpeggio #'arpeggio-direction
\revert PianoStaff.Arpeggio #'dash-definition
}
connectArpeggioBracket = {
\revert PianoStaff.Arpeggio #'X-extent
\override PianoStaff.Arpeggio #'stencil = #ly:arpeggio::brew-chord-bracket
}
___
Then, for cross-staff arrowed (or bracket) arpeggios, the
user would be able to just do this:
\version "2.13.3"
\new PianoStaff \relative c'' <<
\set PianoStaff.connectArpeggios = ##t
\new Staff {
4\arpeggio
\connectArpeggioArrowUp
4\arpeggio
\connectArpeggioArrowDown
4\arpeggio
\connectArpeggioNormal
4\arpeggio
}
\new Staff {
\clef bass
\repeat unfold 4 {
4\arpeggio
}
}
>>
___
Good idea? Bad idea? Support? Opposition?
Thanks.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
