\include im includierten File feststellen (GELÖST)

[ingmar]

hallo,

ich möchte per \include ein File QUELLE in ein anderes File PARTITUR einbinden. QUELLE enthält im Prinzip die Noten, PARTITUR kümmert sich um deren Darstellung. Es gibt nun Details, die ich nicht in PARTITUR schreiben kann, da sie bei jeder einzelnen Note stehen müssen (Beispiel: Fingersätze, und ich will eine Partitur mit, eine andere ohne Fingersätze erzeugen können). Daher möchte ich in PARTITUR eine Variable setzten, die anschließend in QUELLE ausgewertet wird.

Problem: Wenn ich QUELLE kompiliere, ist diese Variable natürlich undefiniert. Das ist schlecht, denn so kann ich bei Änderungen nicht so ohne weiteres die syntaktische Richtigkeit von QUELLE prüfen. Also möchte ich diese Variable gegebenenfalls mit einem Defaultwert setzen.

Dazu müsste ich innerhalb von QUELLE prüfen können,
* ob die Variable existiert
* oder ob das File über \include eingebunden wurde.

Gibt es da eine schlichte Möglichkeit?

Ich kann keinen lauffähigen Code liefern, aber vielleicht reicht das Folgende:
 

Code: [Auswählen]

===PARTITUR.ly===
\version "2.18.2"
condition = "irgendwas"
\include QUELLE.ly
...

===QUELLE.ly===
\version "2.18.2"
\relative { c d e f
#(if condition ; ...und condition ist eben nicht gesetzt, wenn QUELLE selbst kompiliert wird.
#{ RESULT = \relative {c d e f } #}
#{ RESULT = \relative { g a b2 } #})
}

Ich hatte es mal mit #(if defined? \condition) versucht, aber auch da gibts vom Compiler nur die Klage, \condition sei "unbound", also nicht bekannt..

tja. Gibt bestimmt ne ganz simple Lösung...? : - )
--ingmar

[harm6]

Hallo Ingmar,

sieht nach einem Syntax-Problem aus.

Hilft

Code: [Auswählen]

\version "2.18.2"

%% Try comment/uncomment:
%condition = "irgendwas"

\relative {
  c d e f
  #(if (defined? 'condition)
    #{ c d e f #}
    #{ cis dis eis fis #})
}
?


Gruß,
  Harm

[ingmar]

Danke. Ja - das hilft.

Aber im Versuch, minimal zu sein, zeigte mein Beispiel nicht alles. Ich muss eine Variable setzen.

Code: [Auswählen]

\version "2.18.2"

% Try comment/uncomment:
ST = "irgendwas"

#(if (defined? 'ST)
    #{    #}
    #{ ST = "was anderes" #})

\relative {
  c d e f
g^\ST a b c
}
..aber das funktioniert leider nicht, wenn oben einkommentiert wird; der Compiler erwartet offenbar an dieser Stelle keine Variablendefinition.

Eleganter fände ich übrigens auch folgendes - weiß nicht, ob das so geht:

Code: [Auswählen]

\version "2.18.2"

% Try comment/uncomment:
 ST = "irgendwas"


  #(unless (defined? 'ST)
    #{ ST = "was anderes" #})


\relative {
  c d e f
  g^\ST a b c
}

Danke im Voraus... : - )
--ingmar

[harm6]

Dein Beispiel läßt sich so umsetzen

Code: [Auswählen]

\version "2.18.2"

% Try comment/uncomment:
ST = "irgendwas"

#(if (defined? 'ST)
     ST
     (define ST "was anderes" ))

\relative {
  c d e f
g^\ST a b c
}


oder so

Code: [Auswählen]

\version "2.18.2"

% Try comment/uncomment:
ST = "irgendwas"

#(define ST
  (if (defined? 'ST)
      ST
      "was anderes"))
     
\relative {
  c d e f
g^\ST a b c
}

HTH,
  Harm

[ingmar]

Hallo,

die zweite Lösung kann ich nachvollziehen, bei der ersten hab ich Schwierigkeiten:
#(if (defined? 'ST)
     ST
     (define ST "was anderes" ))

Wir prüfen, ob ST definiert ist. Ist es das nicht, definieren wir es als "was anderes". Ist es aber definiert - tja, dann müssten wir doch eigentlich gar nichts tun! Was macht die Zeile "ST" in diesem Fall? *kopfschüttel*

Gruß,
--ingmar

[harm6]

#(if (defined? 'ST)
     ST
     (define ST "was anderes" ))

Wir prüfen, ob ST definiert ist. Ist es das nicht, definieren wir es als "was anderes". Ist es aber definiert - tja, dann müssten wir doch eigentlich gar nichts tun!

Absolut richtig.

Was macht die Zeile "ST" in diesem Fall? *kopfschüttel*

Nichts sinnvolles.

Insoweit:

Code: [Auswählen]

\version "2.18.2"

% Try comment/uncomment:
%ST = "irgendwas"

#(if (not (defined? 'ST))
     (define ST "was anderes" ))

     
\relative {
  c d e f
g^\ST a b c
}

Falls 'ST' definiert ist gibts als Ausgabe "unspecified",

guile> (define ST "irgendwas")
guile> (display (if (not (defined? 'ST))
     (define ST "was anderes" )))
#<unspecified>

was hier völlig unproblematisch ist.

Insoweit war mein Vorschlag durchaus verbesserungswürdig !


Gruß,
  Harm

[ingmar]

...dann ist also Guile/Scheme am Ende doch etwas, was der menschliche Geist, genügend Training vorausgesetzt, auch ohne Bezug zur Esoterik kapieren kann! Für mich ein Grund, nicht aufzugeben...

Gruß,
--ingmar

[harm6]

...dann ist also Guile/Scheme am Ende doch etwas, was der menschliche Geist, genügend Training vorausgesetzt, auch ohne Bezug zur Esoterik kapieren kann!

Ehrlich gesagt habe ich keine Ahnung, warum scheme von vielen so betrachtet wird, gerade von Leuten mit Erfahrung in anderen Programmiersprachen...

Für mich ein Grund, nicht aufzugeben...

Grüße,
  Harm

[mgd]

    ...dann ist also Guile/Scheme am Ende doch etwas, was der menschliche Geist, genügend Training vorausgesetzt, auch ohne Bezug zur Esoterik kapieren kann!

Ehrlich gesagt habe ich keine Ahnung, warum scheme von vielen so betrachtet wird, gerade von Leuten mit Erfahrung in anderen Programmiersprachen...

Ich versuche mich mal an einer Erklärung. Es gibt m.E. mehrere Gründe (gibt es ja eigentlich immer )

• funktionale und prozedurale Programmiersprachen haben von der Strukturierung der Algorithmen her deutliche Unterschiede. Die meisten Leute haben Erfahrung mit prozeduralen Programmiersprachen und LISP et al gehören den funktionalen Sprachen an.
• die verfügbare Dokumentation ist IMO schlecht. Wenn sie überhaupt existiert, dann ist sie meist extrem knapp gehalten. Das mag für jmd reichen, der i.P. weiß, wie es geht. Für Neulinge ist es sehr mühsam und mit viel Frustration verbunden. Eine Stelle, an der mir das besonders deutlich auffällt, sind die Beispiele in der guile Dokumentation. Wenn es überhaupt welche gibt, dann sind sie überwiegend trivialer Art. Da hat eine Funktion 1 obligatorischen und 3 optionale Parameter. Das Beispiel zeigt garantiert "nur" den Fall mit einem Parameter.
  
• Scheme Codefragmente die ich aufstöbere sind nur selten gut dokumentiert. Das mag daran liegen, dass dem Autor die Dinge glasklar und offensichtlich sind. Für den Neuling sind viele subtile Kleinigkeiten unverständlich.
• viele Lilypond Codesnippets sind für meinen Geschmack zu knapp kommentiert. Das mag daran liegen, dass dem Autor ...(siehe vorherigen Punkt). Das hinterläßt Unbehagen [nicht direkt Scheme aber IMO verwandt]

Um ja nicht falsch verstanden zu werden:
Das ist nicht als Bashing gemeint. Ich bin sehr angetan von der durchgängigen Freundlichkeit und Hilfsbereitschaft in der Lilypond Community (jedenfalls soweit ich sie bisher habe kennenlernen können). Obige Punkte sind einfach die Stellen, an denen ich selbst mich abgearbeitet habe. Ich gehöre zu den Leuten mit Erfahrung in anderen Programmiersprachen (incl. ein wenig elisp).

Liebe Grüße,
Michael

[ingmar]

Ich versuche mich mal an einer Erklärung.

ich würde aber doch vorschlagen, dafür einen eignen Thread aufzumachen - so findet das irgendwann niemand mehr! : - )

--ingmar

[ingmar]

Schade, dass die Diskussion über Scheme und wie man dahintersteigt nicht weiterging..

..unabhängig davon:

ich hab ein Problem, wenn die Variable nicht einfach ein String ist. Im folgenden Beispiel soll sie Markup-Code sein; ähnlich ist denkbar, dass es sich um eine Folge von Noten handelt:

Code: [Auswählen]

\version "2.18.2"

DEFAULT-MARKUP = \markup \with-color #(x11-color 'grey45) {
\fontsize #1
\override #'(font-name . "Courier" )
\bold
"Überschrift"
}

#(if (not (defined? 'TITLE ))
     ( #{ TITLE = \DEFAULT-MARKUP #} ))

\TITLE


Der Compiler beschwert sich, weil ich in der Scheme-Passage ein Gleichheitszeichen verwende; nach meinem Verständnis kann ich aber doch per #{ ... #} LilyPond-Code einbinden, oder?

Gruß, danke,
--ingmar

[fugenkomponist]

Der Compiler beschwert sich, weil ich in der Scheme-Passage ein Gleichheitszeichen verwende; nach meinem Verständnis kann ich aber doch per #{ ... #} LilyPond-Code einbinden, oder?

Ich bin mir nicht 100% sicher, aber: Nein, nicht beliebigen LilyPond-Code. Sondern Musik-Ausdrücke. „c“ ist einer. „{ c }“ ist einer „<< \new Staff { c } \new Staff { d e } >>“ ist einer. Die rechte Seite einer Zuweisung ist einer. Aber die Zuweisung selbst nicht.

Du kannst das ganze aber einfach direkt in Scheme machen:

Code: [Auswählen]

#(if (not (defined? 'TITLE ))
     (define TITLE DEFAULT-MARKUP))


[ingmar]

Du kannst das ganze aber einfach direkt in Scheme machen:

Code: [Auswählen]

#(if (not (defined? 'TITLE ))
     (define TITLE DEFAULT-MARKUP))


Ja, so funktioniert's - danke!

--ingmar