Verschiedene Editionen mit denselben Dateien

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

« vorheriges - nächstes »

harm6

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

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


Gruß,
  Harm

harm6

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

Hilflos-im-Code

#17

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

Arnold

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

unique75m

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.

harm6

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.

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.

\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



harm6

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

Hilflos-im-Code

#22
Ü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.)

Hilflos-im-Code

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

harm6

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

unique75m

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.

harm6

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

Hilflos-im-Code

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.

unique75m

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.

harm6

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 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
Vielleicht ist `make' noch was:
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