Glediator - Freeware LED Matrix Steuerung - Software

  • Hallo Freunde der LED-Beleuchtung,


    Zeit den ersten Punkt auf meiner ToDo-Liste abzuhaken. Hier also das Protokoll für die Remote-Control der Szenen-Auswahl:


    Es ist nicht sehr einfallsreich aber es funktioniert :rolleyes:



    Ich gehe im Folgenden davon aus, dass die Remote-App (RM-App) aus nur einer Combo-Box besteht.


    Die Kommunikation erfolgt wie schon erwähnt über ganz ordinäre UDP-Pakete. Die RM-App muss zyklisch (ich habe bei mir 100ms gewählt) prüfen ob ihr ein UDP-Paket geschickt wurde. Wenn eines angekommen ist, dann muss die App den Inhalt des Paketes prüfen und wenn dieser einen der drei folgenden Fälle darstellt entsprechen reagieren:


    "GLEDIATOR;ADD_SCENE;Name_der_Szene;"


    --> Die RM-App nimmt den STRING zwischen den letzten beiden ;; und fügt ihn an die letzte Stelle (ganz unten) in seiner Combo-Box.


    "GLEDIATOR;SET_SELECTED_INDEX;Nummer_der_Szene;"


    --> Die RM-App stellt ihren ausgewählten Index auf "Nummer_der_Szene". (Achtung "Nummer_der_Szene" kommt als STRING)


    "GLEDIATOR;CLEAR_LIST;DUMMY;"


    --> Die RM-App löscht alle einträge in ihrer Combo-Box



    Seinerseits muss die RM-App natürlich auch ab und zu mal was an GLEDIATOR senden, nämlich:


    Wenn die Verbindung hergestellt wird (genauer wenn der UDP-Listener der RM-App gestartet wurde) schickt die RM-App folgendes UDP-PAket an GLEDIATOR:


    "GLEDIATOR;GET_REQUEST;dummy;"


    Wenn man in der Combo-Box eine neue Szene anklickt muss die RM-App folgendes UDP-Paket an GLEDIATOR senden:


    "GLEDIATOR;SET_SCENE;Nummer_der_Szene;dummy;"


    Nummer_der_Szene ist dabei der aktuell selektierte Index (als eine Zahl, NICHT der Name der Szene) der Combo-Box. (Achtung: Die Zahl als STRING in das Paket einbauen!)


    Das war's schon! :P


    Na gut vielleicht sollte man der RM-App noch drei Eingabe-Felder spendieren in die man einträgt:


    1.) Die Ziel-IP-Adresse an die die UDP-Pakete geschickt werden sollen (also die IP-Adresse des Rechners auf dem GLEDIATOR läuft).
    2.) Den Ziel-Port an den die UDP-Pakete gesendet werden (also den Port auf dem GLEDIATOR lauscht).
    3.) Den eigenen Port auf dem man zyklisch auf UDP-Pakete von GLEDIATOR wartet.


    Zudem sollte dann noch ein Button rein, mit dem man den Socket (also das zyklische warten auf UDP-Pakete) öffnet bzw. schließt. Hier sollte man nach dem ÖFFENEN das oben beschriebene Paket "GLEDIATOR;GET_REQUEST;dummy;" senden, damit man von GLEDIATOR die aktuelle Liste bekommt!


    So das war aber wirklich alles!


    Nur um ganz sicher zu gehen: Anführungszeichen "" am Anfang und Ende der oben beschriebenen Pakete werden natürlich NICHT mitgeschickt! 8|


    Nun bin ich ja mal gespannt, ob jemand das auf nem Tablet / Androit / Iphone / Ipad umsetzen kann! :whistling:



    Anderes Thema (auch wenn ich es nur ungern anspreche :( ). Wir haben bisher all unsere Projekte auf unserer Projektseite mit Schematics, Layouts, Firmware, Doku, u.s.w. zur freien Verfügung bereitgestellt. Auch mit den aktuellen RGB-Matrix-Controller-Boards werden wir das so handhaben! Jeder soll unsere Projekte nachbauen und für sich kostenlos nutzen können!


    Auch GLEDIATOR kann jeder, ob privat oder im Job, kostenlos nutzen! Auf Änderungswünsche, Zusatzfunktionen u.s.w. werden wir so gut es geht eingehen. Was wir aber auf keinen Fall möchten ist, dass irgendjemand daherkommt, den Source-Code vom GLEDIATOR hernimmt, ein paar Kleinigkeiten ändert und das Ganze dann in irgendeiner Form als "seine" SW vertickt! Und genau diese Gefahr sehen wir wenn wir GLEDIATOR offen ins Netz stellen! Sicher wird KEINER von Euch so etwas machen, weil ihr alle nette Leute seid! Aber leider gibt es auch noch andere Leute in den unendlichen Weiten des Internet!


    Also seid uns bitte nicht böse wenn wir den Code nicht "Open Source" zur Verfügung stellen!


    ------


    Das dynamische Trigger-Level kommt auf alle Fälle auf die ToDo-Liste. Ich bin auch der Meinung das S2L-Effekte am besten kommen! :D


    Die Farbpaletten bei "Falling Objects" und "Meta Balls" werd ich mir nochmal anschauen!


    2 oder mehr Effekte auf jeder Seite zu mischen wüde m.M. die Einfachheit von GLEDIATOR irgendwie stören 8|



    So nun geh ich zu meiner Frau aufs Sofa, die mich schon seit 45 Min. ruft und ich immer sage "Noch 2 Min." :love:

  • Diese Software kommt gerade richtig. ;) Ich wollte mir diesen Ledwalker kaufen. Aber zum Glück bin ich auf dieses erstklassige Projekt noch frühzeitig gestoßen.
    Ich bin immer wieder begeistert, was man alles auf die Beine stellen kann.


    Eine vielleicht blöde Frage, habt ihr eine Laufzeitbegrenzung in der Software? Das z.B die Software ab einen bestimmten Tag nicht mehr startet? :wacko:

    Also seid uns bitte nicht böse wenn wir den Code nicht "Open Source" zur Verfügung stellen!

    Das sehe ich genauso. Es gibt immer welche, die sowas dann ganz schnell unter anderem Namen veröffentlichen. :cursing:

  • Zitat von Pepe_1981


    Auch GLEDIATOR kann jeder, ob privat oder im Job, kostenlos nutzen! Auf Änderungswünsche, Zusatzfunktionen u.s.w. werden wir so gut es geht eingehen. Was wir aber auf keinen Fall möchten ist, dass irgendjemand daherkommt, den Source-Code vom GLEDIATOR hernimmt, ein paar Kleinigkeiten ändert und das Ganze dann in irgendeiner Form als "seine" SW vertickt! Und genau diese Gefahr sehen wir wenn wir GLEDIATOR offen ins Netz stellen! Sicher wird KEINER von Euch so etwas machen, weil ihr alle nette Leute seid! Aber leider gibt es auch noch andere Leute in den unendlichen Weiten des Internet!


    Also seid uns bitte nicht böse wenn wir den Code nicht "Open Source" zur Verfügung stellen!


    Hi,
    Klar, die bedenken sind nachvollziehbar. Aber ihr seht das glaube ich etwas falsch. Ihr unterstellt hier mutwilligkeit. Jemand nimmt sich euern code, ändert ein paar stellen und fäng an, es als programm zu vertreiben. Mankann davon ausgehen, das so jemand Ahnung von der materie haben wird und genug ändern muss, um sich von euern projekt abzugrenzen. Immerhing gibt es eire software gratis.


    Jetzt is es aber bei eurem projekt eine sache von 30 minuten euren code zu decompilieren und die sourcen etwas aufzubereiten. Gegen echte piraterie sied ihr also auch so machtlos. Da helfen auch gängige verschleierungs taktiken kaum und erhöhen nur etwas den aufwand.


    Viel mehr müsst ihr euch fragen, ob ihr vorteile habt, alles unter einer vernünftigen lizenz zu veröffentlichen. So wird das einbauen von anderen opensource-quellcode möglich, etwa teile von pixelcontroller oder verschiedene effektgeneratoren/algorithmen. Hinzu kommt die möglichkeit vom know-how anderer zu profitieren.


    Ich weiß nicht, ob eure entscheidung etwas voreilig war.

  • Das dynamische Trigger-Level kommt auf alle Fälle auf die ToDo-Liste. Ich bin auch der Meinung das S2L-Effekte am besten kommen!


    Die Farbpaletten bei "Falling Objects" und "Meta Balls" werd ich mir nochmal anschauen!


    Da kann ich nur sagen :thumbup: :thumbup: :thumbup: Sound2Light ftw! ;) Ja ich denke mit einem Zähler, der die Triggervorgänge zählt und dann vielleicht konstant auf einem Wert hält, z.B. 30/Min (könnte ja ebenfalls einstellbar sein) wird einfach am einfachsten sein. Aber das müsst ihr letztendlich sehen wie ihr das umsetzt. Aber dann wird es echt perfekt sein :D



    So nun geh ich zu meiner Frau aufs Sofa, die mich schon seit 45 Min. ruft und ich immer sage "Noch 2 Min."


    Dann mal ab aufs Sofa, ich kenne die Situation ;)


    schönen Abend noch ;)

  • Vieleicht hier eine kleine Idee zur Konfiguration der Matrix unter DMX. Ich hatte schon seit längeren vor eine eigene Matrix zu bauen und habe daher einige Programme getestet. Unter anderem das MadMaxOne Plugin für DMXC. Dort ist das erstellen einer Matrix eigendlich ganz einfach gehandhabt:



    Zuerst wird die Breite und Höhe der Matrix angegeben (Im Beispiel,wer hätte es gedacht, 8x16 Pixel). Wenn gewünscht, kann ein Name für die Konfiguration der Matrix angegeben und später gespeichert werden.



    Konfiguriert wird ein Pixel entweder per Doppelklick auf den Pixel oder per Fast Konfig. Bei Manueller Konfiguration (Doppelklick) kann für jeden Pixel der zugehörige DMX-Kanal zu rot, blau und grün sowie das gewünschte DMX-Univers eingestellt werden (siehe Bild 2).
    In der Fast Konfiguration (siehe Bild3) wird nur der DMX-Startkanal (im Beispiel Kanal 1) und das gewünschte DMX-Startuniverse eingegeben (hier Universe 1).
    Nach einen klick auf den OK Button, wird jedem Pixel automatisch für die Farben rot, blau und grün ein DMX Kanal zugewiesen und das passende Univers. Gezählt wird hierbei von links nach rechts, von Zeile zu Zeile (Anfang oben links, Ende unten rechts). Sollte der Kanal 512 (ein Univers) überschritten werden, wird im nächsten Univers (im Beispiel Univers 2) bei Kanal 1 weiter gezählt. Dies wiederholt sich so lange, bis die Matrix gefüllt ist.



    Auch sehr gut gelöst ist die Ansicht der Konfigurierten und nicht Konfigurieten Pixel. Konfigurierte Pixel sind weiß dargestellt (siehe Bild 4), nicht konfigurierte grau.
    Vieleicht eine von vielen Ideen, wie man es machen könnte.

  • Hallo Morpheus,


    vielen Dank für die Infos, ich denke auf so etwas wird es wohl hinauslaufen! Ich überlege derzeit noch wie man auch noch die gängigsten "Pixel-Verlege-Arten" integriert, denn bei z.B. 32x16 Pixeln kann es schon recht langwierig werden die alle per Hand zu konfigurieren. So eine Art Combo-Box in der so etwas wie :


    "Schlangenlinie - oben links beginnend"
    "Schlangenlinie - oben rechts beginnend"
    "Schlangenlinie - unten links beginnend"
    "Schlangenlinie - unten rechts beginnend"
    "Zeilenweise - oben links beginnend"
    "Zeilenweise - oben rechts beginnend"
    "Zeilenweise - unten links beginnend"
    "Zeilenweise - unten rechts beginnend"


    steht. Und dann noch zusätzlich eine Combo-Box mit der Farbreihenfolge je Pixel:


    "RGB"
    "RBG"
    "GRB"
    "GBR"
    "BRG"
    "BGR"


    Und nun müssen noch die Leute berücksichtigt werden, deren Matrix modular aus Segmenten aufgebaut ist (wie zum Bsp. bei unseren Controller Boards). In diesem Fall wird eine Check-Box angeklickt in der man sagt "Modular Segments" und dann definiert man über die beiden oben genannten Combo-Boxen die Reihenfolge der BOARDS. Danach definiert man über nochmal zwei identischen Comboboxen die Reihenfolge der PIXEL innerhalb eines Boards.


    Und wer JETZT immer noch nicht abgedeckt ist, weil er seine Pixel nach dem Prinzip "Kraut und Rüben" verlegt hat, der kann sie allesamt schön per Hand anklicken und konfigurieren.


    Ich denke damit müsste für jede Eventualität gesorgt sein oder habe ich etwas übersehen?


    LG,


    Pepe

  • In diesem Fall wird eine Check-Box angeklickt in der man sagt "Modular Segments" und dann definiert man über die beiden oben genannten Combo-Boxen die Reihenfolge der BOARDS. Danach definiert man über nochmal zwei identischen Comboboxen die Reihenfolge der PIXEL innerhalb eines Boards.

    Das ist natürlich ne super Idee, da ist dann dieser Fall abgedeckt, den ich gemeint hatte, mit den fertigen Modulen wie sowas hier z.B. - also Teile in der Art gibt's ja auch mit DMX, die verlinkten haben ne eigene Steuerung...


    Ich denke damit müsste für jede Eventualität gesorgt sein oder habe ich etwas übersehen?

    evtl. noch, die Ausgabe dann um 90° zu drehen... ;) - weil die Schlangenlinien können ja waagrecht oder senkrecht laufen, bei den Modulen von André oder der "Hängematrix" von turi z.B. laufen sie senkrecht...


    bei mir im Prinzip ja auch, aber da sortiert das mein Controller um, ich habe da die "Philosophie", dass die Matrix "sich selbst drum kümmern muss", wie sie verkabelt ist, Daten immer von links oben nach rechts unten geschickt werden - aber, klar, wenn man das direkt in Eurer SW einstellen kann, ist es natürlich viel leichter...


    dann sollte aber echt alles dabei sein, Kraut und Rüben verkabelt ja keiner... :D - und, ja, so hätte ich das auch gemacht, dass man ggfs. nur die Nummer des Pixels eingibt, und die Farbreihenfolge extra - so wie in dem Beispiel oben, dass man bei *jedem* Pixel 3 Adressen angeben muss, finde ich auch zu umständlich, normalerweise sollte ja das innerhalb der Matrix gleich bleiben (also die Farbreihenfolge, meine ich)...


    zum Thema Opensource: Ja, das hatte ich mir ja schon gedacht, und auch schon geschrieben, dass ich das gut verstehen kann. Ich kann da beide Seiten gut verstehen, einerseits schade, es wäre schon cool gewesen, wenn man da mit schreiben könnte (hätte ich direkt zum Anlass genommen, mich mal mit Java zu befassen), andererseits ist dann wirklich die Gefahr da, dass jemand anderes das als sein eigenes Produkt verkauft, solche Leute gibt es leider. Und das würde mich dann an Eurer Stelle auch gewaltig ärgern.


    Und das muss der Kunde ja nicht mal mitbekommen, wenn er sich ansonsten für sowas nicht interessiert - Beispiel: Ich werde bei nem Kumpel (der hat nen Liveclub) auch ne kleine Matrix einbauen, und ihm dann natürlich Glediator zur Steuerung *empfehlen* - also ohne dass ich was dran verdiene, ist ja Freeware... ich *könnte* aber auch (wenn ich so jemand wäre) ihm sagen dass das ne gekaufte SW ist und Geld dafür verlangen...


    wenn das nun Open-Source wäre, könnte ich ganz einfach den Namen "Glediator" aus dem Titel entfernen, und der könnte nicht mal im Netz danach suchen, was das nun eigentlich ist - er kennt weder dieses Forum noch die Seite vom Pepe... kann also nicht nachvollziehen, dass ihm ne Freeware verkauft wurde... :D


    klar, sowas kann man irgendwie auch trotzdem machen (ich habe bei Youtube schon mal ein Video gesehen, wo jemand seine LED-Matrix "mit eigener SW" vorgestellt hatte, das war einfach Madrix, und er hat irgendwie das Logo ausgetauscht), aber man muss es den Schwindlern ja nicht auch noch leicht machen.


    was natürlich - wie schon mal gesagt - ne Möglichkeit wäre, dass Du einfach mal kurz erklärst, wie so ein Effektgenerator aufgebaut ist - ich kenne mich mit Java nicht aus, aber da wird wohl irgendwie ein 2-dimensionales Array in der Größe der Matrix angelegt, und der Generator schreibt seine RGB-Werte da rein...?


    wenn man wüsste, *wie* das genau sein muss, also wie das Array heisst o.ä., dann könnten auch andere Leute Effekte für Glediator schreiben, ohne dass sie dazu den Sourcecode kennen müssen - so ähnliches Prinzip, wie wenn ne Drittfirma ein Plugin für Photoshop macht, die haben deswegen ja auch nicht den kompletten Photoshop-Source...

    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!

  • evtl. noch, die Ausgabe dann um 90° zu drehen...


    Ja das war mit eingeplant ;)



    Jetzt is es aber bei eurem projekt eine sache von 30 minuten euren code zu decompilieren und die sourcen etwas aufzubereiten. Gegen echte piraterie sied ihr also auch so machtlos. Da helfen auch gängige verschleierungs taktiken kaum und erhöhen nur etwas den aufwand.


    Da hast Du vollkommen recht! Aber ich sehe das an dieser Stelle wie Pesi:


    aber man muss es den Schwindlern ja nicht auch noch leicht machen.


    Die Sache mit der gemeinsamen Programmierung der Animationen werde ich mir aber nochmal durch den Kopf gehen lassen!



    hier (Glkediator) hat man dagegen ne anwenderfreundlich professionell gemachte SW, bei der jeder alles leicht verständlich mit Dropdown-Menues und Schiebern einstellen kann (Vorteil), dafür ist es eben nicht ganz so frei konfigurierbar (Nachteil)...


    ich weiß ja nicht, wie aufwändig das wäre, solche Einstellungen (wie eben die Farbpaletten, also die Farben und der dazu angeziegte Name) auch in einer Textdatei festzulegen und da raus zu lesen...?


    Vielen Dank für die Blumen! Sicher werden in kommenden Versionen von GLEDIATOR noch einige Einstellmöglichkeiten hinzukommen. Da wird sich sicher auch einiges in Files auslagern lassen! Im Moment sind mir persönlich aber erst mal die Grundfunktionen wichtig, vor allem die Nutzbarkeit auf so vielen "Installationen" und "Protokollen" wie möglich.


    In diesem Sinne beste Grüße,


    Pepe

  • Wenn du jetzt noch als auswahl "RGBW" mit aufnimmst sollte eigendlich jeder User bedient sein, der eine LED Matrix sein eigen nennen darf :)

  • Hey Pepe,


    das sieht ja schonmal sehr gut aus :)
    und ich kann das gut nachvollziehen erstmal den Aufbau zu machen. Dann hat man schonmal eine Orientierung wo es hingehen soll.


    Eine Frage noch:


    Wenn ich mit der SW einen Aufbau aus mehreren Pixelplatinen mit WS2801 ansteuern will, schicke ich das Signal dann auch über USB raus, an einen
    USB - Seriell Wandler mit einem FT232 Chip und von dort dann mit RX TX an die Eingänge der Platinen?


    habe hier sowas rumliegen ;)


    mfg


    :)

  • Das Teil wandelt nur von USB nach seriell mit TTL-Pegel, sowas ist auf manchen Arduinos und dem SEDU-Board z.B. auch drauf...


    da kommt dann - je nachdem, was Du in Glediator eingestellt hast - dem Pepe sein Protokoll raus ("PepePixelStream" finde ich nach wie vor super btw. ;)) oder Mini-DMX, später noch mehr...


    nur, Du kannst nix davon direkt an nen WS2801 anklemmen - wie hier schon erklärt


    Du kannst das serielle Signal aus diesem Adapter eben in den Pepe seine Platinen einspeisen, oder Du baust Dir noch nen Umsetzer von PPS bzw. Mini-DMX nach WS2801 - Mini-DMX nach WS2801 ist hier schon die SW fertig, die muss auch nicht auf ein SEDU, sondern kannst Du einfach auf irgendnen Mega16 drauf klatschen, und am Rx-Pin dann dein USB-Board anschließen...

    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!

  • Danke Pesi ;)


    Jo der Arduino hat sowas, der Colorduino nicht, darum habe ich mir das Teil auch gekauft, also einfach einen Arduino zwischen hängen, wo eine extra SW von Pepe drauf ist und es klappt. Oder ein SEDU mit dem Programm.
    Habe mir ein paar digitale Pixel bei Turi bestellt und wollte erstmal zur Probe ein wenig damit rumspielen ;)


    Naja mein Plan ist später sowieso, das ein paar kleine Animationen vom Controller kommen und die Lichter per An- und Auschalter ein/ausgeschaltet werden, damit es jeder Depp auch ohne PC kann ;)



    Dann euch allen noch einen schönen Tag :D


    EDIT:


    Mir ist gerade was an der SW aufgefallen:



    Right Shape bei Meta Balls zeigt einfach das ganze Bild des linken Monitors an, wird bei Meta Balls das komplette Bild als ein Frame gezeichnet?
    Oder habe ich wieder eine kleine feine Einstellmöglichkeit übersehen ;) ?

  • Pepe: Das sieht ja übrigens schon mal sehr gut aus mit dem Setup-Fenster :thumbup:


    Die Sache mit der gemeinsamen Programmierung der Animationen werde ich mir aber nochmal durch den Kopf gehen lassen!

    Ja, wäre super - ich habe auch schon überlegt, wie ich da dies und das evtl. machen könnte - im Zuge dessen ist mit eingefallen (also, wenn's interessiert), warum wohl beim Pixelcontroller das so umständlich gemacht wird, dass die Generatoren erst ein großes Bild berechnen, das dann wieder auf die tatsächliche Matrixgröße runter skaliert wird:


    Weil's dann immer (also bis auf die Auflösung natürlich) gleich aussieht. Hier ist es ja anscheinend so, z.B. bei den "Falling Objects", das ist halt immer ein Pixel mit 5 verblassenden Pixeln "Schweif", das sich pro Frame (?) um ein Pixel weiter bewegt - daher sieht das je nach eingestellter HW-Auflösung natürlich höchst unterschiedlich aus:



    im Prinzip ist das rechts ein vergrößerter Ausschnitt von Links, eben 15x10 Pixel daraus, und sieht deutlich anders aus...


    klar, gedacht ist der Effekt wohl eher so wie links, und auf 15x10 lässt er sich schlicht und einfach (eben weil die Auflösung nicht reicht) nicht so wie links darstellen - aber der Effekt rechts ist auch recht cool, und den *könnte* man mit Anpassung auch links so machen...


    wenn das eben auf Pixel bezogen ist, dann ist die Geschwindigkeit auch anders, links fallen die Pixel dutlich langsamer als rechts - von daher wäre bei manchen Effekten ein Speed-Regler (der ja eh' schon auf der Liste steht, ich weiß) wirklich nicht verkehrt...


    z.B. dieser oben in nem Video verlinkte Effekt mit den Kreisen, die im Takt größer werden, wenn der Kreis eben pro Frame um ein *Pixel* größer wird, dann ist er bei ner 8x8-Matrix sofort durch, während es bei 64x32 schon länger dauert, bis er den Rand erreicht hat...


    aber das könnte man auch mit Verhältnissen lösen, also z.B. der Kreis wird pro Frame nicht um x Pixel größer, sondern x Prozent, was je nach Auflösung der Matrix dann eben y Pixel entspricht - das kann ja jeder in seinem Generator so machen, wie er will... ;)


    mir ist beim Capture noch was eingefallen: es wäre besser, wenn der Capture-Bereich nicht links oben im Eck beginnt, sondern etwas weiter innen - k.A. ob ich zu blöd bin, aber ich schaffe es nicht, z.B. das VLC-Player-Fenster so weit nach oben zu verschieben, dass die Titelzeile *komplett* weg ist - daher sieht man die auch immer auf der Matrix:



    wenn das Capture nun einfach bei z.B. 32/32 statt 0/0 beginnen würde, täte man sich da doch leichter.... ;)


    andere Idee noch: manche hier haben ja Schwierigkeiten, das Teil zu "installieren", also extra noch RXTX runterladen, wo muss das hin, starten über Console - was hältst Du davon, einfach die nötigen Komponenten in einen Ordner zusammen zu packen, und den zu zippen..? - also, halt ne .cmd zum starten per Doppelklick, rxtxseriall.dll kann ja auch im selben Ordner sein, dann muss man nur noch das RXTXcomm.jar in den richtigen Ordner kopieren, Glediator per Doppelklick starten, fertig - also so in der Art halt:



    Unreal: schau' Dir mal das rechte Bild genau an, da ist kein Bereich komplett schwarz, deswegen wird bei "Shape Right" natürlich das komplette linke Bild dargestellt ;)


    Abhilfe würde hier ein Threshold-Regler schaffen, mit dem man einstellen kann, ab welcher Helligkeit erst das rechte Bild "durchgestanzt" wird - das wäre evtl. ne gute Idee, damit könnte man z.B. auch das Plasma als Maske nehmen... ;)

    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 beim Capture noch was eingefallen: es wäre besser, wenn der Capture-Bereich nicht links oben im Eck beginnt, sondern etwas weiter innen - k.A. ob ich zu blöd bin, aber ich schaffe es nicht, z.B. das VLC-Player-Fenster so weit nach oben zu verschieben, dass die Titelzeile *komplett* weg ist - daher sieht man die auch immer auf der Matrix:


    Mir ist beim Capture aufgefallen, dass wenn man die Matrix von 32x16 umstellt in meinem Fall auf 16x16, es so gut wie unmöglich ist, das Capture auf die ganze Matrix zu bekommen, entweder habe ich rechts eine Pixelreihe schwarz (also nichts "gecaptured") oder die unterste Reihe ist schwarz.


    Bei 32x16 ist es ganz leicht


    Im rechten Bild schauen ;)



    Ist das bei anderen auch so?

  • Right Shape bei Meta Balls zeigt einfach das ganze Bild des linken Monitors an, wird bei Meta Balls das komplette Bild als ein Frame gezeichnet?
    Oder habe ich wieder eine kleine feine Einstellmöglichkeit übersehen ;) ?


    Pesi hat's ja schon gesagt, Plasma Balls enthalten einfach kein schwarz! Über 'nen Threshold hatte ich wizigerweise auch schon mal nachgedacht! :thumbup:


    habe ich mir das Teil auch gekauft, also einfach einen Arduino zwischen hängen, wo eine extra SW von Pepe drauf ist und es klappt.


    Ja ganau so siehts aus! Die Firmware für den ATmega werde ich heut Abend mal auf unsere Seite laden.


    im Zuge dessen ist mit eingefallen (also, wenn's interessiert), warum wohl beim Pixelcontroller das so umständlich gemacht wird, dass die Generatoren erst ein großes Bild berechnen, das dann wieder auf die tatsächliche Matrixgröße runter skaliert wird:


    Weil's dann immer (also bis auf die Auflösung natürlich) gleich aussieht. Hier ist es ja anscheinend so, z.B. bei den "Falling Objects", das ist halt immer ein Pixel mit 5 verblassenden Pixeln "Schweif", das sich pro Frame (?) um ein Pixel weiter bewegt - daher sieht das je nach eingestellter HW-Auflösung natürlich höchst unterschiedlich aus:


    Ja, ich denke auch dass das die Motivation war! Da hat der liebe Michu wohl ein Stück weiter gedacht als ich :thumbup:
    Die Effekte in unserer SW sind ganz klar aus den Maßen unserer Matrizen entstanden :) Wenn man die nun extrem vergrößert oder verkleinert können schon lustige Mutationen entstehen. Das ist ganz klar bei PixelController besser gelöst!


    mir ist beim Capture noch was eingefallen: es wäre besser, wenn der Capture-Bereich nicht links oben im Eck beginnt, sondern etwas weiter innen - k.A. ob ich zu blöd bin, aber ich schaffe es nicht, z.B. das VLC-Player-Fenster so weit nach oben zu verschieben, dass die Titelzeile *komplett* weg ist - daher sieht man die auch immer auf der Matrix:


    Ich weiß nicht ganz recht ob ich dich richtig verstanden habe, aber hast du mal versucht während "Capture" läuft auf der entsprechenden Seite auf "Configure Animation" zu klicken? Falls nicht, lass Dich mal überraschen was dann kommt :P


    andere Idee noch: manche hier haben ja Schwierigkeiten, das Teil zu "installieren", also extra noch RXTX runterladen, wo muss das hin, starten über Console - was hältst Du davon, einfach die nötigen Komponenten in einen Ordner zusammen zu packen, und den zu zippen..?


    Ja die Idee kam mir auch schon, nur müsste man dann halt die RXTX für alle denkbaren Zielsysteme integrieren, also WIN, UNIX, 32 / 64 Bit, MAC u.s.w. Vielleicht fällt mir da noch was ein!


    Mir ist beim Capture aufgefallen, dass wenn man die Matrix von 32x16 umstellt in meinem Fall auf 16x16, es so gut wie unmöglich ist, das Capture auf die ganze Matrix zu bekommen, entweder habe ich rechts eine Pixelreihe schwarz (also nichts "gecaptured") oder die unterste Reihe ist schwarz.


    Bei 32x16 ist es ganz leicht


    Das Caputure-Fenster musst Du von der Größe her immer auf möglichst ganzzahlige Vielfache des Seitenverhältnis' der Matrix-Größe einstellen, sonst wird an den Rändern was abgeschnippelt, weil ich nicht wollte, dass das Capture-Fenster die aufgenommenen Inhalte verzerrt! (Was für ein Satz :P ). In einer kommenden Version von GLEDIATOR werde ich mal versuchen das Seitenverhältnis des Capture-Fensters fix auf das der Matrix zu setzten!


    Beste Grüße,


    Pepe

  • Ja, ich denke auch dass das die Motivation war! Da hat der liebe Michu wohl ein Stück weiter gedacht als ich :thumbup:
    Die Effekte in unserer SW sind ganz klar aus den Maßen unserer Matrizen entstanden :) Wenn man die nun extrem vergrößert oder verkleinert können schon lustige Mutationen entstehen. Das ist ganz klar bei PixelController besser gelöst!

    Nur vorab, weil ich hier im Forum schon ab&zu mit meiner Schreibweise angeeckt bin: Wenn ich irgendwie/wo schreibe "besser" oder "nicht so gut" o.ä., dann ist das nie abwertend/urteilend gemeint! - ich finde beide SWs sehr interessant, sind halt unterschiedliche Konzepte... nur so zur Info, manche hier haben sich wegen solchen Wörtern meinerseits schon auf den Schlips getreten gefühlt, das ist nie meine Absicht!


    wie gesagt, bei Dir könnte man das auch mit Verhältnissen machen, also z.B. Metaball Durchmesser 12 ist dann nicht stur 12 Pixel, sondern eben z.B. 12 %, also bei 16 Pixel Matrix-Höhe dann (12/100)*16 = 2 Pixel - dann muss man zwar auch rechnen, aber nur ein Mal, nicht erst die Animation auf's Vorschaufenster anpassen, und dann auf die HW-Auflösung runter rechnen... das ist insofern "besser", weil's nicht so viel Rechnerei braucht...


    gut, dass Pixelcontroller bei mir nun praktisch 98% CPU-Last erzeugt, liegt wohl auch daran, dass ich da gleich 5 Vorschaufenster habe, in denen allen gleichzeitig Animationen laufen... wenn ich mich da auf 2 beschränken würde, dann sähe es wohl auch wieder anders aus...


    aber bei Euch mit den auf 32x16 angelegt, das passt schon gut, weil so in der Richtung werden wohl die meisten hier ihre Matritzen bauen - und bei mir mit 15x10 - 20x10, sowie manchem mit 8x8 sehen die Effekte ja immer noch gut aus...


    und ganz gleich auf jeder Matrix bekommt man das eben einfach nicht hin, ist ja klar, wenn die Auflösung für nen detailierten Effekt nicht reicht, dann reicht sie halt einfach nicht, da kann man auch mit Rechnen nix dran ändern... ;)


    Ich weiß nicht ganz recht ob ich dich richtig verstanden habe, aber hast du mal versucht während "Capture" läuft auf der entsprechenden Seite auf "Configure Animation" zu klicken? Falls nicht, lass Dich mal überraschen was dann kommt :P

    Ah, Fu***, sorry, da hatte ich echt nicht dran gedacht, dass man das da einstellen könnte... ;)


    super Sache! - da war dann wohl auch dieses halbtransparente Fenster, das ich nie zu Gesicht bekommen hatte ;) - ist aber echt nicht nötig (also, dass das halbtransparent ist), man sieht ja auch so gleich im Effekt-Fenster, was gecaptured wird...


    Ja die Idee kam mir auch schon, nur müsste man dann halt die RXTX für alle denkbaren Zielsysteme integrieren, also WIN, UNIX, 32 / 64 Bit, MAC u.s.w. Vielleicht fällt mir da noch was ein!

    Ja, schau' Dir doch mal Pixelcontroller an - das läuft auf allen Systemen, da ist noch ein Ordner namens "lib" dabei, in dem auch so Dinger sind wie "librxtxSerial.jnilib" (wohl für Mac oder Linux)


    weil ich nicht wollte, dass das Capture-Fenster die aufgenommenen Inhalte verzerrt! (Was für ein Satz :P ). In einer kommenden Version von GLEDIATOR werde ich mal versuchen das Seitenverhältnis des Capture-Fensters fix auf das der Matrix zu setzten!

    Das wäre natürlich wieder ne Erleichterung - und ich sehe das so wie Du, möglichst das Bild nicht verzerren - wenn man nun ne Matrix mit 2:1 hat, und ein Video mit 16:9, dann wird halt bisschen was abgeschnitten oder man hat schwarze Balken...


    direkt *Filme* capturen finde ich auch nicht so interessant, bei z.B. 32x16 sieht man da auch nur bunte Flecken, evtl. mal ein Gesicht in ner Nahaufnahme...


    für mich ist da halt interessant, z.B. animierte GIFs oder Flash-Teile zu machen (gleich in passender Auflösung für meine Matrix, also Pixel 1:1), die in nem kleinen Firefox-Fenster laufen zu lassen und da zu capturen - als weitere, eben "selbst gemachte" Effekte...

    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!