Re: Problem with lilypond-mode in emacs

[David Rogers]

Ralph Palmer  writes:

> Greetings -
>
> I'm running LilyPond 2.16.2 under Windows 7, SP1.
>
> I've copied the *.el files from lilypond\..\site-lisp to
> \emacs\emacs-24.3\site-lisp
> and I've set the PATH and HOME variables so that I think emacs is finding
> lilypond-mode.el, but when I open emacs and type , I get
> [no match]. When I drag-and-drop an .ly file onto the open emacs buffer, I
> get .


In your emacs init file (mine on Linux is called .emacs, yours may have
a different name - the main startup file for Emacs, in any case), I
believe you need to have something like the following (replacing what's
between the quote marks with the correct information of course):


(add-to-list 'load-path "Directory where the *.el files are")


That line tells Emacs where to search, to find the Lilypond information
it needs.

Maybe you have this already - if you do, make sure it's still correct
(you said you had moved the *.el files, so you'd have to change this
line to match the new location).

-- 
David R

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

Re: Lilypond \include statements and the GPL

[Joseph Rushton Wakeling]

On 03/28/2013 08:28 PM, Tim McNamara wrote:
> My understanding is always been that the GPL applies to the software used to 
> produce a file, not to the file itself.

I think (at least in this case) you mean "process", not "produce".

You can draw an analogy to e.g. shell scripts, where the fact that the bash
shell is GPL-licensed doesn't mean that shell scripts must also be GPL'd.

However, I'm not 100% convinced here because I think the situation of putting in
an \include to a GPL'd .ly file, and calling functions defined in that file,
might well make your own .ly file specifically a derivative work.

> Therefore, the GPL would not apply to the users' .ly files; the user has the 
> option of specifying under what license any such files might be published.

That rests on the assumption that there is a separation between GPL'd
interpreter and the source file that's being interpreted.  PHP is a nice example
-- the license of my PHP files can be independent of the license of PHP itself
(which as it happens is a dual-license between GPL and a custom license).

But when I start making calls in PHP to a written-in-PHP library that is GPL'd,
I think things become rather different.

I think the \import "somefile.ly" situation could be more analogous to this
second situation _where the .ly file defines functions that are used in your own
.ly file_.  Hence it's an area of licensing concern.

And as I've stressed before, this licensing issue would kick in only if you
distributed your .ly file -- not if you distributed the graphical score produced
by processing it.

I will be away over the Easter weekend so not able to answer emails, but I'd
like to continue this discussion afterwards.

Thanks & best wishes,

-- Joe

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

Re: Lilypond \include statements and the GPL

[Janek Warchoł]

Hi,

On Thu, Mar 28, 2013 at 7:26 PM, Joseph Rushton Wakeling
 wrote:
> Personally I feel it would be nice to resolve any potential ambiguity.
>
> Obviously the best way to do this is just to show that I'm definitively wrong 
> in
> my interpretation (this would be nice:-),

I'd say this: without the actual content of the included file
available, \include statement doesn't do anything.  If your .ly file
uses a function defined in an \included library file, but you don't
provide this file, the function cannot be used.

> but aside from that I think there are
> probably several other ways in which it could be done, including ensuring that
> all files intended to be \include'd are licensed under something more 
> permissive
> (LGPL, BSD, Boost, Apache, ...), or adding a simple exception or clarification
> to Lilypond's license akin to the GPL font exception.

+1

An example came to my mind: imagine someone typesetting a score and
using one (just one) function from OLLib.  Distributing whole OLLib
together with the score just to have this one functionality would be
inconvenient, so he'd like to actually paste this function from OLLib
into his file.  Can he do this?  I think that such usage should be
permitted (and not resulting in the final score being copylefted), as
long as the function is clearly marked and attributed.

BTW, what about snippets from documentation and LSR?  AFAIK whole lily
documentation is under GNU Free Documentation License; if someone
takes a template from the docs and uses it as a basis for his score,
what should happen then?  Clearly the score would be a derivative work
in some way, but i don't think it's our goal to force all such scores
to be copylefted...

This really needs clarification!

best,
Janek

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

Re: Use proportional spacing for a section in a score

[James Harkins]

David Kastrup  gnu.org> writes:

> Try \set Score.proportionalNotationDuration instead.

OK, that seems to have got it.

This detail seems not to be mentioned in the NR as obviously as it
might be. It does mention that proportionalNotationDuration "lives in
the Score context," but still it escaped me that I should include
"Score." in the \set command.

It would help to have one example of switching between classical and
proportional spacing. All the examples in that NR section assume that
the entire score will be proportional, which is not certain for every
score.

hjh


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

Extraneous accidental after barline in cadenza

[James Harkins]

I would like the E-natural to print here without the accidental.

\version "2.16.1"
\include "english.ly"

\relative c' {
  \key g \major

  ef1
  g
  e1  % no explicit natural sign here

  \cadenzaOn

  ef1
  \bar "|"
  g
  \bar "|"
  e1  % but there is one here - I want to get rid of it
}

In this minimal example, it could be argued that the visible
cancellation makes sense. In my actual score, it doesn't: the E-flat
is early in the system, and the E-nat. is quite a bit later, with many
notes and three barlines intervening (see attached screenshot). The
cancellation is superfluous there, but I can't get rid of it (not even
with "\set Staff.extraNatural = ##f").

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

Re: Extraneous accidental after barline in cadenza

[Phil Holmes]

- Original Message - 
From: "James Harkins" 

To: "lily-users" 
Sent: Friday, March 29, 2013 11:00 AM
Subject: Extraneous accidental after barline in cadenza



I would like the E-natural to print here without the accidental.

\version "2.16.1"
\include "english.ly"

\relative c' {
 \key g \major

 ef1
 g
 e1  % no explicit natural sign here

 \cadenzaOn

 ef1
 \bar "|"
 g
 \bar "|"
 e1  % but there is one here - I want to get rid of it
}

In this minimal example, it could be argued that the visible
cancellation makes sense. In my actual score, it doesn't: the E-flat
is early in the system, and the E-nat. is quite a bit later, with many
notes and three barlines intervening (see attached screenshot). The
cancellation is superfluous there, but I can't get rid of it (not even
with "\set Staff.extraNatural = ##f").

Thanks,
hjh


There was lots of discussion about this earlier:

http://lilypond.1069038.n5.nabble.com/unexpected-accidental-following-cadenza-td62209.html

http://lilypond.1069038.n5.nabble.com/cadenzaOff-and-accidentals-td9420.html


I'm not sure of the cure - perhaps temporarily removing the accidental 
engraver or somesuch?


--
Phil Holmes 



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

Re: Extraneous accidental after barline in cadenza

[Thomas Morley]

2013/3/29 James Harkins 

> I would like the E-natural to print here without the accidental.
>
> \version "2.16.1"
> \include "english.ly"
>
> \relative c' {
>   \key g \major
>
>   ef1
>   g
>   e1  % no explicit natural sign here
>
>   \cadenzaOn
>
>   ef1
>   \bar "|"
>   g
>   \bar "|"
>   e1  % but there is one here - I want to get rid of it
> }
>
> In this minimal example, it could be argued that the visible
> cancellation makes sense. In my actual score, it doesn't: the E-flat
> is early in the system, and the E-nat. is quite a bit later, with many
> notes and three barlines intervening (see attached screenshot). The
> cancellation is superfluous there, but I can't get rid of it (not even
> with "\set Staff.extraNatural = ##f").
>
> Thanks,
> hjh
>

Hi James,

as far as I can see you are still _in_ cadenza with the last note, i.e. in
_unmetered_ music.
Inserting manual \bar "|" doesn't change this and opens _no_ new section of
unmetered music.
Therefore LilyPond's use of the natural is logical.

To get rid of the natural you may want to use:
\once \override Accidental #'stencil = ##f
or
\once \override Accidental #'transparent = ##t

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

Re: Extraneous accidental after barline in cadenza

[James Harkins]

On Mar 29, 2013 7:19 PM, "Phil Holmes"  wrote:
>> In this minimal example, it could be argued that the visible
>> cancellation makes sense. In my actual score, it doesn't: the E-flat
>> is early in the system, and the E-nat. is quite a bit later, with many
>> notes and three barlines intervening (see attached screenshot). The
>> cancellation is superfluous there, but I can't get rid of it (not even
>> with "\set Staff.extraNatural = ##f").
>>
> There was lots of discussion about this earlier:
>
>
http://lilypond.1069038.n5.nabble.com/unexpected-accidental-following-cadenza-td62209.html
>
>
http://lilypond.1069038.n5.nabble.com/cadenzaOff-and-accidentals-td9420.html
>
> I'm not sure of the cure - perhaps temporarily removing the accidental
engraver or somesuch?

Ok, my manually painted \bar lines have no effect on accidentals (either by
design, or as a side effect of a design that has other good reasons to be
as it is).

I've just looked through the manual a bit, and it leads me to doubt whether
it's possible to remove an engraver for a single note. I see that it's
possible to do for a single context, e.g. Staff, but I do want accidentals
elsewhere in the bassoon part.

It's not a big deal, just a little detail that surprised me.

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

Re: Extraneous accidental after barline in cadenza

[Thomas Morley]

2013/3/29 James Harkins 

> Ok, my manually painted \bar lines have no effect on accidentals (either
> by design, or as a side effect of a design that has other good reasons to
> be as it is).
>
Even in metered music a manually printed bar-line in the middle of a
measure has no effect on accidentals, it's little more than a graphic
symbol.

Look at:

\version "2.16.1"
\include "english.ly"

\relative c' {
\key g\major
ef4 fs \bar "|" ef fs
\bar "||"
ef4 fs \bar "|" e f
}


> I've just looked through the manual a bit, and it leads me to doubt
> whether it's possible to remove an engraver for a single note.
>
Another idea. How about:
\once \accidentalStyle forget

> I see that it's possible to do for a single context, e.g. Staff, but I do
> want accidentals elsewhere in the bassoon part.
>
> It's not a big deal, just a little detail that surprised me.
>
> hjh
>

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

Old, but nice

[Christ van Willegen]

Hi,

I was Facebook'ed the following video. It's an oldy, but it's nice:
http://www.facebook.com/photo.php?v=102421339943114&set=vb.15257443455&type=2&theater

Christ van Willegen
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

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

Re: Extraneous accidental after barline in cadenza

[Noeck]

> Hi James,
> 
> as far as I can see you are still _in_ cadenza with the last note, i.e.
> in _unmetered_ music.
> Inserting manual \bar "|" doesn't change this and opens _no_ new section
> of unmetered music.
> Therefore LilyPond's use of the natural is logical.
> 
> To get rid of the natural you may want to use:
> \once \override Accidental #'stencil = ##f
> or
> \once \override Accidental #'transparent = ##t

which only helps for the first note in this measure (as it is in this
case). Is there no way to start a new measure also in terms of
accidentals (some kind of reset accidental status)?
I like your suggestion
  \once \accidentalStyle forget
more, because it does what I would expect in a new measure: forget the
previous accidentals, perhaps even without \once and then after 1 measure
  \accidentalStyle modern
(or what ever was there before).

Cheers,
Joram

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

Hiding staff lines without barlines hiding

[anchom]

Hello

How can I hide staff lines without hiding barlines? The \stopStaff command hids 
barlines either.
Removing "Staff_symbol_engraver" does the same.

Best
Anna Choma



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

Re: Lilypond \include statements and the GPL

[Tim McNamara]

On Mar 29, 2013, at 4:42 AM, Joseph Rushton Wakeling wrote:
> On 03/28/2013 08:28 PM, Tim McNamara wrote:
>> My understanding is always been that the GPL applies to the software used to 
>> produce a file, not to the file itself.
> 
> I think (at least in this case) you mean "process", not "produce".

I didn't express myself very well, I realized after I re-read what I wrote.  
The GPL applies to source code that can be compiled into an application, not to 
the products of an application.  Thus LilyPond can be licensed under the GPL 
and that has implications for licensing an application that uses the LilyPond 
source code; however, the GPL does not apply to a PDF, PS, MIDI or other image 
file produced using LilyPond.  If I use Emacs to write a book and LaTeX to 
typeset it, I am not required to GPL the book.  This sort of thing was my 
intent.

> You can draw an analogy to e.g. shell scripts, where the fact that the bash
> shell is GPL-licensed doesn't mean that shell scripts must also be GPL'd.
> 
> However, I'm not 100% convinced here because I think the situation of putting 
> in
> an \include to a GPL'd .ly file, and calling functions defined in that file,
> might well make your own .ly file specifically a derivative work.

I don't see that a .ly or .ily file that may be \included creates a situation 
of derivation.  Lilypond is an application with a language that is somewhat 
similar to TeX in appearance and function.  As far as I can tell, if one uses a 
language that is GPL'd, this does not require that files written in that 
language also be GPL'd.  Most \include files modify the operation and output of 
LilyPond in some way and are functionally part of the application rather than 
the musical content of the file.  Using them does not have an affect on the 
licensing of the output (e.g., the PDF or MIDI file).  

I think that the user's copyrightable material consists of the music 
expressions between the curly braces.  It is separate from the LilyPond 
engraving language, which would not be copyrightable because it is released 
under the GPL.  So the formatting parts of a .ly file are derivative but the 
unique music expression- e.g., the music content, to use a term I have never 
been really happy with- cannot be considered derivative of LilyPond and is not 
subject to the GPL.  It may be derivative of something else and have other 
copyright issues, but those are independent of LilyPond.  The {} are the 
dividing line.

>> Therefore, the GPL would not apply to the users' .ly files; the user has the 
>> option of specifying under what license any such files might be published.
> 
> That rests on the assumption that there is a separation between GPL'd
> interpreter and the source file that's being interpreted.  PHP is a nice 
> example
> -- the license of my PHP files can be independent of the license of PHP itself
> (which as it happens is a dual-license between GPL and a custom license).
> 
> But when I start making calls in PHP to a written-in-PHP library that is 
> GPL'd,
> I think things become rather different.
> 
> I think the \import "somefile.ly" situation could be more analogous to this
> second situation _where the .ly file defines functions that are used in your 
> own
> .ly file_.  Hence it's an area of licensing concern.
> 
> And as I've stressed before, this licensing issue would kick in only if you
> distributed your .ly file -- not if you distributed the graphical score 
> produced
> by processing it.

I am not sure that it would make a difference, because the copyrightable 
content (the music expressions) is separated from the LilyPond language by the 
curly braces.  It seems like a lot of weight to put on some {} symbols, but 
they are the demarcation line between the two aspects of a LilyPond file (one 
being what is rendered, the other being how it is rendered).  You'd end up with 
a hybrid copyleft/copyright file:  LilyPond functions which which are copyleft 
with an embedded music expression that is or can be copyrighted.  The music 
expression sort of lives in a walled neighborhood within a city, the 
neighborhood and the city having different property rights.

In short, \melody {} belongs to LilyPond and the GPL.  The c4 d e f g contained 
within the {  } is mine to license as I choose.

I think.  ;-)

Tim


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

Re: Hiding staff lines without barlines hiding

[Eluze]

Anna Choma wrote
> Hello
> 
> How can I hide staff lines without hiding barlines? The \stopStaff command
> hids barlines either.
> Removing "Staff_symbol_engraver" does the same.

depending what you for!

try (version 2.17.14)

  \stopStaff
  \override Staff.StaffSymbol.color=#white 
  \override Staff.BarLine.layer=#999
  \startStaff

hth
Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Hiding-staff-lines-without-barlines-hiding-tp143606p143608.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: Hiding staff lines without barlines hiding

[Phil Holmes]

- Original Message - 
From: "Eluze" 

To: 
Sent: Friday, March 29, 2013 3:13 PM
Subject: Re: Hiding staff lines without barlines hiding



Anna Choma wrote

Hello

How can I hide staff lines without hiding barlines? The \stopStaff 
command

hids barlines either.
Removing "Staff_symbol_engraver" does the same.


depending what you for!

try (version 2.17.14)

 \stopStaff
 \override Staff.StaffSymbol.color=#white
 \override Staff.BarLine.layer=#999
 \startStaff

hth
Eluze


How about:

\new Staff \with {
\override StaffSymbol.line-count = #0
\override BarLine.bar-extent = #'( -2.5 . 2.5 )
}
{ a'4 e' f' b' | d'1 }

--
Phil Holmes 



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

Fermata over barline moving to next liine

[Richard Shann]

I have a score with a fermata on a barline. If the barline occurs at a
line break it moves itself on to the next line over the clef there.
Digging in the manual I found I can stop it moving to position itself
over the clef on the following line with this:

\once \override Score.RehearsalMark #'break-visibility = #end-of-line-visible 
\mark \markup { \musicglyph #"scripts.ufermata" }

however, the fermata then vanishes if further changes result in the
fermata not being at a line break.

How can I position a fermata over a barline regardless of whether that
barline is at the end of a line or not?


I have found things like this:
\override Score.RehearsalMark #'break-align-symbols = #'(time-signature)

but guessing at the name and trying
\override Score.RehearsalMark #'break-align-symbols = #'(barline)
didn't stop the fermata moving to the next line.

Anyone got a solution for this?

Richard Shann




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

Re: Fermata over barline moving to next liine

[Noeck]

Hi Richard,

> \once \override Score.RehearsalMark #'break-visibility = #end-of-line-visible 
> \mark \markup { \musicglyph #"scripts.ufermata" }

Instead of #end-of-line-visible you can use #begin-of-line-invisible,
then it would be visible at the end and in the middle, but not at the
beginning of a bar line.

\once \override Score.RehearsalMark #'break-visibility =
#begin-of-line-invisible

cf.
http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects#using-break_002dvisibility

HTH,
Joram

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

Re: Fermata over barline moving to next liine

[Richard Shann]

On Fri, 2013-03-29 at 17:21 +0100, Noeck wrote:
> Hi Richard,
> 
> > \once \override Score.RehearsalMark #'break-visibility = 
> > #end-of-line-visible \mark \markup { \musicglyph #"scripts.ufermata" }
> 
> Instead of #end-of-line-visible you can use #begin-of-line-invisible,
> then it would be visible at the end and in the middle, but not at the
> beginning of a bar line.
> 
> \once \override Score.RehearsalMark #'break-visibility =
> #begin-of-line-invisible

Thank you very much - worked a treat
> 
> cf.
> http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects#using-break_002dvisibility
> 
ah, I didn't find that section ...

Richard


> HTH,
> Joram
> 
> ___
> 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: Hiding staff lines without barlines hiding

[Michael Rivers]

I use

\override Staff.Clef #'stencil = ##f 
\override Staff.StaffSymbol #'stencil = ##f



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Hiding-staff-lines-without-barlines-hiding-tp143606p143625.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: extending event-listener.ly

[Phil Hézaine]

Hi list,

A patch about event-listener.ly was send to:

https://codereview.appspot.com/8165043/

Phil.

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

Re: Old, but nice

[Pierre Perol-Schneider]

Thanks for this nice moment !


2013/3/29 Christ van Willegen 

> Hi,
>
> I was Facebook'ed the following video. It's an oldy, but it's nice:
>
> http://www.facebook.com/photo.php?v=102421339943114&set=vb.15257443455&type=2&theater
>
> Christ van Willegen
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>
> ___
> 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: Lilypond \include statements and the GPL

[Urs Liska]

First of all, I think we have quite a consensus on what we intend - which is a 
good start.

On Fri, 29 Mar 2013 09:43:59 -0500
Tim McNamara  wrote:

> On Mar 29, 2013, at 4:42 AM, Joseph Rushton Wakeling wrote:
> > On 03/28/2013 08:28 PM, Tim McNamara wrote:
> >> My understanding is always been that the GPL applies to the software used 
> >> to produce a file, not to the file itself.
> > 
> > I think (at least in this case) you mean "process", not "produce".
> 
> I didn't express myself very well, I realized after I re-read what I wrote.  
> The GPL applies to source code that can be compiled into an application, not 
> to the products of an application.  Thus LilyPond can be licensed under the 
> GPL and that has implications for licensing an application that uses the 
> LilyPond source code; however, the GPL does not apply to a PDF, PS, MIDI or 
> other image file produced using LilyPond.  If I use Emacs to write a book and 
> LaTeX to typeset it, I am not required to GPL the book.  This sort of thing 
> was my intent.

OK, that's clear. But the question is whether the GPL applies to the LilyPond 
source files.
> 
> > You can draw an analogy to e.g. shell scripts, where the fact that the bash
> > shell is GPL-licensed doesn't mean that shell scripts must also be GPL'd.
> > 
> > However, I'm not 100% convinced here because I think the situation of 
> > putting in
> > an \include to a GPL'd .ly file, and calling functions defined in that file,
> > might well make your own .ly file specifically a derivative work.
> 
> I don't see that a .ly or .ily file that may be \included creates a situation 
> of derivation.  Lilypond is an application with a language that is somewhat 
> similar to TeX in appearance and function.  As far as I can tell, if one uses 
> a language that is GPL'd, this does not require that files written in that 
> language also be GPL'd.  Most \include files modify the operation and output 
> of LilyPond in some way and are functionally part of the application rather 
> than the musical content of the file.  Using them does not have an affect on 
> the licensing of the output (e.g., the PDF or MIDI file).  

No, surely not. What we are discussing it, whether that has an impact on the 
licensing of the input.

> 
> I think that the user's copyrightable material consists of the music 
> expressions between the curly braces.  It is separate from the LilyPond 
> engraving language, which would not be copyrightable because it is released 
> under the GPL.  So the formatting parts of a .ly file are derivative but the 
> unique music expression- e.g., the music content, to use a term I have never 
> been really happy with- cannot be considered derivative of LilyPond and is 
> not subject to the GPL.  It may be derivative of something else and have 
> other copyright issues, but those are independent of LilyPond.  The {} are 
> the dividing line.
> 
> >> Therefore, the GPL would not apply to the users' .ly files; the user has 
> >> the option of specifying under what license any such files might be 
> >> published.
> > 
> > That rests on the assumption that there is a separation between GPL'd
> > interpreter and the source file that's being interpreted.  PHP is a nice 
> > example
> > -- the license of my PHP files can be independent of the license of PHP 
> > itself
> > (which as it happens is a dual-license between GPL and a custom license).
> > 
> > But when I start making calls in PHP to a written-in-PHP library that is 
> > GPL'd,
> > I think things become rather different.
> > 
> > I think the \import "somefile.ly" situation could be more analogous to this
> > second situation _where the .ly file defines functions that are used in 
> > your own
> > .ly file_.  Hence it's an area of licensing concern.
> > 
> > And as I've stressed before, this licensing issue would kick in only if you
> > distributed your .ly file -- not if you distributed the graphical score 
> > produced
> > by processing it.
> 
> I am not sure that it would make a difference, because the copyrightable 
> content (the music expressions) is separated from the LilyPond language by 
> the curly braces.  It seems like a lot of weight to put on some {} symbols, 
> but they are the demarcation line between the two aspects of a LilyPond file 
> (one being what is rendered, the other being how it is rendered).  You'd end 
> up with a hybrid copyleft/copyright file:  LilyPond functions which which are 
> copyleft with an embedded music expression that is or can be copyrighted.  
> The music expression sort of lives in a walled neighborhood within a city, 
> the neighborhood and the city having different property rights.
> 
> In short, \melody {} belongs to LilyPond and the GPL.  The c4 d e f g 
> contained within the {  } is mine to license as I choose.
> 
> I think.  ;-)

I slightly disagree, although your considerations are valuable and give some 
good insights in the situation.
I think the 'ambiguity' Joe is talking about is the 

Re: Lilypond \include statements and the GPL

[Alexander Kobel]

On 03/29/2013 05:39 PM, Urs Liska wrote:


Now take a programming language as another example (PHP and Python are 
explicitely _not_ distributed under the GPL BTW).
The interpreter is GPLed by group A, as well as some libraries.
User B writes a program in that language. This program is considered a 'user 
document', and the GPL doesn't affect it - User B can publish the program in 
any way he likes, with or without source code.
User C writes a program, but uses functions from the GPLed libraries. That 
forces him to release his program under the GPL too.



Uh, wait a second.  As most people, IANAL, but to my understanding:

User B is allowed to give away the source code in any form, and the 
binary under non-GPL code /if and only if/ it does not come with parts 
of group A's libraries compiled in.  If, e.g., inline function calls are 
replaced by library code, or a library is statically linked into the 
binary, I would assume this enforces GPL to the binary.  And this is 
exactly what will happen in practice, if e.g. the stdlibs were GPL'ed.


On the other hand, user C /should/ be allowed to distribute source code 
under whatever license he wants to /as long as he doesn't ship the GPL 
libraries with it./  It's useless without them, but anybody who wants to 
run or compile the code is free to download the necessary GPL'ed stuff.
However, even user C may freely without any constraints give away the 
/output/ of the program he has written and compiled.



Translated to LilyPond, IMHO this means:

- A user may give away his .ly file, if he did not copy-paste from 
Lily's source files.  Importing standard .ly's is okay (like \include 
"english.ly"), as long as the english.ly is not shipped with the user's 
file.
- A user may give away the PDF/PNG/PS/Inkscape-handtuned SVG/MIDI, since 
it is the output of his "program" written in the "LilyPond language". 
The PDF/... does not contain any GPL'ed stuff in it - in particular, no 
LilyPond code.  Very similar to the situation that I can distribute a 
text document (or even a .ly file) I've written using the GPL'ed Emacs, 
unless I quote part of Emacs' source code in there.  (I agree with Tim.)
@Joseph: I can see no difference in \include'ing a LilyPond file and 
calling a bash built-in function in a shell script, just because one is 
explicit and the other isn't.  Again, unless you ship bash along with it.



Or am I totally wrong here?


Best,
Alexander

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

Re: Lilypond \include statements and the GPL

[Alexander Kobel]

On 03/29/2013 06:26 AM, Janek Warchoł wrote:

An example came to my mind: imagine someone typesetting a score and
using one (just one) function from OLLib.  Distributing whole OLLib
together with the score just to have this one functionality would be
inconvenient, so he'd like to actually paste this function from OLLib
into his file.  Can he do this?  I think that such usage should be
permitted (and not resulting in the final score being copylefted), as
long as the function is clearly marked and attributed.


That might be a dark gray area.
I'm not sure what's the smallest "unit" a license like the GPL can be 
applied to, but rest assured that I know from past experience that it is 
/very/ beneficial to have one license per file.  From the law you may be 
right (with the same reasoning why a publisher can print the works of 
different composers, or both PD and copyrighted works, in the same 
volume), but if that case appears in reality, I strongly suggest you 
distribute in small pieces.  One more file is cheap, one more letter 
from a lawyer isn't.



Best,
Alexander

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

Re: extending event-listener.ly

[Graham Percival]

On Thu, Mar 28, 2013 at 08:09:45PM +0100, Phil Hézaine wrote:
> And what about the conversion of drum notes to midi pitches?
> I'm not able to find a way to write a specific function for that issue.
> Graham? Have you some time?

To clarify, I wasn't suggesting that drums should be converted to
midi pitches.  Rather, it should be possible to write a function
which extracts the MIDI pitch number (if it's a normal note), or
the drum name (if it's a drum note).  Using a function like that
would allow you to eliminate some duplicate lines, making the file
easier to maintain in the future.

- Graham

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

Re: Extraneous accidental after barline in cadenza

[James Harkins]

On Fri, Mar 29, 2013 at 8:20 PM, Thomas Morley
 wrote:
> Another idea. How about:
> \once \accidentalStyle forget

Good one. That did it. Thanks!
hjh

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

Removing lines of rest with two voices and bar count numbers

[ryanmichaelmcclure]

I am working on the bassoon part for Holst's First Suite, and I want to try
something that looks essentially like this:

http://pastebin.com/71RJe0YB

Except I want the last measure in the 2nd part to be hidden (There is music
later in that part but I want the rests to be gone.)

I do not know how to remove this rest in the 2nd part. In the real part, it
is about 100 measures of rest.

http://pastebin.com/yGHkgDWE

Here is how I want it to look, but with the measure count numbers above.



-
Ryan McClure

Luna Music Engraving
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Removing-lines-of-rest-with-two-voices-and-bar-count-numbers-tp143636.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

Tempo marking pushes rehearsal mark far above the staff

[James Harkins]

Sorry if it's a basic question -- my eyes are starting to glaze over
from looking at the manual.

In this minimal example, there's a collision between the rehearsal and
tempo marks. LP resolves the collision by pushing the rehearsal mark
rather far above the staff. This is a legibility issue when there is
more than one system, because the rehearsal mark is closer
(underneath) the preceding system than it is to the system that it
actually belongs to.

\relative c'' {
  \set Score.markFormatter = #format-mark-box-alphabet
  c4 c c c
  \mark \default
  % Note, I'm putting the tempo change here instead of bar 1
  % b/c my piece changes tempo in the middle,
  % often at rehearsal marks
  \tempo "Andante" 4 = 72
  \repeat unfold 3 { c4 c c c }
}

If I comment out the markFormatter line, then the rehearsal mark
appears just to the left of the tempo mark (with vertical centering),
but there is not enough horizontal distance between them. It almost
looks like "AAndante" (except that the first "A" is slightly larger
and its baseline is a little bit lower). For this case (no box), I
also tried these two (separately):

  % Pushed the rehearsal mark higher, possibly usable but not ideal
  % This had no effect on a rehearsal mark with box
  \override Score.RehearsalMark #'padding = #'4

  % No discernible effect, even with much larger numbers
  \override Score.RehearsalMark #'extra-spacing-width = #'(+inf.0 . -5.0)

I like the appearance with the box better. What I'd really like is for
LP to resolve the conflict by pushing the tempo mark to the right just
enough to avoid the rehearsal mark's horizontal padding.

TIA,
hjh

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

Re: Tempo marking pushes rehearsal mark far above the staff

[Keith OHara]

James Harkins  gmail.com> writes:

> In this minimal example, there's a collision between the rehearsal and
> tempo marks. LP resolves the collision by pushing the rehearsal mark
> rather far above the staff. 

>   % No discernible effect, even with much larger numbers
>   \override Score.RehearsalMark #'extra-spacing-width = #'(+inf.0 . -5.0)
> 
> What I'd really like is for
> LP to resolve the conflict by pushing the tempo mark to the right just
> enough to avoid the rehearsal mark's horizontal padding.
> 

You were on the right track; both MetronomeMark and RehearsalMark need
to have space reserved.  I always use the set of overrides below.  
(For some reason they don't work for Kieren, however, so he prefers
composing all his tempo marks as text markup 
 )


\layout { \context { \Score
% \override Clef #'break-align-anchor-alignment = #RIGHT % marks right of clef
  \override MetronomeMark #'extra-spacing-width = #'(-0.5 . 0.5)
  \override MetronomeMark #'Y-offset = #3
  \override MetronomeMark #'outside-staff-padding = #0.8
  \override MetronomeMark #'break-align-symbols =
   #'(time-signature key-signature)
  \override MetronomeMark #'non-break-align-symbols =
   #'(paper-column-interface)
  \override RehearsalMark #'extra-spacing-width = #'(-0.5 . 0.5)
  \override RehearsalMark #'Y-offset = #0
  \override RehearsalMark #'outside-staff-padding = #0.8
 } }


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