Re: Quit [now definitely O/T]

[David Kastrup]

Carl Sorensen  writes:

> David,
>
> I appreciate your persistence in this.  I think that you are having part of
> the difficulty in this conversation because it's on -user, not on -devel.
>
> The modifications to anything except input files (which use lilypond code
> and embedded scheme) really involve knowledge that's primarily discussed on
> -devel.

Certainly.  This thread started by a user throwing in the towel, on the
user list, explaining his reasons for doing so.  This was followed by
several comments that questioned his commitment in getting to learn
Lilypond.  As it is my impression that this in several respects was
doing the original poster injustice as well as pasting over existing
deficiencies in how Lilypond keeps up with what it is advertised for, I
wanted to pitch in with my personal take.

_Addressing_ the actual problems is definitely more suitably done on the
developer list.

-- 
David Kastrup



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

version 0.0.0-0

[Martin Tarenskeen]

Hi,

http://lilypond.org/web/install/ is showing version numbers 0.0.0-0 
instead of 2.13.7-1 for the development branch. This is not the first 
time this has happened, so I guess there is someone who will fix this.


--

Martin


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

Re: Manually place a clef object?

[James E. Bailey]

On 11.11.2009, at 22:37, Peter Kaplan wrote:

When a repeated section begins in one clef and ends in another (as  
in the Basso
Continuo part I'm working on), it would be nice to be able to add a  
"reminder"
clef at the end of the repeated section, to alert the player to  
return to the

original clef when the repeat sign is reached.

This behavior is easy to implement when the repeated section comes  
at the end of
the score; a simple \clef tenor can be placed after the final note  
and the tenor
clef will appear between the final note and the end of the bar --  
perfect.


However, when the repeated section does not come at the end of the  
score, this
same fix fails.  Lilypond instead looks to see if there are any  
notes following
the reminder clef, finds none, and omits the reminder clef when  
engraving.  Is
there an alternative way to manually place a clef object for use in  
such cases?


Snippet can be found at http://pefty.elementfx.com/audio/snippet.ly


In such a case, I would use markup: have a hidden time signature with  
one extra quarter note, remove the stem from the note engraver,  
change the stencil for the notehead to be the requested clef, and  
then use either \raise or \lower to get it to the proper height.


James E. Bailey



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

Re: documentation formats

[David Kastrup]

Kieren MacMillan  writes:

> Hi Graham,
>
>> If we did stuff in plain html, we'd lose the pdf docs.  If we did
>> stuff in plain latex, we'd lose the html docs (without a lot of
>> tweaking).  Both would lose the info docs, which IMO wouldn't be
>> terrible, but some people seem to like.
>
> I don't even know what the "info docs" are, so IMO...?

Let me post a screen shot from Emacs.

<>
This opens right in my editor window.  It has structured navigation
which does not go off-screen, you can navigate using single keypresses,
you can search plain text, you can copy and paste, rendering is
instantanously, the whole document is indexed and you can navigate by
search index.  And it shows both Lilypond input and output.

Very valuable if you use Emacs, still useful when using an external info
reader.  I can switch back and forth between info pages and source code
without changing my editing window.

Yes, it is a life-saver for working with Lilypond with me.

-- 
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: documentation formats

[David Kastrup]

Graham Percival  writes:

> On Wed, Nov 11, 2009 at 05:47:28PM -0500, Kieren MacMillan wrote:
>> Werner,
>>
>>> What's the problem here?
>>
>> The problem is that I come to Lilypond with a skill set — specifically, 
>> many years of Java+Javascript+(X)HTML+XSL(T)+CSS+(La)TeX experience — 
>> which should be more than adequate for any modern documentation project 
>> involving a WWW component.
>
> If we did stuff in plain html, we'd lose the pdf docs.  If we did
> stuff in plain latex, we'd lose the html docs (without a lot of
> tweaking).  Both would lose the info docs, which IMO wouldn't be
> terrible, but some people seem to like.

Emacs as an editor is enough of a suggestion for developers that the
question "how do I indent code?" is answered "as lilypond-mode does".
Navigating through info is much faster and more direct than through HTML
which is one of the main reasons Emacs (and GNU) never switched to
something else.

> I asked for alternate ideas almost a year ago (I think it was
> Jan), but after looking at various suggestions, we decided that
> texinfo was still the best way to go.

git uses Asciidoc which outwardly looks less intimidating and more
directly readable (and can produce man pages as well).  But both the
resulting XML/Docbook layer as well as the Asciidoc translator are
lousily documented.  I've had quite a bit a problem with those.

HTML directly misses too much structure and information which is nice to
have in some hypertext readers.

>> I guess what I'm really saying is, if we think the barrier-to-entry
>> for USERS is high, we've got another thing coming re: DEVELOPERS...
>> =\
>
> As you can see on -devel, I've been trying to make the build system
> easier (including only requiring texi2html (perl) and lilypond-book to
> make the docs).  But that's *another* highly non-trivial problem.

Really, Texinfo is a better choice than some other popular options
because it is reasonably well maintained and documented.  It means
people can come along and have a chance of learning things without
external help.  Or with.  And it's clear enough to mostly
fly-by-example.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[Carl Sorensen]

David,

I appreciate your persistence in this.  I think that you are having part of
the difficulty in this conversation because it's on -user, not on -devel.

The modifications to anything except input files (which use lilypond code
and embedded scheme) really involve knowledge that's primarily discussed on
-devel.



On 11/11/09 1:36 PM, "David Kastrup"  wrote:

> Kieren MacMillan  writes:
> 
>> 
>> c.f. 
>> > e>
>> What needs to be added/improved? Once again, I'm sincerely asking,
>> since you obviously still have questions about Lilypond coding style
>> that weren't answered by that page (and surrounding ones).
> 
> Uh, have you read it?  It worries about things like indentation, says to
> prefer C++ over Python (but Python please in "PEP 8" whatever that fancy
> acronym is supposed to be), and some identifier names.

I agree.  But at least for now, the coding style rules for LilyPond are the
GNU coding style without modifications.  Hence, the limited stuff that seems
to not make much sense.

> It does not say
> what kind of code to put where for what reason.
> 
> That is: it tells you minor details about how source should be formatted
> once you know perfectly what you are doing and which part of the code is
> appropriate to use.  Namely it tells you about the difference between
> something that compiles and fits in with the rest of the _code_.  It
> does not tell you what language/classes/operations to use to implement
> what kind of task.

That's right.  This kind of documentation does not exist.  Several years ago
I couldn't understand LilyPond at all, so I started trying such a document.
It didn't get very far and it wasn't very accurate (but it did get a
reference in Erik's thesis as the only available description).

I'm still not sure I'm up to speed.  I have some knowledge, but probably
just enough to be dangerous.  I could write a little bit better description,
but probably not a really *good* one.

> 
>>   
>> Same question as above.
> 
> The thesis is a thesis.  It is unclear what state of Lilypond it
> documents, and what the current state of Lilypond embeds from what is in
> the thesis.
> 
> And some thesis on the web is not a good substitute for programming
> docs.  Because it does not evolve with the program.

I agree, but the fact is that the thesis *is* currently the best description
we have of LilyPond's overall architecture.  And it is current, and will
likely be current at least through all of 2.x.  Details have changed, but
not the overall structure.

>> 
>>> The internals documentation should likely spell out the layers of C+
>>> +, Scheme, Music macros and what one can hope to reasonably implement
>>> in what layer.  What new functionality requires equivalence of new
>>> engravers or performers, can one implement them in Scheme, does one
>>> need C++, and what exactly does one _do_ when creating them?

I agree that this information is needed.  It doesn't belong in the internals
documentation, which is a dictionary, as described before.  It probably
belongs in the Contributors' Guide, or a separate Program Architecture
manual.

Would you be willing to create an outline of a Program Architecture manual?
It could have headings that relate to your questions, and then we could fill
in the answers, roughly at first and later in greater detail.

>> 
>> The introductory page
>> > -architecture#Overview-of-LilyPond-architecture>
>> does spell this out, I believe.
> 
> I don't see this.  Mostly, it points to sources for reference.  That's
> useful to some degree.  But if people write sources with only sources
> for reference, any design inherent in the first generation of the
> sources is going to become less and less discernible with successive
> layers of code.

As a matter of fact, Han-Wen is consistent in telling us to "Use the Source,
Luke", rather than referring to other materials. So referring to the source
is important, but need not be exclusive.

> 
> More educational than studying how existing code is written would be to
> study how the code is _supposed_ to be written.  Some self-contained
> example with well-defined functionality that sits well in the scheme of
> things.  If people can't make their own code as simple and
> self-contained (or see existing "real" code much uglier), that is an
> incentive for improving the state of their and preexisting "real" code.

I think this is a great idea -- a sort of Learning Manual for programming.
Aimed not at users, but at developers.  Something that works through a
simple engraver, and describes the key components that are used.

I don't know that we have anybody who knows enough and has the time and
interest to write such a beast, but it would probably help increase the
number of developers on the project.  I've cross-posted

Re: documentation formats

[Graham Percival]

On Wed, Nov 11, 2009 at 06:39:26PM -0500, Kieren MacMillan wrote:
> Hi Graham,
>
>> If we did stuff in plain html, we'd lose the pdf docs.  If we did
>> stuff in plain latex, we'd lose the html docs (without a lot of
>> tweaking).  Both would lose the info docs, which IMO wouldn't be
>> terrible, but some people seem to like.
>
> I don't even know what the "info docs" are, so IMO...?

Have you heard of man?  As in
   man ls
?  it works on OSX.

info is basically "man on steroids".  It might work on OSX; I
can't remember.  Try
   info gcc
and see if you get anything.


> For the record, I only want to do this documentation stuff for three  
> reasons:
>   1. Get my build system in place (i.e., learn git, get dependencies  
> installed, etc.);

Ok.  The Contributor's Guide is definitely the place for that.

>   2. Satisfy [i.e. shut up] the people who say that the docs are what's 
> keeping them/Lilypond/worldpeace from advancing; and,

Ah good, so it's not just a one-time website thing.  :)
*cough*  website / general.pdf / lilypond-general.info

>   3. Get comfy enough with the whole Lily-dev process to "graduate" 
> (i.e., fix some real bugs and add some real features).

I'm fine with that.  I mean, I'll be sad to lose another doc
writer, but I have no problem with the docs as being somewhat of a
"training ground" before people "graduate".  As long as we have
something resembling a stream of newcomers to replace people who
graduate, at least...

Cheers,
- Graham


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

Re: documentation formats

[Kieren MacMillan]

Hi Graham,


If we did stuff in plain html, we'd lose the pdf docs.  If we did
stuff in plain latex, we'd lose the html docs (without a lot of
tweaking).  Both would lose the info docs, which IMO wouldn't be
terrible, but some people seem to like.


I don't even know what the "info docs" are, so IMO...?
All that being said, I've never had a problem writing docs in XML,  
then having a stylesheet to output the HTML (via XSLT) and PDF (via  
XSL-FOP).



I asked for alternate ideas almost a year ago (I think it was
Jan), but after looking at various suggestions, we decided that
texinfo was still the best way to go.


I wasn't part of that discussion, so I guess I lose.  =)


For the benefit of unified presentation /and/ saving your sanity,
I strongly recommend that all you do is copy&paste and change text.


Right — thanks.

For the record, I only want to do this documentation stuff for three  
reasons:
  1. Get my build system in place (i.e., learn git, get dependencies  
installed, etc.);
  2. Satisfy [i.e. shut up] the people who say that the docs are  
what's keeping them/Lilypond/worldpeace from advancing; and,
  3. Get comfy enough with the whole Lily-dev process to  
"graduate" (i.e., fix some real bugs and add some real features).


Alright... back to installing the 24th of 37 (or more?) dependencies/ 
packages...

Kieren.

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

Re: chordSymbols, arbitrary chord markup

[TaoCG]

VáclavŠmilauer wrote:
> 
> I use \chordSymbols hack (http://lsr.dsi.unimi.it/LSR/Item?id=608) in my
> jazz
> charts and although, it works quite well in normal cases, it has some
> limitations: you can't write "C phryg" or combination of 6,7,9,11,13 not
> in the
> font etc. 

"C phryg" doesn't exist, true, but you can write combinations of numbers,
e.g. C7/9/11/13
I personally don't like the expression Cphryg, I prefer to write GbM/C,
that's why I didn't include it in the font. But if you want you can add it
yourself in the font with fontforge.
-- 
View this message in context: 
http://old.nabble.com/chordSymbols%2C-arbitrary-chord-markup-tp26300083p26310664.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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

Re:Quit [now definitely O/T]

[Jonathan Wilkes]

> > 
> > Things like "ritardando" can't be found in the
> notation index and are
> > programmed something like
> > 
> >     Some performance indications,
> e.g., rallentando or accelerando, are
> >     written as text and are
> extended over multiple notes with dotted lines.
> >     Such objects, called
> "spanners", may be created from one note to
> >     another using the following
> syntax:
> > 
> >          \override
> TextSpanner #'(bound-details left text) = "rit."
> >          b1\startTextSpan
> >          e,\stopTextSpan
> 
> Yes, so we should add "ritardando" to the index.  A
> patch is within the
> ability of any LilyPond user, and would be speedily
> applied.
> 
> The code to establish a ritardando could be easily written,
> and may (or may
> not) be done as part of the forthcoming GLISS (Grand
> LilyPond Input Syntax
> Stabilization) project.  There's currently some
> disagreement about whether
> it would be good to define
> 
> spannerText = 
> #(define-music-function (parser location span-text)
> (string?)
>   #{
>       \override TextSpanner #'(bound-details
> left text) = #$span-text
>   #")
> 
> which would allow above example to be coded much more
> easily in the input
> file
> 
> \spannerText "rit."
> b1\startTextSpan
> e,\stopTextSpan
> 
> but would hide the underlying LilyPond functionality (the
> \override) and
> make users less likely to learn how to do overrides that
> they may need to do
> for their own challenging music.
> 
> Stay tuned for the GLISS, and get your own opinion in.
> 
> Thanks,
> 
> Carl
> 

Hello David and Carl,
 I was really excited to read David's suggestion for \startTextSpan 
taking an argument.  For me, it makes much more sense and flows better 
when entering notes to write:

b1\startTextSpan "accel."
c,\stopTextSpan "a tempo"

than the syntax Carl has used above.  I cannot imagine any scenario 
where this would hinder one's understanding of the \override syntax and 
am curious what the reasoning is behind this assumption.

To me, this syntax looks a lot like:

b1^"so easy to learn, retain, type..."
c,_"...and teach!"

Just my two cents.  I'm not a programmer but would be happy to test the 
heck out of this functionality if you know how to implement it, David. 
Well, I'm also happy to test Carl's syntax too if that's the way 
most people prefer it; it's still way better than having to "override" 
the text spanner to enter text (which is still not as bad as having to 
draw your own splayed stem when you click the splayed stem button in 
Finale!).

As for the original topic, I definitely felt a similar amount of 
frustration when initially learning lilypond.  But the recent 
improvements in the documentation kept me on track.  I'll contribute 
some revisions/errata when I finish up my second time through the 
docs.

Thanks,
Jonathan

-Jonathan





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

Re: Quit [now definitely O/T]

[Tim McNamara]

On Nov 11, 2009, at 11:29 AM, David Kastrup wrote:


For me, this situation is awkward, impeding and dissatisfactory.  For
others, it is reason to go away.  I don't see that anything is gained
for chastising me for my impression.  That is merely shooting the
messenger.  Actually, more than the messenger.


This sort of thing is very common in open source projects IME,  
basically "if you can't supply the solution, then you don't have a  
right to complain about it."  I see less of this attitude on the  
LilyPond user list, at least, than in most other open source projects  
I've dealt with (e.g., some of the Emacs Gnus folks can be right  
***holes).  There's usually just one or two who spout a 'tude like  
this here and even that's pretty infrequent.



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

documentation formats

[Graham Percival]

On Wed, Nov 11, 2009 at 05:47:28PM -0500, Kieren MacMillan wrote:
> Werner,
>
>> What's the problem here?
>
> The problem is that I come to Lilypond with a skill set — specifically, 
> many years of Java+Javascript+(X)HTML+XSL(T)+CSS+(La)TeX experience — 
> which should be more than adequate for any modern documentation project 
> involving a WWW component.

If we did stuff in plain html, we'd lose the pdf docs.  If we did
stuff in plain latex, we'd lose the html docs (without a lot of
tweaking).  Both would lose the info docs, which IMO wouldn't be
terrible, but some people seem to like.

I asked for alternate ideas almost a year ago (I think it was
Jan), but after looking at various suggestions, we decided that
texinfo was still the best way to go.

*shrug*

> Oh, wait... I've got to learn yet another markup language (one which I am 
> unlikely to use in any other job/situation in my maoing lifetime), and 
> install a bunch of apps (still in progress, over an hour later?!) before 
> I can even start the [alleged] 2-5 hours of content 
> development/improvement.
>
> I guess what I'm really saying is, if we think the barrier-to-entry for 
> USERS is high, we've got another thing coming re: DEVELOPERS...  =\

As you can see on -devel, I've been trying to make the build
system easier (including only requiring texi2html (perl) and
lilypond-book to make the docs).  But that's *another* highly
non-trivial problem.

> p.s. Hopefully I'm more resilient than others who have come before me — 
> and subsequently dropped off the face of the interwebs, if Graham's "0 
> documentation developers" is accurate —

It's worse, since all of those documentation developers learned
enough texinfo to write docs.  They learned things, and then all
either "graduated" to being developers (which, in the long run, is
not a bad thing at all!), or drifted away, or are unable to work
for various perfectly valid reasons.


But really, if you find yourself wanting to do anything that isn't
already in the same place of that file... we should talk.  For the
benefit of unified presentation /and/ saving your sanity, I
strongly recommend that all you do is copy&paste and change text.
I don't mean @text; only change text that doesn't appear as a
@command.

Cheers,
- Graham


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

Re: Quit [now definitely O/T]

[Joe Neeman]

On Wed, 2009-11-11 at 22:33 +0100, David Kastrup wrote:
> Carl Sorensen  writes:
> > The code to establish a ritardando could be easily written, and may (or may
> > not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
> > Stabilization) project.  There's currently some disagreement about whether
> > it would be good to define
> >
> > spannerText = 
> > #(define-music-function (parser location span-text) (string?)
> >   #{
> >   \override TextSpanner #'(bound-details left text) = #$span-text
> >   #")
> >
> > which would allow above example to be coded much more easily in the input
> > file
> >
> > \spannerText "rit."
> > b1\startTextSpan
> > e,\stopTextSpan
> >
> > but would hide the underlying LilyPond functionality (the \override)
> > and make users less likely to learn how to do overrides that they may
> > need to do for their own challenging music.
> 
> What is wrong with
> b1\startSpan "rit."
> e,\stopSpan
> 

If proper semantics and MIDI are the eventual goal, you will probably
need something like \startRit and \stopRit instead. This suggests the
need for some C++ work, since Text_spanner_engraver currently only
allows one spanner at a time, so
b\startRit c\startSpan "foo" d\stopRit d\stopSpan
would act strangely if \startRit used TextSpanners internally.

Joe




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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Werner,


What's the problem here?


The problem is that I come to Lilypond with a skill set —  
specifically, many years of Java+Javascript+(X)HTML+XSL(T)+CSS+(La) 
TeX experience — which should be more than adequate for any modern  
documentation project involving a WWW component.


I want to help move Lilypond forward, and I'm told that documentation  
is the place to start.

Awesome! With apologies to Apple, "I've got an app for that!"

Oh, wait... I've got to learn yet another markup language (one which  
I am unlikely to use in any other job/situation in my maoing  
lifetime), and install a bunch of apps (still in progress, over an  
hour later?!) before I can even start the [alleged] 2-5 hours of  
content development/improvement.


I guess what I'm really saying is, if we think the barrier-to-entry  
for USERS is high, we've got another thing coming re: DEVELOPERS...  =\


Cheers,
Kieren.

p.s. Hopefully I'm more resilient than others who have come before me  
— and subsequently dropped off the face of the interwebs, if Graham's  
"0 documentation developers" is accurate — and I'll be able to get  
past these initial obstacles without losing [too much of] my goodwill  
steam.


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

Manually place a clef object?

[Peter Kaplan]

When a repeated section begins in one clef and ends in another (as in the Basso
Continuo part I'm working on), it would be nice to be able to add a "reminder"
clef at the end of the repeated section, to alert the player to return to the
original clef when the repeat sign is reached.  

This behavior is easy to implement when the repeated section comes at the end of
the score; a simple \clef tenor can be placed after the final note and the tenor
clef will appear between the final note and the end of the bar -- perfect.

However, when the repeated section does not come at the end of the score, this
same fix fails.  Lilypond instead looks to see if there are any notes following
the reminder clef, finds none, and omits the reminder clef when engraving.  Is
there an alternative way to manually place a clef object for use in such cases?

Snippet can be found at http://pefty.elementfx.com/audio/snippet.ly

 



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

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 9:33 PM, David Kastrup  wrote:
>> \spannerText "rit."
>> b1\startTextSpan
>> e,\stopTextSpan
>
> What is wrong with
> b1\startSpan "rit."
> e,\stopSpan
>
> ?  Why force meddling with an internal variable in the first place?  You
> need the text anyway, why not make it part of the macro?

To ward off yet more thread drift: that's already in the list of
things to consider as part of the Grand LilyPond Input Syntax
Stabilization.

GLISS will start whenever I have the time to organize it, which will
happened whenever GUB and the new website are done, which... well it
_might_ be done by Christmas, at the current rate of progress.

Cheers,
- Graham


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

Re: Quit [now definitely O/T]

[Werner LEMBERG]

>> @node Alternate input
> 
> I have to mao-ing learn TEXI now?

What's the problem here?  If you don't want to do nifty things it's
just a quite simple markup language.  And since there has already been
written a lot of TEXI documentation for lilypond I'm quite sure that
you find examples for almost all situations.


Werner


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

Re: Quit [now definitely O/T]

[David Kastrup]

Carl Sorensen  writes:

> David,
>
> Thanks for your willingness to articulate some concerns.  I think that
> your careful thinking can be of real help to the LilyPond community,
> expecially if you can help us make things better.

Thanks for putting up with me.

> On 11/11/09 7:21 AM, "David Kastrup"  wrote:
>
>> Lilypond is supposed to be a music typesetter.  Music in, glyph
>> placement out.  If I have to do the typesetting myself, placing
>> glyphs rather than specifying musical content, Lilypond is not doing
>> its job.
>
> This is absolutely true.  The objective *is* to make the music
> entirely tweak-free.  Unfortunately, we are not there yet.

Perhaps the snippets resource should contain snippets for _future_
versions along with the current snippets.

Not just "here is how you can do this" but also "here is how we wish one
could do this".  And possibly a list of "here are the pieces needed for
that".  Part of that might be better located in the issue tracker.

> The challenge is that there are two possible responses to a problem
> where LilyPond doesn't do the right thing:
>
> 1) File a bug report, and wait for somebody to get around to fixing it
> 2) Figure out a workaround, which will certainly seem hacky, but doesn't
> require waiting for a new LilyPond release.

You forgot

3) Work out a proper solution and contribute it.

And in open source software development, that is an option not to be
neglected, because in the end this is the _only_ thing anybody can do
that actually causes things to improve reliably.

> When option 2 is chosen, we also have the ability to add the hack to
> the LSR in order to save it for posterity and allow others to use it.
>
> Unfortunately, when option 2 is chosen, we also lose some of the
> pressure to fix the bug in the first place.  Since available
> development time is severely limited, we tend not to focus on things
> that have workarounds.

I have noticed that some of the LSR entries are revolting.  For example,
the diatonic accordion typesetting uses editor macros to
semi-automatically translate music into pseudo-music that happens to
place the tabulature dots in the right locations.

That's pretty absurd since that kind of translation belongs into Scheme.
The resulting source code is no longer transposable, the Midi has
nothing to do with the music, and so on.

This thing belongs in the LSR _only_ accompanied by a task description
of what one would rather be able to write.

It would be an _excellent_ way for _experienced_ programmers to tell
others "what do to eventually" to label ugly hacks as ugly hacks by
spelling out how a nice solution might look in the _source_.

> The code to establish a ritardando could be easily written, and may (or may
> not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
> Stabilization) project.  There's currently some disagreement about whether
> it would be good to define
>
> spannerText = 
> #(define-music-function (parser location span-text) (string?)
>   #{
>   \override TextSpanner #'(bound-details left text) = #$span-text
>   #")
>
> which would allow above example to be coded much more easily in the input
> file
>
> \spannerText "rit."
> b1\startTextSpan
> e,\stopTextSpan
>
> but would hide the underlying LilyPond functionality (the \override)
> and make users less likely to learn how to do overrides that they may
> need to do for their own challenging music.

What is wrong with
b1\startSpan "rit."
e,\stopSpan

?  Why force meddling with an internal variable in the first place?  You
need the text anyway, why not make it part of the macro?

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 04:05:59PM -0500, Kieren MacMillan wrote:
>> The first thing that comes to mind is Alternate input.
>> Documentation/general/introduction.texi
>> @node Alternate input
>
> I have to mao-ing learn TEXI now?
> So much for your "2-5 hours" estimate...

I stand by my "2-5 hours of editing texi", but I forgot to add
that this was "assuming the worker is familiar with git, texinfo,
etc".

> Still-doing-it-but-thinking-there's-almost-definitely-a-better-way,

In the case of that page... just look at Denemo and the current
Frescobaldi.

- Denemo shows you how the "top boxes" work.  Don't use any other
  formatting; just copy what's there, and change the text and
  links to images accordingly.
- the current Frescobaldi shows how the "bottom list" works... or
  at least, how I imagine it would work the best.  Make a note of
  how that format works (or maybe duplicate it once or twice),
  then make Frescobaldi into a thing like the current Denemo.  And
  move it higher on the page.

The idea behind the website is that it's just like the other docs;
once somebody is accustomed to working on the lilypond docs, they
can easily work on the html+pdf+info that is "general lilypond
information".  Besides, texinfo is easier than html.


Really, seriously.  Don't look at any texinfo tutorials or
manuals... I don't even recommend looking at the extensive
texinfo-related stuff in the Contributor Guide.  Just follow the
examples already in the file.

Cheers,
- Graham


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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Graham,


The first thing that comes to mind is Alternate input.
Documentation/general/introduction.texi
@node Alternate input


I have to mao-ing learn TEXI now?
So much for your "2-5 hours" estimate...

Still-doing-it-but-thinking-there's-almost-definitely-a-better-way,
Kieren.


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

Re: Quit

[Graham Percival]

On Wed, Nov 11, 2009 at 09:49:28PM +0100, David Kastrup wrote:
> Jan Nieuwenhuizen  writes:
> 
> > Also seen several times are people sending /lots/ of questions,
> > be it users or developers, and after everything has been
> > answered, the user quits or potential developers says she has no
> > time or does not thing she is up for it after all.
> 
> If the gist of the relevant answers are placed in the docs rather than
> put to rot in the list archives, the effort has not been wasted.

Given that we have 0 people working on the docs, I doubt that the
relevant answers are making their way into the docs.

> > While I do not have a final verdict on this, it seems safe to spend
> > most of our development efforts on developing.
> 
> There is a limit to how much development each of "us" can do.  There is
> no limit to how many persons "we" can be.

I entirely agree... but how many new persons have we had recently?

Let me put it another way: if *you're* not willing to step forward
and work out the baby steps towards being a "fully-fledged"
developer (and ideally write docs to help the next people
interested), then who else is going to do it?

Ok, maybe your desired task is too difficult... so pick a
different bug/feature to fix/implement, spend a few weeks learning
how to fix it, then submit docs to help other people reach that
level.


If you spend a month or two doing that, it would definitely help
the next person.  Then you could take a break for a month, and
that person could go through the frustration of figuring things
out, and hopefully write docs about the next stage.  Then maybe a
third person could learn from the docs that you both wrote, and go
even further.

Or, you know, we could just totally waste this discussion and
whine about the current state of affairs without doing anything to
fix it.

- Graham


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

Re: Quit [now definitely O/T]

[Carl Sorensen]

David,

Thanks for your willingness to articulate some concerns.  I think that your
careful thinking can be of real help to the LilyPond community, expecially
if you can help us make things better.


On 11/11/09 7:21 AM, "David Kastrup"  wrote:

> Kieren MacMillan  writes:
> 
>> Hi Craig (et al.),
>> 
>>> I must say that the "faster" thing is a typical United States
>>> behavior.
>> 
>> Whether or not it started in the USA, it's a worldwide phenomenon now.
>> =)
>> [Disclosure: I'm Canadian.]
> 
> It is too cheap to put this down to "faster".  The problem is not that
> you need longer to do some things with Lilypond initially.  The problem
> is that there is a large number of things for which there is no proper
> way to do them at all, and you have to take out the crowbar.
> 
> Lilypond is supposed to be a music typesetter.  Music in, glyph
> placement out.  If I have to do the typesetting myself, placing glyphs
> rather than specifying musical content, Lilypond is not doing its job.

This is absolutely true.  The objective *is* to make the music entirely
tweak-free.  Unfortunately, we are not there yet.

> And some Scheme/C++/whatever hackery for manually placing some glyphs
> one by one sure as heck is less convenient than just point and click.

Yes, that is true.  And we understand it.

The challenge is that there are two possible responses to a problem where
LilyPond doesn't do the right thing:

1) File a bug report, and wait for somebody to get around to fixing it
2) Figure out a workaround, which will certainly seem hacky, but doesn't
require waiting for a new LilyPond release.

When option 2 is chosen, we also have the ability to add the hack to the LSR
in order to save it for posterity and allow others to use it.

Unfortunately, when option 2 is chosen, we also lose some of the pressure to
fix the bug in the first place.  Since available development time is
severely limited, we tend not to focus on things that have workarounds.

> 
> The documentation for extending Lilypond is not working out well: the
> automatically generated lilypond-internals contains no useful examples
> or explanations, the concepts for the C++, Scheme and Lilypond data
> structures that one needs for internal programming are not explained
> anywhere visibly, it is not clear what one can or cannot hope to do in
> what layer and with what level of expertise.

I completely agree with you here.  Your frustration is reasonable.  Part of
it stems from a misunderstanding about the intent of lilypond-internals.  It
is *not* intended to be a tutorial.  It's strictly a reference (think
dictionary, not encyclopedia).  The information you're looking for would
ideally be in the Contributors' Guide or a yet-to-be-written LilyPond
Architecture  manual.

> 
> lilypond-extending does not contain examples for the various layers.
> There are no examples for how to work in Midi functionality.  As a
> side-effect of taking out the crowbar and doing visual arrangement of
> music content manually, of course the Midi output does not get any
> relevant info.

Lilypond-extending has not been reworked as part of the GDP (Grand
Documentation Project) which greatly improved the Notation Reference
chapters 1-4.  If you are having a hard time now, you should have tried it
before the GDP.  I have hopes that we'll eventually get Extending worked out
to an equivalent level, but "so much to do, so little time"...

Midi in LilyPond was implemented not as a way to really play the music as
written, but as a way to proof-hear the notes to make sure the notes were
right.  There is no core developer who has MIDI as their primary interest.
Peter Chubb did create articulate.ly to improve the MIDI output (many
thanks, Peter!), but that's hacking the input code, not the source code.  I
don't know of *anybody* who has the expertise and interest to do the MIDI
stuff.

> 
> Things like "ritardando" can't be found in the notation index and are
> programmed something like
> 
> Some performance indications, e.g., rallentando or accelerando, are
> written as text and are extended over multiple notes with dotted lines.
> Such objects, called "spanners", may be created from one note to
> another using the following syntax:
> 
>  \override TextSpanner #'(bound-details left text) = "rit."
>  b1\startTextSpan
>  e,\stopTextSpan

Yes, so we should add "ritardando" to the index.  A patch is within the
ability of any LilyPond user, and would be speedily applied.

The code to establish a ritardando could be easily written, and may (or may
not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
Stabilization) project.  There's currently some disagreement about whether
it would be good to define

spannerText = 
#(define-music-function (parser location span-text) (string?)
  #{
  \override TextSpanner #'(bound-details left text) = #$span-text
  #")

which would allow above example to be coded much more easily in the input
fil

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 03:53:11PM -0500, Kieren MacMillan wrote:
>> It does not tell you what language/classes/operations to use to  
>> implement what kind of task.
>
> OK, then submit a feature request — rant on -user does not count — and 
> maybe someone in the know will help out.

No, please don't.  We really don't need issues in the tracker like
"improve the learning manual", "improve the extending manual".  We
know that documentation is a never-ending job.  We especially know
that the advanced docs are weak.


Fun fact: right now, 14 months after the Grand Documentation
Project (wherein over 20 people worked on the docs), we have 0
people working on the documentation.  Many people have good
reasons for their absence (serious medical issues, dead computers
-- yes, multiple ones!, running the Frogs, etc).

But that doesn't change the sadness of "0 documentation writers".

Cheers,
- Graham


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

Re: Quit [now definitely O/T]

[David Kastrup]

Jonathan Kulp  writes:

> On Wed, Nov 11, 2009 at 2:01 PM, Kieren MacMillan <
> kieren_macmil...@sympatico.ca> wrote:
>
> Hi David (and anyone else who makes it here, wondering how to find the
> "CG"),
>
>
>
> The manuals don't tell anything about "CG", where it is, what it does.
> http://lilypond.org/web/devel/participating/> does not tell.
> There is no directory of that name in the distribution.
>
> At the risk of stating the obvious (to long-time lilypond contributors
> anyway), "CG" stands for "Contributor's Guide."

I wish more people would take that kind of risk, never mind how much of
a spoilsport that may make them.  I plead guilty to having noticed the
"contributor's guide" rather late into my rants.  But it does not
particularly help that the mailing list conversations avoid pronouncing
its full name like it were Youknowwho.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi David,


Where does the GDP document the meaning of the acronym "GDP"?


Here's one place (of many):
   


It does not say what kind of code to put where for what reason.





"Programming in LilyPond is done in a variety of programming  
languages. Each language is used for a specific purpose or purposes.  
This section describes the languages used and provides links to  
reference manuals and tutorials for the relevant language. […] The  
core functionality of LilyPond is implemented in C++. The C++ code  
calls Scheme/GUILE through the GUILE interface […] The LilyPond  
parser is implemented in Bison, a GNU parser generator. […] GUILE is  
the dialect of Scheme that is used as LilyPond’s extension language.  
Many extensions to LilyPond are written entirely in GUILE."

etc.

It does not tell you what language/classes/operations to use to  
implement what kind of task.


OK, then submit a feature request — rant on -user does not count —  
and maybe someone in the know will help out.
I wish I could help out, but I don't know enough about Lilypond to  
write (or even start writing) such a page.


Good luck,
Kieren.

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

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 03:19:37PM -0500, Kieren MacMillan wrote:
> Hi Graham,
>
>> - 2-5 hours of texinfo file editing
>
> I just pulled a new origin/master from git.
> Today, I've got upwards of 3 hours to code: what do you want me to work 
> on?

The first thing that comes to mind is Alternate input.
Documentation/general/introduction.texi
@node Alternate input

I'm thinking of having 4 main boxes at the top:
- denemo
- lilypondtool
- frescobaldi
- emacs+vim

then one box with all the others.  Probably with only a 1 or
2-sentence descrition, and no pictures.  Alternately, maybe have
two other boxes: 1 for "moderately recommended" (i.e. a list, but
still pictures), and another for "not really recommended (i.e. a
list with no pictures).

Pictures and descriptions from the project websites are ok as far
as I'm concerned.  I suppose that *technically* even a
one-sentence project description is still under copyright, so
*technically* you shoudl ask the project if you can use it.  But I
think that's getting ridiculous.

Pictures (screenshots or not) go in Documentation/pictures/.
You'll need to delete the out/ and/or out-www/ in that dir and do
another "make doc" to regenerate them; a simple "make doc" again
won't regenerate those new images.  (another joyous build system
issue)


Now for the disclaimers:
- if you're willing to be responsible for this page, then feel
  free to toss out anything in the above description (other than
  the technical build system stuff).  Organize the page however
  you maoing feel like it.
- as far as I'm concerned, do the minimum amount -- just format
  the bottom list(s) nicely.  Don't bother looking up project
  webpages to see if Denemo supports windows or anything lile
  that; if we get stuff wrong, somebody will complain eventually.

As a disclaimer to the second disclaimer, somebody posted on
bug-lilypond earlier today with a bunch of info that this page
could contain, including news that denemo works on windows.  So it
might be polite to fix that thing, at least... but I maintain that
it's probably not worth researching any editor.



More generally, find any @help  in the new website.  They're
really ugly flsahing green and red.  Somebody already offered to
look at the Features page, although having more people looking at
it can't be bad.  One or two of the @help are directed at build
system people (which seems to be me now).  But most of them can be
done -- at leats, done in a quick "band-aid" manner -- by just
editing the .texi files.

Cheers,
- Graham


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

Re: Quit

[David Kastrup]

Jan Nieuwenhuizen  writes:

> Also seen several times are people sending /lots/ of questions,
> be it users or developers, and after everything has been
> answered, the user quits or potential developers says she has no
> time or does not thing she is up for it after all.

If the gist of the relevant answers are placed in the docs rather than
put to rot in the list archives, the effort has not been wasted.  If
another one independently decides to pick up the lost ball at a later
point of time, he does not need to start from scratch.

> While I do not have a final verdict on this, it seems safe to spend
> most of our development efforts on developing.

There is a limit to how much development each of "us" can do.  There is
no limit to how many persons "we" can be.

> You need to be pretty good to add something to LilyPond and I doubt if
> developer documentation/hand-holding is going to make that any easier.

It is less distracting to other developers if the likes of me don't blow
their top every minute.

> Apparently, making this Reasonable is something you consider
> to be important.  The thing to do here would be to pick up
> that task -- if it's important enough for you.  It is next
> to impossible to get people to do what you want by merely
> stating that it is important.

I can't that task before having a clue.  I can coax code to do what I
want it to do eventually.  But I can't coax code into doing things like
they were _intended_ to be done.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[Carl Sorensen]

On 11/11/09 12:12 PM, "Graham Percival"  wrote:

> On Wed, Nov 11, 2009 at 06:11:26PM +0100, David Kastrup wrote:
> 
>> But if there is roadmap, design and vision, I have not yet been able to
>> find it in the obvious places I have been looking for.
> 
> The information for developers is the CG.  I have a rough roadmap
> and vision in my head (assuming those terms mean "plan for the
> future"), but completely lack the developers to implement it.  So
> there's no point writing it down.

OOPS -- Graham, you forgot that we agreed that we wouldn't use abbreviations
on -user.

David, CG is the Contributors' Guide, and it's part of the 2.13 docs.  It
tries to get at the issues you're concerned about.

Thanks,

Carl



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

Re: Quit [now definitely O/T]

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
> [By the way, since it's apparently open season on posting style
> criticism: your consistent lack of salutation and valediction in your
> posts makes you seem rude, curt, and above all patronizing.]

Perfectly accurate.

>> "Reasonable" entails a collective effort not to repeat avoidable work
>> and frustration.
>
> e.g., the GDP and the 000s of hours Graham P personally has put in to
> improving the docs...?

Where does the GDP document the meaning of the acronym "GDP"?

>> presumably _is_ something like coding style
>
> c.f. 
> 
> What needs to be added/improved? Once again, I'm sincerely asking,
> since you obviously still have questions about Lilypond coding style
> that weren't answered by that page (and surrounding ones).

Uh, have you read it?  It worries about things like indentation, says to
prefer C++ over Python (but Python please in "PEP 8" whatever that fancy
acronym is supposed to be), and some identifier names.  It does not say
what kind of code to put where for what reason.

That is: it tells you minor details about how source should be formatted
once you know perfectly what you are doing and which part of the code is
appropriate to use.  Namely it tells you about the difference between
something that compiles and fits in with the rest of the _code_.  It
does not tell you what language/classes/operations to use to implement
what kind of task.

>> or idea behind Lilypond
>
> c.f.
>   
> 

I have found the contributor's guide by now (not mentioned in the web
resources AFAICS).  It gives some sort of outline, but lacks examples
that walk the prospective programmer through the skeleton of what he
needs to do.

>   
> Same question as above.

The thesis is a thesis.  It is unclear what state of Lilypond it
documents, and what the current state of Lilypond embeds from what is in
the thesis.

And some thesis on the web is not a good substitute for programming
docs.  Because it does not evolve with the program.
>
>> The internals documentation should likely spell out the layers of C+
>> +, Scheme, Music macros and what one can hope to reasonably implement
>> in what layer.  What new functionality requires equivalence of new
>> engravers or performers, can one implement them in Scheme, does one
>> need C++, and what exactly does one _do_ when creating them?
>
> The introductory page
> 
> does spell this out, I believe.

I don't see this.  Mostly, it points to sources for reference.  That's
useful to some degree.  But if people write sources with only sources
for reference, any design inherent in the first generation of the
sources is going to become less and less discernible with successive
layers of code.

More educational than studying how existing code is written would be to
study how the code is _supposed_ to be written.  Some self-contained
example with well-defined functionality that sits well in the scheme of
things.  If people can't make their own code as simple and
self-contained (or see existing "real" code much uglier), that is an
incentive for improving the state of their and preexisting "real" code.

-- 
David Kastrup



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

Re: upgrading

[James E. Bailey]

On 11.11.2009, at 12:13, Gerard McConnell wrote:


Hi, Perhaps a stupid question -  is there any reason NOT to
upgrade from 2.12.x  to 2.13.7?
Thanks,
Gerard



I tend to work from the "if it ain't broke, don't fix it" principle.  
So, unless there's something fundamentally broken that you absolutely  
cannot work without (like custom key signatures) that's fixed in 2.13  
and not in 2.12, I would wait.


James E. Bailey



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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi Graham,


the "more available/obvious" choice would be
to make the new website the main one.

Currently, that's waiting on:
- 2-5 hours of texinfo file editing


I just pulled a new origin/master from git.
Today, I've got upwards of 3 hours to code: what do you want me to  
work on?


Cheers,
Kieren.


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

Re: Quit [now definitely O/T]

[Jonathan Kulp]

On Wed, Nov 11, 2009 at 2:01 PM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi David (and anyone else who makes it here, wondering how to find the
> "CG"),
>
>
>  The manuals don't tell anything about "CG", where it is, what it does.
>> http://lilypond.org/web/devel/participating/> does not tell.
>> There is no directory of that name in the distribution.
>>
>
>
Hi all,

At the risk of stating the obvious (to long-time lilypond contributors
anyway), "CG" stands for "Contributor's Guide."

Jon

p.s. to Graham and anyone else who was wondering: my wrists still aren't
really better after months. I'm going to a specialist next week. I hope to
be a productive LP community member again one day...
-- 
Jonathan Kulp
http://www.jonathankulp.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 03:01:33PM -0500, Kieren MacMillan wrote:
> Step 3: Click on "Documentation for LilyPond 2.13 (latest development)" 
> [since you're going to be helping with development, this is the logical 
> choice].
>   Location: 

>> Not the general manuals, not the web page, not in the FAQ,
>> not in the learning manual, not even in the Wiki AFAICS.
>> [...] Where or what is "the CG"?
>
> What else could have been done to make the CG more available/obvious?

In David's defense (not that I _want_ to be doing this), the "more
available/obvious" choice would be to make the new website the
main one.

Currently, that's waiting on:
- 2-5 hours of texinfo file editing.
- 5-15 hours of technical build system + server work
- *maybe* a few weeks of time for the translators to catch up,
  although at the moment I'm not feeling patient.

I'm not asking anybody else to touch the build system or the web
server.  But I'm not going to make those a priority until the
.texi file editing is done.

Cheers,
- Graham


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

Re: Quit

[Jan Nieuwenhuizen]

Op woensdag 11-11-2009 om 20:08 uur [tijdzone +0100], schreef David
Kastrup:

> > As we both (all) know, there IS a "reasonable way to become an expert"
> > at Lilypond
> 
> No.  A _reasonable_ way to become an expert is by reading into
> increasingly more expert-level documentation and working with it.
> 
> "Humanly possible" is not the same as "reasonable".  "Reasonable"
> entails a collective effort not to repeat avoidable work and
> frustration.

Being able to maintain this pov "would be nice".  However, how do
you suggest we get there?  It may well be that you are helping
with the first steps right now: identification of the problem.
The thing with open source/ LilyPond is: someone needs to follow
up and do the work to get from Humanly possible to Reasonable.
Until now, that has not been done yet.  And my question would be:
is it worth it?

Several times we have seen people sending perfect patches or code
right out of the blue, without asking any questions.  Simon
Tatham with his Gonville font being the latest instance I
remember.  This falls in the category of Humanly possible.
Possibly harsh and not enough for some potential contributors.  The
good thing is: it did not cost us any resources.

Also seen several times are people sending /lots/ of questions,
be it users or developers, and after everything has been
answered, the user quits or potential developers says she has no
time or does not thing she is up for it after all.

While I do not have a final verdict on this, it seems safe to
spend most of our development efforts on developing.  You need
to be pretty good to add something to LilyPond and I doubt if
developer documentation/hand-holding is going to make that any 
easier.

> I can't improve what I can't see or understand.

Can you change what you see and then look what happened?

> The topic was why people find Lilypond too cumbersome to use.  I gave
> reasons, and the reaction "please change it yourself" is not addressing
> the topic at all.  It also delivers the impression that the current
> state is basically my fault and responsibility, and nothing needs to be
> done about it that I don't do myself.

Apparently, making this Reasonable is something you consider
to be important.  The thing to do here would be to pick up
that task -- if it's important enough for you.  It is next
to impossible to get people to do what you want by merely
stating that it is important.

Several months ago I tried to coax people to help with the
website and look into SEO ["Do we have the best search terms that
will bring new users/developers in?"].  I argued that most of our
potential users/developers by far (>99%) never heard of LilyPond
yet and I figured that good findability/visibility and
attractiveness of the website were probably of utmost importance.
Well, have you read some of Graham's cries for help?  Noone cares.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen  | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl| http://lilypond.org



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

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 08:47:33PM +0100, David Kastrup wrote:
> 
> Graham Percival  writes:
> 
> > The information for developers is the CG.
> 
> The manuals don't tell anything about "CG", where it is, what it does.
> http://lilypond.org/web/devel/participating/> does not tell.  There
> is no directory of that name in the distribution.

In case you've been living under a rock, there's a new website
that's almost ready.
http://lilypond.org/doc/v2.13/Documentation/
in particular, see
http://lilypond.org/doc/v2.13/Documentation/development

would it be nice if this new website was _ready_, and not "almost
ready"?  Definitely.

> > I have a rough roadmap and vision in my head (assuming those terms
> > mean "plan for the future"), but completely lack the developers to
> > implement it.  So there's no point writing it down.
> 
> Wrong, because it means that nobody can work in the right direction even
> if he wanted to.  If you write "at one point of time, we want the
> following code to work:", that gives people a goal to work towards.

Ok.  Start with "no high-priority or regression-priority bugs".

> You waste the low-level contributors in that manner, adding to your
> resource shortage.

The waste in my high-level contributions far outweighs the waste
of low-level contributors.

> Where or what is "the CG"?  Where do the Frogs train their new
> generation of developers?
> 
> Why aren't they mentioned on
> http://lilypond.org/web/devel/participating/>?

Again, new website.  Yes, I'll fill in the "help wanted" section
if and when the new website is almost ready.

Since almost nothing has happened in the past two months, I'm not
holding my breath.  I've been working on getting development
packages out there... including having it working on OSX 10.6.
Is that more or less important than the new website?  I don't
know.  I decided it was, but I really have no evidence to support
my decision to abandon the website in favor of that work.

*shrug*  maybe that was a mistake.  But it was _my_ mistake to
make, since it was my time stake.  (rhyme unintentional)

- Graham


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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi David (and anyone else who makes it here, wondering how to find  
the "CG"),



The manuals don't tell anything about "CG", where it is, what it does.
http://lilypond.org/web/devel/participating/> does not tell.
There is no directory of that name in the distribution.


Step 1: Go to home page.
  Location: 

Step 2: Click on "Documentation".
  Location: 

Step 3: Click on "Documentation for LilyPond 2.13 (latest  
development)" [since you're going to be helping with development,  
this is the logical choice].

  Location: 

Step 4: Click on either "Manuals" or "Community".
  Location: either  or 


Step 5: Click on "Development"
  


Not the general manuals, not the web page, not in the FAQ,
not in the learning manual, not even in the Wiki AFAICS.
[...] Where or what is "the CG"?


What else could have been done to make the CG more available/obvious?

Regards,
Kieren.


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

Re: Quit [now definitely O/T]

[David Kastrup]

Graham Percival  writes:

> On Wed, Nov 11, 2009 at 06:11:26PM +0100, David Kastrup wrote:
>
>> But if there is roadmap, design and vision, I have not yet been able
>> to find it in the obvious places I have been looking for.
>
> The information for developers is the CG.

The manuals don't tell anything about "CG", where it is, what it does.
http://lilypond.org/web/devel/participating/> does not tell.  There
is no directory of that name in the distribution.

> I have a rough roadmap and vision in my head (assuming those terms
> mean "plan for the future"), but completely lack the developers to
> implement it.  So there's no point writing it down.

Wrong, because it means that nobody can work in the right direction even
if he wanted to.  If you write "at one point of time, we want the
following code to work:", that gives people a goal to work towards.
Beginning contributors can massage code until it achieves a certain
thing.  But they can't figure out what is a good idea and what not, and
what fits into the general scheme of Lilypond, and what not.

You waste the low-level contributors in that manner, adding to your
resource shortage.

> As for the CG... would you prefer it if Carl stopped answering
> your emails, and wrote stuff for the CG instead?  Would you prefer
> it if we kidnapped Carl, strapped him to a wooden board, and
> whipped him until he wrote more CG *and* still answered emails?

I can make no educated guess, since I don't know what the CG is.  It is
likely that I should be called names for that, but I don't see any
obvious source of information explaining it.  Not the general manuals,
not the web page, not in the FAQ, not in the learning manual, not even
in the Wiki AFAICS.

> We can't demand any more work than what people are willing to do.  I
> think we should *thank* the past/present developers for the work they
> did/are doing, not demand that they work more.

Tell that to Killian.

> I've done everything I can to create the organizational
> infrastructure.  We have the Extending manual for how to program
> lilypond.  We have the CG for how to interact with git + the developer
> community.  We have the Frogs to train a new generation of developers.

Where or what is "the CG"?  Where do the Frogs train their new
generation of developers?

Why aren't they mentioned on
http://lilypond.org/web/devel/participating/>?

> Other than kidnap + torture, of course.  I might vote for this, but it
> strikes me that it might cause long-term problems... I mean, who'd
> want to become a lilypond developer if they knew that _they_ might be
> subjected to waterboarding in 5-10 years?

My impression is that the waterboarding starts right away.  Of course,
the answers will not prove very high quality.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi David,

[By the way, since it's apparently open season on posting style  
criticism: your consistent lack of salutation and valediction in your  
posts makes you seem rude, curt, and above all patronizing.]


"Reasonable" entails a collective effort not to repeat avoidable  
work and frustration.


e.g., the GDP and the 000s of hours Graham P personally has put in to  
improving the docs...?



presumably _is_ something like coding style


c.f. 
What needs to be added/improved? Once again, I'm sincerely asking,  
since you obviously still have questions about Lilypond coding style  
that weren't answered by that page (and surrounding ones).



or idea behind Lilypond


c.f.
  

  
Same question as above.

The internals documentation should likely spell out the layers of C+ 
+, Scheme, Music

macros and what one can hope to reasonably implement in what layer.
What new functionality requires equivalence of new
engravers or performers, can one implement them in Scheme, does one  
need

C++, and what exactly does one _do_ when creating them?


The introductory page
  

does spell this out, I believe.

Cheers,
Kieren.


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

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 07:12:44PM +, Graham Percival wrote:
> Other than kidnap + torture, of course.  I might vote for this,
> but it strikes me that it might cause long-term problems...

Addendum: I don't know the details that you want, so torturing me
won't help.

I'd *like* to know those details.  I'd *like* to be working on the
collisions, defects, and making a dent in the 300+ known issues.
But recently I've been spending all my time on the basic
infrastructure (like GUB).

Why do I think I'm so shrill about finding people to do grunt work
on the new website?  Because we don't need me to edit bloody .texi
files.  People in GDP did that after 1 hour of reading the CG.  If
we had more people taking over the mundane easy jobs, that would
give me more time to investigate the medium iffy jobs.  And after
a few weeks of those mundane easy jobs, the helpers could tackle
the medium iffy jobs, and I could do the horrendously complicated
jobs.  I would *love* to do things like making lilypond take
advantage of multiple CPUs!

Or, you know, I could keep on plugging away at the easy jobs, and
everything else can be dumped in the issue tracker to be ignored
for years.

- Graham


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

Re: Quit [now definitely O/T]

[Graham Percival]

On Wed, Nov 11, 2009 at 06:11:26PM +0100, David Kastrup wrote:
> 
> Kieren MacMillan  writes:
> 
> > I couldn't agree more! [See Steps 1&2, above.]
> 
> I think that sums up very well why somebody would prefer not working
> with Lilypond.  Not only do you have to rely on expert advice, but the
> main advice is "please do what an expert would do, or shut up".

That's not quite it -- we're saying "lilypond is open source;
please help".  With varying degrees of politeness, depending on
how polite the original complaint was.

What else *can* we say?  We don't have the amount of developers
that people think we have.  For most issues, all we can do is add
it to the tracker and hope that somebody works on it sometime.  I
know that's not a very encouraging answer, but it's the only
honest one I can give.

> Now I am in the situation of being an expert _programmer_.  If you had
> actually bothered taking a look at recent postings of mine, you would
> have noticed that I am trying to get some functionality into Lilypond.
> There is little enough useful information to go by, there is very little
> advice on the list (Carl was the only one to give any pointers to
> repetitive requests for advice or reviews), there is no "big picture"
> you get for how to work which functionality in where.

Carl is in charge of the Frogs, which is the "developer training /
mentoring" project.  Of course he should answer.

Would it be nice if more in-training developers joined the
discussion?  Well, yes.  But they probably feel shy because they
aren't really certain about the topic at hand.

*shrug*  again, what else can we do?  Unless we kidnap Han-Wen and
force him to answer questions at gunpoint -- which, quite apart
from the legal and ethical considerations, is just plain *rude*[1]
-- there is *nothing* else we can do.

[1] can you tell I'm a Canadian?  :)


> But if there is roadmap, design and vision, I have not yet been able to
> find it in the obvious places I have been looking for.

The information for developers is the CG.  I have a rough roadmap
and vision in my head (assuming those terms mean "plan for the
future"), but completely lack the developers to implement it.  So
there's no point writing it down.

As for the CG... would you prefer it if Carl stopped answering
your emails, and wrote stuff for the CG instead?  Would you prefer
it if we kidnapped Carl, strapped him to a wooden board, and
whipped him until he wrote more CG *and* still answered emails?


We can't demand any more work than what people are willing to do.
I think we should *thank* the past/present developers for the work
they did/are doing, not demand that they work more.

I've done everything I can to create the organizational
infrastructure.  We have the Extending manual for how to program
lilypond.  We have the CG for how to interact with git + the
developer community.  We have the Frogs to train a new generation
of developers.

Are any of those items as complete, or working as well, as I had
hoped?  No.  But what else can I do?  I really can't think of
_anything_ else.

Other than kidnap + torture, of course.  I might vote for this,
but it strikes me that it might cause long-term problems... I
mean, who'd want to become a lilypond developer if they knew that
_they_ might be subjected to waterboarding in 5-10 years?

- Graham


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

Re: Quit [now definitely O/T]

[David Kastrup]

Sorry for the post in triplicate.  Gmane's response time confused me.

Kieren MacMillan  writes:

> Hi David,
>
>> I think that sums up very well why somebody would prefer not working
>> with Lilypond.  Not only do you have to rely on expert advice, but the
>> main advice is "please do what an expert would do, or shut up".
>
> Please show me where I said anything resembling "shut up"...?

Well, I omitted the other option "or whine on".  My fault.

More pointedly: for every question I asked, you basically replied: could
you please answer this question yourself and contribute the answer?  And
that, while a popular way to stifle contributions, is not a reasonable
expectation.  The first stumbling steps don't teach you what the best
way to walk is, and how to teach others to walk.

>> If there is no reasonable way to become an expert
>
> As we both (all) know, there IS a "reasonable way to become an expert"
> at Lilypond

No.  A _reasonable_ way to become an expert is by reading into
increasingly more expert-level documentation and working with it.

"Humanly possible" is not the same as "reasonable".  "Reasonable"
entails a collective effort not to repeat avoidable work and
frustration.

>> Now I am in the situation of being an expert _programmer_.  If you
>> had actually bothered taking a look at recent postings of mine, you
>> would have noticed that I am trying to get some functionality into
>> Lilypond.
>
> I *have* "actually bothered taking a look at recent postings" of yours
> — in fact, I thoroughly read almost every post on this list.  Hence, I
> had noticed that you are contributing, and was therefore wondering
> aloud if you would be adding more functionality to solve the
> problem(s) you were highlighting — specifically, I wondered if you
> were able [technically] to do so,

I am able to create functionality.  I am not able to guess what the
Lilypond way of adding this functionality would be.  I don't like doing
work that does not benefit others.  I don't like incoherent interfaces
and bad code.  I don't see how I can avoid doing those.

I am not interested into prodding Lilypond to accidentally produce
output that matches what I need.  I want Lilypond to understand
straightforward instructions in its Lilypond way to get the output I
want.  For that I need to understand the Lilypond way of doing this, and
the available information is not sufficient.  "Please create this
information" does not make sense, since there presumably _is_ something
like coding style or idea behind Lilypond, and guessing from code is
unreliable.

> and might be doing so in the near future: “Any chance you can/will
> improve it?”

I can't improve what I can't see or understand.

>> if there is roadmap, design and vision, I have not yet been able to
>> find it in the obvious places I have been looking for.
>
> Then I think that needs to be fixed — suggestions on where in the
> documentation this roadmap/design/vision should be?

The internals documentation should likely spell out the layers of C++,
Scheme, Music macros and what one can hope to reasonably implement in
what layer.  What new functionality requires equivalence of new
engravers or performers, can one implement them in Scheme, does one need
C++, and what exactly does one _do_ when creating them?

The extending documentation should point people to what kind of stuff
they need to consider for adding things like chords, lyrics, general
bass, tabs and so on themselves: what layers need to be meddling with
for what task, what will work only with recompilation, what might work
with Scheme code.  Give a sketch of the layout of some existing
functionality in Lilypond, and what one would need to add it if it did
not exist.

>> I don't see that anything is gained for chastising me for my
>> impression.
>
> Once again, I ask you to please point out exactly (with quotations)
> where I “chastised” you... since I clearly didn't intend to, I want to
> know how to avoid having my intentions misinterpreted in the future.

If a posting does not contain anything except "please contribute this
yourself", it is not likely to cause anything but annoyance.

The topic was why people find Lilypond too cumbersome to use.  I gave
reasons, and the reaction "please change it yourself" is not addressing
the topic at all.  It also delivers the impression that the current
state is basically my fault and responsibility, and nothing needs to be
done about it that I don't do myself.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi David,


I think that sums up very well why somebody would prefer not working
with Lilypond.  Not only do you have to rely on expert advice, but the
main advice is "please do what an expert would do, or shut up".


Please show me where I said anything resembling "shut up"...?
I'm sorry if you inferred something like that, but I certainly  
neither meant it nor [in my opinion] implied it — and I *certainly*  
didn't explicitly type anything of the sort.



If there is no reasonable way to become an expert


As we both (all) know, there IS a "reasonable way to become an  
expert" at Lilypond — it just may take more effort than with a point- 
and-click interface like Fin/Sib, and that (unfortunately) may be too  
much to ask of many people/users.


Naturally, I wish that the barrier-to-entry were lower.
And, like others, I am making material efforts to lower that barrier  
all the time.



Now I am in the situation of being an expert _programmer_.  If you had
actually bothered taking a look at recent postings of mine, you would
have noticed that I am trying to get some functionality into Lilypond.


I *have* "actually bothered taking a look at recent postings" of  
yours — in fact, I thoroughly read almost every post on this list.  
Hence, I had noticed that you are contributing, and was therefore  
wondering aloud if you would be adding more functionality to solve  
the problem(s) you were highlighting — specifically, I wondered if  
you were able [technically] to do so, and might be doing so in the  
near future: “Any chance you can/will improve it?”



if there is roadmap, design and vision, I have not yet been able
to find it in the obvious places I have been looking for.


Then I think that needs to be fixed — suggestions on where in the  
documentation this roadmap/design/vision should be?


I don't see that anything is gained for chastising me for my  
impression.


Once again, I ask you to please point out exactly (with quotations)  
where I “chastised” you... since I clearly didn't intend to, I want  
to know how to avoid having my intentions misinterpreted in the future.


Cheers,
Kieren.

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

Re: A barline half length long

[Robin Bannister]

Jiri Zurek wrote: 
What is wrong with my syntax, please? 


ly:bar-line::calc-bar-size needs a parameter.  

If you get used to writing things like 

   \override Staff.BarLine #'bar-size = #ly:bar-line::calc-bar-size
you think that is all you ever need to say. 
But the functions for grob properties like #'bar-size all need to be 
told which grob to work with; this is done here implicitly.  

To use this function anywhere else you have to say 

   (ly:bar-line::calc-bar-size grob)
i.e. you have to explicitly give it a grob as a parameter. 

The function you are making should in turn 
be written to expect a grob as a parameter 
and it is this info that you can relay to the default function. 

\override Staff.BarLine #'bar-size = 
  #(lambda (grob) (* (ly:bar-line::calc-bar-size grob) 0.5))



Cheers,
Robin


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

Re: Quit [now definitely O/T]

[David Kastrup]

> I'm not topposting

Third attempt because of topposting automoderation -- this _is_ a
nuisance.

Kieren MacMillan  writes:

[...]

I don't see the "now definitely O/T" you put in the subject line.  The
subject was that somebody quit, and we are talking about the reasons.

[...]

>> It is too cheap to put this down to "faster".  The problem is not
>> that you need longer to do some things with Lilypond initially.  The
>> problem is that there is a large number of things for which there is
>> no proper way to do them at all, and you have to take out the
>> crowbar.
>
> As is also true with Finale/Sibelius/etc.

If I have to wield a crowbar rather than _saying_ what I want, I prefer
at least seeing where I hit.  WYSIWYG.

[...]

> Any chance you can/will improve it?

[...]

> if it matters to you or others, by all means make it better!

[...]

> Patch?

[...]

> 1. Define a music function to do this.
> 2. Submit a patch.

[...]

> I couldn't agree more! [See Steps 1&2, above.]

I think that sums up very well why somebody would prefer not working
with Lilypond.  Not only do you have to rely on expert advice, but the
main advice is "please do what an expert would do, or shut up".

If there is no reasonable way to become an expert, this is equivalent to
"Lilypond is not for you.  Go away."  Which is what the original poster
did.

Now I am in the situation of being an expert _programmer_.  If you had
actually bothered taking a look at recent postings of mine on the
developer list, you would have noticed that I am trying to get some
functionality into Lilypond.  There is little enough useful information
to go by, there is very little advice on the list (Carl was the only one
to give any pointers given repetitive requests for advice or reviews),
there is no "big picture" you get for how to work which functionality in
where.

The problem is that this state does not just turn away prospective
users, it also turns away prospective _programmers_ who could help
moving Lilypond further on its roadmap, according to its design and
vision.

But if there is roadmap, design and vision, I have not yet been able to
find it in the obvious places I have been looking for.

And that means that not only do I have to do all the coding for my task,
I also have to invent interfaces which may be completely inconsistent
with what other people with special instruments do.  And I don't _want_
to have my code just remain in the state of some ad-hoc snippet.  I want
it to become part of Lilypond proper so that the next person will not
have to start at the same point again.

For me, this situation is awkward, impeding and dissatisfactory.  For
others, it is reason to go away.  I don't see that anything is gained
for chastising me for my impression.  That is merely shooting the
messenger.  Actually, more than the messenger.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[David Kastrup]

Kieren MacMillan  writes:

[...]

I don't see the "now definitely O/T" you put in the subject line.  The
subject was that somebody quit, and we are talking about the reasons.

[...]

>> It is too cheap to put this down to "faster".  The problem is not
>> that you need longer to do some things with Lilypond initially.  The
>> problem is that there is a large number of things for which there is
>> no proper way to do them at all, and you have to take out the
>> crowbar.
>
> As is also true with Finale/Sibelius/etc.

If I have to wield a crowbar rather than _saying_ what I want, I prefer
at least seeing where I hit.  WYSIWYG.

[...]

> Any chance you can/will improve it?

[...]

> if it matters to you or others, by all means make it better!

[...]

> Patch?

[...]

> 1. Define a music function to do this.
> 2. Submit a patch.

[...]

> I couldn't agree more! [See Steps 1&2, above.]

I think that sums up very well why somebody would prefer not working
with Lilypond.  Not only do you have to rely on expert advice, but the
main advice is "please do what an expert would do, or shut up".

If there is no reasonable way to become an expert, this is equivalent to
"Lilypond is not for you.  Go away."  Which is what the original poster
did.

Now I am in the situation of being an expert _programmer_.  If you had
actually bothered taking a look at recent postings of mine on the
developer list, you would have noticed that I am trying to get some
functionality into Lilypond.  There is little enough useful information
to go by, there is very little advice on the list (Carl was the only one
to give any pointers given repetitive requests for advice or reviews),
there is no "big picture" you get for how to work which functionality in
where.

The problem is that this state does not just turn away prospective
users, it also turns away prospective _programmers_ who could help
moving Lilypond further on its roadmap, according to its design and
vision.

But if there is roadmap, design and vision, I have not yet been able to
find it in the obvious places I have been looking for.

And that means that not only do I have to do all the coding for my task,
I also have to invent interfaces which may be completely inconsistent
with what other people with special instruments do.  And I don't _want_
to have my code just remain in the state of some ad-hoc snippet.  I want
it to become part of Lilypond proper so that the next person will not
have to start at the same point again.

For me, this situation is awkward, impeding and dissatisfactory.  For
others, it is reason to go away.  I don't see that anything is gained
for chastising me for my impression.  That is merely shooting the
messenger.  Actually, more than the messenger.

-- 
David Kastrup



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

Re: Quit [now definitely O/T]

[David Kastrup]

I don't see the "now definitely O/T" you put in the subject line.  The
subject was that somebody quit, and we are talking about the reasons.

Kieren MacMillan  writes:

>> It is too cheap to put this down to "faster".  The problem is not
>> that you need longer to do some things with Lilypond initially.  The
>> problem is that there is a large number of things for which there is
>> no proper way to do them at all, and you have to take out the
>> crowbar.
>
> As is also true with Finale/Sibelius/etc.

If I have to wield a crowbar rather than _saying_ what I want, I prefer
at least seeing where I hit.  WYSIWYG.

[...]

> Any chance you can/will improve it?

[...]

> if it matters to you or others, by all means make it better!

[...]

> Patch?

[...]

> 1. Define a music function to do this.
> 2. Submit a patch.

[...]

> I couldn't agree more! [See Steps 1&2, above.]

I think that sums up very well why somebody would prefer not working
with Lilypond.  Not only do you have to rely on expert advice, but the
main advice is "please do what an expert would do, or shut up".

If there is no reasonable way to become an expert, this is equivalent to
"Lilypond is not for you.  Go away."  Which is what the original poster
did.

Now I am in the situation of being an expert _programmer_.  If you had
actually bothered taking a look at recent postings of mine, you would
have noticed that I am trying to get some functionality into Lilypond.
There is little enough useful information to go by, there is very little
advice on the list (Carl was the only one to give any pointers to
repetitive requests for advice or reviews), there is no "big picture"
you get for how to work which functionality in where.

The problem is that this state does not just turn away prospective
users, it also turns away prospective _programmers_ who could help
moving Lilypond further on its roadmap, according to its design and
vision.

But if there is roadmap, design and vision, I have not yet been able to
find it in the obvious places I have been looking for.

And that means that not only do I have to do all the coding for my task,
I also have to invent interfaces which may be completely inconsistent
with what other people with special instruments do.  And I don't _want_
to have my code just remain in the state of some ad-hoc snippet.  I want
it to become part of Lilypond proper.

For me, this situation is awkward, impeding and dissatisfactory.  For
others, it is reason to go away.  I don't see that anything is gained
for chastising me for my impression.  That is merely shooting the
messenger.  Actually, more than the messenger.

-- 
David Kastrup



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

Re: A barline half length long

[David Kastrup]

"Jiri Zurek (Prague)"  writes:

> \once \override Staff.BarLine #'bar-size = #(* ly:bar-line::calc-bar-size
> 0.5) \bar "|"

Try something like

  \once \override Staff.BarLine #'bar-size = #(lambda(x) (* 0.5 
(ly:bar-line::calc-bar-size x))) \bar "|"

It is probably possible to fabricate something with
ly:make-simple-closure, but it escapes me at the moment.

-- 
David Kastrup



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

Re: series of up'n'down bows: /\\//\\/

[user28]

ok. cool.

thanks for the tip.
-- 
View this message in context: 
http://old.nabble.com/series-of-up%27n%27down-bows%3A---%5C%5C--%5C%5C--tp26295691p26304439.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi David,


It is too cheap to put this down to "faster".  The problem is not that
you need longer to do some things with Lilypond initially.  The  
problem

is that there is a large number of things for which there is no proper
way to do them at all, and you have to take out the crowbar.


As is also true with Finale/Sibelius/etc. — for example, try doing  
 and its opposite (i.e.,  
barline-synced version) in a single score in Fin/Sib.  ;)



The documentation for extending Lilypond is not working out well


Any chance you can/will improve it?


lilypond-extending does not contain examples for the various layers.
There are no examples for how to work in Midi functionality.


Since I don't [yet] make any use of MIDI, this doesn't really matter  
to me — if it matters to you or others, by all means make it better!



Things like "ritardando" can't be found in the notation index


Patch?

Not only does it appear ridiculous to have to use a TextSpanner  
override
before even starting the relevant note just to specify the text  
(rather

than have \startTextSpan take an argument), naturally nothing will
appear in the Midi output.


1. Define a music function to do this.
2. Submit a patch.


it is important that Lilypond gets to do more things all by itself


I couldn't agree more! [See Steps 1&2, above.]

The mailing list is somewhat helpful, but many of the answers are  
in the

line of "you can trick Lilypond into showing this/you can hack the
output to be like this" rather than "Lilypond's language for this
musical construct would be".


Can you give an actual example from the archives?
i.e., link to a message where the answer wasn't what you needed/ 
wanted, and rewrite the answer so that it is


Thanks,
Kieren.

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

A barline half length long

[Jiri Zurek (Prague)]

Given that scheme calculations may be passed to the barLine bar-size
property, I was attempting to draw a barLine which would be only a half
length long vertically. When the size of the score is constant, it is not
difficult to hard-code a specific bar-size, but since I use several staff
sizes, it must be coded as the fraction of the "normal" bar-size. So, I
wrote this:

\once \override Staff.BarLine #'bar-size = #(* ly:bar-line::calc-bar-size
0.5) \bar "|"

...but I have got an error message by GUILE: Wrong type argument in position
1: #. 
I suspect it must be some silly error in scheme syntax, but I tried many
things and I cannot get it right. What is wrong with my syntax, please? 
-- 
View this message in context: 
http://old.nabble.com/A-barline-half-length-long-tp26303251p26303251.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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

Re: \override VerticalAxisGroup #'remove-empty works only at the beginning of a score

[Nicolas Sceaux]

Le 11 nov. 2009 à 16:07, Reinhold Kainhofer a écrit :

Now, this is a problem, if the whole score consists of several  
different parts.

For example, I have a choral score with fugues and a soprano solo.
during the fugues, none of the staves should be removed (if e.g. the  
Alto sets
in 9 measures later, I still need the empty staff for them them),  
but during

the soprano solo, the alto, tenor and bass should be removed.


By adding the rest-interface to Score.keepAliveInterface, you prevent
a staff from being removed when there are rests.

startUnremovableSection = \set Staff.keepAliveInterfaces =
#'(rhythmic-grob-interface
rest-interface
lyric-interface
percent-repeat-item-interface
percent-repeat-interface
stanza-number-interface)

endUnremovableSection = \unset Staff.keepAliveInterfaces

\score {
  <<
\new Staff {
  \startUnremovableSection
  c'1 R R c'
  \endUnremovableSection
  e'1 R R e'
}
\new Staff {
  \clef "bass" \repeat unfold 8 { c1 \break }
}
  >>
  \layout {
\context { \RemoveEmptyStaffContext }
  }
}



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

Re: chordSymbols, arbitrary chord markup

[Carl Sorensen]

On 11/11/09 4:51 AM, "VáclavŠmilauer"  wrote:

> Hi,
> 
> I use \chordSymbols hack (http://lsr.dsi.unimi.it/LSR/Item?id=608) in my jazz
> charts and although, it works quite well in normal cases, it has some
> limitations: you can't write "C phryg" or combination of 6,7,9,11,13 not in
> the
> font etc. I read threads on jazz chords on this list as well
> (http://thread.gmane.org/gmane.comp.gnu.lilypond.general/49607 and others).
> 
> I would like to ask if there is a way to write arbirary markup for chords
> (even
> as lyrics, i.e. they wouldn't be transposable), other than using \markup{...}
> in
> lyrics context for every single chord -- some helper macros perhaps?

You could define each special chord as its own identifier, then use it as a
markup:

\version "2.13.7"

chordOne = \markup {"Chord I"}
chordTwo = \markup {"Chord II"}

\relative c'' {
  \textLengthOn
  a2^\chordOne a | 
  a^\chordTwo a
}

There are also potentially fancier ways of doing it using a markup function,
but those are more complicated than I want to get into on this list.

I think the best way for you to do it is with the chordExceptions list.

> 
> In the longer term, I am considering sponsoring development of non-interpreted
> transposable chord symbols context, as discussed earlier on the list; it seems
> that any sponsorship pages have been removed since a few year... ?

There is nobody who is working on LilyPond for money right now.  I think
that none of us could make it worth our time to make changes to LilyPond for
a reasonable sponsorship fee.  We work on what we're interested in working
on as a hobby; hobbies don't have to make money to be worth doing.

The current way to make a sponsorship offer is to post an enhancement
request to bug-lilyp...@gnu.org, with an offer of a bounty.  But I don't
think any of the issues that have bounties have been worked on for the
bounty.

I'm sorry I don't have a better answer for you, but this is the current
state of LilyPond development.

HTH,

Carl



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

\override VerticalAxisGroup #'remove-empty works only at the beginning of a score

[Reinhold Kainhofer]

It seems that overriding #'remove-empty for Staff.VerticalAxisGroup has only an 
effect if it is called prior to the first note of the staff. Any 
   \override VerticalAxisGroup #'remove-empty = ##t (or ##f)
after the first note does not have any effect. 

Now, this is a problem, if the whole score consists of several different parts. 
For example, I have a choral score with fugues and a soprano solo.
during the fugues, none of the staves should be removed (if e.g. the Alto sets 
in 9 measures later, I still need the empty staff for them them), but during 
the soprano solo, the alto, tenor and bass should be removed.

I tried using 

\layout {
  \context { \RemoveEmptyStaffEngraver }
  \context { \Staff
\override VerticalAxisGroup #'remove-empty = ##f
  }
}

and then in the music:
  b1 |
  % We want to remove empty staves only during the Solo!
  \override VerticalAxisGroup #'remove-empty = ##t
  R1*3 | 
  \override VerticalAxisGroup #'remove-empty = ##f
  c1 

Attached is a full sample file. I don't want the empty staves in measures 2 and 
3 removed, but during the solo (measures 4-6) all empty staves should be 
removed. Then, in measure 7, empty staves should no longer be removed...

Any idea how to implement this? Or how can I make #'remove-empty also work 
after a staff has started?

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
\version "2.13.7"

% This sample score has the following structure:
% Measures 1-3: tutti, empty staves should be kept
% measures 4-6: solo, empty staves of the 2. & 3. voice should be removed
% measures 7-end: tutti, empty staves should be kept again

\layout {
  \context { \RemoveEmptyStaffContext }
  \context { \Staff
\override VerticalAxisGroup #'remove-empty = ##f
  }
}
m = \relative c'' { c1^"Tutti" c c c^"Solo" c c c^"Tutti" c }
musicA = \relative c' { d1 d R1 |
  % We want to remove empty staves only during the Solo!
  % this does not have any effect!
  \override Staff.VerticalAxisGroup #'remove-empty = ##t
  R1*3 | 
  \override Staff.VerticalAxisGroup #'remove-empty = ##f
  R1 e1 \bar"|."
}
musicB = \relative c' { d1 R1 b1 |
  % We want to remove empty staves only during the Solo!
  \override VerticalAxisGroup #'remove-empty = ##t
  R1*3 | 
  \override VerticalAxisGroup #'remove-empty = ##f
  c1 c1 \bar"|."
}


\score {
  <<
\new Staff \with { shortInstrumentName = "V1" } { << \m \repeat unfold 8 {s1\break} >> }
\new Staff \with { shortInstrumentName = "V2" } { \musicA }
\new Staff \with { shortInstrumentName = "V3" } { \musicB }
  >>

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

Re: modern accidentals rule

[Hudson Flávio Meneses Lacerda]

Frédéric Bron wrote:

BTW, I have found a strange behaviour of "modern" accidentals rule:
LilyPond considers volta alternatives as "previous" measure. Is this
correct? (Note the natural sign at the 2nd and 3rd alternatives, not
related to the previous _played_ measure.)


Yes, this is known behaviour. Here is the workaround I use:

[...]

Thanks!

Hudson



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

Re: Quit [now definitely O/T]

[David Kastrup]

Kieren MacMillan  writes:

> Hi Craig (et al.),
>
>> I must say that the "faster" thing is a typical United States
>> behavior.
>
> Whether or not it started in the USA, it's a worldwide phenomenon now.
> =)
> [Disclosure: I'm Canadian.]

It is too cheap to put this down to "faster".  The problem is not that
you need longer to do some things with Lilypond initially.  The problem
is that there is a large number of things for which there is no proper
way to do them at all, and you have to take out the crowbar.

Lilypond is supposed to be a music typesetter.  Music in, glyph
placement out.  If I have to do the typesetting myself, placing glyphs
rather than specifying musical content, Lilypond is not doing its job.
And some Scheme/C++/whatever hackery for manually placing some glyphs
one by one sure as heck is less convenient than just point and click.

The documentation for extending Lilypond is not working out well: the
automatically generated lilypond-internals contains no useful examples
or explanations, the concepts for the C++, Scheme and Lilypond data
structures that one needs for internal programming are not explained
anywhere visibly, it is not clear what one can or cannot hope to do in
what layer and with what level of expertise.

lilypond-extending does not contain examples for the various layers.
There are no examples for how to work in Midi functionality.  As a
side-effect of taking out the crowbar and doing visual arrangement of
music content manually, of course the Midi output does not get any
relevant info.

Things like "ritardando" can't be found in the notation index and are
programmed something like

Some performance indications, e.g., rallentando or accelerando, are
written as text and are extended over multiple notes with dotted lines.
Such objects, called "spanners", may be created from one note to
another using the following syntax:

 \override TextSpanner #'(bound-details left text) = "rit."
 b1\startTextSpan
 e,\stopTextSpan
<>

Not only does it appear ridiculous to have to use a TextSpanner override
before even starting the relevant note just to specify the text (rather
than have \startTextSpan take an argument), naturally nothing will
appear in the Midi output.

There is a lot of things that you can do with Lilypond, but it is
important that Lilypond gets to do more things all by itself (and the
vocabulary to tell it what happens _musically_ so that it will produce
PDF and Midi without further intervention).  If the input for a
facsimile of some historical score is basically indistinguishable from a
modern score input (just differing by how one does everything manually),
something is wrong.

It does not even matter if Lilypond's first implementation/iteration at
doing something sucks: once I can _express_ my musical intent to
Lilypond, future improvements of Lilypond will lead to better output.
But if I can only express a glyph arrangement, improvement is off the
chart.

The mailing list is somewhat helpful, but many of the answers are in the
line of "you can trick Lilypond into showing this/you can hack the
output to be like this" rather than "Lilypond's language for this
musical construct would be".

And that makes you continue your dependence on others' manual help.

-- 
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: temporary staff for divisi

[Simon Bailey]

figured this one out:

On 11 Nov 2009, at 14:56, Stefan Thomas wrote:

I have a last question.
Why is the shortInstrumentName for Violin one solo not shown?


because the staff only just started. lily puts the instrumentName at  
the beginning of the first line of a staff. (naïve explanation, trying  
to sound like i know what i'm talking about).



Here the snippet:
\version "2.12.2"
 violineA = \context Staff ="ViolineA"
 { \set Staff.instrumentName = "Violine 1"
  \set Staff.shortInstrumentName="Vlne.1"


   c'' 4 d'' e'' f'' g'' a'' b'' c'''\break
 <<
   \new Staff \with { alignAboveContext = "ViolineA" }
   { \set Staff.shortInstrumentName="Vlne. 1 solo" %why is this not  
shown?

%add this here:
  \set Staff.instrumentName="Vlne. 1 solo"


 c'''4^"solo"( d''' e''' f''' g''' a''' b''' c) }
   { c'' 4 d'' e'' f'' g'' a'' b'' c''' } >>
 }
 violineB = \context Staff ="ViolineB"
 { \set Staff.instrumentName = "Violine 2"
   \set Staff.shortInstrumentName="Vlne. 2"
   \repeat "unfold" 2 { c'' 4 b' a' g' f' e' d' c' }}
\score {
 \new StaffGroup <<
 \new GrandStaff \violineA
  \violineB >>

}



hth,
sb
--
Simon Bailey
Oompa Loompa of Science
+43 699 190 631 25



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

Re: quit

[Leonardo Herrera]

On Tue, Nov 10, 2009 at 9:01 PM, Erik Appeldoorn  wrote:
[...]
>
> On the plus I found, good looking scores, very flexible
> On the minus I found, very tedious, time-consuming and heavily relying on
> work-arounds.
>
> Hope this will give some inside. I won't say I'll never try again, but not
> just now.
>
> Hou je goed / Keep well,
>
> Erik

This is some good criticism. The cons you mention are, however, what
makes Lilypond able to produce truly good-looking scores, which is -as
you say- a plus.

I would add that your challenge is a tough one: to write complex,
non-standard scores. I remember you asking something regarding ties
between different voices, for example, and those are difficult to
express in text, but really easy to express using a GUI (press some
'tie' button, click one head, click another head, done.) So yes, in
your particular case, doing that in a good editor like Sibelius should
be easier.

(But I'm _sure_ Lilypond produces a better looking score!)

Anyways, I hope you manage to get around. Sibelius _is_ a great piece
of software, no point on negating that. But, in my case, I write
scores just for the fun of it, so I cannot spend US$600 just upload
free things to the series of tubes...

Regards,
-- 
Leonardo Herrera
mailto:leonardo.herr...@gmail.com
http://leus.epublish.cl


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

Re: temporary staff for divisi

[Stefan Thomas]

Dear community,
I have a last question.
Why is the shortInstrumentName for Violin one solo not shown?
Here the snippet:
\version "2.12.2"
 violineA = \context Staff ="ViolineA"
 { \set Staff.instrumentName = "Violine 1"
  \set Staff.shortInstrumentName="Vlne.1"


   c'' 4 d'' e'' f'' g'' a'' b'' c'''\break
 <<
   \new Staff \with { alignAboveContext = "ViolineA" }
   { \set Staff.shortInstrumentName="Vlne. 1 solo" %why is this not shown?
 c'''4^"solo"( d''' e''' f''' g''' a''' b''' c) }
   { c'' 4 d'' e'' f'' g'' a'' b'' c''' } >>
 }
 violineB = \context Staff ="ViolineB"
 { \set Staff.instrumentName = "Violine 2"
   \set Staff.shortInstrumentName="Vlne. 2"
   \repeat "unfold" 2 { c'' 4 b' a' g' f' e' d' c' }}
\score {
 \new StaffGroup <<
 \new GrandStaff \violineA
  \violineB >>

}


2009/11/10 Trevor Daniels 

> Stupid of me - ignore this - sorry for the noise :(
>
> Trevor
>
> - Original Message - From: "Trevor Daniels"  >
> To: "Mats Bengtsson" ; "Stefan Thomas"
>
> 
> Cc: "lilypond-user" 
> Sent: Tuesday, November 10, 2009 6:25 PM
> Subject: Re: temporary staff for divisi
>
>
>
>> Mats Bengtsson wrote Tuesday, November 10, 2009 5:40 PM
>>
>>
>>  I answer this email for the record.
>>>
>>> It seems that there's an attempt to explain this better in the
>>> 2.13 manual than in the 2.12 manual, see
>>>
>>> http://lilypond.org/doc/v2.13/Documentation/notation/Context-layout-order#Context-layout-order
>>> and
>>>
>>> http://lilypond.org/doc/v2.13/Documentation/notation/Aligning-contexts#Aligning-contexts
>>> ,
>>> but it still doesn't really answer your question.
>>>
>>
>> There's a little more in
>>
>> http://lilypond.org/doc/v2.13/Documentation/notation/Context-layout-order#Context-layout-order
>> but even this is not quite complete.
>> Trevor
>>
>>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quit [now definitely O/T]

[Kieren MacMillan]

Hi Craig (et al.),

I must say that the "faster" thing is a typical United States  
behavior.


Whether or not it started in the USA, it's a worldwide phenomenon  
now.  =)

[Disclosure: I'm Canadian.]


Our markets and media constantly barrage us with "time" issues.


I think maybe "convenience" is a better word to describe what our  
culture really [apparently] prizes, since "convenient" implies both  
"faster" (time) and "easier" (effort) — and, usually,  
"cheaper" (cost), at least in the short term.


I'm constantly fascinated by the fact that people will pay more for  
lower quality (e.g., cellular phones ALWAYS sound worse and cut out  
more often than land lines, yet cost far more to own/operate).  
Furthermore, our culture now prizes digital downloads (regardless of  
price) despite the obvious drop in aural/visual quality. [I still buy  
all my music on CD, and all my movies on DVD.]



It has effected how we eat, think, commute


Ironically, most people have MUCH longer (and slower) commutes now  
than they did years ago — my commute, fortunately, is only about 10  
seconds from breakfast room to composition studio.  ;)


As a 50 year old composer, a guy that will take 3 months to write a  
saxophone concerto


Good for you!
Although I do [out of necessity] compose quickly from time to time  
(e.g., my writing partner and I completed our last musical in about  
2.5 weeks), the really good stuff takes time, "space", and focus.


Cheers,
Kieren.

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

Re: chordSymbols, arbitrary chord markup

[Robin Bannister]

Václav Šmilauer wrote:

other than using \markup{...} in lyrics context for every single chord


If your needs are met by (a possibly modifed) ChordNames most of the time,
you can use replaceCN to deal with the impossible cases.
http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00558.html

Cheers,
Robin 




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

Re: series of up'n'down bows: /\\//\\/

[-Eluze]

user28 wrote:
> 
> 
> is it possible to make they more compact?
> 

with \textLengthOn you can make sure the next note or barline is starting
when the text has been written.
additionally you can move the starting position of your bows (which i
replaced with \dmarcato) to the right if needed.

{
  \clef "G_8"
  2
  4
  \textLengthOn
  
  ^\markup {
\hspace #.5
\raise #1 \musicglyph #"scripts.dmarcato"
\musicglyph #"scripts.umarcato"
\raise #1 \musicglyph #"scripts.dmarcato"
\musicglyph #"scripts.umarcato"
\raise #1 \musicglyph #"scripts.dmarcato"
\musicglyph #"scripts.umarcato"
\raise #1 \musicglyph #"scripts.dmarcato"
\musicglyph #"scripts.umarcato"
  }
  \textLengthOff  % optional
  8[ ^\markup { \hspace #.5 \raise #1 \musicglyph #"scripts.dmarcato"
}
  8] ^\markup { \hspace #.5 \musicglyph #"scripts.umarcato" }
}
-- 
View this message in context: 
http://old.nabble.com/series-of-up%27n%27down-bows%3A---%5C%5C--%5C%5C--tp26295691p26300641.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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

Re: Quit

[craigbakalian]

On Wed, 2009-11-11 at 00:44 -0500, lilypond-user-requ...@gnu.org wrote:
> Also, the complaint here isn't that there's some inherent defect in  
> the program or the documentation, rather that you didn't want to
> take  
> the time to learn how to use lilypond when you could do it in  
> sibelius faster.
> 
> James E. Bailey 

I must say that the "faster" thing is a typical United States behavior.
Our markets and media constantly barrage us with "time" issues.  The
main point of sale is "if you buy our product you can get it done
faster".  The barrage has brought about an almost infantile attitude
amongst US citizens.  They want it fast and now!  There is no other way.
It has effected how we eat, think, commute, learn, and often make
products (we really don't do that anymore). 

As a 50 year old composer, a guy that will take 3 months to write a
saxophone concerto, I watch this whirlwind and frenzy every day-  It is
taking a toll on US citizens, the stress level is bizarre.  It is
incredible to watch these poor souls demanding more and more from each
other, faster and faster, stronger and stronger... to finally get...
somewhere?  Eventually my grand children will look back on this era as
truly infantile.  I know that is such a harsh word, but that is how
monopolies want their customers-- infantile and dependent for
everything.

Craig Bakalian





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

Re: octave

[Bertalan Fodor (LilyPondTool)]

Use

\set Staff.clefOctavation = #7 in the octavated staff

See 
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Displaying-pitches 
for details.

Bert


Francesco Petrogalli wrote:

Hi,
a friend send me a score written with encore, I am "porting" it in
lilypond. This score has 4 instruments, a sax, a cello and two pianos.

Now, the part of the first piano has to be played an octave higher the
what is written on the score, so the guy who has written it with
encore has placed an "8" over the clefs of the piano staves.

Is this a standard way to specify to play an octave higher?
If yes, how can I do this with lilypond?
If not, what should I do? Which is the "standard" way?

Thanks,

Francesco

  





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

Re: octave

[Gilles Sadowski]

Hi.

> Now, the part of the first piano has to be played an octave higher the
> what is written on the score, so the guy who has written it with
> encore has placed an "8" over the clefs of the piano staves.
> 
> Is this a standard way to specify to play an octave higher?
> If yes, how can I do this with lilypond?

 \clef "G^8"

Best,
Gilles


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

octave

[Francesco Petrogalli]

Hi,
a friend send me a score written with encore, I am "porting" it in
lilypond. This score has 4 instruments, a sax, a cello and two pianos.

Now, the part of the first piano has to be played an octave higher the
what is written on the score, so the guy who has written it with
encore has placed an "8" over the clefs of the piano staves.

Is this a standard way to specify to play an octave higher?
If yes, how can I do this with lilypond?
If not, what should I do? Which is the "standard" way?

Thanks,

Francesco

-- 
Francesco Petrogalli
PhD student
Dipartimento di Matematica e Informatica
Universita' degli Studi di Perugia
via Vanvitelli 1, Perugia (Italy)
phone: +39 075 585 5039
fax:   +39 075 585 5024
email: francesco.petroga...@dmi.unipg.it
   francesco.petroga...@gmail.com

Linux Registered User: #414858

P Funking Band
http://www.perugiafunkingband.it
http://www.myspace.com/perugiafunkingband


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

chordSymbols, arbitrary chord markup

[VáclavŠmilauer]

Hi,

I use \chordSymbols hack (http://lsr.dsi.unimi.it/LSR/Item?id=608) in my jazz
charts and although, it works quite well in normal cases, it has some
limitations: you can't write "C phryg" or combination of 6,7,9,11,13 not in the
font etc. I read threads on jazz chords on this list as well
(http://thread.gmane.org/gmane.comp.gnu.lilypond.general/49607 and others).

I would like to ask if there is a way to write arbirary markup for chords (even
as lyrics, i.e. they wouldn't be transposable), other than using \markup{...} in
lyrics context for every single chord -- some helper macros perhaps?

In the longer term, I am considering sponsoring development of non-interpreted
transposable chord symbols context, as discussed earlier on the list; it seems
that any sponsorship pages have been removed since a few year... ?

Regards, Václav




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

Re: upgrading

[Reinhold Kainhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Mittwoch, 11. November 2009 12:13:49 schrieb Gerard McConnell:
> Hi,
> Perhaps a stupid question -  is there any reason NOT to
> upgrade from 2.12.x  to 2.13.7?

If you are adjusting the vertical layout (staff spacing, padding etc.), then 
things will be completely different in 2.13.7, and there is no convert-ly rule 
(yet???).

Cheers,
Reinhold

- -- 
- --
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFK+p+STqjEwhXvPN0RApgnAJ9afg8rE7i6/lQTnPttMDQ8g3P2GgCgjmSr
JnBwCzKrW8+dXFUWP7THtSM=
=V3aU
-END PGP SIGNATURE-


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

Re: vim vagaries

[Jethro Van Thuyne]

Hi Jonathan,

It's not to easy to find the right locations indeed, perhaps this might 
help. First you have to edit a file called filetype.vim, located in 
/home/yourusername/.vim/


If it isn't there, you can just create it:

  touch /home/yourusername/.vim/filetype.vim

If the .vim directory isn't there either, you have to create that first.

  mkdir /home/yourusername/.vim

When you finished doing that, you can paste the following text in the file 
"filetype.vim":


  if exists("did_load_filetypes")
finish
  endif
  augroup filetypedetect
au! BufNewFile,BufRead *.lysetf lilypond
  augroup END

The next thing you should do, is to locate the syntax files for vim, 
which will go into your .vimrc. Check if you have a file called 
.vimrc in your home directory. If you don't have one, do:


  touch /home/yourusername/.vimrc

The location of the syntax folder depends on how you installed lilypond, 
and on which computer. The easiest way to find out where they are, is to 
type this in the terminal:


  locate vim/syntax | grep lily

This should give you a short list of paths, containing something like 
/usr/share, the version nummer of your current lilypond install, followed 
by "/vim/syntax/". Mine looks like this:


  locate vim/syntax | grep lily
/usr/share/lilypond/2.13.7/vim/syntax
/usr/share/lilypond/2.13.7/vim/syntax/lilypond-words
/usr/share/lilypond/2.13.7/vim/syntax/lilypond-words.vim
/usr/share/lilypond/2.13.7/vim/syntax/lilypond.vim


Copy the line - without the words after "vim" - and paste it in your 
.vimrc like this:


  set runtimepath+=/usr/share/lilypond/2.13.7/vim

and save it. Next time you open up a file with a .ly extension, you should 
get the correct syntax highlighting.


Best regards,

Jethro


On Wed, 11 Nov 2009, J. wrote:

Hi Again evrey body, I'm happy to say that with because of the help you 
gave me I was not only able to get jedit up and running for lilypond but 
was encouraged to succede in setting up emacs too! Vim though is 
somthing else. I looked at the directions on the lilypond site for 
setting it up but, because of my noviciate I got confused with all the 
places and symbols. i.e. can you add all the lilpond things into the 
place where vim is (/user/bin/share/vim) or have to make a ~/.vim and 
how does one modify the files when the're found. [Whew!] Would appreciat 
some help like you gave last time.


   Jonnie



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

Re: upgrading

[Francisco Vila]

2009/11/11 Gerard McConnell :
> Hi, Perhaps a stupid question -  is there any reason NOT to
> upgrade from 2.12.x  to 2.13.7?

Possibly. 2.13.7 could have changes in syntax, or experimental
features. It worths it if you want to help testing it.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org
www.csmbadajoz.com


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

upgrading

[Gerard McConnell]

Hi, 
Perhaps a stupid question -  is there any reason NOT to

upgrade from 2.12.x  to 2.13.7?
Thanks,
Gerard


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

Re: Orphaned and widowed lines in \markuplines

[Nicolas Sceaux]

Le 10 nov. 2009 à 07:19, David Kastrup a écrit :


Nicolas Sceaux  writes:


Le 9 nov. 2009 à 11:10, Jiri Zurek (Prague) a écrit :



It happens to my scores that when using \markuplines for long texts
(more
than a page), Lilypond leaves a first or a last line orphaned  
(single,

alone) on a page. This is normally unwanted in printed
literature. Is there
a way how to instruct Lilypond not to leave orphaned or widowed
single lines
on any page?


You may consider using the ly:minimal-breaking page breaking  
algorithm

for
text sections. The default algorithm, ly:optimal-breaking, is  
abviously
dedicated to scores, so it can lead to suboptimal results when  
dealing

with
text. Conversely, ly:minimal-breaking gives better results with  
text: it
stacks as many lines as possible on a page before brekaing to the  
next

one.


The answer does not fit the question.  The question was not about
stacking as much on a page as possible.  Quite contrary: it was about
stacking less than possible if it avoids ugly results.


Yet, it might have been an artefact of an inappropriate page breaking
algorithm, hence the suggestion, which was not labeled as a solution,
mind you, just a possible track to investigate.
Your post is absolutely unnecessary, btw.



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

Double/Combination Trills

[grammerfest]

Hi all,

I can't find any mention of an implementation of double or combination trill
in the docs anywhere. 

Has anyone found a way to implement these (trills with two or more notes
other than the principal note)?  

many thanks,

piaras
-- 
View this message in context: 
http://old.nabble.com/Double-Combination-Trills-tp26299196p26299196.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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

Re: chord names in piano staff

[Peter Chubb]

> "henrik" == henrik pantle  writes:

henrik> hi, i wonder where to find the solution for my problem.  i
henrik> guess a lot of others do too.

henrik> i want the chord names above the piano staff:

You need to add a score block thus:

guitarChords = \chordmode { ...}
upper = \relative { ... }
lower = \relative { ... }

\score {
   <<
\context ChordNames \guitarChords
\context GrandStaff <<
\context Staff = upper \upper
\context Staff = lower \lower
>>
   >>
}


--
Dr Peter Chubb  www.nicta.com.aupeter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au   ERTOS within National ICT Australia


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

Re: vim vagaries

[Graham Breed]

J. wrote:


I looked at the directions on the lilypond site for
setting it up but, because of my noviciate I got confused
with all the places and symbols.


I found a page here:

http://lilypond.org/doc/v2.12/Documentation/user/lilypond-program/Vim-mode

It isn't clear which of those things you have to do.  As I 
hadn't done any of this before, I gave it a try.  The answer 
is: both.  You need to create this filetype.vim in a 
suitable place so that vim knows to go looking for .ly 
files.  (And should that be modified for the extension we're 
supposed to be using for include files?)  You also need to 
tell vim about your Lilypond installation or move some files 
into a standard vim folder.



i.e. can you add all the lilpond  things into the place
where vim is (/user/bin/share/vim) or have to make a
~/.vim and how does one modify the files when the're
found. [Whew!]


You can add the Lilypond things to your vim folders, but 
this might confuse you when you move computers or reinstall 
or something like that.  If you add things to ~/.vim you can 
move that to any new computer you want things to work on.


Note that these instructions are for UNIX but your headers 
show that you're using Windows.  Identifying those folders 
for a Windows installation of vim (outside of Cygwin) may 
well confuse you.  Inside vim, you can do


:set runtimepath

to find places where vim will look for things.


Graham



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