Re: Is this reasonable/playable (guitar)?

[David Kastrup]

Johan Vromans <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> But how bad are those, anyway?  The Midi sounds doable.
>> And I am too lazy to look for my guitar and skills.
>
> From a guitarist perspective, looks playable to me.
>
> From a LilyPond perspective, I always consider David's snippets as
> useful learning stuff. While trying to understand how the \pattern
> function works I noticed that there seems to be no documentation for
> make-relative and make-event-chord. 
>
> Can you help me out?

The documentation does not document functions defined in Scheme.  One
has to look them up in scm/music-functions.scm (for example).  This
shows

(define-safe-public (make-event-chord elts)
  (make-music 'EventChord
              'elements elts))

and

(defmacro-public make-relative (variables reference music)
  "The list of pitch or music variables in @var{variables} is used as
a sequence for creating relativable music from @var{music}.

When the constructed music is used outside of @code{\\relative}, it
just reflects plugging in the @var{variables} into @var{music}.

The action inside of @code{\\relative}, however, is determined by
first relativizing the surrogate @var{reference} with the variables
plugged in and then using the variables relativized as a side effect
of relativizing @var{reference} for evaluating @var{music}.

Since pitches don't have the object identity required for tracing the
effect of the reference call, they are replaced @emph{only} for the
purpose of evaluating @var{reference} with simple pitched note events.

The surrogate @var{reference} expression has to be written with that
in mind.  In addition, it must @emph{not} contain @emph{copies} of
music that is supposed to be relativized but rather the
@emph{originals}.  This @emph{includes} the pitch expressions.  As a
rule, inside of @address@hidden@address@hidden variables must @emph{only} be
introduced using @code{#}, never via the copying construct @code{$}.
The reference expression will usually just be a sequential or chord
expression naming all variables in sequence, implying that following
music will be relativized according to the resulting pitch of the last
or first variable, respectively.

Since the usual purpose is to create more complex music from general
arguments and since music expression parts must not occur more than
once, one @emph{does} generally need to use copying operators in the
@emph{replacement} expression @var{music} when using an argument more
than once there.  Using an argument more than once in @var{reference},
in contrast, does not make sense.

There is another fine point to mind: @var{music} must @emph{only}
contain freshly constructed elements or copied constructs.  This will
be the case anyway for regular LilyPond code inside of
@address@hidden@address@hidden, but any other elements (apart from the
@var{variables} themselves which are already copied) must be created
or copied as well.

The reason is that it is usually permitted to change music in-place as
long as one does a @var{ly:music-deep-copy} on it, and such a copy of
the whole resulting expression will @emph{not} be able to copy
variables/values inside of closures where the information for
relativization is being stored.
"

[...]


Now version 2.18 does not permit introducing music via #... into chords,
so I needed to use
(make-event-chord (list x y z))
instead of the self-explanatory
#{ < #x #y #z > #}
that can be used in 2.19.2 or something like that.  While one could also
write
#{ < $x $y $z > #}
this would not work due to making copies of the music expressions, and
thus stopping the implicit \relative < $x $y $z > from having an actual
effect on the original variables x, y, and z.

make-relative is a somewhat quirky beast, but much preferable over
trying to deal manually with music function arguments inside of
\relative.

-- 
David Kastrup