Posts by Moritz

    Eventuell wäre auch die OS2L Schnittstelle von Virtual DJ eine Alternative:

    mit Virtual DJ kenne ich mich nicht aus aber ich habe es geschafft aus Traktor ein Beat Signal zu bekommen. Zwar nutze ich nicht den Beat da der immer gesendet wird sondern ich habe mir die Phase von Master Deck geholt.

    In DMXC 3 habe ich mir dann jeweils Deck A und Deck B für master angelegt und jeweils die Phase für Deck A und B. Im Iput Assiment habe ich es dann entsprechend verdratet das mir nur das Master Deck den Beat (phase 0) als Beat ausgiebt.

    Es gibt für DMXControl 3 ein OS2L Plugin. Damit kann man das Beat Signal von Virtual DJ empfangen. Damit bekommt man dann direkt zuverlässig die Takte die auch in VirtualDJ angezeigt werden und mann muss in DMXControl nicht das Audiosignal auswerten, was ja prinzipbedingt nicht immer 100% treffsicher ist.

    Eine Alternative könnte eventuell ein Beamer sein, in Verbindung mit dem Beamertool kann man damit ähnliche Effekte erreichen wie mit einem Laser, ganz ohne die Risiken die ein Laser mit sich bringt.

    Ein Beispiel sieht man hier:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Der Beamer sollte möglichst Lichtstark sein, damit es gut aussieht. Erreicht natürlich nicht 100% eines Lasers, aber auch mit Beamer bekommt man gute Effekte hin, die in echt auch noch besser wirken wie nur im Video. Dafür lässt sich der Beamer aber gefahrlos betreiben und benötig keinenzusätzlichen Aufwand mit Laserschein, etc.

    Kannst du mal etwas genauer beschreiben was du gerne tun möchtest? Das klingt eventuell nach einer sehr komplizierteren Aufgabe, je nachdem was du tun willst. Ein einfaches Asyncrones setTimeout() wie z.B. in JavaScript gibt es in C++ nicht. Vorschläge sind z.B. hier: https://stackoverflow.com/ques…o-window-settimeout-for-c


    Aber ich glaube fast ohne richtiges Multithreading wirst du hier nicht wirklich weiterkommen. Selbst mit einem zusammengebastelten setTimrout Ersatz musst du je nachdem was genau du tun willst aufpassen was in wechem Thread passiert, gerade im zusammenspiel mit OpenGL kann da potentiel viel schiefgehen.


    Ich denke wenn du mal etwas abstrakter beschreibst was du tun möchtest oder passieren soll gibt es eventuell eine Lösung die besser zu C++ passt.

    Kannst du ggf. mal beschreiben welche der Schritte aus dem Handbuch du bereits durchgeführt hast und an welcher Stelle dann nichts passiert?

    Ohne genauere Beschreibung des Problems/Vorgehens ist es schwer aus der Ferne irgendwas dazu zu sagen.

    Ok, schwarzer Bildschirm wird schwer, weil ich an keiner Stelle wirklich abfragen kann was man sieht, das fertige Bild zu prüfen geht wie wie gesagt aus Performance-Gründen nicht praktikabel. Da müsste man das Bild von der GPU in den RAM kopieren und jedes Pixel prüfen.

    Und ob gerade Inhalt gezeichnet wird oder nicht hängt ja generell sehr von der Art des Inhalts ab, z.B. könnte ja eine Textur zur Hälfte schwarz sein, und dann gleichzeitig wird die Position so verschoben, dass der eigentliche Inhalt nicht zu sehen ist. Beim zeichnen kann ich dann nie wirklich wissen ob gerade der Bildschirm schwarz ist oder doch nicht.


    Auch im ArtNet Receiver wird auf 0 Prüfen nicht unbedingt helfen, gerade die Position hat ja einen default von "127". Wenn dann müsste man vermutlich mit einem Timer arbeiten und schauen ob denn überhaupt Pakete in den letzten X Sekunden gekommen sind und sonst annehmen, dass keine Verbindung besteht.

    Was verstehst du denn unter "nichts angezeigt"?

    Schwarzer Bildschirm oder kein Input über DMX/ArtNet?


    Den Bildschirm direkt zu prüfen ist gar nicht so einfach, bzw, wäre möglich aber ist extrem teuer was die performance angeht. Es kann halt ggf. vorkommen, dass nichts angezeigt wird weil z.B. bewusst über ArtNet die Größe eines Bildes auf 0 gesetzt, etc. Kein Input wäre ggf einfacher abzufragen, aber müsste man einbauen. Eine Stelle wo man das direkt schon abfragen könnte gibt es vermutlich noch nicht.


    Viele Grüße

    Moritz

    Wenn ich mir die technischen Daten des Surface 2 Pro Go und hier insbesondere den Prozessor ansehe, mag das mit einem kleinen Setup sowohl mit DMXControl 2 als auch mit DMXControl 3 funktionieren, da der verbaute Intel m3-8100Y einen recht hohen Turbo-Takt hat. Kann dieser über einen längeren Zeitraum (weitestgehend) gehalten werden, ist das recht unkritisch. Fällt der Takt aber schon nach kurzer Zeit auf den Basistakt von 1,1 GHz zurück, macht das Arbeiten gerade mit DMXControl 3 nur noch halb so viel Spaß (gerade wenn es ums Programmieren und ums Laden der Show geht). Ich habe selbst noch einen Laptop mit einer AMD-APU, die mit 2 x 1,3 GHz läuft, der mich genau in dieser Aussage bestätigt.


    Schaue ich mir im direkten Vergleich das Surface Pro 4 und den dort verbauten Intel i5-6300U an, sollte das Arbeiten mit beiden Programmen bei dem Gerät besser von der Hand gehen, weil der Prozessor trotz seines Alters mit 2 x 2,4 GHz eine besser Grundleistung hat.

    Bitte, bitte niemals!!! CPU Power anhand von GHz vergleichen. Das konnte man eventuell mal vor 20 Jahren mal machen, aber stimmt heute auf keinen Fall mehr. Insbesondere verschiedene Modellreihen oder gar Hersteller sagen darüber überhaupt nichts aus. Und auch ist älter, aber hat mehr GHz sagt überhaupt nichts über die Leistung aus.


    Ein Beispiel wären schon die aktuellen Modelle des Surface Go 2: Es gibt den schlechteren Intel Pentium Gold 4415Y und das bessere Modell mit dem oben genannten m3. Der m3 ist da deutlich schneller, jedoch hat der m3 1,1 GHz Takt und der Pentium Gold 1,6 GHz. Also genau andersrum verteilt als die tatsächliche Leistung.


    Auch der Turbotakt ist vermutlich hauptsächlich (generell bei CPUs) aus Marketinggründen angegeben, generell bei allen Notebooks/Laptops ist meistens die maximal erlaubte Abwärme das Kriterium das die Leistung beschränkt. Da hat der Turbo meistens eh nur wenig Reserven die man nutzen könnte. (Das ist so natürlich auch nur eine pauschale Aussage die ggf. im Detail anders ausfallen kann.)


    Verschiedene CPUs kann man am besten über Benchmarks vergleichen, das zeigt die tatsächliche Leistung. Ist natürlich auch nicht 100% aussagekräftig, weil die meisten Benchmarks nur bestimmte Rechenoperationen testen, die sich ggf. vom geplanten Einsatzzweck unterscheiden und dann durchaus bei verschiedenen Benchmarks die Ergebnisse zu gunsten der einen oder anderen CPU schwanken. Aber wenn man sich mehrere Benchmarks anschaut und so grob den Schnitt davon betrachtet, sollte man doch zu einem ganz guten Leistungsüberblick kommen. Hier mal ein Beispiel: https://cpu.userbenchmark.com/…-i5-6300U/m648336vsm27864
    Dort scheint der Vorteil des i5 nur recht klein auszufallen. Bitte aber auch noch andere Benchmarks in Betracht ziehen und nicht nur jetzt das Beispiel hier alleine betrachten.


    Im Bezug auf DMXControl ist aber schwer eine pauschale Aussage zu treffen welcher der Prozessoren jetzt besser passt. Die Mindestanforderungen sollten beide Prozessoren schaffen, die Frage ist halt wie viel hast du mit DMXControl vor. Je nachdem wie groß dein Projekt ist können die Anforderungen aber auch größer sein. Wenn du schon DMXControl im Einsatz hast kannst du ja mal die Hardwaredaten deines aktuellen Computers vergleichen mit den oben genannten Möglichkeiten.


    Und abgesehen von der CPU sollte man natürlich auch sonst überlegen was besser zu einem passt und mit was man besser Arbeiten kann. Z.B. Bildschirmgröße wäre noch ein wichtiges Kriterium, das Surface Go erscheint mir hier recht klein, aber ist natürlich Geschmacksache. Und am Ende natürlich auch noch der Preis bzw. Preis-Leistung und was man ausgeben will. Ich weiß jetzt nicht was das Surface Pro 4 kostet gegenüber dem oben genannten Surface Go 2.

    Ich hab jetzt doch mal noch kurz mein Raspberry ausgegraben und nochmal getestet. Um den Code zu bauen wird jetzt CMake verwendet. Das hatte ich schonmal irgendwann damals angefangen und vergessen, ist jetzt fertig im Repo. Das alte Makefile ist dann jetzt weg. Die Pfadangaben stimmen dadurch aktuell leider nicht, d.h. man muss binary und config Datei sowie die Texturen manuell in einen gemeinsamen Ordner nebeneinander verschieben, damit die config gefunden wird. Das schön zu machen, geht leider auf die schnelle nicht, dazu müsste man mal den Code anfassen, damit das sauber gelöst wird. Da bräuchte ich mal mehr Zeit.


    Ich weiß jetzt auch wieder warum es noch kein Release für buster gab. Das Beamertool binary selbst läuft mit den minimalen Änderungen zwar die im Repo sind, das Installer Script benötigt aber einen größerem Umbau, weil sich bei den anderen Programmen (samba freigabe, web control panal) Sachen verändert haben.

    Ja ich hatte das mal angepasst, es waren eh nur 2 Libraries die unter buster anders heißen. Allerdings glaube ich hatte ich kein Release gemacht davon, d.h. die veröffentlichten Binaries laufen weiter nur unter jessie, der Code sollte aber unter buster bauen. Und generell natürlich bitte auch beachten das ganze funktioniert nur auf dem Pi 1-3, der Pi 4 wird nicht unterstützt, der hat ja den neuen Graphikchip der die alten Low-Level Schnittstellen nicht mehr unterstützt, die vom Beamertool verwendet werden.


    Gerne einfach mal testen und sonst nachfragen wenn was nicht tut. Für weitere Entwicklungsfragen dazu dann aber gerne einen neuen Thread aufmachen oder mir ggf. direkt ne Nachricht schreiben.


    Und den Code bitte nicht zu ernst nehmen, wenn dort Dinge komisch erscheinen, das ist wirklich alles steinalt und damals noch vermutlich mit diversen Anfängerfehlern und anderen hässlichen Stellen und auch defintiv kein zeitgemäßer ordentlicher C++ Code :).

    Zur Not hilft auch hier wieder die Texturen per SSH zu übertragen, z.B. mit WinSCP.


    Webinterface würde ich den aktuellen Zustand nicht nennen, das ist ein minimales php script, dass ein paar commands ans Terminal sendet (unter Missachtung jeglicher moderner Sicherheitsfeatures :))


    Ideen zur Verbesserung sind hier nicht das Problem, geplant haben wir schon sehr viel, es fehlt halt leider die Zeit für die Umsetzung. Deswegen ist das beamertool jetzt auch schon wieder lange Zeit ohne update.