Unzufrieden mit \textMark

[Arnold]

Ja, mit der aktuellen Lösung des \textMark in LilyPond (Version 2.24.1) bin ich unzufrieden. Und gemäß Quelltext-Änderderungsprotokoll hat sich da auch bis in die 2.25.x nichts geändert.

Aber von vorne:
Ich möchte in der Regel mehrere Score-weite Anmerkungen (\mark und Co.) festlegen, z. Bsp. die Übe-Kennzeichen (A, B, C, ...) und Quell-Querverweis-Angaben (z. Bsp. in der Quell-Partitur Seite 17, System 1). Ersteres mit \mark; bei zweitem scheidet \mark aus, da es nicht gleichzeitig angewendet werden kann, und \textMark wird ohne Rücksicht auf eine Vielfachnennung von jedem Staff kommend mehrfach angezeigt, was mir zu umständlich ist, dies zu filtern.

Ich wäre ja nicht ich, wenn ich nicht schon eine Modifikation ausprobiert hätte:

• In music-functions-init.ly definiere ich \textMark und \textEndMark so um, daß diese noch optional ein Symbol akzeptieren. Dieses Symbol ist dann die Schlüsselkennung anhand derer ich die Doubletten aufräumen kann.
• In scheme-engravers.scm wird dann der angedeutete Doublettenfilter in den Text_mark_engraver hinzugefügt. Nur TextMarkEvents mit Schlüsselsymbol werden konsolidiert. Und da fand ich es sogar sinnvoller, jedes Schlüsselsymbol nicht nur in einem Zeitstempel (current-moment) einmal zuzulassen, sondern die Einmaligkeits-Prüfung auf die ganze Sequenz mit gleichen Main-Moment auszudehnen (also vom ersten Grace-Timing bis zum Grace-losen-Timing)
• Und wenn schon, dann hab ich mir ein neues Context-Property textMarkFilter (in define-context-properties.scm) definiert. Dadurch könnte man den Text_mark_engraver sowohl im Score- als auch im Staff-Kontext nutzen, wenn man alle \textMark mit entsprechenden Schlüsseln versieht und die Filterliste in den Kontexten so setzt, daß sie nur im gewünschten Kontext (Staff oder Score) erscheinen.
• Das ganze weckt dann noch mehr Begehrlichkeiten in mir: z. Bsp. Formatierungs-Vordefinitionen je nach Schlüssel-Symbol festlegen; oder den TextMark-Grob an der ersten Grace-Timing-Spalte verankern, auch wenn das TextMarkEvent erst zu einem späteren Grace-Timing verarbeitet wird; den Duplikate-Filter auch wieder deaktivieren können; mit einer Direction = #'both (oder so ähnlich) zwei Grobs (oberhalb und unterhalb) erstellen.

Welche Meinungen hat ihr dazu? Wäre solch eine Funktionserweiterung im Lilypond wünschenswert?

Außdem habe ich noch ein seltsames Verhalten (unregelmäßiges Aussehen der Positionierung) entdeckt, wenn die TextMarkEvents in einer Stimme ohne Grace-Notes notiert sind, eine andere Notenzeile aber zuvor Grace-Notes einfügt. Sieht mir also nach einem Bug der Kategorie ugly aus. Siehe dazu angehängtes PNG.

Ebenfalls im Anhang die Texte der umdefinierten Scheme-Funktionen und mein Test-Dokument welches dann das PNG-Bild erstellt hat. Aber nicht im Anhang die Definition des neuen von mir verwendeten Kontext-Properties textMarkFilter!

Arnold.

[Manuela]

Nur so auf die Schnelle. Was spricht dagegen, per Context den TextMark aus allen Staffs zu entfernen und einen neuen Staff-Context zu definieren, der TextMark enthält? Dieser wird dann als oberster Staff verwendet.

Ich habe gerade nachgelesen, dass TextMark wie RehearsalMark ebenfalls zum Score-Context gehört, wieso wird es dann bei jedem Staff angezeigt?

[Arnold]

Hallo Manuela,

das Konzept im TextMarkEngraver ist eben, daß mehrere »gleichzeitige« TextMark-Events auch alle angezeigt werden. Um ein »Bereinigen von Duplikaten« muß sich der Anwender selbst kümmern.

Beispiel: Man möchte (in Partitur und Einzelstimmen) Querverweise zu mehreren Quellen angeben - im Stil »Quelle Nr. A / Seite Nr. B / System Nr. C / (beginnt hier)«. Und dann noch zusätzliche (eventuell globale) Aufführungsanweisungen (»hier Licht im Saal ausschalten«, »Schuh ausziehen und dem Tenorhorn nebenan in den Schalltrichter legen«, u.s.w.).
Da der TextMarkEngraver die Events prinzipiell nicht unterscheiden kann, wird das ganze schnell zu einer "Schlacht mit Tags" damit in der Partitur und allen Einzelstimmen genau die richtigen TextMarks an der richtigen Stelle erscheinen.

Wenn ich nun die TextMarks mit einem Identifizierungs-Symbol kennzeichne, dann kann dieses auch zum »Aufräumen der Duplikate« herangezogen werden.

• Nur ein TextMark je Symbol zu einem Notenzeitpunkt. Auf die ganze Main-Moment-Periode (Hauptzeitpunkt plus vorangestellte Vorschlagsnotenzeitpunkte) angewandt bietet mir das ein »minimalistisches Grace-Echo-Purging (Issue 34, wenn auch nur eine einzige Erscheinungsform davon)«.
• Ich kann sowohl TextMarks für den Score-Context, als auch TextMarks für den Staff-Context angeben. Die Score-Context-TextMarks werden also auch dann richtig angezeigt, wenn z. Bsp. die eigentlich oberste Notenzeile mangels Noten darin ausgeblendet wird.
• Man kann auch verschiedene Formatierungen (z. Bsp. font-size, self-alginment-X, direction) für jedes Identifizierungs-Symbol festlegen, nicht nur eine globale Festlegung für alle TextMark-Grobs.
• In meinem aktuelle Programmcode ist auch schon abgedeckt, daß ich meinen erweiterten TextMarkEngraver anweisen kann, bei angegebenen Identifizierungs-Symbolen zwei TextMarkGrobs zu erstellen, einen über und einen unter dem System (ergo unabhängig von durch langen Pausen unterdrückten Notenzeilen). Nun ja, normalerweise sieht man so etwas für die RehearsalMarks (und Tempoangaben) in Partituren mit vielen Einzelstimmen.

Zusammengefaßt, für mich sind diese Änderungen einen deutliche Usability-Steigerung.
Und das alte Verhalten (ohne die optionalen Kennzeichner-Symbole) bleibt erhalten.

Und als Nachbemerkung:
Bis Version 2.22 habe ich meinen PolyMarkEngraver sehr intensiv benutzt. Mit der Umstellungen auf Version 2.24 habe ich den noch nicht wieder richtig zum Laufen gebracht. Alle aufgezählten zusätzlichen Features für den TextMarkEngraver hatte auch der PolyMarkEngraver abgedeckt.

Arnold.

[Arnold]

Die ganze Geschichte, warum:

Unsere Tenöre sind sehr wählerisch und mögen keinen Baßschlüssel. Wenn sie dagegen eine Abschrift aus dem Chorbuch (wo Tenor und Baß sich oft eine Notenzeile - im Baßschlüssel - teilen) mit \clef "treble_8" bekommen (weiterhin als Chorpartitur mit allen Singstimmen), dann singen sie auch sicherer und finden ihre Töne leichter.

Als Querverweis setze ich wie ein Rehearsal-Mark immer eine Anmerkung »Seite/System« über die Noten.

Erstelle ich es als \mark ist einerseits eine Kollision mit den echten Übebuchstaben möglich. Andererseits macht Lilypond 2.24 daraus ein Ad-hoc-Mark-Event und beschwert sich, daß ich doch einen anderen Typ nehmen sollte - falls keiner der Ablaufsteuerungs-Marks passt den \textMark.

Gesagt, getan. In der obersten Stimme (die gerade nicht pausiert) habe ich jeweils die \textMark hinzugefügt. Prompt waren meine Querverweise teilweise doppelt (oder noch öfter) übereinander gestapelt in den Noten. Schließlich habe ich für die Unisono-Abschnitte die Noten auch nur einmal abgeschrieben und in beiden Stimmen angezogen.

Also die \textMark noch mit einem \tag versehen, und in allen bis auf einer Stimme in den Unisono-Abschnitten wieder herausfiltern.
Das kann doch besser gehen als mit einer »Schlacht um die Tags«, war mein erster Gedanke:
Statt ein Symbol als Tag anzuhängen, könnte man doch genauso ein Symbol als optionalen Paramter am \textMark definieren und im Music-Event ablegen.
Dann könnte doch der Text_Mark_engraver von den so gekennzeichneten TextMarkEvents nur noch das zuerst ankommende Event akzeptieren - natürlich nach diesem Kennzeichen-Symbol und jedem Zeitschritt getrennt betrachtet.

Als ich über die Zeitschritt-Bedingung nachgedacht habe, kam die Idee, warum nicht über alle Grace-Zeitschritte hinweg bis zum Zeitschritt ohne Vorschlag. Sollte dann in einer Stimme vor den Vorschlägen eine \textMark mit Kennzeichnungs-Symbol definiert sein, und in einer anderen Stimme direkt vor der Hauptnote (da dort kein Vorschlag) mit dem gleichen Kennzeichnungs-Symbol, dann hätte ich doch ein Grace-Sync-Problem weniger zu bereinigen.

Und, basierend auf die Kennzeichnung wären noch ein paar weitere »usability-enhancements« möglich.

Und ja, ich war verwöhnt vom polyMarkEngraver, der aber seit den Änderungen in Version 2.24 nicht mehr funktioniert.

Arnold.

[Manuela]

Hmm, das klingt kompliziert. Im 6. Absatz bin ich dann ausgestiegen 

[Arnold]

Hallo Manuela,

stell die einmal die Notenschrift in einem Gitter ähnlich einem karierten Papier vor.

• Jede Zählzeit besitzt dann eine senkrechte Linie (musical paper column) zum Anheften der Notenköpfe, und links davon eine weitere (non-musical paper column) für mögliche Taktstriche, RehearsalMarks, Tempoangaben und ähnlichem.
• Diese Spalten (columns) gibt es aber nicht nur für die »Haupt«-Noten, sondern auch für die Vorschlagsnoten.
• Die Engraver arbeiten natürlich die Events in der vom Anwender in Lilypond-Syntax erstellten Musik Spaltenpaar (non-musical und musical) für Spaltenpaar von links nach rechts ab. Zuerst die Grace-Spalten (falls Vorschlagsnoten vorhanden sind), dann die normale Notenspalte, und dann weiter zur nächsten musikalischen Zählzeit.
• Kommt nun ein Mark-Event passend zur ersten Vorschlagsnote einer musikalischen Zählzeit im Engraver an, dann wird das GROB (Grafik-Objekt) an diese non-musical-paper-colum angehängt.
• Kommt nun ein weiteres Mark-Event (z. Bsp. von einer anderen Stimme) nochmal, aber erst nach den Vorschlagsnoten, ansonsten zur gleichen musikalischen Zählzeit, im Engraver an, dann wird es normalerweise wie ein Echo an der non-musical-paper-colum der Hauptzeit angehängt, wo es der Anwender eigentlich nicht haben will.
• Eine Echo-Unterdrückung wäre also, nur ein einziges Rehearsal-Mark für alle Spalten mit der gleichen musikalischen Zählzeit und unabhängig von der Vorschlagsposition zuzulassen.
• Mit solchen Echo-Unterdrückungen ließen sich zwar viele, aber keineswegs alle grace-sync-Probleme (bekanntes Issue-34) lösen.

Arnold

P.S.

Die Issue-Nummer 34 ist eigentlich um 8 zu klein. Dann hätte sie als 42 einen hübschen literarischen Bezug.