David Kastrup wrote Tuesday, May 08, 2012 11:06 AM
> "Trevor Daniels" <t.daniels@tred...> 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
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.