Hab noch hinbekommen... die Menüs sind ja voneinander abhängig... wäre vielleicht übersichtlicher diese in einen geführten Dialog zu packen...
Hab gerade ne 64x64 RGB Matrix mit Jinx über tmp2 per USB ausgegeben... läuft super... leider seh ich nur einen Ausschnitt, weil meine Matrix selbst, nicht so groß ist 
Grüße
Basti
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
Ich meine, dass man drei Einzeldialoge aufrufen muss und das in der richtigen Reinfolge, um für eine Matrix eine sinnvolle Ausgabe zu patchen...
Gut, nach dem ersten mal weiß mans, aber es verwirrt, wenn man neu ist...
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 
Das Konzept is ja nicht schlecht, aber die Führung über Einzeldialoge die aus dem Menü aufgerufen werden, ist gewöhnungsbedürftig... Beim Glediator ist es beispielsweise in einem Dialog mit verschiedenen Registerkarten, was ja durchaus sinnvoll ist... So kannst du das Konzept auch gut umsetzen, aber würdest halt nen Stück weit Glediator nachbauen... das kann ich auch verstehen, dass du dich da etwas absetzen willst und nicht noch mal das selbe schreiben
Hab ja auch längere Zeit WinAPI pur geschrieben, hatte sogar ne Webseite mit Tutorials... Heute kann ich aber nicht mehr so richtig nachvollziehen, warum man sich das noch antut *g*
Immerhin werden die Geräte immer unterschiedlicher, die Displaygrößen und Auflösungen sind stark unterschiedlich... da gibt schon so einige Oberflächenansätze die das sehr schön bequem umsetzen lassen... das mit der Performance kann ich net ganz nachvollziehen... ich mein, wir leben in Zeiten von Quadcore-CPU-Handys
Ansonsten Respekt vor der Arbeit und ist ein schönes Programm geworden, das ich gern weiter auf meine Matrix, loslassen würde
Also ich persönlich finde das cool so, das ist halt wohl auch Gewöhnungssache...
ich kenne das z.B. vom E:Cue genauso, da hat man auch nen extra Dialog um die Ausgabegeräte (Nano, Butler, ...) zu registrieren, und dann ein eigenes Fenster, um die Fixtures auf die Geräte/DMX-Kanäle zu patchen...
für mich ist das schon "logisch" so: Erst stelle ich ein, wie groß die Matrix sein soll, dann, was ich an Interfaces dran hängen habe, und dann patche ich die Pixel auf diese Interfaces.
ob das nun 3 einzelne Dialoge sind, oder alle 3 Sachen in einem Fenster mit Registerkarten, spielt für mich dabei keine Rolle.
klar, für Leute, die Jinx zum ersten mal benutzen, wäre so ein Assistent bestimmt hilfreich, also der einen Schrtt für Schritt da durch führt: 1. wie groß soll denn die Matrix sein? - 2. was hast Du denn an Ausgabegeräten dran? - 3. So, jetzt verteil die Pixel mal...
aber ich kann mir schon denken, dass das großer Aufwand zu programmieren ist, und eigentlich auch unnötig, da reicht m.M. nach ne kurze Bedienungsanleitung auch, wie man da vorgeht... die Dialoge an sich finde ich gut gemacht, praktisch selbsterklärend.
übrigens: Ist diese Idee, dass man Programm, Helligkeit und Strobo über drei per tpm2 rein kommende Bytes steuern kann, immer noch aktuell, oder schon wieder verworfen...?
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 Da ist solch eine Aufteilung Standard und man ist diese Vorgehensweise einfach gewohnt
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 
). 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
-> Version 0.9d
Hab mal noch ein kleines DDF für DMXControl angehängt, falls es jemand braucht.
Vielen Dank für das Killerfeature! 
ich habe die Umsetzer-SW fertig, die DMX empfängt und das als tpm2 an den Rechner gibt, funktioniert im Prinzip...
gibt nur ein paar kleine Probleme damit:
- irgendwie ist der Master das einzige, was bei mir richtig läuft
- Strobo reagiert manchmal, Programme umschalten auch nur sehr sporadisch
- ist das richtig, dass der Master auf Kanal 3 liegt...? - also wenn ich im Dialog "Channel 1" eingebe, sollte odch DMX-Kanal 1 das Programm, 2 der Master, und 3 das Strobo sein...?
- die Steuerung ist seeehr träge.
ich glaube, da läuft irgendwie ein Empfangspuffer über, kann das sein...?
meine SW ist so gemacht, dass sie nur dann was per tpm2 raus schickt, wenn auch DMX-Daten rein kommen - die können aber ja auch mit 44 Hz (oder mehr, bei so nem kleinen Pult, das nicht alle 512 Kanäle schickt) kommen, und Du tastest mit 25 Hz ab - kann das sein, dass da also alle empfangenen Daten erst mal gepuffert werden...?
und es deswegen "ewig" dauert, bis eine Änderung registriert wird, weil die geänderten Daten ja erst mal alle durch den Puffer müssen...?
zum testen habe ich das mal so probiert, dass ich das Lichtpult ausgesteckt habe, dann was geändert, wieder angesteckt - da reagiert Jinx! sofort, wohl weil der Puffer gerade leer ist...
wie man das beheben könnte, weiß ich jetzt gerade leider auch nicht - ich könnte als Workaround in meine SW einbauen, dass die ebenfalls nur tpm2 an den Rechner schickt, wenn sich an den empfangenen DMX-Daten was geändert hat - aber cooler wäre es natürlich schon, wenn das auch so ginge...
Update: ich hab's jetzt mal anders gemacht, in meiner SW so geändert, dass die nur 3 Kanäle per tpm2 weiterschickt statt allen 512, jetzt läuft's geschmeidig!
auch rausgefunden, ich muss "Channel 0" angeben, wenn's auf DMX-Kanal 1 losgehen soll - das könnte man evtl. beheben, bei DMX zählt man halt ab 1, aber wenn das zu kompliziert ist, auch kein Ding...
eine Bitte noch: Es wäre cool, wenn in dem Show-Mode-Fenster:
auch noch der Regler für die Masterhelligkeit da wäre - wenn man mal damit arbeitet (wird bei mir whl immer der Fall sein, wenn ich das nicht per DMX mache) wäre das ganz praktisch...
und, ich weiß nicht, ob das arg aufwändig wäre, aber es wäre cool, wenn man den Regelbereich für die Szenen "vergröbern" könnte - also dass z.B. von 0-7 Szene 1 kommt, von 8-15 Szene 2, usw. - dann könnte man das auch gut mit nem billigen Faderpult steuern, mit dem man ja meist nicht so genau einstellen kann - dann sind's halt nur noch 32 abrufbare Szenen, aber das reicht bei so kleineren Sachen meist...
schick' mir doch mal Deine Adresse per PN, dann schick' ich Dir nen SEDU mit der SW drauf...
Ich habe mal eine 32x32-Matrix mit 1cm Pitch aufgebaut und per tpm2 mit Jinx! gekoppelt. Ein Video kommt bald noch dazu. Ich muss sagen, ich bin echt begeistert. Wer es live sehen möchte, sollte nächste Woche zum Arduino OpenSpace kommen
Schade, dass ich da nicht kann... 
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...
habe die SW mal in den SEDU-SW-Thread gepostet...
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
Ich schick' mit 250k, so wie DMX auch rein kommt...
bei mir gibt's keinen FIFO-Puffer, da kann also keine Verzögerung auftreten... im FT232R ist zwar ein FIFO, aber nur 64 Byte (oder so), und nach dem geht's ja über USB weiter, da ist kein Flaschenhals.
Im Terminal sieht man das auch gut, da ändern sich die Zahlen auch sofort, wenn ich am Pult was schiebe - auch bei 512 verschickten Kanälen...
ich schicke exakt das, was die Baudrate kann, immer wenn ein Byte versendet ist, kommt sofort das nächste.
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.
Hi
Has anyone try this program via the wireless artnet because to me it is not good after about one minute to hack pixels and will remain so until the Output turns off and turns on again.
I've tried it so far only the wireless artnet setup them 2.0.0.10 Net 0, Subnet 0, Universe 0, Channel 312
