ich benutze PriMus nun schon ein paar Jahre und bin mit dem Programm zufrieden. Im Laufe der Zeit fallen dann aber einige störende Dinge auf.
In diesem Fall jetzt der MusikXML Export. Dabei wir leider nicht alles, und vor allen Dingen nicht korrekt exportiert. Zum Einenen ist es die Position der Dynamikzeichen, die im Chorsatz normalerweise über den Noten notiert werden und beim Export wieder unter den Notenzeilen stehen (PriMus Standard). Außerdem die Crescendogabeln, die gar nicht exportiert werden. Außerdem Titel, Komponist usw. wird fehlerhaft und unvollständig exportiert. Wenn ich diese Datei wieder in PriMus importiere sitzen alle Dynamikzeichen wieder unter der Notenzeile.
Wenn man in die aus PriMus exportierte XML Datei hineinschaut, dann fehlt m.E. der Tag für die Dynamikzeichen.
Um bei einem größeren Werk (Schubert Messe Nr. 3) den Korrekturaufwand in der exportierten XML Datei möglichst gering zu halten, habe ich diese in MuseScore eingelesen. Dort kann ich mittels rechter Maustaste und dann Auswählen die entsprechenden Dynamikzeichen zeilenweise selektieren und im Block über den Inspekeur an die richtige Position verschieben. Anschließen aus MuseScore heraus wieder ein MusikXml File schreiben. Beim anschließenden Import in PriMus sitzen die Dynamikzeichen dann an der richtigen Stelle.
Das ist aber eine Krücke und PriMus sollte das von Haus aus richtig exportieren.
Gruß Reinhard Dorico 5.x Pro, PriMus Publisher, Finale 27, Sibelius First, Capella 7+8+9, CapellaScan 9, Musecore 4.1 unter WIN 10 Prof. 64, I-MAC
Die Sprachdefinition war leider von Anfang an mangelhaft, höchst lückenhaft, teilweise mehrdeutig oder undefiniert. In der Folge ist die Programmierung eines MusicXML-Importers eine aufwendige und in höchstem Maße frustrierende Angelegenheit. Denn die mangelhafte Sprachdefinition führte dazu, daß alle Programme mehr oder weniger fehlerhaftes MusicXML erzeugten. Aber jeder mit anderen Fehlern und Eigenheiten. Der Importer muß also zunächst feststellen, aus welcher Quelle die Daten stammen, und daraufhin vieles was er liest unterschiedlich interpretieren und tlw. bekannte Fehler der Exporter versuchen zu reparieren. Zeitraubend, mühsam und ungemein frustrierend. Daher sind alle Exporter und Importer lückenhaft und tlw. fehlerhaft. Keiner behandelt den kompletten Umfang der möglichen Daten und keiner macht es fehlerlos.
Bei PriMus steckt die meiste Arbeit im Importer, da die meisten PriMus-Anwender von anderen Programmen herkommen und ihre Daten mitnehmen möchten. Wir haben ganze Oratorien- und Opernprojekte (hunderte von Partiturseiten) z.B. aus finale übertragen. Das klappt recht gut und viele Entwicklungen des Importers haben entlang solcher Projekte stattgefunden.
Der PriMus-Exporter wird viel weniger angefragt. Er funktioniert einigermaßen, aber er wird nur dann erweitert, wenn konkreter Bedarf entsteht. In PriMus 2 wird er auf jeden Fall erheblich weiterentwickelt sein.
Wollte man die komplette MusicXML-Sprache umsetzen und das noch korrekt im Zusammenhang mit anderen Programmen, dann könnte man sich locker mal ein Jahr oder auch zwei daransetzen.
Der kommende MNX-Standard soll MusicXML ablösen und wird da hoffentlich Besserung schaffen.
Zitat von Christof Schardt Frage: Verstehe ich es richtig, daß Du aus PriMus nach MusicXML exportierst und dann wieder importierst? Falls ja: Wozu dient das?
Der Reimport diente nur zum Testen, um zu sehen was passiert, wenn ich eine exportierte und mit einem anderen Programm (Sibelius, Finale oder MuseScore) korrigierte Datei wieder in PriMus einlese. Üblicherweise mache ich das sonst nicht.
Der Import von XML Dateien aus anderen Programmen in Primus funktioniert wirklich recht gut. Da gib es ob der Komplexheit des XML Formates nix zu meckern.
Ich habe einen Sängerkameraden der mag sich nicht von seinem Capella trennen und somit stelle ich ihm die Dateien im Capellaformat zu verfügung. Das heist, ich importiere die aus PriMus exportierte XML Datei in Capella und korrigiere dort die flasch positionierten Dynamikzeichen usw. Vielleicht werde ich zukünftig noch eine Zusatzschleife über MuseScore drehen, dort geht die Verschiebung der Dynamics am Stück und somit schneller. So gesehen könnte ich die Noten eigentlich gleich wieder mit Capella schreiben, aber PriMus ist mir doch einiges lieber und die Arbeit geht mir damit besser von der Hand.
Es wäre sicherlich viel gewonnen, wenn PriMus die Dynamikzeichen und Crescendogabeln im Chorsatz oberhalb der Notenzeilen positionieren würde. Die manuelle Verschiebung geht leider beim Export verloren.
Hoffentlich bringt Primus 2.0 die entscheidene Verbesserung.
Danke für die Rückmeldung.
PS: Wenn ein Betatester benötigt wird, stelle ich mich gerne zur Verfügung.
Gruß Reinhard Dorico 5.x Pro, PriMus Publisher, Finale 27, Sibelius First, Capella 7+8+9, CapellaScan 9, Musecore 4.1 unter WIN 10 Prof. 64, I-MAC
Zitat von Reinhard32 Es wäre sicherlich viel gewonnen, wenn PriMus die Dynamikzeichen und Crescendogabeln im Chorsatz oberhalb der Notenzeilen positionieren würde. Die manuelle Verschiebung geht leider beim Export verloren. Hoffentlich bringt Primus 2.0 die entscheidene Verbesserung.
Ja, PriMus 2 ordnet Dynamikzeichen in Liedsystemen oberhalb an (einstellbar).
Bezgl. eines XML-Workflows: Da gibt es eigentlich nur eine einzige sinnvolle Anwendung: Die einmalige Übertragung in ein Zielprogramm, um dort die endgültige Bearbeitung vorzunehmen. Alle anderen Szenarien (Hin-und-her-Übertragung zur zwischenzeitlichen Bearbeitung in einem anderen Programm - evt. sogar mit Zusatzschleife über ein Drittprogramm) sind meines Erachtens nur Masochisten zu empfehlen. Man bedenke folgendes: im einfachsten Fall müssen die Daten bereits durch zwei lückenhafte Programme hindurch (den Exporter und den Importer), beim Rücktransport wären es dann schon vier und mit Zusatzschleife acht! Stille Post läßt grüßen.
Zitat von Christof SchardtBezgl. eines XML-Workflows: Da gibt es eigentlich nur eine einzige sinnvolle Anwendung: Die einmalige Übertragung in ein Zielprogramm, um dort die endgültige Bearbeitung vorzunehmen.
ICH habe ja einen anderen Traum: MusicXML als Clipboard-Format!!! Beliebige Passagen (von einzelnen Noten über Takte, Systeme, Passagen oder ganze Stücke) per Clipboard von einem Programm in ein Anderes kopieren. So wie man es auch von Textverarbeitung gewohnt ist.
Ich weiss, das bleibt angesichts a) der Unzulänglichkeit der MusicXML-Definition und b) der Voraussetzung, dass dafür die Hersteller der Notensatzprogramme zusammenarbeiten müssten für immer ein Traum.
Musik: Notensatz&Musizieren&Recording@Jazz,Rock,Chor@Bass,Gitarre,Gesang. Soft: Aktuell : PriMusPublisher, PdfToMusic, CapalleScan8, Transcribe, Ardour (+MuseScore, Audacity, u.v.a.m.) Früher: GuitarPro(1…6), Capella(1…6), TuxGuitar, CakeWalk, … Prog: Lua, C++, Perl, Bash, ... HW: i7-8086K, 32GB-Ram, 2x1TB SSD + 2x4TB HD BS: xubuntu20.04LTS (Früher auch W7x64, W10 hat bei mir Hausverbot) Sound: Allen &Heath QU16, Focusrite Scarlett 2i2
Zitat ICH habe ja einen anderen Traum: MusicXML als Clipboard-Format!!! Beliebige Passagen (von einzelnen Noten über Takte, Systeme, Passagen oder ganze Stücke) per Clipboard von einem Programm in ein Anderes kopieren. So wie man es auch von Textverarbeitung gewohnt ist.
Ich weiss, das bleibt angesichts a) der Unzulänglichkeit der MusicXML-Definition und b) der Voraussetzung, dass dafür die Hersteller der Notensatzprogramme zusammenarbeiten müssten für immer ein Traum. ..
Das Clipboard Format könnte nur eine Übergangsvariante sein. Ein Standard XML-Dateiformat für Musiknotation wäre mein Wunsch. Wenn einige Hersteller (PriMus, MuseScore, Capella...)damit anfangen würden, würden auch die Anderen nachziehen. Im Office Berich machen es Microsoft und Open-/Libreoffice ja schon vor. Das sind die Dateiformate gegenseitig les- und schreibbar. Es gibt dabei leider 2 Standards (Lobbyarbeit von MS), aber immerhin zeigt es, dass es möglich sein müsste. Sicherlich ist Musiknotation um einiges komplexer als z.B. Texte zu formatieren, aber die Trennung von Formatierung und Inhalt würde vermutlich einiges vereinfachen.
Gruß Reinhard Dorico 5.x Pro, PriMus Publisher, Finale 27, Sibelius First, Capella 7+8+9, CapellaScan 9, Musecore 4.1 unter WIN 10 Prof. 64, I-MAC
Zitat von Reinhard32 Es wäre sicherlich viel gewonnen, wenn PriMus die Dynamikzeichen und Crescendogabeln im Chorsatz oberhalb der Notenzeilen positionieren würde. Die manuelle Verschiebung geht leider beim Export verloren. Hoffentlich bringt Primus 2.0 die entscheidene Verbesserung.
Ja, PriMus 2 ordnet Dynamikzeichen in Liedsystemen oberhalb an (einstellbar).
Bezgl. eines XML-Workflows: Da gibt es eigentlich nur eine einzige sinnvolle Anwendung: Die einmalige Übertragung in ein Zielprogramm, um dort die endgültige Bearbeitung vorzunehmen. Alle anderen Szenarien (Hin-und-her-Übertragung zur zwischenzeitlichen Bearbeitung in einem anderen Programm - evt. sogar mit Zusatzschleife über ein Drittprogramm) sind meines Erachtens nur Masochisten zu empfehlen. Man bedenke folgendes: im einfachsten Fall müssen die Daten bereits durch zwei lückenhafte Programme hindurch (den Exporter und den Importer), beim Rücktransport wären es dann schon vier und mit Zusatzschleife acht! Stille Post läßt grüßen.
Prima, dass Primus 2 die Möglichkeit bieten wird, die Dynamics bei den Liedzeilen wahlweise oben anzuordnen.
Der von mir beschriebene Workflow ist sicherlich eine "Krücke" denn bei jeder Konvertierung gehen Informationen verloren oder werden verfälscht. Bei einem Stück mit 30 Takten ist der manuelle Aufwand sicherlich überschaubar, aber bei eine Stück mit 200 Takten? Dann wird es doch lästig.
Ich habe gerade noch eine andere Möglichkeit probiert. Die aus PriMus erzeugte PDF-Datei mittels PDFtoMusic in XML zu konvertieren und anschließend in Capella einzulesen. Das ist zwar auch nicht perfekt aber der Nacharbeitsaufwand ist erheblich geringer.
Viele Wege führen nach Rom....
Gruß Reinhard Dorico 5.x Pro, PriMus Publisher, Finale 27, Sibelius First, Capella 7+8+9, CapellaScan 9, Musecore 4.1 unter WIN 10 Prof. 64, I-MAC
Zitat ICH habe ja einen anderen Traum: MusicXML als Clipboard-Format!!! Beliebige Passagen (von einzelnen Noten über Takte, Systeme, Passagen oder ganze Stücke) per Clipboard von einem Programm in ein Anderes kopieren. So wie man es auch von Textverarbeitung gewohnt ist.
Ich weiss, das bleibt angesichts a) der Unzulänglichkeit der MusicXML-Definition und b) der Voraussetzung, dass dafür die Hersteller der Notensatzprogramme zusammenarbeiten müssten für immer ein Traum. ..
Das Clipboard Format könnte nur eine Übergangsvariante sein. Ein Standard XML-Dateiformat für Musiknotation wäre mein Wunsch. Wenn einige Hersteller (PriMus, MuseScore, Capella...)damit anfangen würden, würden auch die Anderen nachziehen. Im Office Berich machen es Microsoft und Open-/Libreoffice ja schon vor. Das sind die Dateiformate gegenseitig les- und schreibbar. Es gibt dabei leider 2 Standards (Lobbyarbeit von MS), aber immerhin zeigt es, dass es möglich sein müsste. Sicherlich ist Musiknotation um einiges komplexer als z.B. Texte zu formatieren, aber die Trennung von Formatierung und Inhalt würde vermutlich einiges vereinfachen.
NEE, Reinhard. Das Clipboard-Format hat andere Anwendungsfälle, ist aber informationstechnisch eigentlich ähnlich. MusicXML SOLL ja genau dieses Standard XML Dateiformat sein. IST es aber nicht aus den von Christof angebrachten Gründen.
Die W3C Music Notation Group versucht wie gesagt die Unzulänglichkeiten zu verbessern / beseitigen. "MNX-Common" wird der Standard heißen, der MusicXML ablöst und aktuell in der Spezifizierung ist.
Grüße, Carsten
Grüße, Carsten -- PriMus Publisher 1.1 und Sibelius 7, unter Windows 8.1 x64. Klassische und E-Gitarre.
Zitat von Cachsten Die W3C Music Notation Group versucht wie gesagt die Unzulänglichkeiten zu verbessern / beseitigen. "MNX-Common" wird der Standard heißen, der MusicXML ablöst und aktuell in der Spezifizierung ist.
Das "N" an der zweiten Stelle und der Name der Working Group läßt mich befürchten, daß wieder die papierne Notation an erste Stelle steht, also die Präsentation anstatt dem semantischen Inhalt.
Ich denke an eine digitale Speicherung von Musik, die vielleicht eine XML-formatierte Version von MIDI ist, die also festhält, wie die Musik klingen soll, und die dann mit einem XSLT-Transformator zu visueller Wahrnehmung als Notation (in verschiedenen Systemen) transformiert werden kann, so wie es eine CSS-Datei mit den zugrundeliegenden HTML-Document macht.
Zitat von Cachsten Die W3C Music Notation Group versucht wie gesagt die Unzulänglichkeiten zu verbessern / beseitigen. "MNX-Common" wird der Standard heißen, der MusicXML ablöst und aktuell in der Spezifizierung ist.
Das "N" an der zweiten Stelle und der Name der Working Group läßt mich befürchten, daß wieder die papierne Notation an erste Stelle steht, also die Präsentation anstatt dem semantischen Inhalt.
Ich denke an eine digitale Speicherung von Musik, die vielleicht eine XML-formatierte Version von MIDI ist, die also festhält, wie die Musik klingen soll, und die dann mit einem XSLT-Transformator zu visueller Wahrnehmung als Notation (in verschiedenen Systemen) transformiert werden kann, so wie es eine CSS-Datei mit den zugrundeliegenden HTML-Document macht.
Genau das ist das große Ziel, über die Papier-Form hinaus eine dynamische Präsentation in einheitlichem Format zu ermöglichen. Deine Befürchtungen sind also unbegründet. [wink]
Ich denke an eine digitale Speicherung von Musik, die vielleicht eine XML-formatierte Version von MIDI ist, die also festhält, wie die Musik klingen soll, und die dann mit einem XSLT-Transformator zu visueller Wahrnehmung als Notation (in verschiedenen Systemen) transformiert werden kann, so wie es eine CSS-Datei mit den zugrundeliegenden HTML-Document macht.
Genau das ist das große Ziel, über die Papier-Form hinaus eine dynamische Präsentation in einheitlichem Format zu ermöglichen. Deine Befürchtungen sind also unbegründet. [wink]
Die Formulierung "einheitliches Format" steigern eher meine Sorge.
Man Wunsch ist es ja, ein einheitliches digitales Musikformat zu haben, im Sinne von einem Quelltext, ohne Rücksicht darauf, wie es visuell erscheinen könnte, und getrennt davon verschiedenste Transformatoren, die diesen musikalischen Quelltext zur Darstellung in visuellen oder akustischen Darstellungen transformieren können.
War mir schon klar. [wink] ich rede ja nicht von einer "einheitlichen Noten-Formatierung", sondern von einem "einheitlichen Datei-Format". Einheitlich im Sinne von "Eindeutig spezifiziert und daher richtig implementiert".
Grüße, Carsten -- PriMus Publisher 1.1 und Sibelius 7, unter Windows 8.1 x64. Klassische und E-Gitarre.
Ich möchte das Eingangsthema (MusikXML Eport) nochmals aufgreifen:
Um die Dynamikzeichen von aus Primus exportierte Gesangspartituren oberhalb der Notenzeile in Capella darzustellen, habe ich ein Script von Andreas Herzog gefunden, dass das automatisch macht.
Das funktionniert wirklich gut und man muss nur an ein paar Stellen noch manuel nachjustieren. Problem gelöst!
XML-Import in Primus: Beim Import in Primus aus verschiedenen XML Quellen kommt es ebenfalls vor, dass die Dynamiksymbole und Crescendogabeln bei Liedern unterhalb der Notenzeile stehen.
Workaround: Import der XML- Datei in Primus. Anschließend exportieren als Emil-Datei.
Die Emil Datei in einem Texteditor öffnen.
Dort den Wert „dy=70“ mittels der Bearbeiten Ersetzen Funktion durch den Wert „dy=950“ (jeweils ohne Anführungsstriche) im gesamten Dokument ersetzen. Anschließen den Wert „Cresc{}“ durch „Cresc{y=800}“ und danach „Dim{}“ durch „Dim{y=800}“ ersetzen. Dann die Datei unter demselben Namen speichern.
Mit den Werten für dy und y muss man ggf. noch etwas herumprobieren, aber bei einem längeren Stück ist es doch eine erhebliche Erleichterung.
Hinweis: Es werden alle Dynamiksymbole verschoben.
Zum Schluss die Emil Datei in Primus öffnen und voila, alle Zeichen und Symbole sitzen da wo sie hin sollen. Anschließend ist noch Feinarbeit angesagt.
Gruß Reinhard Dorico 5.x Pro, PriMus Publisher, Finale 27, Sibelius First, Capella 7+8+9, CapellaScan 9, Musecore 4.1 unter WIN 10 Prof. 64, I-MAC
Notensatzforum
Thema drucken
06.04.2018 20:54
Antworten
