[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: disabling point-and-click for displayed chords?
From: |
Adam Spiers |
Subject: |
Re: disabling point-and-click for displayed chords? |
Date: |
Sat, 26 Jan 2013 22:04:16 +0000 |
On Tue, Jan 15, 2013 at 3:05 PM, Adam Spiers
<address@hidden> wrote:
> On Tue, Jan 15, 2013 at 9:41 AM, David Kastrup <address@hidden> wrote:
>> Adam Spiers <address@hidden> writes:
>>
>>> I need to generate point-and-click links for notes but not for
>>> displayed chord names. However, \pointAndClickTypes only filters by
>>> music event class, and if my understanding is correct, events in a
>>> certain music class have no notion of which context they are being
>>> applied in, and so this filter cannot distinguish between a note-event
>>> in a Voice context and a note-event in a ChordNames context.
[snipped]
>>> Am I correct, and if so, is there any workaround? I naively tried:
>>>
>>> \score {
>>> <<
>>> \pointAndClickTypes #'()
>>> \allchords
>>> \pointAndClickTypes #'(note-event)
>>> \new Staff {
>>> \allnotes
>>> }
>>> >>
>>> ...
>>> }
>>>
>>> but it still created point-and-click annotations for everything.
>>
>> You could use an engraver in ChordNames for wiping out the (event) cause
>> of the last involved grob. Then the point-and-click location would no
>> longer be available...
>
> That makes sense. Do you mean an existing engraver though, or a new
> one? The only existing one which looks promising is
> Output_property_engraver (which I had never heard of before). Does
> that mean I do this via \applyOutput?
I got this to work for a single note via:
#(define (delete-grob-cause grob origctx curctx)
(let* ((cause (ly:grob-property grob 'cause))
(music-origin (if (ly:stream-event? cause)
(ly:event-property cause 'origin))))
(ly:debug "removing grob origin '~a'" music-origin)))
(ly:grob-set-property! grob 'cause #f))
and then:
\applyOutput #'ChordNames #delete-grob-cause
However, this only worked for the single note following the command.
I searched hard for a way to apply it to all notes, but this was the
best advice I could find:
http://thread.gmane.org/gmane.comp.gnu.lilypond.general/18699/focus=18700
and both options presented were behind my expertise.
However, I did find another solution which worked great:
diff --git a/scm/output-ps.scm b/scm/output-ps.scm
index dd92175..04b248f 100644
--- a/scm/output-ps.scm
+++ b/scm/output-ps.scm
@@ -142,7 +142,9 @@
(define (grob-cause offset grob)
(if (ly:get-option 'point-and-click)
- (let* ((cause (ly:grob-property grob 'cause))
+ (let* ((name (assoc-get 'name (ly:grob-property grob 'meta)))
+ (class (assoc-get 'class (ly:grob-property grob 'meta)))
+ (cause (ly:grob-property grob 'cause))
(music-origin (if (ly:stream-event? cause)
(ly:event-property cause 'origin)))
(point-and-click (ly:get-option 'point-and-click)))
@@ -153,7 +155,8 @@
(ly:in-event-class? cause point-and-click))
(else (any (lambda (t)
(ly:in-event-class? cause t))
- point-and-click))))
+ point-and-click)))
+ (not (equal? name 'ChordName)))
(let* ((location (ly:input-file-line-char-column music-origin))
(raw-file (car location))
(file (if (is-absolute? raw-file)
Clearly this patch is not appropriate for submission as is. However,
I think it would be worth either extending \pointAndClickTypes to
support filtering by context, or adding a new command such as
\pointAndClickContexts. If there is agreement with this idea I am
happy to submit an issue and drum up a patch, but I'd appreciate
guidance on the best interface syntax. For instance, I'm not sure
whether it's better to treat the argument as a list of contexts to
include:
\pointAndClickExcludedContexts #'(Voice DrumVoice)
or contexts to exclude:
\pointAndClickContexts #'(ChordNames)
or should both inclusion and exclusion be supported, either via
separate commands or a single command, e.g.
\pointAndClickContexts #'(Voice DrumVoice -ChordNames)
And how would any of these commands interact with the existing
\pointAndClickTypes command? Presumably they'd have to be treated as
an additional level of filtering.
Thanks,
Adam