Benutzer Diskussion:Zupftom

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 4. April 2013 um 21:59 Uhr durch imported>Cachsten(793837) (Neuer Abschnitt →‎Score ist kein "Markup-Notensatzprogramm").
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Guido

Und dieses noch

Danke für dein Mail und auch für deine Hinweise, wegen dem Abspeichern, werde künftig in Ruhe mich in irgend einen Editor zurück ziehen. Die Sänger bevorzuge ich gar nicht, bin selbst kein Sänger, es ist einfach nur so: um einen Ton mit der Stimme hervorzubringen, muss man man den Ton gleichsam innerlich vorwegmusizieren, ihn innerlich vorstellen, das fördert das innere Gehör. Um einen Ton am Instrument zu spielen, muss ich nur die richtige Taste oder den richtigen Steg drücken. Natürlich fördert über die Jahre auch die haptische Handhabe eines Instruments die Assoziation und Merkfähigkeit. Jeder Instrumentalist kennt das, wenn er sich eine Melodie vorstellt, kommen ihm als Vorstellung unweigerlich grifftechnische Bilder zu Hilfe. Sehr gute Notenleser visualisieren vielleicht eher ein Notenbild. In einem hast du recht, da Sänger nur Noten vor sich haben, ist für sie ein zusätzliches Merkverfahren wichtiger. Übrigens ist die Gitarre ein ziemlich relatives Instrument, weil man eine Grifffolge bundweise unverändert verschieben kann. Am Klavier oder bei Blasinstrumenten dagegen schaut jede Tonart vollkommen anders aus. Vielleicht ist das ein Grund, warum Gitarristen die Notwendigkeit der Relative Solmisation eher anzweifeln (Zufall oder nicht, aber meine Erfahrung).

--Joskar 10:38, 27. Apr 2006 (CEST)

Nichts für ungut, Major Tom!

Ich glaube, du kannst mit meiner Korrektur leben, habe - so weit es mir möglich schien - den Änderungen im Text beibehalten. Dass man ausdrücklich darauf hinweist, Guido sei ein großer Didaktiker gewesen, und dass die Guidonische Hand den haptischen, nicht bloß den visuellen Sinn einbezieht, sollte nicht fehlen, wenn man von Reizverknüfung spricht. Dass man darauf eingeht, wenn es um Notation geht, finde ich durchaus angebracht, weil die absolute Notation der erste Geniestreich des Alten war. Und es ist tatsächlich so, das Guido im Unterricht die didaktischen Schwächen der absoluten Notation beklagt. Ich glaube, dass einige Stellen jetzt besser sind, verständlicher, das ist natürlich auch dein Verdienst. Hoffe dir gefällt "dem Gedächtnis einprägen" besser als "einlernen" ...

Servus --Joskar 10:21, 27. Apr 2006 (CEST)


Hallo Herr Zupftom!

Deine Änderungen finde ich etwas eigenmächtig, habe mir sehr Mühe gegeben, aber irgendwie scheinst du diesen Artikel als dein Territorium anzusehen, und wer da was reinmacht, muss gleich verbessert werden. Gut, es stört mich nicht, solange der Inhalt nicht falsch dargestellt wird. Aber das ist jetzt zum weiteren Mel der Fall. Der Text war die letzten Wochen so etwas von verkehrt, dass es mir schon peinlich war, mich daran überhaupt beteiligt zu haben. Ich wollte das als Diskussion mal ansprechen und habe mich dazu ausführlich geäußert - keine Reaktion! Dann habe ich den Text inhaltlich richig gestellt (irgend wer hat tatsächlich geglaubt, dass das Terzliniensystem von Guido in irgend einer Weise relativ zu vestehen sei). Anstatt das ebenfalls in der Diskussion zu begründen, haust du gleich richig drein. Mit dem Ergebnis, dass wieder ein grober Fehler im Text steht. Offenichtlich ist Guido nicht so dein Thema, aber das merkst du offensichtlich nicht. Zur Zeit Guidos gab es noch keine tonale Theorie, es ging Guido nur um die modale Konditionierung des Halbtonschrittes Mi-Fa. Gut es waren nicht 1000 Jahre vor Pawlow, aber 900 Jahre kann man ruhig gelten lassen. Alles rausgeschnitten. Wieso, bloß weil das neu für dich ist? Es gibt tatsächlich keinen eindeutigeren Nachweis von systematischer Konditionierung vor Pawlow als eben bei Guido - dass er dies eher unbewusst vollbrachte, ändert nichts daran, dass der Hinweis korrekt ist. Guido war ein didaktisches Genie, befass dich mal näher mit seinen Schriften. Dass ihn die Lernpsychologie für sich noch nicht entdeckt hat, liegt wohl daran, dass ihn selbst die Musiker noch fälchlich als Theoretiker behandeln, was er bestenfalls in zweiter Linie war.

Und es ist auch nicht richtig, dass Solmisation vor allem für Sänger wichtig ist, es handelt sich um ein Konzept der Gehörbildung, die innere Tonvorstellung soll mittels Singstimme gefördert werden. Du wirst doch nicht sagen wollen, Gehörbildung sei nur etwas für Sänger ...

Ich werde deine Änderungen zum Teil lassen, weil ich hoffe, dass dich das irgendwie zufrieden stellt. Es sollte doch um die Sache gehen - oder?

--Joskar

Hallo! Ich bin mit deinen Kürzungen bei Guido nur sehr beschränkt einverstanden. Nicht weil der Beitrag von mir stammt, sondern weil offensichtlich Inhalte gestrichen wurden, die so nirgendwo gestanden sind. Ich habe sogar Essays angeführt, um Menschen, die sich nicht durchblicken, eine Hilfe zu bieten. Das Thema ist nicht so einfach, dass man es in einem kleinen Absatz abhandeln könnte. Wer etwas über Guido sagen willm wird nicht um die Frage herum kommen, wie verhält sich relative Notation zu absoluter. Habe dazu was auf die Diskussionsseite unter Guido geschrieben. Nix für ungut, aber dein Finger erscheint mir etwas zu flink ----Joskar 11:33, 11. Apr 2006 (CEST)

Intonation

Hallo Thomas, könntest Du mal den Artikel Intonation anschauen? Da steht etwas über die Bundreinheit bei der Gitarre, aber in einem Zusammenhang, der mir komisch vorkommt. Spricht man denn bei der Gitarre auch von Intonation, wenn man die Positionierung der Bünde meint?

Grüße --Rs newhouse 20:54, 27. Mär 2006 (CEST)

Ich finde den Artikel überhaupt etwas komisch, vor allem, dass er sich so auf den Instrumentenbau versteift und so tut, als ginge es bei Intonation im Gesang (oder bei Streichern und allen möglichen anderen Instrumenten, die finden nirgendwo Erwähnung) um etwas vollkommen anderes.
Um auf deine Frage zurückzukommen: Die Bundreinheit ist in diesen Zusammenhang eigentlich nicht deplaziert. Es geht ja hier um die Intonation im Sinne der "Feinabstimmung". Nur falls du bezüglich Bundinstrumenten nicht so bewandert bist: Es ist nicht damit getan, zum Beispiel den 12. Bund für die Oktave auf die Hälfte der Saite zu setzen, der Ton würde höher klingen als die Oktave, weil durch den Fingerdruck die Spannung erhöhrt wird und die Dicke des Bundes die Saite noch minimal verkürzt. Wie der Bund nun genau platziert wird, ist wahrscheinlich Erfahrungssache - da kann ich nichts weiter zu sagen.
Allerdings gebe ich dir recht, dass die Bundreinheit in diesem Artikel (zumindest in diesem Zustand) wenig zur Sache tut, zumal sie überhaupt nicht in den Zusammenhang eingebettet ist. Da müsste vieles rein, was wesentlicher ist und direkt mit dem Begriff Intonation zu tun hat. Am Besten wäre vielleicht ein Überarbeiten-Baustein und eine Diskussion auf der Artikelseite. --Zupftom 00:34, 28. Mär 2006 (CEST)
Lieber Zupftom, vielen Dank für die heutige sehr sinnvolle Überarbeitung und Ergänzung des Artikels. Langsam wird er - so hoffe ich - besser lesbar und eine nützliche und nachvollziehbare Lektüre. Membeth 10:07, 3. Sep. 2009 (CEST)

Diskussion:Accademia Filarmonica

Bitte lesen hier it:Utente:Biopresto --212.34.235.44 10:18, 26. Sep 2006 (CEST)

Fernpunkt / Fluchtpunkt

Da hast du, finde ich, viel zur Klärung beigetragen. Ich hab trotzdem noch mal verändert und gestrafft. Findest du das so in Ordnung? -- Peter Steinberg 00:44, 3. Dez. 2007 (CET)


An Zupftom bzgl. Interessen und Ausbildung

Hallo, habe Ihren Äußerungen entnommen, dass Ihre Persönlichkeit, Ihre Interessen und Ausbildung und Ihre Denkweise auf meiner Seite Entsprechungen finden. Es würde mich interessieren, auch über Wikipedia hinaus mal zu korrespondieren. --Herbert Eppler 12:29, 17. Jan. 2008 (CET)

Kombinierend

Hallo, Zupftom, ein kleiner Gegenbesuch: Das "Kombinierend" muss immer dann mit rein, wenn das Zeichen nur in Kombination mit anderen Zeichen verwendetet wird (siehe Tremolo ... u.a.). Wir schreiben bei der Liste ja kein Musiklexikon, sondern wollen nur die Unicode-Zeichen genau benennen. --Reiner Stoppok 01:55, 3. Mär. 2008 (CET)

Ich habe die deutsche Übersetzung eher so als Erläuterung verstanden, deshalb finde ich das "Kombinierend" irgendwie irritierend. Was soll sich Ottonormalleser unter einem "kombinierenden Tremolo" vorstellen? Vielleicht findet sich ja eine bessere Formulierung?? --Zupftom 02:00, 3. Mär. 2008 (CET)
Schau mal bitte hier. Am besten ist es, wir verfahren bei allen Unicode-Blöcken einheitlich mit diesem "kombinierend". Der Ottonormalvomblattspieler schaut dann da nach, wohin die Links führen (das finde ich jetzt auch gut gelöst so). Hier geht es nur um die genaue Zeichenbenennung. --Reiner Stoppok 02:08, 3. Mär. 2008 (CET)
Gut, einverstanden. Habe gerade einen Bearbeitungskonflikt mit deinen letzten Edits. Ich versuche jetzt mal die richtigen Teile rüberzukopieren, bitte schau dann doch nochmal drüber, ob deine Edits noch heil sind. --Zupftom 02:22, 3. Mär. 2008 (CET)
Holla, Portato (für Loure)?! Wo steht das denn? --Reiner Stoppok 02:47, 3. Mär. 2008 (CET) PS: Das "SYMBOL CROIX" ist auch gerade ein Kreuz für mich ...
PS: Ein paar Lücken sind noch da. Damp bzw. DAMP ALL hat bestimmt was mit Saiten "dämpfen" zu tun. Bei der größten Lücke weiß ich garnicht weiter. PS: Das mit Loure habe ich immer noch nicht verstanden. (Ich hatte den Ehrgeiz, das hier zu erledigen, ohne in ein schlaues Buch zu schauen.) - Wie wollen wir den ganzen Block taufen? "Musiksymbole" (als Übersetzung von Musical Symbols) fände ich nicht schlecht. Der Begriff wäre weit genug.
Meinst du jetzt die Spieltechnik? Naja, also platt gesagt ein Zwischending zwischen Legato und Staccato. Bin kein Streicher, aber die musikalische Idee ist mir schon vertraut, die lässt sich auch auf anderen Instrumenten imitieren. Jeder Ton kriegt eben etwas mehr Gewicht durch den neuerlichen "Anstrich", der eigentlich keiner ist. Naja, egal, ist einfach zu spät. Musiksymbole finde ich gut. Denn mal gute Nacht! --Zupftom 03:11, 3. Mär. 2008 (CET)
Ich weiss, was Portato ist, wusst aber nicht, wieso Du das bei engl. "Loure" stehen hast. --Reiner Stoppok 03:13, 3. Mär. 2008 (CET)
Den Link dazu hatte ich auf deiner Disku geschrieben, vielleicht hast du den nicht gelesen. Hat sich etwas zerstreut, diese Unterhaltung hier. --Zupftom 03:15, 3. Mär. 2008 (CET)
Gefunden! Danke! Man lernt nie aus ... --Reiner Stoppok 03:17, 3. Mär. 2008 (CET) PS: Noch ne allerletzte Idee zum Blocknamen?
Präziser als "Musiksymbole" wäre vielleicht noch "Musiknotationssymbole". Auch wenn's etwas sperriger klingt ist es dann sehr exakt umrissen. Etwas weniger sperrig könnte ich mir so was wie "Zeichen für die Musiknotation" vorstellen - ist genauso präzise. --Zupftom
Musiknotationssymbol dann auch vor jedes Zeichen? (Ich würde einen Begriff aus einem Wort bevorzugen.) --Reiner Stoppok 03:29, 3. Mär. 2008 (CET) PS: Bend, smear etc. (die große Lücke) sind Jazz-Effekte. Ich rate einfach mal: auch unübersetzt belassen?!
Ach, darum gehts! Na dann am Besten schon einfach nur Musiksymbole, damit's nicht zu lang wird.
Ja, der leere Block fällt bei Gitarristen unter Bending-Techniken. Bin zwar Gitarrist, habe aber hauptsächlich auf der klassischen Schiene meine Ausbildung genossen. Müsste aber trotzdem irgendwas zum Thema rumfliegen haben. Allerdings wird das sicher auch von Posaunisten und sonstigen Jazz/Rock/Poppern benutzt werden, also sind spezielle Gitarren-Ausdrücke vielleicht nicht so angebracht. Ich glaube auch, dass wir die original Bezeichnungen übernehmen können, da dieser Musikbereich ja sowieso stark international ist. Eine Verlinkung auf Bending wäre vielleicht nicht schlecht. Da steht u.a. "[Bending] findet vereinzelt auch bei Blechbläsern Anwendung." Außerdem ist auch die Blues-Harp mit abgedeckt. --Zupftom 03:39, 3. Mär. 2008 (CET)
So, jetzt bin ich aber echt weg, noch eine Mütze Schlaf nehmen. --Zupftom 03:53, 3. Mär. 2008 (CET)
So kurz vor dem Ziel? --Reiner Stoppok 04:03, 3. Mär. 2008 (CET) PS: Wie wärs mit "Notenschriftzeichen" als Unicode-Block-Name?
Perfekt! --Zupftom 10:26, 3. Mär. 2008 (CET)
"Byzantinische Noten" und "Altgriechische Noten" würde ich ebenfalls entsprechend umändern (in Byzantinische Notenschriftzeichen bzw. Altgriechische Notenschriftzeichen). --Reiner Stoppok 14:49, 3. Mär. 2008 (CET) PS: Inzwischen geschehen.

Score

Hallo Zupftom, vielleicht kannst Du mir ja helfen. Ich würde gern wissen, wie Score-Datein intern aufgebaut sind, das heißt wie das File-Format aussieht. Hast Du irgendeine Ahnung, wo man Informationen dazu finden könnte? Danke und viele Grüße, Leopold 16:04, 19. Jun. 2008 (CEST)

Hallo Leopold, habe auf deiner Benutzerdiskussion geantwortet. --Zupftom 09:46, 26. Jun. 2008 (CEST)
Hallo Zupftom, danke für Deine freundliche Hilfe. Bei mir lief es die letzten Wochen drunter und drüber, darum schreibe ich erst jetzt. Ich war auf einer Web-Seite fündig geworden und habe mir dann ein Buch gekauft. Das ist ganz gut, wenn auch nicht erschöpfend. Insbesondere die ominöse Liste mit den angeblich 1000 Codes für Musik-Zeichen fehlt dort. Ich danke Dir erst einmal sehr. Leopold 07:40, 18. Jul. 2008 (CEST)
Du kennst Score selbst also nicht? Dann wird es wohl schwierig werden. Ohne die Handbücher hast du keine Chance. Das Dateiformat selbst (also die Art und Weise wie die Parameter gespeichert sind) ist eigentlich sehr einfach zu verstehen - die Bedeutung der einzelnen Parameter und was sie grafisch bewirken ist aber nicht immer so ganz trivial. Das Parametersystem ist wie ich finde nicht gerade das eleganteste und konsistenteste, mit vielen "Wenns und Abers".
Ich nehme an du hast dir Beyond MIDI zugelegt? Ich habe das Buch noch nie in der Hand gehabt, aber auf den 30 Seiten die es Score widmet werden die Parameter kaum umfassend dokumentiert sein können. Was die Liste der Zeichen angeht: Score liefert tatsächlich ca. 500 Zeichen mit. Je nach Bedarf können eigene Zeichen oder Zeichenvarianten hinzugefügt werden. Dafür gibt es ein sehr einfaches Vektorgrafikprogramm. Grundsätzlich sind alle Zeichen änderbar und können im Prinzip unter einem beliebigen Index in der Symbolbibliothek gespeichert werden.
Was hast du denn vor? --Zupftom 10:15, 18. Jul. 2008 (CEST)

Notensystem (Musik)

Hallo Zupftom,

also mit der "subjektiven" Formulierung gebe ich dir recht und finde deine Formulierung o.K. Aber Tatsache bleibt: NotenZEILE taucht in keiner ernstzunehmenden Fachliteratur (vgl. Hugo Riemann Musiklexikon, Dachs/Söhner Harmonielehre etc.) auf. ZEILE wäre auch von der Wortbedeutung her nicht sinnvoll: Man schreibt AUF eine (EINE!) Zeile, aber Notenlinien haben auch Zwischenräume... Im Übrigen ist die Sache eindeutig: "System" sind mehrere Linien, Akkolade sind mehrere Systeme und eine Partitur enthält eine Mischung aus Systemen und Akkoladen ... Noch ´was: Wenn du Notenpapier kaufst, dann druckt der Verlag unten aufs Papier z.B. 10 Systeme (und nicht ZEILEN ... oder?).

Gruß-- Hondali 20:17, 30. Aug. 2009 (CEST)

Klar, Notenzeile ist keine Fachsprache und sollte hier nicht verwendet werden. Dass du Notenzeile aber irreführend findest kann ich nicht ganz nachvollziehen. Im ersten Schuljahr hat man auch Zeilen, die aus vier Linien (und drei Zwischenräumen) bestehen, trotzdem sind es Zeilen. Oder worum geht es dir im Kern? --Zupftom 20:52, 30. Aug. 2009 (CEST)
Nur ums Prinzip: Zeile ist nach Duden eine "abgeteilte Reihe", in WP fehlt die Definition bisher noch (sollte man vielleicht mal machen). Eigentlich also eine Folge von Buchstaben. Das, worauf man schreibt, ist die Linie. Im Schreibheft der 1. Klasse finde ich nur den Begriff "Lineatur" (http://www.unterrichtsmaterial-schule.de/deutschvorschau47.shtml), d.h. von den vier Linien ist die 2. von unten die eigentliche Schreiblinie, die anderen sind "Hilfslinien" für die Ober- und Unterlängen. Im Grunde ist das eine Diskussion um "Kaisers Bart" und es ist mit der "Zeile" wie mit vielem in der Sprache: Begriffe verändern sich im Laufe der Zeit. Dennoch bin ich der Meinung, dass in WP die Fachbegriffe klar und einwandfrei verwendet werden sollten. Aber wenn´s jemand unbedingt anders will, werde ich es nicht verhindern. Gruß -- Hondali 11:04, 31. Aug. 2009 (CEST)
Nee, ich will das auf gar keinen Fall anders. Ich finde es absolut richtig, dass du das geändert hast. Aber um unabhängig davon des Kaisers Bart nochmal sportlich aufzugreifen, der Begriff Zeile ist doch nicht für eine Folge von Buchstaben reserviert. Es gibt auch Küchenzeilen, Häuserzeilen, Tabellenzeilen, Matrixzeilen, Zeilenbrötchen und was weiß ich noch alles. Was mit "Notenzeile" gemeint sein soll, ist doch einsichtig!? Genügt auch der Duden-Definition "abgeteilte Reihe". --Zupftom 14:19, 31. Aug. 2009 (CEST)

PostScript-Fontformate

Vielleicht magst Du nochmal drüberkucken, ob das hoffentlich jetzt so stimmt mit den verschiedenen Bezierkurven-Typen.--Wondigoma 18:23, 5. Nov. 2009 (CET)

Hallo Wondigoma, super, dass du dir den Artikel vorgenommen hast. Sozusagen mathematisch gesehen ist es so richtig - wenn du nichts dagegen hast, vergreife ich mich demnächst nochmal an ein paar Formulierungen. --Zupftom 15:35, 6. Nov. 2009 (CET)
Alles weitere auf Diskussion:PostScript-Fontformate --Zupftom 10:14, 7. Nov. 2009 (CET)

lilypond 2.12.3

Wieso hast Du meine Änderung beim Lilypond-Artikel rückgängig gemacht? -- Lemzwerg 22:23, 16. Jan. 2010 (CET)

Habe ich auf der Disku geschrieben, weil ich nur auf "Zurücksetzen" geklickt habe und es da leider nichts gibt, wo man noch eine Begründung eingeben kann, die in der Versionsgeschichte angezeigt wird (wenn doch, habe ich noch nicht rausgefunden, wie). Die Version 2.12.3 ist "nur" eine Entwicklerversion, also so eine Art Release Candidate, oder liege ich da falsch? In der Regel wird doch als aktuelle Version eine stabile und keine Entwicklerversion angegeben. --Zupftom 22:59, 16. Jan. 2010 (CET)
Du liegst falsch – ein Blick auf die lilypond-Homepage hätte Dir das aber auch gesagt. Gerade Minor-Nummern, also 2.12, 2.14, etc. sind stabile Versionen, wohingegen 2.13, 2.15, etc. Entwicklerversionen sind. 2.12.3 ist also eine neue Version der stabilen 2.12-Serie. Die aktuelle Entwicklerversion ist übrigens 2.13.11 (gestern erschienen). Bitte korrigiere das. -- Lemzwerg 17:11, 17. Jan. 2010 (CET)
Entschuldige, da habe ich bei deiner Änderung nicht richtig hingeguckt, nur die 3 hinten gesehen und mein schräges Hirn hat das fälschlicherweise mit der 13 in der Mitte der Entwicklerversion durcheinandergeworfen. Tut mir leid, da korrigiere ich mich mal gleich selbst wieder zurück. --Zupftom 21:34, 17. Jan. 2010 (CET)

Mensuralnotation

Hallo Zupftom, so ganz habe ich das mit dem Verrutschen nicht verstanden, aber ich gehe mal davon aus, dass du Recht hast. Trotzdem hatte ich mir eingebildet, dass alles besser wäre als diese wirklich unmögliche Form, so wie sie jetzt ist. Übrigens bevor ich deine Rückänderung bemerkt hatte, habe ich versucht, am Anfang des Artikels eine etwas bessere Formatierung hinzukriegen, um dem Lachkrampf vorzubeugen, den jeden Leser schütteln dürfte, der diese Monsternoten sieht. Ist wahrscheinlich auch noch nicht optimal, aber schlechter als es jetzt ist, wird es wohl kaum sein. Ich hoffe also mal, dass da jetzt kein Grund besteht, das wieder rückgängig zu machen. Ansonsten würde ich anregen, dass du dir auch mal ein paar Gedanken mahst, wie man die Form besser hinkriegen könnte. Apropos: Willst du dir wirklich diesen Knochenjob Schulmusik antun...? Ich hab's zum Glück hinter mir und mache drei Kreuze hinterher! Schöne Grüße--Balliballi 14:11, 29. Apr. 2010 (CEST)

Hallo Balliball,
du bist also Ex-SchMu? Na, ich werde mal sehen, was mir das Referendariat so bringt. Andere Traumjobs hätte ich auch, aber die sind eher so Richtung Wolkenkuckucksheim einzuordnen ;-).
Das mit dem Verrutschen meinte ich so: Je nachdem, welche Schriftgröße der Nutzer verwendet (also ob er z.B. einen anderen Skin als den Standard benutzt oder im Browser besondere Einstellungen für die Schriftgröße gewählt hat) liegen die Zeilen weiter auseinander/dichter beisammen, so dass die Bezeichnungen nicht mehr unbedingt neben der Noten liegen. Die ordentliche Lösung wäre m.E. eine Tabelle, die links die Grafiken und rechts die Bezeichungen enthält. Ich habe gerade mal nachgeschaut, ich habe eigentlich alle Zeichen bis auf die Semifusa als SVG da, die könnte ich hochladen und eine Tabelle basteln. Die Semifusa lässt sich ja einfach aus den Teilen der Fusa basteln. Ist die Halslänge korrekterweise bei beiden gleich, oder verlängert sich der Hals für das zweite Fähnchen? (Gibt's da überhaupt eine Regel??) Mit den SVG-Dateien kann man dann ja auch mal sehen, ob man vielleicht eine schöne Lösung für die Abbildungen weiter oben hinbekommt. Haben die schwarze Maxima und Longa einfach die gleiche Form wie die weißen? Dann würde ich die auch noch aus den vorhandenen Zeichen abwandeln und hochladen. Vielleicht nicht sofort, aber demnächst. Wenn nichts kommt, kannst du mich ja nochmal dran erinnern, sonst siegt noch mein innerer Schweinehund. --Zupftom 22:31, 29. Apr. 2010 (CEST)

Challenge

Hallo, eben habe ich einen richtigen Hammer entdeckt, Datei:Spain_traffic_signal_s510.svg mit 491.954 (!) Bytes. Ein wenig kleiner kann ich das schon bekommen, aber etwas fehlt mir wohl noch. Im Bild sollte

  1. der weiße Hintergrund,
  2. der rote Schrägstrich, und
  3. der schwarze Rand

sein. Meine Variante 

<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" width="40" height="10">
<rect width="40" height="10" fill="#FFF"/>
<path stroke="#F00" d="M0,9L40,1"/>
<path stroke="#000" d="M.5,.5h39v9H.5z" fill="none"/>
</svg>

ist doch noch verbesserungsfähig (außer, dass "red" ein Byte spart gegenüber "#F00")? Ist die Deklaration des weißen Hintergrundes irgendwie einfacher machbar, in Zeile 2? Oder hast du sonst Ideen? Gruss -- sarang♥사랑 19:04, 3. Jun. 2010 (CEST)

Wow, das ist wirklich ein richtiger Hammer! Bis man da erst mal durchsieht, was überhaupt Sache ist! Wenn man nur alle Namespaces außer SVG rausschmeißt kommt man schon auf 2.452 Bytes runter, das wären dann 5 Promille! Wenn man dann noch alle Redundanzen aufräumt, gibt's 854 Bytes, also unter zwei Promille. Mit deiner Reduktion kommst du ja sogar schon auf eine knappe halbe Promille.
Ein paar Bytes kann man noch sparen, indem man das Rechteck als Pfad angibt. Man kann gleich die Füllung und die Umrandung zeichnen, wenn man den Schrägstrich als gefüllten Umriss angibt:
 <?xml version="1.0" standalone="no"?>
 <svg xmlns="http://www.w3.org/2000/svg" width="40" height="10">
 <path d="m.5,.5h39v9H.5z" stroke="#000" fill="#fff"/>
 <path fill="#F00" d="M1,8.8v.2h3.5L39,1.2v-.2h-3.5z"/>
 </svg>
Gesamtgröße 218 Bytes, also gut unter einer halben Promille. Sollte man nicht für möglich halten! Noch eine andere Möglichkeit, allerdings 6 Bytes größer:
 <?xml version="1.0" standalone="no"?>
 <svg xmlns="http://www.w3.org/2000/svg" width="40" height="10">
 <path stroke="#F00" fill="#fff" d="m-2,10h44V0L-2,10V0h44"/>
 <path d="m.5,.5h39v9H.5z" stroke="#000" fill="none"/>
 </svg>
Hier zeichnet der rote Pfad den Hintergrund mit. Ein letzter Versuch, das Clipping des <svg>-Elements auszunutzen - allerdings nochmal 8 Bytes größer:
 <?xml version="1.0" standalone="no"?>
 <svg xmlns="http://www.w3.org/2000/svg" width="40" height="10">
 <path d="m.5,.5h39v9H.5z" stroke="#000" fill="#fff"/>
 <svg height="8" y="1">
 <path stroke="#F00" d="M1,8.5l38,-9"/>
 </svg>
 </svg>
--Zupftom 22:38, 3. Jun. 2010 (CEST)

Da habe ich nicht vergeblich auf deine Genialität gehofft, und darauf, wieder dazulernen zu können. Auf Variante 1 und 2 hätte ich kommen sollen, 3 enthält mir noch nicht bekannte Strukturen. 2 und 3 erscheinen mir eleganter, auch wenn sie geringfügig größer sind als Var. 1, für die wiederum der Vorzug der Einfachheit spricht. Hier wäre es angemessen, die Varianten in einer Diskussionsseite zum Bild aufzuzeigen.

Womit editierst denn du? Sowohl bei notepad.exe, meinem bevorzugten Editor, als auch bei wordpad.exe habe ich 221 Bytes, wenn du 218 angibst. Könnte es an den Linefeeds liegen? Wenn du deine Lösung uploaden willst, kannst du auch gleich richtig kategorisieren (Traffic signals in Spain); da hat es noch mehr Hämmer….

Da gibt es noch ein Bild, File:Entrada pueblo.svg, das viel einfacher war, und mir dennoch Probleme bereitet hat. Schon mehrmals musste ich nach dem Hochladen feststellen, dass die Bilder dann ganz anders aussehen als im offline-Test, wo sie o.k. schienen. Insbesondere bei fehlerhaften SVGs (CentreOfGravity, Lilith symbol) sind die offline-Ansichten sowohl von Firefox als auch vom MS-IE ganz anders als die dann von Wiki erzeugten PNGs. Die Version von 17:40 mit impliziter stroke-width sieht (bei mir online) völlig kaputt aus, deshalb habe ich sie gleich überspeichert. Falls sie bei dir korrekt angezeigt wird: der Rand scheint oben ½pt, rechts und unten 1½pt, und links von unten 1½pt nach oben ½pt. Ich habe noch keinen Fehler gefunden, vielleicht siehst du die Ursache und kannst mir helfen. -- sarang♥사랑 09:20, 4. Jun. 2010 (CEST)

Vielleicht liegt es an den kleinen Abmessungen? Auch im Bild City locator 20 sieht es verrutscht aus, der rechte Horizontalstrich ist zu weit rechts − auch schon in der Vorversion. -- sarang♥사랑 10:43, 4. Jun. 2010 (CEST)
Eigentlich wären solche stupiden Abspeckaufgaben was für einen Bot. Insbesondere die Illustrator-Dateien sind dermaßen gigantisch, wenn man die direkt als SVG einbinden würde hätten solche Seiten wie ca:Senyals_de_trànsit_d'indicació horrende Ladezeiten. Es hat keinen Zweck, sich da an allen betroffenen Dateien sportlich betätigen zu wollen. Die Entfernung aller SVG-fremden Namespaces (außer XLink natürlich, vielleicht noch sinnvolle Metadaten) würde da schon extrem weiterhelfen. Keine Ahnung, ob so ein Bot überhaupt möglich ist, mit sowas habe ich mich noch kein bisschen beschäftigt.
Eigentlich wäre es sogar sinnvoll, ein ähnliches Modell wie jetzt zu haben, dass aus einer Quell-SVG-Datei eine Präsentations-SVG-Datei (statt einer PNG-Datei) erstellt wird. Ein großer Vorteil der Vektorgrafiken ist ja, dass sie viel besser weiterverwendet werden können als Rastergrafiken. Da sollte man im Allgemeinen (bei nicht-trivialen Grafiken) vielleicht die Editor-spezifischen Tags drinlassen, die könnten ein weiteres Bearbeiten im jeweiligen Editor erleichtern. Illustrator schreibt wohl einen Binär-Dump der Original-Datei in die SVG-Datei (bei PDF und EPS macht er das offenbar ebenso). Ich vermute allerdings stark, dass es auch eine Export-Funktion geben müsste, die das nicht tut. Da müsste man die Ersteller mal sensibilisieren.
Was die Dateigrößen angeht: Ich arbeite unter Linux (mit SciTE), die Unterschiede liegen also wirklich an den Umbrüchen. Unter Linux kann ich mir übrigens mit rsvg-view oder eog anschauen, wie die Grafik wahrscheinlich online ausschauen wird (abgesehen von Fonts). Wikimedia benutzt die gleiche Bibliothek. Für Windows gibt's die Programme glaube ich nicht, die Bibliothek allerdings schon. Es könnte also einen anderen rsvg-basierten Viewer für Windows geben - das weiß ich jetzt nicht.
Das Problem mit File:Entrada pueblo.svg und auch meiner Lösung (!) scheint zu sein, dass librsvg das erste "M.5,.5" nicht versteht. Das Ergebnis ist das von "M0,0". Das "H.5" am Ende ist aber wieder richtig, es kann also nicht daran liegen, dass das Weglassen der Null generell nicht unterstützt wird. Ich habe mal einen Bug gemeldet. Da kann man auch sehen, dass .5 nicht immer als 0 oder 0.5 interpretiert wird, sondern manchmal auch als sehr viel größerer Wert. Dass sowas grundlegendes noch keinem aufgefallen sein soll! --Zupftom 15:09, 4. Jun. 2010 (CEST)

Danke. -- sarang♥사랑 18:07, 4. Jun. 2010 (CEST)

Und schon gibt es ein Patch! Werde ich demnächst mal ausprobieren. Wie lange es braucht, bis das auf die Wikimedia-Server durchsickert ist halt die Frage. Aber da kann man vielleicht auch an die Admins herantreten. --Zupftom 11:03, 5. Jun. 2010 (CEST)

Hallo Thomas, nach den SVG-specs scheint nicht nur d="m.5,.5h39v9H.5z" gültig, sondern sogar d="m.5.5h39v9H.5z" − nach einer Fraktion muss weder Space noch Komma sein, so wie nach einem Command letter (nach einer Integer natürlich schon, sonst wäre es ja der Fraktionsteil dazu). Mit Firefox und MS-IE funktioniert es offline richtig! Und dank deiner Intervention vielleicht bald auch in Wikipedia…
Bei CentreOfGravity mit dem dashoffset dachte ich dass es mit -14 funktionieren sollte; bei einer Gesamtlänge von (ca.) 98 sollte -14 und +84 etwa dasselbe ergeben – wie aber zu sehen ist, mitnichten, die Version von 14:06 sah zwar offline richtig aus, nicht jedoch online. Wieder ein bug - oder ein Fehler von mir, der unterschiedlich behandelt wird? -- sarang♥사랑 18:27, 5. Jun. 2010 (CEST)

Du hast recht mit der Pfad-Syntax, denke ich! Ich habe das Patch nochmal gepatcht, so dass diese Syntax auch akzeptiert wird. (Das ist mein erstes Patch überhaupt - besteht zwar nur aus dem Auskommentieren einer Zeile, bin aber trotzdem ein bisschen stolz drauf ;-)). Damit ist die Sache aber noch nicht ausgestanden, es gibt noch weitere Problemfälle.
Ich habe gleich noch einen Bug gemeldet, mit dem sich noch ungefähr sieben Bytes sparen ließen ;-). Bei dem habe ich aber wohl selbst keine Chance, irgendwas zu reparieren.
stroke-dashoffsets wird laut den Specs übrigens als length angegeben, und negative Werte werden da - leider - ausgeschlossen, auch wenn es einige Implementierungen bei manchen Dingen (wie bei stroke-dashoffset) fälschlicherweise erlauben. Finde ich eigentlich nicht so gut, wenn die sich bewusst über die Spezifikationen hinwegsetzen. Das gibt einem den Eindruck, man hätte alles richtig gemacht - hat man aber nicht, und irgendwo erwischt's einen dann. (Der w3.org-Validator untersucht die Syntax der Attribute auch nicht und sagt, der Code sei valide.) Allerdings gibt es viele Situationen wo negative Werte nützlich wären. Etwa, wenn man ein Rechteck mit der Maus ziehen lässt, dessen Startpunkt fest ist und die gegenüberliegende Ecke sich "bewegt". Statt einfach width und height entsprechend der Mausposition zu ändern muss man dann den Originalpunkt irgendwo speichern, kontrollieren, ob sich die Maus links, rechts, oberhalb oder unterhalb befindet und alle vier Positionsattribute jedesmal setzen - lästiger Mehraufwand. Gut, mit einem path kann man das umgehen, mit einem rect wär's halt noch einfacher, weil man einfach x/y so lassen kann und den Startpunkt nicht noch extra irgendwo speichern oder das d-Attribut analysieren muss, um das erste moveto zu belassen und Rest zu ändern. Egal...
Komisch übrigens, dass rsvg bei Rechtecken negative Werte unterstützt, während Opera, Google Chrome, Firefox, Batik und Inkscape das nicht tun - bei stroke-dashoffset ist es genau umgekehrt. Negative stroke-widths akzeptiert wiederum nur Opera. Ein einziges Durcheinander also. ..Zupftom 03:00, 6. Jun. 2010 (CEST)

Danke, Fachmann der Specs! Also wieder mal ein Fehler, der unterschiedlich behandelt wird - im einen Fall toleriert und so interpretiert, wie es (mir) sinnvoll erscheint, und dann nicht, was nach dem Austesten überrascht. Immerhin weiß ich es jetzt und kann künftig darauf achten; schließlich möchte ich syntaktisch richtige Dateien erstellen.
Bei SVG scheinen unterschiedliche "Handschriften" erkennbar: einerseits die knappen Commandletters beim path oder das 'g' für Grouping, andrerseits rechte Wortungetüme wie 'stroke-dashoffset' und dergleichen. Mich veranlaßt das, zB ein Rechteck lieber als path denn als rect (mit height und width) zu zeichnen - obwohl ich ja wirklich ein Rechteck und keinen Pfad meine. Aber ich bin vermutlich der einzige, der sich zusätzlich zur langatmigen Notation noch die Möglichkeit einer Art Kurzschrift wünschte, und damit keineswegs im Trend. Nochmals, danke für deine kundige Unterstützung. -- sarang♥사랑 13:29, 6. Jun. 2010 (CEST)

Fachmann der Specs bin ich nicht unbedingt, habe einfach nachgeschaut :-). Die Überlegung hinter der komprimierten Pfad-Syntax war glaube ich, dass Pfade den Großteil vieler SVGs ausmachen würden. Wenn du dir sowas wie diesen Mülleimer anschaust, dann stimmt das auch - ist aber einer dieser Fälle, die radikalst entschlackbar wären.
Eine Kurzschrift finde ich persönlich nur bedingt sinnvoll. Ich finde es gerade gut, dass die Attribute sehr selbsterklärend benannt sind. Dafür nehme ich die zusätzlichen Bytes gerne in Kauf. Man kann ja auch als SVGZ speichern, wenn's auf die Dateigröße ankommt. Ich vermute, der Kompressionsalgorithmus dürfte erkennen, dass sich da was ständig wiederholt, so dass auch längere Tag- und Attributnamen nicht mehr wirklich ins Gewicht fallen sollten(?). --Zupftom 21:19, 6. Jun. 2010 (CEST)

Mehr Hämmer

Hallo Thomas, vielleicht macht es dir Vergnügen, gelegentlich an diesen Kandidaten was zu ändern:

Sind alles Primitivgrafiken, mit einfachen Griffübungen auf Promille reduzierbar. Gruss -- sarang♥사랑 15:56, 19. Jun. 2010 (CEST)

Fehler
ok
Etwas sehr merkwürdiges - es scheint, dass sich beim SVG-Interpreting was geändert hat: Bei der Datei:Dice-6.svg sehen seit kurzem manche (kleinere) thumbs anders aus, es fehlen manchmal die Augen rechts oben und links unten. Es hängt mit der path-Länge zusammen, die ich ganz exakt angab, manchmal scheint es nicht auszureichen. Vielleicht hast du eine Idee – bug report, oder sonst was. Eigentlich sehe ich keinen Bedarf, dass ich am Bild was ändere.
Vielleicht sieht es bei anderen anders aus: nebenstehend erscheint bei mir der Fehler im 64px-Bild, aber nicht im 48px-Bild! Sehr merkwürdig. Gruss, -- sarang♥사랑 12:52, 20. Jun. 2010 (CEST)
Die stroke-dasharrays mit Nuller-Strichlängen sind eine heikle Sache. Alle Renderer, mit denen ich die Datei geöffnet habe und die nicht von vornherein anderweitige Probleme hatten, zeigen für einige Zoomstufen die Punkte rechts oben und links unten nicht (das sind außer librsvg noch Firefox (3.6.5) und Batik (1.7)). Ursache sind mit ziemlicher Sicherheit Rundungsfehler. Das heißt, bei bestimmten Auflösungen ist für die Software der Abstand zwischen Start- und Endpunkt einer Linie ein My kleiner als das Doppelte der Zwischenraum-Länge. Deshalb gibt es nur zwei Punkte innerhalb der Linie. Ich würde empfehlen, die Linie etwas länger zu zeichnen als theoretisch nötig. Bei Bild:Mayan00_19.svg habe ich das auch so gemacht. Da gibt es folgendes dasharray:
   stroke-dasharray="0,45,0,10,0,35,0,10,0,10,0,25,0,10,0,10,0,10"
Die Teillängen summieren sich auf 165, im path habe ich dann für die Gesamtlänge der einzelnen "gepunkteten Linien" jeweils 170 gewählt:
   d="
   M74,41h170
   M74,113h170
   M74,185h170
   M74,257h170"
Für den Würfel würde ich deshalb folgenden Pfad vorschlagen:
   <path d="M117,117H514M435,440H38"/>
Abgesehen von den Rundungsfehlern zeigt Opera (10.10) immer nur drei Punkte. Chrome (6.0.437.1) zeigt gar keine Punkte und Inkscape (0.47) zeigt zwei durchgehende Linien. Wirklich gut wird das Attribut also momentan nicht unterstützt. --Zupftom 16:13, 20. Jun. 2010 (CEST)

Wenn so viele Renderer solche Probleme haben, werde ich dem doch begegnen müssen. Ich verwende nun ausreichend lange Strichlängen, und wenn ich beide Linien von rechts nach links zeichne, liegt der Endpunkt zwischen -unendlich und <117, also kann ich ihn auch einstellig angeben und so sogar etwas mehr sparen, als bisher (vom rechten Ende der oberen Linie relativ das rechte Ende der unteren Linie ansteuern und diese nach links ziehen). Wenn ich uploade, zeigt das linke Bild nicht mehr den Fehler.
Aber die Probleme von Chrome und Inkscape bestehen weiterhin, wenn die mit der Nulllänge nicht zurecht kommen. Das macht dasharray mit Längen zu knapp bei Null sehr fragwürdig! Wenn es aber zumindest in Wikimedia immer richtig angezeigt wird, wie ich dich verstehe, lasse ich es hier dabei und halte mich künftig eher zurück. Jedenfalls danke, Thomas, ich habe wieder dazugelernt. -- sarang♥사랑 10:48, 21. Jun. 2010 (CEST)

Ich sehe das so: Rundungsfehler sind unvermeidbar. (Oder sagen wir's so: In diesem Zusammenhang sind sie vielleicht theoretisch, aber nur mit unverhältnismäßigem Aufwand vermeidbar, der den Implementierungen nicht zuzumuten ist und zudem deutlich auf deren Performance drücken würde.) Das heißt, wenn die Endpunkte hier verschwinden ist das unerfreulich, aber kein Bug. Man kann sich streiten, ob die Specs von SVG 1.1 exakt vorschreiben, was bei einem dasharray mit Nullen passieren soll. In SVG 1.2 Tiny ist das schon sehr viel präziser formuliert, aber es wird auch explizit gesagt, dass es noch gewisse Fälle gibt, die mit SVG 1.2 Tiny nicht abgedeckt sind und die man deshalb vermeiden sollte.
Wenn ich mir's recht überlege, sollte man vielleicht der Form halber version="1.2" angeben, wenn man stroke-dasharray mit Nullen benutzt. Inkscape hat insofern ein Problem als es vorgibt, 1.2 zu unterstützen (schreibt es zumindest in die Datei). Für Chrome und Inkscape kann man sich zwar mit "ausreichend von Null verschiedenen" Werten durchmogeln, ich persönlich habe aber kein Problem damit, die "richtige" Lösung zu benutzen. Bei Wikimedia funktioniert es schließlich, und was Chrome und Inkscape betrifft ist es in meinen Augen ein Defizit der Implementierungen, das über kurz oder lang behoben werden dürfte. Für Chrome gibt es zumindest schon mal einen Eintrag im Bugtracker. Ich weiß aber nicht, ob's auch tatsächlich einen entsprechenden Eintrag bei Skia gibt, wie dort angedeutet. Für Inkscape habe ich keinen entsprechenden Bug gefunden. Da ich quasi schon dabei bin könnte ich bei Gelegenheit auch da mal eine Meldung machen ;-). --Zupftom 12:58, 21. Jun. 2010 (CEST)

Frage zu SVG

Hallo Thomas, falls du mal etwas Zeit hast: ich würde gerne von deiner SVG-Expertik was abfragen. Es geht um die Datei Fotografieverbot. Das Rechteck (die Kamera) und der Kreis (das Objektiv) lassen sich so zeichnen: 

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 574 574">
<path d="m121,238v147h332.5v-147zM287,250a61,61 0 0,1 0,122 61,61 0,0 1 0-122zm0,8a53,53 0 0,1 0,106 53,53 0 0 1 0-106z"/>
</svg>

aber ich werde den Verdacht nicht los dass das auch einfacher gehen müsste als mit vier Halbkreisen mittels Ellipsenkommandos. Mit Clippen ist es noch umständlicher. Du hast da sicher eine Idee - oder weisst zumindest definitiv, wenn es nichts besseres gibt. Gruss, -- sarang♥사랑 11:52, 13. Sep. 2010 (CEST)

Tut mir leid, ich glaube, da kann ich auch nichts rausholen. Ich habe überlegt, die schwarzen äußeren und weißen inneren Kästchen als dicke Linien zu zeichnen. Das gibt dann aber insgesamt so viele Elemente, dass man rein von der Dateigröße (und das ist ja der Sport) keinen Gewinn hat. Denkbar wäre auch ein großes schwarzes Rechteck, das mit Weiß überzeichnet wird, da hat man aber den gleichen Effekt.
Was ganz anderes: Ich finde, dass man den schwarzen Kreis an den Anfang stellen und weiß füllen sollte, denn man kann ja nie wissen, was für eine Farbe im Hintergrund gerade durchscheint - wenn du die Mehrbytes verschmerzen kannst ;-). --Zupftom 13:12, 15. Sep. 2010 (CEST)
Danke für deine Antwort.
Natürlich kann das ganze auch anders gezeichnet werden, doch so einfach ein fill=none mit weiß zu ersetzen (oder auch umgekehrt) ist dann eine andere Zeichnung. Mein Interesse ist es, das Bild genau (oder zumindest in der äußeren Erscheinung genauso aussehend) etwas geschickter darzustellen.
Der bug mit den Dezimalstellen: die PNG-Umsetzung in Wikipedia erscheint noch unverändert fehlerhaft? Gruss, -- sarang♥사랑 08:28, 18. Sep. 2010 (CEST)

Terzen ... mitteltoenig.ogg klarer machen

Hallo Zupftom, Du bist bestimmt derselbe wie auf wikimedia-commons. Könntest Du wegen Deiner Datei "Terzen pythagoreisch - mitteltoenig.ogg", die bei Stimmung (Musik) verwendet wird, mitdiskutieren? --PG64 10:13, 2. Jan. 2011 (CET)

SVG Problem

Hallo Thomas, wieder mal bin ich völlig ratlos. Ich habe die Grafik Datei:Sierpinski9.svg erstellt, offline ist alles so wie gewünscht. Nach dem Hochladen staune ich, es sieht total anders aus. Weil ich vermutete, dass die Folge -.5.866 noch nicht funktioniert habe ich das in -.5 .866 geändert und als neue Version darüber geladen; ohne die gewünschte Wirkung.
Es sieht so aus: Beide thumbs der Historie erscheinen korrekt (soweit das bei der Größe beurteilbar ist), sowohl was die Strukturen als auch die Ausdehnung (bis an den Rand) betrifft. Hingegen zeigt das png der Ansicht wirres Gestrichel, das links unten und oben über den Rand hinausgeht. Ich kann nichts finden, wo ich mich gegen die specs versündigt hätte. Ehe ich weitere Versuche hochlade, die Frage an dich, ob du schnell erkennen kannst, was da klemmt. Danke-- sarang♥사랑 11:03, 1. Feb. 2011 (CET)

Bei solchen Fällen kann man die Dateien mal mit --renderer-workaround durch Scour jagen. Da kommt dann das hier raus:
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <svg width="512" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" height="444">
  <g id="g">
   <g id="f">
    <g id="e">
     <g id="d">
      <g id="c">
       <g id="b">
        <g id="a" stroke="#000" stroke-width=".3" fill="none">
         <path d="m254 3.464h4l-0.5-0.866-0.5 0.866-0.5-0.866-0.5 0.866-0.5-0.866-0.5 0.866-0.5-0.866zm0.5-0.866h1m1 0h1l-0.5-0.866-0.5 0.866m-1 0l-0.5-0.866-0.5 0.866m0.5-0.866h2l-0.5-0.866-0.5 0.866-0.5-0.866zm0.5-0.866h1l-0.5-0.866z"/>
        </g>
        <use xlink:href="#a" transform="translate(-2 3.464)"/>
        <use xlink:href="#a" transform="translate(2 3.464)"/>
       </g>
       <use xlink:href="#b" transform="translate(-4 6.928)"/>
       <use xlink:href="#b" transform="translate(4 6.928)"/>
      </g>
      <use xlink:href="#c" transform="translate(-8 13.846)"/>
      <use xlink:href="#c" transform="translate(8 13.846)"/>
     </g>
     <use xlink:href="#d" transform="translate(-16 27.713)"/>
     <use xlink:href="#d" transform="translate(16 27.713)"/>
    </g>
    <use xlink:href="#e" transform="translate(-32 55.426)"/>
    <use xlink:href="#e" transform="translate(32 55.426)"/>
   </g>
   <use xlink:href="#f" transform="translate(-64 110.85)"/>
   <use xlink:href="#f" transform="translate(64 110.85)"/>
  </g>
  <use xlink:href="#g" transform="translate(-128 221.7)"/>
  <use xlink:href="#g" transform="translate(128 221.7)"/>
 </svg>
Das ist übrigens so ein schöner Fall, wo ich lieber die Struktur verdeutliche anstatt "Bytegeiz" zu betreiben. Das hier wäre mein Favorit:
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <svg width="512" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" height="444">
   <g id="level_9">
     <g id="level_8">
       <g id="level_7">
         <g id="level_6">
           <g id="level_5">
             <g id="level_4">
               <g id="level_3">
                 <g id="level_2">
                   <polygon id="level_1" points="0,0 1,0 .5,.866" stroke="black" fill="none" stroke-width=".3"/>
                   <use xlink:href="#level_1" x="1"/>
                   <use xlink:href="#level_1" x=".5" y=".866"/>
                 </g>
                 <use xlink:href="#level_2" x="2"/>
                 <use xlink:href="#level_2" x="1" y="1.732"/>
               </g>
               <use xlink:href="#level_3" x="4"/>
               <use xlink:href="#level_3" x="2" y="3.464"/>
             </g>
             <use xlink:href="#level_4" x="8"/>
             <use xlink:href="#level_4" x="4" y="6.928"/>
           </g>
           <use xlink:href="#level_5" x="16"/>
           <use xlink:href="#level_5" x="8" y="13.856"/>
         </g>
         <use xlink:href="#level_6" x="32"/>
         <use xlink:href="#level_6" x="16" y="27.712"/>
       </g>
       <use xlink:href="#level_7" x="64"/>
       <use xlink:href="#level_7" x="32" y="55.424"/>
     </g>
     <use xlink:href="#level_8" x="128"/>
     <use xlink:href="#level_8" x="64" y="110.848"/>
   </g>
   <use xlink:href="#level_9" x="256"/>
   <use xlink:href="#level_9" x="128" y="221.696"/>
 </svg>
Also, "Polygon" statt "Path" (das beschreibt besser, um was es sich handelt) und alle Ebenen durch <use> mit deskriptiven IDs realisieren. Die Sache hat in einigen SVG-Implementierungen leider den Haken, dass sie mit der exponentiellen Zunahme der Elemente nicht gut klar kommen (wahrscheinlich kommt es darauf an, wie sie das "<use>n von <g>s" implementieren), aber librsvg macht das hervorragend. --Zupftom 14:53, 1. Feb. 2011 (CET)
Apropos Bytegeiz: Mit PostScript geht's schön bytegeizig:
 matrix currentmatrix
 
 /MATRIX matrix def
 
 0 0 moveto
 1 0 lineto
 -.5 .866 lineto
 closepath
 
 9 {
   //MATRIX currentmatrix pop
   false upath
   1 0 translate
   dup uappend
   -.5 .866 translate
   uappend
   //MATRIX setmatrix
   2 2 scale
 } bind repeat
 
 setmatrix
 
 .3 setlinewidth
 stroke
 showpage
Aber Ghostscript macht das exponentielle Wachstum auch zu schaffen. Nach acht Iterationen ist (mit diesem Code) Schluss. --Zupftom 15:20, 1. Feb. 2011 (CET)

Da bringst du wieder viel Interessantes. Mit USE und x/y-Angabe, ohne transform, hab ich es versucht aber nicht hinbekommen. Wie du gesehen hast habe ich die ersten 7 Dreiecke mit dem path gezeichnet und so zwei Iterationen eingespart; eleganter ist es natürlich von einem Ursprungselement auszugehen. Mir ist nicht klar geworden ob du eine Vermutung oder Gewissheit hast, warum es offline tadellos geht und in den Commons nicht. Ich habe nicht gedacht dass es an der Iterationszahl liegt, weil etwas völlig anderes gezeichnet wird. Soll ich mal sehen, ob deine 2. Variante besser aussieht in den Commons – oder hast du da bereits Erkenntnisse? Für mich ist es immer wieder verblüffend, wenn etwas nach dem Hochladen ganz anders aussieht als offline getestet. Das ist mir ähnlich mit Commons:User_talk:Sarang#File:Deutsche_Turnerschaft.svg ergangen, da waren die Strukturen nicht mehr parallel. Auch ein Rätsel. -- sarang♥사랑 18:51, 1. Feb. 2011 (CET)

Der workaround hat einfach vor jeden Dezimalpunkt eine Null gestellt; sicher auch wo librsvg es ohne die Null ebenso verstanden hätte; aber ich kenne den librsvg und seine Macken zu wenig. In der "Turnerschaft" habe ich mehrere Angaben ohne die Vornull: l.5/q.5/l-.5/q-.5; ich dachte direkt nach einem Command-letter wie q oder l sei das ok., nur Angaben wie .5.5 machten Probleme. Du weißt doch mehr darüber, was geht und was nicht? -- sarang♥사랑 19:20, 1. Feb. 2011 (CET)

Nun hab ich den Turnerschaftsfehler, dank deiner Anregungen, finden können. ein l.5 in ein l0.5 geändert, und schon sind die Linien parallel. Es hat noch eine Ungenauigkeit, weil ich die q.5 gelassen habe. l-.5 und q-.5 scheint verstanden zu werden. Seltsam.-- sarang♥사랑 20:26, 1. Feb. 2011 (CET)

Noten scannen

Hi Zupftom, ich habe mich gestern beim Editieren von Optische Notenerkennung anfangs vergessen einzuloggen, sodass es jetzt einer manuellen Sichtung bedarf. Die Rechte dafür habe ich leider noch nicht. Schaust du bitte über den Artikel noch mal drüber und sichtest ihn anschießend. Danke vorweg und Grüße, -- Cachsten 09:48, 5. Mai 2011 (CEST)

Aber gerne! --Zupftom 10:17, 5. Mai 2011 (CEST)
Danke! :) -- Cachsten 10:33, 5. Mai 2011 (CEST)

SVG:Ellipse

Hallo Zupftom, jetzt habe ich versucht, was Vernünftiges als Anregung zum Abschnitt "Ellipse" beizutragen, und da reagiert keiner - schnief ;-) .
Ich frage mal, ob die Anregungen als solche halbwegs akzeptabel (akzeptiert) sind, ich wollte sie nicht gerade eigenmächtig in den Artikel hineinredigieren, aber tue das natürlich, wenn man (?) das gutheißen würde. Ansonsten gebe ich auch sofort eine Ruhe, wenn man die Änderungswünsche anderweitig berücksichtigt. Grüße -- Hll001 21:40, 13. Okt. 2011 (CEST)

Ich war etwas irritiert, dass du dich auf der Diskussionsseite selbst rückgänig gemacht hast. Ich hätte sonst "Sei mutig" druntergesetzt. Ich denke, du hast absolut recht. Vieles, was Google aufstöbert, scheint von Wikipedia kopiert oder zumindest "inspiriert" zu sein. Ist schon spannend, wie Fehler aus der Wikipedia schnell überall übernommen werden. --Zupftom 22:32, 13. Okt. 2011 (CEST)
Ich rede hier nicht über Google, sondern über den Artikel SVG. Habe ich jetzt bei Dir gelesen, dass ich mutig sein soll und meine "Weisheiten" einfach in den Artikel (!) reinredigieren? Ich will auch nicht unbedingt die Diskussions-Seite von SVG editieren, sondern den Artikel selber.

Übrigens: Die Selbst-Rückgängig-Machung war die Folge einer Fehlbedienung. Ich weiß nicht genau, wieso, aber auf der Diskussionsseite des SVG-Artikels habe ich immer so ein doofes graues Kästchen bekommen, das meinen Beitrag dann immer irgendwie verschandelt hat. Grüße -- Hll001 19:37, 14. Okt. 2011 (CEST)

Mit Google habe ich mich auf das von dir zitierte "bekannte Suchprogramm" bezogen. Dort stößt man bei der Suche nach "Halbachsenradius" häufig auf die exakt gleiche Formulierung, die genau so etwa 2006 im Artikel stand. Also, der Erfinder des Begriffs "Halbachsenradius" ist vermutlich Wikipedianer.
Klar würde ich die Änderungen einfach im Artikel vornehmen. Da steht offenbar schon mindestens ein halbes Jahrzehnt Mist und keiner hat es bisher in Frage gestellt (auch ich nicht). Es kann nur besser werden. --Zupftom 22:57, 14. Okt. 2011 (CEST)

PostScript

Hallo! Die Angabe stammt direkt aus der englischen Wikipedia. Siehe en:PostScript#PostScript_3 ebenda. Daher kann ich nichts über die Richtigkeit aussagen.

lg -- PW 17:19, 12. Dez. 2011 (CET)

PostScript

Hallo! Die Angabe stammt direkt aus der englischen Wikipedia. Siehe ebenda.

Daher kann ich nichts über die Richtigkeit aussagen.

lg

-- PW 17:21, 12. Dez. 2011 (CET)

Review-Prozess Notensatzprogramm

Hi Zupftom, hast du Lust dich zu beteiligen? -- Cachsten (Diskussion) 15:25, 2. Feb. 2013 (CET)

Hallo Cachsten! Danke für dein großartiges Engagement zu dem Artikel, aber ich stecke momentan in allen möglichen anderen Notensatz betreffenden Angelegenheiten und habe wenig Ruhe, den Artikel mitzuverbessern. Grüße --Zupftom (Diskussion) 12:48, 5. Feb. 2013 (CET)
Kein Ding, danke trotzdem, du hast ja dennoch ein paar gute Beiträge geleistet. Mittlerweile steht der Artikel zur Auszeichnung. Wenn du willst, schreib da kurz als Fachmann deine Meinung, denn ich denke es gibt nur wenige Wikipedianer, die von der Thematik Ahnung haben. ;) Frohes Schaffen! -- Cachsten (Diskussion) 14:49, 3. Apr. 2013 (CEST)
Noch was... Glaubst du nicht, dass das Score-Beispiel dennoch aussagekräftig ist!? Du hast geschrieben: "Die Quelle bezieht sich nicht auf das SCORE-Notensatzssystem sondern einen ebenfalls SCORE genannten Vorläufer im Bereich Audio-Synthese, daher vorerst auskommentiert". Damit hast du schon recht. Aber wenn man das Kapitel "Kapitel 6.6 Leland Smith's SCORE Code" in dem Buch liest, wird erklärt: "This programm (SCORE-11) uses Smith's input language with some extensions. The main difference in encoding is that Smith's programm names instruments rather than numbering them." Das Codebeispiel ist das einzige, an das man frei herankommt, ohne ein Buch aus ner Bib holen zu müssen. Denkst du nicht, dass das geht? SCORE-11 und SCORE unterscheiden sich soweit ich das einschätzen kann von der Syntax her bei diesem Beispiel nicht. -- Cachsten (Diskussion) 15:49, 3. Apr. 2013 (CEST)
Du hast schon recht, der Eingabetext ist stellenweise identisch, ich wollte bei Gelegenheit aber lieber ein neues Beispiel machen. Dieser Eingabetext ist auch etwas anders zu verstehen als bei Lilypond, ABC, DARMS o.ä., weil er normalerweise nicht in eine Datei abgespeichert wird. Wenn man das tut, dann funktionert es eher als eine Art Makro, das man einlesen kann. Eigentlich wird man von Score zeilenweise interaktiv dazu aufgefordert, die verschiedenen Eingaben zu tätigen. Die eigentliche Eingabephase ist auch lediglich die Vorstufe weiterer Operationen, d.h., im Anschluss wird man die Noten horizontal ausrichten, diverse Dinge wie Liedtext ergänzen, die im ersten Eingabeschritt nicht abgedeckt werden, Befehle zum Noten horizontal/vertikal ausrichten eingeben etc. Theoretisch kann man alle Bearbeitungsschritte als Text in einer großen Datei zusammenfassen, aber das würde man normalerweise nicht tun, weil man doch auf die Anzeige der Noten angewiesen ist. Da sich die Benutzerführung in verschiedenen Score-Versionen unterscheidet, sind auch die Tastendrücke ggf. andere.
Vorschlag: Ich setze das gleiche Beispiel neu in Score, gebe aber nur den Text des ersten Eingabschritts an. Die Grafik suggeriert auch, dass sie Score-Output sei. Da sollte echter Score-Output hin. --Zupftom (Diskussion) 21:16, 3. Apr. 2013 (CEST)
So, Beispiel erstellt. Du kannst den Eingabecode übrigens hier reinkopieren und schauen, was passiert! --Zupftom (Diskussion) 21:46, 3. Apr. 2013 (CEST)
Cool, danke dir. Kannte ich noch nicht. -- Cachsten (Diskussion) 09:15, 4. Apr. 2013 (CEST)

Score ist kein "Markup-Notensatzprogramm"

Warum nicht? -> "Die folgenden Notensatzprogramme bedürfen des Erlernens einer Musik-Auszeichnungssprache.", steht vor Beginn der Liste. Score braucht auch eine eigene Auszeichnungssprache, die es zu beherrschen gilt, demnach zähle ich es auch zu den Markup-Notensatzprogrammen. Soweit ich das sehe, hat sich das auch für das neue Winscore nicht verändert. Oder!? -- Cachsten (Diskussion) 23:59, 4. Apr. 2013 (CEST)

Abgerufen von „https://de.wikiup.org/index.php?title=Benutzer_Diskussion:Zupftom&oldid=117074886“