<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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. <br></div></blockquote><div><br></div><div>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?<br></div><div>Imo, permissiveness means the decisions should suggest that the guidelines determine what <i>may</i> be called spliced and not what <i>must</i>. This performance doesn't even have 'spliced' in the title: <a href="https://bb.ringingworld.co.uk/view.php?id=1267756">https://bb.ringingworld.co.uk/view.php?id=1267756</a>.</div><div>If a peal of minor is listed as spliced and has 6 c.o.m, the composition details will likely indicate what was rung. <br></div><div><br></div><div><span class="gmail-title" title="Unknown performance title">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.</span></div><div><span class="gmail-title" title="Unknown performance title"><br></span></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 11:56 AM Tim Barnes <<a href="mailto:tjbarnes23@gmail.com">tjbarnes23@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jan 21, 2019 at 10:52 PM Don Morrison <<a href="mailto:dfm@ringing.org" target="_blank">dfm@ringing.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:"courier new",monospace">Why? </span><span style="font-family:"courier new",monospace">Does not the latter correspond more closely to current practice, with this row-based idea being brand new?</span></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><div dir="ltr" class="gmail-m_-2826728705276106537gmail_attr">On Tue, Jan 22, 2019 at 4:15 AM <<a href="mailto:iain@13to8.co.uk" target="_blank">iain@13to8.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_-2826728705276106537gmail-m_2590124058357565032WordSection1"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Is the problem here that you are trying to come up with a simple definition for spliced when it actually means two different things.</span><br></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Having two definitions, and acknowledging that people may use the word spliced differently might solve the problem.</span></p></div></div></blockquote><div><br></div><div>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: <a href="https://bb.ringingworld.co.uk/search.php?title=mixed" target="_blank">https://bb.ringingworld.co.uk/search.php?title=mixed</a></div></div><div><br></div></div></div></div>
_______________________________________________<br>
ringing-theory mailing list<br>
<a href="mailto:ringing-theory@bellringers.org" target="_blank">ringing-theory@bellringers.org</a><br>
<a href="https://bellringers.org/listinfo/ringing-theory" rel="noreferrer" target="_blank">https://bellringers.org/listinfo/ringing-theory</a><br>
</blockquote></div>