<div dir="ltr"><div dir="ltr">On Fri, Jan 18, 2019 at 1:16 PM <<a href="mailto:matthew@frye.org.uk" target="_blank">matthew@frye.org.uk</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">Is this really that complicated? What I'm thinking is along the lines of:<br>
"Any multi-method performance is spliced unless it can be divided into  <br>
a series of contiguous round blocks, each of which is of a single  <br>
method and contains each row n times, or at most one of which contains  <br>
each row n or n+1 times."<br>
<br>
Wording isn't optimal, but that doesn't seem too bad to me. Is there  <br>
an example where that definition gives a counter-intuitive and/or  <br>
wrong classification? I think that defining an explicit exception  <br>
avoids both a lot of complication and the possibility of unexpected  <br>
edge cases.</blockquote><div><br></div><div>Yes, agree that basing the definition on what isn't spliced simplifies things.  A couple of potential problems are as follows, both very much edge cases:</div><div><br></div><div>- If a multi-method performance isn't a round block (e.g. starts in rounds and finishes in Queens), it would be spliced even if all the changes of method occur at rounds.</div><div><br></div><div>- If a multi-method performance is false, it would be spliced.  E.g. if 7 extents of Cambridge were rung on the front 6 of a 12, with 7 extents of London rung simultaneously on the back 6, this would be a multi-method performance and wouldn't be true when considered at the Maximus stage.  The framework handles the lack of truth by asking for a disclosure, and the band might also note that each half of the performance is true.  Your definition would make this a spliced performance, which doesn't seem right.</div><div><br></div><div>As I say, these are both very much edge cases, but are probably worth considering given our aim is to be permissive and descriptive.  There are probably other examples where your definition gives the expected answer and the framework's doesn't.  But overall, it seems better to base the definition of spliced on changes of method at a particular row, rather than on round blocks / truth / completeness.</div><div><br></div><div>The framework we're handing over to the Exec now is version 1 only, and we expect there to be further versions, especially as more people look at it and come up with ideas for improving it.  Spliced might be a definition to revisit in a later version.</div><div><br></div></div></div>