Re: promoting LilyPond

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> 2013/12/1 Kieren MacMillan <address@hidden>:
>> Urs wrote:
>>> Most people I tried to persuade simply said "this isn't my cup of tea,
>>> I'm not a programmer”.
>>
>> THAT is the main problem right there — one we are likely never to
>> overcome, as much as I hate to admit it.
>
> Yup...  As i see it, 90% of people notating music will never want to
> use LilyPond, and we cannot do much about it:
> - they don't care about high quality (just want "good enough"),

I think the high quality is a nice touch.  Part of the reason we have it
is that the programmers don't spend all of their time catering to GUI
centric stuff.  But it has nothing to do really with text based input.

There are other text-based formats like ABC, MusiXTeX, PMX, GuitarTeX
and so on.  Picking LilyPond over any of them should be a no-brainer,
but it obviously isn't.

> - they want to do things the easiest way, and LilyPond will never
> appear to be the easiest choice,

We should not worry too much about appearance.  It's the realities we
have to work on.  "It's a text based format" is no excuse for
complexity.

One does not make violins more popular by transcribing piano music for
them and vice versa, so we really need to work on playing to our own
strengths instead of being apologetic.

The basic mantra for any tools is: simple tasks should be simple to do.
And we have quite a way to go there still.

> Unfortunately, people who don't have money for Finale/Sibelius usually
> pirate it (instead of using Free Software).  Also, some smaller
> publishers i've talked with seem not to care much about quality
> engraving, and big publishers have a lot of inertia and stick to tried
> programs.

If quality engraving comes at the cost of the amount of manual tweaks
you put into your scores, it's not a selling point for LilyPond.

LilyPond's strengths are what it is able to do automatically:
transpositions, partial partitures, catering to different page formats,
fast adaption to different orchestras...  Your score is _malleable_.

> Let's not waste time trying to convince the ones who cannot be
> convinced, and instead try finding people who may actually like
> LilyPond, but don't know that they could use it:
>
> - people with no money AND strong etthics, who won't pirate software
> (e.g. monks/other religious people that typeset religious music),

Again, I don't think the "no money" aspect should be a primary selling
point.

> - public companies with little money, which cannot risk using pirated
> software,

How about companies which cannot risk getting locked in to software that
may stop being maintained in future?

> - other professionals who would benefit from very advanced workflows
> (using version control).  This is what Urs was talking about and i
> really think it would be a very good opportunity for LilyPond.

Oh, web collaboration and score crowdsourcing is essential.  Mutopia is
all but dead.  Should we try to get a hook into Wikimedia?

At any rate, we need to pitch LilyPond to _ourselves_ and listen what
annoys us.  Particularly when explaining LilyPond to others and/or
pitching it to them.

> The approach i used there (i mean "crowd-engraving") proved to be a
> good one, but we'd have to make a lot things simpler to make this
> really effective.  I mean, i was the only one who could combine the
> parts into the full score - creating \score blocks (real-life \score
> blocks, with all nuances and settings) is too difficult for beginners.

Good, then we have to make a lot of things simpler to make this really
effective.  I would imagine that the "combining parts into the full
score" thing is something that a live template engine for Frescobaldi
should help with.  Where a "live" template is not just some code copied
for a starting point, but more something like a folding editor of a
predetermined structure where you tie parts in that are stored in
separate files.  Then you can hand out that template, and regularly
update those files that people are _not_ currently working on (for
example, git merges fine when everybody edits different files).

-- 
David Kastrup