Verschiedene Editionen mit denselben Dateien

Begonnen von unique75m, Montag, 30. April 2018, 22:05

« vorheriges - nächstes »

unique75m

Hallo

ich habe nun testweise mal ein kleines Beispiel gebaut mit einer streng hierarchischen Struktur.




book01.ly

\book
{
<<
\include "./book01-score01.ly"
>>
}


book01-score01.ly

\new Score
{
<<
\include "./book01-score01-staff01.ly"
>>
}


book01-score01-staff01.ly

\new Staff
{
<<
\include "./book01-score01-staff01-voice01.ly"
\include "./book01-score01-staff01-voice02.ly"
>>
}


book01-score01-staff01-voice01.ly

\new Voice
{
\relative c'
{
c d e f g a b
}
}


book01-score01-staff01-voice02.ly

\new Voice
{
\relative c'
{
f g a b c d e
}
}





Natürlich steht in der Staff, Score Datei später noch mehr Information wie z.B. Titelangaben usw. Oder im Buch stehen dann Paperangaben, Layoutangaben usw.

Nun möchte ich gern mehrere Editionen drucken. Eine Edition soll das Papierformat A3 haben mit allen Staffs und allen Voices. Andere Editionen sollen A4 sein mit nur einem Staff oder einer Voice, hierbei sollen aber die ganzen Titel aus dem Score mit gedruckt werden, denn es bringt ja nix wenn man einen Einzelauszug für die Violine macht und die ganzen Titelinformationen dort nicht stehen.

Bei dem Papierformat könnte ich nun Variablen im \book.ly nehmen. Diese Variable kann ich dann vielleicht in einer übergeordneten edition.ly definieren und dort das book.ly per \include einbinden. In dieser edition.ly möchte ich nun aber auch sagen, dass ich nur den Staff01 und davon nur die Voice01 drucken möchte. Dazu benötige ich bedingte Kompilierung, die es in Lilypond leider nicht gibt. Ich habe auch nicht wirklich Lust alle Dateien rekursiv zu kopieren, nur um dann in den verschiedenen Dateiversionen die \include Befehle zu variieren.

Ich hatte auch schon probiert z.B. in der Staff-Datei anstatt der einzelnen \include Befehle eine Variable wie \voiceList zu benutzen, damit ich diese Variablen dann ganz oben in der edition.ly definieren kann. Aber dann wird man gelinde gesagt blöd im Kopf, weil man einerseits Dinge oben per \include reinzieht, die eigentlich von der Logik her unten in die staff.ly gehören. Am Ende hat man zig \include Anweisungen in der edition.ly stehen und zig Variablenzuweisungen, damit dann die "variabilisierten" staff, score und book Dateien auch funktionieren. Das gefällt mir einfach nicht.

Des Weiteren habe ich mit den \tag Befehlen experimentiert, in dem ich jedem \include Befehl einen \tag vorangestellt habe, sodaß ich das \include steuern kann von oben. Aber mir gelingt es einfach nicht, dass ich mehrere Tags auf einmal aktiviere. Mit \keepWithTag kann ich nur ein Symbol angeben. Ich möchte jetzt aber z.B. sagen \keepWithTag #'voice01 #'voice02. Geschachtelte \keepWithTag mit geschweiften Klammern hat auch nicht funktioniert. Wenn das funktionieren würde, wäre das zwar ein mickriger Ersatz für bedingte Kompilierung, aber zumindest wäre es einer  :)

Meine Frage an die Forumsmitglieder ist nun, wie man das Problem mit den verschiedenen Editionen lösen kann, ohne dass man zig Dateien repliziert. Unabhängig davon, ob man gleichbleibende Strukturteile wie score-header usw. ebenfalls auslagert, man müsste immer zuviele Dateien erstellen.

ingmar

Hallo Einzigartiger,


ich verstehe nicht, warum du es dir selber so schwer machst. Wozu denn diese vielen unübersichtlich geschachtelten Dateien! Warum nicht einfach eine Datei, in der alle Notentexte in Variablen stehen, und dann für jede Edition halt eine  eigene Datei, die dieses Quellfile mit den Variable einbindet? Das sollte doch für den Hausgebrauch reichen! Du kannst dann immer noch später, wenn der Bedarf auftritt, versuchen, weitere Dinge in eine Art Bibliothekfile auszulagern. Aber  halt erst dann, wenn es wirklich schmerzt, mit einer Lösung, die dann hilft! Ich kann dir nicht empfehlen, erst eine Lösung zu bauen, um sich anschließend nach den passenden Problem umzusehen.


Viel Erfolg!
--ingmar

unique75m

#2
Hallo Ingmar,

das von mir gezeigte ist ja nur ein Minimalbeispiel. Ich muss hier auch Bücher digitalisieren mit 4 Scores mit je 12 Staffs und teils 2-3 Voices pro Staff. Da halte ich eine EinzelDatei-Lösung für kontraproduktiv und unübersichtlich. Außerdem möchte ich das Grundgerüst auch mal später als Template meinem Geigenlehrer geben, sodaß er nur noch in die Voice-Dateien gehen muss und lostippen kann. Oder er geht eben in die score.ly und ändert den Titel. Das Wichtige dabei ist, dass er nicht mit unnötig viel Syntaxwirrwar geflutet wird, was ihn da garnicht interessiert. Stell dir vor ich würde die gesamte Struktur mit 4 Scores a 12 Staffs a 2-3 Voices in einer Strukturdatei haben, da blicke dann nicht mal ich auf Anhieb durch und muss immer nur suchen.

Ich habe auch schon mit Variablen experimentiert, allerdings ohne zufriedenstellende Lösung. Das endet dann meist damit, dass man auf oberster Ebene alles includet bis runter zur kleinsten voice-Datei und alle möglichen Variablen initialisiert.

Die Aufteilung in book, score, staff, voice ergibt ja eine Baumstruktur. Was ich suche ist eine Lösung, wie man einen bestimmten Teilbaum drucken kann und die anderen Teilbäume deaktiviert.

harm6


unique75m

Hallo Harm

auf den Artikel bin ich auch schon gestoßen, allerdings empfinde ich das als viel zu kompliziert und mit Kanonen auf Spatzen geschossen. Da müsste ich ja jetzt den gesamten Tree selber zusammen programmieren und dann scheinen die dort beschriebenen Funktionen auch noch fest kodiert zu sein, wenn man sowas wie die Voice-Definitionen sieht. Außerdem werde ich den Eindruck nicht los, dass ich damit nur die Leafs des Trees ausgeben kann und nicht den ganzen Pfad dahin.

Da neige ich doch eher zu der Idee mir den GCC zu installieren und den normalen C++ Präprozessor über das .ly File zu jagen. Anschließend kann man das so präprozessierte File immer noch durch Lilypond parsen lassen. Allerdings weiß ich nicht ob der C++ Präprozessor damit klar kommt, dass in Lilypond Files auch mal # vorkommt.

Ich habe aber noch eine andere Variante gefunden. Es wird beschrieben, dass ab Version 2.18 der Befehl \keepWithTag eine Liste mit Symbolen erlaubt. Ich habe die Version 2.18.2-1. Da ich kein Lilypond bzw. Schema-Experte bin, weiß ich aber nicht, wie man eine Liste von Symbolen syntaktisch hinschreibt? Hat da jemand Ahnung? Im Netz habe ich da bisher auch nix gefunden.
Leider scheint das \keepWithTag auch nicht außerhalb eines \book zu wirken, z.B:


     \keepWithTag #'voiceOne \book {...}


Aber das scheint zu funktionieren:


     \symbolList = #'voiceOne

     \book
          {
          \keepWithTag \symbolList
          ...
          }


Also kann ich die Variable \symbolList in meiner edition.ly definieren und dort die book.ly includen. Jetzt muss die symbolList eben nur noch eine richtige SymbolListe sein, sodaß ich mehrere Tags angeben kann. Steht zumindest hier beschrieben, dass es funktionieren soll:


http://lilypond.org/doc/v2.18/Documentation/changes.pdf


Jedenfalls könnte ich dann so die Pfade angeben, wenn ich bei jedem include-Befehl so eine tag-Definition voranstelle.

harm6

Zitat
auf den Artikel bin ich auch schon gestoßen, allerdings empfinde ich das als viel zu kompliziert und mit Kanonen auf Spatzen geschossen. Da müsste ich ja jetzt den gesamten Tree selber zusammen programmieren und dann scheinen die dort beschriebenen Funktionen auch noch fest kodiert zu sein, wenn man sowas wie die Voice-Definitionen sieht. Außerdem werde ich den Eindruck nicht los, dass ich damit nur die Leafs des Trees ausgeben kann und nicht den ganzen Pfad dahin.

Ich habs nicht probiert. Kann also eigentlich nichts weiter dazu sagen. Es schien mir abgesehen von tags (s.u.) am ehesten auf Dein Vorhaben zu passen.

ZitatDa neige ich doch eher zu der Idee mir den GCC zu installieren und den normalen C++ Präprozessor über das .ly File zu jagen. Anschließend kann man das so präprozessierte File immer noch durch Lilypond parsen lassen. Allerdings weiß ich nicht ob der C++ Präprozessor damit klar kommt, dass in Lilypond Files auch mal # vorkommt.

Das halte ich für eine Schnapsidee ;)

Zitat
Ich habe aber noch eine andere Variante gefunden. Es wird beschrieben, dass ab Version 2.18 der Befehl \keepWithTag eine Liste mit Symbolen erlaubt. Ich habe die Version 2.18.2-1. Da ich kein Lilypond bzw. Schema-Experte bin, weiß ich aber nicht, wie man eine Liste von Symbolen syntaktisch hinschreibt? Hat da jemand Ahnung? Im Netz habe ich da bisher auch nix gefunden.

Wieso Netz? Schau doch in die Doku:
http://lilypond.org/doc/v2.18/Documentation/notation/different-editions-from-one-source#using-tags


ZitatLeider scheint das \keepWithTag auch nicht außerhalb eines \book zu wirken
Natürlich nicht.
keepWithTag ist eine Musikfunktion, die Musik als (zweites) Argument erwartet und auch Musik ausgeben muß.
Ein book ist keine Musik im LilyPond-Sinne mehr. Es enthält möglicherweise multiple bookparts mit möglicherweise multiplen scores sowie header und layouts/papers.
Musik im LilyPond-Sinne ist innerhalb eines scores zu finden, der aber auch wieder eigene layouts/headers haben kann.

Aber wenn Dir Jan-Peters Zugang nicht zusagt, sind tags wahrscheinlich das Mttel der Wahl.

Gruß,
  Harm



rgree

#6
Hallo,

tatsächlich funktioniert keepWithTag mit mehreren Parametern, z.b.:

\keepWithTag #'(partsOnly formatiertNachVorlage allNumbers) \satzIxCello

Das benutze ich extensiv.
Ist übrigens in der Doku "notations" auch dokumentiert.

Gruß,
Reinhard

Ooops, das wurde ja schon in der vorhergehenden Antwort gesagt; habe ich übersehen.






unique75m

Vielen Dank erstmal für eure Hilfe.

Die Tags habe ich schon probiert, welche aber wie erwähnt nicht außerhalb von score-Definitionen funktionieren. Außerdem scheinen diese in PianoStaffs/GrandStaffs ebenfalls ignoriert zu werden. Ich konnte mittels Tags einzelne Voices abschalten und die übergeordneten Staffs ebenso, wenn ich weit oben im score die \removeWithTag Befehle eingebaut habe. Die multiple Angabe von Symbolen bei \keepWithTag hat auch immer mal nicht richtig funktioniert. Bei dem Pianostaff mit 2 SubStaffs a 2 Voices hat es dann auch versagt. Ich könnte zwar die beiden Voices eines SubStaffs abschalten, aber als ich den SubStaff selbst abschalten wollte, hat er trotzdem wieder einen Violinschlüssel gezaubert. Möglich das das daran lag, dass es in einem PianoStaff eingebettet war und der das immer so tut, wenn nix da ist. Vielleicht prüfe ich das nochmal mit einem GrandStaff.

Unabhängig davon funktioniert der ganze Kram eben nur innerhalb eines Score. Da muss mir schon mal jemand erklären wie man ein Buch mit 4 Scores schreibt, wo jeder Score 12 Stimmen hat + Piano-Double-Staff und wo ich dann am Ende sagen kann... bitte printe mir mal das Buch, aber von jedem Score nur die Violinstimme. Dafür benötige ich ein Conditional-System, was auch ganz weit außen funktioniert, sodaß ich das book.ly includen kann und dort die gewünschten Pfade definiere.

Ich habe aber weiter herum gedoktert, anders kann man das echt nicht bezeichnen :-)
Ich habe eine Funktion gefunden, die hieß glaube ich ifDefinedElse. Diese habe ich etwas umgebaut, sodaß man 2 Argumente vergleicht und bedingte Musikausdrücke damit erreicht.


if-equal =
#(define-music-function
(parser location a b music else)
(string? string? ly:music? ly:music?)
(if (equal? a b) music else))


Funktioniert aber dummerweise auch nur innerhalb von score, da es eine Musikfunktion ist. Alle Versuche sind bis dato gescheitert, diese Funktion mal mit normalem Scheme zu schreiben. Mir gelingt es nicht mal, z.B. das Argument b wegzulassen und durch einen konstanten String zu ersetzen. Momentan benutze ich die Funktion so am Anfang eines .ly Files


\if-equal #scoreOne-staffOne-voiceOne "visible"
     {
     Mein Code
     } {}


In meiner edition.ly definiere ich dann nur die ganzen Variablen wie scoreOne-staffOne-voiceOne als "visible" oder "invisible". In der edition.ly include ich das gesamte book.ly.
Ich wollte eigentlich aufbauend auf dieser Funktion eine 2. Funktion schreiben, die dann if-visible heißt und das Argument b dann als literalen String einsetzt, z.B. so


if-visible =
#(define-music-function
(parser location a music else)
(string? string? ly:music? ly:music?)
(if-equal a "visible" music else))


Scheinbar bin ich aber zu doof für Scheme-Syntax. Abgesehen davon hätte ich all diese Funktionen gern als Nicht-Musik-Funktionen, sodaß man sie außerhalb von book benutzen kann.

Hilflos-im-Code

Zitat von: unique75m am Dienstag,  1. Mai 2018, 18:31
meinem Geigenlehrer geben,
So wie ich meine Kollegen kenne, würde ich dir abraten, so etwas mit Lilypond zu machen.

Grundsätzlich würde ich aber etwas suchen, mit dem dein Lehrer umgehen kann und will. Ich würde ihn nicht zwangsbeglücken.

Weil in einem deiner Post auch MuseScore erwähnt wurde, habe ich den Verdacht, es soll nichts kosten. Es handelt sich aber ja um eine Art Lebenswerk deines Geigenlehrers? Wenn er so viel Vorarbeit oder Unterstützung von einem anderem braucht, ist die Frage, ob er das dann für sich selber weiter betreibt.

Wenn ihm eine Digitalisierung wirklich wichtig wäre, hätte er es schon in Angriff genommen. Wenn er es noch nicht getan hat, ist es ihm nicht wichtig genug oder die Denke dafür ist ihm so fremd, dass die Frage ist, ob Du diese Fremdheit überbrücken kannst, sodass er selbstständig arbeiten kann. Wenn er sich bis jetzt noch nicht auf den Hosenboden gesetzt hat, hilft es nicht, wenn Du Dich für ihn auf den Hosenboden setzt.

unique75m

Hallo lieber Hilflos-im-Code,

grundsätzlich möchte ich erstmal diese Dinge für mich digitalisieren, weil ich das handgeschriebene oftmals zu schlecht entziffern kann und ich das Papierblättern leid bin. Ich möchte am Ende auf ein Tablet oder besser so einen 13 Zoll eBook Reader von Onyx gehen. Wenn ich dann pro Woche mal ein neues Stück bekomme und das digitalisiere ist der Arbeitsaufwand ok, sofern das Tool eben einem nicht ständig kilometerlange Baumstämme zwischen die Beine wirft :-)

Deswegen benötige ich ein wiederverwendbares, leserliches und wartbares Template, damit ich schnell das neue Lied eintippen kann. Dabei möchte ich einerseits das Gesamtwerk mit allen Stimmen auf A3 drucken und andererseits eine einzelne Violinstimme auf A4, wobei aber eben die gesamten anderen Dinge wie Score-Titel usw. weiterhin sichtbar sein müssen. Auf dem A4 können dann die Noten z.B. größer dargestellt werden, um den Platz besser auszunutzen und die Lesbarkeit zu erhöhen. Gerade für Anfänger wie mich sind große Noten doch schöner :-)

Die Hoffnung (wenn auch eben nur die Hoffnung) ist, das es dann meinen Geigenlehrer überzeugt und er dann ebenfalls digital schreibt. Hier liegt der große Knackpunkt bei ihm aber, dass er bisher kein Programm gesehen hat, wo er schneller eingeben kann als wenn er handschriftlich schreibt. Da fallen meiner Meinung nach solche Programme wie MuseScore auch schon raus, weil das lästige Nachbearbeiten viel zu viel Zeit kostet. Wenn ich schon das große A3-Werk umfangreich nachformatiere, damit Notenhälse oder Bögen sich nicht überschneiden und dann die Auszüge einzelner Stimmen auch nochmal, dann wird man einfach irre bei dem Zeitaufwand.

Ich glaube aber dass man das mit der bedingten Kompilierung direkt in Scheme/Lilypond vergessen kann. Mir ist bewusst geworden, dass Scheme eine funktionale Sprache ist und somit keine lazy-evaluation hat, jedenfalls nicht ohne zusätzliche Handstände zu machen. Das macht es z.B. unmöglich eine Funktion wie if-equal zu bauen, die ein if drin hat und dann diese if-equal wiederzuverwenden in anderen Funktionen. Wenn man die äußere Funktion aufruft werden die Parameter sofort ausgewertet, noch bevor sie an die innere Funktion mit dem if gehen. D.h. es werden Ausdrücke ausgewertet, die garnicht ausgewertet werden würden, wenn man direkt das if hinschreibt. Zudem ist es nicht möglich Variablen außerhalb von book zu definieren, die dann komplette Lilypond-Anweisungen enthalten, die in dem Kontext nicht erlaubt sind. Wahrscheinlich muss man hierfür jedesmal Scheme-Funktionen definieren, weil evt. der Funktionsbody eben nicht gleich ausgewertet wird, wobei ich daran auch nicht ganz glaube :-)
Jedenfalls macht es das in vielen Fällen kompliziert bis unmöglich modular zu denken und wiederverwendbaren Code zu schreiben. Ich denke ohne echten Preprocessor wird man hier keinen Blumentopf gewinnen.

Arnold

Hallo,

ich habe in der Vergangenheit eigentlich nur ein wirklich größeres Projekt gestemmt - 24 Stücke einer Sammlung von Salonorchestermusikstücken, von denen es nur Einzelstimmen und Pianodirektion gab, aber keine Partitur und schon gar nicht alle aktuell benötigten transponierten Stimmen.
Ich glaube, da sind fast eintausend LY-Dateien daraus geworden, und unter Windows habe ich das 2-GB-Limit für (bestimmte) 32-Bit-Programme geknackt - aber ich konnte die EXE als 'large-address-aware' umdeklarierten, und LILYPOND.EXE hatte damit kein Problem.

Der erste Grundsatz war die Trennung von Stimmdefinition und PDF-Definition - genauso wie ich es bei der Anwendung von aktuellen 3D-CAD-Programmen als Trennung zwischen Zeichnung und 3D-Modell gewohnt bin.
Für manche unbedarfte Anwender mag es komisch klingen, daß man »für eine Kleinigkeit« immer zwei Dateien anlegen muß. Im CAD ist das normal, da ich ja ein Einzelteil ohne dessen Zeichnung in einer Baugruppe wiederverwenden will.

Grundsätzlich eine Datei, in welcher eine Variable mit der Musikdefinition eines Satzes einer Stimme festgelegt wird. Dabei ist natürlich ein bestimmtes Namensschema für Variablennamen und Dateinamen entstanden. 24 Stätze für 1Fl, 2Cl, 2Tr, 2Hr, 1Pos/Tenorhorn, 2Ve, 1Va, 1Vc/Cb, Perc, PianoDirektion, Akkordeon, Violine-Obligat, Schlagwerk (also 17 Stimmen, die doppelzeiligen nur einmal gezählt) macht schon 408 Dateien.

Diese 408 Dateien habe ich aber nicht direkt in ein PDF übersetzt, dazu war jeweils eine weitere Datei zuständig, welche dann nur geringste Änderungen (Namensschema für Variablennamen und Dateinamen) untereinander benötigen. Damit habe ich beim Abschreiben also meine Abschrift der Einzelstimmen korrigiert.
Außerdem habe ich auch den Titel (piece = im Header-Block des Score) in eine (insgesamt 24) Dateien geschrieben und per include eingebunden.

Auch die 24 Partiturzusammenstellungen wurden als Musikdefinition in je einer separaten Datei festgelegt, und je eine weitere Datei diente zum Erstellen des PDF der Partitur des einzelnen Satzes.

Genauso wie die Partitur sind dann die Einzelstimmen Schritt für Schritt (Satz für Satz) gewachsen - mit dabei ettliche transponierte Stimmen.

Außerdem gab es noch ein paar Dateien mit globalen Konfigurationsinhalten (z. Bsp. Paperblock für die Einzelstimmen).


Im Falle von Varianten habe ich übrigens einen Vorläufer der künftigen tagGroup-Funktionalität genutzt.


Arnold

P.S. Der zweite Band dieser Salonorchestermusik bzw. die nächsten ca. 200 Seiten Partitur warten noch darauf, daß ich Zeit finde es anzugehen.

Hilflos-im-Code

#11
Zitat von: unique75m am Mittwoch, 16. Mai 2018, 13:45
Die Hoffnung (wenn auch eben nur die Hoffnung) ist, das es dann meinen Geigenlehrer überzeugt und er dann ebenfalls digital schreibt. Hier liegt der große Knackpunkt bei ihm aber, dass er bisher kein Programm gesehen hat, wo er schneller eingeben kann als wenn er handschriftlich schreibt.
Zitat des Profs der vor ca 30 Jahren als erster Computernotensatz mit Finale an meiner MuH machte. "Was ich bei der Eingabe an Zeit verliere, gewinne ich mit Faktor vier bei den Proben."

Grundsätzlich gilt das Zitat heute auch noch. Notensatz am PC dauert länger als Handschrift, aber man hat Gewinne in der Arbeit mit den computergesetzten Noten. Deswegen machst Du dir ja die Arbeit.

Du müsstest deinen Lehrer eher davon überzeugen, dass sein Unterricht vielleicht besser laufen würde.

Heißes Eisen. Ich kenne Leute, die haben eine Notenhandschrift, die superleserlich ist und es gibt Schmierer. Dein Lehrer gehört, wenn ich dich recht verstehe, zur zweiten Gruppe. Da ist Vorsicht geboten, weil das in das Fahrwasser geraten könnte, er gibt sich nicht genügend Mühe für sein Schüler. (Schon alleine die Tatsache, dass Du Material bekommst, welches Du in ein Notensatzprogramm wirfst, weil es so schwer leserlich für dich ist, finde ich befremdlich Als es nur Finale für 2000 DM gabe, gab es notgedrungen Kollegen mit handschriftlichen Material. Das war aber immer deutlich sorgfältiger als ihre normale Notenhandschrift. Hälse und Balken mit Lineal gezogen usw.)

Dann noch ein Post von mir, weil Du ja verschiedene Ausgabemedien haben willst: https://lilypondforum.de/index.php/topic,207.msg1302.html#msg1302 Soll heißen, weil es bei einem Medium gut aussieht, sieht es bei dem anderen nicht gut aus.

unique75m

Hallo Hilfslos-im-Code,

danke für den genialen Tipp mit dem Zeitaufwand bei den Proben :-)
Ich denke das ist ein sehr gutes Argument, was auch meinen Lehrer überzeugen könnte :-)
Es ist ja auch nicht so, dass alles komplett unleserlich wäre, einfache Stücke sind noch leserlich. Es gibt aber auch Werke wo es 2-3 Stimmen pro Notenzeile gibt und wo die Noten so dicht gepackt sind, dass man als Anfänger eigentlich nur noch einen Wald aus Strichen und Punkten sieht. Ich kann da nicht mal die Tonart oder Taktart deuten oder irgendwelche Versetzungszeichen innerhalb der Noten. Und ja, da hat dein Professor wohl recht, man spart zwar Zeit beim Schreiben, aber verliert 4x soviel Zeit bei den Proben, weil es keiner richtig lesen kann. Ich bin leider Anfänger und scheitere zugegebenermaßen auch oft an der Spielgeschwindigkeit in der Gruppe, aber eine deutliche Notenschrift reduziert auf meine Violinstimme würde da vermutlich schonmal eine kleine Besserung sein. Und das ständige Mitschleppen/Durchwühlen eines Papierstapels, der immer größer wird, würde dann auch wegfallen.

Neulich hatte ich mal ein altes Werk in den Händen (nicht von meinem Geigenlehrer), da war auf den 1. Blick garnicht erkennbar, dass es Handschrift ist. Da musste ich erst dreimal hinschauen um kleine Unregelmäßigkeiten bei den Notenköpfen zu erkennen. Das Schriftbild fand ich schon Wahnsinn. Da hatte sich jemand richtig Mühe gegeben und scheinbar alle Notenhälse mit Lineal ausgerichtet usw.. Den Zeitaufwand um das so perfekt hinzukriegen möchte ich mir aber nicht ausmalen :-)

Zu Arnold...

Es klingt so, als würdest du dieselbe Herangehensweise haben wie ich. Lieber kleine überschaubare und wiederverwendbare Schnipsel in Einzeldateien. Ich muss aber zugeben, dass ich nicht alles an deinen Erläuterungen verstanden habe. Wenn man das allerdings ohne Conditional Compiling macht, landet man unweigerlich bei sehr vielen Strukturdateien, weil man ja für jede "Partiturzusammenstellung" die Strukturdateien kopieren/anpassen muss. Das ist redundanter Code oder CopyPaste-Programmierung. So verwaltet man heutzutage kein größeres Softwareprojekt. Sobald nämlich irgendeine Strukturänderung ansteht, die auf alle "Partiturzusammenstellungen" wirken soll, muss man das in all den zig kopierten Strukturdateien nachziehen. Das erhöht den Aufwand und die Fehleranfälligkeit ungemein. Deswegen bin ich auch so vehement gegen solche Lösungen, weil es gegen alle guten Regeln der Softwareentwicklung spricht, die mühsam in den letzten Jahrzehnten definiert wurden.

Meine Vorstellung ist, dass ich einmal die Strukturdateien erstelle, die wie ein Baum hierarchisch aufgefächert sind. Die book.ly enthält alles Notwendige für die Buchdefinition (z.b: Version, Paper und Layout Block) und inkludiert am Ende alle scoreXX.ly. In den scoreXX.ly steht das Notwendige für den jeweiligen Score und es werden die staffXX.ly inkludiert. In den staffXX.ly definiert man sowas wie den InstrumentName und inkludiert die voiceXX.ly. In den voiceXX.ly steht dann eigentlich nur noch, dass ich ein \new Voice mache mit den Noten. In jeder dieser Dateien möchte ich eine if-Direktive um den gesamten Dateiinhalt machen, welche den Wert einer Variablen testet. Ganz oben in der Hierarchie stehen dann über dem book.ly noch die editionXX.ly, wo ich dann nur die ganzen Variablen für die if-Blöcke definiere oder eben nicht definiere und damit die Sichtbarkeit der Dateiinhalte steuere. Die editionXX.ly includieren dann immer nur das book.ly und verwenden so den Strukturcode immer wieder. Das macht dann bei einem Buch mit 1 Score mit 12 Staffs zu je 2 Voices = book.ly + score.ly + Anzahl Staffs * Anzahl Voices = 26 Dateien. Will man jetzt noch die editionXX.ly haben für die Gesamtpartitur und für jeden Staff einzeln, so kommen nochmal 13 Edition-Dateien hinzu.

Um das ganze noch einfacher zu machen bzw. damit ein solches Template in puncto Staff-Anzahl und Voice-Anzahl flexibler wird wäre es hilfreich wenn man einen \include Befehl hätte, der mit Wildcards oder regulären Ausdrücken umgehen kann. Dann kann man z.B. in einer staff01.ly einfach sagen, dass er alles includieren soll was wie "staff01-voice*.ly" heißt, wobei der Stern eben der Wildcard für beliebigen Ausdruck ist. Schon kann ein Außenstehender eine Stimme hinzufügen, ohne das er in die staff01.ly irgendwelche Strukturbefehle zu tippen hat. Er würde dann einfach eine neue Datei erstellen die dem Namensschema entspricht, sie würde dann automatisch inkludiert werden. Auch dies gibt es nicht in Lilypond, wodurch die \include Definitionen sehr statisch und festgezurrt sind.

Noch einfacher wird's dann, wenn mal so Umgebungsvariablen wie $(FILENAME) existieren, sodaß man den Dateinamen ermitteln kann, in der man sich gerade zum Kompilierzeitpunkt befindet. Dann kann man auch sowas schreiben wie

    \include "$(FILENAME)-voice*.ly"

Schon kann man eine staff.ly einfach kopieren, umbenennen und fertig. Alle zugehörigen voice.ly Dateien müssen dann dem Namensschema der staff.ly folgen. Sowas gibt es heutzutage in allen gängigen Entwicklungsumgebungen wie VisualStudio.

ingmar

Zitat...wenn mal so Umgebungsvariablen wie $(FILENAME) existieren, sodaß man den Dateinamen ermitteln kann, in der man sich gerade zum Kompilierzeitpunkt befindet.

https://archiv.lilypondforum.de/index.php/topic,2273.msg12664.html#msg12664


Gruß,
--ingmar

unique75m

Hallo Ingmar,

vielen Dank, aber wie sieht das dann am praktischen Beispiel mit dem Include aus?

\include "staff01-voice01.ly"

Soll zu sowas hier werden:

\include "$(FILENAME)-voice*.ly"

Wobei $(FILENAME) dann durch "staff01" ersetzt werden soll, also den Dateinamen ohne .ly Extensions.
Oder wie kann man z.B. dann den Filename in solch anderem Lilypondcode verwenden, auch wenn das zugegebenermaßen jetzt ein blödes Beispiel ist, dass man den Instrumentnamen aus dem Dateinamen ableitet.

\new Staff \with {instrumentName = $(FILENAME)}

Ich kann nunmal nichts mit abstrakten Scheme-Code-Beispielen anfangen, die dann im Lilypond Code sowieso nicht funktionieren, weil die Ersetzung innerhalb eines Strings nicht geht oder weil der Lilypond-Code an der Stelle wieder mal kein Scheme akzeptiert.