Re: Do we really offer the future?

[Gilles]

On Mon, 20 Apr 2015 10:22:23 -0400, Kieren MacMillan wrote:
> Hi Andrew (et al.),
>
> > I would have thought that, like the invention of desktop publishing 
> > in the 1980’s, which allowed small scale companies and individuals to 
> > produce professional publications, lilypond frees composers, 
> > musicians, and engravers from the tyranny - and rejections - of the 
> > hidebound established music publishers. Why do we need Peters and 
> > Barenreiter and others?
>
> Have you seen the “graphic design” of the millions of people who
> bought a Mac (or whatever) and Adobe Illustrator (or whatever) and
> started cranking out “design”? The situation is exactly analogous in
> the music world: the vast majority of people (composers, etc.) 
> *think*
> they know how to make a readable music score, or at least trust that
> Finale/Sibelius/whatever will do it for them, and the results are
> atrocious.
>
> Publishing houses, for the most part, are Awfulness Sieves… and as
> such are [mostly] necessary evils, at a certain level.
>
> > My composer colleague of the New Complexity School will never be 
> > published by the Big Firms. But he will be published by me. And with 
> > the web nowadays, the big distribution networks the Old Companies have 
> > is no longer important.
>
> For better or worse, I have chosen to self-publish my own works. But
> I’m not deluding myself into thinking that “the big distribution
> networks the Old Companies have is no longer important” — that’s a
> fallacy, and easily debunked. It may well be that *one day* that
> statement will be more true than false… but we’re still at least a
> decade off from that Rapture, maybe more.
>
> > I would like to see every engraver using lilypond
>
> I don’t really care; I only care about engraving quality. What I
> *would* like to see is every engraver outputting music of equal or
> superior quality to the scores I engrave myself in Lilypond, and
> that’s clearly not happening right now.
>
> If (as some have suggested) Steinberg’s pending application has
> output of equal or greater quality to Lilypond, and there is some
> reasonable way (e.g., MusicXML or MEI) for me to “own the source
> indefinitely”, that application's ease of use (read: GUI and other
> tools and workflows) could certainly sway me into abandoning 
> Lilypond.
>
> Unlike many on this list, I have no burning need to force Open Source
> Philosophy on the world if it’s not willing to prove its own worth.

In
  F - Free
  L - Libre
  O - Open
  S - Source
  S - Software
the most important word is "Libre" (as in "freedom").

When people put convenience above all, they start giving up their 
freedom.
And yes, we are heading in that direction (through lazyness, despite 
all
the wonderful work build by the _original_ OSS movement, and the 
increasing
availability of free alternatives).  It's the wrong direction.

> > If [established firms] need vast amounts of explaining to understand 
> > it, they simply will not get it.
>
> So true. Hence my repeated pleas to try to make Lilypond usable
> without vast amounts of explaining.

In some sense, LilyPond is usable with a little amount of explanation.
As you know, some people will turn away just because of text input,
even though I'm sure that, for simple tasks, it requires less time get
up to speed with LilyPond than with a GUI software. [That is, unless
one insists that softwares must be usable without reading the usage
instructions...]

Vast explanations are needed for example when it comes to making things
that are not part of the LilyPond "language".
[Whenever Scheme code is part of the solution, it can never be easy
from viewpoint of someone who does not know the language.]

It may also be a "problem" that the software is so flexible: there
are (too?) many ways to organize a large work, at which LilyPond is
probably much better than the competition.
Along the years, several "add-ons" (templates, makefile, scripts,
snippets) have been mentioned here but, unless I'm mistaken, they
didn't yet evolve into a compelling "standard" set of files with
features that would cover most needs.
As a concrete example, I'd favour recommending that _any_ piece of
music (small or large, it does not matter) be encoded in files that
separate layout from contents; the official documentation provides
templates where everything is in a single file.


Best regards,
Gilles

> Cheers,
> Kieren.