[Top][All Lists]

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

Re: Substitute for s1*0

From: Trevor Daniels
Subject: Re: Substitute for s1*0
Date: Tue, 8 May 2012 11:43:00 +0100

David Kastrup wrote Tuesday, May 08, 2012 11:06 AM

"Trevor Daniels" <address@hidden> writes:

Keith OHara wrote Tuesday, May 08, 2012 3:48 AM

I suggest we mention that <> takes no time in NR 1.5.1 Chorded
Notes, but avoid it in the examples.

Most of the visible uses of s1*0 in the docs were instigated by me,
so I see how to avoid them.

This seems like a sensible way forward.  Let's take it a
step at a time:

1. Raise a bug report to highlight the problems of s1*0,
giving the <> workaround.  That seems standard procedure
for the bug squad - a problem has been identified and a
workaround suggested.  David - thanks for alerting us to this!

There is no bug with s1*0.

I didn't say there was.  But there is a problem with the documentation.
You've identified it, and it should be raised as an issue.  As you say:

Which is the reason s1*0 is an accident waiting to happen.  It takes a
programmer to understand its numerous implications.

The documentation should aim to minimise the likelihood of this
happening.  It is doesn't it's defective and should be improved.

The simple rule
"never forget an explicit duration for the next element or things will
blow up" is nice, but if s1*0 is used for the last element in a
sequence, it is not easy to do always.

That sounds like a good warning to add.

2. Document the semantics of <> in NR 1.5.1.  Does anyone
dissent from this?  Ian has already provided a reasonable
first draft.

It is not complete without including an explanation why that construct
is being avoided in the rest of the manual for the sake of more complex,
error-prone and cumbersome code.

No, but it's a sensible first step. It is an improvement in itself. The rest
follows in step 3.

3. Look at the individual uses of s1*0 and see first if its use can be
avoided.  We can discuss each of these individually,
considering the relative merits of using alternative approaches (if
any) or using <>.

The goal being to avoid the impression that there is a working and
simple approach for letting postevents happen at some time without
requiring a note or rest, instead using parallel music and spacer rests,
or a number of other constructs more or less suited to different
situations, instead of a single, existing, simple tool.

No.  Didn't I list <> as an possibility?  The goal being to find the
consensus solution.  You have a firm opinion about what is best;
others disagree.  But this isn't David's project (or Graham's either);
it's a community project.  People downing tools or putting on coats
or otherwise resorting to extortion doesn't help.

I should have added a 4th point to my list:

4. Defer discussion of z or other alternatives to <> until GLISS.


reply via email to

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