Re: promoting LilyPond

2014-01-05 Thread Janek Warchoł
2014/1/2 Trevor Daniels t.dani...@treda.co.uk:

 Janek, you wrote Monday, December 09, 2013 11:31 PM

 I saw Trevor's snippet and it's really nice!  Now i'm waiting for the
 pull request :)

 Sorry to be late in replying, but you may have seen this has now
 been pushed to master, so it will be incorporated in the next
 release of LilyPond.  That version uses the much improved
 code supplied by Devon Schudy.

Yes, i saw it - looks great!
thanks,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2014-01-02 Thread Trevor Daniels

Janek, you wrote Monday, December 09, 2013 11:31 PM


 2013/12/6 Trevor Daniels t.dani...@treda.co.uk:

 Janek Warchoł wrote Thursday, December 05, 2013 11:29 PM

 2013/12/6 Trevor Daniels t.dani...@treda.co.uk:

 A simpler approach would be to embed templates into LP so that they
 could just be invoked.  The template would provide the context structure
 of a particular type of score, and also define the variables needed.

 I very much like it!

 Could you add it to
 https://github.com/openlilylib/snippets/tree/master/templates

 I could, but I'll need to annotate them first.  And as I said above,
 a pair of \include'd files are needed, one at the top and one at the
 bottom - the user code goes in-between the two.
 
 I saw Trevor's snippet and it's really nice!  Now i'm waiting for the
 pull request :)

Hi Janek,

Sorry to be late in replying, but you may have seen this has now
been pushed to master, so it will be incorporated in the next
release of LilyPond.  That version uses the much improved
code supplied by Devon Schudy.

Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-09 Thread Janek Warchoł
2013/12/6 Trevor Daniels t.dani...@treda.co.uk:

 Janek Warchoł wrote Thursday, December 05, 2013 11:29 PM

 2013/12/6 Trevor Daniels t.dani...@treda.co.uk:

 A simpler approach would be to embed templates into LP so that they
 could just be invoked.  The template would provide the context structure
 of a particular type of score, and also define the variables needed.

 I very much like it!

 Could you add it to
 https://github.com/openlilylib/snippets/tree/master/templates

 I could, but I'll need to annotate them first.  And as I said above,
 a pair of \include'd files are needed, one at the top and one at the
 bottom - the user code goes in-between the two.

I saw Trevor's snippet and it's really nice!  Now i'm waiting for the
pull request :)

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-09 Thread Janek Warchoł
2013/12/6 Johan Vromans jvrom...@squirrel.nl:
 Trevor Daniels t.dani...@treda.co.uk writes:

 A real example using a template which
 provides an SATB choir on two staves with lyrics between them and
 a piano staff with accompaniment is attached.

 I've been using a similar approach for SLHML choir, with a skeleton
 template (attached). I haven't been able to add this to LSR since it's
 not a snippet file, but a package of associated files.

Now, this is *exactly* one of the reasons why i have a beef with
current LSR design[1], and why i insisted on creating
openlilylib/snippets repository.

Johan, feel invited to contribute it to https://github.com/openlilylib/snippets

best,
Janek

[1] i don't mean to say that LSR is wrong and unneeded!  LSR is
awesome, but we need something more awesome :-)

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-06 Thread David Kastrup
Urs Liska u...@openlilylib.org writes:

 David Kastrup d...@gnu.org schrieb:

We need to figure out how we can provide style sheets, similar to how
LaTeX makes it possible to define document classes (layout
definitions
and tools) and packages (raw functionality packaged into coherent
interfaces).

Moving in the direction where this is possible also takes some pressure
of stable/unstable development and features/fixes: something which
comes
in its own, optionally used file is not disruptive to the core
stability.


 You can imagine that I like this idea ;-)
 Would also make it more straightforward for editors to implement
 functionality based on LilyPond or Scheme code that's not part of
 LilyPond itself.

 Is this just a thought or has there already been discussion about this?

I think this has been mentioned a few times as an idea.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-06 Thread David Kastrup
Johan Vromans jvrom...@squirrel.nl writes:

 Trevor Daniels t.dani...@treda.co.uk writes:

 A real example using a template which
 provides an SATB choir on two staves with lyrics between them and
 a piano staff with accompaniment is attached.

 I've been using a similar approach for SLHML choir, with a skeleton
 template (attached). I haven't been able to add this to LSR since it's
 not a snippet file, but a package of associated files.

 A nice feature is that any context left without input is not printed,
 so the same template could be used for SA and piano, just piano, a
 variable number of verses, etc.

 Exactly.

 \use SA-TB-B-template

 An important 'feature' of the hypothetical \use (as opposed to \include)
 would be that it can do things in the beginning (e.g., settings), and at
 the end (e.g., handle the \score part(s)).

Well, actually \include can be made to do that perfectly well since the
\score parts are handled by hooks.  But there is no nice user interface.

The LaTeX distinction between class and package makes another point:
there must always be exactly one document class, but you can have an
arbitrary number of packages since those are providing features, not a
layout.  With LilyPond, the exactly one relation for document classes
would not really hold: basically we have one per \score block.

I'm not saying that we should copy the nomenclature, but differentiating
between something providing a layout (or rather, all relevant output
blocks) and something providing functionality makes sense.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Janek Warchoł
Hi,

2013/12/2 David Kastrup d...@gnu.org:
 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.

I can do this at any moment.  But how to make sure that it won't end
up as another long rant that everybody reads but noone acts upon?  The
last thing i want is to waste time on talking instead of doing
something.
I honestly don't know how to proceed here!

 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.

For starters, we could take
https://github.com/openlilylib/snippets/tree/master/templates/predefined-instruments
and expand it, and add such predefined instruments to official
LilyPond.  I think it would make structural work much easier (esp.
for beginners).

Just take a look at the simplicity this could give us: this
https://github.com/openlilylib/snippets/blob/master/templates/predefined-instruments/simple-example.ly
can produce the attached output.  Defining this stuff manually would
take 2-3 times more code and a lot of doc study.

Last time i got stuck on something in this template, but if you (or
someone else experienced with scheme functions) would offer to help,
i'd like to get back to this.

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

Indeed, such separation of content and structure is a very good thing,
and i try to design my templates that way.  But my point was that
currently i'm the only one in my choir who can get hold of structural
stuff, because it's complicated.


2013/12/3 Carl Peterson carlopeter...@gmail.com:
 2. Floating lyric spacing. Right now, lyrics are by default centered
 underneath the note they are attached to. This is fine in many
 circumstances, but when there are multiple stanzas with syllables of varying
 length, this can create some irregular spacing and general ugliness.

This is bugging me for *years*.  See
http://code.google.com/p/lilypond/issues/detail?id=2456
I tried solving it in summer 2012, but I failed...  I expect that by
2015 i should have enough skill to fix it.


2013/12/3 flup2 phili...@philmassart.net:
 Regarding the feeling of people about the quality of their tool, it's
 simple: most people don't think that their Word layout is crappy. The same
 can occur with musical scores, except that even less people know musical
 typography. So, a lot of people won't think or feel my score is bad if
 they don't know which way they could loot better. Some situation will show
 LilyPond better, other will show Finale or Sibelius.

That's why i'm talking with every musician i meet and show him/her
some engraving comparisons that demonstrate real, serious problems
(not just this doesn't look nice stuff that is mostly mentioned in
the Essay).

I'm quite surprised that noone (did i overlook someone?) expressed
interest in getting these comparisons and translating them, despite my
offer.

best,
Janek
attachment: example.png___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Urs Liska

Am 05.12.2013 18:09, schrieb Janek Warchoł:

I'm quite surprised that noone (did i overlook someone?) expressed
interest in getting these comparisons and translating them, despite my
offer.
There were some people mentioning that, but actually it looks like you 
had Polish texts to offer, and I doubt there are many here that could 
translate them


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Noeck

Am 05.12.2013 18:28, schrieb Urs Liska:
 Am 05.12.2013 18:09, schrieb Janek Warchoł:
 I'm quite surprised that noone (did i overlook someone?) expressed
 interest in getting these comparisons and translating them, despite my
 offer.
 There were some people mentioning that, but actually it looks like you
 had Polish texts to offer, and I doubt there are many here that could
 translate them

Hi Janek,

at least I know people speaking Polish ;) I would like to have a look
(even if I probably don't have the time to translate it).

Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread David Kastrup
Janek Warchoł janek.lilyp...@gmail.com writes:

 2013/12/2 David Kastrup d...@gnu.org:
 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.

 I can do this at any moment.  But how to make sure that it won't end
 up as another long rant that everybody reads but noone acts upon?

Oh, it _will_ end up as another long rant that everybody reads but noone
acts upon for a long time.

Issue 3682 tooks decidedly more than a year before I acted upon it.
That's because it's not really convincing me without issue 3648.  And
for issue 3648, things had to be sorted out in the parser before it
became feasible.  And, of course, 2.18 had to be branched off.

A lot of things take a basic constellation of things to be right before
they can be done sensibly.  But such a constellation will not be reached
by chance: one has to work on it.  And that means that one has to have
some goals in the back of one's mind.

A few months ago, I worked on the meaning and implementation of
\defaultchild and the relation to implicit contexts.  Work which seems
utterly without purpose.  It isn't.  I have some tasks in the back of my
mind which move closer to be doable because of those changes.

 For starters, we could take
 https://github.com/openlilylib/snippets/tree/master/templates/predefined-instruments
 and expand it, and add such predefined instruments to official
 LilyPond.  I think it would make structural work much easier (esp.
 for beginners).

We need to figure out how we can provide style sheets, similar to how
LaTeX makes it possible to define document classes (layout definitions
and tools) and packages (raw functionality packaged into coherent
interfaces).

Moving in the direction where this is possible also takes some pressure
of stable/unstable development and features/fixes: something which comes
in its own, optionally used file is not disruptive to the core
stability.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Janek Warchoł
2013/12/5 Urs Liska u...@openlilylib.org:
 Am 05.12.2013 18:09, schrieb Janek Warchoł:

 I'm quite surprised that noone (did i overlook someone?) expressed
 interest in getting these comparisons and translating them, despite my
 offer.

 There were some people mentioning that, but actually it looks like you had
 Polish texts to offer, and I doubt there are many here that could translate
 them.

2013/12/5 Noeck noeck.marb...@gmx.de:
 at least I know people speaking Polish ;) I would like to have a look
 (even if I probably don't have the time to translate it).

Hmm, it seems that i didn't make myself clear.  I meant to say that
i'll gladly do the translation *if* there are people who'd actually
use it (and contribute back similar lily-marketing materials).

Since there seems to be some interest, i'll post what i currently have
(in a separate thread).

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Werner LEMBERG

 Just take a look at the simplicity this could give us: this
 https://github.com/openlilylib/snippets/blob/master/templates/predefined-instruments/simple-example.ly
 can produce the attached output.

... and I see a buglet in this image: The vertical line in the
Soprano's ambitus must not degenerate to a dot.  Either the line gets
omitted completely, or it gets stretched a bit.


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Urs Liska




David Kastrup d...@gnu.org schrieb:

We need to figure out how we can provide style sheets, similar to how
LaTeX makes it possible to define document classes (layout
definitions
and tools) and packages (raw functionality packaged into coherent
interfaces).

Moving in the direction where this is possible also takes some pressure
of stable/unstable development and features/fixes: something which
comes
in its own, optionally used file is not disruptive to the core
stability.


You can imagine that I like this idea ;-)
Would also make it more straightforward for editors to implement functionality 
based on LilyPond or Scheme code that's not part of LilyPond itself.

Is this just a thought or has there already been discussion about this?

Urs
-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Janek Warchoł
2013/12/5 Werner LEMBERG w...@gnu.org:

 Just take a look at the simplicity this could give us: this
 https://github.com/openlilylib/snippets/blob/master/templates/predefined-instruments/simple-example.ly
 can produce the attached output.

 ... and I see a buglet in this image: The vertical line in the
 Soprano's ambitus must not degenerate to a dot.  Either the line gets
 omitted completely, or it gets stretched a bit.

... and 10 points for Werner Lemberg for eagle sight!
However,
http://code.google.com/p/lilypond/issues/detail?id=3525
and thus
attachment
:-)


simple-example.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Werner LEMBERG

 We need to figure out how we can provide style sheets, similar to
 how LaTeX makes it possible to define document classes (layout
 definitions and tools) and packages (raw functionality packaged
 into coherent interfaces).

*This* is a very worthy project IMHO!  It basically means a lot of
studying lilypond scores out in the wild to get a feeling how users
are arranging stuff.  It doesn't need any knowledge of lilypond
internals, so non-core developers are invited to contribute!  Based on
that there should be an abstraction step to get a sensible interface.


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Werner LEMBERG

 ... and I see a buglet in this image: The vertical line in the
 Soprano's ambitus must not degenerate to a dot.  Either the line
 gets omitted completely, or it gets stretched a bit.
 
 However, http://code.google.com/p/lilypond/issues/detail?id=3525 and
 thus attachment :-)

Hehe, thanks.


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Janek Warchoł
2013/12/5 David Kastrup d...@gnu.org:
 Janek Warchoł janek.lilyp...@gmail.com writes:

 2013/12/2 David Kastrup d...@gnu.org:
 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.

 I can do this at any moment.  But how to make sure that it won't end
 up as another long rant that everybody reads but noone acts upon?

 Oh, it _will_ end up as another long rant that everybody reads but noone
 acts upon for a long time.

 Issue 3682 tooks decidedly more than a year before I acted upon it.
 That's because it's not really convincing me without issue 3648.  And
 for issue 3648, things had to be sorted out in the parser before it
 became feasible.  And, of course, 2.18 had to be branched off.

 A lot of things take a basic constellation of things to be right before
 they can be done sensibly.  But such a constellation will not be reached
 by chance: one has to work on it.  And that means that one has to have
 some goals in the back of one's mind.

Heh.  I have tried several times to start various discussions among
devs about things that we should have in the back of our minds, but it
seemed to me that each time i failed ;-)

Anyway, it seems that this (talking about problems so that we'll have
them in the back of our minds) is needed.  Do you have any suggestions
about the actual form of such talk?  Should wee restrict topics
somehow or talk about everything?  Should we add our observations to
the tracker with a usability tag?  Should there be someone who'll
introduce topics one by one in some order?

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Trevor Daniels

David Kastrup wrote Thursday, December 05, 2013 5:48 PM

 We need to figure out how we can provide style sheets, similar to how
 LaTeX makes it possible to define document classes (layout definitions
 and tools) and packages (raw functionality packaged into coherent
 interfaces).

A simpler approach would be to embed templates into LP so that they
could just be invoked.  The template would provide the context structure
of a particular type of score, and also define the variables needed.  All
the (new) users would need to do would be to override the values of the
variables with their own music.

You can try this now by simply using \include.  Two \include's are needed:
one which goes at the top of the file to define and set up the default
values of the variables and one which goes at the bottom of the file to
define the context structure.  A real example using a template which
provides an SATB choir on two staves with lyrics between them and
a piano staff with accompaniment is attached.  I've left out the two
include files, but you can easily image what they contain.  You'll see this
is a really easy interface for a new user, as all the complication is
provided by the included file.

A nice feature is that any context left without input is not printed, so the
same template could be used for SA and piano, just piano, a variable
number of verses, etc.

If this mechanism were to be embedded in LP all that would be needed
as the user interface would be something like

\use SA-TB-B-template

before the user code providing the music, as attached.

Just a thought ...

Trevor

\version 2.17.96

\include SA-TB-P-init.ily

#(set-global-staff-size 19)

\header {
  title = 'Twas Cool that Night in Bethlehem
  composer = James L. Alty
  poet = James L. Alty
}

\paper {
  page-count = 2
}

Time = {
  \numericTimeSignature
  \time 4/4
  \tempo 4 = 100
  \repeat volta 4 {
s1*17
  }
  \alternative {
{ s1 }
{ s1 }
  }
  s1*2
  \bar |.
}

Key = { \key ef \major }

LadiesInstrumentName = 
  \markup \right-column \smallCaps { Soprano Alto }

MenInstrumentName = 
  \markup \right-column \smallCaps { Tenor Bass }
  
PianoInstrumentName = \markup \smallCaps Piano

SopranoMusic = \relative {
  \oneVoice R1 | r2 r4 \voiceOne bf'\mp\( | bf bf bf af | bf ef bf4.\) af8\( | g4 g g f |
  g2.\) g4\(\ | f g c, g' | f g bf4.\)\mf g8\(\ | f4 ef ef c | ef2.\) c'4\p\( |
  c4 bf c ef | c bf g f\) | g4.\( f8 g4 bf | c,2.\) ef4\mf\( | f\ g bf\) g\( |
  c4 bf ef4.\)\f c8\(\mf | af4\ g f ef\p | ef1\) | ef | \oneVoice R1 | R1 |
}

AltoMusic = \relative {
  s1 | s2. g'4 | g g af af | g g af4. ef8 | ef4 ef c c |
  d2. d4 | c c af d | c c d4. d8 | bf4 bf af af | bf2. g'4 |
  g4 g g g | g g d d | d4. d8 ef4 ef | af,2. c4 | c d f ef |
  g4 g af4. af8 | ef4 d c c | bf1 | bf1 | s1 | s1 |
}

TenorMusic = \relative {
  \oneVoice R1 | r2 r4 \voiceOne ef' | ef ef ef ef | ef ef ef4. c8 | bf4 bf af af |
  b2. bf4 | af af f bf | af af d4. bf8 | g4 g f f | g2. ef'4 |
  ef ef ef ef | d ef bf bf | bf4. bf8 g4 g | f2. af4 | af bf bf bf |
  e4 d c4. ef8 | c4 bf af af | g1 | g1 | \oneVoice R1 | R1 |
}

BassMusic = \relative {
  s1 | s2. bf4 | bf bf c c | bf bf c4. af8 | ef4 d c c |
  g'2. g4 | bf, d c d | bf c g4. d'8 | ef4 ef bf bf | ef2. c'4 |
  bf4 bf af af | g bf g f| ef4. ef8 c4 bf | c2. ef4 | bf bf d ef |
  c4 g' f4. f8 | f4 g f bf, | ef1 | ef | s | s |
}

VerseOne = \lyricsto Soprano \lyricmode {
  \set stanza = 1.
  'Twas cool that night in Beth -- le -- hem,
  the U -- ni -- verse was still,
  And time and space were full of grace,
  a -- wai -- ting our Lord's will.
  The an -- gels looked on an -- xious -- ly 
  and Ma -- ry gave a sigh.
  And then all heav'n was full of joy: 
  they heard a ba -- by cry.
}

VerseTwo = \lyricsto Soprano \lyricmode {
  \set stanza = 2.
  A ti -- ny boy in swad -- dling clothes 
  lay in a man -- ger bare.
  His love -- ly face was full of grace, 
  with -- out a world -- ly care.
  Then Ma -- ry took him in her arms, 
  her fine be -- lov -- ed son.
  She thanked the Lord for this great gift 
  and all that He had done.
}

VerseThree = \lyricsto Soprano \lyricmode {
  \set stanza = 3.
  An an -- gel from the Lord came down
  to shep -- herds on the hill.
  \hdq Great joy and peace I \tdq bring, he said,
  \hdq and to man -- kind, good -- \tdq will.
  They jour -- neyed down to Beth -- le -- hem
  to seek what they'd been told.
  They found the man -- ger and the boy
  as was fore -- told of old.
}

VerseFour = \lyricsto Soprano \lyricmode {
  \set stanza = 4.
  That ba -- by grew in -- to a man, 
  who saved us from our sin.
  Who died for us up -- on a cross,
  and begs us to come in.
  Why can't we all be like this man,
  and fill our lives with grace?
  To help the poor and weak and lame
  un -- til we see his _ face.
}

PianoRH = \relative {
  \repeat unfold 4 { d' ef g bf2 c ef g af2 } |
  % bar 5
  bf c ef g2 af c ef g |
  % bar 6
  g b d g2. g'4 | af, c f g' ef, f af c g' | af, c f g' d f g bf4. g8 |
  % 

Re: promoting LilyPond

2013-12-05 Thread Trevor Daniels

Janek Warchoł wrote Thursday, December 05, 2013 11:29 PM

 2013/12/6 Trevor Daniels t.dani...@treda.co.uk:

 A simpler approach would be to embed templates into LP so that they
 could just be invoked.  The template would provide the context structure
 of a particular type of score, and also define the variables needed.  All
 the (new) users would need to do would be to override the values of the
 variables with their own music.

 You can try this now by simply using \include.  Two \include's are needed:
 one which goes at the top of the file to define and set up the default
 values of the variables and one which goes at the bottom of the file to
 define the context structure.  A real example using a template which
 provides an SATB choir on two staves with lyrics between them and
 a piano staff with accompaniment is attached.  I've left out the two
 include files, but you can easily image what they contain.  You'll see this
 is a really easy interface for a new user, as all the complication is
 provided by the included file.

 A nice feature is that any context left without input is not printed, so the
 same template could be used for SA and piano, just piano, a variable
 number of verses, etc.
 
 I very much like it!
 
 Could you add it to
 https://github.com/openlilylib/snippets/tree/master/templates

I could, but I'll need to annotate them first.  And as I said above,
a pair of \include'd files are needed, one at the top and one at the
bottom - the user code goes in-between the two.

Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-05 Thread Johan Vromans
Trevor Daniels t.dani...@treda.co.uk writes:

 A real example using a template which
 provides an SATB choir on two staves with lyrics between them and
 a piano staff with accompaniment is attached.

I've been using a similar approach for SLHML choir, with a skeleton
template (attached). I haven't been able to add this to LSR since it's
not a snippet file, but a package of associated files.

 A nice feature is that any context left without input is not printed,
 so the same template could be used for SA and piano, just piano, a
 variable number of verses, etc.

Exactly.

 \use SA-TB-B-template

An important 'feature' of the hypothetical \use (as opposed to \include)
would be that it can do things in the beginning (e.g., settings), and at
the end (e.g., handle the \score part(s)).

-- Johan



LHML.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread Joseph Rushton Wakeling

On 03/12/13 22:47, David Kastrup wrote:

You are aware that the Sibelius development team has been laid off due
to financial problems of their parent company in spite of Sibelius
having a paying market and turning a profit?


Yes, fully.  But there is still _a_ Sibelius development team, there is still 
commercial support and maintenance available, etc. etc.  The worries are 
obvious, but only time will tell how damaging this really is to the software.



Well, you can't lay them off, and you can't prohibit them from
continuing to work on their software like the original authors of
Sibelius who have no right to do anything with the sources written by
themselves any more.

And you can't prohibit anybody else from working on LilyPond in order to
meet a company's needs.


You should not take my words as an endorsement of non-free software, merely a 
recognition of the factors that many users take into account.  Whether or not we 
like it, there is a general perception that commercially-backed software 
(whatever the licence) is in general more viable and future-proof than 
volunteer-driven efforts.


Yes, the processes of contribution-based free software break in different ways 
to the processes of commercial proprietary software -- there are different risks 
and different benefits.  But the fact is, someone using Sibelius now does not 
have to worry about the product being discontinued.  Even if Avid decided to 
discontinue the product, its userbase, brand value and commercial viability 
would mean that someone would step in to buy it.


By contrast, I do worry about what happens to Lilypond if for example you find 
yourself indisposed.  I think we can all agree it would be a severe blow. :-)



No question about that.  I think a necessary step would be to move to
GUILE2 first because the costs and tradeoffs of refactoring stuff
between C++ and Scheme will be different, so this is more or less a
prerequisite to make decisions and be able to factor in their costs.


Makes sense to me.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread David Kastrup
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:

 Yes, the processes of contribution-based free software break in
 different ways to the processes of commercial proprietary software --
 there are different risks and different benefits.  But the fact is,
 someone using Sibelius now does not have to worry about the product
 being discontinued.  Even if Avid decided to discontinue the product,
 its userbase, brand value and commercial viability would mean that
 someone would step in to buy it.

Uh, the original developers of Sibelius made Avid an offer for buying
Sibelius back.  The offer was turned down.

The situation you are talking of is that of a complete discontinuation
of every developer continuity: what someone would be buying would be a
final dump, not a project in development.  Even porting to a different
platform will be difficult.

Betting on Sibelius is nowhere like betting on Microsoft Office on
Windows (which feels more like betting on a race track than on a horse
since if it goes down, it will change how races are done).  It's already
a bouncing ball.

 By contrast, I do worry about what happens to Lilypond if for example
 you find yourself indisposed.  I think we can all agree it would be a
 severe blow. :-)

It would be a blow for its progress but not for its existence.  I fancy
myself to believe that I make a difference regarding where the
equilibrium between maintainability, usability, bit rot, user
experience, releasability and a few other things lies (or rather where
it gravitates quite slowly).

Without me, the equilibrium would likely move differently.  But
hopefully we are nowhere near the state that me quitting would lead to
an unstable situation.

And I have been cited as a reason that scares off new developers, so it
would appear the vacuum would be filled by such new developers stepping
in, and it's to be hoped that they'd be interested enough in maintaining
stability and usability that they'd take care not to go off the deep
end.

Let's not forget that Han-Wen and Jan are basically indisposed (though
available for reference) for most purposes, and that would appear to
have been quite a larger blow that LilyPond got over reasonably well.

Not to mention that Graham left, and it's hard to estimate what the
ultimate cost of that will be, particularly regarding community building
and maintaining.  A good technical lead can't make up for everything:
that's another shift in the equilibrium that happened in the recent
past.

What I am saying is that LilyPond survived a lot, and it survived this
with a reasonable amount of continuity.  A _sale_ of a software without
accompanying infrastructure is not the same.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread Joseph Rushton Wakeling

On 04/12/13 10:33, David Kastrup wrote:

Uh, the original developers of Sibelius made Avid an offer for buying
Sibelius back.  The offer was turned down.


Happy to have this discussion if you want it, but I think it's getting away from 
the point I wanted to make.


It's simply that I don't see the risk of proprietary software stopping being 
maintained or developed as one that is appealing to many current Finale/Sibelius 
users.  The risk of the software being sold to an irresponsible or greedy 
investor, or the risk of development being messed around with for commercial 
reasons, is a different risk (and an argument that IMO carries much more weight).


I understand that we may have simply been talking about the same thing in 
different words, though.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread David Kastrup
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:

 On 04/12/13 10:33, David Kastrup wrote:
 Uh, the original developers of Sibelius made Avid an offer for buying
 Sibelius back.  The offer was turned down.

 Happy to have this discussion if you want it, but I think it's getting
 away from the point I wanted to make.

It's not really a discussion: I am just reiterating points already made
a lot of times with regard to Free Software.  Corporate parents can
easily become a liability rather than an asset, and when that happens,
you are powerless as a user.

If you take a look at serious general-purpose programmers' editing
environments, the market is more or less Eclipse, Emacs, vi clones
(mostly vim).

Open Source and/or Free Software.  general-purpose programmers' are
the buzz phrases where an open community really pays off for a product.
general-purpose since it serves and is served back a larger variety of
applications than the original developers imagined and/or could hope to
care for, programmers' because those are in the situation to indeed
contribute back.

So we need to get LilyPond into the shape where an average programmer
caring about mongolic double flute music can do what is needed to let
LilyPond support it nicely without too many unexpected road blocks.

We're not there yet.  LilyPond is more a humongous blob of an
application rather than a music typesetting _platform_, like Emacs is an
easily extended editing platform.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread Urs Liska

Am 04.12.2013 11:18, schrieb David Kastrup:

We're not there yet.  LilyPond is more a humongous blob of an
application rather than a music typesetting_platform_, like Emacs is an
easily extended editing platform.



Of course this would be a beautiful idea. And it's of course very good 
to work into that direction as we (and particularly you) do.
But would you really think it is possible (actually, not theroretically) 
to reach such a state? Maybe Framework would be a nice label too.


Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread David Kastrup
Urs Liska u...@openlilylib.org writes:

 Am 04.12.2013 11:18, schrieb David Kastrup:
 We're not there yet.  LilyPond is more a humongous blob of an
 application rather than a music typesetting_platform_, like Emacs is an
 easily extended editing platform.


 Of course this would be a beautiful idea. And it's of course very good
 to work into that direction as we (and particularly you) do.
 But would you really think it is possible (actually, not
 theroretically) to reach such a state? Maybe Framework would be a
 nice label too.

Oh, it's not a realistic goal to set.  It never was a goal for Emacs to
become a platform.  It's just more or less a consequence if you have
to serve a lot of different and possibly temporary interests very well
while trying to keep the code base from becoming unmaintainable.

Platform basically implies that the code base needs to get divided
along similar lines as the interest of the community and the various
applications.

The alternatives are staying single-purpose (where single is not
literal but implies a small number), or becoming unmaintainable.

We'll see where LilyPond will end up.  But it's not really a goal you
can set yourself, it's more or less _how_ you go about reaching the
goals that you actually _do_ set yourself.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-04 Thread Joseph Rushton Wakeling

On 04/12/13 11:18, David Kastrup wrote:

It's not really a discussion: I am just reiterating points already made
a lot of times with regard to Free Software.  Corporate parents can
easily become a liability rather than an asset, and when that happens,
you are powerless as a user.


Yes, I'm very familiar with those arguments, and in the general sense I strongly 
agree with them.  It's just that in practice, based on experience, I find that 
the weight others will give to those arguments tend to vary a great deal based 
on context.  So, if you're trying to promote your software solution to other 
people, you need to tailor the message with that in mind.


For example, the risk of your software ceasing to be maintained or developed is 
often (for good reason) not seen as a high risk by users of major proprietary 
software tools.  The risk of a business decision being taken that undermines the 
software's usefulness is taken much more seriously, but even then that risk gets 
offset against costs of migration, and the perceived maintainability of 
alternatives.  In that context having a corporate body to deal with is generally 
considered a major plus (and a volunteer community, often something of a 
negative) regardless of the licensing situation, because it generally attests to 
the economic sustainability of the software in question.


So I'm not disagreeing with you or the general free software philosophy, I'm 
just pointing out that -- like free-as-in-beer -- not all of these benefits are 
necessarily perceived as such by prospective users.  And I think one particular 
point you raised fits that bill.



So we need to get LilyPond into the shape where an average programmer
caring about mongolic double flute music can do what is needed to let
LilyPond support it nicely without too many unexpected road blocks.


Yes.  Generally speaking whenever I consider some development idea in Lilypond, 
I quickly come up against the realization that the investment of time required 
just to work out how to _start_ doing it is extremely large, and doesn't bring 
with it a lot of transferable knowledge.  So, it's difficult to justify putting 
that effort in compared to (say) providing an overview of what I want and 
offering a bounty.



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-03 Thread Garrett McGilvray

On Dec 3, 2013, at 12:55 AM, Martin Tarenskeen m.tarensk...@zonnet.nl wrote:
 
 On Mon, 2 Dec 2013, Garrett McGilvray wrote:
 
 The reason that I came back for a second try was not that it was free, since 
 I had already paid for the real thing.  I don't remember what made me 
 think of it, but I remembered the essay on LilyPond's goal of superior 
 engraving, and I decided to give it a second try. I fared better the second 
 time. I have redone some of my past work in LilyPond, and I like the new 
 results better. I doubt now I'll go back to Finale.
 
 I would be interested to see a comparison of some *good* scores engraved 
 using Finale (and/or Sibelius) and the same scores using LilyPond. Maybe you 
 can post some examples?
 
 It's easy to show a really bad Finale result and compare it with how much 
 better LilyPond can do this.
 
 But it is more fair to compare a good Finale/Sibelius score, prepared by a 
 skilled and experienced Finale/Sibelius user, and then try to use LilyPond to 
 do things better.

If a true comparison between Finale and LilyPond is what you want, then I am 
surely not the person to provide it, because as you say, a truly fair 
comparison should be made by comparing results by people with much experience 
in each program. But if that is not what you want, then I can't help but feel 
that posting my own example of a *good* score of mine would be an invitation 
for everyone to critique what I did wrong in either version. The whole point of 
my post was not that LilyPond was better than Finale but rather to agree with 
David's comment that the fact that LilyPond is free should not be its main 
selling point, because that's not what drew me in. Whether or not LilyPond is 
better is irrelevant to my point, but rather that I perceived it to be better, 
and that is what eventually drew me in.

Now, to focus on a different point: the question as to whether a truly fair 
comparison can be made only by professionals. I have no doubt that an 
experienced professional in Finale (and I've ignored Sibelius because I've 
never used it, so I have no opinion) could produce a better score than the best 
that I can do in LilyPond. But I don't think each one's merit could be totally 
measured based on what one is able to achieve with the greatest skill and 
effort given at tweaks. I am fairly confident that if a person tried an 
experiment to make a sample score in Finale that looked like LilyPond's default 
output, he could nearly well achieve an identical look. He would alter stem, 
line, slur thickness. He could manually position each note to line up with 
LilyPond. He could develop a font that copycats LilyPond's default. In the end, 
the two results would be identical, and based on final output alone, the two 
options would therefore be judged comparable. Of course, default LilyPond is 
not th
 e target goal, but my point is that it is not just about what one can do if he 
applies skill and time to tweaking output. I know that beautiful results can be 
had from either program with much tweaking on both sides, but default output 
should be at least part of the comparison.

Then we come to the fact that there are very many people who use either of 
these programs who are not professionals, or even professionals who do not have 
the time to tweak every score to perfection. In my case, I am very much aware 
of many of the tools to tweak just about everything in Finale. However, first, 
I don't want to have to fight with spacing at the minute level, and secondly, 
as I was trained to read the music, not write it, I won't know the finer rules 
of when and where I should override Finale's default. On the one hand, I look 
at Finale's default output, and on the whole I feel like it looks as it should. 
But then I look at LilyPond's output and see, Oh yeah, that does look more 
correct. That's the best someone like me can do without knowing rules of 
engraving. So in my circumstance, a comparison of what a professional can do is 
irrelevant. I need to know rather what *I* can do or what I have time to do in 
one program or another. So my own comparison of my own work in
  one versus my own work in the other is exceedingly relevant and fair in 
helping me decide which is right for me. That is especially true since I am a 
hobbyist doing my own work for my own use. I'm the only one who needs to be 
pleased in that case.

And all of this is just to explain a comment I made about what aspect of 
LilyPond appealed to me that made me give it a second chance. That seemed to be 
the point of a thread about promoting LilyPond.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-03 Thread Carl Peterson
On Tue, Dec 3, 2013 at 12:01 PM, Garrett McGilvray 
garrett.mcgilv...@icloud.com wrote:


 Now, to focus on a different point: the question as to whether a truly
 fair comparison can be made only by professionals. I have no doubt that an
 experienced professional in Finale (and I've ignored Sibelius because I've
 never used it, so I have no opinion) could produce a better score than the
 best that I can do in LilyPond. But I don't think each one's merit could be
 totally measured based on what one is able to achieve with the greatest
 skill and effort given at tweaks. I am fairly confident that if a person
 tried an experiment to make a sample score in Finale that looked like
 LilyPond's default output, he could nearly well achieve an identical look.
 He would alter stem, line, slur thickness. He could manually position each
 note to line up with LilyPond. He could develop a font that copycats
 LilyPond's default. In the end, the two results would be identical, and
 based on final output alone, the two options would therefore be judged
 comparable. Of course, default LilyPond is not the target goal, but my
 point is that it is not just about what one can do if he applies skill and
 time to tweaking output. I know that beautiful results can be had from
 either program with much tweaking on both sides, but default output should
 be at least part of the comparison.

 Then we come to the fact that there are very many people who use either of
 these programs who are not professionals, or even professionals who do not
 have the time to tweak every score to perfection. In my case, I am very
 much aware of many of the tools to tweak just about everything in Finale.
 However, first, I don't want to have to fight with spacing at the minute
 level, and secondly, as I was trained to read the music, not write it, I
 won't know the finer rules of when and where I should override Finale's
 default. On the one hand, I look at Finale's default output, and on the
 whole I feel like it looks as it should. But then I look at LilyPond's
 output and see, Oh yeah, that does look more correct. That's the best
 someone like me can do without knowing rules of engraving. So in my
 circumstance, a comparison of what a professional can do is irrelevant. I
 need to know rather what *I* can do or what I have time to do in one
 program or another. So my own comparison of my own work in one versus my
 own work in the other is exceedingly relevant and fair in helping me decide
 which is right for me. That is especially true since I am a hobbyist doing
 my own work for my own use. I'm the only one who needs to be pleased in
 that case.

 And all of this is just to explain a comment I made about what aspect of
 LilyPond appealed to me that made me give it a second chance. That seemed
 to be the point of a thread about promoting LilyPond.


Regarding what it takes to make a score look right, I have some rather
direct comparison between LP and Finale. When it comes to something as
relatively-simple as an SATB hymn, my friends who use Finale have to do a
number of things beyond note entry:

* They constantly have to go back and fix horizontal note offsets anytime
they make a change to notes so that the treble and bass clef notes line up
vertically.
* Because they work with shaped notes (and a custom shape note font at
that), they have to do all sorts of tricks with stem lengths to avoid gaps
between some of the noteheads and the base of the stem.
* Any number of other manual tweaks for slurs and ties and such things.

The bottom line is that I can transcribe a hymn note for note using direct
text input into an LP template and fix any entry errors in the space of
20-30 minutes, with few, if any, of the problems my Finale counterparts
encounter. The only manual tweak I use in the music is an override for the
part combiner when I want three notes on a stem (such as a tenor and two
bass notes, which happens rarely in the hymns I transcribe, and almost
never in my own compositions). Everything else is handled by layout-block
overrides, which are stored as a template. By comparison, one person (who
does semi-professional Finale work and is quite proficient with Finale,
from what I've seen) spends 2-3 times that time to get similar results.

The only major defect I tend to see in my output, relative to the same hymn
in Finale, is lyric spacing, particularly horizontal spacing. There are two
features which, if they do not exist, would make the LP settings much
better:

1. Horizontal spacing priority for lyrics rather than note durations. In
other words, can we tell the horizontal spacing engine to space lyric
anchor points more or less equally rather than strictly going by note
durations? The big issue is when there are significant differences in note
durations, such as when a half note appears in the midst of eighth notes.
This creates a huge gap in the spacing. This is particularly ugly at the
ends of lines, since it leaves a huge gap at the end

Re: promoting LilyPond

2013-12-03 Thread Joseph Rushton Wakeling

On 02/12/13 16:00, David Kastrup wrote:

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


I'm not sure that's a selling point, either.  As long as there's a paying 
market, commercial software tends to keep getting maintained.  By contrast the 
risk with Lilypond is that it's vulnerable to the continuing contributions of a 
fairly small set of core volunteers.



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.


A good rule of thumb is, to ask What is easy to do by hand but hard to do with 
Lilypond?  But you can also add to that the question, What is easy to do with 
Finale/Sibelius but hard to do with Lilypond? and What is hard to do with 
Finale/Sibelius and can we find a way to make it easy?


I don't suggest just casually asking those questions but really documenting 
extensively the evidence and experience of users.  Some of those things will 
come up against David's play to your strengths remarks -- there are going to 
be things which are unavoidably difficult in order to make some other things 
very easy, and those will not be the same between Lilypond and WYSIWYG engraving 
software.


But on the other hand, I am not convinced that the most practical way to improve 
Lilypond's future is not to look inside and focus on making sure the internal 
design of Lilypond's codebase is optimal from a 
future-development-and-maintenance point of view.


Graham pointed out to me not so long ago that a problem with new enthusiastic 
contributors is that they can come, fix some issue and in the process break so 
much stuff that it costs far more time to correct it than to just reject the 
contribution out of hand and have one of the existing developers do the work. 
Trying to think about how the codebase could be refactored so that this isn't 
likely to happen seems to me to be a potentially productive way to expand and 
engage the Lilypond community.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-03 Thread David Kastrup
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:

 On 02/12/13 16:00, David Kastrup wrote:
 How about companies which cannot risk getting locked in to software that
 may stop being maintained in future?

 I'm not sure that's a selling point, either.  As long as there's a
 paying market, commercial software tends to keep getting maintained.

You are aware that the Sibelius development team has been laid off due
to financial problems of their parent company in spite of Sibelius
having a paying market and turning a profit?

 By contrast the risk with Lilypond is that it's vulnerable to the
 continuing contributions of a fairly small set of core volunteers.

Well, you can't lay them off, and you can't prohibit them from
continuing to work on their software like the original authors of
Sibelius who have no right to do anything with the sources written by
themselves any more.

And you can't prohibit anybody else from working on LilyPond in order to
meet a company's needs.

 Graham pointed out to me not so long ago that a problem with new
 enthusiastic contributors is that they can come, fix some issue and
 in the process break so much stuff that it costs far more time to
 correct it than to just reject the contribution out of hand and have
 one of the existing developers do the work. Trying to think about how
 the codebase could be refactored so that this isn't likely to happen
 seems to me to be a potentially productive way to expand and engage
 the Lilypond community.

No question about that.  I think a necessary step would be to move to
GUILE2 first because the costs and tradeoffs of refactoring stuff
between C++ and Scheme will be different, so this is more or less a
prerequisite to make decisions and be able to factor in their costs.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


promoting LilyPond (was: Supporting my work on LilyPond financially)

2013-12-02 Thread Janek Warchoł
Hi all,

a very important discussion!  A couple thoughts:

2013/12/1 Carl Peterson carlopeter...@gmail.com:
 LP came out in the midst of other packages that already existed. As a
 result, it is fighting for marketshare in a relatively mature market.
 Granted, it is possible to overcome this hurdle, as Google Chrome seems to
 be doing in the Browser Wars, but it takes something special for that to
 happen. In the case of Firefox and Chrome, that something was IE's truly
 abysmal performance in the IE 6-8 years.

That's true.  What's more, web browser users are just consumers.  With
notation packages, they are creators:
- learning how to create takes days or weeks (while learning how to
consume takes minutes),
- creators have a lot of their content tied to a specific format.


2013/12/1 Kieren MacMillan kieren_macmil...@sympatico.ca:
 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),
- they want to do things the easiest way, and LilyPond will never
appear to be the easiest choice,
- etc.

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.

Still, something like 10% of people *could* be convinced to using
LilyPond.  Some of them (2-3% of notation software users?) would
actually prefer using Lily for some reason.  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),
- public companies with little money, which cannot risk using pirated software,
- people who want to Do Things The Right Way (usually geeks) - these
usually won't be scared by text input at all,
- professional engravers that really want perfect results,
- 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.
- people who still use Score - they do care about quality, they
shouldn't be scared by learning curve,
- organizations funded by governments (0 price should be a big
advantage to them, and gonvernments should be promoting open culture
anyway),
- people who don't use any notation yet - students.


2013/12/1 David Kastrup d...@gnu.org:

 Here are the problems I run into: (1) most musicians/composers/institutions
 are already using something.

 So we need to catch them before they do.  Janek got a number of his
 choir colleagues to enter Stabat Mater (don't remember whose,
 Pergolesi?) into LilyPond.

It was Handel's Dixit Dominus
(http://lilypondblog.org/2013/06/crowd-engraving-whats-that-part-1/) -
very simple notation-wise.  But later we entered more complex pieces
as well.  Still, most of them were geeky people (physics PhD, a
couple programmers, math students).

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.


So, what should we do now?  I suggest to create some comparisons and
promotional materials, similar to what is already in our Essay, but
more diverse and in a more compact form.  I already have some stuff
like that which i could share and translate.  Who'd like to join this
effort?

Also, the currently published series of articles on the
lilypondblog.org aims to make a foundation for this effort (evangelize
about LilyPond).

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-02 Thread David Kastrup
Janek Warchoł janek.lilyp...@gmail.com writes:

 2013/12/1 Kieren MacMillan kieren_macmil...@sympatico.ca:
 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

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-02 Thread James Harkins
David Kastrup dak at gnu.org writes:

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

LilyPond excels at *vertical* malleability, but it's nearly disastrous when it 
comes to horizontal malleability, as I recently opined in another thread. 
Changes to metrical structure, and adding/deleting bars, are difficult, if not 
excruciating. I would argue that these tasks are at least as common, if not 
more common, then the ones you mention here.

hjh


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-02 Thread Garrett McGilvray
I've laid low because I'm still new enough that I don't have much to contribute 
unless it is a question, but here I might actually have something to say:

 On Dec 2, 2013, at 9:00, David Kastrup d...@gnu.org wrote:
 
 Again, I don't think the no money aspect should be a primary selling
 point.

I definitely agree there. We often have the idea that You get what you pay 
for. Too much emphasis on free may cheapen LilyPond in people's minds. 

Personal anecdote: Two or three years ago I gave LilyPond a try as a candidate 
to replace my aging Finale 2000. I eventually decided that free software was 
not going to be sufficient for my needs and that I would have to go ahead and 
pay for the real thing. I doubt whether my assessment was fair, but that's 
the way I saw it. So instead I paid the big bucks (for me) to upgrade to the 
then-current Finale 2011.

I can't remember why I then arrived at the decision I did. I don't know if the 
LP version at that time was insufficient compared to today, or more likely, I 
didn't know how to make it work. It may have been the shape notes (which now I 
know of the super easy \aikenheads).

The reason that I came back for a second try was not that it was free, since I 
had already paid for the real thing.  I don't remember what made me think of 
it, but I remembered the essay on LilyPond's goal of superior engraving, and I 
decided to give it a second try. I fared better the second time. I have redone 
some of my past work in LilyPond, and I like the new results better. I doubt 
now I'll go back to Finale. 

Part of the change of my mindset was my experience with Finale. I was 
disappointed by how little it had improved after 11 years of updates. I became 
disappointed with its output once I saw what LilyPond could do. And although a 
GUI should be quite a bit easier to use for most people, Finale remains to my 
mind one of the most unintuitive GUI programs there is. I spent a lot of time 
in its manuals and searching its forums. 

To get to the point, the you get what you pay for mindset was replaced for me 
by the idea that you can take the easy way out or you can take the time to 
do it right. LilyPond then compared favorably from the second perspective to 
me. It was the challenge that led to perfection.

I hope no one takes offense at these comparisons. I only mean them as my own 
first and second impressions (fair or otherwise) to show how in my case the 
free price was not what drew me in. 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-02 Thread Martin Tarenskeen



On Mon, 2 Dec 2013, Garrett McGilvray wrote:

The reason that I came back for a second try was not that it was free, 
since I had already paid for the real thing.  I don't remember what 
made me think of it, but I remembered the essay on LilyPond's goal of 
superior engraving, and I decided to give it a second try. I fared 
better the second time. I have redone some of my past work in LilyPond, 
and I like the new results better. I doubt now I'll go back to Finale.


I would be interested to see a comparison of some *good* scores engraved 
using Finale (and/or Sibelius) and the same scores using LilyPond. Maybe 
you can post some examples?


It's easy to show a really bad Finale result and compare it with how much 
better LilyPond can do this.


But it is more fair to compare a good Finale/Sibelius score, prepared by a 
skilled and experienced Finale/Sibelius user, and then try to use LilyPond 
to do things better.


In many cases it will be a matter of taste which of the results people 
will like best.


Many of my collegues - actually probably all of them - use Finale or 
Sibelius. I have never heard anyone of them complain My scores look bad! 
Please suggest a better alternative for me!


A comparison: When the audio CD was introduced it became a huge success 
because everyone could hear the difference in sound quality and the 
improvement in user-friendlyness. When after that the Super-Audio CD was 
introduced it was only embraced by a very small number of people who 
wanted the very best sound quality. For most people CD-quality was and 
still is synonym to perfect audio. And even MP3 is good enough for them. 
Why would you need Super-Audio?


--

MT

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-02 Thread flup2
Although it might look strange, I think that fair comparison depends of the
intended use. For advanced users, of course, a finely tuned score of each
software would give better idea of possible end result. But, for a lot of
users who don't need (or want or know how) those refinements and the
standard output (out of the box, without manual tweaking) will be
important.

Regarding the feeling of people about the quality of their tool, it's
simple: most people don't think that their Word layout is crappy. The same
can occur with musical scores, except that even less people know musical
typography. So, a lot of people won't think or feel my score is bad if
they don't know which way they could loot better. Some situation will show
LilyPond better, other will show Finale or Sibelius.

An (really) adventurous image about that could be Plato's Allegory of the
Cave.

Philippe



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/promoting-LilyPond-was-Supporting-my-work-on-LilyPond-financially-tp154839p154896.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: promoting LilyPond

2013-12-02 Thread Urs Liska

Am 03.12.2013 08:23, schrieb flup2:

Although it might look strange, I think that fair comparison depends of the
intended use. For advanced users, of course, a finely tuned score of each
software would give better idea of possible end result. But, for a lot of
users who don't need (or want or know how) those refinements and the
standard output (out of the box, without manual tweaking) will be
important.

Regarding the feeling of people about the quality of their tool, it's
simple: most people don't think that their Word layout is crappy. The same
can occur with musical scores, except that even less people know musical
typography. So, a lot of people won't think or feel my score is bad if
they don't know which way they could loot better. Some situation will show
LilyPond better, other will show Finale or Sibelius.


I have the experience from the dual perspective (producing and 
consuming): Playing in orchestras and ensembles you'll get all sorts of 
scores, and I can definitely second what's written in the lilypond.org 
essay: the better the material the better the performance (I think this 
section of the LilyPond introduction was probably the most important 
single incentive for me to try out LilyPond). But when I'm talking to 
composers about it they only vaguely and theoretically understand what 
I'm saying. In general they consider their scores good enough by 
default. They may think hard about how to unambiguously visualizing 
their intention and help the player with the right cue notes or 
(sometimes) page breaks and the like. But making them accept that the 
engraving quality itself matters is a _hard_ task. Probably composers 
should get mandatory courses in sight-reading from differently engraved 
material throughout their studies ;-)


The Word layout example is very good. I can't think of many fellow 
scholars I've met who'd care for layout and typography of their texts. 
Maybe they're astonished when they see their texts professionally 
typeset in a publication, but they wouldn't start to think about using 
better tools for their own writing.
I know of exactly one fellow student who told us he learnt LaTeX to 
write his doctoral thesis - but not for its typography but for creating 
Schenker like graphics.


Urs



An (really) adventurous image about that could be Plato's Allegory of the
Cave.

Philippe



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/promoting-LilyPond-was-Supporting-my-work-on-LilyPond-financially-tp154839p154896.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user