Re: cresc. whitespace padding

[David Kastrup]

EdBeesley <address@hidden> writes:

[...]

> I'm sensing a certain level of hostility here which I don't think is
> completely deserved....  I'm assuming from your experience and knowledge
> that you are a programmer first and foremost?

You mean, as opposed to a human being?

> So for example if you saw the first solution

No.  I just picked the keywords that Thomas Morley provided and looked
in the index of the manual for them.  Without even bothering to look at
the first solution.

> and then consulted the suggested entries in the manual you'd
> immediately spot the connections and be able to figure out how to
> create your own function.

The manual gives the example:

<URL:http://lilypond.org/doc/v2.16/Documentation/notation/substitution-function-examples>

padText =
#(define-music-function
     (parser location padding)
     (number?)
   #{
     \once \override TextScript #'padding = #padding
   #})

\relative c''' {
  c4^"piu mosso" b a b
  \padText #1.8
  c4^"piu mosso" d e f
  \padText #2.6
  c4^"piu mosso" fis a g
}

Which could be considered suffering from a bit of overuse of "padding"
both as symbol and as argument, if we are assuming no previous clue
about what this may be about.  It probably would have helped if the
non-function version of the code was written out before that.

> Whereas I saw the entry in the manual and just thought 'where the hell
> do I go from here'.

It helps if you _mention_ what manual entry you did not get along with
and why if you want to avoid the impression that you did not actually
look.

> How to solve this? Ideally make it so I don't have to delve into
> complex code to do things like this. But then that depends on what the
> target market of Lilypond is... If it's for professional typesetters
> (e.g. people who use winScore) then absolutely they should be expected
> to have intimate knowledge of the inner workings of Lilypond to enable
> them work out how to do all the complex and crazy things they no doubt
> have to do on a daily basis.

You _totally_ evade the question about how the manual entry (or its
navigation) could have been improved to actually make you not require
additional help.  Instead you insist that "programmers" or whoever else
should feel responsible for manually solving your problems.

> But if you're after your average Sibelius/Finale user who just wants
> nicer looking music than those 2 programs can offer but doesn't want
> to have to spend hours and hours (and it /has/ taken me hours and
> hours to get even a basic understanding of how Lilypond works, and I
> don't regard my level of stupidity as particularly above average) on
> figuring out how to do things that aren't documented directly yet,
> (e.g. this whitespace thing I originally posted about) then I think
> necessitating this level of knowledge will switch a lot of people off.

So how about pointing out _particular_ problems?  A rant is very nice
and all, but it does not help us improve our documentation.

> Speaking personally if it wasn't for the fantastic level of support
> I've received from all the generous people on this mailing list then I
> simply wouldn't have bothered with Lilypond in the first place, as I
> don't have the time to spend working stuff out that someone else can
> answer in 10 seconds.

Didn't playing an instrument require you to work stuff out that someone
else could play just right away?  And do you really think that Thomas
Morley invested a mere 10 seconds for each of his very elaborate answers
to you?

> I know the point of the manual/tutorials is to enable me to work
> things out easily, but, as I mentioned earlier, sometimes you look at
> things and without a programmer's mindset it just looks
> insurmountable.

So can you point out _what_ exactly looked insurmountable without a
programmer's mindset?  And how it could have been made surmountable?

> Has anyone ever broached the topic of a subscription "help-line" forum
> or something like that? If there was a way I could pay a subscription
> fee and then get suggested snippets like the above without having to
> spend time trying to work it out first I would sign up
> immediately.

Suggested snippets are both in LilyPond's online manual under
<URL:http://www.lilypond.org/doc/v2.16/Documentation/snippets/> as well
as on <URL:http://lsr.dsi.unimi.it/>.

> This way I wouldn't have to feel guilty about asking a question and
> people with superior knowledge would get more than just a thank you
> for their time...

You'll find that things are even more counterintuitive in that regard
than LilyPond's documentation.  At the current point of time, Thomas
Morley is likely the single most helpful "help-line" person around.  Now
you would imagine that this would most likely lead to people paying him
small amounts of money as appreciation.

The reality is rather that he as well as others pay me, probably one of
the less helpful people around here, regularly not so small amounts of
money so that I keep improving LilyPond including its manual.

Because when more people can make sense from LilyPond and its manual,
more people can profit from LilyPond with less work for everyone
involved.

So in essence, Thomas is _paying_ for the privilege of being able to
help more people.  And there are others in the list of people financing
my work on LilyPond where you'd say "haven't they done more than enough
for LilyPond already?".  I don't consider that overly fair either, but
it's quite harder for me to reach for the pockets of those who are not
in love with LilyPond to the degree of having actually invested a lot of
time for its sake already.

Now you are basically saying that Thomas _wastes_ his money, at least
regarding the part where it goes to letting me work on making the manual
more human-understandable, because you consider the manual useless: you
explicitly state that you will not look anything up that anybody else
can solve for you in a reasonably short amount of time, and it's very
hard for a manual to compete with _that_.

But that does not mean that one should not try.  Can you suggest how the
manual could have been improved to you in a manner making it useful for
you in this case?

-- 
David Kastrup