Deutsches Lilypond Forum (Archiv)
Betriebssystemabhängig => Mac OS X => Thema gestartet von: juppes am Freitag, 23. April 2010, 01:23
-
ich habe seit langer Zeit wieder einmal mein Lilypond angeworfen, weil ich eigentlich nur ein einfaches einstimmiges Stück transponieren wollte. Ich muß aber leider feststellen, daß mein Lilypond bockig ist. Ich habe im Programme-Ordner (Applications) verschiedene Lilypond-Versionen (2.10.33/2.12.2/2.12.3/2.13.4) liegen, aber welche ich auch nehme, alle produzieren eine Fehlermeldung, die im wesentlichen besagt: resource unavailable. Das bekomme ich auch wenn ich lilypond im Terminal ausführe.
Kann mir einer sagen, was da los ist?
was ich in der Lilypond-Konsole nach dem Befehl Cmd-R zu sehen bekomme, sieht zum Beispiel so aus:
>>/Users/ich/Desktop/Untitled.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>Untitled.ps<< ausgeben...
Konvertierung nach >>./Untitled.pdf<<.../Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: In procedure system in expression (system silenced):
/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: Resource temporarily unavailable
Wenn ich Lilypond mit der berühmten Datei "A Scale in Lilypond" öffne, funktioniert die Umwandlung in ein PDF ohne Probleme.
-
Hallo juppes,
wie lange ist denn „seit langer Zeit“ bzw. für welche Lily-Version ist deine .ly-Datei geschrieben? In dieser muss irgendetwas notiert sein, das irgendetwas an /dev/null schickt (entsprechender Block in backend-library.scm).
Offenbar bricht Lily erst während der PS→PDF-Konvertierung ab – d.h., dass im besten Falle eine brauchbare PS-Datei bereits erzeugt wurde, die auf anderem Weg nach PDF konvertiert werden könnte. Was sagt denn die Mac-Preview dazu?
Immerhin wird angesichts deiner „Versionsvielfalt“ auf Lily 2.12.3 zurückgegriffen. Du kannst deine Datei gern hier posten oder mir privat schicken, um sie zu prüfen. Vermutlich ist es nur ein Syntaxproblem. Wäre auch prima, wenn du deine Mac OS X-Version mit angibst.
Grüße, Robert
-
hallo Robert,
danke für Deine Fragen, die ich gerne beantworte:
"Seit langer Zeit" heißt in diesem Fall ein paar Monate.
Ich habe tatsächlich eine .ps-Datei gefunden, die sich z.B. per Vorschau in ein PDF verwandeln ließ.
Versionsvielfalt: Ich habe die älteren Versionen nur aufbewahrt, damit ich mit älteren Versionen erstellte Dokumente bei Bedarf damit öffnen kann. Ich will nicht immer mit convert-ly arbeiten müssen. Mein Mac OS hat beschlossen, alle *.ly-Dateien immer mit Lilypond 2.13.4 zu öffnen (kann ich ändern, weiß ich natürlich). Ich öffne sie aber mit Lilypond 2.12.3, weil nur da der Befehl cmd-R einigermaßen funktioniert. Wiederhole ich den aber öfters, fangen bald Fehlermeldungen an zu kommen in der Art wie beschrieben. Sie verschwinden wieder, wenn ich das PDF-Programm (in meinem Fall Skim) und Lilypond neu starte. Das ist aber begreiflicherweise umständlich.
Ich habe meinen ganzen Lilypond-Kram (aber nicht die Lilypond-Dokumente; die liegen in einem Unterordner meines Benutzerverzeichnisses) in einem Unterordner in "Applications" liegen. Könnte das eventuell unter der Haube für Verwirrung sorgen? Die Lilypond-Version 2.13.4 weigert sich übrigens komplett, den Befehl Cmd-R anzunehmen. Ich bekomme dann immer nur die Fehlermeldung, die ich hier als Screenshot anhänge:
Ach ja: ich arbeite mit Tiger 10.4.11.
-
Hallo juppes,
wir sollten uns auf eine Lily-Version konzentrieren, am besten die letzte stable 2.12.3. Deine ursprünglich gepostete Konsolenausgabe greift auf 2.12.3 zurück, wohingegen der Screenshot einen Fehler bei 2.13.4 zeigt (aktuelle devel ist übrigens 2.13.18).
Ich habe meinen ganzen Lilypond-Kram … in einem Unterordner in "Applications" liegen. Könnte das eventuell unter der Haube für Verwirrung sorgen?
Das kann ich mir gut vorstellen, aber bei guter Organisation sollte es keine Probleme geben. Ich habe auch mehrere Lily-Versionen „installiert“, aber davon liegt eine (die jeweils aktuelle stable) als „Masterversion“ unmittelbar in /Applications; die anderen liegen in ihrem eigenen Ordner unterhalb von /Applications. Zum Editieren benutze ich TeXShop (http://www.texshop.org/), dessen Engines man prima anpassen kann (durch verschiedene Engines kann ich gezielt andere Lily-Versionen ansprechen).
Welche Lily-Version springt denn auf der Konsole an? lilypond -v eingeben zum Überprüfen.
Beim Stöbern nach der Fehlermeldung mac oserror errno 8 exec format error (http://www.google.de/#hl=de&q=mac+oserror+errno+8+exec+format+error&meta=&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=ebbd8e4827c4c9bc) stößt man immer wieder auf den Hinweis, dass man die PPC/Intel-Versionen checken soll. Es könnte ja auch bei dir der Fall sein, dass du die falsche 2.13.4 hast.
Grüße, Robert
-
hallo Robert,
wenn ich im Terminal eingebe: lilypond -v, bekomme ich:
de-spiegelkast:~ ich$ lilypond -v
GNU LilyPond 2.12.2
2.13.4 könnte natürlich versehentlich eine Intel-Version sein, die ich mir da runtergeladen habe. Ich lösche sie einfach mal - sie funktioniert eh nicht.
2.12.3 funktioniert ja eigentlich, macht aber das, was ich Dir schon geschrieben habe.
Die Datei, die so komisch sich verhalten hat, besteht übrigens hartnäckig darauf, mit 2.13.4 geöffnet zu werden, auch wenn man das im Infofenster ändert.
Ansonsten: ich habe eigentlich auch eine TeXShop-Arbeitsumgebung, mit der ich am liebsten arbeite, weil auch ein PDF-Viewer gleich mit dabei ist, und weil man ihn konfigurieren kann.
Ich werde nach der Löschung von 2.13.4 mich noch einmal aus- und wieder einloggen und dann noch einmal eine kleine Versuchsreihe starten. Werde mich dann gleich wieder mit einem Testbericht melden.
herzlichen Gruß
-
hallo Robert,
habe meine Testreihe durchlaufen gelassen. Lilypond 2.12.3 scheint jetzt glatter zu laufen. Es bleibt aber eine Merkwürdigkeit: wenn man mehrere Male hintereinander an einer Datei etwas ändert, scheint das Programm zu "ermüden". Das ist nach ca. 6-7 Mal der Fall – ich kann das reproduzieren. Die ersten Male läuft alles nach Plan, und am Ende bekommt man Fehlermeldungen. Ich habe lediglich die erste Note im Stück wiederholte Male geändert. Hast Du eine Erklärung dafür?
Hier ist das vollständige Protokoll der Lilypond-Konsole (sorry, ist natürlich ein ziemlicher Sermon, aber am Ende wird es interessant):
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<...sh: fork: Resource temporarily unavailable
>>gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./GounodAve.pdf" -c .setpdfwrite -f "GounodAve.ps"<< gescheitert (32768)
Fehler: gescheiterte Dateien: "/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly"
>>/Users/ich/Documents/Notenabschriften/GounodAve/GounodAve.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16][24][32][40][48][56][64]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>GounodAve.ps<< ausgeben...
Konvertierung nach >>./GounodAve.pdf<<.../Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: In procedure system in expression (system silenced):
/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: Resource temporarily unavailable
-
Hallo juppes,
ich denke, die Durchläufe 1 bis 6 hättest du ruhig als „\repeat volta 6 { Konsolenausgabe }“ notieren können ;) Wir glauben dir, dass beim siebten Mal etwas anderes passiert!
Aber wieder zu dem, was bei diesem verflixten siebten Mal passiert: offensichtlich ein Problem in GhostScript (GS). Deine Datei wird zunächst in ein PS-File gerechnet, und dann streicht GS während der Konvertierung nach PDF die Segel. Die Frage ist nun, ob die zuletzt erzeugte PS-Datei bereits korrupt ist, oder ob die PS→PDF-Komponente in GhostScript den Dienst verweigert. Gleichermaßen fraglich ist, auf welchen GS-Unterbau genau zugegriffen wird: jeder Lilypond-AppContainer enthält eine mitgelieferte GS-Version. Zusätzlich kann eine andere, separate GS-Installation Verwirrung stiften. Für Python gilt das gleiche in grün. Jedenfalls ist deine Mini-Partitur fehlerfrei (lt. Screenshot); allenfalls könnte es noch Probleme mit dem PDF-Viewer (bei geöffneter/gesperrter Datei) oder auch Lilys point-and-click geben (letzteres mal probehalber deaktivieren).
Es ist schonmal gut, dass Lily 2.12.3 jetzt besser läuft, auch wenn sich auf der Konsole v2.12.2 angesprochen fühlt. Da solltest du die Pfadeinträge ändern – und bei dieser Gelegenheit auch gleich die Pfade zu GS und Python überprüfen. Ich hatte z.B. das Problem, dass für GS Pfade eingetragen waren, die auf nicht existente Ordner verwiesen. Das kann in der .profile in deinem Home-Verzeichnis korrigiert werden.
v2.12.3 läuft bei mir mit einer einzigen Ausnahme reibungslos und stabil: in einem von hundert (vielleicht auch von fünfhundert) Fällen wird eine minimale Änderung (z.B. ein einzelner Buchstabe) nicht im PDF angezeigt! Wenn ich dann einige Zeichen mehr ändere, anschließend übersetze und darauf zur vorigen Änderung wechsle, funktioniert es wieder. Es scheint, als ob GS kurz pausiert ohne abzustürzen. Allerdings brauche ich den Editor und das PDF nicht zu schließen; nach erneuten Durchläufen fängt es sich wieder. Klingt ein wenig nach deiner Beobachtung …
Das „Resource temporarily unavailable“-Problem betrifft wohl unixoide Betriebssysteme. Die (seltene) Macke ist bekannt, aber es gibt keine generelle Lösung. Ich selbst habe diese Fehlermeldung noch nie zu Gesicht bekommen. Dieser Fehler wird am häufigsten iVm Python und GhostScript erwähnt. Einfach mal bei Google die Fehlermeldung 1:1 eintippen, suchen und schmökern.
Ich habe es mir mit Lily im TeXShop recht gemütlich gemacht – incl. lilypond-book (mit nur einem Durchlauf) und TeXShop-Engines für unterschiedliche Lily-Versionen. Es kann so einfach sein! Wenn du mit Lily komfortabel im TeXShop arbeiten magst, kann ich dir gern helfen. Seit ich u.a. die Deklaration der Engines am Dateianfang (% !TEX TS-program = engine file) entdeckt habe, kann ich blind „Apfel-T“ betätigen, ohne irgendeine TS-Fehlermeldung zu bekommen – grandios!
Viel Erfolg beim Weiterforschen und beste Grüße,
Robert
-
hallo Robert,
Es ist schonmal gut, dass Lily 2.12.3 jetzt besser läuft, auch wenn sich auf der Konsole v2.12.2 angesprochen fühlt. Da solltest du die Pfadeinträge ändern – und bei dieser Gelegenheit auch gleich die Pfade zu GS und Python überprüfen.
Es sieht so aus, als ob Du der erfahrenere Terminal-Bediener bist. Um mir langes Herumprobieren zu ersparen, könntest Du so nett sein und mir kurz erklären, wie ich die Pfade ändere? Wenn ich Lilypond 2.12.3 nutze, dann nehme ich an, daß es sich um den Pfad "/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/bin/gs" (in meinem Fall) handelt. Richtig?
Was Python angeht, so hat eine Fahndung auf meinem Rechner drei Fundorte ergeben: einmal in "Applications", dann noch in "/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6" und in "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6". Zu welchem muß ich den Weg weisen durch Pfadangabe?
Habe auch noch folgende Entdeckung gemacht: wenn ich im Terminal eingebe: python -v, kriege ich folgende Rückmeldung:
python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site.pyc has bad mtime
import site # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/os.pyc has bad mtime
import os # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/os.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/os.pyc
import posix # builtin
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.pyc has bad mtime
import posixpath # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/stat.pyc has bad mtime
import stat # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/stat.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/stat.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/UserDict.pyc has bad mtime
import UserDict # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/UserDict.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/UserDict.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.pyc has bad mtime
import copy_reg # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/types.pyc has bad mtime
import types # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/types.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/types.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/warnings.pyc has bad mtime
import warnings # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/warnings.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/warnings.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/linecache.pyc has bad mtime
import linecache # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/linecache.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/linecache.pyc
import encodings # directory /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/__init__.pyc has bad mtime
import encodings # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/__init__.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/__init__.pyc
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/codecs.pyc has bad mtime
import codecs # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/codecs.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/codecs.pyc
import _codecs # builtin
# /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/utf_8.pyc has bad mtime
import encodings.utf_8 # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/utf_8.py
# can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/utf_8.pyc
Python 2.3.5 (#1, Jan 12 2009, 14:43:55)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1819)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Die Spotlight-Suche verweist aber nicht auf eine Python 2.6- und nicht auf eine Python 2.3-Installation. Und wenn ich unter den im Terminal angegebenen Pfaden suche, stoße ich auf 2.6. Was hat das zu bedeuten?
Und was heißt "has bad mtime"? Klingt nicht gut...
Ich hoffe, daß Du Licht in dieses Dunkel bringen kannst.
herzlichen Gruß
-
Hallo juppes,
zuerst würde ich Lily zuliebe Python 2.6.5 (http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg) und für alle Fälle Python 3.1.2 (http://www.python.org/ftp/python/3.1.2/python-3.1.2-macosx10.3-2010-03-24.dmg) installieren (das sind die jeweils aktuellen „Production Releases“). Nach der Installation dürften schonmal die Pfade zu Python stimmen. Achtung: um sich die Python-Versionsnummer anzeigen zu lassen, muss man python -V (großes „V“!) eingeben. Du hast lediglich die Python-Konsole gestartet und durch das kleine „v“ anzeigen lassen, was es beim Start so alles versucht zu importieren. Deswegen bleibt Python auch aktiv (angezeigt durch >>>) und muss durch quit() beendet werden. Trotzdem verrät die drittletzte Zeile die Versionsnummer – und die ist ein bisschen alt ;) Lily benötigt für convert-ly und lilypond-book mindestens Python 2.6. Ich würde zuerst die 3er-Version installieren und danach die 2.6er – aufpassen, dass du während der Installation auf „Anpassen“ klickst, um die erweiterten Installationsoptionen zu erreichen. Dort muss dann für beide Versionen „Shell profile updater“ und für 2.6.5 zusätzlich „Fix system Python“ angeklickt sein, um 2.6.5 als Standard-Python-Konsolenversion zu registrieren. Anschließend kannst du wieder mit python -V (mit großem „V“) überprüfen, dass es geklappt hat.
Welche Pfade überhaupt für dein Userprofil eingetragen sind, kannst du durch Eingabe von env ermitteln. In der Variable PATH findet sich neben den Pfaden zu den gerade installierten Python-Versionen auch der Pfad zu deiner LilyPond-Version, und zwar bis zum /bin-Ordner. Dort dürfte der Pfad zu Lily 2.12.2 auftauchen. Diesen änderst du nun in der .profile-Datei in deinem Home-Verzeichnis in den Pfad zu Lily 2.12.3:
- Terminal starten
- falls du nicht bereits im Home-Verzeichnis bist, per cd (ohne weitere Eingaben) dorthin wechseln
- mit einem Editor die .profile-Datei öffnen: pico .profile
- die Pfadangabe zu Lily suchen und entsprechend ändern
- Editor (pico/nano) per ctrl-X beenden, die Speicherabfrage mit „Y“ beantworten und Dateinamen mit Enter bestätigen
Spätestens nach erneutem Einloggen dürften die Pfade geändert sein. Einfach mit env oder lilypond -v bzw. python -V überprüfen.
Schau erstmal, wie es jetzt funktioniert. Nächstes Mal können wir dann GhostScript checken.
Grüße, Robert
-
hallo Robert,
danke für die ausführliche Anleitung! Ich werde mich in ein paar Tagen an die Arbeit machen. Ich habe schon die neuen Python-Versionen heruntergeladen. Was rätst Du mir: Installation über das Terminal oder einfach Doppelklick auf das im .dmg befindliche Installationsprogramm?
Und dann hat mich eines doch überrascht: ich glaubte, Python 2.6 bereits installiert zu haben, und eine Spotlight-Suche brachte ja auch Treffer diesbezüglich.
Wenn ich aber im Terminal python -V eingebe, kriege ich zurück: Python 2.3.5. Hab ich 2.6 nicht richtig installiert? Ich habe damals bestimmt nicht das Terminal benutzt, aber ein Installationsprogramm sollte doch wissen, wo die zum Programm gehörigen Dateien hin müssen oder?
env lilypond ergibt übrigens tatsächlich, daß ein Pfad zu Lilypond 2.12.2 eingetragen ist. Muß man den Pfad eigentlich bei jedem Lilypond-Update, wenn man die neue Version anstelle des Vorgängers benutzen will, selber ändern? Ich habe hier den Eindruck, daß dem so ist.
-
Was rätst Du mir: Installation über das Terminal oder einfach Doppelklick auf das im .dmg befindliche Installationsprogramm?
Ganz normal doppelklicken und ab die Post.
Hab ich 2.6 nicht richtig installiert? Ich habe damals bestimmt nicht das Terminal benutzt, aber ein Installationsprogramm sollte doch wissen, wo die zum Programm gehörigen Dateien hin müssen oder?
Doch, kann schon installiert sein; es ist nur der Pfad nicht eingetragen worden. Deswegen mein Hinweis
… aufpassen, dass du während der Installation auf „Anpassen“ klickst, um die erweiterten Installationsoptionen zu erreichen. Dort muss dann für beide Versionen „Shell profile updater“ und für 2.6.5 zusätzlich „Fix system Python“ angeklickt sein, um 2.6.5 als Standard-Python-Konsolenversion zu registrieren.
Muß man den Pfad eigentlich bei jedem Lilypond-Update, wenn man die neue Version anstelle des Vorgängers benutzen will, selber ändern?
Der Normalfall ist ja, dass LilyPond direkt in /Applications liegt. Bei einem Update wird der alte App-Container mit dem neuen überschrieben. Dann wäre der Pfad immer derselbe (/Applications/LilyPond.app/Contents/Resources/bin). Wenn du verschiedene Versionen gleichzeitig oder mit anderer Pfadangabe installiert hast, musst du es selbst ändern.
Pfadeinträge in der .profile dienen doch gerade dazu, den Pfad zu einer Anwendung nicht immer mit eingeben zu müssen. Wenn du im Terminal einfach nur lilypond eingibst, sucht das Betriebssystem in allen eingetragenen Pfaden nach der Anwendung. Wird eine Anwendung auf diese Weise nicht gefunden, gibt’s ’ne Fehlermeldung. Ansonsten müsstest du jedes Mal die Anwendung mit kompletter Pfadangabe aufrufen, z.B.
/Applications/LilyPond.app/Contents/Resources/bin/lilypond meine_partitur.ly
Grüße, Robert
-
hallo Robert,
ich habe nun Python 3.1.2 und 2.6.5 installiert und den Pfad zu Lilypond 2.12.3 richtig eingetragen. Entsprechende Terminal-Eingaben bestätigen, daß jetzt alles in dieser Hinsicht seine Ordnung hat. Ich habe Lilypond 2.12.3 denn auch mal gestartet. Ein Probelauf ergab, daß Lilypond zwar alle möglichen .ly-Dateien brav in ein PDF verwandelt, aber irgendetwas grummelt noch im Untergrund, denn ich bekomme Fehlermeldungen z.B. in dieser Art:
Konvertierung nach >>./GounodAve.pdf<<.../Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: In procedure system in expression (system silenced):
/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: Resource temporarily unavailable
Mache ich dasselbe mit der gleichen Datei im Terminal, ist das Ergebnis:
Konvertierung nach »./GounodAve.pdf«...sh: fork: Resource temporarily unavailable
»gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./GounodAve.pdf" -c .setpdfwrite -f "GounodAve.ps"« gescheitert (32768)
Fehler: gescheiterte Dateien: "GounodAve.ly"
Spanne ich TeXShoP für die gleiche Aufgabe ein, kommt:
Feeding GounodAve.ly to lilypond... Please wait...
tcsh: lilypond: Command not found.
Beim Start von TeXShoP kriege ich zwar ein PDF zu sehen, aber wohl nur, weil es bereits eines gibt, das beim Start gleich geöffnet werden kann.
Kannst Du das deuten? Hat das mit meiner GCC-Umgebung zu tun? Oder ist was mit Postscript faul?
Bin gespannt, was Du zu sagen hast.
-
Hat das mit meiner GCC-Umgebung zu tun? Oder ist was mit Postscript faul?
Sieht eher nach GhostScript-Fehler aus. Komme ich später drauf.
Spanne ich TeXShoP für die gleiche Aufgabe ein, kommt:
Feeding GounodAve.ly to lilypond... Please wait...
tcsh: lilypond: Command not found.
Wie sieht es in deiner Lilypond.engine (vorausgesetzt, sie heißt so) aus? Dort stimmt der Pfad zu LilyPond nicht! In deinem Fall sähe die abgespeckte Lilypond.engine folgendermaßen aus:
#!/bin/tcsh
set path = (/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/bin/)
echo "Feeding $1 to lilypond... Please wait...";
lilypond "$1"
Mehr ist nicht nötig; sogar die Zeile, die mit echo beginnt, kann entfallen. Wenn der Pfad zu Lily systemweit richtig eingetragen ist, kann selbst die Zeile mit set path entfallen! Somit reduzierte sich die TeXShop-Engine auf:
#!/bin/tcsh
lilypond "$1"
Am sichersten aber fährst du, wenn du den Pfad in der Engine setzt. Damit kannst du durch verschiedene Engine-Dateien verschiedene Lily-Versionen ansprechen. Wenn du bspw. mit einer Engine – nenne sie z.B. Lilypond-2.10.33.engine – die Lily-Version 2.10.33 im Ordner /Applications/Notation/Lilypond_2.10.33 ansprechen willst, setzt du den Pfad entsprechend, und die Datei hätte folgenden Inhalt:
#!/bin/tcsh
set path = (/Applications/Notation/Lilypond_2.10.33/LilyPond.app/Contents/Resources/bin/)
echo "Feeding $1 to Lilypond 2.10.33... Please wait...";
lilypond "$1"
In der jeweils letzten Zeile (wenn lilypond aufgerufen wird) kannst du alle verfügbaren Kommandozeilenoptionen an Lily übergeben, z.B. -dno-point-and-click, um point-and-click abzuschalten, oder -ddelete-intermediate-files, um die zwischendurch erzeugten PS-Dateien zu löschen. Diese Zeile würde dafür so aussehen:
lilypond -dno-point-and-click -ddelete-intermediate-files "$1"
Kleiner Tipp: Wenn du in die erste Zeile deiner .ly-Datei % !TEX TS-program = Lilypond (oder wie auch immer deine .engine heißt) einträgst, wählt TeXShop diese Engine von allein aus. Das funktioniert für alle Engines, die in der Liste verfügbar sind, z.B. auch für Pdflatex.
Eine wichtige Sache fällt mir dabei gerade ein: Gib bitte im Terminal lilypond -dhelp ein und poste, was dort hinter datadir eingetragen ist. Vielleicht könnte das „unavailable resource“-Problem daher rühren!
Grüße, Robert
-
hallo Robert,
da haben sich meine Antwort auf Dein Mail und Deine Antwort im Forum überschnitten. Die Antwort auf die Mail wollte sich aber nicht senden lassen, und so kommt sie nun auch hierhin:
danke, so ist es wohl leider mit dem Süppchen. Kompilieren kann ich den Quellcode nicht; dazu fehlt es mir an Kenntnissen.
Ich habe GCC 4.0.1 nun laut Terminal-Rückmeldung auf dem Rechner. Wenn ich jetzt Lilypond in diversen Umgebungen betreibe, ergibt sich folgendes Bild:
Terminal: funktioniert wunderbar; auch endlose Wiederholungen von lilypond *.ly lösen offenbar keine Fehlermeldungen mehr aus.
Lilypond 2.12.3: Die "Ermüdungserscheinungen", bei denen Lilypond nicht bis zum PDF kommt, treten nun schon reproduzierbar nach dem 3.Mal auf.
TeXShoP: das funktioniert nach wie vor überhaupt nicht, da lilypond laut Konsole nicht gefunden wird (tcsh: lilypond: Command not found.) Blöderweise finde ich in TeXShoP auch nichts, wo ich den Pfad (das ist, so vermute ich, der Knackpunkt) zu lilypond eintragen könnte. Mit 2.12.2 hat das einfach so immer funktioniert. Ich kann mich nicht erinnern, daß ich da mal einen Pfad angeben mußte.
Ich hoffe, daß Du noch nicht am Ende Deines Lateins bist...
Nun die Antwort auf Deinen Kommentar hier:
Leider habe ich keine Ahnung, was die Lilypond.engine ist (was sie tut, wird natürlich aus dem Kontext hier klar). Wenn ich im Terminal suche, bekomme ich die Antwort:
which Lilypond.engine
no Lilypond.engine in /Library/Frameworks/Python.framework/Versions/2.6/bin /Library/Frameworks/Python.framework/Versions/3.1/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/texbin /Users/ich/bin
Ist das also eine Datei, die ich selber anlegen muß? Und wenn ja, wo am besten? Und wo finde ich Infos zu solchen Themen (Du hast sie Dir vermutlich ja auch mal angelesen...)?
Und wenn ich lilypond -dhelp tippe, kommt die Antwort (hier der Auszug, der Dich interessiert):
datadir ("/Applications/Notation/LilyPond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current")
LilyPond prefix for data files (read-only).
herzlichen Gruß
-
datadir ("/Applications/Notation/LilyPond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current")
LilyPond prefix for data files (read-only).
Das ist schonmal in Ordnung.
Ich habe GCC 4.0.1 nun laut Terminal-Rückmeldung auf dem Rechner.
Das ist auch prima.
Terminal: funktioniert wunderbar; auch endlose Wiederholungen von lilypond *.ly lösen offenbar keine Fehlermeldungen mehr aus.
Da wollen wir ja hin! Super! Wenn der Unterbau fehlerfrei zu laufen scheint, wird der Rest auch klappen.
Lilypond 2.12.3: Die "Ermüdungserscheinungen", bei denen Lilypond nicht bis zum PDF kommt, treten nun schon reproduzierbar nach dem 3.Mal auf.
Das ist weniger erfreulich, lässt aber auf Defekte in der App schließen. Schonmal probiert, v2.12.3 nochmal runterzuladen (http://lilypond.org/web/install/#2.12) und drüber zu kopieren? Aufpassen, dass du die richtige Version für deine Architektur (PPC oder Intel) erwischst!
TeXShoP: das funktioniert nach wie vor überhaupt nicht, da lilypond laut Konsole nicht gefunden wird (tcsh: lilypond: Command not found.) Blöderweise finde ich in TeXShoP auch nichts, wo ich den Pfad (das ist, so vermute ich, der Knackpunkt) zu lilypond eintragen könnte. Mit 2.12.2 hat das einfach so immer funktioniert. Ich kann mich nicht erinnern, daß ich da mal einen Pfad angeben mußte.
Jetzt muss ich aber mal ganz blöd fragen, wie du das sonst in TeXShop anstellst? Also wie bringst du TeXShop bei, eine .ly-Datei zu übersetzen? Warum soll das mit 2.12.2 einfach so gegangen sein und jetzt nicht mehr? Beschreib doch mal kurz deine Vorgehensweise.
Der Pfad geht auch nicht in TeXShop selbst einzutragen, sondern in der .engine. Ob eine Datei namens Lilypond.engine auf deinem System ist, kriegst du über die ganz normale Spotlight-Suche raus.
Ist das also eine Datei, die ich selber anlegen muß? Und wenn ja, wo am besten? Und wo finde ich Infos zu solchen Themen (Du hast sie Dir vermutlich ja auch mal angelesen...)?
Ja, selber anlegen. Ich habe es aus der AU 2.2.4 TeXShop (http://lilypond.org/doc/v2.12/Documentation/user/lilypond-program/TexShop#TexShop). Dort ist der Link zu den .engine-Dateien. Früher waren diese gut kommentiert, jetzt leider nicht mehr. Eine Beispielversion der Lilypond.engine habe ich beigefügt. Diese Engines sind sehr nützlich! Ansonsten googlen, googlen, googlen und viel ausprobieren ;)
Aber schreib noch, wie du das sonst immer mit TeXShop gemacht hast …
Beste Grüße, Robert
-
hallo Robert,
wenden wir uns mal dem Sorgenkind TeXShoP zu:
Ich habe mir die Umgebung im letzten Jahr eingerichtet, nachdem ich eine Menge ausprobiert habe, was Arbeitsumgebungen angeht, und bin dann letzten Endes bei TeXShoP gelandet. Das alles ist in dem "convert-ly"-Thread hier enthalten. James alias "DerHindemith" war dabei eine munter sprudelnde Informationsquelle, der auch selber in monatelanger Kleinarbeit eine ebenfalls tolle Umgebung in nano gebaut hat, die wirklich einen Blick wert ist. Eigentlich ist sie genauso gut wie TeXShoP. Ich hatte mich nur vorher schon an das letztere gewöhnt...
Aber das am Rande;-)
etzt muss ich aber mal ganz blöd fragen, wie du das sonst in TeXShop anstellst? Also wie bringst du TeXShop bei, eine .ly-Datei zu übersetzen? Warum soll das mit 2.12.2 einfach so gegangen sein und jetzt nicht mehr? Beschreib doch mal kurz deine Vorgehensweise.
Der Pfad geht auch nicht in TeXShop selbst einzutragen, sondern in der .engine. Ob eine Datei namens Lilypond.engine auf deinem System ist, kriegst du über die ganz normale Spotlight-Suche raus.
Meiner Erinnerung nach habe ich ihm gar nichts beibringen müssen. Ich habe einfach den Editor geöffnet, meine .ly-Datei erstellt, in der Leiste oben im Fenster unter den verschiedenen Schriftsatzmöglichkeiten "lilypond" ausgewählt, auf "Setzen" geklickt oder Cmd-T betätigt, und dann ging es los. Das fand ich ja so angenehm, daß man gar nichts Kompliziertes oder schwer Aufzufindendes machen mußte!
Na ja, jetzt geht es momentan nicht mehr. Ich habe aber ein wunderbares Programm namens EasyFind, das noch mehr findet als Spotlight in aller Regel, und das habe ich mal auf ".engine" angesetzt. Und es fand einen ganzen Haufen davon, und auch eine Lilypond.engine!
Der Pfad ist: /Users/ich/Library/TeXShop/Engines/Lilypond.engine
Es handelt sich um eine Textdatei, in der erklärt wird, wie man sich eine "engine" bauen kann. Also genau das, was mir an Info gefehlt hat. Und nirgendwo ein Hinweis darauf!
Im Terminal habe ich sie auch nicht entdeckt, aber das lag wahrscheinlich an meinem Suchbefehl which. Kenne nur keinen anderen, der einen weiteren Bereich abdeckt. "which" sucht offenbar nur bestimmte vordefinierte Ordner ab, habe ich den Eindruck. Ach Gott! Jetzt dämmert es mir: doch, ich habe diese Engines von dieser Seite: http://users.dimi.uniud.it/~nicola.vitacolonna/home/content/lilypond-scripts (http://von dieser Seite: http://users.dimi.uniud.it/~nicola.vitacolonna/home/content/lilypond-scripts) heruntergeladen und dorthin gelegt. Hatte ich völlig vergessen. Kennst Du die Seite?
Inzwischen habe ich meine Experimente abgeschlossen und kann berichten:
TeXShop: ich habe die "Lilypond.engine" und die "convert-ly.engine" nach Anweisung aus den Kommnetaren in der Datei (da steht das gleiche, was Du auch gesagt hast) geändert. Dort stand tatsächlich ein anderer Pfad zu Lilypond 2.12.1. Und nun funktioniert alles wieder, o Wunder! Ich habe nur die "1" in eine "3" geändert.
Lilypond: Immer noch ein Sorgenkind. Ich habe das alte Lilypond gelöscht und ein frisches in den Ordner gelegt, aber es gibt immer noch Fehlermeldungen, die alsbald dazu führen, daß Lilypond den Dienst verweigert: entweder "Weiter" oder "Beenden". Nach einem Neustart geht es dann wieder, aber nur ein paarmal, dann ist wieder Schluß. In der Konsole sieht das so aus:
>>/Users/ich/Documents/Notenabschriften/Vorlagen/Vorlage_Einzelstimmen.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>Vorlage_Einzelstimmen.ps<< ausgeben...
Konvertierung nach >>./Vorlage_Einzelstimmen.pdf<<...
>>/Users/ich/Documents/Notenabschriften/Vorlagen/Vorlage_Einzelstimmen.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>Vorlage_Einzelstimmen.ps<< ausgeben...
Konvertierung nach >>./Vorlage_Einzelstimmen.pdf<<...sh: fork: Resource temporarily unavailable
>>gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./Vorlage_Einzelstimmen.pdf" -c .setpdfwrite -f "Vorlage_Einzelstimmen.ps"<< gescheitert (32768)
Fehler: gescheiterte Dateien: "/Users/ich/Documents/Notenabschriften/Vorlagen/Vorlage_Einzelstimmen.ly"
>>/Users/ich/Documents/Notenabschriften/Vorlagen/Vorlage_Einzelstimmen.ly<< wird verarbeitet
Analysieren...
Interpretation der Musik...[8]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach >>Vorlage_Einzelstimmen.ps<< ausgeben...
Konvertierung nach >>./Vorlage_Einzelstimmen.pdf<<.../Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: In procedure system in expression (system silenced):
/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/lilypond/current/scm/backend-library.scm:26:15: Resource temporarily unavailable
Versucht man es dann noch einmal, dann nur noch "Continue" oder "Quit". Aber mein PDF kriege ich jetzt trotzdem jedes Mal. Hakt es also bei Postscript? Solche Fehlermeldungen kommen auch in TeXShop, ohne daß das Programm komplett seinen Geist aufgibt. Das sieht dann so aus:
Layout nach >>Vorlage_Einzelstimmen.ps<< ausgeben...
Konvertierung nach >>./Vorlage_Einzelstimmen.pdf<<...sh: fork: Resource temporarily unavailable
>>gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./Vorlage_Einzelstimmen.pdf" -c .setpdfwrite -f "Vorlage_Einzelstimmen.ps"<< gescheitert (32768)
Fehler: gescheiterte Dateien: "Vorlage_Einzelstimmen.ly"
Was fällt Dir hierzu ein?
-
Hallo juppes,
Meiner Erinnerung nach habe ich ihm gar nichts beibringen müssen. Ich habe einfach den Editor geöffnet, meine .ly-Datei erstellt, in der Leiste oben im Fenster unter den verschiedenen Schriftsatzmöglichkeiten "lilypond" ausgewählt, auf "Setzen" geklickt oder Cmd-T betätigt, und dann ging es los. Das fand ich ja so angenehm, daß man gar nichts Kompliziertes oder schwer Aufzufindendes machen mußte!
Na ja, jetzt geht es momentan nicht mehr. Ich habe aber ein wunderbares Programm namens EasyFind, das noch mehr findet als Spotlight in aller Regel, und das habe ich mal auf ".engine" angesetzt. Und es fand einen ganzen Haufen davon, und auch eine Lilypond.engine!
Der Pfad ist: /Users/ich/Library/TeXShop/Engines/Lilypond.engine
Es handelt sich um eine Textdatei, in der erklärt wird, wie man sich eine "engine" bauen kann. Also genau das, was mir an Info gefehlt hat. Und nirgendwo ein Hinweis darauf!
Im Terminal habe ich sie auch nicht entdeckt, aber das lag wahrscheinlich an meinem Suchbefehl which. Kenne nur keinen anderen, der einen weiteren Bereich abdeckt. "which" sucht offenbar nur bestimmte vordefinierte Ordner ab, habe ich den Eindruck.
Ich kann leider nicht glauben, dass TeXShop das von allein gemacht haben soll. Hat vielleicht irgendwer anderes nachgeholfen? Ich weiß zuverlässig, dass TeXShop diese Lilypond.engine von Haus aus nicht mitbringt. Jedenfalls ist die passende Datei schon am rechten Ort und ist auch offensichtlich ausführbar. Sie enthält zwar nicht gerade eine Anleitung für „Eigenbau-Engines“, dafür aber, wie man die Datei an die lokale Umgebung anpasst. Hinweise dazu gibt es nur in der Datei selbst; dazu muss man sie aber wissentlich runtergeladen und entsprechend untergebracht haben!
which sucht nach Programmdateien und gibt deren Pfad aus. Dazu müssen die Programmdateien aber bereits „angemeldet“ sein. Wenn man z.B. lilypond wild irgendwohin in’s System kopieren würde, ohne dem System „Bescheid zu sagen“, könnte which es auch nicht finden. Überhaupt ungeeignet, um beliebige Dateien zu finden.
Um universellsten ist wohl locate. Es durchsucht allerdings statt der Festplatte seine lokale Datenbank, in der es alle Dateien katalogisiert. Vorteil: extrem schnell; Nachteil: Datenbank muss up-to-date sein. Das automatische Aktualisieren funktioniert nach meiner Erfahrung nicht einwandfrei, deshalb ist es ratsam, die Aktualisierung der Datenbank zu forcieren: sudo /usr/libexec/locate.updatedb (in nativen Unix-Systemen updatedb). Beim ersten Aufruf dauert das Anlegen der DB relativ lang; später geht es schneller, weil nur nach Unterschieden gesucht wird.
Eine Sache aber ist allen Suchmethoden gemein: sie durchforsten nicht einfach die ganze Festplatte à la WinExplorer. Wenn also eine Datei nicht gefunden wird, heißt das noch lange nicht, dass es sie im System nicht gibt!
Ach Gott! Jetzt dämmert es mir: doch, ich habe diese Engines von dieser Seite: http://users.dimi.uniud.it/~nicola.vitacolonna/home/content/lilypond-scripts heruntergeladen und dorthin gelegt. Hatte ich völlig vergessen. Kennst Du die Seite?
Na also, wusste ich doch ;) Klar, von dort habe ich ja auch das Script.
Lilypond: Immer noch ein Sorgenkind. Ich habe das alte Lilypond gelöscht und ein frisches in den Ordner gelegt, aber es gibt immer noch Fehlermeldungen, die alsbald dazu führen, daß Lilypond den Dienst verweigert: entweder "Weiter" oder "Beenden". Nach einem Neustart geht es dann wieder, aber nur ein paarmal, dann ist wieder Schluß.
Dann bleib am besten bei TeXShop oder am Terminal. Oder häng die Datei mal an, ob ich den Fehler reproduzieren kann.
Nun müssen wir also mal GhostScript checken. Gib im Terminal gs -h ein. Als letzte Information werden die Suchpfade von GS ausgegeben: bitte überprüfen, ob diese Pfade tatsächlich existieren! (Bei mir hatten sie nicht gestimmt.) Es kann sein, dass GS z.B. in /usr/local/share statt in /usr/share liegt. Die korrekten Pfade kannst du in deiner .profile mit der Variable GS_LIB ändern. Also wieder ran an’s Terminal:
cd
pico .profile
und folgende zwei Zeilen (natürlich mit Pfaden, die für dein System stimmen) hinzufügen:GS_LIB="/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Font:/usr/local/share/ghostscript/fonts:/Users/Orlando/Library/Fonts"
export GS_LIB
Die erste Zeile darf keinen Zeilenumbruch enthalten; verschiedene Pfade werden hintereinanderweg durch Doppelpunkt getrennt angegeben. Ich hoffe, das hilft deinem GS etwas auf die Sprünge (ab-/anmelden nicht vergessen).
Grüße, Robert
-
hallo Robert,
Du bist ja ein alter Terminal-Hase, das merkt man... Wahrscheinlich hast Du all das, was ich hier erlebe, schon hinter Dir und kennst dadurch die Verfahren, wie man aus der Bredouille wieder herauskommt ;)
Andererseits habe ich auch schon einiges mit lilypond und dem Terminal angestellt, aber das Problem ist, daß man nach einer längeren Pause so vieles wieder vergißt, siehe Vitacolonna :P
Nun müssen wir also mal GhostScript checken. Gib im Terminal gs -h ein. Als letzte Information werden die Suchpfade von GS ausgegeben: bitte überprüfen, ob diese Pfade tatsächlich existieren! (Bei mir hatten sie nicht gestimmt.) Es kann sein, dass GS z.B. in /usr/local/share statt in /usr/share liegt.
Deine Vermutung ist goldrichtig! Aus dem Terminal tönt es zurück:
Search path:
. : %rom%lib/ : /usr/local/share/ghostscript/8.63/lib :
/usr/local/share/ghostscript/8.63/Resource :
/usr/local/share/ghostscript/fonts :
/usr/local/share/fonts/default/ghostscript :
/usr/local/share/fonts/default/Type1 :
/usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
/usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType
Initialization files are compiled into the executable.
For more information, see /usr/local/share/ghostscript/8.63/doc/Use.htm.
Bei Dir scheint ja vielleicht eine neuere Version von Ghostscript installiert zu sein: 8.70. Oder sehe ich das falsch? Sollte ich meines aktualisieren, bevor ich mich an die Arbeit mache. Ich weiß allerdings nicht wie. Und es wundert mich auch, daß Ghostscript in einem Ordner liegt, wo es eigentlich nicht sein soll. Wäre es nicht besser, es einfach umzubetten? Oder kommen dann wieder andere Dinge ins Schleudern?
-
Hallo juppes!
Bei Dir scheint ja vielleicht eine neuere Version von Ghostscript installiert zu sein: 8.70. Oder sehe ich das falsch?
Jein. Es ist die von Lily mitgelieferte GS-Version. Vielleicht beharkt die sich mit deiner 8.63er …
Sollte ich meines aktualisieren, bevor ich mich an die Arbeit mache. Ich weiß allerdings nicht wie. Und es wundert mich auch, daß Ghostscript in einem Ordner liegt, wo es eigentlich nicht sein soll. Wäre es nicht besser, es einfach umzubetten?
Lass das mit dem „umbetten“ mal lieber ;)
GS aktualisieren ist eine gute Idee. Eine aktuelle Mac-Version gibt es hier: http://www.uoregon.edu/~koch/Ghostscript-8.71.pkg.zip (vom TeXShop-Chef-Entwickler). Das Pfadproblem bei mir lag (und liegt) an Lily.
Es installiert sich in /usr/local (der komplette Pfad zur gs-Executable ist dann /usr/local/bin/gs)
Anschließend aus-/einloggen und per which gs den Pfad, per gs -v die Version und per gs -h die Suchpfade überprüfen. Ansonsten an’s Ende der ~/.profile (da isse wieder ;) ) die beiden Zeilen
PATH="/usr/local/bin:${PATH}"
export PATHhinzufügen.
Grüße, Robert
-
hallo Robert,
wenn ich tatsächlich zwei Ghostscript-Versionen auf dem Rechner haben sollte, ohne es zu wissen: wäre es dann nicht besser, eine davon rauszuschmeißen (die ältere; aber wie?) oder reicht es, wenn ich Lilypond eindeutig sage, auf welchen von meinen diversen Ghostscripts es zugreifen soll?
Vielleicht braucht ja etwas anderes bei mir im System dieses GS 8.63?
herzlichen Gruß
-
Lily bringt sein eigenes GS eben mit! Es schadet aber nicht, die aktuelle 8.71 zur Verfügung zu stellen (irgendwas wird es sicher benötigen).
Probier es erstmal mit dem Update. Man kann Lily nicht einfach sein GhostScript wegnehmen ;)
Grüße, Robert
-
hallo Robert,
schade, Ghostscript 8.71 läßt sich nicht installieren - kriege eine Fehlermeldung, daß es sich auf diesem Computer (Tiger 10.4.11 PPC G4) nicht installieren läßt.
Stelle dieses Projekt also einstweilen zurück und mache erst die anderen Hausaufgaben. Melde mich wieder, wenn ich fertig bin.
-
hallo Robert,
der Befehl "locate" ist ja eine echte Wunderwaffe, hat er mir doch enthüllt, daß ich mehrere Versionen von Ghostscript auf dem Rechner habe! "Offiziell" im System ist offenbar Version 8.63.
/usr/local/share/ghostscript
/usr/local/share/ghostscript/8.63
Und dann haben meine drei Lilypond-Versionen ihre eigene, wie Du ja schon sagtest:
/Applications/Notation/Lilypond_2.12.3/LilyPond.app/Contents/Resources/share/ghostscript/8.70
/Applications/Notation/LilyPond_2.13.4/LilyPond.app/Contents/Resources/share/ghostscript/8.65
/Applications/Notation/LilyPond_2.12.2/LilyPond.app/Contents/Resources/share/ghostscript/8.57
Ich habe nun versucht, die Pfade zu Ghostscript entsprechend Deinen Anweisungen zu ändern. Aber sei es, daß ich etwas nicht richtig gemacht oder verstanden habe, außer einem Absturz von Lilypond beim Start ist nichts dabei herausgekommen. Ich wollte in ".profile" auf 8.70 von Lilypond 2.12.3 verweisen und nicht auf das systemeigene Ghostscript.
Ich habe dann schließlich wieder alles auf den alten Zustand vor den Änderungen gesetzt, Lilypond 2.12.3 in den Applications-Ordner verschoben, die Pfade in ".profile" und in der TeXShop-Engine entsprechend geändert und im Infofenster (Cmd-I) eingestellt, daß alle .ly-Dateien mit TeXShop geöffnet werden sollen.
Ich hatte außerdem vorher noch eine Merkwürdigkeit entdeckt: wähle ich eine .ly-Datei aus und dann "Öffnen mit", kommt als Standard-Programm immer Lilypond 2.12.2. Egal, welche von den anderen Lilypond-Versionen ich dann nach "Cmd-I" eingestellt habe, es blieb bei Lilypond 2.12.2! Daraufhin habe ich diese Version in den Papierkorb verschoben, aber auch das änderte nichts daran!
Nach all diesem Stand der Dinge ist die Lage trotzdem positiv:
Terminal: alles funktioniert ohne Wenn und Aber.
TeXShop: Dito - keine Fehlermeldungen auch nach dem 11ten Mal Cmd-T - das reicht mir vollkommen aus.
Lilypond 2.12.3: toleriert ca. 6mal Cmd-R, dann fängt es an, die besagten Fehlermeldungen, die ich hier schon geschrieben habe, auszugeben. Es
kommt dann eben nur bis zur .ps-Datei. Nach einem Neustart des Programms hat man dann wieder ca. 6 Würfe frei. Da kann ich mit leben, obwohl die Macke für andere nervig sein könnte, jedenfalls dann, wenn man tatsächlich mit Lilypond selber arbeiten will.
herzlichen Gruß
-
guten Abend Robert,
bevor der Computer ausgeschaltet wird, noch schnell ein großes Dankeschön an Dich für die sachkundige Hilfe. Das meiste von den Problemen ist nun komplett abgestellt. Lilypond konnte nicht ganz "gezähmt" werden, aber man kann damit leben, wenn man es gar nicht als Arbeitsumgebung nutzt. Hauptsache, die anderen Umgebungen laufen rund. Jetzt kann ich wenigsten wieder Noten schreiben und muß nicht mehr "unter die Motorhaube"... Ich habe nebenbei was über das Basteln von Engines in TeXShop gelernt und auch schon welche für meine anderen Lilypond-Versionen angelegt. Außerdem habe ich noch ein paar nützliche Unix-Befehle fürs Terminal gelernt und den Nutzen von ".profile"
herzlichen Gruß
-
Moin juppes,
Ghostscript 8.71 läßt sich nicht installieren - kriege eine Fehlermeldung, daß es sich auf diesem Computer (Tiger 10.4.11 PPC G4) nicht installieren läßt.
Vielleicht 8.70 aus dem MacTeX 2009-Paket? http://www.uoregon.edu/~koch/
Und dann haben meine drei Lilypond-Versionen ihre eigene, wie Du ja schon sagtest
Hmm, seit 2.12.3 veröffentlicht wurde, ist allen Versionen GS 8.70 beigepackt. Auch die aktuelle Developmentversion 2.13.19 enthält GS 8.70. Das Problem ist, dass Lily offenbar immer auf sein eigenes GS zurückgreift (zu erkennen in den PDF-Eigenschaften unter „PDF erstellt mit“). Und diese Version sucht in den Pfaden /usr/share/...
Du kannst, wie gesagt, mit GS_LIB in der .profile Suchpfade für GS hinzufügen. Hier noch einmal die Zeilen:
GS_LIB="/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Font:/usr/local/share/ghostscript/fonts:/Users/Orlando/Library/Fonts"
export GS_LIB
Die Pfade musst du natürlich entsprechend anpassen. Ob Lily-GS dann tatsächlich danach sucht, kannst du mit gs -h und vollständiger Pfadangabe überprüfen. Wenn Lily 2.12.3 nun wieder direkt in Applications liegt, sieht der Befehl für’s Terminal folgendermaßen aus:
/Applications/LilyPond.app/Contents/Resources/bin/gs -h
Die Version dürfte 8.70 sein, und in den Suchpfaden müssten die zusätzlich angegebenen Pfade auftauchen.
Abschließend wären vielleicht noch zwei Maßnahmen nützlich:
(1) Den Lily-Fontcache löschen: dieser versteckte Ordner liegt in deinem Home-Verzeichnis und beginnt mit .lilypond-fonts.cache
(2) Die Volume-Zugriffsrechte reparieren, falls du das nicht öfter schon tust. (Dienstprogramme → Festplattendienstprogramm)
… aber man kann damit leben, wenn man es gar nicht als Arbeitsumgebung nutzt. Hauptsache, die anderen Umgebungen laufen rund.
Ja, „LilyPad“ ist wohl eher zum schmunzeln ;) Es gibt viele andere Editoren, die Lily-Code besser handhaben. Voraussetzung für alle ist aber, dass der Unterbau stimmt. Lily 2.12.2 kann ruhig ganz gelöscht werden; 2.12.3 beinhaltet viele Bugfixes aus der 2.13-Serie.
Übrigens kann ich in Lily 2.12.3 Cmd-R so lange betätigen, bis ich ’ne Sehnenscheidenentzündung kriege – es ist einfach „unermüdlich“ … :) Vielleicht steckt doch etwas in deiner Datei? Schick doch mal eine rüber, ob bei mir das gleiche passiert.
Schönen Sonntag, Robert
-
hallo Robert,
Die Version dürfte 8.70 sein, und in den Suchpfaden müssten die zusätzlich angegebenen Pfade auftauchen.
So ist es auch.
Du kannst, wie gesagt, mit GS_LIB in der .profile Suchpfade für GS hinzufügen.
Eines verstehe ich noch nicht ganz: Lilypond sucht also nach seinem eigenen Ghostscript und findet es wohl auch bei mir, wenigstens ein paarmal:
Search path:
. : /usr/share/ghostscript/8.70/Resource/Init :
/usr/share/ghostscript/8.70/lib :
/usr/share/ghostscript/8.70/Resource/Font :
/usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
/usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType :
/usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 :
/usr/openwin/lib/X11/fonts/TrueType
In Deinem Codebeispiel von GS_LIB gibt es nun Suchpfade in /usr/local/share/ghostscript/8.70. Was ist denn nun, wenn dort gar kein 8.70 liegt, sondern eben nur ein 8.63 wie bei mir? Muß dich dann in diesen zusätzlichen Suchpfaden (das ist doch so, wenn ich die Sache richtig verstehe, oder?) statt wie in Deinem Beispiel "/usr/local/share/ghostscript/8.70." dann "/usr/local/share/ghostscript/8.63." eintragen?
Ansonsten was mein Versuchkaninchen immer eine ganz einfache .ly Datei mit folgendem Code:
\include "deutsch.ly"
\header{
title = "Frère Jacques"
subsubtitle = "for concert on June 14; always bring to violin lessons"
tagline = \markup { \center-column { \small
"Hajo Bäß, Nümbrecht 29.3.2010" \line { \tiny \with-url #"http://lilypond.org/web/" {
gesetzt mit LilyPond 2.12.3 — www.lilypond.org \italic {
music notation for everyone
} } } }
}
}
\relative {
\clef treble \key d \major \time 4/4
d4-0^\markup {D} e-1 fis-2 d-0
d-0 e-1 fis-2 d-0
fis-2 g-3 a2-0^\markup { A}
fis4-2^\markup { D} g-3 a2-0^\markup { A}
a8-0 h-1 a-0 g-3^\markup { D} fis4-2 d-0
a'8-0^\markup { A} h-1 a-0 g-3^\markup { D} fis4-2 d-0
d-0 a-1^\markup { G} d2-0^\markup { D}
d4-0 a-1^\markup { G} d2-0^\markup { D} \bar "|." }
\version "2.12.3" % necessary for upgrading to future LilyPond versions.
\pointAndClickOn
Das Terminal und TexShop hatten daran nie was auszusetzen (ebenfalls bis kurz vor die Sehnenscheidenentzündung, unterstelle ich jetzt einfach mal ;))
-
Lilypond sucht also nach seinem eigenen Ghostscript und findet es wohl auch bei mir, wenigstens ein paarmal:
Jein. Lily sucht in seinem eigenen Ordner und nimmt die gs, die es dort findet. Dieses gs sucht nun in den Pfaden, die es ausgibt. Das heißt noch lange nicht, dass diese Pfade tatsächlich existieren! Ich könnte wetten, dass es /usr/share/ghostscript auch auf deinem System nicht gibt (stattdessen /usr/local/share/ghostscript – siehe Ausgabe von locate). Der einzig existente Ordner ist wohl /usr/share/fonts/default/TrueType. Alle anderen Ordner gibt es zumindest bei mir nicht (und bei dir vermutlich auch nicht).
Das bedeutet, dass sich Lilys GS im Lilypond-Ordner irgendwie zurechtfinden muss. Die Pfade unterhalb von /share existieren innerhalb des LilyPond.app-Containers. Ich kann nur mutmaßen, dass gs in Lily davon ausgeht, dass es bereits in /usr/local installiert sei – das wäre der Fall für die meisten Linux-Packages.
Du kannst gern deine Festplatte im Terminal oder z.B. mit XFolders (http://www.kai-heitkamp.de/) durchsuchen, welche Pfade es wirklich gibt ;)
Was ist denn nun, wenn dort gar kein 8.70 liegt, sondern eben nur ein 8.63 wie bei mir? Muß dich dann in diesen zusätzlichen Suchpfaden (das ist doch so, wenn ich die Sache richtig verstehe, oder?) statt wie in Deinem Beispiel "/usr/local/share/ghostscript/8.70." dann "/usr/local/share/ghostscript/8.63." eintragen?
Auf eine ältere Version würde ich nicht verweisen. Es müsste schon mindestens 8.70 sein. Deswegen mein Hinweis, ob wenigstens die 8.70 auf http://www.uoregon.edu/~koch/ für deine PPC-Architektur funktioniert.
Ansonsten was mein Versuchkaninchen immer eine ganz einfache .ly Datei mit folgendem Code:
Ich meinte nicht den Dateiinhalt, sondern die Datei an sich :) Am besten zippen und hier ranhängen!
Grüße, Robert
-
Wette gewonnen! Gibt's bei mir nicht, noch nicht mal "fonts".
Das hier ist bei mir drin:
Ssh.bin bison.simple dict gprof.callg libiodbc openldap snmp texinfo
aclocal calendar doc gprof.flat libtool ri swat vim
aclocal-1.6 cracklib emacs groff locale screen tabset wx
autoconf cups enscript httpd man sdef tcsh zoneinfo
automake-1.6 curl file icu misc servermgrd terminfo zsh
bison.hairy cvs gdb info mk skel texi2html
Und in /usr/local/share:
ghostscript gutenprint info man nano tabset terminfo
Voilà!
Was soll ich jetzt machen? Erst mal versuchen und sehen, ob nach einer eventuell erfolgreichen 8.70-Installation ein Ordner 8.70 in /usr/share liegt?
Kann man das bei einer Installation auswählen?
-
muß noch was hinterherschieben (siehe Bildschirmfotos). Die Installationsprogramme von Ghostscript 8.70 und 8.71 scheinen mein Betriebssystem nicht zu erkennen: sie glauben, ich hätte Panther oder Jaguar drauf!
Was nun?
An den Entwickler schreiben? Oder hast Du oder sonst irgendjemand einen Workaround?
Außerdem hier zum Test noch meine Versuchs-.ly-Datei
-
Und noch ein Nachtrag:
Könnte man die Sache nicht auch folgendermaßen lösen: ich habe festgestellt, daß weder mein TeXShop noch mein MacTeX auf der Höhe der Zeit sind. Ich arbeite mit TeXShop 2.26 und mit der MacTeX-Version, die ich mir mal 2009 im April heruntergeladen und installiert habe. Wenn ich das alles mal auf den neuesten Stand brächte, wäre als Nebeneffekt dann möglicherweise auch mein Ghostscript mitaktualisiert?
-
Ein Update auf die aktuelle MacTeX-Distribution ist natürlich eine Idee. Enthalten ist u.a. GhostScript 8.70 … sofern dieser ominöse Fehler wegen eines angeblich zu alten Systems nicht auftaucht.
Aktuelle TeXShop-Version ist 2.33 (falls die im MacTeX-Paket älter sein sollte).
GhostScript dürfte trotz allem in /usr/local/share/ghostscript/8.70 installiert werden.
Viel Erfolg ;)
Ach so: deine .ly-Datei läuft bei mir einwandfrei auch in Lily durch …
-
hallo Robert,.
dann probier ich es mal heute abend. Aber erst muß ich MacTeX-2009 herunterladen. 1,3 GB - das dauert... Vor acht Uhr werde ich es wohl nicht auf der Festplatte haben.
Melde mich wieder nach getaner Tat...
-
1,3 GB - das dauert...
In Abhängigkeit der Verbindung ;)
MacTeX-2009 hat ein cooles neues Feature: den Updatemanager tlmgr! Man kann jetzt also endlich mit einem einzigen (Konsolen-)Programm die Pakete aktualisieren :) Die Anleitung als PDF liegt in Applications/TeX.
-
ja, ich hab nur das langsamste DSL - aber stabil. Und nun ist es vollbracht - ich habe GS 8.70 auf dem Rechner, wie mir das Terminal auf die Anfrage "gs -v" mitteilt:
Search path:
. : %rom%Resource/Init/ : %rom%lib/ :
/usr/local/share/ghostscript/8.70/Resource/Init :
/usr/local/share/ghostscript/8.70/lib :
/usr/local/share/ghostscript/8.70/Resource/Font :
/usr/local/share/ghostscript/fonts :
/usr/local/share/fonts/default/ghostscript :
/usr/local/share/fonts/default/Type1 :
/usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
/usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType
Es hat sich anstandslos installieren lassen ohne Meckern. Aber das Pfadproblem mit Lilypond besteht nun wohl immer noch, da Lilypond ja gerne sein GS in /usr/local sähe, nicht wahr? Wenn dem so ist, muß ich also noch weitere Suchpfade nach Deinem Muster hinzufügen, nicht wahr? Jedenfalls benimmt es sich noch exakt wie vorher, wohingegen TeXShop 2.33 und Terminal weiterhin ohne Probleme laufen.
-
Es hat sich anstandslos installieren lassen ohne Meckern.
Supi!
Aber das Pfadproblem mit Lilypond besteht nun wohl immer noch, da Lilypond ja gerne sein GS in /usr/local sähe, nicht wahr? Wenn dem so ist, muß ich also noch weitere Suchpfade nach Deinem Muster hinzufügen, nicht wahr?
In /usr/share :( Die Suchpfade sollten „meinem“ Muster entsprechen, ja. Also für dich auf 8.70 gemünzt.
Mir hatte das Hinzufügen der zusätzlichen GS_LIB-Pfade (also Pfade zu einer vollwertigen, nicht abgespeckten GS-Version) einmal sehr bei einem dämlichen Fontproblem geholfen; deswegen kann ich es beruhigt empfehlen.
Ich habe es noch nicht selbst ausprobiert, die Lily-GS-Suchpfade mit Inhalt zu füllen. Man vergisst so etwas schnell, und es lässt sich auch schwer aktuell halten. Deshalb ist der komfortabelste und saubere Weg tatsächlich, GS_LIB in der .profile einzutragen. Lily-GS ist mit seinen eigenen Suchpfaden kompiliert, das können wir nicht anders ausmerzen.
Jedenfalls benimmt es sich noch exakt wie vorher, wohingegen TeXShop 2.33 und Terminal weiterhin ohne Probleme laufen.
Wir können mittlerweile wohl davon ausgehen, dass das Lily-GUI auf deinem System niemals wie gewünscht laufen mag … unten rum funktioniert alles, nur die Lilyoberfläche zickt – das wäre bei den Mac-Binaries nicht das erste Mal! Freu dich lieber über eine nunmehr aktuelle und funktionierende LP-TeXShop-GS-Umgebung ;) Du weißt jetzt auch, wie man die TeXShop-Engines handhaben kann (vor allem für versch. Lily-Versionen).
Beste Grüße, Robert
-
hallo Robert,
Ich habe ".profile" nach Deinen Vorgaben abgeändert (war ja nicht viel anzupassen außer dem Benutzernamen für ~/Users/*/Fonts, wenn ich das richtig sehe). Ich bringe aber (und vielleicht steckt ja noch ein Denkfehler in meinen zusätzlichen Suchpfaden für Lilypond, die ich in ".profile" hineingeschrieben habe) Lilypond nicht dazu, dort auch tatsächlich zu suchen, denn eine Eingabe im Terminal
/Applications/LilyPond.app/Contents/Resources/bin/gs -h
ergibt nur:
. : /usr/share/ghostscript/8.70/Resource/Init :
/usr/share/ghostscript/8.70/lib :
/usr/share/ghostscript/8.70/Resource/Font :
/usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
/usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType :
/usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 :
/usr/openwin/lib/X11/fonts/TrueType
Der Inhalt von ".profile" bei mir sieht folgendermaßen aus:
LC_CTYPE=de_DE.UTF-8 export LC_CTYPE export PATH=$PATH:~/bin
GS_LIB="/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Fo$
export GS_LIB PATH="/usr/local/bin:${PATH}"
export PATH
Die erste Zeile stand vorher schon drin; die brauche ich, um nano UTF-8 beizubringen.
Hoffe, Du findest eine Ungereimtheit, die man beseitigen kann...
Und sonst: es ist vielleicht tatsächlich so, daß das Lilypond-GUI unter Mac OS X immer ein wenig hakt. Aber wenn andere Umgebungen nicht haken, dann nimmt man eben die, vor allem wenn sie noch mehr Features haben.
herzlichen Gruß
-
Hallo juppes!
Hoffe, Du findest eine Ungereimtheit, die man beseitigen kann...
Sind die Zeilen per Zeilenumbruch getrennt? Man kann diese auch anders schreiben (und am besten kommentieren):
# UTF-8 fuer nano
export LC_CTYPE=de_DE.UTF-8
# Pfad zu /bin im Home-Verzeichnis den anderen Pfaden voranstellen
export PATH="~/bin:$PATH"
# Pfade zu GS 8.70-Libraries und Font-Ordnern
export GS_LIB="/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Font:/usr/local/share/ghostscript/fonts:/Users/ich/Library/Fonts"
# Pfad zu /usr/local/bin (wo gs liegt) den anderen Pfaden voranstellen
export PATH="/usr/local/bin:$PATH"
Ein-/ausgeloggt wirst du dich wohl haben … Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
Grüße, Robert
-
hallo Robert,
da bin ich wieder (war zwei Tage unterwegs). Ich habe mal Deine Version von ".profile" bei mir eingesetzt. Erstmal sieht das natürlich übersichtlicher aus und zweitens hatte es positive Auswirkungen:
Lilypond läuft wieder etwas runder, was die ominösen Fehlermeldungen nach Cmd-R betrifft. Jetzt sind es wieder wie zu Anfang unserer "Unterhaltung" sieben Mal, bis es meckert. Das ist ja schon mal was!
Lilypond sucht jetzt tatsächlich auch nicht nur bei sich nach Ghostscript:
Search path:
. : /usr/local/share/ghostscript/8.70/Resource/Init :
/usr/local/share/ghostscript/8.70/lib :
/usr/local/share/ghostscript/8.70/Resource/Font :
/usr/local/share/ghostscript/fonts : /Users/ich/Library/Fonts :
/usr/share/ghostscript/8.70/Resource/Init :
/usr/share/ghostscript/8.70/lib :
/usr/share/ghostscript/8.70/Resource/Font :
/usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
/usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType :
/usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 :
/usr/openwin/lib/X11/fonts/TrueType
Terminal und TeXShop machen auch weiterhin keinerlei Probleme.
Habe aber noch zwei Fragen:
Sind die Zeilen per Zeilenumbruch getrennt?
Ist das von Bedeutung und wenn ja, wieso? Ich hatte an mindestens einer Stelle einen Zeilenumbruch.
Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
Sorry, das verstehe ich nicht. Meinst Du: "env # gs"? Oder "env gs #"? Da stoßen meine Unix-Kenntnisse schon wieder an ihre Grenzen... :-\
-
Hallo juppes!
Lilypond läuft wieder etwas runder, was die ominösen Fehlermeldungen nach Cmd-R betrifft. Jetzt sind es wieder wie zu Anfang unserer "Unterhaltung" sieben Mal, bis es meckert. Das ist ja schon mal was!
Na ja, streng genommen ist das nichts >:( Idealerweise sollte Lily von sich aus fehlerfrei laufen, was es auf den meisten Systemen ja auch tut! Lily ist für den eigenständigen Programmbetrieb konzipiert (bringt eigenes GS und Python mit), weswegen die ganzen Einstellungen, die wir gerade für dich anpassen/angepasst haben, nur Auswirkungen auf den Betrieb im Terminal und das Zusammenspiel mit externen Editoren haben dürften. Ich kann nur vermuten, dass Lily in der Not systemweite Einstellungen zu Rate zieht, um irgendwo überhaupt weiter zu kommen. Das Hauptproblem ist einfach, dass wir als Mac-User nach wie vor eine Randgruppe sind und die vorkompilierten Binaries eben nicht so umfassend getestet sein können wie für native Unix-/Linux- oder Windows-Systeme. Womöglich liegt es aber auch an uns selbst, weil wir vielleicht weniger Feedback an die Entwickler liefern … In deinem Fall könnte es simplerweise an der PPC-Architektur (wie auch bei GS für Mac OS X) liegen! Ich hab halt ’nen Intel-basierten Mac und kann solche Phänomene wie bei dir nicht 1:1 nachstellen. Die stabilen Versionen von Lily habe ich bei mir noch nie abk…en sehen ;) (Muss aber auch dazu sagen, dass ich den Lily-Editor resp. LilyPond als App – außer für dein aktuelles Problem – nie benutze.)
Terminal und TeXShop machen auch weiterhin keinerlei Probleme.
Dann ist es gut so – bleib dabei! In der englischen Liste sind Diskussionen zu beobachten, „LilyPad“ komplett zu überholen, um einen brauchbaren Editor gleich mitzuliefern; der Tenor ist allerdings, in erster Linie Lily selbst weiterzuentwickeln, und aufgrund wesentlich besserer, externer Editoren (Frescobaldi, jEdit mit LilypondTool, Canorus etc.) ein eigenes benutzerfreundlicheres GUI zurückzustellen. Das finde ich persönlich gar nicht schlimm, aber es erschwert dem Einsteiger sehr den Zugang zu Lily – gerade wenn es „die erste Begegnung“ mit Software auf Texteingabebasis ist. Die Entwickler wissen darum und wollen den Einstieg dadurch erleichtern, aber sie wissen auch, dass man das Rad (in Sachen Editor) nicht neu erfinden muss. Ich erwarte von Lily auch nur eine gute Notensatz-Engine – auf welche Art und Weise ich Lily mit Code füttere, darf ruhig mir selbst überlassen bleiben :) Vielleicht liegt es ja gerade am spartanischen „LilyPad“, dass man sich gezwungenermaßen nach einem nützlichen Tool umsehen muss … Aber dann sollte man im Gegenzug insbesondere Einsteigern entgegenkommen und auf alternative Editoren schon auf lilypond.org (http://lilypond.org) hinweisen!
Lilypond sucht jetzt tatsächlich auch nicht nur bei sich nach Ghostscript
Um das noch einmal abzugrenzen: es ist GhostScript in Lily, das in diesen Pfaden sucht. Lily produziert mit Hilfe von GhostScript PS-Code, welchen GS nach PDF konvertiert. Lily hat also, nachdem es die Eingabedatei postscriptgerecht bearbeitet hat, nix mehr zu melden.
Sind die Zeilen per Zeilenumbruch getrennt?
Ist das von Bedeutung und wenn ja, wieso? Ich hatte an mindestens einer Stelle einen Zeilenumbruch.
Ja, das ist sogar ziemlich von Bedeutung. Ein Leerzeichen ist ganz lapidar ein typographisches Symbol. Leerzeichen werden in Programmabläufen höchstens einmal ausgewertet: tauchen bspw. 4 Leerzeichen hintereinander auf, wird das erste berücksichtigt und die verbleibenden 3 ignoriert.
Ein Zeilenumbruch – also das Betätigen der Enter-/Eingabetaste – ist ein Steuerzeichen. Es bedeutet: hier an dieser Stelle ist Schluss, mache fertig und warte auf Neues. Ein Leerzeichen macht nicht Schluss, selbst wenn am Ende einer Textzeile der optische Effekt eines Zeilenumbruchs einträte. Der „optische Effekt“ der Enter-Taste ist natürlich ein Zeilenumbruch, aber wie sollte man ihn sonst erkennen? Fakt ist: Befehl eingeben, Enter drücken und den Befehl somit abschließen und ausführen.
In der Regel schreibt man jeden auszuführenden Befehl in eine neue Zeile (durch „Enter“ erzeugt). Die Anweisungen werden dann zeilenweise von oben nach unten abgearbeitet. Wenn man nun in einer Zeile zwei Befehle hintereinander notiert, die nur durch Leerzeichen getrennt sind, werden diese als eine Eingabe interpretiert. Dies führt meist zu Fehlermeldungen bzw. ungewollter oder gar keiner Verarbeitung. Die Kombination zweier Befehle in einer Zeile ist durch doppeltes kaufmännisches Und (&&) möglich. Die beiden Befehle:
sudo tlmgr update --self
sudo tlmgr update --all
könnten dadurch in einer Zeile zusammengefasst werden:
sudo tlmgr update --self && sudo tlmgr update --allLässt man die && weg, wird allerhöchstens der zuletzt vollständig erkannte Befehl ausgeführt (in diesem Beispiel sudo tlmgr update --all). Man ist jedenfalls auf der sicheren Seite, wenn man auch in Scripten die Befehle durch „Enter“ trennt. Es liegt zwar im Ermessen des Interpreters, ob er einen Befehl bereits ausführt, wenn er ihn als vollständig erkannt hat, aber dazu muss man genaueres darüber wissen: mal genügt ein Leerzeichen, mal nicht … Mach einfach Enter und fertig.
Poste bei Gelegenheit mal den Output von env (am besten mit der Codefragment-Darstellung; der Button mit dem Gatterzeichen # ).
Sorry, das verstehe ich nicht. Meinst Du: "env # gs"? Oder "env gs #"? Da stoßen meine Unix-Kenntnisse schon wieder an ihre Grenzen...
Ups, weg vom Terminal ;)
Du sollst nur (1) im Terminal env eingeben und die Ausgabe hier im Forum posten, und zwar (2) formatiert als Code: wenn du einen Beitrag schreibst, gibt es doch die bunten Buttons über dem Texteingabefeld (oder benutzt du einen Textbrowser???); einer davon ist mit dem Gatterzeichen (#) versehen und nennt sich „Code einfügen“. Wenn du darauf klickst, wird an der aktuellen Cursorposition im Eingabefeld [code][/code] eingefügt; dahinein kopierst du die Terminalausgabe. Ich hab es einfach mal „Codefragment-Darstellung“ genannt; es schafft eine eigene Zitierumgebung, in der alles „wie eingegeben“ dargestellt wird – incl. Zeilenumbrüchen, auf die es uns ja ankommt.
Die wichtigste Information aus dem env-Ergebnis ist aber der Inhalt der PATH-Variable: Pfade werden von vorn nach hinten durchsucht. Wenn z.B. Pfade zu verschiedenen GS- oder Python-Executables gleichzeitig eingetragen sind, hört die Suche danach auf, sobald eine ausführbare Anwendung gefunden wurde. Es ist dann völlig egal, ob in einem anderen (nachfolgenden) Pfad eine gleichnamige und evtl. neuere Version vorhanden ist.
Und damit sind wir noch kurz bei den GS-Suchpfaden: die schauen schonmal gut aus! Die relevanten Pfade stehen ja vorn in der Liste, von daher wird mit den ersten Treffern gearbeitet, sofern Lily das für nötig hält. Ich frage mich trotzdem, weshalb Pfade zu /usr/lib/DPS oder /usr/openwin/* pauschal in die Anwendung kompiliert werden, selbst wenn dort nichts aufzufinden ist und deshalb keinen Schaden anrichten kann. Ich schau mir das auch mal in Windows an und frage notfalls die Entwickler.
Diese Nachricht (http://lists.gnu.org/archive/html/lilypond-user/2006-06/msg00522.html) der lilypond-user-Liste hatte mir Mut gemacht, die GS-Executable/Binary versuchsweise auszutauschen, aber das mochte nicht gelingen (trotz GS-Binary für Mac). Vielleicht war das vor 4 Jahren in einer Uralt-Lily-Version noch möglich.
[ups – falschen Button erwischt und grüßen vergessen]
Grüße, Robert
-
Lilypond läuft wieder etwas runder, was die ominösen Fehlermeldungen nach Cmd-R betrifft. Jetzt sind es wieder wie zu Anfang unserer "Unterhaltung" sieben Mal, bis es meckert.
Das sollte ruhig mal in der englischen Liste gepostet werden! Ich weiß nicht, wie lang Apple noch auf PPC baut (falls es daran läge), aber es sind gewiss genügend Maschinen damit im Umlauf.
Wenn du dabei Hilfe brauchst, vielleicht an James wenden (hat dort bereits einiges gepostet und arbeitet selbst am Mac) oder halt an mich (wär mal ein Anlass, dort mehr als zu lesen …).
-
hallo Robert,
danke für die ausführlichen Kommentare. Jetzt bin ich in manchem besser informiert. Wenn ich im Terminal einfach "env" eingebe, kriege ich das zurück:
de-spiegelkast:~ ich$ env
TERM_PROGRAM=Apple_Terminal
TERM=xterm-color
SHELL=/bin/bash
TERM_PROGRAM_VERSION=133-1
MOZILLA_FIVE_HOME=/Applications/Browser/Camino.app/Contents/MacOS
USER=ich
__CF_USER_TEXT_ENCODING=0x1F5:0:3
PATH=/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/3.1/bin:/usr/local/bin:~/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/texbin
PWD=/Users/ich
SHLVL=1
HOME=/Users/ich
LOGNAME=ich
LC_CTYPE=de_DE.UTF-8
SECURITYSESSIONID=41d090
_=/usr/bin/env
Ist das das, was Dich interessierte?
Und was das leicht hakende Lilypond-GUI betrifft, so kenne ich das schon von Anfang an, wenn ich zurückdenke. Wie alle Neulinge fängt man ja erst einmal mit der Grundausstattung an. Die Fehlermeldungen, die nach längerem Arbeiten und damit verbundener wiederholter Betätigung von Cmd-R kommen, habe ich nie so recht zu deuten gewußt. In der Lernsituation hat man auch erst mal andere Sorgen. Man konnte ja im Zweifelsfall Lilypond beenden und neu starten; dann hatte man wieder für eine Weile Ruhe. Vielleicht hat das ganze tatsächlich mit der PowerPC-Architektur zu tun, da ich die gleichen Probleme immer schon hatte. Ich bin bei Version 2.10.33 eingestiegen. Ich denke aber auch, daß noch eine Menge Macs dieser Bauart in Gebrauch sind und auch noch eine Weile in Gebrauch sein werden. Wer nicht immer das Allerneueste haben muß, kann mit diesen Rechnern noch lange arbeiten. Für Otto Normal-Mac-User reicht das völlig aus. Ich habe meist erst einen neuen gebrauchten Mac gekauft, wenn irgendwelche wichtigen Dinge, vor allem der Browser, zu oft Probleme gemacht haben. Vermutlich geht es anderen auch so. Natürlich nutze ich das Lilypad jetzt auch nicht mehr. Aber für den unerfahrenen Lilypond-Nutzer ist es schon ein ganz schönes Stück Arbeit, sich eine komfortablere Umgebung zu organisieren. Ich gebe Dir völlig recht, daß es nicht nur hier im Forum, sondern auch auf der Lilypond-Seite selber deutliche Hinweise und Anleitungen geben sollte, wie man diesem Manko abhilft. Ich habe schon mit vielen Finale- und Sibelius-Anwendern über Lilypond diskutiert. Alle fanden die Noten viel schöner, die Lilypond erzeugt, bemängelten aber die allzu gewöhnungsbedürftige Bedienung. Nur wenige fanden es der Mühe wert, wegen des besseren Outputs sich wirklich eingehender damit zu beschäftigen. Die meisten Kollegen, die Noten schreiben, sind außerdem zu ungeduldig. Und auch die Tatsache, daß Lilypond kostenlos ist, war kein ausreichender Anreiz. Für Komfort zahlen die Leute offenbar gern viel Geld.
Mein eigener Einstieg in Lilypond war dadurch motiviert, daß ich bis dahin sehr viel und gerne Noten mit der Hand abgeschrieben habe. Ich habe mich außerdem als Berufsmusiker oft genug über die vielen mehr oder weniger unzulänglichen am Computer "professionell" erstellten Ausgaben geärgert. Da ich viel mit Alter Musik und den teilweise fantastischen Druckausgaben des 18. und 19. Jahrhunderts zu tun hatte, weiß ich genau, wie schön, gut lesbar, aber auch wie praxisnah ein Notensatz sein kann. Ich hatte mir eigentlich geschworen, niemals Noten am Computer zu schreiben, bis ich eines Tages auf Lilypond gestoßen bin. Das hat mir vor Augen geführt, daß so etwas am Rechner also auch möglich ist. Und da Notensatz ja ohnehin eine komplexe Angelegenheit ist, hatte ich auch kein Problem damit, daß man erst einmal eine Menge lernen muß, bevor man etwas Ordentliches zustandebringt.
Jetzt bin ich etwas abgeschweift... Sag mir bei Gelegenheit mal, was Du aus der Terminal-Ausgabe bei mir herauslesen kannst.
herzlichen Gruß
-
hallo Robert,
ich habe eine ganze Zeit lang nichts von Dir gehört zu meinem Beitrag. Vielleicht hast Du auch nur zu viel anderes um die Ohren im Moment, um hier posten zu können - soll bei Musikern ja schon mal vorkommen ;)
Melde Dich doch bitte nochmal, wenn Du wieder Zeit hast.
herzlichen Gruss
-
Hallo juppes!
Vielleicht hast Du auch nur zu viel anderes um die Ohren im Moment, um hier posten zu können - soll bei Musikern ja schon mal vorkommen ;)
Na ja, geht so ;) ZU viel ist es nicht, aber ausreichend …
Und was das leicht hakende Lilypond-GUI betrifft, …
… wird das Problem eher bei unixoiden Betriebssystemen rapportiert. Entweder ist der Windows-Nutzeranteil gegenüber Unix-/Linux-/Mac-Systemen derart gering, dass bisher niemand (zumindest im deutschen LP-Forum) ein solches Problem hatte – oder die Win32-Oberfläche ist tatsächlich stabiler, auch wenn sie ähnlich spartanisch daherkommt. Wie gesagt: die Entwickler wissen darum, Lily mit einem ansehnlicheren Editor auszuliefern, um insbesondere Windows-LilyPond-Newbies von Anfang an besser überzeugen zu können. Alles, was du beschreibst, entspricht auch meiner persönlichen Erfahrung – mit mir selbst und mit anderen ;) Es gibt halt eine große Nutzergruppe, die das Ergebnis sehr bestaunt, aber sich selbst nicht in der Lage sieht, selbiges reproduzieren zu können; sei es aus mentaler Blockade wegen des Eingabeverfahrens oder mangelnder Geduld bzw. anfänglich eher kleinen Fortschritten (beides nachvollziehbar). Hier geht es Musikern wie Leuten: „Ich bin kein Informatiker. Es soll doch einfach nur funktionieren!“ Das „einfach-so-funktionierende“ kostet nunmal Geld, da sich im Vorfeld viele andere Leute Gedanken machen müssen, was genau denn einfach so funktionieren könnte – und die wollen dafür natürlich bezahlt werden. Ein Profimusiker lässt sich ja auch dafür bezahlen, dass er „einfach so funktionierend“ in’s Horn stößt, in die Tasten haut oder in die Saiten greift und als Sänger den „richtigen Ton“ trifft – alles mit etlichen Jahren vorangehender Übung und abgeschlossenem Hochschulstudium! (Liebe Berufsmusiker: die musikalische Ausbildung schließe ich hier ein; selbstverständlich geht es nicht nur um Technik. Und liebe Veranstalter: berücksichtigen Sie dies bitte künftig bei Ihrer Honorarvorstellung.)
Kurzum: Ich kann es niemandem verleiden, Geld für (Bedienungs-)Komfort auszugeben, wenn das Resultat überwiegend der Erwartung entspricht, auch wenn ich selbst weiß, dass zum Nulltarif ein bedeutend besseres Ergebnis mit einem gewissen Maß an Eigenleistung erzielbar ist. Klingt ein wenig nach Häuslebaue, gebe ich zu :D Ich persönlich wünsche mir ja auch etwas mehr „Eigenleistung“ bzw. Forscherdrang oder Bastelwut! Open source bedeutet keineswegs, alles immer nur per Texteingabe zu bewerkstelligen. Für Lily gibt es WYSIWYG-Editoren, die einem die Tipparbeit ersparen und trotzdem vollständige Code-Kontrolle gewährleisten. Leider ist „Code“ seit Windows völlig „out“. Und was Bedienkomfort in Windows XYZ angeht, muss man sich auch ernsthaft fragen, was MS denn bloß denkt, was der Anwender denken könnte …
Ich habe mich außerdem als Berufsmusiker oft genug über die vielen mehr oder weniger unzulänglichen am Computer "professionell" erstellten Ausgaben geärgert.
Dito. In genau diese Kerbe hauen ja die Entwickler :) Mit 99,5%iger Wahrscheinlichkeit ist Computernotensatz spätestens auf den zweiten Blick nach wie vor erkennbar. Zugegebenermaßen fallen Lily-Notensätze (genau wie LaTeX-Dokumente) ebenso in’s Auge, aber nicht, weil sie wie andere etwa blass, mechanisch, nüchtern, mager oder zu scharf erscheinen, sondern weil der Unterschied zu etablierten computergenerierten Dokumentformaten kommerzieller Hersteller ein deutlich wohltuenderer ist. Ich betrachte wohlwollend, dass z.B. bei Haus-/Magister-/Diplomarbeiten (wenn auch erst in höheren Semestern) zunehmend Wert auf gediegene, leserfreundliche Gestaltung Wert gelegt wird und Satzsysteme wie LaTeX (im MuWi-Bereich eben LilyPond) Beachtung finden. Wer einmal Blut geleckt hat, der wird (La)TeX so schnell nicht missen wollen. Es ist wünschenswert, dass dies auch schnell mit Lily passiert. Die Integration von Lily-Code in LaTeX (oder doch eher umgekehrt) hat mit der Einführung von lilypond-book und der Abkehr von MusicTeX einen Quantensprung erfahren, auf dessen erreichtem Niveau es weiterzumachen gilt. Unabdingbar ist deshalb eine saubere Portierung auch auf Windows-Maschinen und ein noch reibungsloseres Zusammenspiel von Lily und TeX.
Da ich viel mit Alter Musik und den teilweise fantastischen Druckausgaben des 18. und 19. Jahrhunderts zu tun hatte, weiß ich genau, wie schön, gut lesbar, aber auch wie praxisnah ein Notensatz sein kann.
Dazu relativ kurz ein paar Anmerkungen, da ich mich des öfteren schon darüber geäußert habe: Es mangelt einfach am Erkennen und Analysieren, warum das eine besser als das andere aussieht. Kein Notensatzprogramm – noch nicht einmal Lily – kann uns alle Arbeit abnehmen. Die Standardeinstellungen in Lily sind recht gut, der Font für Notenelemente ist wirklich geglückt und außergewöhnlich. Die Hausschrift Century School halte ich für überarbeitungsbedürftig – eher die Proportionen als die Schrift an sich. Die Randeinstellungen sind katastrophal. Die Seitenaufteilung geht so. Bei allem kann man sich sehr viel bei TeX abgucken. Trotzdem darf man sich nicht darauf verlassen, dass Maschinen uns die Gedanken lesen und deswegen erstklassigen Output produzieren. Ich „spicke“ immer in klassischen Notenstichen und rücke Elemente so lang hin und her, bis ich die geeignetste Stelle gefunden habe – die beste Kontrolle ist immer noch das eigene Auge. Ich habe wenig Verständnis für „das war ich nicht, das hat Programm XYZ so gemacht …“ Beherrschen wir diese Maschinen/Software oder die uns? Ich meine damit nicht, dass jederman in der Lage sein muss, ein eigenes Programm zu schreiben (das kann auch ich nicht), aber ich darf betonen, dass wir zu vieles als gegeben nehmen, wo doch ausreichend Manipulationsmöglichkeiten des Programmablaufs vorhanden sind.
Ich hatte mir eigentlich geschworen, niemals Noten am Computer zu schreiben, bis ich eines Tages auf Lilypond gestoßen bin. Das hat mir vor Augen geführt, daß so etwas am Rechner also auch möglich ist.
Möglich ja, aber dann auch schön :) Ich war schon immer begeistert von dieser Möglichkeit, weil ich häufig schlecht kopierte (die 10. Kopie von der 100.) oder durch mitkopierte Eintragungen versaute oder vergilbte handschriftliche Noten hatte. Selbst ein kleines, beschränktes Satzprogramm wie Capella im letzten Jahrtausend eröffnete eine völlig neue Dimension. Damit habe ich meine ersten Gehversuche gemacht, um heute darüber lächeln zu können und alles Wissen in Lily zu verarbeiten ;D
Und da Notensatz ja ohnehin eine komplexe Angelegenheit ist, hatte ich auch kein Problem damit, daß man erst einmal eine Menge lernen muß, bevor man etwas Ordentliches zustandebringt.
So isses. Eine Fremdsprache lernt man auch nicht über Nacht … Neben Vokabeln und Grammatik gibt es ja auch noch Interpunktion und ähnlich fiese Dinge ::)
Sag mir bei Gelegenheit mal, was Du aus der Terminal-Ausgabe bei mir herauslesen kannst.
Ist es heute noch dieselbe Ausgabe? Dann kann ich zumindest herauslesen, dass in der PATH-Variablen kein Pfad zu /Applications/LilyPondXYZ auftaucht und die Environment-Variable GS_LIB nirgends auftaucht, um gezielt eine bestimmte GS-Version anzusprechen. Waren wir nicht schon mal so weit? Gibt es eigentlich noch ein akutes Problem mit Lily?
Beste Grüße, Robert
-
hallo Robert,
schön, nach so langer Zeit wieder ein Lebenszeichen von Dir zu bekommen! Ich kann Dir nur in allem zustimmen, was Du sagst. Unsere Erfahrungen gleichen sich da sehr, auch wenn ich im Vergleich zu Dir ein Notenschreib-Neuling am Computer bin. Jedesmal, wenn ich etwas schreibe, lerne ich etwas dazu, auch wenn ich nicht immer aus eigener Kraft die Lösung für ein Problem finde, aber doch meistens. Die Dokumentation ist eigentlich sehr umfassend. Man muß sich eben nur die Mühe machen, sie auch zu lesen. Habe sie mir sogar ausgedruckt und binden lassen...
Der technische Unterbau, wenn er denn hakt, bringt mich jedenfalls öfter ins Grübeln. Habe mich mal ein bißchen mehr mit Unix befaßt in der Zwischenzeit, aber auch das ist ein Studium, das sich nicht mal eben in ein paar Stündchen erledigen läßt. Aber wenigstens sind mir jetzt ein paar Grundzüge klarer geworden.
Nun zurück zu meinem Problem: gebe ich env ein, dann passiert noch immer das gleiche wie damals. Habe seitdem nicht mehr unter die Haube geschaut.
de-spiegelkast:~ ich$ env
TERM_PROGRAM=Apple_Terminal
TERM=xterm-color
SHELL=/bin/bash
GS_LIB=/usr/local/share/ghostscript/8.70/Resource/Init:/usr/local/share/ghostscript/8.70/lib:/usr/local/share/ghostscript/8.70/Resource/Font:/usr/local/share/ghostscript/fonts:/Users/ich/Library/Fonts
TERM_PROGRAM_VERSION=133-1
USER=ich
__CF_USER_TEXT_ENCODING=0x1F5:0:3
PATH=/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/3.1/bin:/usr/local/bin:~/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/texbin
PWD=/Users/ich
SHLVL=1
HOME=/Users/ich
LOGNAME=ich
LC_CTYPE=de_DE.UTF-8
SECURITYSESSIONID=59ccf0
_=/usr/bin/env
Da ich wie Du eine TeXShop-Umgebung verwende, die zum Glück zum Schreiben problemlos läuft, habe ich nicht genügend Leidensdruck. Cmd-T kann ich dort betätigen, so oft ich will. Komische Fehlermeldungen kommen nur dann, wenn ich zu viele Programme gleichzeitig geöffnet habe. Dann scheint der Arbeitsspeicher nicht mehr auszureichen. Beende ich ein oder zwei Programme, geht alles wieder.
Dort geht allerdings convert-ly auch nicht, genau wie in Lilypond. Das glaubt, ich hätte nicht die richtige Python-Version installiert, was aber einfach nicht stimmt. Offenbar ist da auch wieder nicht der richtige Pfad eingetragen... Bei einer normalen Installation per Installer müßte das doch miterledigt werden, oder? Dafür sind die Dinger doch da, daß alles "schlüsselfertig" eingerichtet wird.
Die Konsolenmeldung in TeXShop lautet:
Python 2.4 or newer is required to run this program.
Please upgrade Python from http://python.org/download/, and if you use MacOS X,
please read 'Setup for MacOS X' in Application Usage.
Dabei habe ich Python 2.6 auf meinem Rechner!
Heute hatte ich den Gedanken, daß vielleicht zu viele Konfigurationsdateien in meinem Benutzerverzeichnis ein Chaos anrichten. Dort liegen inzwischen:
.bash_history, .bash_profile, .profile, .nanorc, .screenrc., .bash_profile.pysave, nanorc.save
Wenn ich das richtig verstanden habe, kann man in .bash_profile alle möglichen Terminal-Einstellungen festlegen. Vielleicht könnte man da ja auch mal alle Pfade wie der zu Python, zur Lilypond.app, die Lilypond so braucht, mit hineinschreiben, um das mal an einer Stelle zu haben. Wäre das eine gute Idee?
herzlichen Gruß
-
Wie ist denn die erste Zeile in convert-ly? Ersetze diese mal durch
#!/Library/Frameworks/Python.framework/Versions/2.6/bin/python
Grüße, Robert
-
lieber Robert,
herzlichen Glückwunsch! Volltreffer! Tooor!
Dabei ist mir auch wieder eingefallen, daß ich seinerzeit das convert-ly von Lilypond 2.12.2 in ähnlicher Weise geändert habe, weil die von Haus aus mitgelieferte Fassung nicht funktionierte. Man vergißt das dann irgendwann wieder, weil das Problem abgehakt ist und weil ab und zu eine längere Zeit ohne Notenschreiben ins Land gegangen ist.
convert-ly brauche ich zwar im Moment nicht oft, aber ab und an lade ich auch mal bei Mutopia etwas herunter, und da sind oft .ly-Dateien, die mit Uralt-Versionen von Lilypond erstellt wurden.
#!/usr/bin/env python#! scheint also zum Beispiel unter Linux der Python-Ort zu sein, nicht wahr? Dann kann es ja unter Mac OS X nicht gehen. Das "Geheimnis" ist also, zu wissen, wo man bestimmte Pfade eintragen muß - ein ganz simples Prinzip.
ganz herzlichen Dank und einen geruhsamen Abend
-
Mit #!/usr/bin/env python dürfte convert-ly im Terminal funktionieren, aber TeXShop kommt damit irgendwie nicht klar. Die Zeile teilt dem Python-Script lediglich mit, wo es die benötigte Python-Anwendung findet. #!/usr/bin/env python ist also dasselbe wie die bloße Eingabe von python im Terminalfenster. Voraussetzung ist natürlich, dass der Pfad zu Python in der Environment-Variable path eingetragen ist. Es geht ja nur darum, nicht immer die kompletten Pfadangaben eintippen zu müssen. Die convert-ly.engine würde auch folgendermaßen laufen (ohne #!/usr/bin/env python o.ä. im Script):
#!/bin/tcsh
exec /Library/Frameworks/Python.framework/Versions/2.6/bin/python /Applications/Lilypond.app/Contents/Resources/bin/convert-ly -e "$1"
Wie du unschwer erkennen kannst, werden hier mit absoluten Pfadangaben zuerst Python gestartet und dann convert-ly mit der aktuell in TeXShop geöffneten Datei aufgerufen. Die erste Zeile in convert-ly.engine (#!/bin/tcsh) teilt der Engine mit, welche Shell benutzt werden soll (in diesem Fall die TENEX C Shell), um die nachfolgenden Befehle interpretieren zu können. Es würde auch mit der Standard-Shell (bash) funktionieren, dann müsste die convert-ly.engine folgenden Inhalt haben:
#!/bin/bash
/Library/Frameworks/Python.framework/Versions/2.6/bin/python /Applications/Lilypond.app/Contents/Resources/bin/convert-ly -e "$1"
Beste Grüße, Robert
-
Voraussetzung ist natürlich, dass der Pfad zu Python in der Environment-Variable path eingetragen ist.
Und wo trage ich das ein? In ~/.profile oder ~/.bash_profile? Wäre schon toll, wenn auch die Shell und auch alles andere immer gleich Bescheid wüßte, wo Python ist, so daß es dann egal wäre, ob ich im Terminal arbeite oder eben in TeXShop oder in Lilypond direkt.
-
Hallo juppes!
Und wo trage ich das ein? In ~/.profile oder ~/.bash_profile?
In ~/.profile stehen die spezifischen Umgebungsvariablen für den jeweils angemeldeten Nutzer (das, was man nach Eingabe von env angezeigt bekommt; env = environment = Umgebung). Pfade also hier eintragen.
In ~/.bash_profile kann man das Verhalten der Bash (Bourne-again shell) beeinflussen, z.B. Reaktion auf bestimmte Nutzereingaben, Codeeinfärbung/Syntaxhighlighting usw. Die Bash ist die Standard-Shell in Mac OS X.
Es gibt auch andere Shells, die anderslautende Befehle und anders aufgebaute Syntax erwarten, z.B. die TENEX C Shell (tcsh), für welche die lilypond-Engines geschrieben wurden. Zu Beginn eines Scripts muss daher angegeben werden, welcher Interpreter angesprochen werden soll. Diese erste Zeile wird mit #! begonnen, gefolgt vom Systempfad, z.B. #!/bin/bash (auch DOS unter Windows-Systemen ist eine Shell, aber dort gibt es ohne weiteres Zutun nur diese eine). Ein sichtbarer Unterschied zwischen bash und tcsh ist z.B. die explizite Anweisung in der tcsh, etwas auszuführen (exec), was die bash nicht benötigt.
Wäre schon toll, wenn auch die Shell und auch alles andere immer gleich Bescheid wüßte, wo Python ist, so daß es dann egal wäre, ob ich im Terminal arbeite oder eben in TeXShop oder in Lilypond direkt.
An diesem Punkt teilen sich leider die Wege.
(1) Terminal (oder auch Konsole, Eingabeaufforderung, Prompt etc.) und Shell
Laut deiner aktuellen Ausgabe durch env weiß dein System bereits, wo überall sich Python befindet – falsch: dein System weiß, wo es danach suchen soll, nämlich in den Pfaden, die in der Variablen PATH eingetragen sind. Die Verzeichnisse, die dort angegeben sind, werden von vorn nach hinten solange durchsucht, bis die gewünschte Anwendung gefunden wurde; die Suche wird sobald abgebrochen und die Anwendung ausgeführt. In deiner PATH-Variablen steht an erster Stelle der Pfad zu Python 2.6 (/Library/Frameworks/Python.framework/Versions/2.6/bin), gleich darauf der Pfad zu Python 3.1 (/Library/Frameworks/Python.framework/Versions/3.1/bin). Gibt sich nun das aufgerufene Python-Script mit der ersten Version zufrieden, besteht keine Notwendigkeit zum Weitersuchen, und das Script wird ausgeführt. Verlangt ein Script eine höhere Version, wird PATH weiter durchsucht, ob eine höhere Version gefunden werden kann. Bei Erfolg wird das Script ausgeführt. Andererseits bricht das System mit einer Fehlermeldung ab. Dein unverändertes convert-ly (mit der ersten Zeile #!/usr/bin/env python) muss im Terminal also funktionieren! Das einzige Problem dabei kann jetzt nur sein, dass convert-ly selbst nicht gefunden wird, weil die Pfadangabe zum Lilypond-Container fehlt. Aber das ist einfach und hatten wir bereits: convert-ly liegt genau wie lilypond und lilypond-book in /Applications/LilyPond.app/Contents/Resources/bin, und dieser Pfad muss PATH hinzugefügt werden (wie bei GS_LIB). Also wieder Terminal starten, und los geht’s:cd
nano .profileund an’s Ende der Datei folgenden Zweizeiler einfügen:# Pfad zu LilyPond 2.12.3
export PATH="$PATH:/Applications/LilyPond.app/Contents/Resources/bin"Nach Abspeichern und Aus-/Einloggen sind convert-ly und auch lilypond und lilypond-book direkt im Terminal ohne Umwege aufrufbar. Du kannst es ausprobieren, indem du in ein beliebiges Verzeichnis mit .ly-Dateien wechselst und dort eine .ly-Datei mit convert-ly aufrufst. Ein Beispiel: kopiere deine GraafDuoEconomique.ly (aus deinem anderen Thread) auf den Schreibtisch und benenne sie meinetwegen in test.ly um. Im Terminal wechselst du nun dorthin und lässt sie mit convert-ly durchlaufen:cd
cd Desktop/
convert-ly test.lyBei Erfolg sollte im mindesten folgendes in’s Terminalfenster geschrieben werden:
convert-ly (GNU LilyPond) 2.12.3
Processing `test.ly'...
Applying conversion:
(2) TeXShop und die TeXShop-Engines
Es ist mir wirklich schleierhaft, warum TeXShop den Systemunterbau ignoriert. Ich habe jetzt wirklich vieles ausprobiert und versucht zu verstehen, und es ziert sich nach wie vor wie die Zicke am Strick … Aber gut, es hat sein Für und Wider – bringen wir der TeXShop-Engine convert-ly.engine die Pfade eben auch bei! Wie einfach das ist, hatten wir vor gefühlten 25.000 Zeilen in diesem Thread schon einmal, aber es genügt tatsächlich der Zweizeiler aus meiner vorangehenden Antwort (unter Verwendung der tcsh):
#!/bin/tcsh
exec /Library/Frameworks/Python.framework/Versions/2.6/bin/python /Applications/Lilypond.app/Contents/Resources/bin/convert-ly -e "$1"
Das Problem ist halt, dass convert-ly eben nur ein Script ist, das von einem Programm abgearbeitet werden muss. In der ersten Script-Zeile in convert-ly wird System-Python zwar aufgerufen, aber das wird irgendwie nicht an TeXShop zurückgegeben. Daran wird’s unterm Strich scheitern.
Im Prinzip muss man nur im Hinterkopf behalten, dass TeXShop möglicherweise bewusst unabhängig manche Umgebungsvariablen ignoriert – und genau das ist unser Vorteil beim Stricken von neuen TeXShop-Engines! Ich hatte ja früher schon erwähnt, dass ich verschiedene Engines für die aktuell stabile Version, die jeweils aktuelle Entwicklerversion und auch für lilypond-book (bzw. lilypond-latex) und convert-ly habe. Wenn schon TeXShop das nicht anders kapiert, machen wir uns das doch zunutze ;)
Fazit
- convert-ly kann so bleiben, wie es ist, solang die Pfade zu Python und Lilypond in der Environment-Variable PATH zur Verfügung gestellt werden.
- TeXShop-Engines müssen sicherheitshalber die (absoluten) Pfadangaben noch einmal enthalten, damit es reibungslos funktioniert.
- Kein Programm sucht von allein die ganze Festplatte ab. (Das könnte mittlerweile auch ganz schön lange dauern …)
- TeXShop ist nicht das Terminal!
- Die verantwortliche Datei für den angemeldeten Nutzer ist ~/.profile
Das „direkt in Lilypond“ hab ich mal wieder bewusst ausgelassen … Es macht ja auch keinen Spaß, in einem langweiligen monochrom-Texteditor zu arbeiten ;) Bei deiner Systemkonfiguration und der für TeXShop kann ich dir helfen, aber den buggy Lilypond-Editor kann ich beim besten Willen nicht patchen. Natürlich ist es doof, wenn eine App nicht so spurt, wie wir das möchten, aber das kennen wir ja schon von woanders her. Für diese Fälle gibt’s eben solche Foren wie dieses hier! (Stell dir nur vor, du hättest für Lily bezahlt und hingest daraufhin Woche für Woche in einer teuren Supportline.)
Falls dir die Idee in diesem Thread (https://liarchiv.joonet.de/index.php?topic=718.msg3927#msg3927) zusagt, schreib doch einfach was dazu.
Beste Grüße, Robert
-
hallo Robert,
danke, das ist klar und deutlich! Ich werde mir das mal in Ruhe zu Gemüte führen und ggf. das eine oder andere in die diversen Dateien eintragen.
herzlichen Gruß