Re: promoting LilyPond
2014/1/2 Trevor Daniels : > > 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
Janek, you wrote Monday, December 09, 2013 11:31 PM > 2013/12/6 Trevor Daniels : >> >> Janek Warchoł wrote Thursday, December 05, 2013 11:29 PM >> >>> 2013/12/6 Trevor Daniels : 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/6 Johan Vromans : > "Trevor Daniels" 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/6 Trevor Daniels : > > Janek Warchoł wrote Thursday, December 05, 2013 11:29 PM > >> 2013/12/6 Trevor Daniels : >>> >>> 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
Johan Vromans writes: > "Trevor Daniels" 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
Urs Liska writes: > David Kastrup 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
"Trevor Daniels" 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
Janek Warchoł wrote Thursday, December 05, 2013 11:29 PM > 2013/12/6 Trevor Daniels : >> >> 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
Hi Trevor, 2013/12/6 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. I very much like it! Could you add it to https://github.com/openlilylib/snippets/tree/master/templates ? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
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 { 2 2 } |
% bar 5
2 |
% bar 6
2. g'4 | g' g' | g' 4. g8 |
% bar 9
4 ef' | 1 |
%
Re: promoting LilyPond
2013/12/5 David Kastrup : > Janek Warchoł writes: > >> 2013/12/2 David Kastrup : >>> 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
>> ... 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 :-) Hehe, thanks. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
> 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/5 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. ... and 10 points for Werner Lemberg for eagle sight! However, http://code.google.com/p/lilypond/issues/detail?id=3525 and thus :-) 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
David Kastrup 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
> 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/5 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. 2013/12/5 Noeck : > 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
Janek Warchoł writes: > 2013/12/2 David Kastrup : >> 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
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
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
Hi, 2013/12/2 David Kastrup : > 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 : > 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 : > 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 <>___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
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
Urs Liska 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
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
Joseph Rushton Wakeling 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
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
Joseph Rushton Wakeling 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
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
Joseph Rushton Wakeling 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
Re: promoting LilyPond
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
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
Re: promoting LilyPond
On Dec 3, 2013, at 12:55 AM, Martin Tarenskeen 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
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
Re: promoting LilyPond
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
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
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 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
David Kastrup 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
Janek Warchoł writes: > 2013/12/1 Kieren MacMillan : >> 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
promoting LilyPond (was: Supporting my work on LilyPond financially)
Hi all, a very important discussion! A couple thoughts: 2013/12/1 Carl Peterson : > 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 : > 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 : > >> 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
