Verbesserung der LilyPond-Eingabe-Syntax!?

[harm6]

Hallo zusammen,

z.Zt. findet auf der devel-list eine Diskussion statt, wie man die LilyPond-Eingabe-Syntax vereinfachen bzw verbessern kann.
Diese Diskussion wird nur von Entwicklern und erfahrenen Benutzern geführt.
Da wir (die diskutierenden) alle die Anfangsschwierigkeiten längst überwunden haben bzw mit den bestehenden Unzulänglichkeiten viel zu vertraut sind, kann ich mich des Eindrucks nicht erwehren kann, daß wir nicht die richtigen Personen sind ein solches Thema zu bereden, oder besser formuliert: wir lenken unsere Aufmerksamkeit vielleicht nicht auf die Dinge, die wirklich problematisch sind.
Zumindest denke ich, daß eine gewisse Diskussions-Grundlage fehlt, was Einsteigern (aber auch fortgeschrittenen Benutzern und Experten) das Leben schwer macht.

Somit die Frage(n) an alle (mit Schwerpunkt auf LilyPond-Neueinsteiger):

• Was macht den LilyPond-Einstieg schwer?
• Wo gibt es Inkonsequenzen?
• Ärgernisse?
• etc

Zur Abgrenzung:
Alle Fragen beziehen sich nur auf die Syntax die in einem .ly-file vorkommen kann!
Es geht nicht um scheme oder C++
Es geht nicht um features nach dem Motto "Ich hätte gerne, daß lily "xy" kann"

Über zahlreiche Antworten würde ich mich sehr freuen.
Ich beabsichtige nach einer Woche Eure Antworten auflistend zusammenzustellen und in die oben erwähnte Diskussion einfließen zu lassen.


Viele Grüße,
  Harm

[himatt]

zuerst fällt mir da die gesamte Problematik "Abstände" (Seitenlayout) ein. (sicher auch verbunden mit der Umgewöhnung an neue Befehle, nachdem ich mühsam die alten versuchte zu begreifen)

M.

[harm6]

Hallo,

zuerst fällt mir da die gesamte Problematik "Abstände" (Seitenlayout) ein.

Vielen Dank für Deine Antwort.
Kannst Du ein konkretes Beispiel angeben?
Ich weiß, es gibt tausend und einen Befehl fürs Spacing, es wäre daher schön, wenn Du an einem konkreten Beispiel ein konkretes Problem zeigen könntest.

Gruß,
  Harm

[kilgore]

Hi Harm,

Die folgende Befehle fallen mir Beispielsweise als umständlich ein:

Code: [Auswählen]

\override TextSpanner #'(bound-details left text)
\override Glissando #'(bound-details right padding)

Als Anfänger kommt man nicht wirklich drauf, und nicht mal meine Auto-Vervollständigung kommt hinterher. Andere "ähnliche" Befehle sind dagegen etwas einfacher zu merken:

Code: [Auswählen]

\override TextScript #'X-extent
\override Script #'staff-padding


Auch die Weise wie man custom Notenköpfe baut finde ich umständlich:

Code: [Auswählen]

\once \override NoteHead #'stencil = #ly:text-interface::print
\once \override NoteHead #'text = \markup { \musicglyph #"scripts.coda" }

Selbst nach viele Erfahrung muss ich solche Befehle mit Copy-Paste eingeben. Ich stelle es mir irgendwie einfacher vor:

Code: [Auswählen]

\once \override NoteHead #'custom-head = \markup { \musicglyph #"scripts.coda" }

Falls mir noch was einfällt sag ich Bescheid!!

Gruß
Nathan

[Arnold]

Hallo,

eigentlich bin ich ein schon einigermaßen erfahrerer Anwender, der durch CAD-Anwendungen und Programmiererfahrung auch vor manchen 'konzeptionellen' Stolpersteinen bewahrt war.

Wenn die Standardformatierung verändert werden soll, war und ist es immer eine mehr oder minder große Sucherei, bis man die richtigen \override bzw. \set Parameter und den richtigen Kontext findet.
Vielleicht ist ein großer Schritt zur Erleichterung nur eine Dokumentationsmethodik.

Wenn wieder einmal die Klammern nicht ausbalanziert sind, hilft meist nur die Erfahrung die exakte Fehlerstelle schnell zu funden.
Das ist vielleicht nur eine Frage der Editorunterstützung.

Arnold

[harm6]

Die folgende Befehle fallen mir Beispielsweise als umständlich ein:

\override TextSpanner #'(bound-details left text)
\override Glissando #'(bound-details right padding)

Als Anfänger kommt man nicht wirklich drauf, und nicht mal meine Auto-Vervollständigung kommt hinterher. Andere "ähnliche" Befehle sind dagegen etwas einfacher zu merken:

Vielen Dank für Deine Antwort!

Hast Du einen Vorschlag, wie man das syntaktisch einfacher gestalten könnte?
Bei den NoteHead-stencils hast Du ja mit
\once \override NoteHead #'custom-head = \markup { \musicglyph #"scripts.coda" }
einen Vorschlag gemacht. Wie könnte das dann hier aussehen?

Gruß,
  Harm

P.S.
Ich bin der Meinung, daß die meisten Vorschläge einen eigenen Thread durchaus verdienen würden, um sie dann ausführlicher zu diskutieren.
Hier soll aber erst mal nur gesammelt werden.
Wer das Bedürfnis hat etwas ausführlicher zu bereden möge bitte einen neuen Thread öffnen, vielleicht mache ich das auch selbst bei dem ein oder anderen Thema.

[harm6]

Wenn wieder einmal die Klammern nicht ausbalanziert sind, hilft meist nur die Erfahrung die exakte Fehlerstelle schnell zu funden.

Erst mal vielen Dank für Deine Antwort.

Du weißt es wahrscheinlich schon, aber den meisten wird es noch nicht geläufig sein:

Ab "2.17.0" werden die Klammern gezählt, und wenn es kein Paar von öffnender/schließender Klammer gibt, wird eine etwas substantiellere Warnung ausgegeben als bisher.

Gruß,
  Harm

[kilgore]

Hi Harm,

Hast Du einen Vorschlag, wie man das syntaktisch einfacher gestalten könnte?

Ja, im Prinzip das ganze mit bound-details und die Klammer auch wegstreichen:

Code: [Auswählen]

\override Glissando #'right-padding = #4
\override TextSpanner #'left-text = "rit. molto"

finde ich viel logischer....

Gruß
kil

[harm6]

Wir sind auf -devel übereingekommen diese Umfrage etwas anders zu gestalten.

1. Sie soll nicht nur auf Anfänger/Einsteiger fokussiert sein, sondern alle ansprechen, denn erfahrene Benutzer stolpern ja wahrscheinlich immer wieder über dieselben Unzulänglichkeiten in der Syntax und könnten dann wohl so einiges zu beklagen haben.

2. Der Fragenkatalog ist neu erstellt und wird in der selben Art und Weise auch auf der spanischen und französischen Liste veröffentlicht:

• Was findet Ihr verwirrend in der LilyPond-Syntax? Zum Beispiel: seid ihr manchmal unsicher in welcher Reihenfolge Code-Elemente geschrieben werden sollen oder welche Schreibweise benutzt werden muß (Klein- bzw Groß-Schreibung, CamelCase, Bindestriche)?
  
• Gibt es irgenwas besonders unverständliches oder kryptisches in der LilyPond-Syntax? Namen oder Symbole, die nicht zu den Objekten passen, die sie repräsentieren.
  
• Was findet ihr besonders lästig/unbequem an der LilyPond-Syntax? Zum Beispiel: Etwas das sich in Worten sehr einfach beschreiben läßt, aber einen größeren Aufwand erfordert es zu kodieren.
  
• Was findet ihr besonders schwer in der LilyPond-Syntax auszudrücken? Zum Beispiel: Gibt es irgendwo die Notwendigkeit etwas manuel zu bewegen, weil die innewohnende Logik nicht verständlich/zugänglich ist?

Gruß,
  Harm

[fairsein]

Mir fällt gerade etwas ein. Zur Zeit ist es in lilypond nicht möglich an einem Zeilenende z. B. ein D. S. al Kopf - Kopf einzufügen, wenn am Anfang des nächsten Taktes ein Kopf steht. Bisher musste man das immer stückeln.

[Arnold]

Zu genau diesem Thema habe ich schon länger eine Idee:
Das \mark Kommando (mit allem darunter) klonen - dann bleibt das \mark für die "Taktmarkiergungn" wie gehabt, ein \markLeft wäre für "RehearsalInstructions" zuständig, welche (standardmäßig) den Text linksbündig anzeigen, und ein \markRight wäre für "RehearsalInstructions" zuständig, welche (standardmäßig) den Text rechtsbündig ausgerichtet und mit "begin-of-line-invisible" anzeigen.
Die sollte ich wohl mal in der DEV-Site anfragen.

Arnold

[Arnold]

•Was findet ihr besonders lästig/unbequem an der LilyPond-Syntax? Zum Beispiel: Etwas das sich in Worten sehr einfach beschreiben läßt, aber einen größeren Aufwand erfordert es zu kodieren.

a) spreizende Platzhalter einfügen (z. Bsp. zwischen Noten) - ähnlich einem \breathe mit angegebener Breite und ohne sichtbaren Stencil

b) einfachere Eingabesyntax für den "hohen Baßschlüssel" (high bass clef) und den "nach unten oktavierten Violinschlüssel mit eingeklammerter Acht". Da habe ich schon erste Versuche gemacht für das Ziel

Code: [Auswählen]

\clef "bass^[8]"
 % und
\clef "treble_(8)".

c) einfachere Syntax um manuell die Balkensetzung in der zweiten Balkenebene angeben zu können. Vielleicht so:

Code: [Auswählen]

c32[[ c c c] c[ c c c]]
Arnold

[fugenkomponist]

Ich fänds gut, wenn

Code: [Auswählen]

\times 2/3 { a8 b c d e f g h i } das gleiche täte wie

Code: [Auswählen]

\times 2/3 { a8 b c } \times 2/3 { d e f } \times 2/3 { g h i }.

Damit solche Sachen wie

Code: [Auswählen]

\times 2/3 { a8 b c16 d } noch funktionieren, kann man aber nicht einfach in Dreiergruppen einteilen, sondern müsste das „2/3“ (was ja für „skaliere alles auf 2/3 und schreib ne 3 ran“ steht) wahrscheinlich erweitern zu „2/3 4“ für „skaliere alles auf 2/3 und schreib an jedes Viertel ne 3 ran“ o. ä.

Edit: Mir ist noch was eingefallen: Texte wie dolce, rit., poco a poco accel. etc. werden doch normalerweise kursiv geschrieben, oder? Könnte man das nicht zum Standardverhalten für a-"foo" machen? Wann braucht man jemals einen roman-Text?

[harm6]

Hallo zusammen,

die Vorschläge die bislang hier zusammengetragen wurden, sind genau von der Art, die mir vorschwebt.

Ich denke, ich werde die (selbstgesetzte) Frist von einer auf zwei Wochen verlängern.



Vielen, vielen Dank schon mal,
  Harm

[fugenkomponist]

Ich hab noch was:

Bei Kammermusik mit Klavier werden ja die anderen Instrumente auf kleineren Systemen dargestellt. Bisher kenn ich da nur so Konstrukte wie

Code: [Auswählen]

\new Staff \with{
    fontSize = #-3
    \override StaffSymbol #'staff-space = #(magstep -3)
    \override StaffSymbol #'thickness = #(magstep -3)
}Daran gefällt mir nicht, dass ich drei Sachen setzen muss, um eigentlich eine Sache zu bewirken (nämlich das ganze System kleiner zu kriegen) und außerdem fänd ich nen Default-Wert sinnvoll (es wird doch bestimmt nen Erfahrungswert oder Regeln geben, wieviel kleiner die anderen Instrumente oder auch ossia-Stimmen dargestellt werden).
Mit anderen Worten: ein \new SmallStaff oder \new Staff \with { size = small } wär schön. (Hm. Müsste vor das small jetzt noch ein # oder #' oder #" "? Hab mich nie genug damit befasst, um das zu durchblicken .)