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

[Janek W. <lem...@gm...>]

Hi,

2014-01-29 Marc Sabatella <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.
>

Yes, this is a valuable discussion!

>
>   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.
>

Indeed.

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.
>

Ah, it seems that i have misunderstood you previously.  Indeed, i agree.



> 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.
>

You're right, i'm sorry!  Obviously, i'm biased towards LilyPond here.
I'll try to be more careful.

   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.
>

Agreed; making the program understand every subtle nuance and provide
options for everything is extremely hard.  However, i believe that it is
perfectly doable to make the software understand vast majority of such
cases (something like 95%?) - much more than now.



>   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.
>

Indeed.

best,
Janek
-------------- next part --------------
An HTML attachment was scrubbed...