Neueste Beiträge

Seiten: 1 2 3 [4] 5 6 ... 10
31
Fragen zu Funktionen / Re: Abstände von Ankerpunkten in vertikaler Richtung finden
« Letzter Beitrag von xr am Freitag, 17. März 2017, 11:15 »
Um die Abstände der Ankerpunkte zu finden, habe jetzt folgenden Code:

#(define counter-va-lines 1)
#(define ht-va-distances (make-hash-table))

#(define (get-slur-extents layout pages)
;; This method has to be the first to be executed. It starts at the end
;; of the first compilation pass. Another pass is neccessary to use the calculated values.
;; It iterates over pages/system-lines/VerticalAlignment/VerticalAxisGroup.
;; Writes the distance between each VerticalAxisGroup
;; and the system baseline to the hash table ht-va-distances.
;; Key is the number of the system line, counted by
;; counter-va-lines
    (for-each (lambda (page)
        (for-each (lambda (line)
            (let* (
                (sys-grob (ly:prob-property line 'system-grob))
                )
                (if (not (equal? sys-grob '()))
                    (begin
                        (let* (
                            (vertAlign (ly:system::get-vertical-alignment sys-grob))
                            (va-groups (ly:grob-array->list (ly:grob-object  vertAlign 'elements)))
                            (tmp '())
                            )
                            (for-each
                             (lambda (group)
                                 ;; a VAGroup with no elements (e.g. no lyrics) will turn
                                 ;; to a spanner grob. As it has no properties, grob::name
                                 ;; returns false.
                                (if (grob::name group)
                                    ;; calculate relative position between
                                    ;; system baseline and VAGroup
                                    (set! tmp (append tmp (list
                                           (ly:grob-relative-coordinate group sys-grob Y))))
                                    (set! tmp (append tmp '(0 0)))
                                )
                             )
                             va-groups
                            )
                            (hash-set! ht-va-distances
                                         (number->string counter-va-lines)
                                         tmp)
                            (set! counter-va-lines (1+ counter-va-lines))
                        )
                    )
                )
            ))
            (ly:prob-property page 'lines)
        ))
        pages
    )
)

Eingebunden wird der Code mit:

\paper {   
    #(define (page-post-process layout pages)
        (get-slur-extents layout pages))
}

Dies ist jetzt ein Auszug aus dem kompletten Beispiel in dem anderen Thread, den ich schon angesprochen hatte.
Das komplette Beispiel findet sich hier:
https://github.com/XRoemer/Lilypond/tree/master/Custom_Slurs
Und hier können alle Dateien als zip. heruntergeladen werden:
https://github.com/XRoemer/Lilypond

Gruß,
Xaver
32
Allgemeine Diskussion / Re: Lilypond und MEI
« Letzter Beitrag von uli_1973 am Freitag, 17. März 2017, 08:55 »
Wieso ist die Lösung mit den Vorschlagsnoten schlecht? Da das Ziel meiner Arbeit die Übertragung in maschinenlesbaren Code und die Erstellung der modernen Notenschrift nur ein Nebenprodukt ist, kann man, denke ich, getrost auf einen kritischen Apparat einer Edition verzichten. Das wäre eine Arbeit alleine für sich schon, das würde den Rahmen auf jeden Fall sprengen. Um trotzdem alle Informationen unterzubringen, die wichtig sind, finde ich die Lösung annehmbar. Auch wenn sie nicht den Konventionen entspricht...

Das Problem daran ist nicht als solches, dass die Lösung nicht den Konventionen widerspricht, sondern dass sie einer ziemlich klar definierten Konvention zu folgen scheint. Jeder, der diese Noten lesen wird, wird sie als Vorschläge auffassen, auch wenn es im Text erläutert wird. Ich bin der Ansicht, dass abweichende Darstellungsformen unzweideutig sein und daher lieber ganz neue Formen verwenden sollten.

Die "üblichen" Formen, Alternativen darzustellen, wären z.B. Kleinstich oder gleich ein Ossia-Staff (was übrigens mit LilyPond mit überschaubarem Aufwand realisierbar sein sollte, also, dass eine kodierte Variante automatisch ein temporäres Staff erzeugt), Die "moderne" Variante, wäre das mit MEI=>Verovio im Browser anzuzeigen und per Mausklick zwischen verschiedenen Varianten zu wechseln - geht halt nicht in gedruckter Form.

Im allgemeinen informiere Dich über version-control-Systeme wie git, im besonderen über LilyPonds Möglichkeiten mit tags und annotations zu arbeiten.

Tags: http://lilypond.org/doc/v2.18/Documentation/notation/different-editions-from-one-source

Annotations: http://lilypondblog.org/2015/01/introducing-scholarly/ und https://github.com/openlilylib/scholarly

Das Letztere ist ein leider noch recht unbekanntes Paket, mit dem man den kompletten editorischen Workflow innerhalb des Partitur-Kontexts erledigen kann, so kann aus den Anmerkungen LaTeX-Code erzeugt werden, aus dem eine professioneller kritischer Bericht gesetzt werden kann. Inzwischen können Anmerkungen aber auch Fußnoten (in der Partitur) erzeugen und besonderes Highlighting anstoßen (also z.B. Herausgeberergänzungen durch Kleinstich/Klammern/Stricheln hervorheben). Geplant ist darüber hinaus etwa die Möglichkeit, Notenbeispiele in die Anmerkung zu schreiben -> und daraus könnte man z.B. eine Ossia-Variante entwickeln wie ich sie oben angedeutet habe.
33
Fragen zu Funktionen / Re: Abstände von Ankerpunkten in vertikaler Richtung finden
« Letzter Beitrag von harm6 am Donnerstag, 16. März 2017, 23:51 »
Zitat
Der Code geht mal wieder auf eine Anregung harms zurück
Zuviel der Ehre.

Tatsächlich wurde ich auf das Verfahren durch David Kastrup aufmersam gemacht, der es auf eine Anfrage meinerseits im Usage-Manual gefunden hatte. (Nicht diesen code, aber 'page-post-process')
Implementiert wurde es von Rainhold Kainhofer Jahre zuvor und war lange Zeit schlichtweg in Vergessenheit geraten.

Gruß,
  Harm
34
Fragen zu Funktionen / Re: Abstände von Ankerpunkten in vertikaler Richtung finden
« Letzter Beitrag von xr am Donnerstag, 16. März 2017, 20:26 »
Nachdem ich nun eine Weile und immer mal wieder mit der  minimum-translations-alist herumgespielt habe, ohne jedoch zu einer verläßlichen Lösung zu kommen, bin ich nun dazu übergegangen, die Lilyponddatei zweifach zu compilen. Beim ersten Mal werden die entsprechenden Werte ausgelesen, beim zweiten Mal dann eingesetzt.

Ausgelesen wird mit einer Funktion innerhalb einer Paper Umgebung, die erst angesprochen wird, wenn bereits alle Berechnungen abgeschlossen sind.
\paper {   
    #(define (page-post-process layout pages)
        (get-slur-extents layout pages ))
}

Der Code geht mal wieder auf eine Anregung harms zurück:
http://lilypond.1069038.n5.nabble.com/intercepting-implicit-explicit-page-breaks-td194196.html#a194198

Wenn ich mein Ziel erreicht habe und halbwegs kommentierte und geordnete Dateien erzeugt haben werde, poste ich meine Lösung in diesem Thread:
https://liarchiv.joonet.de/index.php?topic=2503.0

Xaver
35
Allgemeine Diskussion / Re: Lilypond und MEI
« Letzter Beitrag von Sterndeuter am Donnerstag, 16. März 2017, 16:01 »
Wiedo ist die Lösung mit den Vorschlagsnoten schlecht? Da das Ziel meiner Arbeit die Übertragung in maschinenlesbaren Code und die Erstellung der modernen Notenschrift nur ein Nebenprodukt ist, kann man, denke ich, getrost auf einen kritischen Apparat einer Edition verzichten. Das wäre eine Arbeit alleine für sich schon, das würde den Rahmen auf jeden Fall sprengen. Um trotzdem alle Informationen unterzubringen, die wichtig sind, finde ich die Lösung annehmbar. Auch wenn sie nicht den Konventionen entspricht...
36
Allgemeine Diskussion / Re: DANKE!
« Letzter Beitrag von fugenkomponist am Donnerstag, 16. März 2017, 12:15 »
Danke auch von mir. Vor allem harm und früher auch andere, nicht mehr aktive Nutzer dieses Forums haben mir oft geholfen (auch von den aktiven kommt jetzt immer mal wieder was, ich komm bloß glaub ich inzwischen einfach seltener mit eigenen Problemen an ;) ).

Es ist nicht gut, wenn nur wenige helfen können.

Das stimmt wohl. Ich möchte dazu mal ein paar Gedanken loswerden:
  • Dadurch, daß es die englische Mailingliste gibt, ist ein Teil der deutschsprachigen User aufgrund der größeren Community und Reichweite nur dort aktiv. Tatsächlich finde ich so ein Forum wie hier übersichtlicher von der Organisation und der Form der Posts und außerdem fällts mir doch leichter, ausführliche und korrekte Antworten in der Muttersprache zu verfassen, ich würds also nicht aufgeben. Durch ein Mitlesen auf der englischen Liste kriegt man aber von den üblichen Problemen, die immer wieder auftauchen, mehr mit und kennt dann schnell Ansätze und Lösungen.
  • Auch ich hab mal klein angefangen. Tatsächlich hab ich gerade festgestellt, daß ich zwar seit 2009 in diesem Forum angemeldet bin, aber über die Hälfte meiner knapp 1000 Posts in den letzten 20 Monaten geschrieben habe – damals (Juli 2015) hatte ich ein Problem, welches sich u. a. mithilfe der englischen Liste lösen ließ (falls es wen interessiert: hier der deutsche Forums- und hier der englische Listen-Thread). Ich hab die Lösung genommen, probiert zu verstehen und meinen eigenen Bedürfnissen anzupassen und habe dabei schon mal ordentlich was über Scheme und LilyPond gelernt.
  • Seitdem schau ich regelmäßig in Probleme anderer User rein, wo ich erstmal keine Ahnung von habe. Alles, was halbwegs interessant oder einfach zu lösen klingt, ist schon mal dabei, manchmal auch größere Brocken. Ich probiere dann, mithilfe der Dokumentation (Notation Reference, Internals Reference, Guile Reference Manual (Scheme), LilyPond Snippet Repository) eine Lösung zu finden und biete notfalls meine Gedanken oder eine Teillösung an, die andere (oder auch ich später) dann vervollständigen. Mit der Zeit kommt dann Übung: gewisse Ansätze braucht man immer wieder, man weiß, welche Grobs und welche properties wofür gut sind und wo in der Dokumentation (oder in alten Foren- und Mailinglisten-Threads) man was findet.
  • Wichtig: Wenn mir jemand hilft, probiere ich, den Code möglichst komplett nachzuvollziehen und für jede einzelne Code-Zeile zumindest ne ungefähre Ahnung zu bekommen, was sie tut. Nur ungefähr nachzuvollziehen ist zwar ein guter Anfang, hilft aber nur bedingt, wenn man selbst später solchen Code schreiben will ;)
Mit anderen Worten: Traut euch, zu helfen! Fangt ruhig klein an, aber schreckt nicht zurück vor Problemen, die erstmal ein bißchen groß erscheinen. Und bietet ruhig auch Teillösungen an, wenn ihr keine komplette hinkriegt. Konfuzius hat schon recht mit „Laß es mich selbst tun“ und so :)
37
Allgemeine Diskussion / Re: Lilypond und MEI
« Letzter Beitrag von harm6 am Donnerstag, 16. März 2017, 11:04 »
Zitat
Heugel hat selbst Töne korrigiert. Das stelle ich als Vorschlagsnoten dar, um möglichst viele Informationen aus der Quelle in der modernen Edition unterzubringen, ohne das Schriftbild zu sehr zu stören.
Hmm, das ist ein wenig überzeugender workaround (um es mal seeehr höflich zu formulieren. ;)

Im allgemeinen informiere Dich über version-control-Systeme wie git, im besonderen über LilyPonds Möglichkeiten mit tags und annotations zu arbeiten.

Eine zu compilierende Text-Datei ist genau das, was Du eigentlich brauchst, falls ich Dich richtig verstehe.
Insoweit fällt Finale schlichtweg als ugeeignet aus, imho.

Gruß,
  Harm
38
Allgemeine Diskussion / Re: Lilypond und MEI
« Letzter Beitrag von Sterndeuter am Donnerstag, 16. März 2017, 07:04 »
Nein, Finale kann das tatsächlich auch nicht, da hast du recht. Ich habe allerdings den Vorteil, dass es von meiner Quelle (eine Kasselaner Handschrift Johann Heugels) nur eine Version gibt, also kaum alternativen Schreibweisen. Das einzige: Heugel hat selbst Töne korrigiert. Das stelle ich als Vorschlagsnoten dar, um möglichst viele Informationen aus der Quelle in der modernen Edition unterzubringen, ohne das Schriftbild zu sehr zu stören.

Die Eindeutigkeit von Mensuralnotation lässt sich sicher diskutieren. Ich bin der Meinung, sie lässt sich durchaus eindeutig lesen, sieht man vielleicht von ein paar Spezialfällen ab. Je klarer die Handschrift, desto eindeutiger - und bei mir ist sie sehr klar ;) Die Regeln zur Übertragung sind ja bekannt, und alle Änderungen oder Abweichungen vom Notentext werden natürlich im Begleittext kenntlich gemacht. Oder meintest du das mit der Eindeutigkeit anders?
39
Allgemeine Diskussion / re: Lilypond und MEI
« Letzter Beitrag von ingmar am Mittwoch, 15. März 2017, 22:18 »
Zitat
@Ingmar: Verstehe ich das richtig, Lilypond ist nicht in der Lage, alternative Lesarten zu kodieren? Also wenn zum Beispiel in verschiedenen Überlieferungen Töne geändert sind, ist es nicht möglich, dies im Wuelltext zu vermerken? Dann stimme ich dir natürlich zu, für die Archivierung ist Lilypond dann nicht geeignet, das leuchtet ein. Gerade dieses Feature ist etwas, das ich an MEI sehr zu schätzen gelernt habe.
Das hatte Harms Uli oben schon richtig gestellt: Doch, Lilypond kann das. Ich habe das auch schon verwendet. Mein Gedanke war nur, dass die Mensuralnotation nicht diese Eindeutigkeit besitzt, die Lilypond verlangt, und dass das Ergebnis in Lilypond dadurch umgekehrt eine Eindeutigkeit vorgaukelt, die im Original nicht vorhanden war.

Finale dürfte in dieser Hinsicht aber nicht viel besser sein, oder?

Gruß,
--ingmar
 
Edit: Fehler korrigiert - sorry, Uli!
40
Allgemeine Diskussion / Re: Lilypond und MEI
« Letzter Beitrag von uli_1973 am Mittwoch, 15. März 2017, 18:00 »
@Ingmar: Verstehe ich das richtig, Lilypond ist nicht in der Lage, alternative Lesarten zu kodieren? Also wenn zum Beispiel in verschiedenen Überlieferungen Töne geändert sind, ist es nicht möglich, dies im Wuelltext zu vermerken? Dann stimme ich dir natürlich zu, für die Archivierung ist Lilypond dann nicht geeignet, das leuchtet ein. Gerade dieses Feature ist etwas, das ich an MEI sehr zu schätzen gelernt habe.

Nein, das stimmt so nicht. LilyPond hat das Konzept von "Tags" (http://lilypond.org/doc/v2.19/Documentation/notation/different-editions-from-one-source.html#using-tags), das dem "app"-Element von MEI nicht unähnlich ist. Es hat sich nur nicht so richtig durchgesetzt.

Mit einem "Kollegen" habe ich übrigens den Plan, ein kleines Werkzeug zu erstellen, das dieser Alternativen-Darstellung noch näher kommt. Das ist gar nicht sonderlich kompliziert, man muss sich nur genau über die Use-Cases und das Interface Gedanken machen.

@Urs: Es freut mich, dass du dich hier extra angemeldet hast, um mir diese Fragen zu beantworten. Die alte Notation ist für mich jedenfalls nicht so sehr das Problem, es ergeben sich meist mehr Fragen im Bezug auf die Kodierung.
Was genau meinst du mit Versionskontrolle?

Nun, ich habe nur meinen alten Account wiederbelebt ...

Versionskontrolle?


Ich finde es sehr schade, dass es so gar keine Tools zur Untersuchung des kodierten Materials in Lilypond gibt, aber das kommt vermutlich aus dem Ziel "Notensatz, nicht Archivierung". Humdrum habe ich ebenfalls schon versucht zu recherchieren, es schien mir aber, dass diese Sprache seit längerem nicht mehr erweitert wird (letzte Änderung am über Google gefundenen Guide ist aus den 90ern), sondern vielmehr von MuseData abgelöst wurde. (Übrigens führen selbst die Links auf der Seite musedata.org, die zum Humdrum Toolkit leiten sollen, bei mir zu "Seite nicht gefunden...)

Das mit Humdrum scheint so, ja. Es gibt aber durchaus eine Community und noch mindestens einen äußerst fähigen Entwickler, der sich darum kümmert. Beispielsweise hat er gerade einen Adapter geschrieben, um Humdrum-Dateien per MEI und Verovio rendern zu lassen (http://verovio.humdrum.org/?file=mozart/sonatas). Es gibt auch Pläne eines hum2ly-Konverters, und es wird ein großes Editions-Projekt des Chopin-Institus in Warschau geben, das nicht auf MEI, sondern auf Humdrum basieren wird.
Das Highlight an Humdrum ist eben die Verfügbarkeit der zahlreichen Analysewerkzeuge. Ein Gegenpunkt ist dabei, dass Humdrum ausschließlich am baren Inhalt (im Sinne von Tonhöhen und -dauern) interessiert ist, was für eine breit aufgestellte Kodierung m.E. etwas dürftig ist.
Seiten: 1 2 3 [4] 5 6 ... 10