Re: tie over clef change

[Lukas-Fabian Moser]

However, this gets *never* notated as such.

I gave the example of augment sixth chords, that seem to never be notated as 
diminished sevenths.
https://en.wikipedia.org/wiki/Augmented_sixth_chord


I assume you meant "dominant sevenths"? (Augmented sixth chords, at 
least "Italian" and "German" augmented sixths, are identical to dominant 
sevenths without or with fifth on a modern keyboard, e.g. c-e-[g]-a♯ vs. 
c-e-[g]-b♭, but none of them yield diminished sevenths.)


But anyway, I'm not sure that your statement holds true invariably: I'm 
pretty sure that in late 19th century composers like Bruckner, the 
difference between both chords becomes blurry. I will see if I can find 
an example, maybe even older than Bruckner.


On a related but different note, I always found it funny how certain 
editors of Mozart's Requiem, of all things, tried to "improve" Mozart's 
chromatic/enharmonic spelling. See the old Peters vocal scores on IMSLP 
at the end of the "Confutatis maledictis"


vs. the original Mozart spelling (which Süßmayr preserved faithfully):

I would not claim that this change generates any measurable difference 
in what the musicians actually play and sing, but I imagine it changes 
the way they _think_ their lines. In particular, I like Mozart's 
notation for the clarity with which he expresses that he uses the 
diminished seventh as a triple-leading tone neighbour to the ensuing 
dominant seventh - not to mention the fact that this exact device is all 
over the place in the second half of the Confutatis, and it's frankly 
silly to change it just once, only to avoid a double flat...


Lukas

Re: tie over clef change

[Jean Abou Samra]

Hi all,

So, I've tried to follow this thread, but with 35 messages, this is 
becoming difficult...


Could someone make a short summary of what is at stake here? What should 
we decide?


Thanks,
Jean

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 22:17, Werner LEMBERG  wrote:
> 
>>> It is common, for example, for a composer to write D sharp for some
>>> instruments and E flat for others.
>> 
>> A composer should write so that it becomes easy for the musician to
>> perform, otherwise they will have to edit the score, which costs
>> time and money.  The musicians then listens to the other musicians
>> and adapt so it sounds right—this is what one of my flute teachers
>> said, who sits in an opera here.  Or modern composers just haven't
>> checked it out. Some do, though.
> 
> Well, almost all orchestra musicians think linearly, this is,
> horizontally, not vertically.  Consequently, composers (at least up to
> the late romantic era) write music that can be easily read linearly.
> This is what sometimes leads to have d sharp and e flat at the same
> time.

Right. For example, on older clarinets, it was difficult to switch between 
flats and sharps, having B♭ and A clarinets, so it must be written for that. 
With modern mechanics, it does not matter so much.

> Hans, please note that your opinion is that of a minority IMHO.  

You are free to implement whatever you like, as you are ones doing it.

> In
> all classical, romantic, or impressionistic scores that I'm aware of,
> pitches of enharmonic changes are completely insignificant.  Musicians
> are expected to automatically adjust the pitch so that it sounds ok
> within chords.  

They will adjust even if it is written it enharmonically wrong. But if one is 
choosing it wrong on an instrument that can play it accurately, one gets a wolf 
interval, which sounds like it is named.

> However, this gets *never* notated as such.

I gave the example of augment sixth chords, that seem to never be notated as 
diminished sevenths.
https://en.wikipedia.org/wiki/Augmented_sixth_chord

> Consequently, we have ties between enharmonic changes and not slurs.

Whatever.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 22:01, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser  wrote:
>>> 
 I seem to remember that even in Bach's B minor mass (where E12 was not
 yet a thing) there is an enharmonic tie (or at least tonal repetition?)
 in the transition from "Confiteor" to "Et expecto".  I mean, that
 transition is a tonal center nightmare anyway.
 
>>> In bar 138:
>>> 
>>> 
>>> 
>>> Basically that is an example of enharmonic equivalence of diminished
>>> 7th chords: The tonal centre in the preceding bars is clearly d (d
>>> major with hints of d minor), so the diminished chord in bar 138 is
>>> most probably first heard as f♯-a-c-e♭ (with expected resolution to
>>> g minor), but is then being re-interpreted (and written) as
>>> f♯-a-b♯-d♯, resolving to c♯ major functioning as a dominant to f♯
>>> minor.
>>> My point is: Even without E12 tuning, this is clearly an example of
>>> fully exploited enharmonic equivalence used as a "wormhole" in an
>>> otherwise purely diatonic tonal system. There can be no question
>>> that this is semantically a tie.
>>> 
>>> (One might raise the objection that, maybe, when performing the
>>> piece, a slight adjustment in intonation might be needed in the
>>> transition from c to b♯. But this can also happen for bona fide ties
>>> in purely diatonic music, so that does not yield an argument against
>>> the tie being a tie.)
>> 
>> I think it is the last, because E12 was not in use is the music that
>> J.S. Bach wrote. The CPP (Common Practise Period) composers are
>> careful distingushing between an augmented 6th a minor 7th in
>> chords. There is a slight adjustment from the formal point of view,
>> but for a violin to be able to express that, there needs to be some
>> pitch references, like the open strings or intervals derived from
>> that, so it may be a way to just adhere to formal writing.
> 
> The tonal center collapse is done purely vocally in an a cappella
> passage and when the instruments come back in, it's in a resurrection
> key and instrument groups (like brass) that are typical for it.
> 
> Really, you need to listen to it before sorting it into the context of
> its period.  This passage is completely out of whack with its time while
> it is arrived at from a grandiosely conservative fugue in full ars
> antiqua.
> 
> Here is a link  to a
> Herreweghe version.  The piano extract displayed in parallel would
> suggest that there is, after all, an instrumental part even in the 2:30
> and finally 3:00 (or so) locations which is a bit surprising to me since
> I remember how we fought keeping the intonation in line so that the
> resurrection trumpets could fall right in.  I cannot hear instruments
> there right now but I have only builtin speakers at low volume right now
> so I may be wrong about that.

The choirs here have a high number of performers with absolute pitch. By 
contrast, most orchestral musicians don't have it, and it is easier to play 
pitches exactly with musical instruments. Some singing, like barbershop, use 
Just Intonation, and if the chords are pivoted, the pitches must slide in some 
common harmony transitions.

Re: tie over clef change

[Werner LEMBERG]

>> It is common, for example, for a composer to write D sharp for some
>> instruments and E flat for others.
> 
> A composer should write so that it becomes easy for the musician to
> perform, otherwise they will have to edit the score, which costs
> time and money.  The musicians then listens to the other musicians
> and adapt so it sounds right—this is what one of my flute teachers
> said, who sits in an opera here.  Or modern composers just haven't
> checked it out. Some do, though.

Well, almost all orchestra musicians think linearly, this is,
horizontally, not vertically.  Consequently, composers (at least up to
the late romantic era) write music that can be easily read linearly.
This is what sometimes leads to have d sharp and e flat at the same
time.

Hans, please note that your opinion is that of a minority IMHO.  In
all classical, romantic, or impressionistic scores that I'm aware of,
pitches of enharmonic changes are completely insignificant.  Musicians
are expected to automatically adjust the pitch so that it sounds ok
within chords.  However, this gets *never* notated as such.
Consequently, we have ties between enharmonic changes and not slurs.


Werner

Re: tie over clef change

[David Kastrup]

Kevin Barry  writes:

>> Both cases were discussed. For an orchestra they are not the same
> pitch, thus formally a slur.
>
> You cannot make this assumption. It is exceptional to distinguish D
> sharp and E flat since most performed orchestral music is equally
> tempered. It is common, for example, for a composer to write D sharp
> for some instruments and E flat for others.

Distinguishing D♯ from E♭ formally when some instruments are written in
transposing keys is also a recipe for trying to read more into the
intonation than the composer was intent rather than forced to place
there.

-- 
David Kastrup

Re: tie over clef change

[David Kastrup]

Hans Åberg  writes:

>> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser  wrote:
>> 
>>> I seem to remember that even in Bach's B minor mass (where E12 was not
>>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>>> in the transition from "Confiteor" to "Et expecto".  I mean, that
>>> transition is a tonal center nightmare anyway.
>>> 
>> In bar 138:
>> 
>> 
>> 
>> Basically that is an example of enharmonic equivalence of diminished
>> 7th chords: The tonal centre in the preceding bars is clearly d (d
>> major with hints of d minor), so the diminished chord in bar 138 is
>> most probably first heard as f♯-a-c-e♭ (with expected resolution to
>> g minor), but is then being re-interpreted (and written) as
>> f♯-a-b♯-d♯, resolving to c♯ major functioning as a dominant to f♯
>> minor.
>> My point is: Even without E12 tuning, this is clearly an example of
>> fully exploited enharmonic equivalence used as a "wormhole" in an
>> otherwise purely diatonic tonal system. There can be no question
>> that this is semantically a tie.
>> 
>> (One might raise the objection that, maybe, when performing the
>> piece, a slight adjustment in intonation might be needed in the
>> transition from c to b♯. But this can also happen for bona fide ties
>> in purely diatonic music, so that does not yield an argument against
>> the tie being a tie.)
>
> I think it is the last, because E12 was not in use is the music that
> J.S. Bach wrote. The CPP (Common Practise Period) composers are
> careful distingushing between an augmented 6th a minor 7th in
> chords. There is a slight adjustment from the formal point of view,
> but for a violin to be able to express that, there needs to be some
> pitch references, like the open strings or intervals derived from
> that, so it may be a way to just adhere to formal writing.

The tonal center collapse is done purely vocally in an a cappella
passage and when the instruments come back in, it's in a resurrection
key and instrument groups (like brass) that are typical for it.

Really, you need to listen to it before sorting it into the context of
its period.  This passage is completely out of whack with its time while
it is arrived at from a grandiosely conservative fugue in full ars
antiqua.

Here is a link  to a
Herreweghe version.  The piano extract displayed in parallel would
suggest that there is, after all, an instrumental part even in the 2:30
and finally 3:00 (or so) locations which is a bit surprising to me since
I remember how we fought keeping the intonation in line so that the
resurrection trumpets could fall right in.  I cannot hear instruments
there right now but I have only builtin speakers at low volume right now
so I may be wrong about that.

-- 
David Kastrup

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 20:59, Kevin Barry  wrote:
> 
>> Both cases were discussed. For an orchestra they are not the same pitch, 
>> thus formally a slur.
> 
> You cannot make this assumption. It is exceptional to distinguish D
> sharp and E flat since most performed orchestral music is equally
> tempered.

Orchestral music is in what microtonalists call adaptive 5-limit Just 
Intonation; Hindemith calls it the natural tuning. A measurement of a 
performance of a string quartet that should have been (atonal) E12 showed that 
it in reality it was in something like Pythagorean. There are not references 
for playing in E12, unless there are som such instruments added, and using 
would make the harmonies sound less focused.

> It is common, for example, for a composer to write D sharp
> for some instruments and E flat for others.

A composer should write so that it becomes easy for the musician to perform, 
otherwise they will have to edit the score, which costs time and money. The 
musicians then listens to the other musicians and adapt so it sounds right—this 
is what one of my flute teachers said, who sits in an opera here. Or modern 
composers just haven't checked it out. Some do, though.

Re: tie over clef change

[Kevin Barry]

> Both cases were discussed. For an orchestra they are not the same pitch, thus 
> formally a slur.

You cannot make this assumption. It is exceptional to distinguish D
sharp and E flat since most performed orchestral music is equally
tempered. It is common, for example, for a composer to write D sharp
for some instruments and E flat for others.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser  wrote:
> 
>> I seem to remember that even in Bach's B minor mass (where E12 was not
>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>> in the transition from "Confiteor" to "Et expecto".  I mean, that
>> transition is a tonal center nightmare anyway.
>> 
> In bar 138:
> 
> 
> 
> Basically that is an example of enharmonic equivalence of diminished 7th 
> chords: The tonal centre in the preceding bars is clearly d (d major with 
> hints of d minor), so the diminished chord in bar 138 is most probably first 
> heard as f♯-a-c-e♭ (with expected resolution to g minor), but is then being 
> re-interpreted (and written) as f♯-a-b♯-d♯, resolving to c♯ major functioning 
> as a dominant to f♯ minor.
> My point is: Even without E12 tuning, this is clearly an example of fully 
> exploited enharmonic equivalence used as a "wormhole" in an otherwise purely 
> diatonic tonal system. There can be no question that this is semantically a 
> tie.
> 
> (One might raise the objection that, maybe, when performing the piece, a 
> slight adjustment in intonation might be needed in the transition from c to 
> b♯. But this can also happen for bona fide ties in purely diatonic music, so 
> that does not yield an argument against the tie being a tie.)

I think it is the last, because E12 was not in use is the music that J.S. Bach 
wrote. The CPP (Common Practise Period) composers are careful distingushing 
between an augmented 6th a minor 7th in chords. There is a slight adjustment 
from the formal point of view, but for a violin to be able to express that, 
there needs to be some pitch references, like the open strings or intervals 
derived from that, so it may be a way to just adhere to formal writing.

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 20:20, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 27 Sep 2020, at 19:31, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
> 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.
>>> 
>>> We are talking about a piano here.  It has no different keys for d♯ and
>>> e♭ and only a single manual.  A slur even across the same pitch will be
>>> executed with a separate keypress as opposed to a tie.
>> 
>> If you look down the thread, there are two different questions, when
>> expressing it in the staff notation as is, and when forcing E12
>> enharmonic equivalents onto it.
>> 
>> And not all pianos are tuned in E12, as in the case of meantone
>> tunings.
> 
> I repeat: It has no different keys for d♯ and e♭ and only a single
> manual.  Yes, I know about historical split-key instruments but that is
> not what a modern piano composer is writing for.

Both cases were discussed. For an orchestra they are not the same pitch, thus 
formally a slur.

Re: tie over clef change

[David Kastrup]

Hans Åberg  writes:

>> On 27 Sep 2020, at 19:31, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 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.
>> 
>> We are talking about a piano here.  It has no different keys for d♯ and
>> e♭ and only a single manual.  A slur even across the same pitch will be
>> executed with a separate keypress as opposed to a tie.
>
> If you look down the thread, there are two different questions, when
> expressing it in the staff notation as is, and when forcing E12
> enharmonic equivalents onto it.
>
> And not all pianos are tuned in E12, as in the case of meantone
> tunings.

I repeat: It has no different keys for d♯ and e♭ and only a single
manual.  Yes, I know about historical split-key instruments but that is
not what a modern piano composer is writing for.

>> I seem to remember that even in Bach's B minor mass (where E12 was not
>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>> in the transition from "Confiteor" to "Et expecto".  I mean, that
>> transition is a tonal center nightmare anyway.
>> 
>> I'd have to consult my score to pick out the details.
>
> It would be of interest.

Lukas has picked out the bar elsewhere in the thread.

-- 
David Kastrup

Re: tie over clef change

[Hans Åberg]

> On 27 Sep 2020, at 19:31, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> 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.
> 
> We are talking about a piano here.  It has no different keys for d♯ and
> e♭ and only a single manual.  A slur even across the same pitch will be
> executed with a separate keypress as opposed to a tie.

If you look down the thread, there are two different questions, when expressing 
it in the staff notation as is, and when forcing E12 enharmonic equivalents 
onto it.

And not all pianos are tuned in E12, as in the case of meantone tunings.

> I seem to remember that even in Bach's B minor mass (where E12 was not
> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
> in the transition from "Confiteor" to "Et expecto".  I mean, that
> transition is a tonal center nightmare anyway.
> 
> I'd have to consult my score to pick out the details.

It would be of interest.

Re: tie over clef change

[David Kastrup]

Lukas-Fabian Moser  writes:

>>  I seem to remember that even in Bach's B minor mass (where E12 was not
>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>> in the transition from "Confiteor" to "Et expecto".  I mean, that
>> transition is a tonal center nightmare anyway.
>
> In bar 138:


> Basically that is an example of enharmonic equivalence of diminished
> 7th chords: The tonal centre in the preceding bars is clearly d (d
> major with hints of d minor), so the diminished chord in bar 138 is
> most probably first heard as f♯-a-c-e♭ (with expected resolution to g
> minor), but is then being re-interpreted (and written) as f♯-a-b♯-d♯,
> resolving to c♯ major functioning as a dominant to f♯ minor.
>
> My point is: Even without E12 tuning, this is clearly an example of
> fully exploited enharmonic equivalence used as a "wormhole" in an
> otherwise purely diatonic tonal system. There can be no question that
> this is semantically a tie.

Thanks for digging this up: I knew there was something like that in
there.

-- 
David Kastrup

Re: tie over clef change

[David Kastrup]

Jean Abou Samra  writes:

> Le 27/09/2020 à 19:37, David Kastrup a écrit :
>
>> (in-chord slurs are not reallya good reference since
>> they currently suck with regard to theirpositioning). 
> By the way... if you have information about this, that's very
> welcome in https://gitlab.com/lilypond/lilypond/-/issues/5616!

The only information I have is that I implemented in-chord slurs since
there was a need for them, and the graphical representation is a very
rough sketch of what should be there since I have no real clue about
background programming.  My expectation was that some of the backend
gurus like Keith O'Hara would take this up and put sensible code in the
graphical output code.

That hasn't really happened (Keith in particular became a less frequent
visitor around that time).  So it's not as much a matter of fixing
something that isn't working as intended as it is of implementing sane
graphical output methods in the first place.

-- 
David Kastrup

Re: tie over clef change

[Lukas-Fabian Moser]

I seem to remember that even in Bach's B minor mass (where E12 was not
yet a thing) there is an enharmonic tie (or at least tonal repetition?)
in the transition from "Confiteor" to "Et expecto".  I mean, that
transition is a tonal center nightmare anyway.


In bar 138:

Basically that is an example of enharmonic equivalence of diminished 7th 
chords: The tonal centre in the preceding bars is clearly d (d major 
with hints of d minor), so the diminished chord in bar 138 is most 
probably first heard as f♯-a-c-e♭ (with expected resolution to g minor), 
but is then being re-interpreted (and written) as f♯-a-b♯-d♯, resolving 
to c♯ major functioning as a dominant to f♯ minor.


My point is: Even without E12 tuning, this is clearly an example of 
fully exploited enharmonic equivalence used as a "wormhole" in an 
otherwise purely diatonic tonal system. There can be no question that 
this is semantically a tie.


(One might raise the objection that, maybe, when performing the piece, a 
slight adjustment in intonation might be needed in the transition from c 
to b♯. But this can also happen for bona fide ties in purely diatonic 
music, so that does not yield an argument against the tie being a tie.)


Lukas

Re: tie over clef change

[Jean Abou Samra]

Le 27/09/2020 à 19:37, David Kastrup a écrit :


(in-chord slurs are not reallya good reference since
they currently suck with regard to theirpositioning). 

By the way... if you have information about this, that's very
welcome in https://gitlab.com/lilypond/lilypond/-/issues/5616!

Cheers, Jean

Re: tie over clef change

[David Kastrup]

Dan Eble  writes:

> 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.

Slur/Tie have graphical function, not musical function like stream
events.  So it's more a question of practicality than philosophy what to
use here, and it could even be something else like EnharmonicTie with
both slur-interface and tie-interface.

Tie endpoints tend to be different from slur endpoints since they
connect noteheads more than note columns (in-chord slurs are not really
a good reference since they currently suck with regard to their
positioning).

-- 
David Kastrup

Re: tie over clef change

[David Kastrup]

Hans Åberg  writes:

>> 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.

We are talking about a piano here.  It has no different keys for d♯ and
e♭ and only a single manual.  A slur even across the same pitch will be
executed with a separate keypress as opposed to a tie.

I seem to remember that even in Bach's B minor mass (where E12 was not
yet a thing) there is an enharmonic tie (or at least tonal repetition?)
in the transition from "Confiteor" to "Et expecto".  I mean, that
transition is a tonal center nightmare anyway.

I'd have to consult my score to pick out the details.

-- 
David Kastrup

Re: Run formatting tools

[Jean Abou Samra]

Le 26/09/2020 à 10:26, Jonas Hahnfeld a écrit :

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.


Actually, subsequent runs do keep the same formatting, but I don't 
understand why.


Jean

Re: Are lilypond output files subject to GPL?

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
 writes:

> 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.)

It's becoming of little relevance these days since those code fragments
don't survive into PDF or bitmap files (PDF does not have a programming
language, so they are not _translated_ into PDF but _executed_ in order
to produce PDF) and nobody really cares about distributing PostScript
files.  But yes, considering a different license for files, similarly to
what GCC code stubs are covered with, would be a part of licensing
hygiene.

>> 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?

While there is no way to reliably predict what any jury might find, I
don't think it makes sense to diverge too far from sanity for making
stipulations.

> 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.

It's worth pointing out that the legal theories surrounding the
connection between dynamic linking and being derived works have not
really been tested in court so far.  As long as nobody wants to test
that, the FSF uses this to achieve some leverage.  I doubt that they
would be terribly upset if they were challenged on that position and
lost in good faith in court as that would create a case of precedence
that would be helpful in other regards.  Basically, those with the means
to call their bluff stand to lose more than they do.

In the mean time, I don't think it makes sense to diverge too far from
sanity for making stipulations.

-- 
David Kastrup

PATCHES - Countdown for September 27th

[James Lowe]

Hello,

Here is the current patch countdown list. The next countdown will be on 
September 29th.


A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority


 Push:

!420 doc: Create directory for topdoc's NEWS.texi - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/420


 Countdown:

!422 Run formatting tools - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/422


 Review:

!423 ly_scm_list_t robustness - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/423

!418 CG: Revise Git documentation - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/418


 New:

No patches in New at this time.


 Waiting:

!386 Add \volta i,j,k command to mark volta-specific music - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/386

!344 doc: fully qualify doc includes. - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/344

!204 Move parallel processing to lilypond-book - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/204


***

Regards,

James

Re: tie over clef change

[Jean Abou Samra]

Le 27/09/2020 à 05:24, Andrew Bernard a écrit :

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


What do you mean? Currently { cis'1~ cis' } produces a Tie object.

Best,
Jean