Beiträge von Seddi

    Daher interessiert mich auch das Problem so...


    Ist ja gut so, je mehr mitdenken desto eher kommen wir vielleicht auf den Punkt was da genau passiert. Mir persönlich ist es wurscht ob ich Mist programmiert habe, ob im Sedu was nicht stimmt (hab mir den Source von Pesi angeschaut, ich schliess den Sedu mal aus da sieht alles gut aus und lässt sich sowas auch nicht weiter beeinflussen) oder ob es da Treiberinterferenzen gibt. ich wills nur gern verstehen :)


    Der Punkt der mir zu denken gibt ist einfach die Latency Timeout des Treibers, wenn ich die verstelle funkioniert ja alles wie es soll. Ich kann mir nur nicht herleiten wie aus einer theoretischen Verzögerung des Frameendes von 16ms, ca 160ms werden in denen ich nix vom device bekomme.

    Seddi ich hab das so mitbekommen, dass der Pesi gute Ergebnisse mit einem Terminal Programm gemacht hat... also kanns ja nicht am FTDI Treiber oder Windows liegen?!


    Ich denke mit einem Terminalprogramm kann man das nicht wirklich verfolgen, da allein die Textausgabe auf dem Schirm schon der Datengeschwindigkeit hinterher hinkt. Da ja alle Werte kommen und nichts verschluckt wird sieht das auf dem Bildschirm dann schon sauber aus, lässt sich aber zeitlich m.E. nicht wirklich bewerten. Das es nicht am FTDI Treiber liegen kann wiederleg ich indem ich im Treiber den besagten Timeout auf 1 stelle und ich plötzlich kontinuierlich sauber die Daten bekomme ohne Auszeiten dazwischen.
    Wie gesagt, ich hab das schon in alle Richtungen debugged, ich bekomm da einfach keine Daten.


    Wie fragst du ab, ob Bytes im Buffer liegen?


    Ich mach nen read auf den seriellen und da ich Nonblocking bin, gibt er mir was er hat und wenn er nix hat gibt er mir sofort eine Null zurück.
    http://msdn.microsoft.com/en-u…/windows/desktop/aa363190(v=vs.85).aspx

    Zitat


    A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received.


    Damit kann ich ganz normal ReadFile auf den Port machen ohne das er blockt und erspar mir die vorherige Abfrage via COMSTAT.

    Ist wie gesagt ganz schön komisch, beim abfragen bekomm ich halt nur ruckweise Daten vom FTDI, wenn ich die 16 ms auf 1ms schiebe bekomm ich sie direkt. Hab das in alle Richtungen in der Software debugged, aber ich kann halt nur Daten verarbeiten, die ich auch über die Schnittstelle bekomme. Und bei 512er Frames und den 16 ms timeout bekomm ich sie nur ruckartig, da kann ich in der Software nichts beeinflussen. Steig da selber noch nicht wirklich durch wo es da klemmt, aber ich vermute fast Treiber/USB Frames und vielleicht auch noch Windows selbst das auch puffert, da kann dann weder ich in der Soft noch du was im Sedu dran ändern. Wie gesagt bei 500kbaud läufts oder auch bei 250k wenn ich das timeout im Treiber runterstelle.
    Die Verzögerung die ich noch hatte liegt vermutlich am Pult. Mir ist vorhin noch eingefallen, dass am kleinen Scannerpult (SGM Pilot 2000) das ich zum testen nutze die Kanäle vermutlich auf Soft eingestellt sind, sprich das Pult fadet auf den neuen Wert. Dadurch eine sichtbare Verzögerung bis zum Zielwert.



    ich schiebe den Fader am Pult in 1 Sekunde von unten nach oben, der Fader (und die Helligkeit) in Jinx springt dabei in ca. 6 Stufen nach oben - also ca. nur alle 166 ms ein neuer Wert erkannt.


    Die 160 ms beim ruckeln, kann ich nachvollziehen. In der Software bekomm ich da beim abfragen 3 mal hintereinander keine Daten von der Schnittstelle ( meldet einfach 0 Bytes in der Queue) , bei der 4. abfrage bekomm ich dann die ganzen Frames auf einen Schlag. Da ich alle 40 ms abfrage entsprechen die 3 Nullrunden ca 160 ms. Da gibt mir der Treiber einfach keine Daten, wenn ich den Timer verkürze und öfters abfrage bekomm ich entsprechend mehr Nullrunden. Ich hole prinzipiell alles aus der Queue was da ist, also lass mir vom Treiber auch nur 1Byte geben wenn er nicht mehr hat und bin Nonblocking. Also kann ich einen Fehler beim auswerten der Daten oder einem Bufferüberlauf in Jinx eigentlich ausschliessen. Vor allem da ich bei jeder Abfrage Daten bekomme, wenn ich im Treiber die 16ms auf 1 oder 2 runterstelle.


    dieses FTDI-Buffer-Problem hatte ich andersrum verstanden, also dass das eher zu Verzögerungen führt, wenn man kleinere Frames schickt


    Der FTDI Buffer spielt ja, nach meinem Verständnis, nicht nur bei kleinen Frames eine Rolle sondern auch wenn der Frame nicht durch die Buffergrösse teilbar ist. Ist der Buffer mal angenommen 64 Bytes gross, hast du das Problem bei einem Frame kleiner 64 Bytes. Aber eben auch bei einem grossen Frame mit sagen wir 288 Bytes. Da bekomm ich dann direkt 256 Bytes (4x Buffer) und die restlichen 32 lassen auf sich warten weil der Buffer nicht voll ist. Da tpm2 aber ein Endbyte hat, werte ich den Frame erst aus wenn ich das Endbyte habe, also verzögert sich das Ganze auch bei grösseren Frames.
    So les ich das auch hier heraus: http://www.ftdichip.com/Suppor…2B-04_DataLatencyFlow.pdf


    Weiterhin müsste auch noch die Blocksize im FTDI eine Rolle spielen. Standardmässig sind das 4k, sprich der USB wartet auf 4096 Bytes bevor er was weitergibt, auch das trägt dann auch zum Delay bzw. dem ruckeln bei. Das Ganze dann auch in Abhängigkeit mit dem latency timer. Nach allem was ich in den letzten Stunden zu dem Thema an Infos aufgetrieben habe, auch von anderen Projekten, ist wohl das Problem die standardmässige Blocksize und der Latency Timer und die saubere und vermutlich einzige Lösung ist das verkleinern des Latency Timeout im Treiber oder das erhöhen der Baudrate, wodurch das Problem aufgrund einer höheren fps Rate umgangen wird.


    das (Edit: 500k benutzen) wollte ich halt nicht machen, weil dann der Bootloader-Aufruf per String nicht mehr funktioniert - warum auch immer...


    Da hast du dir die Antwort doch schonmal selbst gegeben im SEDU Board Software Thread ;) ... "2. der Treiber wurde so modifizeirt, dass der FT232 mit 250 kBaud sendet/empfängt, wenn man am PC 115,2 k einstellt" ... Die Gui des Bootloaders öffnet die Schnittstelle mit 115,2k und somit mit 250k, deshalb funktioniert das mit dem String bei 250k Baud. Ist das SEDU Board auf 500k kann es mit den 250k nix anfangen, da müsste dann das Baud-Aliasing im Treiber so eingestellt sein, das beim öffnen der Schnittstelle 500k gefahren wird.


    und ich will das Teil ja im Gehäuse haben, kann also nicht den Reset-Knopf drücken zum flashen


    2mm Loch an der richtigen Stelle im Gehäuse und du hast nen klassischen Reset Knopf den man mit der Büroklammer drücken kann, hat heutzutage jeder Router :P

    Hier würde ich eher das Problem sehen... man sollte ja immer mit min. der doppelten Rate abtasten...


    Nun ja nicht ganz, hab ja ne grossen Buffer im Windows und arbeite dann alle 40ms auch alles ab was im Buffer ist und bin somit sofort wieder auf dem laufenden, ich arbeite ja nicht nur ein Frame dann ab, sondern alle. Mach ich mit den eingehenden Netzwerkdaten ja nicht anders und bekomme keine Verzögerungen. Da ich ja eh ne Masterframerate von 25 fps habe, passiert eh nur alle 40ms Sekunden was, daher ist es auch unnötig zwischendrin Daten auszuwerten. Ich nehm da lieber den Mastertimer und arbeite die gesammelten Daten dann in einem Rutsch ab.



    //EDIT
    Hab jetzt mal für den Sedu neu assembliert und auf 500kBaud umgestellt, nun läufts auch mit den 16ms TimeOut im Treiber geschmeidig, also gleich wie bei der 3 Kanal Variante, nur eben die leichte Verzögerung.

    tpm2-remote funktioniert jetzt auch mit 512 Kanälen - allerdings geht es ein bisschen "ruckelig" - also wenn man z.B. den Fader für Master hochzieht, geht der im Programm nicht gleichmäßig mit, sondern springt in Stufen nach oben - bei nur 3 gesendeten Bytes geht er super-geschmeidig mit...


    So nun selber mal nachgetestet, da kann ich gar nicht viel daran machen. So wie es aussieht hakt es da am FTDI Treiber. Bei einem 512er Frame kommen ja quasi kontinuierlich Daten, in Realtime abgreifen geht ja nicht (USB Frames, etc). Ausserdem bin ich ja selbst auch getaktet und Frage den virtuellen Com alle 40ms ab und hol mir dann alles was im Buffer ist. Da spielt nun aber nicht nur der Windows Buffer eine Rolle sondern auch derm vom FTDI und da kommt dann folgendes vom FTDI ins Spiel:


    Zitat


    6.3 Setting a Custom Default Latency Timer Value
    The latency timer is a form of time-out mechanism for the read buffer of FTDI devices. When a FT_Read instruction is sent to the device, data will not be sent back to the host PC until the requested number of bytes has been read. If the requested number of bytes never comes, the device would not send data back.
    The latency timer counts from the last time data was sent back to the PC. If the latency timer expires, the device will send what data it has available to the PC regardless of how many bytes it is waiting on. The latency timer will then reset and begin counting again.
    The default value for the latency timer is 16ms.


    Diese 16ms sind quasi deine Sprünge bei einem 512er Frame. Wenn ich nun die Anschlusseinstellungen bearbeite und dieses Timeout auf das Minimum stelle (1ms), dann läufts auch bei 512er Frames Smooth, allerdings mit einer kleinen Verzögerung. Bei 3er Frames spielt das keine Rolle da deutlich weniger Daten kommen.


    Ich hab jetzt die DMX Spec nicht vor mir (von wegen Break und so), aber wenn du 512 Kanäle + Startbyte bekommst via DMX macht 513 Bytes (wie lange ist der Break davor nochmal, 2 oder 3 Bytes ?) Bei 3Bytes wären es dann 516 Bytes emfpangen, ausgegeben werden aber 517 Bytes bei tpm2 (4 Headerbytes + 512 Daten + Stoppbyte). Bekommen wir nicht hier schon probleme wenn die 250k Baudrate bei DMX voll ausgenutzt wird, der SEDU schickt ja auch mit 250k Baud weiter. Kann es sein das es hier schon Probleme gibt ? Bei kleineren Frames würde das ja auch keine Rolle spielen. Oder habe ich mich da jetzt komplett verrechnet ?


    *grübel*
    Könnte man den SEDU FTDI mässig nicht einfach auf 500kBaud setzen ? Dann haben wir in diese Richtungen eigentlich gar kein Problem mehr ?


    //EDIT
    Hab gerade die 3 Kanal Variante ausprobiert, hier läuft es mit den 16ms Latency Timeout smooth aber auch mit leichter Verzögerung, geh ich auf 1ms runter ist die Verzögerung kleiner aber immer noch sicht-/spürbar.

    So, mal wieder ne neue Version im ersten Post (0.92).


    -kleiner Bugfix für Starfield, unter bestimmten Umständen konnte es zum AppCrash kommen
    -bei Artnet Output ist nun auch Broadcasting möglich (IP 255.255.255.255)
    -kompletter Rewrite der logarithmischen Skalen/Bänderberechnung im Spektrum Analyzer
    -Spectrum Analyzer lässt nun eine frei wählbare Zahl an Bänder zu, somit kann man auch bei krummen Matrixdimensionen ein vollflächiges Bild erreichen. Kleinste Bandanzahl ist 4, die grösste entweder die Matrixbreite bzw. max. 64 falls die Matrix breiter ist als 64 Pixel
    -Linienmodus für Spectrum Analyzer, es lässt sich nun das Spectrum auch als einzelne Linie (oder Fläche) anzeigen, auch eine zweite Linie als Peak Hold ist möglich


    Vor allem im Linienmodus sollte erwähnt sein das es ein besseres Bild gibt wenn man es mit den Bändern nicht übertreibt, wählt man hier Bandanzahl=Matrixbreite gibt es keine schöne Linie (wie auch ist ja kein Platz zum interpolieren), hier bietet sich die halbe Pixelzahl als gutes Bild an (Matrix 32 Pixel breit -> 16 Bänder). Balkenabstand, Peakhold ist alles wie gehabt, probierts einfach mal aus.


    Hier noch ein Screenshot mit 42 Bänder auf einer 128x64 Matrix:

    11MBit should be fast enough, how good is the signal ? I never used this arduino based node, can you try if it works via cable, so that we definitly know if there is something wrong with the wlan or if we have a problem between jinx and this node. Stucking pixels sounds a bit like the node isnt able to process the incoming frames fast enough, but it can also stuck within the wireless connection.


    //EDIT
    Looked inside the source code of the artnet node, do you send 312 channels or complete 512 channels ? Looks like the node doesnt handle frames < 512 channels, so if not yet done, try to set the channel count in the device config in Jinx to 512.

    So hier mal ein paar Code Schnippsel zum Verständnis, ich denke mal dir geht es hauptsächlich darum wie du mit der seriellen umgehen musst unter C.


    Linux


    und für Windows


    Bei Fragen ping mich einfach an.

    Hi Michu,


    kenn mich zwar in OLA nicht aus, aber tpm2 in C hab ich ja in Jinx! drin, ich kann dir da schon helfen, müsste mir nur erstmal die API von OLA ansehen, bzw. ich kann dir die Tage mal eine Beispielroutine in C machen.


    Grüße
    Sven

    So dann gleich nochmal die Pesi Deluxe Edition v0.91:
    Remote Control:
    -seriellerEingang blockt nun nicht mehr wenn die serielle Übertragung abbricht
    -kompletter serieller buffer wird nun abgearbeitet, so das kein buffer overrun mehr entstehen kann
    -kompletter Umbau des gleichen Buffers auf einen Ringbuffer um auch bei langsameren Baudraten keine Frames zu verlieren (Framestart wurde nicht immer erkannt)
    Neues:
    -Masterout ist nun auch im Showmode-Fenster verfügbar
    -Bei derRemote Control ist die Szenenwahl nun auf 32 beschränkbar somit gelten die Werte 0-7 für Szene 0, 8-15 für Szene 1 usw. Somit sollte man auch mit einem einfachen DMX Pult eine Szene treffen ;)


    Pesi:
    Sollte nun mit einem 512er Frame klappen der vom Sedu kommt, egal mit welcher Geschwindigkeit. Hauptproblem war, das ich bei dem seriellen Eingang nicht alle anstehenden Daten gleich verarbeitet habe sondern nur ein Teil, sind dann viele Daten gekommen gabs nen Stau. Zweites Problem, wenn die Daten mit einer langsamen Baudrate kommen gibt es zwischen den Frames keine Lücken. An diesem Punkt hab ich dann nicht immer den Framestart sauber erkannt und es gingen Frames verloren und es hat öfters mal gehakt. Deshalb hab ich hier nun klassisch auf einen Ringbuffer umgestellt.

    Ja, wenn das mit 512 Kanälen ginge, wäre das schon super, sonst muss man im Interface immer umstellen, auf welchem Kanal das empfangen soll...


    Ich bearbeite gerade den Buffer, aber beim testen ist mir was anderes aufgefallen. Mit welcher Baudrate sendest du tpm2 ? Nicht das du mehr Daten schickst in der Sekunde als die Baudrate kann, das Thema hatte ich gerade beim testen :) Bei einer Baud von 115200 bekomme ich via tpm2 keine 512 Kanäle bei 25 Frames/Sekunde sinnvoll durch.


    turi
    Coole Sache :) Dresden ist mir ein bisschen zu weit, sonst wäre ich da gerne mal dabei. Aber ich warte geduldig auf das Video ;)

    Buffer schau ich nachher nochmal an, eigentlich arbeite ich den ab. Hatte ein ähnliches Problem mit Artnet, vielleicht hab ich auch vergessen das bei tpm2 mit anzupassen. Yep Kanäle zähl ich grundsätzlich ab 0, ist bei Artnet auch durchaus üblich, bei DMX bei 1. Ich hatte zwar auch mit 512 Frames getestet, aber halt über Software und virtueller serieller Loop. Den Buffer bekomm ich aber hin das du beim Sedu auch 512er Frames schicken kannst, ist geschmeidiger.


    Bin gerade noch unterwegs, schaue aber nachher mal. Masterregler im Showmode ist eine gute Idee, bau ich auch nachher gleich ein. Gröberes Szenenraster könnte man ja umschaltbar machen, 32 oder 256 Szenen. Da kann man das je nach Pukt wählen was man braucht.

    So, neues Wochenende, neuer Release. Die Version 0.9b hängt wie immer am ersten Post in diesem Thread.


    Folgendes ist neu:
    -kleiner Bugfix beim editieren der Output Devices
    -Fix für Comports > COM9 (Ich hätte schwören können, dass ich das schonmal gefixt habe :) )


    -Remote Control Support via tpm2, tpm2.net und artnet (echtes DMX via DMX/USB kommt noch):
    Wie ein paar Posts zuvor schonmal mit Pesi diskutiert möchte ich Jinx von meinem normalen DMX Lichtpult aus fernsteuern können, also haben wir nun einen zuschaltbare Remote Control die Daten via tpm2 (seriell/usb), tpm2.net (udp) oder artnet(udp) empfängt. Ausgewertet werden 3 Kanäle: Szenenwahl (0-255), Masterout (Helligkeit / 0-> aus, 255-> volle Helligkeit) und das Masterstrobe (0-> aus, 1->sauschnell, 255-> verdammt langsam, je höher der Wert desto grösser die Zeitabstände, equivalent zum Masterstroberegler in der GUI).


    Grundsätzlich werden bei jedem Protokoll Frames mit einer Größe zwischen 3 und 512 Kanälen entgegengenommen. Jinx! nimmt sich aus diesem Frame dann seine 3 Kanäle ab dem angegebenen Startkanal heraus. Wird also als Startkanal z.B. 17 angegeben, so wird Kanal 17 des Frames für die Szenen, Kanal 18 für Masterout und Kanal 19 für das Masterstrobe verwendet.
    Natürlich kann jeweils auch ein kleiner Frame mit nur 3 Kanälen (OK, bei Artnet wären es dann 4, da muss die Kanalzahl immer gerade sein) geschickt werden (Startkanal = 0), die variable Framegröße hat jedoch den Vorteil das z.B. auch ein allgemeiner DMX->tpm2(.net) Umsetzer denkbar ist der ein komplettes Universum umsetzt und somit nicht speziell auf Jinx! zugeschnitten sein muss. Weiterhin bedarf es dann keiner Anpassung, falls in Zukunft weitere Remotekanäle zur Fernsteuerung hinzukommen (weitere Mastereffekte z.B.).
    Ansonsten wird bei Artnet die Adressierung (Net, Subnet und Universe) eingestellt, bei tpm2 der Com-Port und die Baudrate und bei tpm2.net ist, abgesehen von dem Startkanal, keine Einstellung nötig.


    Die Einstellungen werden zusammen mit dem Setup und den Szenen gespeichert und beim starten/laden wieder hergestellt.


    Kurz noch zur Steuerung: Prinzipiell reagiert Jinx! bei den Eingängen auf Veränderungen, so dass man direkt in der Software auch gegensteuern kann. Also wenn z.B. via Remote auf Szene 2 geschaltet wird, kann ich in der Software Problemlos Szene 4 wählen obwohl die Remote immer noch 2 sendet. Via Remote wird erst wieder eine Szene gesetzt, wenn ein anderer Szenenwert als 2 gesendet wird, gleiches gilt auch für Master und Strobe. Abgefragt werden die Eingänge mit der Master Frame Rate, also 25 mal pro Sekunde.


    Fernsteuerungen gibt es zugegebenermaßen noch nicht wirklich, allerdings möchte Pesi uns mit einem SEDU ein DMX->tpm2 Interface basteln, damit man von seinem DMX Pult aus Jinx! fernsteuern kann (So, jetzt bist du an der Reihe Pesi :P ). Dies gibt dann quasi die LowCost Alternative zu einem echten USB DMX Interface (die DMX Interfaces die Eingänge bieten sind leider etwas teurer, die ganzen billigen bieten nur Ausgänge). Für tpm2.net fällt mir im Moment nichts ein ;)
    Dafür kann man den Artnet Eingang bereits jetzt problemlos mit vielen DMX Programmen nutzen um Jinx! fernzusteuern.


    Ist jetzt sicherlich kein Killerfeature für diejenigen die in der Kellerbar oder im Wohnzimmer eine Matrix hängen haben. Diejenigen die aber eine Matrix in Kombination mit einer Lichtanlage betreiben, können diese nun in die normale Lichtsteuerung integrieren.



    //EDIT
    Nochmal ne neue version (0.9c) angehängt im ersten Post:
    -kleiner Fehler bei dem Netzwerkempfang (tpm2.net/artnet) behoben, es wurden ab und zu Pakete verschluckt
    -artnet input bei der Remote Control nun broadcast fähig
    -artnet input (remote control) unterstützt nun artpoll. Sprich wenn in Jinx die Remote Control auf Artnet aktiviert ist, wird Jinx von Artpoll fähigen Programmen (z.B. DMXControl) automatisch im Netzwerk gefunden. Getestet mit DMX Control und klappt sogar auf dem gleichen Rechner, allerdings muss dazu die Jinx Remote gestartet werden BEVOR DMXControl bzw. dort das das Artnet-Ausgabeplugin gestartet wird, ansonsten blockt DMXControl den Netzwerkport und lässt Jinx nicht mehr darauf zugreifen.


    //EDIT 2
    So nochmal ein Bugfix für das Artnet Adressing bei Artnetpoll, die "Net" Adresse wurde nicht richtig ausgegeben (nur subnet/universe hatte funktioniert), so ist das halt wenn man immer mit Net=0 testet :D
    -> Version 0.9d


    Hab mal noch ein kleines DDF für DMXControl angehängt, falls es jemand braucht.

    Nee da ist noch nichts verworfen, ist für mich immer noch Prio 1 auf der Todo List. Ich will mit dem DMX Pult fernsteuern können, Killerfeature für mich.
    Nur ist es noch nicht programmiert ;)


    Was die Patch/Device Logik betrifft merkt man glaub ich, das ich das arbeiten mit DMX Pulten gewohnt bin, wie manch anderer ( Pesi) auch :D Da ist solch eine Aufteilung Standard und man ist diese Vorgehensweise einfach gewohnt :)

    Hmm nun ja, die Trennung zwischen Patch und Ausgabedevices halte ich für sehr sinnvoll, weil ich so eben sehr flexibel bin und eben auch über mehrere Devices parallel ausgeben kann, so z.B. eine grosse Matrix die ich seriell steuern möchte auch über 2, 3 oder mehr serielle Schnittstellen um die Framerate hoch zu halten.
    Das ergibt dann die Reihenfolge, erst Ausgänge anlegen und dann patchen. In meinen Augen eigentlich eine logische Trennung und klare Vorgehensweise vom Konzept her, OK eine Bedienungsanleitung wäre nicht schlecht ;)
    Gute Vorschläge sind hier aber immer Willkommen, wenn jemand eine gute Idee hat wie man das übersichtlicher oder logischer gestalten kann, gern nur her damit :)

    Counterfeiter
    Hmm hab ich gerade getestet, funktioniert hier ohne Probleme. Kannst du nochmal deine Startkanäle anschauen ? Evtl. hast du ei Interface gepatcht das zu wenig Kanäle hat ?
    Ansonsten mach mir mal Screenshots Schrittweise, das ich seh was dann nicht stimmt. Wie gesagt, hab hier gerade ne 32x32 durchgepatcht mit snakelines, passt bei mir.


    //EDIT
    Oh hat sich wohl überschnitten, was genau meinst du mit:

    die Menüs sind ja voneinander abhängig


    Also klar, wenn du die Ausgangsdevices änderst fliegt das aus dem Patch heraus was nicht mehr passt. Oder meinst du das Fastpatch ? der merkt sich halt immer den letzten Kanal das man schnell durchpatchen kann.
    Einen Assistent hab ich mir schon überlegt, aber das ist so viel läsige Dialogarbeit die keinen Spass macht beim programmieren und irgendwie keinen wirklichen nutzen bringt :D