das ist ein Bug! aber wo kann man den korrigieren?

[erich]

Hallo allen,

ich habe das Beispiel

Code Auswählen Erweitern

\score {
\relative {
  \set Staff.keyAlterations = #`((6 . ,FLAT)
                                 (5 . ,FLAT)
                                 (3 . ,SHARP))
  c'4 d e fis
  as4 bes c2
}}
zum Vorbild genommen und für meine Zwecke abgewandelt:

Code Auswählen Erweitern

\set Staff.keyAlterations =
       #`( (9 . ,(- KOMMA)) (11 . ,(- KOMMA))  (3 . ,(- KOMMA)) (8 . ,KOMMA) (10 . ,KOMMA))

In meiner Anwendung erhalte ich als Ergebnis (siehe unten); ich habe den Fehler nachträglich rot gefärbt. Die 1. und die 3. Note liegen eine Oktave auseinander und in beiden Fällen wird das Versetzungszeichen korrekter Weise nicht gesetzt; aber als Vorzeichen ist es falsch plaziert. Ich kann den Fehler natürlich in inkscape händisch korrigieren, aber weiß jemand ob man den Fehler selbst beheben kann und wo man ihn suchen müsste?

Gruß Erich

[Malte]

Hm ... mir ist überhaupt nicht klar, was der erwartete Output ist. Und was Kreuze und Bs in deiner 12-stufigen Notation bedeuten. Wäre außerdem die Frage, ob die Zahlenwerte, die du da angibst, sich auf 7- oder 12-Stufigkeit beziehen. Kannst du ein Minimalbeispiel konstruieren?

[erich]

Hallo Malte,

hier der Link http://lilypond.org/doc/v2.19/Documentation/notation/arabic-music.en.html zu dem eingangs zitierten Beispiel.
Ich denke zur Wirkungsweise von Vorzeichen braucht man hier nichts zu erklären. An dem beigefügten Notenbild ist zu erkennen, dass das rote # falsch plaziert ist, es wirkt korrekt auf die Versetzungszeichen der untersten und obersten Noten; entsprechend hätte es auch auf der Höhe dieser Noten plaziert werden müssen.

Gruß
Erich

[harm6]

ich habe das Beispiel

Code Auswählen Erweitern

\score {
\relative {
  \set Staff.keyAlterations = #`((6 . ,FLAT)
                                 (5 . ,FLAT)
                                 (3 . ,SHARP))
  c'4 d e fis
  as4 bes c2
}}
[...]
Die 1. und die 3. Note liegen eine Oktave auseinander

c und e liegen doch nie eine Oktave auseinander???

An dem beigefügten Notenbild ist zu erkennen, dass das rote # falsch plaziert ist,

Hmm, ich erkenne lediglich, daß es eingefärbt ist...

Alles andere ist absolut jenseits meines Verständnisses.


Geht das Beispiel irgendwie auch in standard Notation?


Gruß,
  Harm

[erich]

Hallo

danke für die Kommentare!

Und nochmal zur Erläuterung:
ich denke, man kann in dem Beispiel erkennen, dass zweimal die gleiche Notenfolge dargestellt ist:
einmal mit Versetzungszeichen und einmal ohne diese.
Wenn die Wirkung von set Staff.keyAlterations darin besteht, dass die entsprechenden Versetzungszeichen fortfallen,
kann man erkennen, dass das rote Vorzeichen an einer anderen Stelle wirkt, als es geschrieben steht.

Der Fehler tritt also nicht generell auf und lässt sich nicht in traditioneller Notatation erzeugen, wie mir scheint.
Man kann jedoch feststellen,
dass je Tonort nur ein Versetzungszeichen wirkt; man kann also beispielsweise bei F♯ und G♭ nicht gleichzeitig beide Versetzungszeichen unterdrücken.

@Harm: in QuintGen sind der 1. und der 3. Ton eine Oktave auseinander: im Beispiel ist die gestrichelte Linie die oberste Linie des sich unten anschließenden 3-Liniensystems, insofern haben die beiden Noten derselben Ort in ihrem jeweiligen System; darin ist auch der Zweck der QuintGen-Notation zu sehen.

Gruß Erich

eine Ergänzung: am Beispiel ist zu erkennen, dass jeweils nur ein Vorzeichen wirkt

[Arnold]

Hallo Erich,

wieso Lilypond mit deinem QuintGen bei den Vorzeichen dieses »Modulo-7-Verhalten« (?) zeigt, kann ich dir leider auch nicht sagen, denn lieder verspüre ich kein großes Bedürfnis, das QuintGen herauszusuchen und genauer zu analysieren. Für eine Fehleranalyse müßtest Du das QuintGen sowieso noch in ein »minimal«-Beispiel hineinpacken.

Und auch für die chromatische (13-stufige) Bohlen-Pierce-Notation mit Lilypond, erweitert um Teilschritte via Vor- bzw. Versetzungszeichen, habe ich mich bisher nicht näher interessiert - das sollte aber gegebenenfalls auf die gleichen Probleme treffen.

Also, ich glaube bei deinen Vorzeichen die Berechnung

Code Auswählen Erweitern

a = tone_number mod 7;
if a < 4
then
   relative_line_position = a + 7;
else
  relative_line_position = a;
endif
zu erkennen - alle angegebene Zahlen in deiner Liste werden also in den Bereich [4 .. 10] hineingemapt, und wenn außerhalb entsprechend oft um 7 erhöht oder erniedrigt.

Ich würde da als nächstes auch die anderen Zahlen probieren (offenbar von 0 bis 11 ist von dir gewünscht), und danach zusätzlich mit Oktav-Werten in der Liste. Dann könnte ich vielleicht auf die Spur kommen, was im QuintGen zu ergänzen wäre.

Arnold

P.S. Ich vermute noch einen Zusammenhang damit, daß auf der Internetseite [https://meyerich.pythonanywhere.com/Preetzise/default/snippet/6] das c'' so wie das g' dargestellt ist.

[Arnold]

Hallo Erich,

da ich (nur) vermute, daß die Vorzeichenpositionierung von Lilypond mit deinem QuintGen nicht zurecht kommt, aber noch kein QuintGen-Minimalbeispiel in diesem Thread eingefügt ist, kann auch das Folgende nur eine Sammlung von Vermutungen sein:

• In .../scm/output-lib.scm wird eine Funktion key-signature-interface::alteration-positions definiert, welche wahrscheinlich die beobachtete Modulo-7-Verteilung bewirkt, aber dein QuintGen erfordert wohl eine Modulo-12-Verteilung.
• Ob ein »lokales« Neudefinieren dieser Funktion (mit 12 statt 7 und 11 statt 6) ausreicht, weiß ich nicht.
• Ob man diese modifizierte Funktion unter neuem Namen definieren muß, und dann in einer globalen Variable (oder einem Override?) angeben muß, damit es wirkt, weiß ich auch nicht.
• Die »Holzhammer-Methode« wäre ein Abändern dieser Funktion in der genannten Datei der Installation - damit würdest Du wohl den »normalen Notensatz« lahmlegen.
• Wenn schon in die Installationsdatei eingegriffen werden muß, dann würde ich eine neue Kontextvariable definieren, die in der genannten Funktion abgefragt wird. Als Defaultwert würde ich die 7 festlegen, im QuintGen müßtest Du dann wohl ein override auf 12 angeben. Vielleicht könnte man aber anstelle der neuen Kontextvariablen auch die Länge des »default-scale-Vektors« abfragen.

Arnold.

[ingmar]

Bitte nehmt die Titel ("Betreff") ernster.

Es geht hier im Forum nach meinem Verständnis nicht einfach nur darum, dir, Erich, zu helfen, sondern dabei eine Datenbank für zukünftige Hilfesuchende bereitzustellen. Letzteres ist auf die Dauer auch wichtiger, mir persönlich jedenfalls - sorry.

Ehrlich, auf eine Anfrage "Das ist ein Bug!", gestellt von einem halbwegs erfahreneren Mitglied, würde ich persönlich gar nicht reagieren.

Sorry, wenn das jetzt etwas ausdrücklich rüberkommt, aber ich denke, ihr versteht, was ich will.


--ingmar

[erich]

Hallo Igmar,

warum hast Du überhaupt reagiert. Sieh Dir die Antwort von Arnold an! mir hilft sie weiter.

Gruß Erich

[erich]

Hallo Arnold,

danke für Deinen Hinweis, dem ich nachgehen werde. Ein QuintGen-Minimalbeispiel wäre für dieses Forum viel zu lang; ich pflege deshalb auf meine Ausarbeitungen auf meiner Internetseite zu verweisen. Wenn Du möchtest, stelle ich Dir (und auch jedem anderen (und jeder anderen)) alles gerne zur Verfügung.

Gruß Erich

[Arnold]

Hallo Erich,

bitte werte das jetzt nicht gleich als Zynik: Du hast ja nicht gesagt, ob der Bug in Lilypond oder in deinem QuintGen liegt! 

Ein Quasi-Minimalbeispiel als gezipte Dateianlage wäre trotzdem nicht so abwegig
- oder ein Link auf ein »fertiges Paket« auf deiner Seite
- oder eine Minimalbeispiel, das aber nur funktioniert, wenn die weitern LILYPOND-Include-Dateien (als ZIP-Paket auf deiner Seite zusammengestellt, der Link dazu angegeben) heruntergeladen und im aktuellen Arbeitsverzeichnis abgelegt werden.

Als Kunde anderer Softwarhersteller steht zuerst die »Problembeschreibung«, und erst nach der Analyse entscheidet sich, ob es ein »Fehler« ist, der (möglichst schnell) zu beheben ist (oder es gibt akzeptable Workarounds - dann dauert die Behebung teilweise sehr lange), oder ob es ein »Erweiterungsanliegen« ist, weil es in der ursprünlichen Spezifikation nicht enthalten war.

In diesem Fall ist die Verteilung der Vorzeigen (d. h. in welcher Oktave sie dargestellt werden) nur für die siebenstufige Tonskala definiert. Für die zwölftstufige bist Du wohl der erste Anwender mit Vorzeichen.
→ »quasi Enhancement Request, außerhalb der bisherigen Spezifikation«

Du kannst mal folgende abgeändere Funktion ausprobieren (ohne Gewähr natürlich):

Code Auswählen Erweitern

#(define-public (quintgen-key-signature-interface::alteration-positions
                entry c0-position grob)
  (let ((step (car entry))
        (alter (cdr entry)))
    (if (pair? step)
        (list (+ (cdr step) (* (car step) 12) c0-position))
        (let* ((c-position (modulo c0-position 12))
               (positions
                '(6)) ;;; global value, independent of clef
                ;;; (if (< alter 0)
                ;;;     ;; See (flat|sharp)-positions in define-grob-properties.scm
                ;;;     (ly:grob-property grob 'flat-positions '(3))
                ;;;     (ly:grob-property grob 'sharp-positions '(3))))
               (p (list-ref positions
                            (if (< c-position (length positions))
                                c-position 0)))
               (max-position (if (pair? p) (cdr p) p))
               (min-position (if (pair? p) (car p) (- max-position 11)))
               (first-position (+ (modulo (- (+ c-position step)
                                             min-position)
                                          12)
                                  min-position)))
          (define (prepend x l) (if (> x max-position)
                                    l
                                    (prepend (+ x 12) (cons x l))))
          (prepend first-position '())))))

#(set! key-signature-interface::alteration-positions quintgen-key-signature-interface::alteration-positions)

Selbstverständlich ist dann nur die QuintGen-Darstellung möglich.
Den »oberen Rand« für die Vorzeichenpositionen habe ich auch willkürlich festgelegt, unabhängig von der Lage der C-Linie im QuintGen-System. Normalerweise wäre es mit zwölf statt sieben Werten in flat-positions und sharp-positions zu regeln.

Und, was mit diesem Beispiel nicht geht, ich aber als günstig empfinden würde:
Ein Notensystem (z. Bsp. StaffGroup) aus zwei Notenzeilen anzeigen, bei dem die eine Notenzeile in unserer traditionellen Notation geschrieben ist, die andere Notenzeile den gleichen musikalischen Inhalt in der QuintGen-Darstellung aufzeigt.
So etwas ähnliches mache ich hin und wieder mit einer Tabulatur-Notenzeile zusätzlich nur Standard-Notenzeile.

Arnold.

P.S. "It's not a bug, it's not a feature, then it's design philosophy"

[erich]

Hallo Arnold,

vielen Dank für Deine Mühe!

Ich habe Deinen Vorschlag in QuintGen36 eingebaut und siehe: es funzt

Du kannst es Dir unter https://meyerich.pythonanywhere.com/QuintGen36 ansehen. Die Versetzungszeichen stehen im Prinzip am richtigen Ort, nur die graphische Feinjustierung stimmt noch nicht; da muss ich noch dran arbeiten.

Gruß Erich