[r-t] Opinions sought

Austin Paul austinjpaul at gmail.com
Thu Jan 24 15:45:15 GMT 2019

> We considered using the simplest definition, which is that any
> multi-method performance is spliced -- effectively applying the higher
> stage definition to all stages.  (And it's invariant under rotation.)  But
> this would be a big change to current practice, given many peals of 7 Minor
> and similar are rung that are not described as spliced today, and it would
> likely be mostly ignored.

So what's wrong with that? Keeping this arbitrary distinction between mixed
and spliced seems to be giving unfair weight to the 'historical' component.
Simplicity and permissiveness to me suggest we should abandon; are there
any other reasons for keeping it?
Imo, permissiveness means the decisions should suggest that the guidelines
determine what *may* be called spliced and not what *must*. This
performance doesn't even have 'spliced' in the title:
If a peal of minor is listed as spliced and has 6 c.o.m, the composition
details will likely indicate what was rung.

I feel like the distinction only exists to disappoint ringers who ring
their first multi-method quarter peal of doubles only to find out
afterwards that it doesn't count as 'spliced'. So the word 'mixed' is added
to alleviate their spirits.

On Wed, Jan 23, 2019 at 11:56 AM Tim Barnes <tjbarnes23 at gmail.com> wrote:

> On Mon, Jan 21, 2019 at 10:52 PM Don Morrison <dfm at ringing.org> wrote:
>> Why? Does not the latter correspond more closely to current practice,
>> with this row-based idea being brand new?
> Yes, but it doesn't work in the new descriptive world where non-round or
> non-true blocks ought to be covered, however rarely they might be rung.  We
> therefore needed to update the definition of spliced.  The CRAG mandate
> asked for simplicity, permissiveness and historical continuity, but in some
> cases (including this one) these are in opposition to each other and we
> needed to search for what we thought were the best trade-offs.
> Permissiveness was added by not requiring all extents / MEBs to be spliced
> for the performance to be spliced.  "It's spliced unless all changes of
> method occur at rounds" gave simplicity.  The trade-off was historical
> continuity -- if a multi-method MEB's changes of method all occur at
> internal rounds, the MEB will no longer be spliced.  This seems a
> reasonable trade-off given the unlikelihood of all changes of method
> occurring at internal rounds, but clearly different people will assign
> different weights to the three CRAG criteria.
> Over 40 people took part in the framework consultations and Don was the
> only person to question the definition of spliced.  Of course we don't know
> how carefully people thought about all the framework definitions, and
> obviously many people didn't take part at all.  There will probably be more
> scrutiny of the framework as it's implemented, and if it emerges that
> something clearly goes against general ringing opinion, this will be taken
> up in version 2.
> On Tue, Jan 22, 2019 at 4:15 AM <iain at 13to8.co.uk> wrote:
>> Is the problem here that you are trying to come up with a simple
>> definition for spliced when it actually means two different things.
>> Pure spliced I believe is clear to everyone, but when a touch is
>> laminated, as in the examples given, there is a lack of agreement as to
>> whether it is spliced, or mixed (or what term you wish to use).
>> Having two definitions, and acknowledging that people may use the word
>> spliced differently might solve the problem.
> I don't think that's the problem -- the challenge is with the definition
> of spliced itself in a permissive / descriptive world.  The framework's
> performance reporting section includes 'mixed' as an optional term that can
> be used for any multi-method performance that isn't 'spliced'.  'Mixed'
> isn't in the Decisions, but we included it as an optional term because it's
> widely used on BellBoard:
> https://bb.ringingworld.co.uk/search.php?title=mixed
> _______________________________________________
> ringing-theory mailing list
> ringing-theory at bellringers.org
> https://bellringers.org/listinfo/ringing-theory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bellringers.org/pipermail/ringing-theory/attachments/20190124/ffcb1bb6/attachment.html>

More information about the ringing-theory mailing list