Jinx! - LED Matrix Control ... und die nächste Matrix Software ...

    Zitat

    Habs gerade noch mal mit Glediator gegen gecheckt... bei zwei Pixel zum Test auf zwei Universen verteilt... stört das letzte 0 Byte... das sicherlich bei dir drin ist um spec Konform zu bleiben...


    Da sollte eigentlich keine zusätzliche Null dranhängen!? Aber: max. Channel sollte den letzten benutzten Channel angeben und NICHT die Anzahl an Channels (es wird ja bei 0 angefangen mit dem zählen). Dann sollte es passen.


    LG,


    Pepe

    Zitat von Pepe_1981

    Aber: max. Channel sollte den letzten benutzten Channel angeben und NICHT die Anzahl an Channels (es wird ja bei 0 angefangen mit dem zählen). Dann sollte es passen.


    Sicher? Da steht ja per Default 512 drin... das würde ja bedeuten 513 Byte....
    Hab gerade mit zwei probiert... da gibts patching Fehler und wenn ich was anderes Patche und das in der Liste lasse, dann kommen auch wirklich nur 2 Byte Daten...
    Ergo: Du hast das ganze evtl. doch artnet Konform gemacht? (hab Ver. 1.1 ?!)


    Vielleicht weiter per PN... sind ja im Jinx Thread...



    Grüße


    Basti


    P.S. Pepe hab mal in Glediator source geschaut... da stehts auch so... könnte man das evtl raus nehmen? Wer spec konform sein möchte, kann ja ne gerade Zahl einstellen...
    Hier die Teststelle in der set_paramters Funktion:

    Code
    if (this.data_length[i] % 2 == 1) this.data_length[i] += 1;

    Artnet sieht eine durch 2 teilbare Kanalzahl vor, da hält sich Jinx! auch dran. Und ja, jedes Artnet Node fängt wieder bei Kanal 0 an, da weiter zu zählen würde ja auch nicht wirklich Sinn machen. Beim Fastpatch wird immer nur ein Node gepatcht, wenn du also 2 Nodes hast musst du 2 mal Fastpatch aufrufen, das entsprechende Node wählen und bei 0 wieder starten.


    Grüsse


    P.S.: Usermanual war im Text verlinkt: http://www.live-leds.de/jinx-usermanual-0.95a.pdf

    Zitat von Pepe_1981

    DMX-Specs! Letztere sind meines Wissens nach fest auf 512 Kanäle genagelt!

    Meines Wissens nicht - siehe dazu auch hier

    Zitat

    Jede DMX-512-Verbindung unterstützt bis zu 512 Dimmer; eine Mindestzahl ist nicht vorgegeben.


    Ist in der Praxis auch immer so: Ein E:Cue Nano sendet z.B. nur 256 Kanäle (damit man sich den teureren Butler o.ä. kauft, wenn man mehr braucht :D), ein 8-Kanal-DMX-Lichtpult sendet auch nur 8 Kanäle, keine 512... usw.

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Mir ist noch was aufgefallen...


    Die Geschwindigkeitsregelungen der Animationen ist etwas anders als ichs gewohnt bin...
    zB. Plasma...


    wenn ich das langsamer Stelle, würde ich erwarten, dass die Animationen 25 mal die Sekunde aktualisiert werden und der Farbverlauf flüssiger wird...
    Es sieht aber eher so aus, als wenn die Matrix ruckelt, da für einige Bilder annähernd die selben Frames kommen und es dann hart zum nächsten zu schalten scheint...


    Würde gern für meinen LED Tisch ein paar flüssige und smoothe Animation auf SD Karte aufnehmen, weil man sonst beim TV gucken irre wird ;)
    Irgendwie war das aber Aufgrund des Verhaltens noch nicht so recht möglich... bestes Ergebnis ist der laufende "Regenbogen" bisher...


    Grüße


    Basti

    Yep, Geschwindigkeit regelt quasi die Framerate des Effekts runter, dadurch das viele Effekte pixelbasiert (also eine pixeländerung pro Frame) sind lässt sich das nicht wirklich anders machen. Bei color scrolling ist es von der Effekterzeugung her anders, daher gibts hier auch einen extra Geschindigkeitsregler im Effekt Setup. Die pixelbasierte Berechnung bringt mir genaue Kontrolle ohne Weichzeichner, der Nachteil ist die Geschwindigkeit bei kleinen Matrizen. Ich hatte das Ganze von vorne herein auf höhere Auflösungen ausgelegt (32x16 und höher), alles unter 16x8 ist eher suboptimal im Moment ;)
    Plasma kann ich aber noch anpassen wie beim Color Scrolling, das es hier eine extra Geschwindigkeit innerhalb der Berechnung gibt. Bei anderen Effekten klappt das leider nicht so einfach.


    //EDIT
    Hab das beim Plasma gerade kurz testweise eingebaut. Hab ich im nächsten Update in den nächsten Tagen mit drin.

    Klasse!


    Hab ich mich also doch net verguckt :)


    Das Plasma mit Grün-Rot-Schwarz gefällt mir nämlich sehr gut... wäre super, wenn man das Abends son bissel blubbern lassen könnte, ohne weggeflasht zu werden...
    Das andere seh ich natürlich ein... da ist viel dabei, was nicht anders von der Geschwindigkeit runter zu regeln geht...


    Aber wenn du Lust auf Programmieren hast, dann kannste ja mal versuchen über ungefähr die Anzahl der ausgelassenen Bilder einen gleitenden Mittelwert zu ziehen... das gibt vielleicht einen ziemlich smoothen Effekt und beruhigt die Bilder auch bei kleinen Matrizen.... könnte ich mir vorstellen :)


    Grüße


    Basti

    Achso... könnte dir meinen selbsterdachten Wassertropfen Algo zur Verfügung stellen... dann könnte man zufällig nen paar Wassertropfen mit Jinx! tropfen lassen...


    Ob der jetzt so genial ist weiß ich nicht... ich hatte ihn jedenfalls für nen 8 Bit < 32 MHz Mikrocontroller erdacht und optimiert... aber das macht ja im "Großen" auch keinen Unterschied... kannst ja den richtigen Gleitkommasinus nehmen, stat einer Tabelle ;)


    Wenn du Lust drauf hast einfach PN :)


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Das mit den Tropfen gefällt mir auch gut ...


    Seddi: wäre es denn denkbar, dass Du eine Ausgabe in eine Datei umlenken kannst? Dann könnte man die aufgezeichnete Datei dann standalone auf einem Controller ablegen und abspielen. Ich könnte mir vorstellen, dass das vielleicht gar nicht so kompliziert ist, wenn man Datei als Device wählen kann. Das wäre zunächst für tpm2.net und tpm2 interessant.

    Die Tropfen sind nicht schlecht, ich hab da prinzipiell ne Idee dazu, da muss ich aber erst mal basteln. Den Algo den ich da im Kopf dazu habe und der mir da coole Dinge erzeugt interpoliert stark und da wird es dann mal wieder Probleme geben bei kleinen Matrizen weil dann alles viel zu schnell geht. Muss ich mir mal anschauen, als Effekt Idee gefällt es mir auf jeden Fall gut. Ich setz es mal auf die Liste :)


    By the way Counterfeiter
    Was hat dein Tisch eigentlich für eine Auflösung ? 16x8 oder 32x16 ?


    turi
    Einfach umlenken ist irgendwie doof, prinzipiell sollte man ja schon so eine "Aufnahme" starten/stoppen können. Und dann ist die Frage in welchem Format. Direkt tpm2 Frames ? Kann irgendein Controller sowas (schon) lesen ? Oder würde da irgendein anderes Format Sinn machen ? Pepe macht ja sowas nun im neuen Glediator für ihre Umsetzerboards, finde ich prinzipiell schon interessant. Ich könnte mir hier auch gut vorstellen da irgendwann mal was gemeinsam mit Pepe zu machen, sprich ein einheitliches Format. Dann könnte man z.B. im Glediator Animationen aufzeichnen und in Jinx abspielen und anders herum, das müsste man mal mit Pepe durchdiskutieren ob er sich sowas vorstellen könnte.

    Bei meiner bescheidenen 8x8 Matrix konnte ich ähnliches wie Counterfeiter feststellen. Langsames Plasma sieht es aus, als ob es ruckeln würde.
    Glediators Plasma hat solch einen Effekt jedoch nicht. Ich kenne mich da nicht so aus, aber es scheint mir, dass es an auch an der Dimmung liegt.
    Ich würde jedenfalls einen flüssigen und langsamen Plasmaeffekt sehr begrüßen.

    Seddi ich bin doch nicht auf Formate 2^x angewiesen ;) Habe 24x12 Pixel...


    Aktuell hab ich es so, dass ich mit netcat (gibts auch für windows) einfach den UDP Stream von Jinx in eine Datei umleite...
    Aufnahme starten und stoppen ist kein Problem... Ist ja quasi mit deinem "Ausgabe starten" und stoppen erledigt.
    Damit ist garantiert, dass immer volle Frames eintreffen und in der Datei abgelegt werden. Hier stören aber manchmal die Blank Frames, da es zu einem "zucken" bei der Widerholung führt... da ja zwei mal schwarzer Frame kommt... bisschen wirds immer zucken, da man ja schlecht dort Anfangen kann, wo es aufgehört hatte... da wäre wohl der Programmieraufwand zu hoch...


    Vorteil ist einfach... das Protokoll ist schon fertig und die Erweiterung ist schnell programmiert gewesen (da schon Routine für tpm2.net vorhanden) ... was Pepe da gebastelt hat, würde mich aber auch interessieren...


    Grüße


    Basti

    So, dann mal ein kleines Zwischenupdate um ein paar Bugs zu beheben. Die Version 0.96 hängt wie immer am ersten Post, ein aktualisiertes Manual gibts hier: http://www.live-leds.de/jinx-usermanual-0.96.pdf


    Das hat sich geändert:
    -Pixelstep beeinflusst nun auch die Verschiebung der Welle bei Sinelines
    -maximale Matrixgröße ist nun 128x128
    -der Chase Button im Hauptfenster wurde nicht verschoben wenn man "Resize Preview Height" aktivierte
    -"Animated Gif" Engine heisst nun "Image Viewer" und unterstützt nun gif (animiert und statisch), jpeg, bmp, png, tiff, emf, wmf
    -"Plasma" Engine hat nun einen eigenen Speed Regler (innerhalb Effect Config) der unabhängig von der Framerate des Effect Channels ist.

    Wieder mal ein kleines Update, Version 0.97 und angepasstes Handbuch findet ihr wie immer im ersten Post hier.


    Das ist neu:
    -Fehler im Imageviewer behoben, unter gewissen Umständen konnte beim neu laden einer Datei eine Race Condition und somit ein Crash auftreten
    -Fehler im Fastpatch behoben, bei einer spaltenbasierenden Patchorder wurde der letzte Pixel nicht gepatcht
    -Output Redirection eingebaut, jedes Output Device/Protokoll kann in eine Datei umgeleitet werden. Dabei wird der Datenstrom der eigentlich auf die serielle Schnittstelle oder ins Netzwerk geworfen wird in einer Datei aufgezeichnet. Dies ist nicht nur praktisch für mich beim debuggen, sondern die Dateien können auch genutzt werden um auf Controllern (die das entsprechende Protokoll und z.B. eine SD-Card unterstützen) abgespielt zu werden.
    -Bitmap Output. Dieser Output Treiber kann genutzt werden um die Animation als Serie von Windows Bitmaps zu speichern, diese können dann z.B. mit bmp2avi zu einem Video zusammengefasst werden. Dieses Device muss nicht gepatcht werden (siehe Handbuch) und kann zusätzlich zu einer gepatchten Matrix genutzt werden.
    -Glediator2 Recorder Output. Mit diesem Output Device wird die Animation in einem Glediator2/UIB kompatiblen File gespeichert. Die Datei kann in Glediator2 abgespielt werden oder im kommenden Solderlab UIB Board eingesetzt werden. Dieses Device muss ebenfalls nicht gepatcht werden und kann zusätzlich verwendet werden (siehe Handbuch)