Deutschsprachiges LilyPond-Forum

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.

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

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.

Schau mal hier rein:
http://lilypondblog.org/2014/07/trees-music-and-lilypond/ (http://lilypondblog.org/2014/07/trees-music-and-lilypond/)

Geht das in Deine Richtung?

Gruß,
  Harm

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
(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.

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
(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

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.

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.

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.

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.

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.

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.

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.

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

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.

Hallo unique,

ZitatIch 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.

Was funktioniert unter welchen Umständen nicht?
Warum sollte Ersetzung innerhalb eines strings nicht gehen?
Unter welchen Umständen akzeptiert LilyPond kein scheme?

Mit solch allgemeinen Aussagen kann tatsächlich niemand etwas anfangen.

Falls ein Problem auftaucht, so frag doch.
Natürlich unter Beachtung von
https://lilypondforum.de/index.php/topic,5.0.html (https://lilypondforum.de/index.php/topic,5.0.html)

Ansonsten geh' ich fürs erste davon aus, daß ein unbemerkter Tippfehler vorliegt. ;)


Gruß,
  Harm

Zitat von: unique75m am Mittwoch, 16. Mai 2018, 20:52
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)}

Hier hast Du gefragt.


\include #(format #f "~a/voice-~a.ly" (ly:parser-output-name) 1)
\new Staff \with { instrumentName = #(ly:parser-output-name) } { R1 }


Der string fürs \include muß evtl noch angepasst werden, hängt ja von Deiner Datei-Struktur ab.

Gruß,
  Harm


\version "2.19.81"
InstrumentI = \repeat unfold 100  {c'' c'' c'' c''}
InstrumentII =  \repeat unfold 100 {g' g' g' g'}
InstrumentIII =  \repeat unfold 100 {c' c' c' c'}

Titel = "Bla"

%Edition I

\bookpart {
\paper { system-system-spacing =
  #'((basic-distance . 20)
     (minimum-distance . 10)
     (padding . 4)
     (stretchability . 24))
 
   first-page-number = #1
  }


\score { 
    <<
      \InstrumentI
      \InstrumentII
      \InstrumentIII
    >>
}
     \header {
      title = \Titel

    }
   
 

}



%Edition II

\bookpart {
 
  \paper { system-system-spacing =
  #'((basic-distance . 25)
     (minimum-distance . 15)
     (padding . 4)
     (stretchability . 24))

  }
\header {
      title = \Titel

    }

  \score {
     

    <<
      \InstrumentI
      \InstrumentII

    >>
   
\layout { #(layout-set-staff-size 26)}

  }




}

Könnte vielleicht das die Lösung sein. Du machst alle Ausgaben auf diese Art in ein PDF. Die einzelnen Abschnitte kann man dann entsprechend wie nötig ausdrucken.

Edit: Ich hatte in Frescobaldi den Eindruck, dass die sich ändernden Papierformate berücksichtigt werden. Tut es aber nicht. Das ist aber pragamatisch gesehen höchtwahrscheinlich egal.

Auf den Notenständer liegt normalerweise DIN4. Es geht nur darum, das Du unterschiedliche Stimmauszüge hast. Partitur, Klavierauszug mit kleinen Instrumentenzeilen und die Einzelstimmen. Das ist einfach DIN4. Das ginge mit meiner Aufteilung.

Das einzige Problem könnte der E-Reader mit seinen 13 Zoll sein. Wenn das Blatt voll angezeigt wird, sind die Noten zu klein. Kannst man den weißen Rand ausblenden oder die Darstellungsgröße des Blattes variieren, dann müsstest Du die gleiche Lesegröße hinbekommen.

Und ein Wermutstropfen kommt dazu, die Seitenzahlen scheint man nicht manipulieren zu können.  Aber das regeln die Taktzahlen oder Harm.

Hallo unique75m

ZitatSobald 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.

Durch ein simple-grep.ly und funktionierenes pointAndClick hilt sich der Aufwand bei mir in engen Grenzen.

Heute weiß ich auch, daß es funktioniert, eine (temporäre) Include-Datei erst kurz vor dem Include-Kommando zu erstellen - notfalls durch einen System-Call mittels eines Programms in einer beliegiben Programmiersprache.

---

Vielleicht benötigt man für LILYPOND zuerst noch jemanden, der den Funktionsbedarf für das konditionelle Kompilieren genau spezifizieren kann? Bisher hat Lilypond keinen Preprozessor wie ihn jeder C-Compiler hat, geschweige denn einen der an C++ heranreicht.

Arnold

Hallo allerseits

Lieber Harm, danke für die Beispiele, jetzt weiß ich zumindest wie man den Filename innerhalb von Lillypond reinkriegt, also quasi auch mit einem Schema-Ausdruck. Das Innlude-Beispiel habe ich aber noch nicht genauer angeschaut, da muss ich erstmal googeln was der Format Befehl eigentlich tut.

Lieber Hilfslos-im-Code, ich denke dein Beispiel ist genau das, wo ich nicht hin will. Wenn du dieses Beispiel nun auf 4 Scores mit 12 Staffs und je 2 Voices erweiterst, dann noch alle möglichen anderen Optionen in den Scores (\header \layout), in den Staffs die instrumentalName als multiline-center-Texte und sonstige Steuerangaben wie Treble, Tonart, Taktart usw. dann hast du am Ende ein ziemlich undurchsichtiges Strukturwirrwarr. Außerdem müsste ich das jedesmal, wie von dir übrigens selbst schon beschrieben, kopieren, um die verschiedenen Editionen abzudecken. Da wiederhole ich den Strukturcode dann nochmal. Ja man kann wiederkehrende Dinge mit Variablen einmalig definieren, aber eben nicht die ganzen Strukturdinge wie \score {} oder \new Staff {}. Ich kann nur die Inhalte wie Noten als Variablen definieren. Bei allen anderen Sachen meckert Lilypond, sobald man es außerhalb von \book definiert, weil es nicht im passenden Kontext ist. Außerdem würde man so seine gesamte Struktur zerreißen.

Hier ist mal ein Auszug der Dateien, wobei ich jetzt nur einen Staff und eine Voice hier reimkopiert habe. Du wirst dich sicher fragen, warum ich in den \header alle möglichen Variablen auf leere String setze. Das tue ich deshalb, weil das ganze mal ein Template werden soll für Leute die noch weniger Ahnung haben als ich. Die sollen dann anhand des Dateinamens wissen, in welche Datei sie gehen müssen und sofort sehen, was sie alles sinnvolles ändern können. Die if-equal Funktion soll dann auch irgendwann mal in eine utilities.ly verschwinden. Eigentlich würde ich gern noch mehr Code wie z.B. die \paper-Blöcke oder diese \context-Engraver-Blöcke in die utilities.ly verschieben, aber Lilypond mag das eben nicht, wenn man da nur normale Variablen damit definiert, dann führt er den Code im falschen Kontext aus. Ich denke hier muss man Schema-Funktionen schreiben, was auch wieder aufwändig ist.

book.ly

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

\book
{
\version "2.18.2"

\paper
{
#(set-paper-size "a3" 'landscape)
print-all-headers = ##t
ragged-right = ##f
}

\header
{
dedication = ""
            title = ""
            subtitle = ""
            subsubtitle = ""
            instrument = ""
            poet = ""
            composer = ""
              meter = ""
            arranger = ""
            tagline = ""
            copyright = ""
}

\include "./score01.ly"
}


score01.ly

\score
{
\header
{
dedication = ""
            title = "Alle Jahre wieder"
            subtitle = "Ablauf: Vorspiel ab Takt 5 + 5x, 4. Durchlauf = Zwischenspiel"
    subsubtitle = ""
    instrument = ""
    poet = "Wilhelm Hey"
            composer = "Friedrich Stitcher"
        meter = ""
            arranger = ""
            tagline = ""
    copyright = ""
piece = ""
opus = ""
}

\layout
{
\context
{
\Score
\remove "Bar_number_engraver"
}

\context
{
\Staff
\consists "Bar_number_engraver"
}

\override Score.BarNumber.break-visibility = #end-of-line-invisible
\set Score.barNumberVisibility = #(every-nth-bar-number-visible 2)
}

<<
\include "./score01-staff01.ly"
\include "./score01-staff02.ly"
\include "./score01-staff03.ly"
                \include "./score01-staff04.ly"
\include "./score01-staff05.ly"
\include "./score01-staff06.ly"
>>
}


staff01.ly

\if-equal #scoreOne-staffOne "visible"
{
\new Staff
\with
{
instrumentName = \markup
{
\center-column
{
\line {Solo Violin}
\line {ad lib.}
}
}
}
{
\clef treble
\key c \major
\time 4/4

\include "./score01-staff01-voice01.ly"
}
} {}



\if-equal #scoreOne-staffOne-voiceOne "visible"
{
\new Voice
{
\relative c'
{
c8 \mf c'8 (b8 a8) e'4 f4
c4. b16 (c16) d2
a4 \downbow b8 (c8) b8 (c8) d8 (e8)
g,2 r8 a'8 (g8 f8)
e4 \< e4 (d4 e4) <> \!
c4. b16 (c16) d4 d4 \upbow
g,4 c4 b4. \> a16 (b16) <> \!
c1
\bar "|."
}
}
} {}


So und nun gleich noch die Beispiele, welche nicht funktionieren, damit Harm seine wertvolle Zeit verschwenden kann :-)
In folgendem Beispiel mag er scheinbar den Schema-Code nicht in der if-equal Funktion, weil die eben vom Typ nur musikalische Ausdrücke kann, ein Lob an alle typisierten Sprachen. Man hat mehr Ärger als Freude mit Typen :-)
Schön wäre es auch wenn die if-equal Funktion eben nicht nur innerhalb von \score funktionieren würde.


\if-equal #test "visible"
#(set-paper-size "a3" 'landscape)
{}


Im folgenden Beispiel kann ich keinen Strukturcode in einer Variablen ablegen außerhalb von \book. Vermutlich muss ich hier eine Schema-Funktion definieren, die diesen Lilypond-Code ausgibt.


mypaper =
\paper
{
#(set-paper-size "a3" 'landscape)
print-all-headers = ##t
ragged-right = ##f
}

\book
{
\version "2.18.2"

\mypaper
}


Ich würde liebend gern in der utilities.ly so einige Hilfsfunktionen und Codeschnipsel ablegen. Diese wird dann aber eben außerhalb von book.ly als erstes inkludiert. Solche Codeschnipsel wären dann eigene \paper-Block-Definitionen oder dieses Context-Gefummel mit dem Bar_number_engraver.

Gibt es eigentlich eine einfachere Möglichkeit MultiLine-Texte zu erzeugen bei den Instrumentnamen? Ich dachte da an sowas wie "Line1\nLine2", also ein \n als NewLine.

Zitat von: uniqueLieber Harm, danke für die Beispiele, jetzt weiß ich zumindest wie man den Filename innerhalb von Lillypond reinkriegt, also quasi auch mit einem Schema-Ausdruck. Das Innlude-Beispiel habe ich aber noch nicht genauer angeschaut, da muss ich erstmal googeln was der Format Befehl eigentlich tut.

Ich würd' nicht googlen, sondern ins guile-manual schauen. Aber achte darauf das für guile-1.8 zu finden.
LilyPond verwendet noch diese guile-version, da es mit guile-v2 massive Probleme gibt.
Vom Grund für diese Probleme abgesehen ist guile-v2 anders genug, daß der Blick ins falsche Manual in die Irre führen mag.
Bei manchem wäre es allerdings schön es zu haben, ein Beispiel weiter unten.

Aber Du kannst Dir auch einfach anzeigen lassen was passiert:
#(write (format #t "~a/voice-~a.ly" (ly:parser-output-name) 1))
zeigt den String im Terminal.

Zitat von: uniqueSo und nun gleich noch die Beispiele, welche nicht funktionieren, damit Harm seine wertvolle Zeit verschwenden kann :-)

lol

Zitat von: uniqueIm folgenden Beispiel kann ich keinen Strukturcode in einer Variablen ablegen außerhalb von \book. Vermutlich muss ich hier eine Schema-Funktion definieren, die diesen Lilypond-Code ausgibt.

Code Auswählen Erweitern

mypaper =
\paper
{
#(set-paper-size "a3" 'landscape)
print-all-headers = ##t
ragged-right = ##f
}

\book
{
\version "2.18.2"

\mypaper
}

In neueren devel-Versionen, funktioniert das out-of-the-box.

In 2.18.2. verwende:


\book
{
\paper { \mypaper }
}

Genauso mit layout.

Die Versionsangabe gehört nicht ins book, sondern auf toplevel-Niveau. Meistens wird sie ganz oben als erstes im file angegeben. Der Sinn ist ja, daß das file mit dieser Version geschrieben bzw kompilierbar ist und nicht nur ein Teil des files.
Ein bißchen wundert es mich, daß keine Warnung erfolgt...
Aber das ist nur eine Nebenschauplatz.

Zitat von: uniqueEigentlich würde ich gern noch mehr Code wie z.B. die \paper-Blöcke oder diese \context-Engraver-Blöcke in die utilities.ly verschieben, aber Lilypond mag das eben nicht, wenn man da nur normale Variablen damit definiert, dann führt er den Code im falschen Kontext aus.

Siehe oben.

Zitat von: unique
In folgendem Beispiel mag er scheinbar den Schema-Code nicht in der if-equal Funktion, weil die eben vom Typ nur musikalische Ausdrücke kann, ein Lob an alle typisierten Sprachen. Man hat mehr Ärger als Freude mit Typen :-)
Schön wäre es auch wenn die if-equal Funktion eben nicht nur innerhalb von \score funktionieren würde.

Code Auswählen Erweitern

\if-equal #test "visible"
#(set-paper-size "a3" 'landscape)
{}

Wenn man davon absieht das `test' in diesem snippet nicht definiert ist, so ist der Ausdruck
#(set-paper-size "a3" 'landscape)
in der Tat in der Tat problematisch.

LilyPond kennt verschiedene Funktionstypen, music-function, scheme-function, event-function und void-function.

Ich habe versucht etwas zu entwickeln, das per Fallunterscheidung den richtigen Ausdruck zurückgibt oder eben gar nichts (wie die void-function).
#(set-paper-size "a3" 'landscape) wäre für eine void-function passend.
Das Problem ist aber das set-paper-size mit `module-define!' arbeitet.
In guile-1.8 gibt (module-define! ...) aber #f aus. Also einen regulären scheme-Ausruck, ein boolean. Es ist somit nicht von anderen boolean zu unterscheiden. In guile-v2 wird #<unspecified> retourniert, wie für alle set-was-auch-immer-procedures. Diese set-procedures sind u.a. das Aufgabengebiet der void-function. Um im \paper weiter zu kommen bräuchte man aber eine void-function dafür...

Schon diesen Unterschied bei guile-v1/2 gelernt zu haben, hat sich für mich gelohnt ;)

Um trotzdem weiterzukommen hier ein workaround, der im \paper auf jegliche Funktion verzichtet:


#(define (if-equal a b what else)
  ;; never return #f, but an empty list as fall-back
  (if (equal? a b)
      (or what '())
      (or else '())))
         
ifEqual =
#(define-scheme-function
  (parser location a b what else)
  (scheme? scheme? scheme? scheme?)   
  (if-equal a b what else))
   
 
\paper {
  #(if-equal "x" "xy" (set-paper-size "a3landscape") '())
}


{ R1 }

{ \ifEqual "x" "xy" { c'1 } { cis'1 } }


Übrigens schreibe besser (set-paper-size "a3landscape"), denn (set-paper-size "a3" 'landscape). Das 2.18.2-manual ist da falsch. Neuere devel-Versionen machen da einen Unterschied.


Soviel für jetzt.

Dein genereller Plan erweckt Zweifel, ob der Durchführbarkeit bei mir. Insbesondere daß Du nicht mit Variablen für Voice, Staff, score, book arbeiten willst, sondern den entsprechenden Staff immer direkt via \include kopierst.

Ich hab zwar selbst etwas rumprobiert, bislang ist das Ergebnis aber nioch nicht überzeugend. Vielleicht demnächst.


Gruß,
  Harm

Zitat von: uniqueGibt es eigentlich eine einfachere Möglichkeit MultiLine-Texte zu erzeugen bei den Instrumentnamen? Ich dachte da an sowas wie "Line1\nLine2", also ein \n als NewLine.

Z.B.:

\markup
  \column {
    \wordwrap-string
    #"
    Wie die volle Traube\n
    Aus dem Rebenlaube\n
    Purpurfarbig strahlt!\n
    Am Geländer reifen\n
    Pfirsiche, mit Streifen\n
    Rot und weiß bemalt."
  }


Eine Strophe aus "Bunt sind schon die Wälder"

Aber öffne bitte für neue Fragen einen neuen thread.
Das hat ja nichts mehr mit dem Titel dieses zu tun, es soll ja auch später noch auffindbar sein.

Gruß,
  Harm

Übersetzte mir  "4 Scores mit 12 Staffs und je 2  Voices" bitte auf musikalisch. Vier Stücke mit was für Instrumente sind beteiligt?

Die Befürchtung des Strukturwirrwarrs dürfte eher eine Folge deines mangelnden Wissens als musikalischer Anfänger sein. Wie schon gesagt ich bin seit knapp dreißig Jahren Musikschullehrer. Wenn dein Geigenlehrer nicht irgendwelche unorthodoxen Sachen macht, dann kann man das nach Schema F abarbeiten. Die Klimmzüge die Du machst, dürften eher damit zu tun haben, dass Du das Schema nicht siehst, die hinter solchen Sachen stecken und was man im Alltag braucht.


Das heißt, Du gibst die Einzelinstrumente ein. In denen steht alles an Artikulation, Stricharten, Atemzeichen und Fingersatz und die musst Du dann je nach Einsatz zusammenkleben.

Einzelstimmen.
Die Partitur.
Und wenn noch ein Klavier mit macht, die Vorlage für den Pianisten.

Das alles hat bestimmte Layoutregeln, die wenn festgelegt, unveränderlich sind. Daraus macht man ein Template und füttert das dann am Anfang mit den Noten.

Wenn Du so willst entspricht das dem Konzept von CMS (WordPress) Trennung von Layout und Inhalt, Man gibt den Inhalt rein, dass CMS packt das Layout drum herum. Wie vermurkst oder verschachtelt  dann die Struktur des PHPs, ist vollkommen egal, so lange es sauber tut, was es tun soll. Es wird nie wieder angefasst.

Du musst den Inhalt nur einmal eingeben und schaffen ein Template zu basteln, was alle Situationen abdeckt. Weil die Situation einen Schema folgen müsste das möglich sein. Du brauchst dazu auch kein if oder sonst etwas.

Auch deine Idee eines Buches als Gesamtkunstwerk klingt nicht nach etwas, was man im Alltag eines Instrumentallehrers haben will.

Mich interessiert nicht alle meine Werke in einer Datei zu haben, sondern dass ich ganz schnell die Dateien finde, um die Einzelstimmen und eventuell Partituren für die Kollegen auszudrucken. Weil ich aber von allem unterschiedlich viele Exemplare drucken muss, z. B. ein Cello, vier Geigen und drei Partituren, will ich mich nicht mit Seitenzahlen im Druckdialog rumschlagen, sondern die Einzeldateien als PDF  gut strukturiert, damit gut findbar, auf dem Rechner. Also Rechtsklick auf die Datei Cello, Druckdialog erscheint, Exemplarzahl eingeben. Nächste Datei Violine anwählen, usw.


Aber letztendlich soll dein Geigenlehrer das bedienen. Obwohl ich MuseScore von der Nutzerfreundlichkeit schlecht finde, glaube ich, wäre Musescore die bessere Wahl.  Die aufwendige händische Formatierarbeit, die Du befürchtest, müsste sich mit der Pluginschnittstelle, für die man Plugins schreiben kann, in wenig Arbeit reduzieren lassen. (Weil mir das zu schwer war, habe ich Lilypond ausprobiert. Aber Du bist ja anscheinend IT-Ler. Du müsstest klar kommen.)  Die Nachformatierarbeit ist großteils auch sehr schematisch. Weiter kannst Du den Abstand der Zeichen zu den Noten, der perse bei MuseScore schlecht eingestellt ist, in deinem Sinne beeinflussen. MuseScore hat da etwas, was man mit den Formatvorlagen von Word vergleichen kann.

Und MuseScore hat einen weiteren großen Vorteil. Wenn dir in deiner Großprojektvision, das Einzelergebnis einer ganz bestimmen Geigeneinzelstimme eines Stückes nicht passt, dann kannst Du das in Musescore ändern, weil eine neue unabhängige Datei entsteht. Die entsteht bei Lilypond nicht. Das bedeutet, die Änderung taucht überall auf, auch wo Du sie nicht haben willst. (Wenn ich falsch liege, bitte widersprechen. Aber bitte auch den Praxisbezug in Betracht ziehen.)

Irgendwie habe ich einen Doppelpost geschafft, der hier kann gelöscht werden.

Zitat von: harmUm trotzdem weiterzukommen hier ein workaround, der im \paper auf jegliche Funktion verzichtet: [...]

Neuerliche Prüfung meines Vorschlags ergibt, daß er nicht so arbeitet wie erhofft.

Also erstmal nicht verwenden bitte.
Ich komme vor heut' abend aber wohl nicht dazu wieder rein zu schauen.

Gruß,
  Harm

Lieber Harm,

Zitat
In neueren devel-Versionen, funktioniert das out-of-the-box.

schön wenn das dann mal langsam Einzug hält in neueren Versionen. Ich wusste mir auch nur so zu behelfen wie du das als Alternative für 2.18.2 beschreibst, in dem man den Inhalt des Lilypond-Strukturcodes variabel macht. Aber dann kann ich ehrlich gesagt auch gleich nur das "a3" als Variable machen bzw. mit deinem Hinweis, dass man "a3landscape" schreiben kann, brauche ich auch nur eine Variable um das Papierformat umzuschalten.

Zitat
Dein genereller Plan erweckt Zweifel, ob der Durchführbarkeit bei mir. Insbesondere daß Du nicht mit Variablen für Voice, Staff, score, book arbeiten willst, sondern den entsprechenden Staff immer direkt via \include kopierst.

Ich kann mir beim besten Willen nicht vorstellen, wie das funktionieren soll, dass ich bei Voice/Staff usw. mit Variablen arbeite unter der Berücksichtigung, dass ich jeden Staff/Voice separat an/ausschalten will und dass ich eben nicht wie von allen hier ständig beschrieben eine Strukturdatei für jede Edition bauen muss. Ich will auch nicht in irgendeine Einzel-Voice-Datei gehen und die separat drucken, dann fehlen nämlich sämtliche Papiereinstellungen und Score-Titel und Staff-Clefs usw.

So sieht das aus, wenn ich kein Include mehr mache und alles nur per Copy/Paste in eine einzige Datei kopiere, wobei unterhalb nur 1 Staff und 1 Voice drin sind. Es ist so schon unübersichtlich, mit 12 Staffs und noch mehr Voices wird's nicht besser. Nun kann man überlegen, was man davon alles per Variable rauszieht. Logisch, die Noten der Voice erstmal. Die \header von Book und Score kann man ebenfalls rausziehen in eigene Dateien, logo. Aber das ist dasselbe als wenn ich gleich die gesamte Book und Score-Definition rausziehe und die Unterobjekte include. So steht wenigstens ein zusammenhängender Code zusammen und nicht auseindergerissen. Umgekehrt kann man natürlich auch alle Variablen in den \header Blöcken wieder mit Variablen belegen, damit man die Belegung von außen kontrollieren kann, ziemlich bescheuert wie ich finde. Instrumentnamen lassen sich ebenfalls per Variablen rausziehen. Am Ende hat man einen Haufen kontexttloser Variablen und hat eigentlich nichts gekonnt.


\version "2.18.2"

\book
{
\paper
{
#(set-paper-size "a3" 'landscape)
print-all-headers = ##t
ragged-right = ##f
}

\header
{
dedication = ""
            title = ""
            subtitle = ""
            subsubtitle = ""
            instrument = ""
            poet = ""
            composer = ""
            meter = ""
            arranger = ""
            tagline = ""
            copyright = ""
}

\score
{
\header
{
dedication = ""
            title = "Alle Jahre wieder"
            subtitle = "Ablauf: Vorspiel ab Takt 5 + 5x, 4. Durchlauf = Zwischenspiel"
    subsubtitle = ""
    instrument = ""
    poet = "Wilhelm Hey"
            composer = "Friedrich Stitcher"
            meter = ""
            arranger = "Manfred Apitz"
            tagline = ""
            copyright = ""
piece = ""
opus = ""
}

\layout
{
\context
{
\Score
\remove "Bar_number_engraver"
}

\context
{
\Staff
\consists "Bar_number_engraver"
}

\override Score.BarNumber.break-visibility = #end-of-line-invisible
\set Score.barNumberVisibility = #(every-nth-bar-number-visible 2)
}

<<
\if-equal #scoreOne-staffOne "visible"
{
\new Staff
\with
{
instrumentName = \markup
{
\center-column
{
\line {Solo Violin}
\line {ad lib.}
}
}
}
{
\clef treble
\key c \major
\time 4/4

\if-equal #scoreOne-staffOne-voiceOne "visible"
{
\new Voice
{
\relative c'
{
c8 \mf c'8 (b8 a8) e'4 f4
c4. b16 (c16) d2
a4 \downbow b8 (c8) b8 (c8) d8 (e8)
g,2 r8 a'8 (g8 f8)
e4 \< e4 (d4 e4) <> \!
c4. b16 (c16) d4 d4 \upbow
g,4 c4 b4. \> a16 (b16) <> \!
c1
\bar "|."
}
}
} {}
}
} {}

% \include "./score01-staff02.ly"
% \include "./score01-staff03.ly"
% \include "./score01-staff04.ly"
% \include "./score01-staff05.ly"
% \include "./score01-staff06.ly"
>>
}
}


Selbst wenn ich also nun verschiedenste Dinge per Variablen definiere, dann kommt eine Struktur wie das hier raus:


\version "2.18.2"

\book
{
\bookPaper
\bookHeader

\score
{
\scoreHeader
\scoreLayout

<<
\if-equal #scoreOne-staffOne "visible"
{
\new Staff
\with
{
instrumentName = \staffOne-instrumentName
}
{
\clef treble
\key c \major
\time 4/4

\if-equal #scoreOne-staffOne-voiceOne "visible"
{
\new Voice
{
\staffOne-voiceOne-notes
}
} {}
}
} {}

% \include "./score01-staff02.ly"
% \include "./score01-staff03.ly"
% \include "./score01-staff04.ly"
% \include "./score01-staff05.ly"
% \include "./score01-staff06.ly"
>>
}
}


Und diese Strukturdatei vervielfältige ich jetzt nun, fummel dran rum und entferne Teile, die ich in der jeweiligen Edition nicht haben will, nur damit ich kein Conditional Compiling brauche. Das ist redundante CopyPaste-Programmierung. Wenn ich später irgendwas an der Struktur ändern will, müsste ich das dann in allen Editions-Dateien machen, jedenfalls die Dinge, die alle betreffen, logo.


Wenn Du so willst entspricht das dem Konzept von CMS (WordPress) Trennung von Layout und Inhalt, Man gibt den Inhalt rein, dass CMS packt das Layout drum herum. Wie vermurkst oder verschachtelt  dann die Struktur des PHPs, ist vollkommen egal, so lange es sauber tut, was es tun soll. Es wird nie wieder angefasst.


Stell dir vor, du baust deine Webseite für 2 Kunden, welche verschiedene Layoutansprüche haben. Würdest du da etwa auch die gesamte Layoutstruktur von Kunde 1 kopieren, nur um dem einen kleinen Änderungswunsch von Kunde 2 entgegenzukommen? Wenn dann ein halbes Jahr später beide Kunden schreien, dass sie eine bestimmte Sache eingebaut haben wollen, dann fummelst du nämlich zweimal dasselbe in 2 verschiedene Layouts ein. Vielleicht solltest Du auch mal teambasierte Softwareentwicklung machen, dann wirst du schnell merken, dass es eben nicht egal ist, ob ein Quellcode vermurkst ist oder leserlich. Selbst außerhalb eines Teams kämpft man mit seinem Hometeam, bestehend aus "Deinem Ich vor einem halben Jahr", "Dem aktuellen ich, dass sich über den Murks von dir aufregt" und dem "zukünftigen Ich, was sich dann über den Mist aufregt, den du gerade verzapfst".

Bei allem Respekt dir und deiner 30-jährigen Musikschulkarriere gegenüber, aber ich bin seit 14 Jahren Dipl.Informatiker. Ich denke ich habe da einen etwas anderen Blickpunkt auf sowas, insbesondere was Sprachfeatures und etablierte Softwarepraktiken angeht.  :)
Das was hier bisher an Lösungen für das Strukturproblem vorgeschlagen wurde ist nunmal Spaghetticode, Copy/Paste, redundante Quellen/Daten, Unleserlichkeit/Unwartbarkeit. Alles Dinge, die man als Informatiker zu vermeiden versucht, weil man auf kurz oder lang damit nur Probleme und Mehraufwand hat, insbesondere wenn es noch ein Dritter verstehen soll.

@ unique,

Du hast mich in Deinem letzten post explizit angesprochen und es erscheinen lassen als würden sich Deine Äußerung ausschließlich auf von mir getroffene Aussagen beziehen.
Nicht nur ist das unzutreffend, ich empfinge das auch als no-go.

@all

Wenn wir schon dabei sind, so kommen ironische/sarkastische Äußerungen in posts/mails etc oft falsch an.

Und dem nächsten der sagt "ich habe XX Jahre Erfahrung in YY, deshalb ...", dem antworte ich:
XX Erfahrung und immer noch nichts über YY gelernt !? (*)



-Harm

(*)
Wahrscheinlich werd' ichs nicht machen, wär ja ebenfalls sarkastisch ...
Aber solche Aussagen sind für gewöhnlich wenig hilfreich.

Zitat von: unique75m am Freitag, 18. Mai 2018, 14:47

Bei allem Respekt dir und deiner 30-jährigen Musikschulkarriere gegenüber, aber ich bin seit 14 Jahren Dipl.Informatiker. Ich denke ich habe da einen etwas anderen Blickpunkt auf sowas, insbesondere was Sprachfeatures und etablierte Softwarepraktiken angeht.  :)

Du vermischt zwei Personen, ich bin der Musikschullehrer, der dir versucht zu sagen, dass Du aus seiner Sicht wahrscheinlich an den Bedürfnissen deines Geigenlehrers vorbeiproduzierst und das dir unter Umständen das Wissen über solch Notenmaterial fehlt, und Du Probleme deswegen lösen willst, die es in Realität nicht gibt oder dass diese Probleme sich ganz anders Lösen lassen. Dazu muss man aber sich mit der Materie Notensatz als solches auskennen.

[quote  author=unique75m link=topic=294.msg1860#msg1860 date=1526647641]Alles Dinge, die man als Informatiker zu vermeiden versucht, weil man auf kurz oder lang damit nur Probleme und Mehraufwand hat, insbesondere wenn es noch ein Dritter verstehen soll.[/quote] Und deswegen habe ich dich auf Musescore und die Möglichkeit dafür PlugIns zu programmieren hingewiesen. Im Sinne davon, dass es ein dritter und dann noch ein klassischer Musiker, der eigentlich nicht will, die Anwendung verstehen soll, ist Lilypond sowieso die falsche Entscheidung.

Letztendlich versuchst Du ein gewachsenes Projekt wegen deines Einzelprojektes zum Besseren umzumodeln. Das ist ehrenwert, aber wenn man erst ummodeln muss, damit es tauglich ist, dann sollte man sich ein anderes Werkzeug suchen. Oder glaubst Du zehn Jahre gewachsene Struktur verändert sich in Nullkommanichts?

Geh die Sache pragmatisch an und nicht ideologisch.

Lieber Harm,

entschuldige bitte wenn ich irgendwas geschrieben habe, was dich persönlich angegriffen hat. Ich habe meiner Meinung nach nur auf deine Beispiele geantwortet.

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.

Ich denke eben es ist enorm wichtig, das die Dinge übersichtlich, wartbar und verständlich bleiben. Ganze normale Dinge im Softwarealltag und bei Teamarbeit. Mir dann solche Gründe an den Kopf zu werfen, dass es egal ist wie der Code aussieht und der kann ja ruhig total konfus aussehen, ist nicht wirklich hilfreich. Das mag für eure Ansprüche als Einzelkämpfer gelten, aber nicht für mich, denn ich denke nunmal daran, dass auch andere damit arbeiten sollen.

Für mich ist Lilypond bisher eher eine Interface-Sprache, die nicht unbedingt für den Menschen gedacht ist. Ich sehe den Anwendungszweck wohl eher, dass man Lilypond in solchen Programmen wie Denemo als Ausgabe benutzt und im Hintergrund der Lilypond Code generiert wird, sodaß der Faktor Mensch mit diesen komplizierten Quellcode-Details garnicht in Berührung kommt.

Hallo unique,

Zitat von: uniqueentschuldige bitte wenn ich irgendwas geschrieben habe, was dich persönlich angegriffen hat.

Ich achte sehr darauf weder die Verdienste noch die Torheiten anderer (und aller Zwischenstufen) an mein Rervers zu heften.

Hier (https://lilypondforum.de/index.php/topic,294.msg1860.html#msg1860) differenzierst Du jedoch nicht wer was schrieb, sondern antwortest auf verschiedene posts verschiedener Leute, obwohl Du mich namentlich ansprichst.
Ich fühle mich nicht persönlich angegriffen, aber das ist einfach schlechter Stil.

Auch die Aussage(n)

Zitat von: uniqueWenn 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.
[...]
Das mag für eure Ansprüche als Einzelkämpfer gelten,
[...]

Verallgemeinert wieder.
Ganz davon abgesehen, daß ich schlichtweg nicht finden kann, wo jemand versucht hätte Dich zu etwas zu zwingen oder LilyPond als "technologisches Wundermittel" bezeichnet hätte, so sind die Mitglieder hier alle Personen mit individuellen Stärken und Schwächen, Kenntnissen und Kenntnislücken.
Bitte spreche Individuen individuell an.

Übrigens kann ich mich auch nicht an sowas erinnern:

ZitatMir dann solche Gründe an den Kopf zu werfen, dass es egal ist wie der Code aussieht und der kann ja ruhig total konfus aussehen, ist nicht wirklich hilfreich.

Auch für mich selbst gilt natürlich, daß es Gebiete gibt auf denen ich sehr bewandert bin, und es gibt solche für die das nicht gilt.
Preprozessoren sind ein Gebiet auf dem ich mich nicht auskenne.
Vielleicht erinnerst Du Dich, daß ich zum eigentlichen Thema dieses threads, bislang im wesentlichen nur auf Jan-Peters Methode verwiesen, sowie meinen Zweifeln, ob der generellen Herangehensweise Ausdruck verliehen habe.
Darüberhinaus gehe ich mal davon aus, daß Du die Archive schon besucht und nicht fündig geworden bist.
http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=preprocessor&days=0 (http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=preprocessor&days=0)
Vielleicht ist `make' noch was:
http://lilypond.org/doc/v2.19/Documentation/usage-big-page#make-and-makefiles (http://lilypond.org/doc/v2.19/Documentation/usage-big-page#make-and-makefiles)

Aber es ist offensichtlich, daß Du eine feste Vorstellung davon hast wie Dein Project funktionieren sollte.

Soweit ich das überblicke schaffst Du eine unveränderliche Struktur und beklagst Dich, daß sie unveränderlich ist - da ein preprocessor fehlt.
Deine Ablehnung von Variablen führt auch dazu, daß eine von LilyPonds vorteilhaftesten Eigenschaften, die Pogrammierbarkeit unter Verwendung von Funktionen, die solche Varablen verarbeiten könnten, schlichtweg nicht genutzt werden kann.

Unter diesen Voraussetzungen mußt Du in der Tat alles jedesmal wieder neu kopieren/erschaffen.
Und Du hast völlig recht, das "ist nunmal grober Unfug".

Ich verweise nochmal auf

Zitat von: https://lilypondforum.de/index.php/topic,285.msg1820.html#msg1820
[...]
Aber es scheint, daß Dein Wollen und LilyPonds Möglichkeiten nicht zusammenfinden.
Da sehe ich nur ein paar Möglichkeiten:
Ändere Deine Vorstellung wie Du Deinen Plan ausführen willst.
Oder ändere LilyPond (s.o. patches are ...)
Vielleichtgibt es ja auch bereits etwas, an das niemand hier bislang dachte.
Oder jemand entwickelt etwas (s.o. patches ...)
[...]

Du könntest auch auf der internationalen mailing-list nachfragen, da gibt es zumindest mehr Teilnehmer. Vielleicht kennt sich da jemand mit genau diesem Thema besser aus.


-Harm

Hallo Einzigartiger,

ZitatWenn 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?

ZitatWenn 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

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:


#define myVariable "a3"

\paper { myVariable }


Oder


#define myVariable

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


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


#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.

Zitat von: unique75m am Samstag, 19. Mai 2018, 10:33

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.

Hallo,

Zitatunique75m: 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

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:

Zitat von: unique
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.

#(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.

Zitat von: uniqueIch 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

Hallo,

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

im alten Forum (https://archiv.lilypondforum.de/index.php/topic,2213.0.html) ist zu finden, wie man LilyPond-Variablennamen mit Hilfe von Schema zusammensetzen kann:
\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

Hallo ingmar,

so?


\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

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...


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.


#(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.

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:



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.

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

Lieber Hilflos-im-Code,


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.

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

Zitat... 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

Zitat von: ingmar am Sonntag, 20. Mai 2018, 11:24

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.

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

Fokus: Nicht unbedingt. Book und Orchestermaterial widersprechen sich.

So nun habe ich mal Harms Beispiele getestet. Folgendes habe ich dabei festgestellt:


\version "2.18.2"

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

#(define var1 "visible")
#(define var2 "visible")

% Ich habe hier mal statt dem $ ein # probiert, damit funktioniert es nicht. Was ist der Unterschied zwischen $ und # ??
#(if-equal var1 var2
#{ a' b' c'' #}
#{ d'' e'' f'' #})


Das `und die Kommas innerhalb des Makros scheint wohl irgendein definierter Standard zu sein, mit Komma wählt man dann wohl einen Parameter.

Dann habe ich weiter probiert und eine zweites Makro if-visible abgeleitet und dafür die if-equal Funktion verwendet. Auch das scheint zu klappen. Mit normalen Schema-Funktionen ging das nämlich nicht wegen dem if-Befehl, weil es da keine lazy-evalution gibt. Bei den Makros scheint das doch eher wie Textersetzung zu funktionieren. D.h. damit lassen sich dann auch mal Makros in Makros schachteln und somit komplexere bedingte Ausdrücke formulieren, ohne das man jedesmal wieder mit einem if anfängt.


\version "2.18.2"

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

#(define-macro
(if-visible a x y)
`(if-equal ,a "visible" ,x ,y))

#(define var1 "visible")
#(define var2 "invisible")

$(if-visible var1
#{ a' b' c'' #}
#{ d'' e'' f'' #})

$(if-visible var2
#{ a' b' c'' #}
#{ d'' e'' f'' #})


Nun habe ich noch ein weiteres Makro gebaut, was auf dem if-visible aufbaut und keinen else-Zweig mehr benötigt. Der wäre in meinen Fällen eh meist leer. Dies hat bei mir auch geklappt.


\version "2.18.2"

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

#(define-macro
(if-visible a x y)
`(if-equal ,a "visible" ,x ,y))

#(define-macro
(if-visible-noelse a x)
`(if-visible ,a ,x #{#}))

#(define var1 "visible")
#(define var2 "invisible")

$(if-visible-noelse var1
#{ a' b' c'' #})

$(if-visible-noelse var2
#{ a' b' c'' #})


Als nächstes bin ich dann mal ganz mutig geworden und wollte den Mix von Makros und Funktionen erreichen, damit ich mittels der Funktion dann normalen Lilypond-Syntax schreiben kann. Dies klappt aber leider nicht.


\version "2.18.2"

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

#(define-macro
(if-visible a x y)
`(if-equal ,a "visible" ,x ,y))

#(define-macro
(if-visible-noelse a x)
`(if-visible ,a ,x #{#}))

#(define
(if-visible-noelse-func a x)
(if-visible-noelse a x))

var1 = "visible"
var2 = "invisible"

\if-visible-noelse-func \var1
{ a' b' c'' }

\if-visible-noelse-func \var2
{ a' b' c'' }


Als nächstes habe ich dann mal probiert, ob die Makros auch außerhalb von Score funktionieren. Ich habe auch gleich mal bookpart drum herum gebaut. Die Makros scheinen zu funktionieren. Damit kann ich dann mit den Makros auch einzelne Scores abschalten.


\version "2.18.2"

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

#(define-macro
(if-visible a x y)
`(if-equal ,a "visible" ,x ,y))

#(define-macro
(if-visible-noelse a x)
`(if-visible ,a ,x #{#}))

#(define var1 "visible")
#(define var2 "visible")

$(if-visible-noelse var1
#{
\bookpart
{
\score
{
\new Staff
{
\new Voice
{
a' b' c''
}
}
}
}
#})

$(if-visible-noelse var2
#{
\bookpart
{
\score
{
\new Staff
{
\new Voice
{
d'' e'' f''
}
}
}
}
#})


Der klitzekleine Wermutstropfen ist natürlich, dass man es nicht als normale Lilypond-Syntax schreiben kann und ein paar Klammern mehr hat. Aber ich denke damit kann ich leben  :)

Vielen Dank übrigens für die anderen Tipps bezüglich bookpart, so wird jedes Lied gleich auf einer neuen Seite angefangen. Ich denke ich werde mit den nun gewonnenen Ideen mal eins der größeren Heftchen/Bücher umsetzen. Mal sehen was da dann alles noch so für Probleme entstehen bei den Details wie Noten, Verzierungen, usw. Aber prinzipiell hat man jetzt erstmal eine vernünftige Basis, um redundanten Code zu vermeiden.

Das hier klappt leider auch nicht mit den Makros. Irgendwie mag er nicht den \paper Block in einem Makro.


$(if-visible "visible" #{
\paper
{
(set-paper-size "a3landscape")
print-all-headers = ##t
ragged-right = ##f
} #})


Oder sowas wie den komplette \layout Block kann man auch nicht einkapseln:


$(if-visible "visible" #{
          \layout
{
\context
{
\Score
\remove "Bar_number_engraver"
}

\context
{
\Staff
\consists "Bar_number_engraver"
}

\override Score.BarNumber.break-visibility = #end-of-line-invisible
\set Score.barNumberVisibility = #(every-nth-bar-number-visible 2)
}
#})
   

Außerdem verstehe ich es nicht, wieso man mehrere \bookparts nicht in einem \book einkapseln kann. Sobald man das tut funktionieren die Makros ebenfalls wieder nicht, wenn man dann die \bookparts per if-visible einkapselt. Ohne \book gehts. Dann stehen aber \header und \paper völlig verloren da.

Hallo unique,

nur ganz kurz.
In den beiden Beispielen mit \paper und \layout stimmt die Anzahl der Argumente nicht.
Dein if-visible verlangt drei Du gibst aber nur 2.
Außerdem fehlt im \paper Beispiel ein #-Zeichen vor (set-paper-size "a3landscape").
Hast Du die error-message im terminal übersehen?

Zitat von: terminalerror: GUILE signaled an error for the expression beginning here
$
(if-visible "visible" #{
Wrong number of arguments to #<procedure #f (a x y)>

Schau mal in die guile-1.8-Doku, ob defmacro* weiterhilft, das akzeptiert auch optionale Argumente.

Ich vermute mal ähnliches passiert mit den bookparts.

Gruß,
  Harm

Nochmals hallo,

hier eine mögliche Implementierung als LilyPond-Syntax. (Ist aber nur minimal getestet.)


\version "2.19.81"

#(define *unspecified* (if #f #f))

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

buzz =
#(define-scheme-function (strg1)(string?)
  (define-scheme-function (strg2 expr1 expr2) (string? scheme? scheme?)
    (if-equal strg1 strg2 expr1 expr2)))
 
barr =
  \buzz
    "visible"
    %"not visible"

\barr "visible"
  \paper {
    #(set-paper-size "a3landscape")
    print-all-headers = ##t
    ragged-right = ##f
  }
  #*unspecified*


\barr "visible"
  \layout {
    \context {
      \Score
      \remove "Bar_number_engraver"
      \override BarNumber.break-visibility = #end-of-line-invisible
      barNumberVisibility = #(every-nth-bar-number-visible 2)
    }
 
    \context {
      \Staff
      \consists "Bar_number_engraver"
    }
  }
  #*unspecified*
 
 
\repeat unfold 120 c'4


Allerdings ist 2.19.x zwingend erforderlich.
Ich würd' auch dringend zuraten 2.19. zu installieren, zumindest als Zweit-Version.

Im Code oben zeigt sich aber auch eine Schwäche.
Während es bei der reinen scheme-Version klar ist wo die Argument aufhören (schon der Klammern wegen), so muß in der LilyPond-Syntax der Fall für #f angegeben werden, obwohl man sie optional machen könnte. Anderenfalls wird der nächste Ausdruck, welcher auch immer das sein mag dafür gehalten. Alternativ könnte man wahrscheinlich die Prädikate der inneren scheme-funktion weniger allgemein fassen, beraubt sich damit aber natürlich der breiteren Anwendungsmöglichleiten.

Gruß,
  Harm

Zur Verwendung von \book:

Unter http://lilypond.org/doc/v2.18/Documentation/notation/multiple-scores-in-a-book steht:

ZitatEine wichtige Ausnahme stellen Dokumente dar, die mit lilypond-book erstellt werden, für die Sie explizit \book-Umgebungen notieren müssen, weil sonst nur die erste \score- bzw. \markup-Umgebung angezeigt wird.

lilypond-book ist zur Vorberteitung für Latex, aber wir wollen ja nichts für Latex vorbereiten.

Dann lese ich http://lilypond.org/doc/v2.18/Documentation/notation/multiple-output-files-from-one-input-file und frage mich, warum packt man vier verschiedene Stücke in eine Datei, um dann mit einem Befehl zu erreichen, dass jedes in einem eigenen PDF landet.

ZitatHilflos: ...und frage mich, warum packt man vier verschiedene Stücke in eine Datei, um dann mit einem Befehl zu erreichen, dass jedes in einem eigenen PDF landet.

Na, wenn du zum Beispiel 99 Orchesterstimmen anfertigen willst, die alle einfach nur ein paar Variable in einen Score packen. Dann hätte ich persönlich statt 99 superkleinen *.ly- Files lieber nur ein einziges, und würde die Ergebnisse auch lieber in einen getrennten Folder schreiben lassen.

Hier geht es möglicherweise um Einzelsätze, und der Anforderer möchte nicht einen ungefähr gleichen Code in vier verschiedenen Files stehen haben.

--ingmar

Zitat von: ingmar am Montag, 21. Mai 2018, 07:43
Hier geht es möglicherweise um Einzelsätze, und der Anforderer möchte nicht einen ungefähr gleichen Code in vier verschiedenen Files stehen haben.

--ingmar

Also Du suchst eine Lösung für etwas, wo die dir die Endanforderung nicht klar ist.

Die Endanforderung ist, wie weiter oben steht.

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.

Die Frage nach EInzelstimmenauszug wurde bisher nicht beantwortet. Wobei ich dann die austomatisierten Namensgebung der End-PDFs nicht sehr hilfreich für die später Verwendung finde. Und schon  gar nicht bei deinen fiktiven 99 Einzelstimmen eines Orchesters. Denn man druckt dann z.B. viermal die erste Geige aus, aber nur einmal die Flöte. Bei Dateinamen wie
 

• 'eightminiatures.pdf',
• 'eightminiatures-1.pdf'
• 'eightminiatures-2.pdf'.

stelle ich mir das nicht sehr praktisch vor.

Wobei das Orchester mit 99 Einzelstimmen, nicht  Einzelmusiker möchte ich sehen und ganz besonders im Musikschulbereich.

?

Lieber Harm,

ja da hast du natürlich Recht mit der Anzahl der Argumente in meinen Beispielen. Ich bin mir da gerade selbst nicht mehr sicher, ob ich nicht schon die Makros umgebaut hatte namentlich, was natürlich angesichts der vorausgehenden Beispiele für alle Anwesenden hier verwirrend ist. Ich entschuldige mich dafür :-)

Ich habe also gleich nochmal die alten Makros kopiert und eine Testdatei zusammengestellt mit folgendem Inhalt. Die relevanten Stellen sind auskommentiert, sodaß es in dieser Form fehlerfrei kompiliert. Sobald man die Kommentarzeichen entfernt, gibt es den Fehler, dass er einen unexpected \header hat.


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

#(define-macro
(if-visible a x y)
`(if-equal ,a "visible" ,x ,y))

#(define-macro
(if-visible-noelse a x)
`(if-visible ,a ,x #{#}))

\version "2.18.2"

\paper
{
#(set-paper-size "a3landscape")
print-all-headers = ##t
ragged-right = ##f
}

myvar = "visible"

\bookpart
{
\score
{
% $(if-visible-noelse myvar
% #{
\header
{
dedication = ""
    title = "Test"
    subtitle = ""
subsubtitle = ""
instrument = ""
poet = ""
composer = ""
meter = ""
arranger = ""
tagline = ""
copyright = ""
piece = ""
opus = ""
}
% #})

\new Staff
{
\new Voice
{
a' b' c''
}
}
}
}


Deine Lösung für 2.19.x habe ich syntaktisch noch nicht ganz erfasst, aber auf den 1. Blick sieht es so aus, als würde man eine Funktion bauen, die eine Funktion zurückgibt, wo der Parameter der 1. Funktion in die 2. Funktion hinein kompiliert wird. Erinnert mich stark an BlockClosures, die BlockClosures zurückgeben deren innere Parameter von außen hineingeschleust werden, sowas ähnliches habe ich schon in Smalltalk gemacht. Deine Folgebeispiele mit \buzz und \barr verstehe ich so, dass ich jetzt in meinen Edition-Dateien statt:

    scoreA = "visible"

nun für die Deklaration derselben Variablen schreibe:

    scoreA = \buzz "visible"

Und dann habe ich ein neues Lilypond-Kommando scoreA, dem ich den Vergleichstring und 2 musikalische Blöcke als Parameter schicke

    \scoreA "visible" xxx yyyy

Wenn ich diese Vorgehensweise mit der Funktion-in-Funktion nun kombiniere mit dem if-equal-else Makro, anstatt if-equal, dann bräuchte ich ja keinen Parameter yyyy mehr und somit auch nicht das unspecified. Muss ich mal demnächst testen :-)

Was konkret ist daran jetzt nur 2.19.x kompatibel? Diese Sache mit dem Zurückgeben der Funktion aus einer Funktion, also die Definition von buzz?

Wenn das alles funktioniert wie gedacht, dass ist es natürlich eine deutlich schönere und kürzere Schreibweise, anstatt diese ständigen Wechsel zwischen Lillypond und Scheme und den zig Klammern. Man wird hier ganz beklammert :-)

Lieber Ingmar,

wenn Du 99 Orchesterstimmen hast, dann hat man doch meiner Meinung nach noch mehr diese Probleme, die ich geschildert habe. Man schreibt doch dann einmal eine Struktur für die gesamte Partitur mit 99 Stimmen. Natürlich kann man dann Dinge wie Texte, Instrumentnamen oder Noten per Variablen herausziehen, damit diese nur einmalig definiert werden.

Wenn aber nun ein Musiker schreit, der eben nicht die Gesamtpartitur haben will, sondern nur seine Einzelstimme, dann fange ich doch jetzt eigentlich an einen Teil der Gesamtstruktur herauszukopieren und nochmals irgendwo in einem zweiten \book oder \bookpart abzulegen. Da ich in dem Fall lieber pessimistisch bin, gehe ich davon aus, dass alle 99 Musiker schreien und jeder seine eigene Stimme einzeln will. Das heißt dann habe ich also 99 mal redundanten Strukturcode. Wenn man dann ein halbes Jahr später irgendeinen Fehler entdeckt im Strukturcode und mit einer Änderung beheben will, dann muss ich diese Änderung ja auf einmal an 99 + 1 (Gesamtpartitur-Struktur) Strukturen nachziehen. Deswegen macht es Sinn solche Redundanzen erst garnicht zuzulassen.

Ob ich die 99 + 1 nun in einzelne Dateien ablege oder zusammen in eine große spielt dabei eigentlich keine Rolle, es bleibt redundant. Für mich persönlich sind dann solche großen Dateien, auch angesichts der vielen Klammern bei Lilypond und Scheme, dann nicht mehr wartbar. Ich stelle mir gerade vor wie ich in einer Riesendatei mit 99 Stimmen Strukturcode dann die Stimme 67 finde und hoffe dass ich da ja die richtige Klammerung erwischt habe.

Wenn ich jetzt große Dateien nicht so schrecklich unübersichtlich finden würde, könnte ich natürlich auch alles in eine Datei legen und dort ebenfalls per ConditionalCompiling bestimmte Pfade ausschließen.

Zitat von: unique
Sobald man die Kommentarzeichen entfernt, gibt es den Fehler, dass er einen unexpected \header hat.

<code-Beispiel>

Das kann ich für 2.18.2 bestätigen in 2.19.81 gehts problemlos.

Zitat von: unique
Deine Lösung für 2.19.x habe ich syntaktisch noch nicht ganz erfasst,
[...]
Muss ich mal demnächst testen :-)

Ich bin mir nicht ganz sicher, ob Deine Beschreibungen korrekt sind, da bräuchte ich den Code, wie genau Du es umgesetzt/angewendet hast.

Allerdings:

Zitat von: uniqueWas konkret ist daran jetzt nur 2.19.x kompatibel? Diese Sache mit dem Zurückgeben der Funktion aus einer Funktion, also die Definition von buzz?

Das Zurückgeben einer Funktion aus einer Funktion hat früher schon geklappt.
Ich kann dir nur berichten, daß mein obiges Beispiel mit 2.18.2 einen error erzeugt:

Zitat von: terminalerror: bad expression type

\barr "visible"

Und der Code ansonsten keine Wirkung zeigt.
Leider kann ich Dir nicht genau sagen woran es in 2.18.2 hapert.
Seitdem ist seeeehr viel passiert. Dunkel erinnere ich mich an Änderungen im parser/lexer was erlaubt ist (oder auch nicht).
Insbesondere in #{ ... #}

Wie schon gesagt, ich würde 2.19. installieren. Es ist soooo viel besser. Auch sind parallel-Installationen kein Problem. Anleitungen finden sich auch hier im Forum oder in der Doku. Oder frag einfach danach.
Ich schreib jetzt nicht wie ich das mache, weil meine Methode etwas umständlich ist. Ich komm aber gut damit klar und bin zu faul das setup zu ändern ;)
aber ich hab diverse Versionen auf dem Rechner:
2.21.0 mit guile-2.2.3
2.21.0 mit guile-1.8
2.19.81
2.18.2
2.16.2
2.14.2
2.12.3

Die ersten beiden selbst kompiliert aus dem git-repository. Die älteren sind vor allem für bug-recherchen nützlich. Diese Versionen sind nicht mehr aus dem repository kompilierbar. Dazu bräuchte man ältere Versionen von (vor allem) gcc und anderen Programmen.
Falls es doch nötig wird, so fahre ich eine der alten LilyDev in einer VB hoch ...

Aber ich schweife ab :)

Gruß,
  Harm

Zitat von: unique75m am Montag, 21. Mai 2018, 19:06

Wenn aber nun ein Musiker schreit, der eben nicht die Gesamtpartitur haben will, sondern nur seine Einzelstimme, dann fange ich doch jetzt eigentlich an einen Teil der Gesamtstruktur herauszukopieren und nochmals irgendwo in einem zweiten \book oder \bookpart abzulegen. Da ich in dem Fall lieber pessimistisch bin, gehe ich davon aus, dass alle 99 Musiker schreien und ...

Die Realität sieht, wenn die Partitur größer als zwei oder drei Seiten hat, anders aus. Die Musiker bekommen Einzelstimmen, wenn Sie wollen bekommen sie eine Partitur in handlichem Format. Also das Anfertigen von Einzelstimmen ist der Normalmalfall.

In den normalen Notensatzprogrammen sieht das so aus. Du schreibst die Partitur und ziehst via Automatismus die Einzelstimmen heraus.

In Lilypond schreibst Du die Einzelstimmen und klebst sie dann zusammen. Siehe als Beispiel http://www.mutopiaproject.org/cgibin/make-table.cgi?searchingfor=Divertimento+in+Bb+Major+mozart . Das dürfte deinem Endprodukt vermutlich in gewisserweise entsprechen. Der Weg dahin weniger.

Bloß als Musikschullehrer würde ich so etwas nicht machen wollen. Wenn ich für eine Kammermusikgruppe etwas einrichte, will/muss ich die Partitur vor mir haben.