Re: problems trying to write a conditional \transpose

[David Kastrup]

Mark Polesky  writes:

> David Kastrup wrote:
>>> I'm trying to write a conditional version of the \transpose
>>> function, that would work something like this...
>>>
>>> input = {
>>>   c c
>>>   \conditionalTransposition c c' { c c }
>>> }
>>>
>>> \input
>>> => { c c c c }
>>>
>>> \processConditionalTransposition \input
>>> => { c c c' c' }
>>
>> conditionalTransposition =
>> #(define-music-function (parser location from to music)
>>   (ly:pitch? ly:pitch? ly:music?)
>>   (set! music #{ \transpose c' c' #music #})
>>   (set! (ly:music-property 'from-to music) (cons from to))
>>   music)
>>
>> processConditionalTransposition =
>> #(define-music-function (parser location music) (ly:music?)
>>   (map-some-music
>> (lambda (m)
>>   (and (music-is-of-type? m 'transposed-music)
>>(pair? (ly:music-property m 'from-to music))
>>#{ \transpose #(car (ly:music-property m 'from-to-music))
>>  #(cdr (ly:music-property m 'from-to-music))
>>  #(ly:music-property m 'element)
>>#}))
>>  music))
>
> David, 
>
> sorry for the delayed response.  Your solution is excellent!
> I'm learning so much from you.

The code is written in a manner that does not make it obvious, but I
should have mentioned why I stored a pitch pair rather than a single
pitch difference: this was in order not to have an outer \transpose
affect the pitch difference information: music properties containing a
single pitch are converted by \transpose.  A pitch pair is left alone.

-- 
David Kastrup


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

Re: new to lilypond

[David Kastrup]

James Harkins  writes:

> For accidentals, df and des are both abbreviations -- favoring
> concision -- but one is more concise than the other, and neither is
> inherently more readable.

Uh, no?  df is an abbreviation, but des is a proper pronouncable name
(if you are Dutch/German, that's the name you use when talking about
music).  As such, it has a letter combination that is natural to scan.

Indeed, English has both dflat as well as df, while Dutch/German has
only des and nothing else.  The multi-word equivalent to "d flat" would
be "d mit einem b-chen" but that's kid talk.  No musician would use
that.

Now if you use ds and df often enough, they'll become more than
abbreviations to you, but you still can't easily pronounce them as
non-abbreviations.

> If we wanted efficiency and global readability, we might try db and
> d#, but I guess the # would confuse the parser.

You could use d♭ and d♯ but they are rather cumbersome to type.  And
actually, they are not considerably more readable since they are half
name, half symbol.  While one uses them for chord names, for single
notes they seem sort of unusuable.

-- 
David Kastrup


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

Re: problems trying to write a conditional \transpose

[Mark Polesky]

David Kastrup wrote:
>> I'm trying to write a conditional version of the \transpose
>> function, that would work something like this...
>>
>> input = {
>>   c c
>>   \conditionalTransposition c c' { c c }
>> }
>>
>> \input
>> => { c c c c }
>>
>> \processConditionalTransposition \input
>> => { c c c' c' }
>
> conditionalTransposition =
> #(define-music-function (parser location from to music)
>   (ly:pitch? ly:pitch? ly:music?)
>   (set! music #{ \transpose c' c' #music #})
>   (set! (ly:music-property 'from-to music) (cons from to))
>   music)
>
> processConditionalTransposition =
> #(define-music-function (parser location music) (ly:music?)
>   (map-some-music
> (lambda (m)
>   (and (music-is-of-type? m 'transposed-music)
>    (pair? (ly:music-property m 'from-to music))
>    #{ \transpose #(car (ly:music-property m 'from-to-music))
>  #(cdr (ly:music-property m 'from-to-music))
>  #(ly:music-property m 'element)
>    #}))
>  music))


David, 

sorry for the delayed response.  Your solution is excellent!
I'm learning so much from you.

Thanks again.
- Mark

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

Re: getting LedgerLineSpanner props from a NoteHead callback?

[Mark Polesky]

Thomas Morley wrote:
>> I'm trying to retrieve the value of
>> LedgerLineSpanner.length-fraction from within a NoteHead
>> callback, and I can't figure it out.  Is there a way?
>
> Hi Mark,
>
> a quick shot, seems to work, though:

Harm,

that was great; thanks for that!  It was the 
System.all-elements property that I didn't know about.
That's the trick.

Thanks so much.
- Mark

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

Re: new to lilypond

[James Harkins]

On Aug 19, 2013 11:36 PM, "Andrew Bernard"  wrote:
>> They take up space but don't /do/ anything in
>> return for the extra finger effort.
>
> But they _do_ do something in Nederlands for people whose language it is.

Sure, but I was responding to a comment from a native English speaker who
uses Dutch input because... he likes more typing? :-P

Kidding... the real issue is the trade-off between readability and
concision. Actually, despite my complaints about extra keystrokes, in my
SuperCollider coding, I'm coming to favor readability: naming a variable
pitchClass rather than pc, or compare these ways to make an array of random
numbers:

{ 10.rand } ! 20  // "!"? What's that?

vs

// Even if I don't know anything about SC,
// this is obviously about arrays so I know
// where to look in the help
Array.fill(20, { 10.rand })

In the latter case, SC's code editor has nice auto-completion features, so
the finger cost is not as high as the character count.

For accidentals, df and des are both abbreviations -- favoring concision --
but one is more concise than the other, and neither is inherently more
readable. Of course it's valuable to let users enter notes in the way that
looks comfortable to them, but I think here, there's a rational argument to
be made that the gain in ease of reading is small.

But anyway, with Frescobaldi, I can type \inc RET SPC "eng RET " so, easy
enough.

If we wanted efficiency and global readability, we might try db and d#, but
I guess the # would confuse the parser.

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

[Schikkers-List]: demo feedback

[Paul Morris]

Nice progress on Schikkers list!  It seems like it is coming along well.  

One thing that is counter-intuitive (maybe you're already aware of this), is 
that selecting a different note duration from the palette changes the currently 
selected note.  My expectation was that it would only apply to newly entered 
notes, and that to change an already-entered note to a new duration, I would 
have to click on it again.

Also, I prefer having the LilyPond text box below the staff instead of 
side-by-side, since that would provide more horizontal space for viewing the 
staff.

I noticed an audio bug where a note would repeatedly play for some reason.  
(using Chrome 27)

Ok, those are just a few thoughts for your consideration.  Great work so far!

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

Re: getting LedgerLineSpanner props from a NoteHead callback?

[Thomas Morley]

2013/8/19 Mark Polesky :
> I'm trying to retrieve the value of
> LedgerLineSpanner.length-fraction from within a NoteHead
> callback, and I can't figure it out.  Is there a way?
>
> Thanks.
> - Mark
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

Hi Mark,

a quick shot, seems to work, though:

\version "2.17.24"

#(define (look-up-for-parent name-symbol axis grob)
"
 Return the parent of @var{grob}, specified by it's @var{name-symbol} in
 axis @var{axis}.
 If not found, look up for the next parent.
"
 (let* ((parent (ly:grob-parent grob axis))
(grob-name (lambda (x) (assq-ref (ly:grob-property x 'meta) 'name
 (cond
   ((not (ly:grob? parent))
(ly:error
   (_"Perhaps typing error for \"~a\" or \"~a\" is not in the parent-tree.")
   name-symbol name-symbol))
   ((not (equal? name-symbol (grob-name parent)))
(look-up-for-parent name-symbol axis parent))
   (else parent

#(define (read-out l1 l2)
   (define (helper ls1 ls2 ls3)
   "Filters all elements of ls1 from ls2 by their grob-name and
appends it to ls3"
(let ((grob-name-proc (lambda (x) (assq-ref (ly:grob-property x
'meta) 'name
 (if (null? ls1)
 ls3
 (helper
   (cdr ls1)
   ls2
   (append ls3 (filter (lambda (x) (eq? (car ls1)
(grob-name-proc x))) ls2))
  (helper l1 l2 '()))

foo =
\override NoteHead.before-line-breaking =
  #(lambda (grob)
(let* ((sys (look-up-for-parent 'System X grob))
   (all (ly:grob-array->list (ly:grob-object sys 'all-elements)))
   (llsp (read-out '(LedgerLineSpanner) all))
   (l-f (ly:grob-property (car llsp) 'length-fraction)))
(display l-f)
))


{
\foo
a'
}


HTH,
   Harm

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

getting LedgerLineSpanner props from a NoteHead callback?

[Mark Polesky]

I'm trying to retrieve the value of
LedgerLineSpanner.length-fraction from within a NoteHead
callback, and I can't figure it out.  Is there a way?

Thanks.
- Mark

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

Re: Sharing: "Capone," by Rachael [pdf]

[Janek Warchoł]

Hi Rachael,

2013/7/9 Rachael Thomas Carlson :
> Hello All:
>
> I finished my first transcription with Lilypond a couple of days ago.  I am
> proud of it.  I have realized a couple of flaws since finishing it but since I
> do not feel like writing another 5K lines of code for this piece I have
> decided that it is done.

Congratulations on finishing the score!

> I have found this community extraordinarily helpful.  I am excited to
> continue working with all of you!  And I must say, I have used Finale in
> the past but Lilypond surpasses it in almost every way.  I have talked
> with a fellow fingerstyle buddy of mine who also does transcriptions
> (with Finale, though) and he gripes about some of the same stuff but
> because he is not able to manipulate how Finale interprets what he is
> attempting to tell it he ends up spending many hours attempting to
> input something that could be input within an hour with Lilypond (and
> emacs/vim).

Thanks for your kind words!

I have one question: in measure 36 (lower staff), there are two eight
notes followed by a half-note chord.  One eight note is connected with
the chord using a tie, and the other one using a slur.  Shouldn't both
use ties?  I don't see any rearticulation in the tablature.

cheers,
JAnek

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

Re: Henle piano template

[Janek Warchoł]

2013/8/7 David Rogers :
> I just printed it and compared them side-by-side at the
> piano. Unfortunately I have to guess a little bit about absolute sizes,
> because I don't have any paper in the house except "Letter" size. With
> all due respect for Kieren's skill and work, which I cannot hope even to
> match let alone improve on, I really believe (taking the stated goals of
> Kieren's project literally) that only detail tweaks have so far been
> accomplished, and the general basic appearance is still very very
> LilyPond. What I notice is stuff that (to me) sounds like a mixture of
> easy things and difficult things:
>
> - The whole notation font needs to be replaced with a
>   Henle-look-alike. At the very least, LP's notehead size is much too
>   small for Henle; but everything else (quarter rests, fermatas, sharps
>   & flats, and clefs stand out in this example) looks "very LilyPond" as
>   well.
>
> - The staff lines, ledger lines, and note stems need to be lightened a
>   lot.
>
> - The beams may need to be darkened. (Or maybe they already match, after
>   lightening the staff lines and stems.)
>
> - Slurs need to be thinner at the ends and thicker in the middle.
>
> - The accidentals need to be significantly closer to their
>   noteheads. (I'm on version 2.17.22 - did something change? I'm getting
>   excessive white-space between each accidental and its note, in this
>   template.)

I also wish that accidental spacing would improve - see the resources
i've gathered here
http://code.google.com/p/lilypond/issues/detail?id=2142

Unfortunately that's not going to happen very soon.  One thing we
could do for the sake of better Lilypond engraving is to move forward
with Tie crusade.

best,
Janek

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

Re:

[Thomas Morley]

2013/8/19 Tommaso Gordini :
> "Here are the notes of the
> harmonic series that can be played on the horn. The notes marked with a
> plus tend to sound sharp, and the notes marked with a minus tend to
> sound flat."
>
> Yes, exactly! :-) I was wondering if there is a typographically correct to
> report it. Maybe it could be done with the arrows up or down over the
> quarter notes? But I have not been able to draw them :-(
>
> Ciao
> Tommaso
>
>
> 2013/8/19 David Rogers 
>>
>> Robert Schmaus  writes:
>>
>> > Or do you mean bends? Glissandi? Key change, even? Could you maybe
>> > send (or point to) an example?
>> >
>> > It seems unclear what you mean with "crescente/calante" in harmonics
>> > (as opposed to dynamics) ...
>>
>> I believe that the intended meaning is "Here are the notes of the
>> harmonic series that can be played on the horn. The notes marked with a
>> plus tend to sound sharp, and the notes marked with a minus tend to
>> sound flat."
>>
>> --
>> David R
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

Hi,

how about the coding below.

It shows two possibilities.
a) Simple TextScript
b) Hijacking StringNumber. (I suppose it will not be needed for French Horn.) :)

\version "2.16.2"

stringNumberSettings =
\layout {
\context {
\Voice
\override StringNumber #'Y-extent =
 #(ly:make-unpure-pure-container
ly:grob::stencil-height
(lambda (grob start end) (ly:grob::stencil-height grob)))
stringNumberOrientations = #'(right)
\override StringNumber #'padding = 0
  }
}

showTune =
#(define-event-function (parser location dir)(number?)
#{
  \tweak #'stencil
  #(lambda (grob)
(let* ((layout (ly:grob-layout grob))
   (staff-space (ly:output-def-lookup layout 'staff-space))
   (raise (cond ((= dir 1)
 staff-space)
((= dir -1)
 (* -2.8 staff-space))
(else 0)))
   (rotate (if (= dir -1)
   -90
   0)))
(grob-interpret-markup grob
#{ \markup { \combine \null \raise #raise \rotate #rotate "↗" } #})))
  \0
#})

\layout {
  %% Only needed if \showTune is used
  \stringNumberSettings
}

\relative c'' {
% Using TextScript
c_\markup "↗"
c^\markup \rotate #-90 "↗"
% (Ab)using StringNumber
c-\showTune #up
c-\showTune #down
}

HTH,
  Harm

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

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 Phil Holmes :
> - Original Message - From: "Janek Warchol"
>> What you said would be true if the snippets were so simple that they
>> never change. But they do change.
>
> Hardly ever.  I maintain the current LSR and the changes are so infrequent I
> often forget to check whether there are any.

Well, they need to be convert-ly'ed.  Besides, i have some snippets
that do change moderately often.

> This is part of the problem
> with your proposing changes - you admit you don't use the LSR, don't know
> how it works, don't know how to do simple updates, but you're proposing
> wholescale change.  Please try the current system before trying to make
> large changes to it.

ok, that's a valid point.  I hope to have some time to actually try
working with LSR.
As for now, maybe i'll just start some LSR-esque public git repository
to show that my approach is valid.

>> > You can't update any remote system offline - git or the LSR.
>>
>> but with git i can do everything that matters offline - add new stuff,
>> fix stuff, search old versions, etc. Then i just press a button and
>> it does the rest.
>> Imagine that i'm working on a big project w/o internet access (because
>> i'm on holidays) and i create a few snipets. Do you think i'll
>> remember them when i get back online? Definitely no! I will only
>> care to add them to the repository when i'm actually working on the
>> stuff, not a week later.
>
> You could consider a text editor to create the snippets offline, giving them
> sensible names in a directory you can remember, and pasting them when you're
> online.

Well, i could draw all my scores in Inkscape as well.

> The LSR is
> part of the LilyPond documentation system that users can access and read. It
> must be an accurate set of information and that's how it currently works.

I've already said that, but i probably didn't make myself clear: i
don't want to mix accurate and "official" snippets with chaotic ones.
They would be labeled so that users will know if they're looking at
"official snippet" or some weird hack that may be unsupported.

>> > The LSR is intended to allow non-power users the ability to contribute
>> > lilypond code to other users and potentially our documentation. As such,
>> > > it
>> > performs a useful service. I cannot imagine why you want to go to all >
>> > the
>> > work of reimplmenting something that fundamentally works using completly
>> > different technology. It would be a massive waste of time.
>>
>> Well, as for "completely different technology", that's not necessarily
>> what i propose. Using git as the tool to manage the actual *content*
>> doesn't have to mean changing thee tools that operate on that content.
>> Why do i want to do this? Because the current system is limited: we
>> don't have support for more than one lily version, upgrading is
>> inconvenient, and there are no convenient ways to add some valuable
>> stuff there.
>
>
> Fine.  If you want to waste your time, feel free to propose to change a
> perfectly adequate database for a completely different technology.

please don't say "perfectly adequate" unless you show that the current
system is capable of solving the problems i outlined.

Nevertheless, thanks for the discussion; you're right that i should
start by looking at current LSR and that maybe my ideas would be too
much effort.

cheers,
Janek

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

Re:

[Tommaso Gordini]

"Here are the notes of the
harmonic series that can be played on the horn. The notes marked with a
plus tend to sound sharp, and the notes marked with a minus tend to
sound flat."

Yes, exactly! :-) I was wondering if there is a typographically correct to
report it. Maybe it could be done with the arrows up or down over the
quarter notes? But I have not been able to draw them :-(

Ciao
Tommaso


2013/8/19 David Rogers 

> Robert Schmaus  writes:
>
> > Or do you mean bends? Glissandi? Key change, even? Could you maybe
> > send (or point to) an example?
> >
> > It seems unclear what you mean with "crescente/calante" in harmonics
> > (as opposed to dynamics) ...
>
> I believe that the intended meaning is "Here are the notes of the
> harmonic series that can be played on the horn. The notes marked with a
> plus tend to sound sharp, and the notes marked with a minus tend to
> sound flat."
>
> --
> David R
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Writing a fingering chart for French Horn

[Thomas Morley]

Hi Tommaso,

2013/8/18 Tommaso Gordini :
> Thank you, now everything works perfectly!
>
> I still have three demands.
>
> 1. It is possible to center the whole notes in the bar?

Yes. See attached file.
>
> 2. It is possible to determine the distance of the first row of numbers from
> the first line of the pentagram? I wish that all the numbers were in line
> below the staff. For example, not
>
> 
> 1   2  3
> 2 21  2-3
>
> but
>
> 
> 1 2 2  3
> 21  2-3

Here I don't know what you want. Doesn't the attached file gives you
want you desire?
>
> 3. How do you get the line bar even in the white space between staves?
Do you mean SpanBars? If yes, use StaffGroup. Again see attached file.
>
> Grazie e ciao
> Tommaso


HTH,
  Harm


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

Re:

[David Rogers]

Robert Schmaus  writes:

> Or do you mean bends? Glissandi? Key change, even? Could you maybe
> send (or point to) an example?
>
> It seems unclear what you mean with "crescente/calante" in harmonics
> (as opposed to dynamics) ...

I believe that the intended meaning is "Here are the notes of the
harmonic series that can be played on the horn. The notes marked with a
plus tend to sound sharp, and the notes marked with a minus tend to
sound flat."

-- 
David R

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

Re:

[Robert Schmaus]

Or do you mean bends? Glissandi? Key change, even? Could you maybe send (or 
point to) an example?

It seems unclear what you mean with "crescente/calante" in harmonics (as 
opposed to dynamics) ...

-
Von meinem Fliewatüüt gesendet.

On 19 Aug 2013, at 17:19, Tommaso Gordini  wrote:

> Sorry, I meant increasing and waning harmonics :-)
> 
> Ciao
> Tommaso
> 
> Il giorno lunedì 19 agosto 2013, Tommaso Gordini  
> ha scritto:
> > Hello to all,
> > here's a minimal code:
> > %%
> >
> > \version "2.16.2"
> >
> > \relative c {
> >
> > \clef "bass"
> >
> > \key c \major
> >
> > \cadenzaOn
> >
> > c,2
> >
> > ^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
> >
> > ^\markup {\small { Corno in Fa } }
> >
> > c' \clef "treble" g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4-- 
> > bes-+ b2 c
> >
> > \cadenzaOff \bar "||"
> >
> > }
> >
> > \layout {
> >
> > \context {
> >
> > \Staff \remove "Time_signature_engraver"
> >
> > }
> >
> > }
> >
> > %%
> > The quarter notes marked with '-' are waning, quarter notes marked with '' 
> > are increasing. What is the correct way to indicate it? I tried to draw the 
> > arrows, but I could not do it.
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: new to lilypond

[Carl Peterson]

On Mon, Aug 19, 2013 at 11:36 AM, Andrew Bernard
wrote:

> Greetings,
>
>   James Harkins 
>  20 August 2013 12:31 AM
>
> I'll be bold and disagree. G-flat is ges in Dutch (3 characters) and gf in
> English (2 characters). If you're typesetting a piece in D-flat major, the
> 33%
> redundancy for every black-key note in Dutch will add up quickly.
>
> Avoid D flat major. :-)
>

Or write in C and use a \transpose command, which is what I typically do in
that situation.
<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re:

[Thomas Morley]

2013/8/19 Tommaso Gordini :
> Sorry, I meant increasing and waning harmonics :-)
>
> Ciao
> Tommaso

Do you mean:

\version "2.16.2"

\new Staff {
\key g\major
fis'
fis'?
fis'!
}

?


-Harm

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

Re: new to lilypond

[Andrew Bernard]

Greetings,

   	   
   	James Harkins  
  20 August 2013 
12:31 AM
  I'll
 be bold and disagree. G-flat is ges in Dutch (3 characters) and gf in English
 (2 characters). If you're typesetting a piece in D-flat major, the 33% redundancy
 for every black-key note in Dutch will add up quickly.

Avoid D flat major. :-)

  
They take up space but don't /do/ anything in return 
for the extra finger effort. 

  

But they _do_ do something in Nederlands for people whose language it 
is.

Each to his own - the beauty of lilypond.

Andrew


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

Re: maintaining advanced power-user Scheme functions

[Phil Holmes]

2013/8/19 Phil Holmes m...@philholmes.net:


This will be my last post on this.



> - Original Message - From: "Janek Warchol"
> 
>> 2013/8/19 Phil Holmes :
>> > However, my other opposition to git for this
>> > purpose is that it's intended as a Version Control system, which is
>> > completely unnecessary for the LSR - that's just a simple database of 
>> >  >

>> > text,
>> > with no version control needed.
>>
>> Someone once said "if you have a project and it will take you more
>> than an hour to recreate it from scratch, it should be under version
>> control".
>> It may not be apparent why this is so, but the experience confirms it.
>
> The LSR is not a project, it's a collection of text objects. A simple
> database is the best place for a collection of text objects.

Nonsense. I have a collection of lilypond scores (more than a
hundred) in a git repository and it's working perfectly, and i have
actually used version control features on that collection of scores.
I.e. i did things that would be impossible to do without version
control.
Besides, look at Mutopia (it's a collection of text objects as well -
i mean, the pieces are independent from each other). Or ask power
users such as Nicolas, who has his scores under version control.

What you said would be true if the snippets were so simple that they
never change. But they do change.


Hardly ever.  I maintain the current LSR and the changes are so infrequent I 
often forget to check whether there are any.  This is part of the problem 
with your proposing changes - you admit you don't use the LSR, don't know 
how it works, don't know how to do simple updates, but you're proposing 
wholescale change.  Please try the current system before trying to make 
large changes to it.



>> > If you would actually try the LSR, you'll see it's equally quick to >
>> > enter
>> > snippets - each takes a few seconds or a minute at most. All that you 
>> >  >

>> > need
>> > to do is type the snippet (or paste it) and a description - you can't 
>> > do

>> > _less_ with any other system.
>>
>> Can i do it offline?
>
> You can't update any remote system offline - git or the LSR.

but with git i can do everything that matters offline - add new stuff,
fix stuff, search old versions, etc. Then i just press a button and
it does the rest.
Imagine that i'm working on a big project w/o internet access (because
i'm on holidays) and i create a few snipets. Do you think i'll
remember them when i get back online? Definitely no! I will only
care to add them to the repository when i'm actually working on the
stuff, not a week later.


You could consider a text editor to create the snippets offline, giving them 
sensible names in a directory you can remember, and pasting them when you're 
online.



> What you've described there is a set of odd bits of code that are badly
> structured and with no clear idea of what they do ("chaos here" is not 
> good
> documentation practice). Putting them in a git repo would not make them 
> any
> more suitable for our documentation system than putting them in the LSR. 
> For

> your own use - fine.

What's funny is that this description fits out issue tracker quite
accurately. It's a set of odd bits of code, usually with no clear
idea what they do (i mean, usually we can see that the output is
wrong, but we don't know what actually happens inside - if we knew,
many more bugs would be fixed instantly after submitting). And they
are not structured in any way.
Yet we keep them, because they contain some valuable information and
it's better to have some information rather than none at all.
Moreover, we have a policy to add issues to the tracker quite freely,
i mean - when someone posts something wrong, we don't analyze it
trying to find connections with other issues, but we just throw it in.
It may be marked as duplicate later.

Yet this system seems to work quite well.


Because it's designed to work as a way of remembering odd bits of 
information, not as a way of documenting how LilyPond works.  The LSR is 
part of the LilyPond documentation system that users can access and read. 
It must be an accurate set of information and that's how it currently works.



> The LSR is intended to allow non-power users the ability to contribute
> lilypond code to other users and potentially our documentation. As such, 
> it
> performs a useful service. I cannot imagine why you want to go to all 
> the

> work of reimplmenting something that fundamentally works using completly
> different technology. It would be a massive waste of time.

Well, as for "completely different technology", that's not necessarily
what i propose. Using git as the tool to manage the actual *content*
doesn't have to mean changing thee tools that operate on that content.
Why do i want to do this? Because the current system is limited: we
don't have support for more than one lily version, upgrading is
inconvenient, and there are no convenient ways to add some valuable
stuff there

Re:

[Tommaso Gordini]

Sorry, I meant increasing and waning harmonics :-)

Ciao
Tommaso

Il giorno lunedì 19 agosto 2013, Tommaso Gordini 
ha scritto:
> Hello to all,
> here's a minimal code:
> %%
>
> \version "2.16.2"
>
> \relative c {
>
> \clef "bass"
>
> \key c \major
>
> \cadenzaOn
>
> c,2
>
> ^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
>
> ^\markup {\small { Corno in Fa } }
>
> c' \clef "treble" g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c
>
> \cadenzaOff \bar "||"
>
> }
>
> \layout {
>
> \context {
>
> \Staff \remove "Time_signature_engraver"
>
> }
>
> }
>
> %%
> The quarter notes marked with '-' are waning, quarter notes marked with
'' are increasing. What is the correct way to indicate it? I tried to draw
the arrows, but I could not do it.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 Phil Holmes :
> - Original Message - From: "Janek Warchoł"
> 
>> 2013/8/19 Phil Holmes :
>> > However, my other opposition to git for this
>> > purpose is that it's intended as a Version Control system, which is
>> > completely unnecessary for the LSR - that's just a simple database of >
>> > text,
>> > with no version control needed.
>>
>> Someone once said "if you have a project and it will take you more
>> than an hour to recreate it from scratch, it should be under version
>> control".
>> It may not be apparent why this is so, but the experience confirms it.
>
> The LSR is not a project, it's a collection of text objects.  A simple
> database is the best place for a collection of text objects.

Nonsense.  I have a collection of lilypond scores (more than a
hundred) in a git repository and it's working perfectly, and i have
actually used version control features on that collection of scores.
I.e. i did things that would be impossible to do without version
control.
Besides, look at Mutopia (it's a collection of text objects as well -
i mean, the pieces are independent from each other).  Or ask power
users such as Nicolas, who has his scores under version control.

What you said would be true if the snippets were so simple that they
never change. But they do change.

>> > If you would actually try the LSR, you'll see it's equally quick to >
>> > enter
>> > snippets - each takes a few seconds or a minute at most. All that you >
>> > need
>> > to do is type the snippet (or paste it) and a description - you can't do
>> > _less_ with any other system.
>>
>> Can i do it offline?
>
> You can't update any remote system offline - git or the LSR.

but with git i can do everything that matters offline - add new stuff,
fix stuff, search old versions, etc.  Then i just press a button and
it does the rest.
Imagine that i'm working on a big project w/o internet access (because
i'm on holidays) and i create a few snipets.  Do you think i'll
remember them when i get back online?  Definitely no!  I will only
care to add them to the repository when i'm actually working on the
stuff, not a week later.

>> > What do you find so time-consuming?
>>
>> with current system, as far as i know, i would have to check all these
>> snippets to make sure that they compile with required LilyPond
>> version, and also i don't know of a way to add 'experimental'
>> snippets. For example, i'm doing something and i find an interesting
>> solution, but it only works with current git master and is somewhat
>> hackish - but still useful, at least for advanced users. I'd like to
>> be able to add it under some "draft" or "experimental" category.
>> This isn't related to git, actually - although using git makes
>> everything more maintainable in my experience. For example, i could
>> have my own branch containing some private snippets, and easily merge
>> them when they're ready. Also, assume that i grab all these snippets
>> from my emails and paste them into one big "chaos here" folder (i
>> believe that it's better to have unfinished stuff saved somewhere -
>> just clearly separated from the "clean" stuff - rather than don't have
>> it at all). Having git underneath would be a safety net if someone
>> decides that this wasn't actually a good idea to paste all that stuff
>> there.
>
>
> What you've described there is a set of odd bits of code that are badly
> structured and with no clear idea of what they do ("chaos here" is not good
> documentation practice).  Putting them in a git repo would not make them any
> more suitable for our documentation system than putting them in the LSR. For
> your own use - fine.

What's funny is that this description fits out issue tracker quite
accurately.  It's a set of odd bits of code, usually with no clear
idea what they do (i mean, usually we can see that the output is
wrong, but we don't know what actually happens inside - if we knew,
many more bugs would be fixed instantly after submitting).  And they
are not structured in any way.
Yet we keep them, because they contain some valuable information and
it's better to have some information rather than none at all.
Moreover, we have a policy to add issues to the tracker quite freely,
i mean - when someone posts something wrong, we don't analyze it
trying to find connections with other issues, but we just throw it in.
 It may be marked as duplicate later.

Yet this system seems to work quite well.

> The LSR is intended to allow non-power users the ability to contribute
> lilypond code to other users and potentially our documentation.  As such, it
> performs a useful service.  I cannot imagine why you want to go to all the
> work of reimplmenting something that fundamentally works using completly
> different technology.  It would be a massive waste of time.

Well, as for "completely different technology", that's not necessarily
what i propose.  Using git as the tool to manage the actual *content*
doesn't have to mean changing thee tools that 

Re: maintaining advanced power-user Scheme functions

[David Kastrup]

Urs Liska  writes:

> David Kastrup  schrieb:
>
>>Urs Liska  writes:
>>
>>> Version control _can_ be useful for a collection like the LSR. Think
>>> of providing snippets for more than one LilyPond version. If I'm
>>using
>>> 2.16 I will download a different snippet than for 2.17.24 ...
>>
>>But that's not what version control is for.  Version control does not
>>fundamentally work with a series of codependent equally active HEADs,
>>but rather has one principal HEAD of development, and historic
>>references (quite likely containing _inferior_ code, and inferior for
>>reasons that are often only marginally related to the LilyPond
>>version).
>
> I think developing input files to keep up with LilyPond versions _is_
> natural to Git. Snippet versions which are compatible to a certain
> older version of LilyPond are legitimate 'historic references'.
>
> Accessing them in parallel isn't natural, that's right. But it could
> be made manageable. On Github for example you can access files on
> different branches through different url paths.

Ok, so we have a branch for version 2.17.2, a branch for 2.17.3, a
branch for 2.17.4, a branch for 2.17.5 ...  Now I update a snippet for
the 2.17.4 branch.  How will the update percolate to the branches
2.17.5...2.17.25?  Basically, an automatic procedure would try to run
convert-ly repeatedly and check everything in that has not been
superseded by a manual checkin: after all, if I have replaced the
snippet in 2.17.20, the replacement should most likely stick around.  Or
not: might be worth to flag an "update conflict" and wait for human
resolution like a rebase does.

> I don't want to say that it's dead easy, though ...

Yup.

-- 
David Kastrup


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

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 Janek Warchoł :
> 2013/8/19 David Kastrup :
>> Urs Liska  writes:
>>
>>> Version control _can_ be useful for a collection like the LSR. Think
>>> of providing snippets for more than one LilyPond version. If I'm using
>>> 2.16 I will download a different snippet than for 2.17.24 ...
>>
>> But that's not what version control is for.  Version control does not
>> fundamentally work with a series of codependent equally active HEADs,
>> but rather has one principal HEAD of development, and historic
>> references (quite likely containing _inferior_ code, and inferior for
>> reasons that are often only marginally related to the LilyPond version).
>
> That's true.
> However, i think that it ultimately /makes sense/ with LSR.  Look at
> it this way:
> 1) let's say Lilypond 2.18 is released and all snippets are upgraded
> to work with it.  This is the master branch (what's visible by default
> via the web interface), and it gets a tag "state as of 2.18 release".
> 2) LilyPond is continues to be developed in 2.19 series.  People
> occasionally write new snippets that require 2.19 (or update existing
> ones from 2.18 to 2.19) - commits doing this do to a separate
> "develop" branch, and are not visible by default via the web
> interface, but advanced users can easily access them.  This is the
> "improvement" part, as one upgrades a snippet to 2.19 precisely
> because it will work better.
> 3) at the same time, new snippets that work with the 2.18 release are
> added (and some snippets are improved), and this goes to the master
> branch.
> 4) when lilypond 2.20 is released, master and develop branches are merged.
> 5) the circle starts again.

There's one thing to realize: we wouldn't need to have a branch for
every Lilypond version there.  We would just need two branches:
current stable and stuff that is ahead of current stable.  Very much
like how various projects are developed.
And still, if someone needed to access a version of the snippet meant
for a parrticular verison of lilypond, it would be easy to do this
thanks to git.

Janek

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

Re: new to lilypond

[James Harkins]

Phil Holmes  philholmes.net> writes:

> I think a lot of us simply use the Dutch standard of es for a flat and is 
> for a sharp - I certainly do.

I'll be bold and disagree. G-flat is ges in Dutch (3 characters) and gf in 
English (2 characters). If you're typesetting a piece in D-flat major, the 33% 
redundancy for every black-key note in Dutch will add up quickly.

I've been dealing with repetitive strain injuries for more than half my life 
now, so I have a rather strong aversion toward extra symbols, such as the "s" 
in -es and -is, which are identical between flats and sharps and thereby do 
nothing to distinguish them. They take up space but don't /do/ anything in 
return for the extra finger effort. If I were forced to type them, I would 
seek another input method. Fortunately I can just set the language to English 
and then enjoy more efficient input.

(For longer keywords, Frescobaldi's auto-completion is a lifesaver.)

hjh


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

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 David Kastrup :
> Urs Liska  writes:
>
>> Version control _can_ be useful for a collection like the LSR. Think
>> of providing snippets for more than one LilyPond version. If I'm using
>> 2.16 I will download a different snippet than for 2.17.24 ...
>
> But that's not what version control is for.  Version control does not
> fundamentally work with a series of codependent equally active HEADs,
> but rather has one principal HEAD of development, and historic
> references (quite likely containing _inferior_ code, and inferior for
> reasons that are often only marginally related to the LilyPond version).

That's true.
However, i think that it ultimately /makes sense/ with LSR.  Look at
it this way:
1) let's say Lilypond 2.18 is released and all snippets are upgraded
to work with it.  This is the master branch (what's visible by default
via the web interface), and it gets a tag "state as of 2.18 release".
2) LilyPond is continues to be developed in 2.19 series.  People
occasionally write new snippets that require 2.19 (or update existing
ones from 2.18 to 2.19) - commits doing this do to a separate
"develop" branch, and are not visible by default via the web
interface, but advanced users can easily access them.  This is the
"improvement" part, as one upgrades a snippet to 2.19 precisely
because it will work better.
3) at the same time, new snippets that work with the 2.18 release are
added (and some snippets are improved), and this goes to the master
branch.
4) when lilypond 2.20 is released, master and develop branches are merged.
5) the circle starts again.

Janek

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

Re: How to avoid that it appears the new key with a key change at the end of stave

[Eluze]

Eluze wrote
> Am 19.08.2013 15:56, schrieb Tommaso Gordini:
>> Hello to all,
>> I would like to avoid that the new key appears when I have a key change
>> at
>> the end of the staff. I tried it in the documentation, but I could not
>> find
>> what I need.
>>
> do you mean:
> 
> \layout {
>\context {
>  printKeyCancellation = ##f
>}
> }
> 
> Eluze
> 
> sorry, forgot to add the context \Staff above
> 
> anyway, this will only suppress the cancellation of keys - see Harms
> solution for suppressing the whole key at the end of line
> 
> Eluze
> ___
> lilypond-user mailing list

> lilypond-user@

> https://lists.gnu.org/mailman/listinfo/lilypond-user





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-avoid-that-it-appears-the-new-key-with-a-key-change-at-the-end-of-stave-tp149454p149460.html
Sent from the User mailing list archive at Nabble.com.

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

Re: maintaining advanced power-user Scheme functions

[Phil Holmes]

- Original Message - 
From: "Janek Warchoł" 

To: "Phil Holmes" 
Cc: "Thomas Morley" ; "lilypond-user" 
; "Phil Hézaine" ; "David 
Nalesnik" ; "LilyPond Developmet Team" 


Sent: Monday, August 19, 2013 3:17 PM
Subject: Re: maintaining advanced power-user Scheme functions



Hi,

some things were already answered by other people

2013/8/19 Phil Holmes :
> - Original Message - From: "Janek Warchol"
>> A valid concern, but i have a counterargument: there is a web
>> interface for git that allows you to copy-and-paste code directly in,
>> or alternatively to type it directly in. Both are quite simple and
>> quick. This doesn't require installing a new program and learning how
>> to use it.
>>
>> It's github.
>
> I've never used the web interface, but I'm prepared to believe it's 
> quick

> and easy if you say it is. However, my other opposition to git for this
> purpose is that it's intended as a Version Control system, which is
> completely unnecessary for the LSR - that's just a simple database of 
> text,

> with no version control needed.

Someone once said "if you have a project and it will take you more
than an hour to recreate it from scratch, it should be under version
control".
It may not be apparent why this is so, but the experience confirms it.


The LSR is not a project, it's a collection of text objects.  A simple 
database is the best place for a collection of text objects.


> If you would actually try the LSR, you'll see it's equally quick to 
> enter
> snippets - each takes a few seconds or a minute at most. All that you 
> need

> to do is type the snippet (or paste it) and a description - you can't do
> _less_ with any other system.

Can i do it offline?


You can't update any remote system offline - git or the LSR.


> What do you find so time-consuming?

with current system, as far as i know, i would have to check all these
snippets to make sure that they compile with required LilyPond
version, and also i don't know of a way to add 'experimental'
snippets. For example, i'm doing something and i find an interesting
solution, but it only works with current git master and is somewhat
hackish - but still useful, at least for advanced users. I'd like to
be able to add it under some "draft" or "experimental" category.
This isn't related to git, actually - although using git makes
everything more maintainable in my experience. For example, i could
have my own branch containing some private snippets, and easily merge
them when they're ready. Also, assume that i grab all these snippets
from my emails and paste them into one big "chaos here" folder (i
believe that it's better to have unfinished stuff saved somewhere -
just clearly separated from the "clean" stuff - rather than don't have
it at all). Having git underneath would be a safety net if someone
decides that this wasn't actually a good idea to paste all that stuff
there.


What you've described there is a set of odd bits of code that are badly 
structured and with no clear idea of what they do ("chaos here" is not good 
documentation practice).  Putting them in a git repo would not make them any 
more suitable for our documentation system than putting them in the LSR. 
For your own use - fine.


The LSR is intended to allow non-power users the ability to contribute 
lilypond code to other users and potentially our documentation.  As such, it 
performs a useful service.  I cannot imagine why you want to go to all the 
work of reimplmenting something that fundamentally works using completly 
different technology.  It would be a massive waste of time.


--
Phil Holmes 



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

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

Hi,

some things were already answered by other people

2013/8/19 Phil Holmes :
> - Original Message - From: "Janek Warchoł"
>> A valid concern, but i have a counterargument: there is a web
>> interface for git that allows you to copy-and-paste code directly in,
>> or alternatively to type it directly in. Both are quite simple and
>> quick. This doesn't require installing a new program and learning how
>> to use it.
>>
>> It's github.
>
> I've never used the web interface, but I'm prepared to believe it's quick
> and easy if you say it is.  However, my other opposition to git for this
> purpose is that it's intended as a Version Control system, which is
> completely unnecessary for the LSR - that's just a simple database of text,
> with no version control needed.

Someone once said "if you have a project and it will take you more
than an hour to recreate it from scratch, it should be under version
control".
It may not be apparent why this is so, but the experience confirms it.

>> What if the things i pointed out make it hard to maintain?
>> I'd just like to point this out:
>> - with current system, i know that i'm not going to help with updating
>> LSR. If i had more time, i'd gladly do that, but i don't have.
>> However, if it was independent from LilyPond version - i.e. updating
>> one snippet means that the update becomes instantly visible, because
>> updating isn't an all-or-nothing deal - i would gladly update some
>> snippets from time to time, if it could be done "via git".
>> - i have some valuable snippets and templates myself, and i'd like to
>> share them, but i don't see how they could fit with current LSR
>> system.
>> - i have 79 emails marked "valuable snippet". Adding them to LSR (the
>> way it works currently) would require a lot of work, and i don't have
>> time for this. But if the LSR worked another way, i could do
>> something about it.
>
> If you would actually try the LSR, you'll see it's equally quick to enter
> snippets - each takes a few seconds or a minute at most.  All that you need
> to do is type the snippet (or paste it) and a description - you can't do
> _less_ with any other system.

Can i do it offline?

> What do you find so time-consuming?

with current system, as far as i know, i would have to check all these
snippets to make sure that they compile with required LilyPond
version, and also i don't know of a way to add 'experimental'
snippets.  For example, i'm doing something and i find an interesting
solution, but it only works with current git master and is somewhat
hackish - but still useful, at least for advanced users.  I'd like to
be able to add it under some "draft" or "experimental" category.
This isn't related to git, actually - although using git makes
everything more maintainable in my experience.  For example, i could
have my own branch containing some private snippets, and easily merge
them when they're ready.  Also, assume that i grab all these snippets
from my emails and paste them into one big "chaos here" folder (i
believe that it's better to have unfinished stuff saved somewhere -
just clearly separated from the "clean" stuff - rather than don't have
it at all).  Having git underneath would be a safety net if someone
decides that this wasn't actually a good idea to paste all that stuff
there.

best,
Janek

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

Re: How to avoid that it appears the new key with a key change at the end of stave

[Thomas Morley]

2013/8/19 Tommaso Gordini :
> Hello to all,
> I would like to avoid that the new key appears when I have a key change at
> the end of the staff. I tried it in the documentation, but I could not find
> what I need.
>
> Can you help me?
>
> Ciao
> Tommaso



See:
http://lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects.it.html#special-considerations

Example:

\version "2.16.2"

% Better put the commands in layout
\layout {
\context {
\Staff
\override KeySignature #'break-visibility = ##(#f #t #t)
\override KeyCancellation #'break-visibility = ##(#f #t #f)
explicitKeySignatureVisibility = #'#(#f #t #t)
}
}

\relative c' {
\key cis\major
cis'1
\break
\key ces\major
ces'1
}

HTH,
  Harm

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

Re: How to avoid that it appears the new key with a key change at the end of stave

[Eluze]

Am 19.08.2013 15:56, schrieb Tommaso Gordini:

Hello to all,
I would like to avoid that the new key appears when I have a key change at
the end of the staff. I tried it in the documentation, but I could not find
what I need.


do you mean:

\layout {
  \context {
printKeyCancellation = ##f
  }
}

Eluze

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

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 Werner LEMBERG :
>> Well, one question may be whether git could be an alternate
>> interface into the LSR.  In a limited manner, it already is
>> (snippets migrate back from LilyPond git repository into the LSR).
>
> Actually, I like the idea of using git for the LSR *as the storage*.
> Experienced cann access it directly, and maybe a simple HTML interface
> can be added.

That's what i meant - store LSR data in a repository, and have some
interface for accessing it, similar to current one.

Janek

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

Re:

[Phil Holmes]

http://lilypond.org/doc/v2.16/Documentation/learning/accidentals-and-key-signatures.it.html

--
Phil Holmes


  - Original Message - 
  From: Tommaso Gordini 
  To: lilypond-user@gnu.org 
  Sent: Monday, August 19, 2013 2:51 PM


  Hello to all,
  here's a minimal code:


  %%


  \version "2.16.2"







  \relative c {

  \clef "bass"

  \key c \major

  \cadenzaOn

  c,2

  ^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }

  ^\markup {\small { Corno in Fa } } 

  c' \clef "treble" g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4-- bes-+ 
b2 c

  \cadenzaOff \bar "||"

  }



  \layout {

  \context {

  \Staff \remove "Time_signature_engraver"

  }

  }

  %%


  The quarter notes marked with '-' are waning, quarter notes marked with '' 
are increasing. What is the correct way to indicate it? I tried to draw the 
arrows, but I could not do it.


--


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

How to avoid that it appears the new key with a key change at the end of stave

[Tommaso Gordini]

Hello to all,
I would like to avoid that the new key appears when I have a key change at
the end of the staff. I tried it in the documentation, but I could not find
what I need.

Can you help me?

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

Enter correctly flat and sharp notes

[Tommaso Gordini]

Hello to all,
here's a minimal code:

%%

\version "2.16.2"



\relative c {

\clef "bass"

\key c \major

\cadenzaOn

c,2

^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }

^\markup {\small { Corno in Fa } }

c' \clef "treble" g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c

\cadenzaOff \bar "||"

}

\layout {

\context {

\Staff \remove "Time_signature_engraver"

}

}
%%

The quarter notes marked with '-' are flat, quarter notes marked with ''
are sharp. What is the correct way to indicate it? I tried to draw the
arrows, but I could not do it.

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

[no subject]

[Tommaso Gordini]

Hello to all,
here's a minimal code:

%%

\version "2.16.2"



\relative c {

\clef "bass"

\key c \major

\cadenzaOn

c,2

^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }

^\markup {\small { Corno in Fa } }

c' \clef "treble" g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c

\cadenzaOff \bar "||"

}

\layout {

\context {

\Staff \remove "Time_signature_engraver"

}

}
%%

The quarter notes marked with '-' are waning, quarter notes marked with ''
are increasing. What is the correct way to indicate it? I tried to draw the
arrows, but I could not do it.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Stanza is displaying at bottom of score

[Jethro Van Thuyne]

Perfect, thank you so much!

Jethro

Phil Holmes (19 Aug 2013 @ 15:36)
- Original Message - From: "Jethro Van Thuyne" 


To: 
Sent: Monday, August 19, 2013 2:25 PM
Subject: Stanza is displaying at bottom of score



In the following minimal example, a repeated stanza is showing up
under the PianoStaff. Of course, I would need it to be under the
first stanza, above the PianoStaff. Am I missing some setting,
how can I fix this? Any help much appreciated :)


You need to adjust it like this:

\new Lyrics = "FirstVerse" \lyricsto "melody" {
Not re -- peat -- ed.
<<
{ The first time words. }
\new Lyrics \with { alignBelowContext = #"FirstVerse" } {
\set associatedVoice = "melody"
Sec -- ond time words.
}



}



This is in the NR, a little further on from the place you presumably 
got the first bit of code.


If you'd used different rhythms in the "piano" and voice, it would 
have given the clue that it was a placement issue, not relating to 
the note rhythms.


--
Phil Holmes


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

Re: Stanza is displaying at bottom of score

[Phil Holmes]

- Original Message - 
From: "Jethro Van Thuyne" 

To: 
Sent: Monday, August 19, 2013 2:25 PM
Subject: Stanza is displaying at bottom of score



In the following minimal example, a repeated stanza is showing up
under the PianoStaff. Of course, I would need it to be under the
first stanza, above the PianoStaff. Am I missing some setting,
how can I fix this? Any help much appreciated :)


You need to adjust it like this:

\new Lyrics = "FirstVerse" \lyricsto "melody" {
Not re -- peat -- ed.
<<
{ The first time words. }
\new Lyrics \with { alignBelowContext = #"FirstVerse" } {
\set associatedVoice = "melody"
Sec -- ond time words.
}



}



This is in the NR, a little further on from the place you presumably got the 
first bit of code.


If you'd used different rhythms in the "piano" and voice, it would have 
given the clue that it was a placement issue, not relating to the note 
rhythms.


--
Phil Holmes 



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

Re: maintaining advanced power-user Scheme functions

[Urs Liska]

David Kastrup  schrieb:

>Urs Liska  writes:
>
>> Version control _can_ be useful for a collection like the LSR. Think
>> of providing snippets for more than one LilyPond version. If I'm
>using
>> 2.16 I will download a different snippet than for 2.17.24 ...
>
>But that's not what version control is for.  Version control does not
>fundamentally work with a series of codependent equally active HEADs,
>but rather has one principal HEAD of development, and historic
>references (quite likely containing _inferior_ code, and inferior for
>reasons that are often only marginally related to the LilyPond
>version).

I think developing input files to keep up with LilyPond versions _is_ natural 
to Git. Snippet versions which are compatible to a certain older version of 
LilyPond are legitimate 'historic references'.

Accessing them in parallel isn't natural, that's right. But it could be made 
manageable. On Github for example you can access files on different branches 
through different url paths.

I don't want to say that it's dead easy, though ...

Urs
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Stanza is displaying at bottom of score

[Jethro Van Thuyne]

In the following minimal example, a repeated stanza is showing up
under the PianoStaff. Of course, I would need it to be under the
first stanza, above the PianoStaff. Am I missing some setting,
how can I fix this? Any help much appreciated :)

Kind regards,

Jethro

Screenshot: 
http://jethro.be/upload/sc_stanzas.png


Minimal example:
\version "2.17.24"
\score {
  <<
\new Staff {
  \new Voice = "melody" {
\relative c'' {
  a4 a a a
  \repeat volta 2 { b4 b b b }
}
  }
}
\new Lyrics \lyricsto "melody" {
  Not re -- peat -- ed.
  <<
{ The first time words. }
\new Lyrics {
  \set associatedVoice = "melody"
  Sec -- ond time words.
}
  >>
}
\new PianoStaff
{
  << { a b c d c d e f } { a b c c c d e f } >>
}
  >>
}

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

Re: new to lilypond

[Phil Holmes]

- Original Message - 
From: "Stephanie" 

To: 
Sent: Monday, August 19, 2013 1:30 PM
Subject: new to lilypond



Hi all,


Hi, Stephanie,


I am new to lilypond and have a few basic questions.
1) are there other blind lilypond users?


We have had a number of other blind users, who have been active on the user 
list in the past, but I've not seen contributions from them recently.



2) how do i write accidentals in english.
Steph



I think a lot of us simply use the Dutch standard of es for a flat and is 
for a sharp - I certainly do.  According to the Notation Reference, f is a 
flat in English and s is a sharp (makes sense).


--
Phil Holmes 



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

Re: new to lilypond

[Thomas Morley]

2013/8/19 Stephanie :
> Hi all,
> I am new to lilypond and have a few basic questions.

Hi Stephanie,

welcome!

> 1) are there other blind lilypond users?
Yes
> 2) how do i write accidentals in english.
Try one of this settings in your file:
\language "english"
or
\include "english.ly"
> Steph


Cheers,
  Harm

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

Re: new to lilypond

[Andrew Bernard]

Greetings,

\language "english

Then -s for sharp and -f for flat. [Leave out the dashes.]

Interestingly, myself and I know many others, prefer the Nederlands -es 
and -is.

See the manual section 1.1.1.

I think there are some other blind users on the list...

Andrew


   	   
   	Stephanie  
  19 August 2013 
10:30 PM
  Hi all,
I am new to lilypond and have a few basic questions.
1) are there other blind lilypond users?
2) how do i write accidentals in english.
Steph




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

Re: new to lilypond

[David Kastrup]

Stephanie  writes:

> Hi all,
> I am new to lilypond and have a few basic questions.
> 1) are there other blind lilypond users?

I know about three who have occasionally posted to the list.  I don't
think any of them is a regular reader of the list, probably because
managing the high volume is even harder when you are blind.

> 2) how do i write accidentals in english.

Try the link
http://www.lilypond.org/doc/v2.16/Documentation/notation/writing-pitches#note-names-in-other-languages>

hopefully you have a web browser delivering a useful rendition of that
link.  If not, report back.

Basically, you tack on s for "sharp" and ss or x for "double sharp", and
f for "flat" and ff for "double flat".

Note that the default note language is _not_ English but rather Dutch.

-- 
David Kastrup


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

Re: maintaining advanced power-user Scheme functions

[Werner LEMBERG]

> Well, one question may be whether git could be an alternate
> interface into the LSR.  In a limited manner, it already is
> (snippets migrate back from LilyPond git repository into the LSR).

Actually, I like the idea of using git for the LSR *as the storage*.
Experienced cann access it directly, and maybe a simple HTML interface
can be added.

> Using git for managing snippets corresponding to different versions
> of LilyPond is likely a tool mismatch.  git is more slated for
> maintaining a development of improvements.

Do you know something better?  On the other hand, branches are very
cheap in git, and having separate branches for different lilypond
versions is straightforward, I think.


Werner

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

Re: maintaining advanced power-user Scheme functions

[David Kastrup]

Urs Liska  writes:

> Version control _can_ be useful for a collection like the LSR. Think
> of providing snippets for more than one LilyPond version. If I'm using
> 2.16 I will download a different snippet than for 2.17.24 ...

But that's not what version control is for.  Version control does not
fundamentally work with a series of codependent equally active HEADs,
but rather has one principal HEAD of development, and historic
references (quite likely containing _inferior_ code, and inferior for
reasons that are often only marginally related to the LilyPond version).

-- 
David Kastrup


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

new to lilypond

[Stephanie]

Hi all,
I am new to lilypond and have a few basic questions.
1) are there other blind lilypond users?
2) how do i write accidentals in english.
Steph

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

Re: maintaining advanced power-user Scheme functions

[Urs Liska]

Am 19.08.2013 12:38, schrieb Phil Holmes:
I think making it version independent might be easier to wish for than 
to provide!
I believe the source code is available if you'd like to try getting it 
running on alternative infrastructure and updating it:

http://lsr.dsi.unimi.it/download/

--
Phil Holmes


I've downloaded it.
Java isn't my first language. But I will have a look at it. It should be 
possible to realize such a thing, parsing the source for a version 
string, identifying an appropriate LilyPond version and use _that_ to 
compile the snippet.


Urs


- Original Message -
*From:* Urs Liska 
*To:* Janek Warcho?  ; Phil
Holmes 
*Cc:* LilyPond Developmet Team  ;
Thomas Morley  ; David Nalesnik
 ; lilypond-user

*Sent:* Monday, August 19, 2013 11:21 AM
*Subject:* Re: maintaining advanced power-user Scheme functions

One thing I'd definitely support about this is making LSR somewhat
version independent to allow one to have snippets requiring new
lily versions.
Maybe providing several lily versions (not necessarily _all_ of
course) and use an appropriate one to compile the snippets. This
would also allow us to keep 'old' snippets without updating all to
current lily syntax before being able to upgrade the whole LSR.
Maybe something like running convert-ly over all snippets when a
new stable release comes out and leave snippets that can't be
upgraded automatically for older versions?

Urs

PS: I'd also second the idea of hosting lilypond on a more
accessible server (if that doesn't imply complicated
side-effects). It is so easy to create a fork and open a pull
request, I'm sure such a step would increase the number of
contributions by people who can't or won't go through some
undefined and possibly complex process of 'becoming a developer'



"Janek Warcho?"  schrieb:

2013/8/19 Phil Holmes :

- Original Message - From: "Janek Warcho?"

After some thinking, i came to the conclusion that LSR
should be redesigned. Fristly, it should be a git
repository, to make collaboration easy - when
something's a git repository, i have a habit of
contributing stuff there on every opportunity, because
even if i do something wrong i can undo this.

I'd guess you're in a minority of about 1% of users who
would prefer using git to using a web interface. The
current web interface allows you to copy-and-paste code
directly in, or alternatively to type it directly in. Both
are simple and quick. To use git propoerly requires
installing a new program and learning how to use it.
Remember yesterday when you recommended a whole book about
how it's used? If that doesn't put off casual
contributors, nothing will. I started work on LilyPond by
adding regtests to the LSR. If git had been required, I
wouldn't have done so.


A valid concern, but i have a counterargument: there is a web
interface for git that allows you to copy-and-paste code directly in,
or alternatively to type it directly in. Both are quite simple and
quick.  This doesn't require installing a new program and learning how
to use it.

It's github.

I've just checked and made a couple commits using that web interface.
Plain and simple, *with* all the advantages of git underneath.  Of
course i may be biased, so i invite you to check this with me.  I
believe that i will
be able to explain everything that's needed in
5-10 minutes.  Would you like to try?

Actually, i believe that it would be good to have lilypond repository
on github, so that new contributors would be able to create patches
easily.  They wouldn't have to install a virtual machine with Lilydev.
Found a typo in documentation?  Create a fix and submit it in *2
minutes.*

Secondly, i think that it shouldn't depend on any
particular lilypond version - in fact, it shouldn't
actually run any lilypond in my opinion. I believe
that LSR should hold both snippets' code and their
output, with lilypond version clearly stated, and thus
allow to post snippets for any lilypond version. It
would just be a collection of snippets.

The benefit of it running LilyPond is that it shows the
result of the code on the fly - no need to create and
upload images. This is 

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 Urs Liska :
> PS: I'd also second the idea of hosting lilypond on a more accessible server
> (if that doesn't imply complicated side-effects). It is so easy to create a
> fork and open a pull request, I'm sure such a step would increase the number
> of contributions by people who can't or won't go through some undefined and
> possibly complex process of 'becoming a developer'

/moving/ main lilypond repository from savannah to github would
probably be a big nuisance and can possibly have lots of side-effects.
  However, nothing prevents us from creating a fork on github (acually
i have one already).  The thing is, would it be maintained?  That
could probably be done with some scripts.  I'd gladly help if there's
interest.

Janek

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

Re: maintaining advanced power-user Scheme functions

[Urs Liska]

Am 19.08.2013 12:25, schrieb Phil Holmes:
- Original Message - From: "Janek Warchoł" 


To: "Phil Holmes" 
Cc: "Thomas Morley" ; "lilypond-user" 
; "Phil Hézaine" ; 
"David Nalesnik" ; "LilyPond Developmet 
Team" 

Sent: Monday, August 19, 2013 11:02 AM
Subject: Re: maintaining advanced power-user Scheme functions



2013/8/19 Phil Holmes :
> > - Original Message - From: "Janek"
>> After some thinking, i came to the conclusion that LSR should be
>> redesigned.
>> Fristly, it should be a git repository, to make collaboration easy -
>> when something's a git repository, i have a habit of contributing
>> stuff there on every opportunity, because even if i do something 
wrong

>> i can undo this.
>
> I'd guess you're in a minority of about 1% of users who would 
prefer > using

> git to using a web interface. The current web interface allows you to
> copy-and-paste code directly in, or alternatively to type it 
directly > in.
> Both are simple and quick. To use git propoerly requires installing 
a > new
> program and learning how to use it. Remember yesterday when you > 
recommended

> a whole book about how it's used? If that doesn't put off casual
> contributors, nothing will. I started work on LilyPond by adding > 
regtests

> to the LSR. If git had been required, I wouldn't have done so.

A valid concern, but i have a counterargument: there is a web
interface for git that allows you to copy-and-paste code directly in,
or alternatively to type it directly in. Both are quite simple and
quick. This doesn't require installing a new program and learning how
to use it.

It's github.

I've just checked and made a couple commits using that web interface.
Plain and simple, *with* all the advantages of git underneath. Of
course i may be biased, so i invite you to check this with me. I
believe that i will be able to explain everything that's needed in
5-10 minutes. Would you like to try?


I've never used the web interface, but I'm prepared to believe it's 
quick and easy if you say it is.  However, my other opposition to git 
for this purpose is that it's intended as a Version Control system, 
which is completely unnecessary for the LSR - that's just a simple 
database of text, with no version control needed.


Version control _can_ be useful for a collection like the LSR. Think of 
providing snippets for more than one LilyPond version. If I'm using 2.16 
I will download a different snippet than for 2.17.24 ...



Actually, i believe that it would be good to have lilypond repository
on github, so that new contributors would be able to create patches
easily. They wouldn't have to install a virtual machine with Lilydev.
Found a typo in documentation? Create a fix and submit it in *2
minutes.*


And completely bu**er the make doc in the process.  That's what the 
issue tracker is for and why the patch control system exists.


That's not quite right. Github offers the concept of pull requests for 
exactly this purpose.
Opening a pull request on Github could have the same function like 
uploading a patch for review.





>> Secondly, i think that it shouldn't depend on any particular lilypond
>> version - in fact, it shouldn't actually run any lilypond in my
>> opinion. I believe that LSR should hold both snippets' code and their
>> output, with lilypond version clearly stated, and thus allow to post
>> snippets for any lilypond version. It would just be a collection of
>> snippets.
>
> The benefit of it running LilyPond is that it shows the result of 
the > code

> on the fly - no need to create and upload images. This is another
> significant benefit.

I'm not sure if i understand. Does LSR compile snippets every time i
open its webpage?
Anyway, i'm not saying that LSR shouldn't be able to run LilyPond,
just that it should not require this for operation.


It compiles the snippets every time one is changed, and stores the 
resultant images in clickable form.  Can git do that?


It also exports the snippets so that they can be imported into the 
documents - which git can't do.


_Git_ can be used for all this too.
But I doubt you could make Github work in this way.
I think in order to design a Git driven LSR variant you'd have to create 
a new web application on top of a self-hosted Git installation.


So I'm afraid this isn't an option currently (as I don't see who would 
be willing and able to dive into one more project right now).





>> I could elaborate on this topic, but as i don't have time to actually
>> do something about it it probably wouln't make sense (unless someone
>> wanted to lead such a change - then i would gladly help).
>
> It doesn't need much changing - the main problem is maintaining the 
web

> site.

What if the things i pointed out make it hard to maintain?
I'd just like to point this out:
- with current system, i know that i'm not going to help with updating
LSR. If i had more time, i'd gladly do that, but i don't have.
However, if it was independent from LilyPond version - i

Re: maintaining advanced power-user Scheme functions

[Phil Holmes]

I think making it version independent might be easier to wish for than to 
provide!

I believe the source code is available if you'd like to try getting it running 
on alternative infrastructure and updating it:

http://lsr.dsi.unimi.it/download/

--
Phil Holmes


  - Original Message - 
  From: Urs Liska 
  To: Janek Warchoł ; Phil Holmes 
  Cc: LilyPond Developmet Team ; Thomas Morley ; David Nalesnik ; lilypond-user 
  Sent: Monday, August 19, 2013 11:21 AM
  Subject: Re: maintaining advanced power-user Scheme functions


  One thing I'd definitely support about this is making LSR somewhat version 
independent to allow one to have snippets requiring new lily versions.
  Maybe providing several lily versions (not necessarily _all_ of course) and 
use an appropriate one to compile the snippets. This would also allow us to 
keep 'old' snippets without updating all to current lily syntax before being 
able to upgrade the whole LSR.
  Maybe something like running convert-ly over all snippets when a new stable 
release comes out and leave snippets that can't be upgraded automatically for 
older versions?

  Urs

  PS: I'd also second the idea of hosting lilypond on a more accessible server 
(if that doesn't imply complicated side-effects). It is so easy to create a 
fork and open a pull request, I'm sure such a step would increase the number of 
contributions by people who can't or won't go through some undefined and 
possibly complex process of 'becoming a developer'




  "Janek Warchoł"  schrieb:
2013/8/19 Phil Holmes :- Original Message - From: 
"Janek Warchoł"After some thinking, i came to the conclusion that LSR should 
beredesigned.Fristly, it should be a git repository, to make collaboration easy 
-when something's a git repository, i have a habit of contributingstuff there 
on every opportunity, because even if i do something wrongi can undo this.I'd 
guess you're in a minority of about 1% of users who would prefer usinggit to 
using a web interface.  The current web interface allows you tocopy-and-paste 
code directly in, or alternatively
to type it directly in.Both are simple and quick.  To use git propoerly 
requires installing a newprogram and learning how to use it.  Remember 
yesterday when you recommendeda whole book about how it's used?  If that 
doesn't put off casualcontributors, nothing will.  I started work on LilyPond 
by adding regteststo the LSR.  If git had been required, I wouldn't have done 
so.A valid concern, but i have a counterargument: there is a webinterface for 
git that allows you to copy-and-paste code directly in,or alternatively to type 
it directly in. Both are quite simple andquick.  This doesn't require 
installing a new program and learning howto use it.It's github.I've just 
checked and made a couple commits using that web interface.Plain and simple, 
*with* all the advantages of git underneath.  Ofcourse i may be biased, so i 
invite you to check this with me.  Ibelieve that i will
be able to explain everything that's needed in5-10 minutes.  Would you like to 
try?Actually, i believe that it would be good to have lilypond repositoryon 
github, so that new contributors would be able to create patcheseasily.  They 
wouldn't have to install a virtual machine with Lilydev.Found a typo in 
documentation?  Create a fix and submit it in *2minutes.*Secondly, i think that 
it shouldn't depend on any particular lilypondversion - in fact, it shouldn't 
actually run any lilypond in myopinion.  I believe that LSR should hold both 
snippets' code and theiroutput, with lilypond version clearly stated, and thus 
allow to postsnippets for any lilypond version.  It would just
be a collection ofsnippets.The benefit of it running LilyPond is that it shows 
the result of the codeon the fly - no need to create and upload images.  This 
is anothersignificant benefit.I'm not sure if i understand.  Does LSR compile 
snippets every time iopen its webpage?Anyway, i'm not saying that LSR shouldn't 
be able to run LilyPond,just that it should not require this for operation.I 
could elaborate on this topic, but as i don't have time to actuallydo something 
about it it probably wouln't make sense (unless someonewanted to lead such a 
change - then i would gladly help).It doesn't need much changing - the main 
problem is
maintaining the website.What if the things i pointed out make it hard to 
maintain?I'd just like to point this out:- with current system, i know that i'm 
not going to help with updatingLSR.  If i had more time, i'd gladly do that, 
but i don't have.However, if it was independent from LilyPond version - i.e. 
updatingone snippet means that the update becomes instantly visible, 
becauseupdating isn't an all-or-nothing deal - i would gladly update 
somesnippets from time to time, if it could be done "via git".- i have some 
valuable snippets and templates myself, and i'd like toshare them, but i don't 
see how they could fit with current LSRsystem.- i have 79 emails 

Re: maintaining advanced power-user Scheme functions

[Phil Holmes]

- Original Message - 
From: "Janek Warchoł" 

To: "Phil Holmes" 
Cc: "Thomas Morley" ; "lilypond-user" 
; "Phil Hézaine" ; "David 
Nalesnik" ; "LilyPond Developmet Team" 


Sent: Monday, August 19, 2013 11:02 AM
Subject: Re: maintaining advanced power-user Scheme functions



2013/8/19 Phil Holmes :
> > - Original Message - From: "Janek"
>> After some thinking, i came to the conclusion that LSR should be
>> redesigned.
>> Fristly, it should be a git repository, to make collaboration easy -
>> when something's a git repository, i have a habit of contributing
>> stuff there on every opportunity, because even if i do something wrong
>> i can undo this.
>
> I'd guess you're in a minority of about 1% of users who would prefer 
> using

> git to using a web interface. The current web interface allows you to
> copy-and-paste code directly in, or alternatively to type it directly 
> in.
> Both are simple and quick. To use git propoerly requires installing a 
> new
> program and learning how to use it. Remember yesterday when you 
> recommended

> a whole book about how it's used? If that doesn't put off casual
> contributors, nothing will. I started work on LilyPond by adding 
> regtests

> to the LSR. If git had been required, I wouldn't have done so.

A valid concern, but i have a counterargument: there is a web
interface for git that allows you to copy-and-paste code directly in,
or alternatively to type it directly in. Both are quite simple and
quick. This doesn't require installing a new program and learning how
to use it.

It's github.

I've just checked and made a couple commits using that web interface.
Plain and simple, *with* all the advantages of git underneath. Of
course i may be biased, so i invite you to check this with me. I
believe that i will be able to explain everything that's needed in
5-10 minutes. Would you like to try?


I've never used the web interface, but I'm prepared to believe it's quick 
and easy if you say it is.  However, my other opposition to git for this 
purpose is that it's intended as a Version Control system, which is 
completely unnecessary for the LSR - that's just a simple database of text, 
with no version control needed.



Actually, i believe that it would be good to have lilypond repository
on github, so that new contributors would be able to create patches
easily. They wouldn't have to install a virtual machine with Lilydev.
Found a typo in documentation? Create a fix and submit it in *2
minutes.*


And completely bu**er the make doc in the process.  That's what the issue 
tracker is for and why the patch control system exists.



>> Secondly, i think that it shouldn't depend on any particular lilypond
>> version - in fact, it shouldn't actually run any lilypond in my
>> opinion. I believe that LSR should hold both snippets' code and their
>> output, with lilypond version clearly stated, and thus allow to post
>> snippets for any lilypond version. It would just be a collection of
>> snippets.
>
> The benefit of it running LilyPond is that it shows the result of the 
> code

> on the fly - no need to create and upload images. This is another
> significant benefit.

I'm not sure if i understand. Does LSR compile snippets every time i
open its webpage?
Anyway, i'm not saying that LSR shouldn't be able to run LilyPond,
just that it should not require this for operation.


It compiles the snippets every time one is changed, and stores the resultant 
images in clickable form.  Can git do that?


It also exports the snippets so that they can be imported into the 
documents - which git can't do.



>> I could elaborate on this topic, but as i don't have time to actually
>> do something about it it probably wouln't make sense (unless someone
>> wanted to lead such a change - then i would gladly help).
>
> It doesn't need much changing - the main problem is maintaining the web
> site.

What if the things i pointed out make it hard to maintain?
I'd just like to point this out:
- with current system, i know that i'm not going to help with updating
LSR. If i had more time, i'd gladly do that, but i don't have.
However, if it was independent from LilyPond version - i.e. updating
one snippet means that the update becomes instantly visible, because
updating isn't an all-or-nothing deal - i would gladly update some
snippets from time to time, if it could be done "via git".
- i have some valuable snippets and templates myself, and i'd like to
share them, but i don't see how they could fit with current LSR
system.
- i have 79 emails marked "valuable snippet". Adding them to LSR (the
way it works currently) would require a lot of work, and i don't have
time for this. But if the LSR worked another way, i could do
something about it.


If you would actually try the LSR, you'll see it's equally quick to enter 
snippets - each takes a few seconds or a minute at most.  All that you need 
to do is type the snippet (or paste it) and a description - you can't do 
_less_ with any 

Re: maintaining advanced power-user Scheme functions

[Urs Liska]

One thing I'd definitely support about this is making LSR somewhat version 
independent to allow one to have snippets requiring new lily versions.
Maybe providing several lily versions (not necessarily _all_ of course) and use 
an appropriate one to compile the snippets. This would also allow us to keep 
'old' snippets without updating all to current lily syntax before being able to 
upgrade the whole LSR.
Maybe something like running convert-ly over all snippets when a new stable 
release comes out and leave snippets that can't be upgraded automatically for 
older versions?

Urs

PS: I'd also second the idea of hosting lilypond on a more accessible server 
(if that doesn't imply complicated side-effects). It is so easy to create a 
fork and open a pull request, I'm sure such a step would increase the number of 
contributions by people who can't or won't go through some undefined and 
possibly complex process of 'becoming a developer'



"Janek Warchoł"  schrieb:

>2013/8/19 Phil Holmes :
>> - Original Message - From: "Janek Warchoł"
>>> After some thinking, i came to the conclusion that LSR should be
>>> redesigned.
>>> Fristly, it should be a git repository, to make collaboration easy -
>>> when something's a git repository, i have a habit of contributing
>>> stuff there on every opportunity, because even if i do something
>wrong
>>> i can undo this.
>>
>> I'd guess you're in a minority of about 1% of users who would prefer
>using
>> git to using a web interface.  The current web interface allows you
>to
>> copy-and-paste code directly in, or alternatively to type it directly
>in.
>> Both are simple and quick.  To use git propoerly requires installing
>a new
>> program and learning how to use it.  Remember yesterday when you
>recommended
>> a whole book about how it's used?  If that doesn't put off casual
>> contributors, nothing will.  I started work on LilyPond by adding
>regtests
>> to the LSR.  If git had been required, I wouldn't have done so.
>
>A valid concern, but i have a counterargument: there is a web
>interface for git that allows you to copy-and-paste code directly in,
>or alternatively to type it directly in. Both are quite simple and
>quick.  This doesn't require installing a new program and learning how
>to use it.
>
>It's github.
>
>I've just checked and made a couple commits using that web interface.
>Plain and simple, *with* all the advantages of git underneath.  Of
>course i may be biased, so i invite you to check this with me.  I
>believe that i will be able to explain everything that's needed in
>5-10 minutes.  Would you like to try?
>
>Actually, i believe that it would be good to have lilypond repository
>on github, so that new contributors would be able to create patches
>easily.  They wouldn't have to install a virtual machine with Lilydev.
> Found a typo in documentation?  Create a fix and submit it in *2
>minutes.*
>
>>> Secondly, i think that it shouldn't depend on any particular
>lilypond
>>> version - in fact, it shouldn't actually run any lilypond in my
>>> opinion.  I believe that LSR should hold both snippets' code and
>their
>>> output, with lilypond version clearly stated, and thus allow to post
>>> snippets for any lilypond version.  It would just be a collection of
>>> snippets.
>>
>> The benefit of it running LilyPond is that it shows the result of the
>code
>> on the fly - no need to create and upload images.  This is another
>> significant benefit.
>
>I'm not sure if i understand.  Does LSR compile snippets every time i
>open its webpage?
>Anyway, i'm not saying that LSR shouldn't be able to run LilyPond,
>just that it should not require this for operation.
>
>>> I could elaborate on this topic, but as i don't have time to
>actually
>>> do something about it it probably wouln't make sense (unless someone
>>> wanted to lead such a change - then i would gladly help).
>>
>> It doesn't need much changing - the main problem is maintaining the
>web
>> site.
>
>What if the things i pointed out make it hard to maintain?
>I'd just like to point this out:
>- with current system, i know that i'm not going to help with updating
>LSR.  If i had more time, i'd gladly do that, but i don't have.
>However, if it was independent from LilyPond version - i.e. updating
>one snippet means that the update becomes instantly visible, because
>updating isn't an all-or-nothing deal - i would gladly update some
>snippets from time to time, if it could be done "via git".
>- i have some valuable snippets and templates myself, and i'd like to
>share them, but i don't see how they could fit with current LSR
>system.
>- i have 79 emails marked "valuable snippet".  Adding them to LSR (the
>way it works currently) would require a lot of work, and i don't have
>time for this.  But if the LSR worked another way, i could do
>something about it.
>
>If you'd like to discuss this more, i think IRC could be a good idea
>(it's faster) - i'm logged in.
>
>best,
>Janek
>
>_

Re: maintaining advanced power-user Scheme functions

[Urs Liska]

One thing I'd definitely support about this is making LSR somewhat version 
independent to allow one to have snippets requiring new lily versions.
Maybe providing several lily versions (not necessarily _all_ of course) and use 
an appropriate one to compile the snippets. This would also allow us to keep 
'old' snippets without updating all to current lily syntax before being able to 
upgrade the whole LSR.
Maybe something like running convert-ly over all snippets when a new stable 
release comes out and leave snippets that can't be upgraded automatically for 
older versions?

Urs

PS: I'd also second the idea of hosting lilypond on a more accessible server 
(if that doesn't imply complicated side-effects). It is so easy to create a 
fork and open a pull request, I'm sure such a step would increase the number of 
contributions by people who can't or won't go through some undefined and 
possibly complex process of 'becoming a developer'



"Janek Warchoł"  schrieb:

>2013/8/19 Phil Holmes :
>> - Original Message - From: "Janek Warchoł"
>>> After some thinking, i came to the conclusion that LSR should be
>>> redesigned.
>>> Fristly, it should be a git repository, to make collaboration easy -
>>> when something's a git repository, i have a habit of contributing
>>> stuff there on every opportunity, because even if i do something
>wrong
>>> i can undo this.
>>
>> I'd guess you're in a minority of about 1% of users who would prefer
>using
>> git to using a web interface.  The current web interface allows you
>to
>> copy-and-paste code directly in, or alternatively to type it directly
>in.
>> Both are simple and quick.  To use git propoerly requires installing
>a new
>> program and learning how to use it.  Remember yesterday when you
>recommended
>> a whole book about how it's used?  If that doesn't put off casual
>> contributors, nothing will.  I started work on LilyPond by adding
>regtests
>> to the LSR.  If git had been required, I wouldn't have done so.
>
>A valid concern, but i have a counterargument: there is a web
>interface for git that allows you to copy-and-paste code directly in,
>or alternatively to type it directly in. Both are quite simple and
>quick.  This doesn't require installing a new program and learning how
>to use it.
>
>It's github.
>
>I've just checked and made a couple commits using that web interface.
>Plain and simple, *with* all the advantages of git underneath.  Of
>course i may be biased, so i invite you to check this with me.  I
>believe that i will be able to explain everything that's needed in
>5-10 minutes.  Would you like to try?
>
>Actually, i believe that it would be good to have lilypond repository
>on github, so that new contributors would be able to create patches
>easily.  They wouldn't have to install a virtual machine with Lilydev.
> Found a typo in documentation?  Create a fix and submit it in *2
>minutes.*
>
>>> Secondly, i think that it shouldn't depend on any particular
>lilypond
>>> version - in fact, it shouldn't actually run any lilypond in my
>>> opinion.  I believe that LSR should hold both snippets' code and
>their
>>> output, with lilypond version clearly stated, and thus allow to post
>>> snippets for any lilypond version.  It would just be a collection of
>>> snippets.
>>
>> The benefit of it running LilyPond is that it shows the result of the
>code
>> on the fly - no need to create and upload images.  This is another
>> significant benefit.
>
>I'm not sure if i understand.  Does LSR compile snippets every time i
>open its webpage?
>Anyway, i'm not saying that LSR shouldn't be able to run LilyPond,
>just that it should not require this for operation.
>
>>> I could elaborate on this topic, but as i don't have time to
>actually
>>> do something about it it probably wouln't make sense (unless someone
>>> wanted to lead such a change - then i would gladly help).
>>
>> It doesn't need much changing - the main problem is maintaining the
>web
>> site.
>
>What if the things i pointed out make it hard to maintain?
>I'd just like to point this out:
>- with current system, i know that i'm not going to help with updating
>LSR.  If i had more time, i'd gladly do that, but i don't have.
>However, if it was independent from LilyPond version - i.e. updating
>one snippet means that the update becomes instantly visible, because
>updating isn't an all-or-nothing deal - i would gladly update some
>snippets from time to time, if it could be done "via git".
>- i have some valuable snippets and templates myself, and i'd like to
>share them, but i don't see how they could fit with current LSR
>system.
>- i have 79 emails marked "valuable snippet".  Adding them to LSR (the
>way it works currently) would require a lot of work, and i don't have
>time for this.  But if the LSR worked another way, i could do
>something about it.
>
>If you'd like to discuss this more, i think IRC could be a good idea
>(it's faster) - i'm logged in.
>
>best,
>Janek
>
>_

Re: maintaining advanced power-user Scheme functions

[Janek Warchoł]

2013/8/19 Phil Holmes :
> - Original Message - From: "Janek Warchoł"
>> After some thinking, i came to the conclusion that LSR should be
>> redesigned.
>> Fristly, it should be a git repository, to make collaboration easy -
>> when something's a git repository, i have a habit of contributing
>> stuff there on every opportunity, because even if i do something wrong
>> i can undo this.
>
> I'd guess you're in a minority of about 1% of users who would prefer using
> git to using a web interface.  The current web interface allows you to
> copy-and-paste code directly in, or alternatively to type it directly in.
> Both are simple and quick.  To use git propoerly requires installing a new
> program and learning how to use it.  Remember yesterday when you recommended
> a whole book about how it's used?  If that doesn't put off casual
> contributors, nothing will.  I started work on LilyPond by adding regtests
> to the LSR.  If git had been required, I wouldn't have done so.

A valid concern, but i have a counterargument: there is a web
interface for git that allows you to copy-and-paste code directly in,
or alternatively to type it directly in. Both are quite simple and
quick.  This doesn't require installing a new program and learning how
to use it.

It's github.

I've just checked and made a couple commits using that web interface.
Plain and simple, *with* all the advantages of git underneath.  Of
course i may be biased, so i invite you to check this with me.  I
believe that i will be able to explain everything that's needed in
5-10 minutes.  Would you like to try?

Actually, i believe that it would be good to have lilypond repository
on github, so that new contributors would be able to create patches
easily.  They wouldn't have to install a virtual machine with Lilydev.
 Found a typo in documentation?  Create a fix and submit it in *2
minutes.*

>> Secondly, i think that it shouldn't depend on any particular lilypond
>> version - in fact, it shouldn't actually run any lilypond in my
>> opinion.  I believe that LSR should hold both snippets' code and their
>> output, with lilypond version clearly stated, and thus allow to post
>> snippets for any lilypond version.  It would just be a collection of
>> snippets.
>
> The benefit of it running LilyPond is that it shows the result of the code
> on the fly - no need to create and upload images.  This is another
> significant benefit.

I'm not sure if i understand.  Does LSR compile snippets every time i
open its webpage?
Anyway, i'm not saying that LSR shouldn't be able to run LilyPond,
just that it should not require this for operation.

>> I could elaborate on this topic, but as i don't have time to actually
>> do something about it it probably wouln't make sense (unless someone
>> wanted to lead such a change - then i would gladly help).
>
> It doesn't need much changing - the main problem is maintaining the web
> site.

What if the things i pointed out make it hard to maintain?
I'd just like to point this out:
- with current system, i know that i'm not going to help with updating
LSR.  If i had more time, i'd gladly do that, but i don't have.
However, if it was independent from LilyPond version - i.e. updating
one snippet means that the update becomes instantly visible, because
updating isn't an all-or-nothing deal - i would gladly update some
snippets from time to time, if it could be done "via git".
- i have some valuable snippets and templates myself, and i'd like to
share them, but i don't see how they could fit with current LSR
system.
- i have 79 emails marked "valuable snippet".  Adding them to LSR (the
way it works currently) would require a lot of work, and i don't have
time for this.  But if the LSR worked another way, i could do
something about it.

If you'd like to discuss this more, i think IRC could be a good idea
(it's faster) - i'm logged in.

best,
Janek

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

Re: maintaining advanced power-user Scheme functions

[Phil Holmes]

- Original Message - 
From: "Janek Warchoł" 

To: "Thomas Morley" 
Cc: "lilypond-user" ; "Phil Hézaine" 
; "David Nalesnik" ; 
"LilyPond Developmet Team" 

Sent: Sunday, August 18, 2013 9:46 PM
Subject: Re: maintaining advanced power-user Scheme functions


After some thinking, i came to the conclusion that LSR should be 
redesigned.

Fristly, it should be a git repository, to make collaboration easy -
when something's a git repository, i have a habit of contributing
stuff there on every opportunity, because even if i do something wrong
i can undo this.


I'd guess you're in a minority of about 1% of users who would prefer using 
git to using a web interface.  The current web interface allows you to 
copy-and-paste code directly in, or alternatively to type it directly in. 
Both are simple and quick.  To use git propoerly requires installing a new 
program and learning how to use it.  Remember yesterday when you recommended 
a whole book about how it's used?  If that doesn't put off casual 
contributors, nothing will.  I started work on LilyPond by adding regtests 
to the LSR.  If git had been required, I wouldn't have done so.



Secondly, i think that it shouldn't depend on any particular lilypond
version - in fact, it shouldn't actually run any lilypond in my
opinion.  I believe that LSR should hold both snippets' code and their
output, with lilypond version clearly stated, and thus allow to post
snippets for any lilypond version.  It would just be a collection of
snippets.


The benefit of it running LilyPond is that it shows the result of the code 
on the fly - no need to create and upload images.  This is another 
significant benefit.



I could elaborate on this topic, but as i don't have time to actually
do something about it it probably wouln't make sense (unless someone
wanted to lead such a change - then i would gladly help).

best,
Janek


It doesn't need much changing - the main problem is maintaining the web 
site.



--
Phil Holmes 



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