Re: [oll-user] Finally, the revised instructions - please review!

[Marc S. <ma...@ou...>]

Most of the below is meta-discussion not really relevant to the 
challenges, but still, I think, interesting to think about, as it 
illustrates some of the difficulties inherent in making meaningful 
comparisons.  So, that said, here is my reply to Janek:

Janek Warchoł wrote:

> I believe that both publishers you mention had some reasons to break 
> the lines the way they did it, and that these reasons could be written 
> down as a set of precise rules (although i'm pretty sure that such 
> rules would be very complicated and subtle, and *very* hard to express 
> formally).

Yes, this is a pretty accurate statement.  There is a set of principles 
explainable to and implementable by humans but next to impossible to 
parameterize usefully for a computer.  So in an idealized theoretical 
world with flying cars and all that, sure, manual line breaks wouldn't 
be needed - the desired results could be obtained using style settings 
only.  But in practice, it's unavoidable in contexts where one cares 
about the line breaking.

FWIW, I would suggest that one cares about line breaking "virtually 
always" in the world of lead sheets and perhaps almost as often in the 
world of editions of simple Baroque or classical piano music for 
beginners & intermediates, also presentations of hymns, folk song 
arrangements, and other contexts.  But it is admittedly much less common 
in the world of complex late Romantic piano music, orchestral scores and 
parts, and other contexts.  So differences in the types of music one 
mostly deals can play a large role in what one expects of one's notation 
software.

> Again, I don't really follow.  In the examples I gave, it isn't anything
>
>     about the program that makes it necessary to perform manual
>     adjustments
>     twice - it's inherent in the nature of the types of adjustments
>     that are
>     affected.
>
>
> I don't agree, i.e. i believe that this is not inherent in the nature 
> of adjustments - at least some of them.
> You mentioned that you have to adjust staff distances after 
> determining line-breaks, and if the line-breaking changes you have to 
> redo the adjustments.  I believe that this is a deficiency of the 
> program, i.e. ideal notation program would automatically adjust staff 
> distances so that you wouldn't have to correct them when line breaking 
> changes.

But that's exactly what I mean.  If the program does things such that 
manual adjustments to staff distance is not necessary at all, then 
indeed, N = 0 in this case, and 0 * 2 is still 0.  But what I am 
observing is that *if* an adjustment is necessary at all (ie, if N > 1), 
then it *will* likely have to be done differently for each set of line 
breaks (ie, N * 2 times).  The statement to which I was objecting 
implied that well-designed programs would somehow bend reality such that 
even in cases where manual adjustments were necessary, the same manual 
adjustments would always be applicable regardless of how many different 
line-breakings you needed to support.  That's not going to happen even 
in a world with flying cars.  *If* a manual adjustment is necessary, 
then it *will* likely have to be repeated - that applies to *all* programs.

It's a subtle point, I guess, but you have to realize that in 
encouraging participation by people familiar with other programs, there 
is likely to be some amount of defensive reaction when these other 
programs are incorrectly characterized as having "serious deficiencies" 
just because they cannot change the fact that N * 2 is, well, N *2.  The 
deficiency might be that they have a larger N than other programs, but 
not the fact that two sets of line breaks means N *2 manual adjustments 
- that's true no matter how big or small your N is.

And while this might seem petty to have to point out, I thought one of 
the whole points of this challenge is to ascertain just how big a 
difference there between programs is in the N-per-page values, and to 
what extent these differences might be offset by the *ease* of making 
the necessary adjustments.  To my mind, these are interesting unanswered 
questions.  *Starting* with a characterization of some programs as 
"seriously deficient" kind of biases things right off the bat and is not 
conducive to conducting meaningful comparisons.

>     So indeed, a program that requires
>     fewer adjustments has the advantage.  But assuming a program
>     requires N
>     adjustments, performing those adjustments for two different sets
>     of line
>     breaks means potentially N*2 adjustments.
>
>
> Yes.  That's why i believe good notation software should have as low N 
> as possible (let's say, in the range of 3-5 adjustments per page).

I agree this is a good goal.  But I also think there is an element to 
this that is about as naive as hoping for style settings to parameterize 
all the different rules a publisher might follow in deciding line breaks.

For instance, in the case you just cited - the decision to add extra 
space between staves to accomodate hairpins - this is also a 
*subjective* and in practice virtually always *human-made* decision.  
It's by no means a given that space should be added between staves to 
accomodate hairpins.  Some editors would prefer putting the hairpins 
outside the staves, or allowing them to cross staff lines, or make other 
adjustments in order to preserve the consistency of staff spacing.  Of 
those willing to tolerate inconsistent staff spacing, Some would readily 
add as much space as necessary to fit default spacing allowances, others 
would strive for a compromise in which they allow things to be more 
crowded than they would otherwise in order to minimize (but not 
eliminate) the need for extra space, and the latter would likely want to 
evaluate this on a system-by-system basis.

As with the determination of line breaks, it might be possible to 
describe a set of "house style" rules to a human, but it would like be 
at least as hard to parameterize these as it would rules regarding line 
breaks.  An editor who goes in to the job willing to accept whatever his 
software suggests as long as it looks good in some vague general sense 
is going to have a very different experience than one who goes in to the 
job expecting to make these decisions himself based on specific 
criteria.  The former is going to prefer software that gets to the 
"vaguely / generally good" state quickly, while the latter is going to 
prefer software that makes the process of getting *exactly* what he 
wants the easiest.

Marc

-------------- next part --------------
An HTML attachment was scrubbed...