Die Kollisionsprüfung ist überhaupt nicht brauchbar, denn sie prüft gar keine echten Kollisionen. Immer wieder muss man sie abschalten, weil die Systeme unmotiviert auseinanderspringen. Es sollte nicht der Hauptnutzen einer Funktion sein, daß man sie abschalten kann. In Sibelius funktioniert sie übrigens formidabel. Also bitte nicht erklären, warum das "nicht geht".
P.S.: auch wenn der werte Herr Moderator jegliche Kritik an diesem Programm als "aggressiv" abtut, sollte es doch für jeden und vor allem den Entwickler interessant sein, von den vielen Bugs und Ungereimtheiten zu erfahren. Denn nur so läßt sich das ja eigentlich sehr intuitive Programm verbessern. Also erübrigt sich jede "geh-doch-nach-drüben"-Rhetorik. Ich bin einfach an einem guten Programm interessiert.
Der werte Herr Moderator beobachtet genau und ist dir keinerlei Rechenschaft schuldig. Süffisante Bemerkungen mir gegenüber schätze ich übrigens auch nicht besonders; deine Bemerkung zeigt abermals einen "Tonfall", der hier im Forum sonst nicht gepflogen wird.
Notationsprogramme: MuseScore, Sibelius|First PC-System: Windows 11 (64 Bit)
dass derartiges feedback nichts hilft, ohne konkret zu werden, haben wir schon desöfteren erklärt... daher abermals die bitte um ein beispiel...
wink: oft funktioniert die kollisionserkennung schlicht "falsch", wenn man die objekte "falsch" verankert...
solange du also nicht ein file hochläst oder zumindest genauer die situation beschreibst, bleibt mir nur zu fragen: Objekt an das richtige System?, den richtigen Takt?, das richtige Objekt? veranktert?! Das ist immens wichtig, damit an den Stellen, wo es Kollisionserkennung gibt (und das ist noch nicht an allen Orten), diese sich auch korrekt verhält!!
Grüße, Carsten -- PriMus Publisher 1.1 und Sibelius 7, unter Windows 8.1 x64. Klassische und E-Gitarre.
In der Tat: Beispiele erleichtern das Leben ... auch derjenigen, die sich um Antworten bemühen. Ich will das aber trotzdem mal ohne versuchen:
Die "Kollisionsprüfung" ist keine Prüfung, sondern eine Kollisionsbehandlung, die zunächst mal die gröbsten Fehler vermeidet.
Dabei wird aber - leider - die horizontale Position der Elemente (noch?) nicht berücksichtigt.
Dagegen spielt der Anker eine entscheidende Rolle: am Takt verankerte Dynamikzeichen werden z. B. nicht berücksichtigt, an der Note verankerte aber schon.
Um von einer Kollisionsbehandlung zu einer Kollisionsautomatik zu kommen, müsste m. E. eine einstellbare Funktion implementiert werden, die sowohl die Vertikale (damit sich nichts überschneidet) als auch die Horizontale (wie weit müssen Elemente minimal voneinander entfernt sein, damit sie nicht einbezogen werden) einbezieht, also sozusagen eine "Einhüllende". Und das habe ich Herrn Schardt schon mitgeteilt.
Manchmal wäre es einfach besser, den Programmierer mit konstruktiver Kritik, Vorschlägen und Beispielen zu versorgen, als nur pauschal in diesem Forum zu kritisieren.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
Ich danke Carsten und Günther für die weise worauf sie reagiert haben auf volxmusikant. Es ist immer noch so wie in Sprüche 15:1 steht: „eine gelinde Antwort wendet den Grimm ab, aber ein kränkendes Wort erregt den Zorn“. Und auch ich weis jetzt wieder etwas mehr über Kollisionen.
Programme: Primus Publisher/Capella Scan 8/Capella 6-19/Tonica Sound: VSC/Coolsoft VMS Musikinstrument: Zither Betriebssysteme: Windows 10
Zitat von Cachstendass derartiges feedback nichts hilft, ohne konkret zu werden, haben wir schon desöfteren erklärt... daher abermals die bitte um ein beispiel...
tut mir leid, aber das ist Humbug. Ich dachte, das Programm sei hier soweit bekannt, daß ihr um den Fehler wisst, zumal er ja unter "Hilfe->Tutorien->widerspenstige Systeme" eindeutig beschrieben wird. Dazu ist ein Beispielfile völlig überflüssig, weil diese fehlerhafte Funktion in jedem File auftritt. Das hat nix mit "fehlerhafter Verankerung" zu tun, sondern damit, daß einfach keine echte Kollisionsprüfung statfindet. In dem genannten Beispiel wird eben nicht überprüft, ob das mf wirklich mit der der Fermate kollidiert oder nicht. Wird aber ebenda alles erklärt. Bitte lesen, statt kommentieren.
Zitat von Cachstendaher abermals die bitte um ein beispiel...
Zitat von Volxmusikanttut mir leid, aber das ist Humbug. .... Wie gesagt: in Sibelius funktioniert's...
Schade, dass du so wenig kooperativ bist. Einfach mal zwei Screenshots von den gleichen Noten posten. Einmal in PriMus und einmal in Sibelius. Und am besten noch die Dateien dazu. Dann könnten alle etwas davon lernen. a) was Sibelius denn nun besser macht und b) was man in PriMus verbessern könnte oder an den PriMus-Daten korrigieren müsste. Aber das ist natürlich mit Arbeit verbunden. Und mit dem Risiko, daß jemand aufzeigt, mit PriMus geht es doch. Oder PriMus dahingehend verbessert. Es wäre schön, wenn Du dich darauf einlassen würdest. Jedenfalls, ohne konkrete (!) Beispiele nützt die ganze Diskussion garnix.
Gruß Jørgen
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: xubuntu22.04LTS (Früher auch W7x64, W10 hat bei mir Hausverbot) Sound: Allen &Heath QU16, Focusrite Scarlett 2i2
Zitat von bassklampfeohne konkrete (!) Beispiele nützt die ganze Diskussion garnix.
Nebenkriegsschauplatz! Ich habe genauestens vermerkt, wo der Fehler nachzulesen ist - aber das macht ja Mühe, gell? Jeder kann den Fehler beliebig oft in jeder PriMus-Datei nachvollziehen - in Sekundenschnelle. Aber das macht Mühe, gell?
Übrigens hat acco-boy den Fehler auch längst eingeräumt. Also spar dir die Ablenkungsmanöver. Fehler ist Fehler.
Zitat von Volxmusikant In dem genannten Beispiel wird eben nicht überprüft, ob das mf wirklich mit der der Fermate kollidiert oder nicht
ich kenne dieses Beispiel und genau das Grundproblem hatte ich doch beschrieben:
Zitat von acco-boyDabei wird aber - leider - die horizontale Position der Elemente (noch?) nicht berücksichtigt.
und genau das zeigt auch das Beispiel unter "Widerspenstige Systeme" in den Tutorials. Frage aber: wie sieht denn dein aktuelles Problem aus? Ich habe auch einen Vorschlag zur Änderung gemacht:
Zitat von acco-boyUm von einer Kollisionsbehandlung zu einer Kollisionsautomatik zu kommen, müsste m. E. eine einstellbare Funktion implementiert werden, die sowohl die Vertikale (damit sich nichts überschneidet) als auch die Horizontale (wie weit müssen Elemente minimal voneinander entfernt sein, damit sie nicht einbezogen werden) einbezieht, also sozusagen eine "Einhüllende".
. Alternativ ginge natürlich auch eine "Zone" um jedes Zeichen und jeden Text. Ich an deiner Stelle würde nicht so massiv kritisieren, denn das Tutorial zeigt doch sehr genau, was die Funktion kann und was nicht. Mache doch lieber Vorschläge, wie du das optimal umsetzen würdest.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
Zitat von bassklampfeohne konkrete (!) Beispiele nützt die ganze Diskussion garnix.
Nebenkriegsschauplatz! Ich habe genauestens vermerkt, wo der Fehler nachzulesen ist - aber das macht ja Mühe, gell? Jeder kann den Fehler beliebig oft in jeder PriMus-Datei nachvollziehen - in Sekundenschnelle. Aber das macht Mühe, gell?
Übrigens hat acco-boy den Fehler auch längst eingeräumt. Also spar dir die Ablenkungsmanöver. Fehler ist Fehler.
Hallo Volxmusikant,
auch ich finde Deinen Ton äußerst aggressiv: Du tust so als ob alle anderen nicht sehr helle oder zumindest faul wären und als ob Entwickler absichtlich Fehler einbauen um Dich und die Welt zu ärgern. Aus meiner Erfahrung als professioneller Softwareentwickler ist dies eher nicht so. Entwickler freuen sich über Fehlermeldungen und wenn sie dann noch schön beschrieben sind und reproduzierbar ist es ein leichtes sie zu beheben und jeder Entwickler freut sich so, sein programm verbessern zu können. Aber pauschales Meckern mit "XY ist unbrauchbar" und "geht nun mal nicht" hilft nicht. Und so dann noch zu erwarten Hilfe zu erhalten könnte man ja schon fast als verwegen bezeichnen. Ich bewundere ehrlich die Engelsgeduld mit der Einige im Forum versuchen, Dir dennoch zu helfen - ich hätte sie nicht. Chapeau! Daniel
PriMus 1-1 - wenig und lediglich vertikale Abstands-Erkennung
Sibelius 7 - vertikale und horizontale Kollisionserkennung ("magnetic layout" (nach Ausführen der "Optimieren"-Funktion, leider findet mein Sib gerade manche Fonts nicht, aber man sieht, was theoretisch rauskommt).
Vielleicht weiß ja noch wer, warum mir auch nach manueller Änderung des Schlüssels (der aus dem mxl nicht richtig herausgelesen wurde) in Sib immer noch die Noten in rot als außerhalb der Range angezeigt werden... ?
danke für die Beispiele (mangels Sibelius kann ich das nicht). Dadurch wird nun eindeutig klar, was ich gemeint habe:
Für eine Kollisionsautomatik müssen vertikale und horizontale Abstände berücksichtigt werden. Und das macht derzeit wohl Sibelius, nicht aber PriMus.
Ich wünsche mir, dass PriMus das auch kann (zu Weihnachten darf man sich ja was wünschen), werde deswegen aber keinesfalls zu Sibelius umsteigen.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
Sibelius scheint aus irgendeinem Grunde (der XML-Import ist einfach noch nicht ausgereift) nicht zu erkennen, dass es sich um ein Klaviersystem handelt und wählt stattdessen irgendein Violinschlüssel-Instrument mit Klavierklang und einem Tonumfang von Fis3 bis G9. Mit dem Schlüssel hat das nichts zu tun.
Dr. T's Copyist (1991), capella (1992 bis 2000) Sibelius (aktuelle Version, seit 2000), MuseScore 4 (gelegentlich), Windows 10 (64 bit)
Zitat von VolxmusikantÜbrigens hat acco-boy den Fehler auch längst eingeräumt.
Das stimmt so nicht. Einen "Fehler einräumen" kann doch nur der, der ihn auch gemacht hat. Ich habe als normaler User nur beschrieben, was ich sehe (von Programmieren habe ich überhaupt keine Ahnung). Ich würde hier auch gar nicht von "Fehler" sprechen, sondern von einer Funktion, die sicher noch optimiert werden kann. Und die gibts in jeder Software, denn "fertig" ist die ja wohl nie.
Gruß Günter
Programme: PriMus Publisher 1.1|MuseScore Studio 4.4.3|SPP 7.0 Betriebssysteme: WIN10 Pro|Linux Mint 21.3 Musik: Notensatz (generell) und Akkordeon (von Solo bis Orchester und von E- bis U-Musik)
Zitat von acco-boyEinen "Fehler einräumen" kann doch nur der, der ihn auch gemacht hat.
naja, da Du zu der Fraktion der Guten gehörst und ich offenbar zu den Bösen, habe ich mir diese Vokabel erlaubt. Übrigens zeigt Cachstens Bespiel ja wohl ohne jeden Zweifel, daß der PriMus Satz einfach scheiße aussieht. Das kann man doch nicht ernsthaft in Frage stellen. Und so eine Funktion ist eben nicht "optimierbar", sondern schlicht fehlerhaft und unbrauchbar. Sie erfüllt einfach nicht den Zweck, für den sie gedacht ist. Es ist nunmal nicht Zweck einer Kollisionprüfung, zu prüfen, ob die Fermate mit dem mf kollidieren würde, wenn dieses über der Fermate stünde. Es steht dort einfach nicht. Mit dieser Feststellung greife ich niemanden an. Ein Entwickler, der sich Qualität auf die Fahnen schreibt, muss so eine Kritik nicht nur aushalten, sondern derartige Fehler beheben. Bei mir würde so eine Funktion einfach nicht ins Programm kommen, Basta. Bisher sind übrigens von mir genannte Fehler nicht in Updates korrigiert worden. Soviel zu: "Entwickler freuen sich über Fehlermeldungen" (Zitat Daniel).
Notensatzforum
Thema drucken
21.12.2014 13:22
Das Thema wurde geschlossen.. 
st oder zumindest genauer die situation beschreibst, bleibt mir nur zu fragen: Objekt an das richtige System?, den richtigen Takt?, das richtige Objekt? veranktert?! Das ist immens wichtig, damit an den Stellen, wo es Kollisionserkennung gibt (und das ist noch nicht an allen Orten), diese sich auch korrekt verhält!!
