Siehe bitte die Anlage...
Die 12 Takte von Beispiel 1 und 2 sind identisch.
In Bsp.1 wurden die Schlüsselwechsel in Takt 2 und 8 mit dem Schlüsselwerkzeug erzeugt.
In Bsp.2 wurden die Schlüsselwechsel mittels Notensystemstyle erzeugt. Dabei versagt (jedenfalls bei meinem System) die Musikausrichtung beim 2. Schlüssel.
Hab' ich etwas übersehen?
Versucht' bitte nicht die Melodie zu erkennen, sie stammt nämlich von Meister Zufall.
Gruß
Schlüsselwechsel mittels Notensystemstyle
Schlüsselwechsel mittels Notensystemstyle
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Finale 27 deutsch / WIN 10 64 / Intel i7 / 32 GB RAM / RME Multiface
Daß die Ausrichtung hier fehlerhaft ist, scheint eine Unzulänglichkeit zu sein, die die Programmierer übersehen haben. Da muß man sich denn wohl behelfen, indem man am Taktende zusätzlichen Platz einfügt. Nötig ist das zum Glück ja nur in den wenigen Fällen, wo man tatsächlich einen Notensystemstil benötigt, weil ein Spieler von einem transponierendem Instrument auf ein anderes wechselt. Nur wegen eines Schlüsselwechsels muß man ja nicht erst umständlich einen Notensystemstil definieren. Aus deiner recht sinnfreien Datei geht jedenfalls nicht so recht hervor, warum das hier nötig ist.
Geteilte Bratsche ist halbes Leid.
Windows XP - Finale 2005b - 2012a
Windows XP - Finale 2005b - 2012a
Schlüsselwechsel mittels Notensystemstyle
Dank an Tausig für die Überprüfung der Datei. Es ist doch ein Bug!
Das Experimentieren mit Schlüsselwechsel mittels Notensystemstyle entstand beim Versuch, zufriedenstellende Ergebnisse beim Erstellen von Stichnoten, die in der Partitur versteckt und in den Stimmen sichtbar sind und zusätzlich in der richtigen Oktave dargestellt werden, zu erreichen. Dabei ist mir dieser Bug bei der Ausrichtung aufgefallen.
Besonders stört mich auch, dass man nur mit Tricks einen Wechselschlüssel vor der "Eins" eines Taktes platzieren kann: der Wechselschlüssel wird immer zum Hauptschlüssel (Beispiel 1). Es sollte aber m. E. wie in Beispiel 2 aussehen.
Hier findet man allerdings gute Tipps diesbezüglich:
http://www.finaleforum.superflexible.ne ... stichnoten
Wenn ich in Finale 'was ausprobiere bzw. testen will, erzeuge ich meistens eine "sinnfreie Datei" mit "dummy Daten" und ohne Bibliotheken, um das Problem besser einkreisen zu können.
Gruß
Manchmal schon: z. B. Violin Stichnoten in einem Fagott System. Wenn ich die Stichnoten in der Partitur mittels Notensystemstyle verstecke, so dass sie nur in der Fagott Stimme erscheinen, bleiben trotzdem die Wechselschlüssel in der Partitur sichtbar, es sei denn, ich definiere im Notensystemstyle zusätzlich "keine Transposition" und "neuer Schlüssel = Hauptschlüssel"Nur wegen eines Schlüsselwechsels muß man ja nicht erst umständlich einen Notensystemstil definieren
Das Experimentieren mit Schlüsselwechsel mittels Notensystemstyle entstand beim Versuch, zufriedenstellende Ergebnisse beim Erstellen von Stichnoten, die in der Partitur versteckt und in den Stimmen sichtbar sind und zusätzlich in der richtigen Oktave dargestellt werden, zu erreichen. Dabei ist mir dieser Bug bei der Ausrichtung aufgefallen.
Besonders stört mich auch, dass man nur mit Tricks einen Wechselschlüssel vor der "Eins" eines Taktes platzieren kann: der Wechselschlüssel wird immer zum Hauptschlüssel (Beispiel 1). Es sollte aber m. E. wie in Beispiel 2 aussehen.
Hier findet man allerdings gute Tipps diesbezüglich:
http://www.finaleforum.superflexible.ne ... stichnoten
Wenn ich in Finale 'was ausprobiere bzw. testen will, erzeuge ich meistens eine "sinnfreie Datei" mit "dummy Daten" und ohne Bibliotheken, um das Problem besser einkreisen zu können.
Gruß
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Finale 27 deutsch / WIN 10 64 / Intel i7 / 32 GB RAM / RME Multiface
Man doppelklickt den betreffenden Takt mit dem Takt-Werkzeug und stellen im folgenden Fenster "Taktattribute" unter "Zusätzlicher Abstand am Ende"
einen Leerraum am Taktende ein. Der Bug ist dem Finale-Support bekannt.
einen Leerraum am Taktende ein. Der Bug ist dem Finale-Support bekannt.
Finale 26 & 27, Windows 11 64bit
Finale-Nutzer seit Version 2.1
Dorico- und Sibelius-Ausprobierer (gescheitert bis Dorico 3.5)
Dorico 5
Finale-Nutzer seit Version 2.1
Dorico- und Sibelius-Ausprobierer (gescheitert bis Dorico 3.5)
Dorico 5