Verschiedene Editionen mit denselben Dateien

[ingmar]

Hallo Einzigartiger,

Wenn mir die Software da keine sinnvollen Sprachmittel anbietet muss man der eben den Attest ausstellen, das sie unzureichend ist.

Du kannst jede Software der Welt verwenden, damit sie dir den Lilypond-/Scheme-Code produzierst, den du haben willst. Was hält dich davon ab? Wie du als erklärter Fachmann sicher weißt, nennt man sowas eine Template-Engine, und es gibt Dutzende davon, in jeder dir genehmen Programmiersprache. Ich habe eine solche bereits erfolgreich zu genau diesem Zweck verwendet. Wie kommst du aber auf die Idee, das LilyPond-Projekt sei verpflichtet, dir dies zu liefern?

Wenn ihr mangels Vergleichsalternativen oder mangelndem Fachwissen in dem Bereich es nicht anders kennt, dann ist das eben so. Aber bitte zwingt mich nicht dazu, solche Lösungen dann als das technologisches Wundermittel anzusehen.

Na, wenn ich die Diskussion richtig verfolgt habe, hast DU darauf bestanden, dein Problem mit LilyPond-Mitteln zu lösen und hast auch gleich sehr genaue Vorgaben gemacht: Es haben \include-Files im großen Stil verwendet zu werden, Variablen seien ungeeignet, undsoweiter.

Die Antworten auf deine Vorgaben charakterisierst du jetzt als eine Art Sendungsbewusstsein in diesem Forum. Wer hier im Forum war es eigentlich, der dich da hat zwingen wollen, wer hat von 'Wundermittel' gesprochen?

---x----x-x--

Mit deiner Erfahrung in der IT weißt du ja auch sicher, dass nichts sicherer ein Projekt in den Misserfolg führt, als wenn man die Details einer Lösung festlegt, ehe man die Anforderungen klar hat. Ich hatte dich gleich in meinem ersten Post darauf aufmerksam zu machen versucht, du hast das erstmal angesichts deines überragenden Fachwissens beiseite gewischt. Ich denke aber immer noch, dass hier der Hase im Pfeffer liegt.

Gruß,
--ingmar

[unique75m]

Lieber Harm, lieber Ingmar,

ich habe jetzt schon mehrmals meine Anforderungen dargelegt. Ob dies nun mit aller Klarheit erfolgt ist will ich nicht beurteilen. Anhand der Nachfragen und langen Diskussionen kann ich nur schlussfolgern, dass dem nicht so war. Meine Anforderungen sind grob:

- ich möchte ein Buch mit 4 Scores, 12 Staffs zu je 2-3 Voices bauen
- ich habe hier beispielhaft einen Quellcode eines einfacheren Stücks gepostet, wo auch nur 1 Score vorkommt
- Buch und die Scores bekommen vollständige \header, damit auch ein Laie sieht was es gibt und was er ändern kann. Ich will niemanden später in Lilypond-Dokus wühlen lassen, nur um irgendwelche Befehle/Eigenschaften herauszufinden
- jeder Staff bekommt Zusatzinfos wie mehrzeilige Instrumentnamen, Clefs usw.
- ich möchte verschiedene Editionen drucken, wobei aber die ganzen Zusatzinfos wie Buchheader, Scoreheader, Staffeigenschaften erhalten und mitgedruckt werden. Hierbei möchte ich die verschiedenen Kombinationsmöglichkeiten drucken, z.B. Score 1 mit Staff1 mit Voice1... oder Score2+3, jeweils Staff 2, davon Voice 2.

Meine technischen Anforderungen hierbei sind:

- kein doppelter Quellcode, das gilt auch für den Strukturcode
- Übersichtlichkeit, Lesbarkeit auch für Laien
- Änderungsfreundlichkeit

Die momentan vorgeschlagene Lösung aus dem Forum hier lautet:

- schreibe die gesamte Struktur bestehend aus Buch, 4 Scores a 12 Staffs a 2-3 Voices in eine Gesamtdatei
- anschließend ziehe die Voice-Noten als Variablen heraus und schreibe alle zusammen in eine zweite Datei
- nun soll ich die Strukturdatei pro Edition kopieren und die unerwünschten Scores, Staffs, Voices aus dem Strukturcode entfernen
- das bedeutet, dass die Anzahl der Strukturdateien explodiert, bei einem Score mit 12 Staffs habe ich schonmal mind. 12 Strukturdateien (wenn man die Kombinationsmöglicheiten mit den Voices nicht einrechnet) und in jeder davon wiederholt sich der Quellcode, den ich schon in der großen Strukturdatei stehen habe.
- anders kann man aus meiner Sicht verschiedene Editionen nicht in den Griff kriegen bei diesem Lösungsvorschlag
- Variablen nützen hier auch nur was bei den primitiven Dingen wie Notenblöcken. Wenn man aber einen Staff komplett abschalten will, so müsste man die gesamte Staff-Definition in eine Variable legen, was in momentaner Lilypond-Version eben nicht geht. Darauf hatte Harm schon hingewiesen. Zumal diese Lösung auch schlecht ist, weil man dann noch mehr auseinanderreißt. Es gibt hier wohl auch einen anderen Thread, über den ich mal gestolpert bin, wo es genau darum geht den "ganzen" Staff abzuschalten, weil man eben sonst eine Leerzeile mit Violinschlüssel hat. Da reicht es nunmal nicht die Variable für die Voice-Noten auf einen leeren String zu setzen.

Mein Anspruch lautet:

- ich schreibe nur einmal den Strukturcode für das gesamte Buch
- ich benutze ConditionalCompiling bzw. Preprocessor-Funktionalität um bestimmte Quellcode-Teile variabel an/abschaltbar zu machen
- eine rudimentäre Lösung wäre die if-equal Funktion von mir, leider funktioniert diese eben nicht  außerhalb von Score und auch nicht bei allen Konstellationen. Hier hatte Harm ja schon dasselbe festgestellt und kleinere Verbesserungen aufgezeigt

Mit dieser if-equal Funktion gehe ich schon einen Kompromiss ein und biege meine Ansprüche zurecht mangels Sprachfeatures von Lilypond. Ich kann dann kein Buch mehr mit 4 Scores bauen, da ich die Scores eben nicht dynamisch abschalten kann. Also muss ich jeden Score einzeln in ein Buch packen und den einzeln ausgeben. Dann kann ich aber zumindest da drin alle Staffs und Voices mit if-equal kontrollieren.

Was stört mich nun konkret an dem Forumsvorschlag:

- er widerspricht meinen technischen Anforderungen, dass ich Quellcode nur einmalig schreiben will (inkl. Strukturcode)
- wenn man alles in einer Datei hat und nun den Staff 8 sucht fängt man erstmal wild an zu scrollen und zu suchen. Erklärt das mal einem Laien, der diesen Code noch weniger versteht, was genau er da eigentlich sucht
- Änderungsfreundlichkeit ist auch nicht gegeben, da man von zuviel Quellcode erschlagen wird

Was stört mich an der Diskussion selbst:

- ich habe das Gefühl ich soll meine Anforderungen und Herangehensweisen an die Arbeitsweise der anderen bzw. an die technischen Defizite von Lilypond anpassen
- wenn etwas nicht funktioniert wird mir suggeriert das mein Ansatz falsch ist und ich alles anders machen soll

Ich weiß nicht wie ich das Folgende vorurteilsfrei und ohne jemand persönlich angreifen zu wollen, formulieren kann. Falls das jemand tut, bitte ich im Voraus um Entschuldigung. Ich empfinde es als sehr seltsam, wenn mir jemand suggeriert meine Herangehensweise wäre verkehrt, obwohl er selbst keinerlei anderweitige Erfahrung mit Programmier-/Scriptsprachen oder etablierten Software-/Projektverwaltungstechniken hat. Die Erklärung mit dem "technologischen Wundermittel" war nur eine überspitzte Formulierung dieser Situation.

Ich möchte eigentlich gern diese Streiterei hinter mich lassen, weil das nicht wirklich zielführend ist. ich bitte auch nochmals um Entschuldigung, falls sich irgendwer in irgendeiner Weise angegriffen gefühlt hat. Ich habe meine Anforderungen geschildert und das tue ich ja nicht grundlos. Genau wie ein Automechaniker ein Auto mit anderen Augen beurteilt, so prüfe ich eben solche Scriptsprachen  aus einem anderen Blickwinkel. Wie einfach ist die Sprache? Kann man sinnvoll größere Projekte damit verwalten? Wie werden Redundanzen vermieden? Lassen sich Bibliotheken mit wiederverwendbarem Code aufbauen/verwalten? Speziell fürs Notenblatt, wie einfach lassen sich verschiedene Auszüge erstellen?
Der bisherige Kontakt mit Lilypond hat mir gezeigt, dass viele dieser Bereiche unzureichend umgesetzt sind.

##############

Lieber Harm,

vielen Dank noch für die anderen Links, ich denke aber einen Teil davon kenne ich schon, insbesondere wo jemand nach einem Äquivalent für #define, #ifdef usw. fragt. Genau das ist Preprocesser-Syntax. Eine Lösung gab es da auch nicht, es gab dieselben Probleme, wie hier in diesem Thread schon beschrieben, z.B. mit Tags und deren Eingeschränktheit.

Nur zur Erklärung für Dich. Ein Preprocessor ist ein separates Kommandotool. Meist wird dieser aber gleich direkt in einem C/C++ Compiler integriert und existiert nicht mehr nur als eigenständiges Tool. Mit einem Preprocessor wird ein Vorkompilierungsschritt durchgeführt, wo textuelle Ersetzungen erfolgen. Hierbei kann man allerhand Makros als Variablen, Funktionen definieren und letztere mit Parametern aufrufen. Preprocesser-Definitionen in C/C++ werden prinzipiell mit # eingeleitet. Genau das macht es wohl auch schwieriger mal eben einen solchen Preprocessor für Lilypond zu nehmen. Z.B kann ich folgendes tun:

Code Auswählen Erweitern


#define myVariable "a3"

\paper { myVariable }


Oder

Code Auswählen Erweitern


#define myVariable

#ifdef myVariable
      \paper {irgendein Inhalt}
#else
      \paper {alternativer Inhalt}
#endif


Oder in einem C/C++ Programm mit einer max-Funktion:

Code Auswählen Erweitern


#define max(a, b) a > b ? a : b

max(1, 2)


Wie du siehst ähnelt es den Variablen von Lilypond. Allerdings finden hier nur textuelle Ersetzungen statt und sind unabhängig von der Zielsprache. Erst nachdem alle Textbausteine ersetzt worden sind, wird das Endergebnis an den Compiler gegeben. D.h. der #else Block fliegt dann komplett heraus, noch bevor da irgendeine Codeausführung erfolgt bzw. der Lilypond-Compiler das in die Finger kriegt. Damit wären verschiedene Editionen aus einer Gesamtpartitur ein Klacks, weil man die gesamte Partiturstruktur nur einmal schreibt und die Teile, die man abschaltbar haben will per #ifdef einkapselt. Außen drumherum würde man nur die Edition-Dateien schreiben, die die Gesamtpartitur includen. Dort definiert man dann nur per #define die gewünschten Ausgabeinhalte. Und ich möchte anmerken, dass diese Technik eigentlich schon tiefstes Mittelalter ist, die eigentlich meist nur bei statisch typisierten Sprachen angewendet wird. Bei dynamisch typisierten Sprachen macht man so einen Quatsch garnicht mehr.

Ich will ja nicht mal abstreiten dass teilweise solche Dinge mit Variablen und Scheme-Funktionen in Lilypond umsetzbar sind, nur wissen wir spätestens seit diesem Thread, dass es scheinbar nicht so simpel ist, wenn es außerhalb von score und book funktionieren soll und mit jedwedem Ausdruck zurechtkommen soll.

#############

Lieber Ingmar,

könntest Du mir die Template-Engines nennen, die es da im Lilypond-Umfeld gibt?

Hinsichtlich der Benutzung von Variablen habe ich nun hoffentlich mit obiger Beschreibung klargestellt, warum diese unzureichend sind. Ich müsste die Struktur jedesmal kopieren, das möchte ich nicht.

[Hilflos-im-Code]

Die Bemerkung mit den 30 Jahren ging allerdings an Hilfslos-im-Code. Für mich ist das mit Lilypond ein Test, ob das ein gangbarer Weg ist. Alles was ich bisher dazu gesehen habe ist, dass es unnötig kompliziert ist, grundlegende Sprachfeatures nicht beherrscht, Modularität und Wartbarkeit nicht gegeben sind usw. Ständig irgendwelchen Quellcode zu duplizieren und somit redundanten Code zu haben ist nunmal grober Unfug. Wenn mir die Software da keine sinnvollen Sprachmittel anbietet muss man der eben den Attest ausstellen, das sie unzureichend ist. Wenn ihr mangels Vergleichsalternativen oder mangelndem Fachwissen in dem Bereich es nicht anders kennt, dann ist das eben so. Aber bitte zwingt mich nicht dazu, solche Lösungen dann als das technologisches Wundermittel anzusehen. Selbst die von mir geforderte Preprozessor-Funktionalität ist eigentlich schon eher ein Steinzeit-Feature. Ich bin andere Technologien gewöhnt.

Das Problem ist, ich rate dir eigentlich von Lilypond ab, wenn das dein Geigenlehrer letztendlich nutzen soll, weil ich noch andere Software kenne. Lies bitte genau, bevor Du Dich echauffierst.

[ingmar]

Hallo,

unique75m: Könntest Du mir die Template-Engines nennen, die es da im Lilypond-Umfeld gibt?

Ich wüsste nicht, dass es sowas gibt. Ich arbeite gerne in Python, hab mir das in Python gemacht. Da gibt es Mako und Jinja, ich hab erstere verwendet, für meine Zwecke hat das erstmal gereicht. Ninja kann offenbar mehr, ist aber wesentlich umständlicher zu installieren. Nimm die Engine, die dir gefällt, es gibt sowas doch in den meisten verbreiteten Programmiersprachen!

Was du vermutlich brauchst, ist Zugang zu den Variablen, die in LilyPond definiert sind, dazu hat hier Harms die Lösung geliefert:

https://lilypondforum.de/index.php/topic,225.msg1445.html#msg1445

Ich bin von dem ganzen Ansatz erstmal wieder abgekommen, aus verschiedenen Gründen. Vielleicht komm ich wieder drauf zurück - aber im Moment habe ich andere Sorgen.


Gruß,
ingmar

[harm6]

Hallo unique,

zunächst mal zu
"Was stört mich an der Diskussion selbst"

Da habe ich auch etwas zu sagen:
Du neigst dazu zu verallgemeinern und zum überschnellen Fällen von Urteilen und Schlußfolgerungen.

Als überspitztes Beispiel:
Wenn Ronaldo in einem Spiel kein Tor schießt, dann müsstest Du um Dir treu zu bleiben eigentlich sagen:
Ranoldo kann keine Tore schießen. Er ist ein schlechter Spieler.

Denn viele Deiner Schlussfolgerungen sind nicht vollständig richtig bzw lassen den Leser, insbesondere jemanden, der dies hier vielleicht nach Jahren liest, möglicherweise in die Irre gehen.

Als Beispiel aus diesem thread:

eine rudimentäre Lösung wäre die if-equal Funktion von mir, leider funktioniert diese eben nicht  außerhalb von Score und auch nicht bei allen Konstellationen. Hier hatte Harm ja schon dasselbe festgestellt und kleinere Verbesserungen aufgezeigt

Richtig ist, daß die bisherigen Versuche nicht umfassend erfolgreich waren. Das heißt aber nicht, daß es prinzipiell unmöglich wäre.

Ich habe mittlerweile auf der internationalen Liste nachgefragt und mit den dort gewonnenen Erkenntnissen, folgendes versucht.

Code Auswählen Erweitern


#(define-macro (if-equal a b x y)
  `(if (equal? ,a ,b) ,x ,y))
 
%% test a set! command
#(define lst #f)

#(if-equal 1 2
   (set! lst '(1 2))
   (set! lst '(3 4)))

#(display lst)
 

%% test a set-command in \paper
\paper {
  #(if-equal 1 2 (set-paper-size "a8" 'landscape) (set-paper-size "a8"))
}

{ R1 }

%% test applied to music-expressions
$(if-equal 
  1 2
  #{ ces'1 #}
  #{ cis'1 #})

Es ist nicht über die obigen Beispiele hinaus getestet, aber sieht m.E. deutlich vielversprechender aus als das bisherige coding.

Ich möchte eigentlich gern diese Streiterei hinter mich lassen, weil das nicht wirklich zielführend ist.

Da bin ich sehr einverstanden.

Lass uns einen Neuanfang wagen.

Hallo unique,

zunächst vielen Dank für die Ausführungen zum Thema Preprocessor.
Ich hatte bereits versucht mich im Netz schlau zu machen. Deine Ausführung sind in Wortwahl und sowohl allgemeiner als auch spezieller Darstellung natürlich etwas anders.
Ich empfinde das immer als hilfreich.

Ansonsten hast Du (für mich klarer) zusammengestellt, was Dir vorschwebt.
Lass uns mal schauen, ob ich's richtig verstanden habe, anhand eines eingefärbten Beispiels mit nur einem Staff/score

gelb ist Voice-stuff
orange ist Staff-stuff
rot ist score-stuff
violett ist book-stuff
 
\book {
  \header { <book-header> }
  \paper { <book-paper>}
  \score {
    \new Staff
     \with { <ctx-staff-stuff> }
     {
         <other-staff-level-stuff>
         <<
             \new Voice \musI
             \new Voice \musII
         >>
     }
     \header { <score-header> }
     \layout { <score-layout> }
  }
}

Mehr oder weniger Voices, Staffs, scores je nach Bedarf.

Korrekt, im Sinne von vollständig?

Falls ja wie sollen transpose-Befehle angewendet werden?
Kommen andere "Container"-Contexte wie PianoStaff vor, oder auch Dynamics-contexte?
Willst Du ein explizites \book ausgeben? (Ist eigentlich nur sinnvoll, falls mehrere books pro file erstellt werden können/sollen.)

Du willst ja ein template erstellen. Jedes template das ich jemals sah, schlug etwas vor, schloß damit aber gleichzeitig anderes aus.
Z.B im Pseudo-code oben haben die Voices ja keinen \with-Block. Kann darauf verzichtet werden?



Ich warte mal Deine Reaktion ab. Falls ich Dich richtig verstanden habe so, werde ich mal versuchen das Problem nach meiner fasson zu erledigen.
Einen Erfolg kann ich vorab natürlich nicht garantieren...


Gruß,
  Harm

[ingmar]

Hallo,

in diesem Zusammenhang taucht - für mich - ein Thema immer wieder auf: Wie kann ich die Variablennamen dynamisch machen?

im alten Forum ist zu finden, wie man LilyPond-Variablennamen mit Hilfe von Schema zusammensetzen kann:

Code Auswählen Erweitern

\version "2.19.64"

A-music = \relative { c'4 d e f g1 }
A-titel = "c bis g"

B-music = \relative { g'4 f e d c1 }
B-titel = "g bis c"

myscore = #(define-scheme-function ( pointer) ( string?) #{
\score {
\header {
piece = #(ly:parser-include-string (string-append "\\" pointer "-titel"  ))
}
\new Staff { #(ly:parser-include-string (string-append "\\" pointer "-music"  )) }
}
#})

\myscore "A"
\myscore "B"


Bei der Musik funktioniert das prima, leider aber nicht bei Texten, etwa in \markup. Für Texte habe ich bisher noch keine Lösung gefunden; was im alten Forum vorgeschlagen wurde, verstehe ich entweder nicht - oder es ist eben doch keine echte Dynamisierung. Es sollte schon innerhalb des Lilypond/Scheme-Codes der Variablenname montiert und anschließend verwendet werden, so wie bei der Musik.

Gat da jemand eine Idee, oder kann mir auf die Sprünge helfen? : - )


Herzlichen Dank, Gruß,
--ingmar

EDIT: typo

[harm6]

Hallo ingmar,

so?

Code Auswählen Erweitern


\version "2.19.81"

A-music = \relative { c'4 d e f g1 }
A-titel = "c bis g"

B-music = \relative { g'4 f e d c1 }
B-titel = "g bis c"

myscore = #(define-scheme-function ( pointer) ( string?)
#{
  \score {
    \header {
      piece = #(eval-string (format #f "~a-titel" pointer))
    }
    \new Staff { #(eval-string (format #f "~a-music" pointer)) }
  }
#})

\myscore "A"
\myscore "B"

HTH,
  Harm

[unique75m]

Hallo alle zusammen,

so ich versuche jetzt mal der Reihe nach zu gehen, sonst kommt man ja durcheinander :-)



Erstmal zu Hilflos-im-Code...
ich persönlich habe eigentlich auch eher Bauchschmerzen mit Lilypond wenn ich darüber nachdenke, dass man es einem Musiker gibt, der eben von Technik so gar keine Ahnung hat. Umgekehrt sind aber Programme wie Musescore in puncto Formatierung ziemlich zeitintensiv und lästig. Da halte ich Lilypond eher für besser, da ich mich um die Formatierung eben nicht kümmern muss. Die Syntax ist aber eben für Laien und Technikfremde sehr kompliziert. Deswegen wollte ich gern ein Template bereitstellen, was möglichst einfach und verständlich ist.



Nun zu Ingmar... und seinem vorletztem Post.
Für mich hatte sich deine Beschreibung so gelesen, dass es irgendwelche fertigen Template-Engines gibt, die ich irgendwo downloaden kann und anwenden kann. Da habe ich Dich einfach missverstanden. Mir schwebte auch schon eine Lösung vor, dass ich ein Programm um Lilypond herum schreibe. Dann kann ich natürlich meine mir am liebsten vertraute Sprache Smalltalk nehmen. Aber eigentlich scheue ich den Aufwand. Ich weiß leider aus guter Erfahrung, dass man bei solchen Dingen vom 100. zum 1000. kommt und eigentlich nie richtig fertig wird. Ich möchte eigentlich nur elegant und schnell meine Noten eintippen und dann meine Zeit für das Geigespielen einsetzen, man wird ja nicht jünger :-)
Ich denke die Sache mit den Variablen brauche ich eher genau umgekehrt. Ich möchte außen Variablen definieren, die ich innen im Lilypond abfragen kann und dabei bedingte Entscheidungen/Codepfade wählen kann.



Nun zu Harm...

Code Auswählen Erweitern


Als überspitztes Beispiel:
Wenn Ronaldo in einem Spiel kein Tor schießt, dann müsstest Du um Dir treu zu bleiben eigentlich sagen:
Ranoldo kann keine Tore schießen. Er ist ein schlechter Spieler. ;)


Ok ich geb mich geschlagen. Zu meiner Verteidigung muss ich aber einwenden, dass ich kein Fußball mag. Somit sind per Definition alle Spieler schlechte Spieler :-)

Ich denke aber auch, dass es sicherlich irgendeine Lösung in Form einer Schema-Funktion und nicht einer musikalischen Lilypond-Funktion gibt, die das if-equal umfassend für alle Ausdrücke lauffähig macht, vermutlich dann auch außerhalb von score und book. Das wäre dann die für mich eleganteste Lösung, weil ich dann quasi mit Lilypond-Sprachsyntax den Preprocessor nachbauen kann. Leider bin ich nicht so bewandert mit Scheme. Danke für die Beispiele, vollständig verstanden habe ich sie noch nicht, aber ich werde die Ideen mal testen, ob man z.B. dann auch einfach \if-equal als Lilypond-Code schreiben kann oder eben immer Scheme-Ausdrücke verwenden muss. Ich verstehe aber bei dem Scheme immer noch nicht die syntaktischen Elemente. Was bedeuten in dem folgenden Ausdruck nun wieder die Kommas, z.B. ,a oder ,b? Vorn vor der Klammer steht auch wieder ein ', ich dachte Schema-Ausdrücke sind immer nur geklammert und gut. Ich hatte nur mal gelesen, das ein ' bedeutet, das es von Scheme gequotet wird, damit man nicht die Variable meint, sondern das Symbol. Aber ein Komma ist mir nun wieder neu.

Code Auswählen Erweitern


#(define-macro (if-equal a b x y)
  `(if (equal? ,a ,b) ,x ,y))


Ich denke, dass wir uns jetzt gegenseitig besser verstehen. Dein farbiges Beispiel gibt eigentlich ganz gut wieder, was ich meine. Die staff-stuffs (übrigens lustige Wortkombination :-)) und ctx-staffs usw., also die ganzen Eigenschaften die man so irgendwo reinschreibt sind natürlich nun nicht zwingend immer als Variablen sinnvoll definierbar, ebenso die <book-paper> oder <book-header>. Beim <book-header> ist das vielleicht am besten erklärbar. Da stehen ja normalerweise nun alle möglichen Dinge drin wie title, subtitle, etc, also zig Properties. Wenn ich die nun alle per Variablen belege, habe ich genauso viele gleichnamige Variablen wie Properties definiert, nur um dann kontextlose Variablen zu haben, deren Belegungen im \header viel besser aufgehoben sind. Den gesamten Code inclusive umfassenden \header {...} kann ich nicht rausziehen, weil das Lilypond in der aktuellen Version mit Fehlern quittiert. Dazu bräuchte ich wohl diese neuen Versionen. Umgekehrt geht es glaube ich auch nicht jetzt eine Variable zu definieren wie folgt:

myvariable = title = xxx subtitle = yyyy ...

Da macht glaube ich Lilypond genausowenig mit, dazu müsste man wohl den Teil auf der rechten Seite in {} einfassen, damit es ein musikalischer Ausdruck wird und das funktioniert dann natürlich wieder auch nicht, weil im \header {...} nunmal keine weiteren {} Klammern stehen dürfen. Dasselbe Problem hat man übrigens wenn man andere Dinge auf ähnliche Weise herausziehen will. Also müsste ich pro Property im \header eine eigene Variable definieren, was ziemlich bescheuert ist. Dann kann ich auch gleich die Werte im \header direkt hinschreiben. Also reduzieren sich die praktischen Beispiele des Definierens von Variablen auf so einfache Ausdrücke wie \relative {...} oder \markup {...}.

Containerkontexte für Pianostaff, Dynamics und Pianochords-Beschreibungen kommen natürlich auch vor. Ein \with bei den Voices habe ich "noch" nicht benötigt, wobei mir bisher auch nicht klar war, dass es den gibt bzw. was ich da alles einstellen kann. In meinen bisherigen Beispielen habe ich die nicht gebraucht, aber ob das bei anderen Stücken notwendig wird, kann ich noch nicht genau sagen.

Und ja ich möchte dann das Template einfach erweitern können um weitere Staffs/Voices oder auch Scores. Da ist natürlich ein kilometerlange Spaghetticode nicht so leserlich. Wenn man da kurze übersichtliche Dateien hat, wo am Ende eine Liste mit \include Befehlen steht, die man nur erweitern braucht ist das denke ich für außenstehende Dritte leichter nachzuvollziehen. Stell dir vor ich hätte alle 12 Staffs nach deinem farbigen Schema so zusammengestellt und jetzt versucht ein Techniklaie den Staff 7 zu finden, um dort eine weitere Voice einzubauen. Das wird ein Horrortrip für den.

Über transpose-Befehle habe ich noch nicht nachgedacht, da kann ich also nichts dazu wirklich sagen. Vom jetzigen Stand der Dinge würde ich sagen, dass ICH sie nicht brauche. Mein Geigenlehrer bzw. seine Frau haben aber schonmal davon geredet, dass es mit digitalen Noten toll wäre, da man da einfach transponieren kann. Ob man das dann auf Voice-Ebene macht oder für den gesamten Score kann ich nicht beurteilen.

Ganz wichtig für mich ist dabei eben, dass der Code eben leicht verständlich bleibt, halbwegs erweiterbar und dass man kontrollieren kann, welche Submenge an Scores/Staffs/Voices ausgegeben wird, ohne dass man dazu die gesamte Struktur kopieren muss.

Ich stimme dir natürlich zu, dass jedes Template immer irgendwo etwas Festgenageltes ist. Irgendwer will wieder gleich oben auf dem Blatt die Klavierstimmen, der andere in der Mitte usw.. Oder der nächste will keine Chords, dafür aber Lyrics. Aber man kann ja zumindest ein bisschen irgendwie festzurren und wiederverwendbar machen. Wobei der Positionstausch von Staffs mit einer Liste von \include am Ende einer Datei auch deutlich einfacher geht, als wenn man mitten im Code Teile umkopiert und wieder die falsche Klammer auswählt.

[unique75m]

Zu Ingmar Frage fällt mir gleich eine andere Frage ein. Kann man irgendwie eine Scheme-Funktion oder Macro oder ähnliches definieren, damit man quasi seinen eigenen book-Befehl definieren kann, der gewisse Grunddinge wie \paper schon enthält, aber wo man dann trotzdem ganz normal \mybook {...} schreiben und bei den ... dann trotzdem alle Dinge, die ein normales Book kann. Ok ich glaub das war etwas schwierig erklärt, vielleicht hilft ein Beispiel:

Code Auswählen Erweitern



mybook =
     \book
         {
         \paper
              {
              irgendwelcher Lilypond-Code für Paperzeugs
              }
         }

\mybook
     {
     \header
          {
          alle normalen Dinge, die man so im Header schreibt
          }
     }



Das \mybook soll dann automatisch die Voreinstellungen des paper-Blocks haben und man soll trotzdem alle anderen Dinge direkt reinschreiben können. Damit könnte man sich quasi eine komplette eigene Template-Bibliothek aufbauen und die Befehle von Lilypond erweitern. Dann kann ich z.B. eigene Variablen für vordefinierte Paper-Blöcke erstellen, die ich toll finde. Aufbauend darauf kann man dann eigene Buchbefehle haben wie z.B. book-a3, wo dann gleich das paper-a3 voreingestellt ist. Somit erspart man sich ein Haufen Tipparbeit und kann trotzdem alle üblichen Lilypond-Dinge einbetten.

In der objektorientierten Programmierung wäre das jetzt Spezialisierung bzw. eine Subklasse. Man leitet von einer bestehenden Klasse ab, erweitert sie und erbt alle sonstigen Möglichkeiten und Funktionalitäten.

[Hilflos-im-Code]

Würdest Du mal vorsichtshalber erläutern, warum Du das Material in einem Buch zusammenfassen willst?

[unique75m]

Lieber Hilflos-im-Code,

Code Auswählen Erweitern


Würdest Du mal vorsichtshalber erläutern, warum Du das Material in einem Buch zusammenfassen willst?


Wenn du damit meine generelle Vorgehensweise meinst, dass ich 4 Scores in ein Book packe... ich dachte das wäre eine gute Idee, weil ich doch eben in der Realität ein kleines Buch mit 4 Liedern haben. Naja ich will es ja nicht unbedingt als Buch bezeichnen, eher Heftchen. Aber es  sind inhaltlich zusammengehörige Stücke. Da habe ich also einen Titel für das Heft/Buch und eben pro Lied verschiedene eigene Titel. Nach meinen bisherigen Erkenntnissen aus der Lilypond-Doku erschien mir das als sinnvoller Weg. Wenn es da etwas besseres gibt, bin ich für Vorschläge offen.

Was die letzte Frage von mir angeht ist das ja nur eine Idee, um besseren wiederverwendbaren Code zu haben, wo man dann Lilypond um eigene Befehle erweitert, die aber die Grundfunktionalität von den eingebauten Lilypond-Befehlen erben. Momentan kann man zwar kleinere Templateschnipsel bauen, aber das ist eben immer nur Copy/Paste oder irgendwelche Funktionen, die man mit Parametern aufrufen muss. Das macht es eigentlich meist nur unübersichtlicher und komplizierter, zumal man bei letzterem dann meist nur noch Scheme-Aufrufe programmiert und garnicht mehr die Lilypond-Syntax anwendet.

[Hilflos-im-Code]

Also Du willst nur vier Partituren machen und keine Einzelstimmen? Und inhaltlicher Zusammenhang ist der Normalfall bei deinem Geigenlehrer?

[ingmar]

... dass ich 4 Scores in ein Book packe... ich dachte das wäre eine gute Idee, weil ich doch eben in der Realität ein kleines Buch mit 4 Liedern haben.

Ich würde dir zu \bookpart raten. Es macht allerdings auch nicht viel mehr, als hinter die Scores jeweils ein \pageBreak zu setzen. \book lohnt sich nach meinem Verständnis nur, wenn du die einzelnen Bücher auch als getrennte PDF-Files ausgeben möchtest. Was hier ja offenbar nicht der Fall ist.

--ingmar

[Hilflos-im-Code]

Ich würde dir zu \bookpart raten. Es macht allerdings auch nicht viel mehr, als hinter die Scores jeweils ein \pageBreak zu setzen.

Nicht ganz, es unterscheidet sich zu pageBreak, je nachdem was bei ragged-last-bottom eingestellt ist.

[ingmar]

ja, ich weiß schon. Ich wollte hier nicht in die Details gehen. Nur von \book abraten.

For the record: Wenn du nichts weiter eingestellt hast und hinter den Score \pageBreak setzt, dann werden die Systemen darüber gleichmäßig auf die Seite verteilt. Wenn du zwei Seiten mit sechs Systemen hat und auf der letzten Seite nur zwei oder drei Systeme, ist die Wirkung, nunja - ich nenn es hässlich. Bevor du anfängst, mit \markup eine Leerfläche unter jeden Score zu basteln, ist \bookpart wohl die bessere Wahl.

Wie auch immer, wir verlieren den Fokus...
--ingmar