ragged-right

Begonnen von Köbi, Mittwoch, 26. Juli 2017, 10:18

« vorheriges - nächstes »

Köbi

Hallo zusammen

Wenn ich "ragged-right = ##t" eingestell, bricht Lilypond die Zeilen anders um. Es bringt weniger auf eine Zeile. Warum ist das so?

Wie bringe ich Lilypond dazu, bei "ragged-right = ##t" die Zeilen gleich umzubrechen, wie bei "ragged-right = ##f"?

Hintergrund: Um die für mich idealen Seitenumbrüche zu erstellen habe ich mir überlegt, dass ich mal horizontal und vertikal alles auf das Minimum einstelle, um dabei optisch einen Eindruck zu bekommen, was mindestens wie viel Platz braucht. Dazu habe ich "ragged-right = ##t" und "ragged-last = ##t" eingestellt (und bei system-system-spacing alles auf 0). Dann füge ich die entsprechenden \pagebreak ein. Wie macht ihr das?

Gruss, Köbi

Malte

Ich geh mal schwer davon aus, daß das schwer zu erreichen ist:

Es gibt quasi ein Optimum, wie breit jeder Takt sein sollte. Er kann natürlich gestreckt werden, um Zeilen voll zu kriegen, stattdessen kann ein Takt aber zu einem gewissen Maß auch gestaucht werden. Enger als optimal, aber trotzdem besser als zu weit gestreckt. ragged-right erzeugt also nicht Takte mit der minimalen Breite, deshalb funktioniert dein Ansatz vermutlich so nicht.

Was genau heißt ,,für dich ideale Seitenumbrüche"?

Und zu deiner Frage, wie andere das machen, kann ich ja mal beschreiben, wie ich vorgehe:
1. LilyPonds default, meistens aber mit ragged-last-bottom = ##f anschauen
2. page-count, evtl. system-count (sehr selten auch mal systems-per-page) anpassen
3. dann erst von Hand breaks einfügen, aber so wenig wie möglich:
     a) Zeilenumbrüche genau 1 Takt vor oder nach Wiederholungen/Tonartwechseln etc. per \noBreak verbieten
     b) evtl. bei großen Formteilen auch von Hand nen break setzen
     b) pageBreaks zum Blättern und Vermeiden von Schusterjungen und Hurenkindern.

Insgesamt bemüh ich mich, möglichst viel LilyPond zu überlassen (deshalb kommen explizite \breaks und \pageBreaks auch erst ganz zum Schluß und noch nach \noBreak). Ich habe einfach festgestellt, daß zu viel manuelles Eingreifen zumindest bei mir oft Lösungen produziert, die an jeder Stelle einzeln gut aussehen, aber insgesamt dann trotzdem nicht überzeugen.

Manuela

Ich vermeide es so weit es geht, Zeilen- und Seitenumbrüche in die Noten direkt zu schreiben, sondern verwende eine eigene Stimme dafür.

\version "2.18.2"

mus= \relative c'' { \repeat unfold 40 c4 }
mybreaks = { s1 * 2 \break s1 * 3 \pageBreak
}

\score{
\new Staff
<<
\new Voice \mus
\new NullVoice \mybreaks
>>
}
Danke für eure Hilfe
viele Grüße
-- Manuela

ingmar

Hallo,

Horizontale Raumaufteilung:
ich hab auch am Anfang viel versucht, LilyPond mit \break und dergleichen unter die Arme zu greifen. Ich nutze das inzwischen nur noch, wenn ich echte Blätterstellen habe, ohne die es einfach nicht geht. Da ich sonst immer wieder auch mal was ändere (zum Beispiel ein Hilfs-Versetzungszeichen ergänze), müsste ich den ganzen Prozess anschließend wieder von vorne starten. Und unterm Strich habe ich bei meinen Aktionen nie viel gewonnen; LilyPond macht die Raumaufteilung schon aus dem Stand sehr gut.

Allerdings habe ich manchmal den Eindruck, dass LilyPond dazu neigt, alles etwas eng zu notieren (meist, weil gleichmäßige Notenwerte wegen Vorzeichen oder schnellen Werten in der Parallelstimme zu unruhig dargestellt werden). Ich hab daher angefangen, LilyPond die Anzahl der Zeilen (Akkoladen) vorzuschreiben. Wenn es normalerweise sagenwirmal 13 für ein Stück wären, schreibe ich 14 vor. Bin noch nicht ganz sicher, dass das jedesmal eine Verbesserung war.

Ja, ich geb Manuela recht - Zeilenwechsel würde ich natürlich nicht in der Variablen pflegen, in der ich die Notentext halte.

Vertikale Raumaufteilung:
Da gibts ein Thema, über das ich immer wieder stolpere. Sagen wir, du hast 14 Systeme auf drei Seiten. Dann würden zwei Seiten fünf Systeme bekommen, eine vier. Ich frage mich nach den Kriterien, nach denen LilyPond entscheidet, welche Seite die vier Systeme bekommt. Denn auf der ersten Seite habe ich oft oben noch eine Titelei; da ansonsten die Tonumfänge immer im Rahmen bleiben und keine Dynamik vorkommt, müsste diese erste Seite eigentlich am engsten werden, und wenn ich von Hand schriebe, würde ich ganz sicher dort nur vier Systeme unterbringen. Aber LilyPond entscheidet sich eigentlich immer für eine andere Seite. Nicht, dass die erste nun besonders gequetscht aussieht - aber es verwirrt schon...


Gruß,
--ingmar

Köbi

Hallo zusammen

Danke schon mal für die Antworten :-)  Grundsätzlich halte ich es natürlich auch so, dass ich möglichst viel Lilypond überlasse.

In meinem Fall geht es darum, dass ich mir von einem Quartett (Fagott, Violine, Viola, Violoncello) von Devienne eine "Fagott-Partitur" anfertigen möchte. Die Fagottstimme, ich ich selber spiele in normaler Grösse und die anderen drei Stimmen kleiner. So kann ich beim Proben sehen, was die anderen genau haben und wir sparen Zeit beim Üben. Dadurch habe ich nicht so viele Fagott-Noten auf einer Doppelseite und muss etwas jonglieren mit den Blätterstellen.

In der vertikalen hat Lilypond nebst dem "minimum-distance" noch ein "basic-distance". Gibt es so etwas nicht auch in der horizontalen?

Gruss, Köbi

Manuela

Zitat von: Köbi am Mittwoch, 26. Juli 2017, 23:29
In der vertikalen hat Lilypond nebst dem "minimum-distance" noch ein "basic-distance". Gibt es so etwas nicht auch in der horizontalen?

Sozusagen. Ich schreibe in meine Umbruchsvariable meist noch so was Ähnliches rein (die Zahlenwerte sind jetzt Unfug, einfach ausprobieren welche Werte die besten Resultate erzielen):

\override Score.SpacingSpanner.base-shortest-duration = #(ly:make-moment 1/8)
oder
\override Score.SpacingSpanner.common-shortest-duration = #(ly:make-moment 1/3)
Danke für eure Hilfe
viele Grüße
-- Manuela

Köbi

Ok. Ich habe noch eine Weile recherchiert, aber auch nichts anderes gefunden. Lilypond scheint kein absolutes Maximum zu haben, wie stark es Zeilen komprimiert. Es scheint den besten Kompromiss aus strecken/stauchen von Zeilen, Seitenumbrüchen und vermutlich noch einiges mehr zu nehmen.