lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLISS] non-timed or non-musical events "z" "y"


From: Graham Percival
Subject: Re: [GLISS] non-timed or non-musical events "z" "y"
Date: Thu, 13 Sep 2012 10:02:38 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Sep 13, 2012 at 12:37:00PM +0200, David Kastrup wrote:
> Werner LEMBERG <address@hidden> writes:
> 
> >>> Actually, if we have -{ ... }, we don't need `z' at all: 
> >>>
> >>>   c'1-{ s4 s\< s2 s\! }

This is a little bit unclear, since the final s\! would have the
same duration as the previous s2, and thus would "go over" the
duration limit of 1.  I think there's still a need for a "event
after the previous duration", i.e.
   c'1-{ s4 s\< s2 <>\! }
   c'1-{ s4 s\< s2 z\! }

> >> (in your case 3/2)
> >
> > No.  The `base' note has a length of 1/1.
> 
> s4 + s4 + s2 + s2 is 3/2.  You are asking for the last 1/2 to be
> silently ignored, as opposed to what you want below:

Not silently; if the duration exceeds the base note, there should
be an error (or possibly merely a warning, like a barcheck
warning).

> > No, my idea is that everything `longer' than the base not gets ignored
> > (causing a warning).
> 
> Except when you think they should not cause a warning.

This was due to the "how do we anchor an event after a duration"
problem.

> > I know that we are talking about syntactical sugar.
> 
> The association to cavities is hard to avoid...

Please avoid snarky comments in this discussion.  Avoiding all
sugar would have us writing music directly in scheme; the amount
of sugar used is a matter of degree, not an absolute yes/no.

> > What Graham suggests can be always written with << ... >> constructs.
> > However, I share his feeling that many people (including me) are quite
> > uncomfortable with using parallel music for attaching a crescendo to a
> > note.  Actually, for complicated situations, << ... >> is certainly
> > more appropriate, but for simple cases I want a simpler notation.
> 
> But the notation is not actually simpler at all, and it abuses existing
> constructs.

ok, it could be something else instead,
   c'1-< s4 s\< s2 z\! >
   c'1-<< s4 s\< s2 z\! >>
   c'1-{{ s4 s\< s2 z\! }}
   c'1\at{ s4 s\< s2 z\! }
   c'1\extra{ s4 s\< s2 z\! }

> It is exactly the sort of thing that makes LilyPond
> unsuitable as a reusable representation for music rather than a
> write-only format that only humans and LilyPond itself can hope to
> understand, if they are lucky.  It would not have a reasonable Scheme
> representation as Music expressions.

I don't follow this.  If we can produce an unambiguous "expansion"
of
   c'1-<< s4 s\< s2 z\! >>
into
   << { c'1 } { s4 s\< s2 z\! } >>
then surely it can be expressed as music functions.  (NB: before
the "expansion", we give an error if there's any pitch-notes
within the condensed version, so by assumption the expansion will
only have s or z/<> constructs)

I know that you are not convinced that this can be done
unambiguously, but that's what we're talking about.

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]