Re: Substitute for s1*0

[Trevor Daniels]

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.

Trevor