Homophone Akkorde (GELÖST)

[ingmar]

I
Folgender Code besteht aus einer Melodie- und einer Akkordstimme:

Code: [Auswählen]

\version "2.18.2"
\language "english"

M = \relative c' {
d8 d f g a4 f'4.
e8 d d cs2
}

N = \relative c {
<< d4. f a >> << g8 bf d >> d2
a'4 d, a'2
}

\score { \new StaffGroup <<
\new Staff { \M }
\new Staff { \clef "bass"  \N }
>> }
Seltsamerweise werden die Achtel im zweiten Akkord der Unterstimme als Sechzehntel dargestellt. Sieht für mich so aus, als würden mehrere Achtelfähnchen vertikal verschoben übereinandergedruckt.

Es gibt auch eine mir reichlich unverständliche Fehlermeldung: "Warnung: zu viele kollidierende Notenspalten werden ignoriert".

II
Nun aber: Wir ersetzen die Versionsangabe durch \version "2.19.37".

Nun sind die Akkorde aus horizontal leicht verschobenen Einzelnoten zusammengesetzt! Und die Fehlermeldung hat sich geändert, sie lautet jetzt: Warnung: dieser Stimmen-Kontext braucht \voiceXx oder \shiftXx Einstellungen

III
Interessehalber gehen wir nochmal auf "version 2.18.2" zurück und lassen convert-ly darüberlaufen. Vielleicht kann das den Code irgendwie zurechtzupfen?

Leider nein! Auch convert-ly ist nicht bewusst, dass sich da was geändert hat. Offenbar wird der gleiche Code in zwei Versionen deutlich verschieden interpretiert.

Was ich mir vorstelle: Die Stimme hat ganz homophone Akkorde, die Töne sollten einfach an einem Hals hängen.

Woran liegt das, ist es dokumentiert, und was sollte ich tun?


Danke, und Gruß,
--ingmar

[ingmar]

Habs schon gefunden: Ich muss eigentlich nur \oneVoice in die Klammer der zweiten Stimme schreiben, dann scheints zu gehen. Aber mir ist nicht klar, warum das nötig ist - kann da jemand den Hintergrund ein wenig beleuchten?

Danke,
--ingmar

[fugenkomponist]

Das hat mit indirekten Konsequenzen von \oneVoice zu tun: << x y z >> probiert erstmal, so viel wie möglich in einen gemeinsamen Kontext zu packen; aber das ist so halb-automagisch*, z. B. werden, wenn man das nicht explizit angibt, manchmal mehr Staffs als nötig erzeugt, wenn mit diesem Ausdruck mehrere Stimmen zusammengesetzt werden. Oder wie hier mehr Voices als nötig. \new/\context Voice/Staff sorgt z. B. dafür, dass explizit Kontexte erstellt werden. Und \oneVoice erzeugt anscheinend über den Umweg context-spec-music auch einen expliziten Kontext, wenn ich den Code in ly/property-init.ly (für oneVoice) und scm/music-functions.scm (für context-spec-music) richtig verstehe. Du kannst also dir statt mit \oneVoice offensichtlicher mit einem \new Voice um den \relative-Ausdruck behelfen. Oder nach dem \new Staff, dann gehört der \clef auch noch dazu

* Ich hab da wirklich wenig Ahnung von, sorry. Für mich ist es nicht immer vorhersagbar, was für Kontexte jetzt kreiert werden. Vermutlich ist schon klar definiert, unter welchen Voraussetzungen wie viele und welche Kontexte erstellt werden …

[harm6]

Hallo ingmar,

fugenkomponist hat eigentlich schon alles gesagt. Hier noch mal meine Ausführungen zum Thema, die das Ganze noch illustrieren sollen.

Die Ursache liegt in der << ... >> -Konstruktion.
Im Gegensatz zu dem was Du zu glauben scheinst, handelt es sich nicht um einen Akkord ('EventChord), sondern um 'SimultaneousMusic.
Diese 'SimultaneousMusic wird verschieden interpretiert je nachdem in welchem Context sie auftaucht. Falls nichts angegeben wird, dann ist jedes Element aus << ... >> eine eigene Stimme (Voice).

Kompilier mal (ohne jeden Zusatz):

Code: [Auswählen]

\version "2.18.2"

<< c' e' g' >>
Und Du wirst einen score mit drei Staffs sehen!

Wenn Du es in einen Staff packst,

Code: [Auswählen]

\version "2.18.2"

\new Staff << c'8 e' g' >>

entsteht ein Staff mit drei Voices ohne jegliche Kollisionsvermeidung, d.h. die Noten werden übereinander gedruckt. Weches zu dem von Dir beobachteten Output führt.
Deshalb die Warnungen. In neueren Versionen ist der Text der Warnung verändert worden, um einen Hinweis auf die Lösung zu geben. Auch wenn der Hinweis hier nicht besonders weiterhilft. Er führt zu folgendem Code, der aber gerade nicht das ist, was Du willst.

Code: [Auswählen]

\version "2.18.2"

\new Staff
  <<
    \new Voice { \voiceTwo c'8 }
    \new Voice {  \voiceFour \override NoteColumn.force-hshift = -1 e' }  % \voiceFour reicht allein nicht aus
    \new Voice { \voiceOne g' }
  >>
Es ist halt eine automatische Warnung, die ihr bestes versucht ...

Insoweit stelle sicher, das alles in eine Voice kommt. Mittels \oneVoice oder explizitem Voice-context:

Code: [Auswählen]

\version "2.18.2"

\new Voice << c'8 e' g' >>

{ \oneVoice << c'8 e' g' >> }


Neuere Versionen versuchen besseren output aus dem zu machen, was eingegeben wurde und das ist hier nunmal 'SimoultaneousMusic und keine Akkorde. Auch wenn Du alles in eine Voice packst ist es immer noch kein 'EventChord sieht nur so aus ...
'SimoultaneousMusic auf Voice-Ebene hat Fallstricke!

Ansonsten interpretieren verschiedene LilyPond-Versionen den input verschieden. Wie könnte es anders sein? LilyPond wird ja weiterentwickelt.
convert-ly verändert Dein input-file nur dann, falls die input-syntax verändert werden muß und (natürlich) falls es eine convert-rule für den konkreten Fall auch gibt.

Doku hier:
http://lilypond.org/doc/v2.18/Documentation/learning/music-expressions-explained.de.html

Da wird aber auch gesagt, daß 'SimoultaneousMusic vorzugsweise dazu dient polyphone Musik zu setzen.
Aber die Anwendung auf homophone sollte jetzt klarer ein.


Gruß,
  Harm

[ingmar]

Danke, das klärt einiges, auch wenn ich das volle Verständnis, wann nun genau eine Voice erzeugt wird, wohl erst mit mehr Erfahrung kriegen werde. Offenbar macht es übrigens auch gar nichts, ob ich meine Akkorde mit <<...>> oder <...> anlege. Ich komme aber nun ganz gut klar.

Gruß,
--ingmar

[harm6]

Offenbar macht es übrigens auch gar nichts, ob ich meine Akkorde mit <<...>> oder <...> anlege.

Wie schon gesagt, <<...>> gibt keine 'EventChords aus.
Insbesondere falls Du das Ergebnis noch mit Musik-Funktionen, etc bearbeiten willst ist der Unterschied programmiertechnisch sehr bedeutsam!

Gruß,
  Harm