MatrixMover - Noch eine LED Matrix Steuerung

  • Puh, hier hat sich schon wieder einiges getan :)


    Hmm ich finde Ehrgeiz eigentlich noch gut, das haben wohl die meisten hier die was "machen". Und ob jemand etwas als OpenSource veröffentlichen will oder nicht ist eigentlich sache des Entwicklers. Wenn einer das nicht als OpenSource veröffentlichen will habe ich absolut keinen stress. Wo ich aber stress habe, ist wenn ich was unter GPL veröffentlicht habe, und das jemand nimmt die Lizenz ändert und den Source nicht veröffentlicht (sprich Lizenz verletzung).


    Du hast vollkommen Recht und das war nicht ok. Die erste version meines codes war unter aller sau. Das wollte ich der öffentlichkeit noch nicht präsentieren. Ich habe nun einiges an der Doku gemacht und alles unter GNU gestellt. In klassen, die code von dir bzw. PixelController enthalten habe ich einen entsprechenden verweis auf dein Git-Repository gesetzt. Wenn du nen anderen Verweis wünscht, lass es mich wissen.


    Es liegt jetzt alles auf Github unter (link entfernt). Hab erstmal alles hochgeladen, hab etwas Zeitnot. Hoffe, dass passt jetzt erstmal so :thumbsup:


    Eine Frage: Wäre es möglich, das Protokoll das zum Ansteuern der Platinen von Pepe nötig ist, auch zu implementieren? Dann wäre ein direkter Vergleich wirklich möglich, wenn dann in 1-2 Monaten die Matrix damit an der Wand hängt :D


    Möglich, wenn Pepe mir entsprechendes Protokoll zukommen lassen würde. Aber da quatsch ich mit pepe am besten per PM drüber :)


    Was wirklich cool wäre, wäre wenn du das GUI für PixelController gemacht hättest. Weil dann müsste man die Funktionen nicht erneut testen (ArtNet) und das Projekt hätte mehrere Entwickler.


    Was meinst du dazu?


    Naja, hätte ich eigentlich gerne gemacht. Aber ich war schon etwas müde, mich so tief in PixelController einzuarbeiten. Da hat mir einfach der ansporn gefehlt. Und der Kern von MatrixMover unterscheided sich schon um einiges von PixelController. Aber da ja nun alles veröffentlich ist, kannst du die gui gerne selber anpassen!


    Was bestimmt auch interessant für dich ist ( michu): Ich habe angefangen die Generatoren komplett neu zu parametrisieren. Bis jetzt Plasma, ColorScroll und ColorFade. Vielleicht isses auch für Pixelcontroller Interessant.


    Natürlich gibbet nu auch ne neue Version. Link findet ihr oben im 1. Post. Changelog sieht so aus:


    Code
    1. 0.2 alpha
    2. * added table to configure colors for effects
    3. * added settings for ColorFade
    4. * added bpm based speed control to ColorScroll and ColorFade
    5. * added Plasma and its SettingsDialog
    6. * added Prototypes: Metaballs, Textwriter
    7. * added Effects: Emboss, Monocrome, Monocrome Invers
    8. * added Mixer: AddSat, Mix, NegativeMultiply, Xor, MinusHalf, Either



    Viel spass damit :)

  • Und noch ne neue Version. So langsam wirds :)


    Hier mal das aktuelle changelog

    Code
    1. * scene selection buttons now highlighting if changed or active
    2. * fixed comboboxes changing when new scene selected
    3. * added audio system and input level display
    4. * added pixelwise output mapping
    5. * added pixel mapping
    6. * added Artnet Device
    7. * fixed ColorScroll and ColorFade freezing


    Das zip gibts hier: (link entfernt)


    Im data ordner liegt die datei config.properties, darin müsst ihr matrixmover für euere installation anpassen.


    Vielleicht können die Leute mit ArtNet das dingen nun mal testen. Bin auf feedback gespannt :) Als nächstes steht dann MiniDMX, 2 einfache effekte und ein paar audio effekte und ein audio setup auf den programm.


    Stay tuned 8)

  • hey McGyver


    ich denke das sollte gehen, ist ja zu 95% mein code ;)


    noch eine kleine Anmerkung zum deinem Code, Klassen die du von dem PixelController Projekt übernommen hast, sollten das Copyright oben behalten wie es war, Beispiel Klasse: ArtnetDevice.java


    Original :
    /**
    * Copyright (C) 2011 Michael Vogt <michu@neophob.com>
    * Copyright (C) 2011 Rainer Ostendorf <mail@linlab.de>


    Deine Version:
    /*
    * Copyright (C) 2012 Gyver


    ist nicht so die feine art... Grundsätzlich finde ich es gut, dass PixelController jemand anders inspiriert, jedoch sollte dazu die nötigen credits gegeben werden und wie schon oben gesagt, copyright meldungen nicht einfach überschriebn werden.


    cheers

  • @michuNeo
    Könntest Du sowas bitte mit McGyver per PN klären, ich finde das gehört hier nicht her. Hier sollte es um die Software als solches gehen und der halbe Beitrag besteht bald nur darin über Copyrights zu diskutieren.


    McGyver
    Du hast mich überzeugt. Mit Deiner Software versuche ich auch mal ein bissel in die Matrix einzusteigen. Als erstes wollte ich dazu den Eiwomisa Controller dazu fähig machen MiniDMX zu empfangen und genau da liegt mein Problem. Leider finde ich keine wirkliche halbwegs "standardisierte" Versionsbeschreibung zum erweiterten MiniDMX ala "MiniDMX v3.0" oder so ähnlich. Ich würde mich bei der Empfangsroutine grundsätzlich erst mal an den Mini-DMX Standard halten. Nun gab es hier ja schon mehrere Diskussionen den Standard zu erweitern damit größere Pakete gesendet werden können, aber wirklich ein dokumentiertes Ergebnis gab es bisher nicht. In diesem Beitrag wurde zwar darüber gesprochen, aber als sich der "Vater" von MiniDMX dann gemeldet hat, hat sich das irgendwie verlaufen.


    Ich würde hier gerne eine Senderoutine haben die dann mit dem erweiterten Standard funktioniert und mit dem bisherigen genauso. Vielleicht könnte auch Pesi da nochmals einen Beitrag erstellen wo es wirklich nur um diesen Standard geht und dieser nicht im TTT Bereich versauert. Es wäre dann natürlich auch gut wenn sich die Entwickler von der Software dort zu Wort melden würden.


    Ansonsten finde ich es Top was hier gemacht wird.


    Gruß, Benny.

  • Könntest Du sowas bitte mit McGyver per PN klären, ich finde das gehört hier nicht her. Hier sollte es um die Software als solches gehen und der halbe Beitrag besteht bald nur darin über Copyrights zu diskutieren.

    Naja, wenn da wirklich Copyright-Einträge überschrieben wurden, dann kann bzw. muss man schon öffentlich drauf hin weisen, das haben ja bestimmt auch schon ein paar in der "falschen" Version runtergeladen, die sollen das ja auch mitbekommen... was halt nicht geht, wenn der MichuNEO dem McGyver ne PN dazu schreibt...


    Ein bisschen o.t. ist in so nem Forum auch ganz normal, siehe z.B. den Eagle-Thread, der auch zu 50% aus der alten (dort o.t.) Leier Eagle vs. Target besteht... :D


    Leider finde ich keine wirkliche halbwegs "standardisierte" Versionsbeschreibung zum erweiterten MiniDMX ala "MiniDMX v3.0" oder so ähnlich.

    Weil's die noch nicht gibt! ;) - das "Recht" auf den Namen "Mini-DMX" hat der Matthias Dzionsko, nur der kann ne Version 3.0 ausrufen... Daher war in dem Thread ja auch von einer "inoffiziellen Erweiterung" die Rede, also praktisch, man nimmt Mini-DMX als *Vorbild* (wie das da gemacht ist mit Blockstart/Ende und Framesize-Angabe) und macht ein Protokoll, das abwärtskompatibel ist, aber mit selbst festgelegten Framesize-Bytes... so als "Forums-Standard"


    wie schon paar mal erwähnt, ist das dann meist auch kein "echtes" Mini-DMX mehr, weil eben dieses Frame doppelt puffern und bei Fehler verwerfen entfällt (*muss* auch oft entfallen, ausser man nimmt nen "wirklich großen" AVR mit meinetwegen 8 kB RAM, je nach Framegröße...), auch viele Sender (z.B. Glediator, DMXcontrol, ..) halten sich auch nicht genau dran, die schicken auch einfach raus, egal ob ne Rückmeldung kommt oder nicht...


    ist eben (wie im anderen Thread schon angesprochen) auch gar nicht nötig, die Übertragung ist schon sicher genug... bei meiner Kugelketten-Matrix z.B. hängt ein "Mini-DMX"-Receiver direkt am Rechner, der empfängt nach Standard (also bis auf die Framegröße natürlich) Mini-DMX, puffert das auch und verwirft ggfs. Frames bei Fehlern, macht die Rückmeldung (damit PixelController den Port findet) - das Teil schickt dann aber über 20 m billiges Mikrofonkabel die Daten nach "Pseudo-Mini-DMX", also *ohne* Rückmeldung, *ohne* Frames verwerfen bei Fehlern, die Daten zu den Kugelketten-Controllern, mir wäre den ganzen Abend (5 Stunden Party) kein einziges Flackern oder sonstige Fehler aufgefallen...


    In diesem Beitrag wurde zwar darüber gesprochen, aber als sich der "Vater" von MiniDMX dann gemeldet hat, hat sich das irgendwie verlaufen.

    naja, was heisst "verlaufen"...? - da gibt's halt einfach nix neues... der Matthias Dzionsko wollte sich dort wieder melden, wenn er den neuen Standard fertig hat, aber da ist er wohl noch dran...


    ansonsten besteht der besagte Thread ja auch zu 70% aus o.t. über sichere Datenübertragung im Allgemeinen.. :D - ggfs. mache ich dann noch mal nen neuen hier bei "LED Schaltungen, Treiber und µC" auf... also wenn eben Interesse daran besteht, dass wir hier im Forum uns auf nen Standard einigen...


    man kann nun also entweder drauf warten, bis der "Vater von Mini-DMX" nen neuen Standard veröffentlicht... oder wir machen hier im Forum einen eigenen *auf Basis von Mini-DMX*, den offiziellen Mini-DMX-Standard neu machen können *wir* ja nicht...


    gehört ja auch in diesen Thread: McGyver, wenn Du dann "Mini-DMX" (oder wie auch immer) einbaust, was hältst Du von dieser Tabelle hier..? - Und MichuNeo und Pepe1981 (Ihr lest ja hier mit) ebenfalls gefragt, da sollten ja dann doch alle die selben Framegrößen und zugehörigen Startbytes benutzen, wenn man nicht wieder zu jedem Programm ne andere HW haben will....?


    ansonsten kann ja auch jeder sein eigenes Süppchen kochen, notfalls halt dann alles über Artnet oder die jeweiligen proprietären Protokolle - aber *schöner* wär's natürlich schon, wenn man da ne gemeinsame, einfache Schnittstelle zu Eigenbau-HW hätte... :)

    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!

    Einmal editiert, zuletzt von Pesi ()

  • gehört ja auch in diesen Thread: McGyver, wenn Du dann "Mini-DMX" (oder wie auch immer) einbaust, was hältst Du von dieser Tabelle hier..? - Und MichuNeo und Pepe1981 (Ihr lest ja hier mit) ebenfalls gefragt, da sollten ja dann doch alle die selben Framegrößen und zugehörigen Startbytes benutzen, wenn man nicht wieder zu jedem Programm ne andere HW haben will....?


    Ja, dass sollten wir absprechen und vielleicht in eine eigene library gießen. Dann sind auch sicher die Programme kompatibel zum vereinbarten standard ...


    Gruß

  • gute Idee! :thumbup: - darüber könnte man ja dann in diesem Thread weiter diskutieren, das wird hier sonst wirklich zu o.t. ...

    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!

  • naja, was heisst "verlaufen"...? - da gibt's halt einfach nix neues... der Matthias Dzionsko wollte sich dort wieder melden, wenn er den neuen Standard fertig hat, aber da ist er wohl noch dran...

    Naja, nach Deinem Kommentar:

    Zitat

    Hm, naja, ausser dieser o.t.-Diskussion über die Sicherheit hat das leider niemanden so richtig interessiert - hier z.B. wurde das Mini-DMX-Protokoll mit den neuen Framegrößen eingebaut, das war's dann schon...

    würde ich mich an Stelle von Mathias auch nicht mehr melden, zumindest hört sich der Kommentar von Dir danach an das es keinen Bedarf mehr gibt.


    Ich benutze nun in dem Eiwomisa einen ATMEGA1284P, der hat 16K SRAM und somit stellt da das Puffern kein Problem dar. Und es ist auch nicht ganz so unwichtig das man sich bei dem Protokoll einig ist, das mag bei Dir bei so paar Lichtkugeln ok sein, aber nicht bei mir wenn ich das in meinen Controller reinsetze. Da kann ich nicht all Furz den Code ändern und von den Anwendern erwarten das die das alle selbst flashen, 99% dieser Anwender haben nicht mal einen Programmer.
    Daher ist es für mich schon wichtig einen Standard zu haben und wir sollten da vielleicht nochmals auf Mathias zugehen. Ich könnte mir vorstellen das der Deine Aussage in den "falschen Hals" bekommen hat. ;)


    Gruß, Benny.

  • Ja, Du kannst Dir ja immer viel vorstellen... :D - darum geht's hier aber nicht... lt. Turi (der den Mathias auf diesen Thread aufmerksam gemacht hat) ist er an *seinem* neuen Standard dran, kommt wohl irgendwann, aber wieso sollte er posten, solange es nix zu berichten gibt..?


    letztlich bezog sich sein Post hauptsächlich auch auf diese o.t.-These, dass sein Protokoll nicht sicher sei, er hat erklärt, warum es das seiner Meinung nach doch ist - dazu ein kleiner geschichtlicher Abriss über Mini-DMX - zum eigentlichen Thema lautet die Aussage ja:

    Jedem ist es freigestellt das MiniDMX-Protokoll als Vorlage zu nehmen, mit eigenen Erweiterungen zu versehen und dann zu veröffentlichen. Er sollte dann aber deutlich darauf hinweisen.


    Ich benutze nun in dem Eiwomisa einen ATMEGA1284P, der hat 16K SRAM und somit stellt da das Puffern kein Problem dar.

    Und wen interessiert's... ?( - es gibt auch noch andere HW auf diesem Planeten als den Eiwomisa... :D


    Und es ist auch nicht ganz so unwichtig das man sich bei dem Protokoll einig ist, das mag bei Dir bei so paar Lichtkugeln ok sein, aber nicht bei mir wenn ich das in meinen Controller reinsetze.

    Thread nicht gelesen...? - es geht doch eben *genau darum*, ein festgelegtes Protokoll zu schaffen! - meine paar Kugeln kann ich auch mit *irgendwas* steuern, dazu brauche ich weder nen Standard noch muss ich extra nen Thread im Forum aufmachen... :D


    Und wer den schafft, ist doch wurscht - wenn alleine schon 3 Freeware-Matrixsteuerungen und div. HW hier aus dem Forum diesen Standard unterstützen, dann *ist* es einer, auch wenn er *genausowenig* wie Mini-DMX von USITT oder DIN oder sonstwas genormt ist! Damit geht das gewollte ja bereits, es geht letztlich nur noch um das angleichen von ein paar Parametern...


    Wie gesagt, das kann doch jeder machen wie er will - auf die nächste offizielle Mini-DMX-Veröffentlichung warten, gemeinsam hier im Forum an einem Protokoll weiter arbeiten, das *jetzt bereits schon* zur Steuerung von Matritzen mit mehr als 512 Kanälen benutzt wird, oder ganz was anderes machen (Du kannst ja auch für Dich ein Eiwomisa-Protokoll schaffen, spricht ja nix dagegen).


    Da das Ganze anscheinend ja für Verwirrung sorgt, würde ich dann vorschlagen, für das hier im Forum erarbeitete Protokoll (wenn es denn genug interessiert) einen eigenen Namen zu verwenden, und aber natürlich - wie sich das gehört - immer drauf hinweisen, dass die Vorlage dazu Mini-DMX war...


    Daher ist es für mich schon wichtig einen Standard zu haben und wir sollten da vielleicht nochmals auf Mathias zugehen.

    ja, mach' doch, hindert Dich doch keiner daran... ?(


    also, bitte, keinen weiteren o.t. hier, über dieses neue Protokoll *auf Basis von Mini-DMX* kann man in dem zugehörigen Thread diskutieren, aber bitte auch dort *sachlich*, nicht wieder so Sachen wie *Du* irgendwleche Aussagen von mir auffasst... :thumbup:

    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!

    Einmal editiert, zuletzt von Pesi ()

  • Schaut gut aus - mit Artnet habe ich allerdings noch nichts zum Leuchten gebracht. MAC OSX Lion, 4x4 Matrix, folgende Config:

  • Und wieder gibts was neues ;)


    Da Artnet nun zu laufen scheint und man die Software nun für das benutzen kann, für was sie gedacht ist gibts jetzt die erste beta Version: (link entfernt)


    Changelog sieht so aus:

    Code
    1. * added rain generator and configuration
    2. * added shapes generator and configuration
    3. * added loading and saving of scenes
    4. * added splashscreen
    5. * fixed artnet


    Der shapes generator ist sehr mächtig. Ich denke, da kann man noch sehr viel mehr mit anstellen.


    Ihr müsst - wenn ihr das data Verzeichnis nicht ersetzt - die fehlenden Einträge in der config.properties anpassen.


    Viel Spass damit!


    Gruß
    Gyver

  • 8| Echt genial! :thumbsup:


    Shapes ist wirklich super, da kann man ja auch die Kringel machen, die ich so mag ;) - und noch viel mehr, super Sache!


    Artnet funktioniert bei mir nun auch zuverlässig, bei der Alpha ging's mal und mal nicht, was aber natürlich auch wieder mal an meiner Uralt-Kiste liegen kann...


    tatsächliche HW/Node habe ich leider noch nicht, nur mal mit Artnetominator nachgeguckt, ob/was da kommt, das zeigt nun *immer* Daten an :thumbup:


    sehr schön wäre es nun noch, wenn es eine Möglichkeit gäbe, das direkt über USB seriell auszugeben... :love:


    die Diskussion über das modifizierte Mini-DMX ist leider wieder mal eingeschlafen, mir persönlich wäre es dann auch egal, ob das nun modifiziertes Mini-DMX ist, oder Pepe sein Protokoll, oder - wie schon mal im Gespräch war ;) - ganz was neues eigenes...


    ich würde dann dafür SW für nen µC machen, die dieses Protokoll empfängt, und damit direkt WS2801/TM1804/LPD6803-etc.-Strips ansteuert, bzw. DMX ausgibt (mal sehen, mit SW-UART sollten schon so 4-6 drin sein...) - damit nicht wieder irgendwer was falsch auffasst: Die stelle ich dann ebenfalls open source in's Forum rein, und die ist dann auch nicht auf irgendeine spezielle HW angewiesen...

    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!

  • sehr schön wäre es nun noch, wenn es eine Möglichkeit gäbe, das direkt über USB seriell auszugeben... :love:


    Soll auf jeden fall kommen. Kann ich aber leider nicht testen. Macht das Implementieren also n bissel knifflig.


    die Diskussion über das modifizierte Mini-DMX ist leider wieder mal eingeschlafen, mir persönlich wäre es dann auch egal, ob das nun modifiziertes Mini-DMX ist, oder Pepe sein Protokoll, oder - wie schon mal im Gespräch - ganz was neues eigenes...


    Mir isses im Prinzip egal. Ich würde sagen, ich implementiere dass, was die andern beiden schon drin haben. Dann unterstützen alle 3 Programme das gleiche Protokoll. Da habe ich aber noch nicht den richtigen Überblick und muss mich noch mal einlesen.

  • Soll auf jeden fall kommen. Kann ich aber leider nicht testen. Macht das Implementieren also n bissel knifflig.

    Da biete ich mich gerne an! - Turi wollte Dich eh' kontaktieren, ob Du Interesse daran hast, HW zum ausprobieren von ihm gestellt zu bekommen, da wäre ja ein Bootloader drauf, könnte ich Dir auch immer entsprechende Firmware zum testen schicken...


    Ideal wäre halt, wenn man sich *erst* auf ein Protokoll einigt, dann bekommst Du die Test-HW, kannst Dein Ausgabemodul schreiben, was dann Pepe und Michu wiederum (wenn Interesse, zumindest Pepe hat schon solches signalisiert) bei sich einbauen können...


    Mir isses im Prinzip egal. Ich würde sagen, ich implementiere dass, was die andern beiden schon drin haben.

    Beide haben - neben Artnet - das "modifizierte Mini-DMX" drin, mit den Framegrößen wie hier angegeben - Pepe hat zusätzlich sein eigenes Protokoll... das wurde hier im Thread ja auch schon mal vorgeschlagen, das auch hier einzubauen...


    dieses finde ich ja - wenn's rein um das verschicken von Pixeldaten geht - eigentlich auch nicht schlecht: bei dieser Anwendung ist's ja nun wirklich egal, ob man 254 oder 255 Helligkeitsstufen hat, aber dadurch, dass es ein dezidiertes Blockstart-Byte gibt, wird z.B. die Weiterleitung (Daisy Chain) deutlich einfacher als bei ner festgelegten Framegröße - also das kaskadieren von mehreren Empfängern ohne die explizit Adressieren zu müssen, wie Pepe es bei seinen Steuerplatinen ja auch macht...


    das weitere vorgeschlagene neue Protokoll (Blockstart, 2 Bytes für die Framegröße, Nutzdaten, Blockende) hätte dagegen den Vorteil, dass man es auch zum übermitteln von Kommandos benutzen könnte, also z.B. Matrix-HW damit "aus der Ferne" konfigurieren" - wie gesagt Startbyte, dann High-Byte für die Framegröße, dieses aber max. 0x0F (mehr als 4.096 Byte/Frame machen über USB/Seriell wirklich nicht Sinn) - kommt statt 00-0F nach dem Startbyte FF, sind die folgenden Bytes Befehle, die man z.T. auch noch normen könnte...


    z.B. so Sachen wie (*könnte* man dann machen, muss ja aber auch nicht), dass die Matrix zurück meldet, wie groß sie ist und wie verkabelt, und die SW sich dann automatisch darauf einstellt - oder eben, wurde ja schon oft nachgefragt, wenn man Szenen extern auf Standalone-Player speichern will, könnte man das auch über solche Befehle machen, z.B. "die folgenden 300 Frames unter Programm-Nummer 17 auf die SD-Karte speichern", o.ä.


    wären halt viele Möglichkeiten, die man dadurch nutzen *kann*, aber auch nicht muss - einfach ein vielseitiges, auch noch erweiterbares Protokoll für viele solcher Anwendungen. Wirklich sinnvoll natürlich nur, wenn möglichst viele mitmachen...


    bei Befehlen dann natürlich mit Rückmeldung (z.B. "Daten erfolgreich auf Karte gepeichert", "Konfiguration der Matrix: GBR 16x16 Snake vertical", etc., natürlich mit Kürzeln), beim reinen Daten senden aber ohne - um Zeit und Aufwand zu sparen, bei Artnet (UDP) gibt's ja auch keine Rückmeldung, ob die Pakete tatsächlich alle angekommen sind (?), und bei DMX auch nicht, das funktioniert ja auch alles seit Jahren problemlos...


    auch so Sachen wie bei Pixelcontroller, dass ja den Port automatisch findet, wären damit wieder möglich: SW schickt halt an allen Com-Ports ne Abfrage raus, wo dann ne entsprechende Meldung zurück kommt, da hängt das Interface dran... oder auch mehrere


    von weiterem rumgeschraube an Mini-DMX halte ich mittlerweile am wenigsten, da ist einfach z.B. das Problem mit den Blockgrößen, jeder hätte gern andere, Rückmeldung braucht Zeit und Aufwand, und falls doch mal das offizielle MiniDMX 3 kommt, wird's dann nicht mit der inoffiziellen Erweiterung kompatibel sein, dann gibt's nur noch mehr Verwirrung... solche ist jetzt ja schon vorhanden, weil der Artnet-Node von T64 nun schon andere Framesize-Bytes benutzt als Pixelcontroller und Glediator...


    also lieber gleich was ganz neues eigenständiges. ;)

    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!

  • Also wenn ich meinen Senf dazu geben darf (oder eher Wunsch), dann ist es das FF-Byte für "besondere Aufgaben". Ich denke, die Konfiguration oder auch der Aufruf von standalone-Programm und und und sollte schon vorbereitet sein.


    Das Thema der Frame-Größe bis 4096 wird natürlich dann wieder interessant, wenn man über Netzwerk kommuniziert, also direkt. Dann sind sicher höhere Frame-Raten denkbar. Aber da hätte man ja auch noch genügend Raum nach 0x0F.


    Was mir immer ein wenig am Herzen liegt, ist ein offline-Modus. Aber dazu fehlt momentan auch die passende Hardware. Ich denke, es gibt auch einige Anwendungsfälle, wo das sinnvoll ist. Dann könnte man ja das FF-Byte wieder nutzen und danach eine Programmnummer oder sowas vorsehen.


    Aber alles nur als Idee/Wunsch verstehen ....

  • Sop, hier gibts wieder ne neue Version!


    Changelist:

    Code
    1. * added fading method
    2. * added timed automated fading
    3. * added auto scene changer
    4. * added controls and colormap to fire effect
    5. * added controls and threshold to metaballs


    Der feuer und metaballs effekt sind nun richtig zu gebrauchen, sind jetzt halt auch voll parametrisiert. Außerdem hab ich, wie gewünscht ;) , einen getimeten fade eingebaut und noch ein paar fade-methoden hinzugefügt. Habe noch ein paar kleine bugs gefunden, die ich die tage lösen werde und n silent update machen werde, da sie die Funktion nicht stören.
    Außerdem hab ich noch nen automatischen scenenwechsel gebastelt. So ist die software bei mir gestern das erste mal gelaufen und hat brav alle scenen durchgescrollt. Ganz, wenn man nicht die ganze zeit selber an der software rumtüddeln will :D


    Die todo liste schrumpft so langsam. Auf jeden fall muss vorm release noch die audio funktionalität eingebaut bzw. erweitert werden. Dann folgen auch hoffendlich noch ein paar audio effekte. Auch will ich noch nen globalen BPM regler einbauen um alles besser zur musik zu syncronisieren. Zuerst werde ich noch den Textscroller fertig machen. Dann brauch auch nach nem update die scenen im data ordner (myscenes) nicht gelöscht werden. Die Effekte müssten dann also erhalten bleiben.


    Natürlich gibts auch noch weitere Ausgabeformate (wie miniDMX zum beispiel). Meldet euch doch einfach mal bitte, was ihr gerne so höttet, dann mach ich mir keine Arbeit umsonst.


    Neue version gibts wie immer im 1. Post oder hier: (link entfernt)


    Gruß
    Gyver