Variable hat zweimal verschiedenen Wert (späteres Einfügen von \break) (GELÖST)

[ingmar]

hallo,

ich habe eine Variable mit Notentext und möchte dort "nachträglich" \break-Statements setzen - will meinen, die Variablendefinition selbst soll nicht angetastet werden.

Ich habs mit zwei Lösungen versucht, beide zeigen ein sehr auffälliges Fehlverhalten.

Die erste Lösung zitiert die Originalvariable stückweise, fügt \break ein, zitiert weiter usw:

Code: [Auswählen]

\version "2.18.2"

% Lässt man sich die Variable PART-A nach der Definition anzeigen, brauchen die 26 Takte vier Zeilen.
Auskommentieren der beiden \break-Statements zeigt: Das passt auch in drei Zeilen!
PART-A= \relative c' {
\repeat unfold 8 { c4 d e f }  % \break
\repeat unfold 9 { d4 e f g }  % \break
\repeat unfold 9 { e4 f g a }
}

% Hinzufügen der \breaks - Lösung 1:
PART-A = {
\addQuote "original" { \PART-A }
\quoteDuring #"original" { s1*8 } \break
\quoteDuring #"original" { s1*9 } \break
\quoteDuring #"original" { s1*9 }
}
\PART-A % Darstellung in vier Zeilen!
\PART-A % Darstellung in drei Zeilen!

Die zweite Lösung fügt zur Originalvariable eine stumme Stimme mit den entsprechenden \break-Statements hinzu:

Code: [Auswählen]

\version "2.18.2"

% Gleiche Definition wie oben:
PART-A= \relative c' {
\repeat unfold 8 { c4 d e f }
\repeat unfold 9 { d4 e f g }
\repeat unfold 9 { e4 f g a }
}

% Lösung 2:
PART-A = { <<
\PART-A
{
s1*8 \break
s1*9 \break
s1*9 \break
}
>>}
\PART-A % Darstellung in vier Zeilen!
\PART-A % Darstellung in drei Zeilen mit Doppelsystemen!

Anschließend zeigen wir die neugefüllte Variable zweimal an. Und sie wird prompt zweimal hintereinander verschieden dargestellt!! Beim ersten Mal hat sie offenbar die \break-Statements noch nicht verdaut, beim zweite Mal dann eben doch.

Wie kann das sein??

Gruß,
--ingmar

[harm6]

Hallo Ingmar,

beide Beispiele definieren eine Variable und rufen sie direkt danach auf.
Klappt in 2.18 nicht. Verdaungsproblem ist eine durchaus zutreffende Beschreibung.
In 2.19 läuft das besser (aber noch nicht optimal)

Darüberhinaus überläßt Du es LilyPond die Contexte zu erschaffen.
Im zweiten Beispiel sieht LilyPond zwei Voices und kreiert zwei Staffs.
Das ist der default.
Z.B.:
{ << c' e'' >> }
ergibt zwei Staffs.

Setze einfach \new Staff davor.

Gruß,
  Harm

[ingmar]

harm: beide Beispiele definieren eine Variable und rufen sie direkt danach auf. - Klappt in 2.18 nicht.

tja, was könnte ich denn in der zwischenzeit machen, um die verdauung zu beschleunigen? einmal bis 4711 zählen?

danke, gruß,
--ingmar

[harm6]

Dieser Beispielcode gibt sogar einen Fehler aus:

Code: [Auswählen]

foo = { c''1 }
\foo


tja, was könnte ich denn in der zwischenzeit machen, um die verdauung zu beschleunigen? einmal bis 4711 zählen?

Das wird wohl nicht helfen.

Aber wie schon gesagt, gebe selbst einen Context an, z.B.:

Code: [Auswählen]

foo = { c''1 }
\new Staff  \foo
Oder schreibe etwas dazwischen wie:

Code: [Auswählen]

foo = { c''1 }
\markup \null
\foo
Oder eine reine Fülsel ohne output zu verursachen:

Code: [Auswählen]

foo = { c''1 }
#(begin)
\foo
Gruß,
  Harm

[ingmar]

Für mich ist erstmal wichtig zu wissen, dass das ein Fehler von Lilypond ist, nicht von mir. Es hat mir in der Vergangenheit viel Kopfschmerzen bereitet, weil ich meinen Notentext immer in Variablen zu halten pflege und beim schnellen Ausprobieren von Funktionen immer wieder unerklärliche Fehler hatte.

Harm: Dieser Beispielcode gibt sogar einen Fehler aus:

Code: [Auswählen]

foo = { c''1 }
\foo


Stimmt! Aber es reicht folgendes:

Code: [Auswählen]

\version "2.18.2"

foo = { c''1 }
Digestiv="Fernet-Branca"
\foo

Du kannst je nach Geschmack oder Musikrichtung auch Grappa oder Jägermeister mit gleich guter Wirkung verwenden; mein Bevorzugter in dieser Richtung ist "Vana Tallinn".

Danke, Gruß,
--ingmar

[mgd]

Hallo Ingmar,

ich habe deine beiden Lösungen in 2.19.21 ausprobiert. Zu Lösung 2 habe ich wie von Harm vorgeschlagen ein \new Staff vor das "<<" gesetzt.

Danach liefern beide eine Darstellung in 3 Zeilen.

@Harm:
Welches sind denn die "Verdauungsprobleme", die Lilypond mit Lösung 1 in der 2.19.x Version noch hat ?

Liebe Grüße,
Michael

[harm6]

Für mich ist erstmal wichtig zu wissen, dass das ein Fehler von Lilypond ist, nicht von mir.

Es gab auf der interntionalen Liste einen thread zum Thema, ich finde ihn allerdings nicht mehr. Insofern versuche ich mal in meinem Gedächtnis zu kramen

Das grundsätzliche Problem besteht darin, daß es einige Funktionen gibt die etwas zu einer Variablen hinzufügen.
Das prominenteste Beispiel ist \addlyrics { ... }
(Es gibt noch andere, auch wenn sie mir im Moment nicht einfallen.)
Damit das funktioniert muß der parser beim lesen der Variablen natürlich abwarten, ob so eine Funktion  denn gesetzt ist. Deshalb ist die Variable beim direkt folgenden Aufruf noch nicht "fertig".
Da man nach addlyrics ein weiteres addlyrics anschließen kann, schaut der parser in solchen Fällen nach "oben" und nach "unten" und das Problem setzt sich fort ...

Es handelt sich also eigentlich nicht um einen Fehler, sondern eher um die Kosten, die man aufbringen muß, wenn man Funktionalität wie addlyrics implementiert.

Nicht das ich ein Freund von addlyrics wäre. Es fliegt viel zu schnell aus der Kurve, sobald die Lage etwas komplexer wird. Aber es ist sehr populär ...

Ich hoffe ich habe das einigermaßen korrekt dargestellt, aber ich meine es ist de facto noch komplexer/komplizierter ...

@Harm:
Welches sind denn die "Verdauungsprobleme", die Lilypond mit Lösung 1 in der 2.19.x Version noch hat ?

Eigentlich war ich überrascht, daß Lösung 1 in 2.19.20 funktioniert hat, denn

Code: [Auswählen]

\version "2.19.20"

foo = { c''1 }
\foo
klappt nach wie vor nicht.


Gruß,
  Harm

[ingmar]

Harm: Es handelt sich also eigentlich nicht um einen Fehler, sondern eher um die Kosten, die man aufbringen muß, wenn man Funktionalität wie addlyrics implementiert.

Das Problem ist ja eigentlich nur: Es muss dokumentiert sein. Wenn ich weiß, wie der Schnaps aussehen muss, durch den ich nachhelfen kann, also wann genau ich sicher sein kann, dass die Variable fertig gebaut ist, ist ja alles gut.

Ich habe nun verstanden, dass das "meistens" in der übernächsten (nicht leeren und Nichtkommentar-) Zeile der Fall ist und werde selber immer eine andere Variablenzuweisung dazwischenschieben (wie oben gezeigt, denn dann weiß ich, worum es hier geht). Ich werd das auch in Versionen 19 und 20 tun, bis mir jemand klar sagt, es sei nicht nötig. Ich hoffe, soweit dann richtig zu liegen und diesen "Kosten" (kommen mir eher wie überraschende "Gebühren" vor...)  so schnell nicht mehr zu begegnen...

Danke nochmal,
--ingmar