repeatTie - Bogen verlängert bis Notenkopfmitte?

Begonnen von martinmagtenor, Sonntag, 31. Dezember 2017, 11:46

« vorheriges - nächstes »

martinmagtenor

Hallo,

zufällig bin ich darüber gestolpert, dass Lilypond (hier 2.18.2) den Bogen eines reapeatTie bei den beiden Noten ober- und unterhalb der Notensystemmittellinie bis zur Mitte des Notenkopfes verlängert (und dafür auch etwas vertikal verschiebt). Gibt es einen Grund dafür? Oder ist es ein Bug?


\version "2.18.2"
\include "deutsch.ly"
% Im Violinschlüssel
{ \relative c'' { e4\repeatTie d\repeatTie c\repeatTie h\repeatTie a\repeatTie g\repeatTie f\repeatTie e\repeatTie } }
% Im Bassschlüssel
{ \relative c' { \clef bass g4\repeatTie f\repeatTie e\repeatTie d\repeatTie c\repeatTie h\repeatTie a\repeatTie g\repeatTie } }


Siehe auch Anhang (repeatTie-issues2.png).

Im obigen Beispiel sind im Violinschlüssel die Noten c und a und im Bassschlüssel e und c betroffen und es hat nichts mit der Richtung der Notenhälse zu tun!

Grüße

Martin

Malte

#1
Zitat von: martinmagtenor am Sonntag, 31. Dezember 2017, 11:46
Gibt es einen Grund dafür? Oder ist es ein Bug?
Ich würde sagen: ja und jein. Es ist meiner Meinung nach zumindest unschön.

Ja, es gibt sicher einen Grund dafür, daß zwischen Bögen für Noten auf und zwischen Linien das Verhalten unterschiedlich ist. Aber: Die Sache ist ein bißchen inkonsistent. Soweit ich das sehen kann, wird ein Bogen nämlich dann länger gesetzt, wenn sowohl der Notenkopf als auch der Bogen innerhalb des Systems liegen; aber sollte nicht eigentlich bei einem Notenkopf außerhalb mit einem Bogen innerhalb oder andersrum der Bogen ebenfalls länger sein (z. B. bei einem nach oben gehalsten g² und f¹ im Violinschlüssel)?\version "2.19.80"

music = \relative {
  f'''\repeatTie
  e\repeatTie
  d\repeatTie
  c\repeatTie
  b\repeatTie
  a\repeatTie
  g\repeatTie
  f\repeatTie
  e\repeatTie
  d\repeatTie
  c\repeatTie
  b\repeatTie
  a\repeatTie
  g\repeatTie
  f\repeatTie
  e\repeatTie
  d\repeatTie
  c\repeatTie
  b\repeatTie
  a\repeatTie
  g\repeatTie
  f\repeatTie
  e\repeatTie
}

{ \stemUp \music }

{ \stemDown \music }

{
    \override Staff.StaffSymbol.line-count = 9
    \stemUp \music
}

{
    \override Staff.StaffSymbol.line-count = 9
    \stemDown \music
}


Edit: Ich schreib mal an die bug-list, bisher gibt es dazu nämlich kein issue. Allerdings kanns natürlich sein, daß es andere Meinungen dazu gibt, ich berichte.

martinmagtenor

Zitat von: Malte am Sonntag, 31. Dezember 2017, 12:11
Zitat von: martinmagtenor am Sonntag, 31. Dezember 2017, 11:46
Gibt es einen Grund dafür? Oder ist es ein Bug?
Ich würde sagen: ja und jein. Es ist meiner Meinung nach zumindest unschön.

Ich habe mal in "Hals über Kopf" von Elaine Gould geblättert. Da nehmen die Bögen ja viel Raum ab Seite 65 ein. Dem entnehme ich, dass die Haltebögen nicht zu klein, mit deutlicher Wölbung und symmetrisch sein und vorzugsweise bis zur Notenmitte gehen sollen. Demnach wären die beiden identifizierten Ausnahmen eher als der Regelfall anzusehen.

Andererseits, für "mein" Problem habe ich keine direkte Entsprechung gefunden, aber die Betrachtung "Haltebogen" beim Systemwechsel (S. 121) kommt dieser Situation schon sehr nahe und da wird nur die Variante mit dem Bogen bis zur Mitte des Notenkopfes (falls kein Hals im Weg ist) gezeigt.

Nun ist repeatTie schon ein echter Sonderfall, denn links davon steht ja gar keine Note. Und auf Seite 66, also noch ziemlich am Anfang des Themas, steht: "Haltebögen beschränken sich auf nur einen Zwischenraum, wenn sie sehr kurz sind oder [...]". Das kommt der hier betrachteten Situation sehr nahe. Demzufolge sind die kurzen Bögen in Ordnung und sollten dann aber einheitlich verwendet werden. Falls dieser Argumentation gefolgt wird, wäre es ein Bug.

Im übrigen, die großen Bögen einzuklammern sieht dann auch ziemlich bescheiden aus.

Schau'n wir mal ...

Schönes neues Jahr

Martin

Malte

Bisher gabs nur eine Antwort, ungefähr ,,gehört so". Hab dann noch darauf hingewiesen, daß es meiner Meinung nach inkonsistent ist, was die äußersten Zwischenräume angeht (https://lists.gnu.org/archive/html/bug-lilypond/2017-12/msg00019.html), aber darauf kam jetzt keine weitere Antwort mehr.