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

What do you mean with a long delay ? Can you give me more info about the setup ?

I dont know much about the Teensy, but for driving 88x32 pixel, you will need about 2 mbit/s transfer rate. Dont know if the teensy is able to deliver that via usb. For such a high transfer rate, I would prefer a networkbased protocol. If the device is not able to process 25fps, Jinx! will start to skip frames.

I dont think this is really a problem in Jinx! Jinx monitors the output and starts to skip frames if the output buffer gets not cleared fast enough. When I look at the video, it looks smooth without any skippings, so the data will get stuck outside of Jinx. I still think the virtual com is not able to proccess the amount of data at 25fps. Maybe you will try starting Jinx! with -p in the command line to get a test miode with 20fps output instead of 25, but I still think the controller is not able to process 25fps. Did you make any test with another software as crosscheck ? Glediator for example will slow down the framerate if there is any stucking, Jinx! Will stay at fixed 25fps rate and only works with hardware, that is able to process this framerate, because it has another engine design.
I have users with bigger resolutions, where we got no problems and everything works in real time. But they all use network based protocols or use multiple (virtual) serial interfaces to get the high framrate processed, because one serialusb interface is not fast enough , or exactly, the cpu is not fast enough on the interface.

I think because glediator runs without threads and throttles the frame rate down. What framerate do you get with glediator ?

When you run your hardware with glediator, you can see inside glediator which framerate you will reach (see screenshot):

I think you will get something <25fps, that would be very interesting.

Zitat

when I unplug the on the start output ledpaneli continues to operate until it reaches the point where the has disabled, if I close my Jinx! then at once turns off ledpanel

When you unplug your panel and it still runs, it cannot be the buffer inside Jinx!, because you unpluged it and so you hardware cant access the buffer in Jinx! anymore. So it must still reside in the buffer in your hardware. If you close Jinx, the serial port will be closed and so the hardware will flush its buffer if its empty or not. So that makes sense to me. Just another question, you are using the actual Version of Jinx (2.1a) ? It sounds a bit like you are using a version 0.92 or lower, the frame skipping got implemented into V0.92a. But this all points to the same direction: Your hardware is not able to process 25fps. Jinx produces 25fps, regardless what your hardware does. Versions <=0.92 will produce the delay you described and the software will freeze some time later because of a buffer overrun. Thats why the frameskipping got implemented into 0.92a and later, to avoid an app crash. But then you will get stuttering because you miss frames. Jinx! needs definitly hardware which is able to process 25fps, thats by design and I dont think personally that it really make sense to drive a big matrix with lower frame rates. If the software will produce 25 pictures per second and your hardware will only process 15 pictures per second (for example) you definitly run into a time drift.

@alle
Habe gerade eine Jinx!Script Seite auf die Homepage getackert (unter downloads), hier findet ihr ein paar Jinx!Script Effekte von anderen Usern. Danke an alle die ihre Skripte zur Verfügung stellen !

Zitat von alberti

I looked in glediatore FPS, he 10-12

ok, thats what I thought. Your hardware is not able to process 25 fps, thats why its not working. As already said, you need a hardware that is able to drive 25 frames per second for Jinx! Maybe you should use 2 interfaces to get a higher framerate. 12fps will not really give you a great experience.

Ich habe heute Nacht die Version 2.2 hochgeladen. Es gab nicht viele Änderungen, aber ein paar sind ganz hilfreich.

Zu allererst gabs ein paar neue Befehle für Jinx!Script: round(), floor(), ceil(). Näheres dazu im Handbuch. Weiterhin gibts nun auch einen scroll Befehl in Jinx!Script um den vorhandenen Bildschirm in alle Richtungen zu verschieben, sowie einen direkten Zugriff auf den Audio RMS level. Für alle die ein bisschen mit Farben spielen möchten gibt es nun in Jinx!Script auch eine hsv2rgb sowie hsl2rgb Konvertierung. Näheres hierzu wie immer im Handbuch bzw. in der Onlinehilfe. Ich habe auch ein paar neue Demo-Skripte mit reingepackt, wo die Befehle genutzt werden.

Auf vielfachen Wunsch gibt es nun auch die Möglichkeit einfarbige Matrizen zu betreiben. Wenn man alle 3 Farben eines Pixels auf den gleichen Ausgangskanal patcht, dann errechnet Jinx! bei der Ausgabe den korrekten Grau-Wert aus den 3 Farben und gibt diesen auch aus. Damit dies schneller geht beim patchen gibt es auch einen "Mono" Modus innerhalb des Fastpatch.
Zusätzlich ist der Punkt "Only draw patched pixels" in den Matrix Optionen nun zu "use patch state for pixel drawing" umbenannt und stellt, neben dem ausblenden von nicht gepatchten Pixel in den Previews, nun auch monochrom gepatchte Pixel in den previews in Graustufen dar.

Eine weitere Neuigkeit ist der Autoscene fade. Wird er Auto Scene Fade aktiviert (Auto Button im Showmode bzw. Scene Window) weisst Jinx! half scenes automatisch einer Seite zu und startet einen autocrossfade auf die neue Szene. Somit kann z.B. im Showmode mit einem einfachen klick die Szene gewechselt und überblendet werden. Die Autofade Geschwindigkeit lässt sich nun auch einstellen.

Um ein paar Freaks zu entgehen, die meinen man müsste binär in der Jinx! Binary rumpatchen um irgendwelche Copyrights zu ändern, sind meine binaries nun digital von mir signiert. Ausserdem prüft Jinx! beim start diese Signatur und unterbindet ein starten der Anwendung falls irgendetwas manipuliert wurde (sei es absichtlich von Hand oder durch einen Virus).

Als Bugfix hatten wir noch:
-Szenenvorschau während dem editieren eines Chase wird nun wieder korrekt dargestellt
-Im Patchdialog wird nun bei der Device Auswahl zuerst das Universum angezeigt (Artnet,sACN), damit dieses nicht abgeschnitten wird
-das Artnet Protokol wird nun immer fest vom UDP Source Port 0x1936 gesendet, hier arbeitete ich bisher mit dynamischen Ports um ein den Port nicht unnötig zu binden, leider gibt es ein paar controller die Artnet Pakete auch auf den Source port prüfen

Wünsch euch viel Spass damit.

Grüße
Sven

Download unter: live-leds.de - Direktlinks im ersten Post

Das scheint mir eher eine Frage des Controllers zu sein, weniger eine Frage der Software. Wie steuerst du deine LEDs an (controller) ?

There is no limit inside Jinx! for tpm2(net) channels. But as tpm2.net is network based you should try to use a smaller blocksize in the tpm2.net output, because sending 1466 channels in one network packet will result in fragmented packets on the network and most of the small tcpip stacks for microcontroller will not handle fragmented packets. Thats why a block size is implemented into tpm2.net, this has nothing directly to do with Jinx!.
If your implementation supports multiple blocks, you have to try or ask the author. It is cleanly defined inside the protocol for the given reasons. As far as I remember, we got good results by using a block size around 800channels with a SEDU3.

//edit
Looked into the source code, you linked. Seems like there are no multible blocks supported, like defined in the specs. So with this implementation, you will not be able to use a channel size that will break your mtu size (including protocol and udp overhead).

Zitat von oldIcke

Ich habe eine Art-Net box (AN6USPI V2.0)6 universes von Electron-design.

OK, aber ich verstehe immer noch nicht die Frage so wirklich. Wenn du 750 LEDs hast, musst du das über mehrere Universen ansteuern (kann der Controller wohl, wenn ich das richtig sehe), da du ja pro Universum (512Kanäle/3 Farben) max. 170 LEDs ansteuern kannst. Somit muss der Controller in der Lage sein 5 Universen zu empfangen und das auf die Stripes ausgeben. Vermutlich über mehrere Ausgänge, da 750 in einem Strang vielleicht etwas viel sind. Da ist aber alles ein reines Controllersetup und hat noch nix mit Jinx! oder anderen Matrix Programmen zu tun. Wenn du hier die Hardware am Start hast, dann kannst du in Jinx! die 5 Artnet Universen als Output Device anlegen und im Patchfenster zuweisen.