Beiträge von michuNeo

    Hallo zusammen


    Ich habe eine neue PixelController Version veröffentlicht, grösste Neuigkeit ist der native RPi support (WS2801), TouchOSC Interfaces, neue Effekte und Generatoren und viele Bugfixes.


    Neue Download URL: https://github.com/neophob/Pix…r/releases/tag/v2.1.0-RC1


    Detailiertes Changelog:
    Changelog v2.0.0 to v2.1.0-RC1632 files changed, 96745 insertions(+), 151436 deletions(-)
    Add client/server architecture. PixelController can started headless on a server, connect to the server with the client GUI (same look as the standalone version)
    Add RaspberryPi WS2801 output driver
    Add custom led matrix mapping tool, see http://pixelinvaders.ch/pixelcontroller/ for more details
    Add Bonjour/Zeroconf support, PixelController register itself as "pixelcontroller.local"
    Add new ROTATE_ Generator/Effect/Mixer/Colorset OSC command
    Add Noise generator
    Add Gamma 3.0 color correction
    Add TouchOsc layout for phone and tablet
    Add simple performance test (PixelController.sh -perf or PixelControllerRPi.sh -perf)
    Add Random Mode with selectable time-life (option randommode.lifetime.in.s) (Issue #44)
    Add more Blinkenlights movie files
    Add new effect Posterize
    Add new effect Darken
    Add PixelInvaders firmware for Arduino UNO, thanks Yves Alter. This should fix all UNO related issues.
    Add new output rotate option: FLIPPEDY
    Remove support for stealth panels
    Fix decouple fps setting of PixelController from the GUI update speed (Issue #61)
    Fix replace Pixel and Quality image resize code with custom implementations (nearest neighbour and bilinear), major performance improvement
    Fix add missing float parameter to the OSC server, only int values were parsed
    Fix the framerate configuration can be a float number (ex. fps=0.1) if you need a really slow update rate
    Fix refresh GUI settings when random mode kicks in
    Fix generator speed changes the target fps (0..200%), much smoother (Issue #46, #52 and #59)
    Fix generator speed and brightness were not stored as part of the preset (Issue #62)
    Fix capture generator, crashed if recording window was too small
    Fix Metaball generator resolution for different sizes
    Fix more code cleanup
    Fix optimize CPU usage in heavy beat detection mode
    Fix optimize preset load time, load resource files (image and blinkenlight) only if generator is used in preset
    Fix reduce rotozoom effect speed
    Fix visual size in GUI
    Fix rename preset.led -> preset.properties, all PixelController extension files have now the same file extension.
    Fix update build process, put RPi specifiy resources (Serial and pi4j) dependencies into special directory, do not include junit dependencies.
    Fix speedup Blinkenlight parser, some frames were displayed too long
    Fix Multliply and Negative Multiply mixer, output didn't respect ColorSets correctly
    Fix Subsat mixer - was completly broken
    Fix output layout for all *FLIPPEDY entries - all FLIPPEDY action were broken.




    Hier noch ein Musikvideo mit PixelController und 3 ExpeditInvaders:
    https://www.youtube.com/watch?v=rJ9pGdXraB0

    Hallo


    mitlerweile habe ich den ersten Release Candidate von PixelController 2.0 veröffentlicht. Die grösste Neuerung dürfte die command line Version sein. Somit kann PixelController auf einem RPi (oder einem anderen, günstigen ARM board) laufen. Hier die detaillierten Änderungen:



    Counterfeiter: die möglichkeit, "exotische" verkabelungen komfortabel zu konfigurieren habe ich in meine ToDo liste aufgenommen.


    Gruss
    Michu

    kann natürlich sein, das ich das file falsch geparst habe. wenn du aber zb color fader nimmst, stimmts?


    stimmen die 170 pixel pro universe?


    Laut deinem konfig file ist

    Code
    1. 0 0 R 848
    2. 0 0 G 847
    3. 0 0 B 846


    total 288 pixel oder 864 ansteuerbare farben. mein mapping ist auf pixel offset definiert, das sollte aber kein problem sein.


    der pixel oben links ist pixelnr 282 - stimmt das oder nicht?

    Hier ist Artnet Konfig, lass mich wissen ob es funktioniert!


    Hey zusammen


    Ich werde in nächster Zeit eine neue Version von PixelController veröffentlichen. Es gab viele Änderungen im Bereich TPM2Net, Artnet und E1.31. Daher bin ich auf der Suche nach Tester mit

    • einer oder mehreren TPM2.Net Matrizen
    • einer oder mehreren Artnet und E1.31 Matrizen


    Neu werden mehrere Matrizen für die genannten Output plugins unterstützt. Ich habe das soweit wie möglich getestet wäre aber für einen Endtest froh.


    Die aktuelle Version kann unter https://dl.dropboxusercontent.…roller-SNAPSHOT-1.5.0.zip heruntergeladen werden.


    Sollte etwas unklar sein, zb. die Konfiguration bin ich gerne behilflich.


    Besten DAnk schonmal und Gruss
    Michu



    Detailiertes Changelog:

    danke nochmals.


    da ich nicht entscheide, welchen akku für das projekt verwendet wird habe ich noch eine letzte frage. Wenn LiPo akkus parallel betrieben werden - ist das ein problem? sprich wenn ein akku stärker belastet wird als der andere?

    Hallo zusammen


    Ich habe eine Frage, ich möchte gerne eine 16x16 ws2812 LED Matrix mit einem Akku betreiben. Ein ws2812 braucht max. 60ma strom, macht Total 15.4A.


    Ich dachte dabei an dieses Model http://de.ianker.com/anker-ast…r/product/79ANS1052-BA#sp
    Ich würde pro LED Matrix zwei solche Akkupacks verwenden, die LED Matrix dimmen, damit nicht mehr als 6A verbraucht werden.


    Da LiPo's bei überbeanspruchung ganz schön zicken, wollte ich mal euch fragen, ob jemand schon derartige Erfahrungen gemacht hat und ob es besser Lösungen gibt?


    Cheers
    Michu

    Ich habe eine applikation gemacht, um aus OLA die DMX Daten auszulesen und dann via tpm2net seriell oder via netzwerk auszugeben. den code habe ich unter


    https://github.com/neophob/ola-to-tpm2net


    veröffentlicht, dort ist ebenfalls ein readme vorhanden.


    OLA ist eigentlich interessant für alle, die auch eine LED Matrix software machen (sind ja mittlerweile ein paar), da damit viele verschiedene Protokolle und Hardware unterstützt wird.

    HMMM ich habe mir das auch noch nach einem input auf der OLA Mailingliste nochmals überlegt. TPM2 kann ich nicht verwenden, der Grund dazu ist, ich will ja DMX Daten via seriellen Port auf einen Microcontroller geben.


    Das Problem ist, dass wir mit dem TPM2 Protokoll keine DMX Daten (resp. offset nummern) definieren können. Beispiel (zwei 16x16 Anzeigen):


    Universe1: 170 Pixel
    Universe2: 85 Pixel
    Universe3: 170 Pixel
    Universe4: 85 Pixel


    ich kann mit dem tpm2 protokoll nur ganze frames schicken, weiss aber nicht wohin diese kommen.


    die lösung des problems ist, Tpm2.net zu verwenden, dort kann ich diese Option mit den Paketnummer angeben.


    Hat jemand einwände dazu? andere Vorschläge?

    ja, war leider nicht so toll die installation, weil a) nur zwei personen getrackt werden konnten und b) die bewegungsabläufe zu genau sein mussten um einen effekt zu triggern. ich hatte zuerst nur ein arm tracking, das wäre wohl einfacher für den besucher gewesen...