Re: tie over clef change

[Andrew Bernard]

That can't be a tie because the second note would not have the 
accidental, in general.


Gould is not always right in my view.

Andrew


On 26/09/2020 11:41 pm, Dan Eble wrote:


What kind of grob would an editor expect here? a Tie because it connects notes 
of the same pitch, or a Slur because it connects notes at different staff 
positions? (or something else?)
—
Dan

Re: tie over clef change

[Jean Abou Samra]

Le 26/09/2020 à 15:41, Dan Eble a écrit :

On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:


Despite Gould's “incorrect” verdict, here is an example from an old UE
edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
over clef changes *do* happen and make sense sometimes...

I still think that LilyPond should support that, handling the tie like
a slur in this case.

That's a very good example.  It's hard to imagine any reasonable alternative.

What kind of grob would an editor expect here? a Tie because it connects notes 
of the same pitch, or a Slur because it connects notes at different staff 
positions? (or something else?)


If this were ever implemented, I would expect a Tie.The ~ sign
builds a strong mental connectionwith Tie objects. The different
staff positions are the result ofthe work of the typesetting engine.
In my opinion, the type of agrob should only depend on the input.
Note that having a Slur wouldactually break user code in cases
where the Tie is at the end ofsystem and thus perfectly correct.
Consider:

{
  \override Tie.color = #red
  c'1~
  \clef bass
  \break
  c'1
}

Also, we advocate separation of layout and content. It's
better in my eyes not to silently change the grob type if
a clef change is removed.

That being said, I don't think we should have this as a
default, notably because of the ugly output when the tie
is between chords. As an option, why not. I'm not sure
Joe user would look into the Internals in this case though.
I would just change it to a slur…

Regards,
Jean

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 20:58, Kevin Barry  wrote:
> 
> On Sat, 26 Sep 2020 at 19:30, Hans Åberg  wrote:
>> The notes d♯ to e♭ have different pitches in the staff notation
>> system, which cannot express E12 enharmonic equivalents, so this
>> is slur. So it should be a slur that looks like slur.
>>> 
>>> I disagree.  For all practical purposes in standard classical music,
>>> enharmonic equivalents *do* sound the same.  What you are referring to
>>> IMHO is a special case that might be controlled by a flag.
>> 
>> They do not, and the string section, that primarily stands for the pitch
>> reference, trains to slide the pitch appropriately:
> 
> In some contexts a notated D sharp and E flat are the same pitch (e.g.
> equally tempered piano music) and in some they are not (as you pointed
> out). Since this is a discussion about ties, where the note is the
> same by definition, we can assume we are dealing with the same pitch.

The staff notation pitches are different in the case of an enharmonic tie, as 
in Dan's example d♯ to e♭. You might want to have a tie here to make the 
enharmonic change explicit. —That is perhaps what you meant, but I find it 
confusing saying that d♯ to e♭ are the same pitch, because in the case of staff 
notation, they are not, even though in some music, they can be played the same.

> The question isn't whether it's a tie or a slur, but how LilyPond
> should render a tie when the two notes are not aligned (i.e. the user
> has entered a "~" indicating that it's a tie).

Say the ties are rendered as usual, but the slurs are dotted lines, and the 
phrase marks are square brackets. How do you want the output to be then?

> I agree with Gould that ties across clef changes should be avoided (I
> personally wouldn't even do it in the Liszt example posted), but I
> think LilyPond needs to handle it. I think it's quite acceptable to
> detect this situation and switch to using a slur (but I haven't looked
> at the code).

So if one makes them radically different, substituting ties and slurs for each 
other in the output would not work.

Re: tie over clef change

[Kevin Barry]

On Sat, 26 Sep 2020 at 19:30, Hans Åberg  wrote:
>  The notes d♯ to e♭ have different pitches in the staff notation
>  system, which cannot express E12 enharmonic equivalents, so this
>  is slur. So it should be a slur that looks like slur.
> >
> > I disagree.  For all practical purposes in standard classical music,
> > enharmonic equivalents *do* sound the same.  What you are referring to
> > IMHO is a special case that might be controlled by a flag.
>
> They do not, and the string section, that primarily stands for the pitch
> reference, trains to slide the pitch appropriately:

In some contexts a notated D sharp and E flat are the same pitch (e.g.
equally tempered piano music) and in some they are not (as you pointed
out). Since this is a discussion about ties, where the note is the
same by definition, we can assume we are dealing with the same pitch.
The question isn't whether it's a tie or a slur, but how LilyPond
should render a tie when the two notes are not aligned (i.e. the user
has entered a "~" indicating that it's a tie).

I agree with Gould that ties across clef changes should be avoided (I
personally wouldn't even do it in the Liszt example posted), but I
think LilyPond needs to handle it. I think it's quite acceptable to
detect this situation and switch to using a slur (but I haven't looked
at the code).

Kevin

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 19:36, Dan Eble  wrote:
> 
> On Sep 26, 2020, at 13:11, Hans Åberg  wrote:
>> 
>>> 
>>> On 26 Sep 2020, at 18:50, Dan Eble  wrote:
>>> 
>>> On Sep 26, 2020, at 12:34, Hans Åberg  wrote:
 
> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
> 
>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>> 
>> What kind of grob would an editor expect here? a Tie because it connects 
>> notes of the same pitch, or a Slur because it connects notes at 
>> different staff positions? (or something else?)
> ...
>> 
>> I think the question is answered from the musical point of view: Werner's 
>> example is a tie since it is the same pitch, the same note with longer 
>> value. In your example, the pitches are formally different, and the 
>> difference is a comma in the Pythagorean tone system, so it must be a slur.
> 
> This sounds like an answer to a question I didn't ask.  I don't doubt that 
> the arc in Werner's example is semantically a tie.  What I am wondering is 
> what kind of LilyPond grob should represent the arc, and I'm thinking that it 
> should be a Slur because of its shape, not a Tie because of its purpose.

I think that slurs and ties may be rendered equally because of the legacy of 
drawing them by hand. But suppose they are different, then it should also have 
a tie look.

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 19:56, Werner LEMBERG  wrote:
> 
 The notes d♯ to e♭ have different pitches in the staff notation
 system, which cannot express E12 enharmonic equivalents, so this
 is slur. So it should be a slur that looks like slur.
> 
> I disagree.  For all practical purposes in standard classical music,
> enharmonic equivalents *do* sound the same.  What you are referring to
> IMHO is a special case that might be controlled by a flag.

They do not, and the string section, that primarily stands for the pitch 
reference, trains to slide the pitch appropriately:

In the video below, time 10:43, Brett mentions that the E (on the D string) 
against the open G, the sixth, is a bit lower than against the open A; the pure 
fourth. This is the syntonic comma 81/80, the difference between the Just 
Intonation major third 5/4, and the higher Pythagorean major third.
  https://www.youtube.com/watch?v=dW9t7Nrin_c=643

This is for adjusting towards Just Intonation, but it is necessary for 
enharmonic equivalents too, as the Pythagorean comma is the microtonal amount 
they use in Turkish music. A melody line will not sound right if not adjusted.

>> I can think of special cases: Perhaps the tie and the slur are
>> rendered slightly differently, say of different thickness, so in
>> Werner's example it should be a tie in style.  Somebody might want
>> to indicate an E12 enharmonic equivalence, as in your example, even
>> though it is not so in the staff notation system, and then it should
>> be a tie in style.
> 
> As mentioned above: This might be controlled by a flag.  Or maybe a
> special “E12_tie_slur” engraver can handle this.

You probably think of how to handle it internally, because syntactically one 
might just write a tie between enharmonic equivalents.

Re: tie over clef change

[Werner LEMBERG]

>>> The notes d♯ to e♭ have different pitches in the staff notation
>>> system, which cannot express E12 enharmonic equivalents, so this
>>> is slur. So it should be a slur that looks like slur.

I disagree.  For all practical purposes in standard classical music,
enharmonic equivalents *do* sound the same.  What you are referring to
IMHO is a special case that might be controlled by a flag.

> I can think of special cases: Perhaps the tie and the slur are
> rendered slightly differently, say of different thickness, so in
> Werner's example it should be a tie in style.  Somebody might want
> to indicate an E12 enharmonic equivalence, as in your example, even
> though it is not so in the staff notation system, and then it should
> be a tie in style.

As mentioned above: This might be controlled by a flag.  Or maybe a
special “E12_tie_slur” engraver can handle this.


Werner

Re: tie over clef change

[Dan Eble]

On Sep 26, 2020, at 13:11, Hans Åberg  wrote:
> 
>> 
>> On 26 Sep 2020, at 18:50, Dan Eble  wrote:
>> 
>> On Sep 26, 2020, at 12:34, Hans Åberg  wrote:
>>> 
 On 26 Sep 2020, at 18:04, Dan Eble  wrote:
 
> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
> 
> What kind of grob would an editor expect here? a Tie because it connects 
> notes of the same pitch, or a Slur because it connects notes at different 
> staff positions? (or something else?)
...
> 
> I think the question is answered from the musical point of view: Werner's 
> example is a tie since it is the same pitch, the same note with longer value. 
> In your example, the pitches are formally different, and the difference is a 
> comma in the Pythagorean tone system, so it must be a slur.

This sounds like an answer to a question I didn't ask.  I don't doubt that the 
arc in Werner's example is semantically a tie.  What I am wondering is what 
kind of LilyPond grob should represent the arc, and I'm thinking that it should 
be a Slur because of its shape, not a Tie because of its purpose.
— 
Dan

Re: tie over clef change

[Hans Åberg]

Re: tie over clef change

[Dan Eble]

On Sep 26, 2020, at 12:34, Hans Åberg  wrote:
> 
>> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
>> 
>>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>>> 
>>> What kind of grob would an editor expect here? a Tie because it connects 
>>> notes of the same pitch, or a Slur because it connects notes at different 
>>> staff positions? (or something else?)
>> 
>> I'll answer my own question.  A tie from d♯ to e♭ generates a Tie grob, so 
>> for consistency, this should be a Tie that looks like a slur.
> 
> The notes d♯ to e♭ have different pitches in the staff notation system, which 
> cannot express E12 enharmonic equivalents, so this is slur. So it should be a 
> slur that looks like slur.

I see.  Then that's a different case from Werner's example where the pitch is 
really the same.  So the question is unanswered.
— 
Dan

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 18:04, Dan Eble  wrote:
> 
>> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
>> 
>> On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:
>>> 
>>> 
>>> Despite Gould's “incorrect” verdict, here is an example from an old UE
>>> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
>>> over clef changes *do* happen and make sense sometimes...
>>> 
>>> I still think that LilyPond should support that, handling the tie like
>>> a slur in this case.
>> 
>> That's a very good example.  It's hard to imagine any reasonable alternative.
>> 
>> What kind of grob would an editor expect here? a Tie because it connects 
>> notes of the same pitch, or a Slur because it connects notes at different 
>> staff positions? (or something else?)
> 
> I'll answer my own question.  A tie from d♯ to e♭ generates a Tie grob, so 
> for consistency, this should be a Tie that looks like a slur.

The notes d♯ to e♭ have different pitches in the staff notation system, which 
cannot express E12 enharmonic equivalents, so this is slur. So it should be a 
slur that looks like slur.

Re: tie over clef change

[Aaron Hill]

On 2020-09-26 9:04 am, Dan Eble wrote:

On Sep 26, 2020, at 09:41, Dan Eble  wrote:

On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:



Despite Gould's “incorrect” verdict, here is an example from an old 
UE

edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
over clef changes *do* happen and make sense sometimes...

I still think that LilyPond should support that, handling the tie 
like

a slur in this case.


That's a very good example.  It's hard to imagine any reasonable 
alternative.


What kind of grob would an editor expect here? a Tie because it 
connects notes of the same pitch, or a Slur because it connects notes 
at different staff positions? (or something else?)


I'll answer my own question.  A tie from d♯ to e♭ generates a Tie
grob, so for consistency, this should be a Tie that looks like a slur.


An idea: Could Tie gain a new Boolean property that controls whether to 
slope a Tie or keep it horizontal when the end points do not share the 
same Y position?  That would give the user an easy way to have both 
options.


A more complex idea: This new property could be a number-pair? that 
provides even more control over the Y position of the ends.  Each number 
is an index value (e.g. LEFT, CENTER, RIGHT).  If the value is LEFT, 
then it is the left note's Y position that is used; RIGHT maps to the 
right note's Y position; and CENTER is the average of the two values.  
(Technically, any index value could be used to interpolate the Y 
positions.)  Simple horizontal ties that stick to the left note would 
use #'(-1 . -1), and #'(1 . 1) would hug the right note.  #'(-1 . 1) 
would slope the Tie like a Slur.



-- Aaron Hill

Re: tie over clef change

[Hans Åberg]

> On 26 Sep 2020, at 14:55, Werner LEMBERG  wrote:
> 
> Despite Gould's “incorrect” verdict, here is an example from an old UE
> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
> over clef changes *do* happen and make sense sometimes...
> 
> I still think that LilyPond should support that, handling the tie like
> a slur in this case.

A tie indicates that it is a note whose (time) value (normally) otherwise 
cannot be expressed in the notational system, thus having the same pitch, 
whereas a slur indicates an articulation of notes of different pitch, that they 
should be played together. What do you think it is in your example? :-)

Re: tie over clef change

[Dan Eble]

> On Sep 26, 2020, at 09:41, Dan Eble  wrote:
> 
> On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:
>> 
>> 
>> Despite Gould's “incorrect” verdict, here is an example from an old UE
>> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
>> over clef changes *do* happen and make sense sometimes...
>> 
>> I still think that LilyPond should support that, handling the tie like
>> a slur in this case.
> 
> That's a very good example.  It's hard to imagine any reasonable alternative.
> 
> What kind of grob would an editor expect here? a Tie because it connects 
> notes of the same pitch, or a Slur because it connects notes at different 
> staff positions? (or something else?)

I'll answer my own question.  A tie from d♯ to e♭ generates a Tie grob, so for 
consistency, this should be a Tie that looks like a slur.
— 
Dan

 

Re: tie over clef change

[Jean Abou Samra]

Le 26/09/2020 à 14:55, Werner LEMBERG a écrit :

Despite Gould's “incorrect” verdict, here is an example from an old UE
edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
over clef changes *do* happen and make sense sometimes...

I still think that LilyPond should support that, handling the tie like
a slur in this case.


 Werner


For reference, this is https://gitlab.com/lilypond/lilypond/-/issues/302

Re: tie over clef change

[Dan Eble]

On Sep 26, 2020, at 08:55, Werner LEMBERG  wrote:
> 
> 
> Despite Gould's “incorrect” verdict, here is an example from an old UE
> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
> over clef changes *do* happen and make sense sometimes...
> 
> I still think that LilyPond should support that, handling the tie like
> a slur in this case.

That's a very good example.  It's hard to imagine any reasonable alternative.

What kind of grob would an editor expect here? a Tie because it connects notes 
of the same pitch, or a Slur because it connects notes at different staff 
positions? (or something else?)
— 
Dan

tie over clef change

[Werner LEMBERG]

Despite Gould's “incorrect” verdict, here is an example from an old UE
edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
over clef changes *do* happen and make sense sometimes...

I still think that LilyPond should support that, handling the tie like
a slur in this case.


Werner

Re: Are lilypond output files subject to GPL?

[Jean Abou Samra]

Le 26/09/2020 à 01:11, Carl Sorensen a écrit :

After our two-day break as requested by Jean, I thought I'd look for
something definitive about the question raised by Karsten.

I haven't found any cases where this question has been adjudicated, so we
don't have the court's opinion on this.

However, the FSF has been active in defending Free Software, and created
the GPL 3.0, the AGPL 3.0, and LGPL 3.0 in response to court cases and user
behavior.  And I think you would be hard-pressed to find anybody who is
stronger in terms of asserting "copyleft" than the FSF.

With that in mind, I find these the answers to these two questions in the
FSF GPL 3.0 FAQ to be clear, convincing, and certain that there is no
mechanism by which GPL 3.0 applied to LilyPond or OLL can result in GPL
requirements for LilyPond output.

[see https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL ]


Is there some way that I can GPL the output people get from use of my
program? For example, if my program is used to develop hardware designs,
can I require that these designs must be free? (#GPLOutput
)

In general this is legally impossible; copyright law does not give you any
say in the use of the output people make from their data using your
program. If the user uses your program to enter or convert her own data,
the copyright on the output belongs to her, not you. More generally, when a
program translates its input into some other form, the copyright status of
the output inherits that of the input it was generated from.

So the only way you have a say in the use of the output is if substantial
parts of the output are copied (more or less) from text in your program.
For instance, part of the output of Bison (see above) would be covered by
the GNU GPL, if we had not made an exception in this specific case.

You could artificially make a program copy certain text into its output
even if there is no technical reason to do so. But if that copied text
serves no practical purpose, the user could simply delete that text from
the output and use only the rest. Then he would not have to obey the
conditions on redistribution of the copied text.
In what cases is the output of a GPL program covered by the GPL too? (
#WhatCaseIsOutputGPL
)

The output of a program is not, in general, covered by the copyright on the
code of the program. So the license of the code of the program does not
apply to the output, whether you pipe it into a file, make a screenshot,
screencast, or video.

The exception would be when the program displays a full screen of text
and/or art that comes from the program. Then the copyright on that text
and/or art covers the output. Programs that output audio, such as video
games, would also fit into this exception.

If the art/music is under the GPL, then the GPL applies when you copy it no
matter how you copy it. However, fair use
 may still apply.

Keep in mind that some programs, particularly video games, can have
artwork/audio that is licensed separately from the underlying GPLed game.
In such cases, the license on the artwork/audio would dictate the terms
under which video/streaming may occur. See also: Can I use the GPL for
something other than software?

Having this strong statement from the FSF, I feel no need to worry about
losing my music to the GPL.  If anybody has case law where this principle
is violated, I would be happy to hear it.

Thanks,

Carl
As far as I understand, David K. expressed that merely calling the
functionality has no implications. Getting a definite source for this
would be great because I do see the potential concerns with this
question; after all it would be different from linking to library
compiled from, say, C code under the GPL.


I suggest contacting the FSF's Compliance Lab linked on the FAQ you
mention (https://www.gnu.org/licenses/gpl-faq.html), at licens...@fsf.org.
Surely they can help us sort things out.

Regards,
Jean

Re: Are lilypond output files subject to GPL?

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Freitag, den 25.09.2020, 17:11 -0600 schrieb Carl Sorensen:
> After our two-day break as requested by Jean, I thought I'd look for
> something definitive about the question raised by Karsten.
> 
> I haven't found any cases where this question has been adjudicated, so we
> don't have the court's opinion on this.
> 
> However, the FSF has been active in defending Free Software, and created
> the GPL 3.0, the AGPL 3.0, and LGPL 3.0 in response to court cases and user
> behavior.  And I think you would be hard-pressed to find anybody who is
> stronger in terms of asserting "copyleft" than the FSF.
> 
> With that in mind, I find these the answers to these two questions in the
> FSF GPL 3.0 FAQ to be clear, convincing, and certain that there is no
> mechanism by which GPL 3.0 applied to LilyPond or OLL can result in GPL
> requirements for LilyPond output.
> 
> [...]
> 
> Is there some way that I can GPL the output people get from use of my
> program? For example, if my program is used to develop hardware designs,
> can I require that these designs must be free? (#GPLOutput
> )
> 
> [...]
> 
> So the only way you have a say in the use of the output is if substantial
> parts of the output are copied (more or less) from text in your program.

AFAICT this is partially the case for the Postscript output, see the
files in ps/ and in particular music-drawing-routines.ps, maybe also
parts of scm/framework-ps.scm and scm/output-ps.scm. (The font is also
embedded, but has an explicit "Font exception" for that case.)


> Having this strong statement from the FSF, I feel no need to worry about
> losing my music to the GPL.  If anybody has case law where this principle
> is violated, I would be happy to hear it.

I think this addresses only part of the questions, namely the
implications for the output. The other topic is sharing code that uses
OLL, which is much less clear to me but IANAL. I would generally agree
that LilyPond input files can be considered some form of "programming",
but it's beyond my knowledge how GPL applies to functional languages
like Scheme where there is no binary form. The main question (for me)
is:

Does "\include"ing OLL make the .ly file a "covered work" that is based
on OLL?

As far as I understand, David K. expressed that merely calling the
functionality has no implications. Getting a definite source for this
would be great because I do see the potential concerns with this
question; after all it would be different from linking to library
compiled from, say, C code under the GPL.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Run formatting tools

[Jonas Hahnfeld]

Am Freitag, den 25.09.2020, 21:14 +0200 schrieb Jean Abou Samra:
> Le 25/09/2020 à 16:39, Jonas Hahnfeld a écrit :
> 
> > Am Freitag, den 25.09.2020, 16:01 +0200 schrieb Jean Abou Samra:
> > > Le 25/09/2020 à 15:48, Jonas Hahnfeld a écrit :
> > > > Anyway, running black on all Python files gives the following error:
> > > > 
> > > >  error: cannot format 
> > > > /code/LilyPond/src/scripts/auxiliar/translations-status.py: INTERNAL 
> > > > ERROR: Black produced different code on the second pass of the 
> > > > formatter.
> > > 
> > >   I can't reproduce this. What is your version of Black? (Mine is 
> > > 19.3b0.) What line length did you use?
> > > 
> > > The latest, 20.8b1. Happens with both the default and -l 78.
> 
> Seems to be a known, recently introduced bug in Black.It's easy
> to work around it using --fast.

This will just skip the sanity check that future runs keep the
formatting. I don't consider this a valid workaround because we *will*
run the tool again later on.

Jonas


signature.asc
Description: This is a digitally signed message part