Hi,
hast du die entsprechenden Gobos auch in den UserDDF Ordner abgelegt? Denn wenn DMXControl 3 die Images dort nicht findet, werden die generischen Gobos mit den Zahlen angezeigt. Die auswahl funktioniert aber trotzdem normal, es fehlen halt die Gobo-Darstellungen.
Viele Grüße
JP
Musstest du irgendetwas am Code des Beamertools ändern? Wenn ja, dann gerne damit einen PullRequest bei unserem Repo stellen. Dann wird das eingepflegt und es wäre wieder lauffähig 
Hallo,
ich habe gerade kein DMXC vor mir, aber ich bin mir recht sicher, dass du in den Einstellungen des PositionMasters seinen Bereich (also Minimum und Maximum) einstellen kannst. So wie das z.B. auch bei anderen Mastern wie z.B. dem ParameterMaster der Fall ist. Das müsste dann deine Probleme lösen. Und damit wird auch nicht die "falsche Position" angefahren. Du bist einfach am Limit angekommen und das Verhalten ist exakt so, wie es sein soll 
Viele Grüße
JP
Vermutlich. Aber genauer kann ich das erst sagen, wenn ich das selbst ausprobiert habe. Könntest du aber vielleicht von so einem Lauf, bei dem dann nichts mehr geht, die Logs exportieren und an das genannte Ticket anhängen?
Hallo,
das scheint ein Bug zu sein. Könnte der gleiche Bug wie FS#5590 : FFT-Diagramm in den Timecode Shows werden nicht mehr richtig dargestellt / aktualisiert sein. Ich schaue es mir mal an.
Viele Grüße
JP
P.S.: Wir haben mittlerweile die 3.3.2 veröffentlicht, also kein RC mehr
Ist die Annahme korrekt: raw wird gefadet und rawstep wird nicht gefadet?
Ja deine Annahme ist korrekt: Raw wird gefadet und Rawstep nicht.
Hallo,
erst einmal: DMXControl 3 kennt für die unterschiedlichen Geräteeigenschaften auch unterschiedliche Überblendungs-Modi. Bei Farben und dem Dimmer fadet DMXControl 3 zwischen den beiden Werten, bei Dingen wie z.B. dem Shutter oder Gobos schaltet DMXControl 3 den Wert (üblicherweise ab der Hälfe des Übergangs. Daher wäre erst einmal die Frage, wie die entsprechenden Geräteeigenschaften, bei denen dich das Faden stört, genau im DDF definiert sind. Wenn du das DDF hier anhängst, kann man da mal reinschauen. Unter Umständen kann mit einer Anpassung hier schon das Verhalten korrigiert werden.
Dann gibt es aber auch noch andere Wege, das Verhalten zu beeinflussen. Eine spezielle Möglichkeit ist der sog. Cue Timing Editor. Mit diesem kannst du für jede Cue noch einmal genauer einstellen, wann (sprich welches Delay) und wie schnell (sprich die Fadetime) die einzelnen gespeicherten Geräteeigenschaften der Cue eingeblendet werden. So kannst du z.B. definieren, dass die Cue innerhalb von 2 Sekunden einblenden soll (was du über die entsprechende Zelle in der Cuelist-Tabelle einstellst). Aber im Cue Timing Editor definierst du dann explizit z.B. für die Eigenschaft der dargestellten Bilder, dass sie keine Fadezeit haben soll und mit dem Delay von 0 Sekunden, dass dieses sofort wechseln soll. Auch andere Werte sind hier möglich. Den Cue Timing Editor findest du, wenn du einen Doppelklick auf das vorderste Feld einer Cue machst.
Außerdem hatte ich mal ein Video zum Cue Timing Editor gemacht gehabt. Dieses findest du hier:
Hi,
eigentlich sollte das im Großen und Ganzen passen. Hintergrund ist der: Es gibt im IA zwei Port-Verhalten. Die eine Variante speichert und lädt die Werte am Port, die andere speichert sie nicht. Ersteres ist nötig, wenn der Port nicht verbunden ist und man einen Wert hinterlegt hat (das geht nicht bei allen Ports). Das andere Verhalten wird dann benötigt, wenn der Port verbunden ist und so die Werte aus dem angeschlossenen Port übernommen werden. Da werden die Werte aber aktuell trotzdem immer gespeichert und beim Laden meckert dann diese Komponente, dass sie die Werte nicht setzen kann. Aber wenn du sicher gehen möchtest, kannst du mir ml dein Projekt schicken (z.B. per PM) und ich kann es mal in der Entwicklungsumgebung öffnen. Dann sehe ich, ob es beim Laden zu irgendwelchen Problemen im Projekt kommt.
Viele Grüße
JP
Der Punkt ist, der SpeedMaster inkl. dem Effektsystem haben ein paar Einschränkungen, was die genaue Synchronisation und die Beats angeht. Deshalb bringt das alles auch nicht so richtig etwas, da darüber zu diskutieren
ich habe es bis jetzt so noch nicht in der Intensität gemacht, den Speed Master quasi dauerhaft nur per Sync zu triggern. Und gehört habe ich es bis jetzt an anderer Stelle auch nicht, dass es jemand so macht.
Die Variante via Sync den SpeedMaster zu triggern ist tatsächlich nicht richtig. Der SpeedMaster hat eine eigene interne Clock, welche den Beat macht. Der Learn-Input sorgt dafür, dass die Clock-Dauer entsprechend angepasst wird. Ein Sync stoppt die Clock und startet sie neu. Ein Learn setzt die Dauer. Aber er triggert auch einen Beat. Allerdings hat der Beat einen kleinen Cooldown, um doppelte Trigger zu vermeiden. Der Sync triggert den Beat auch, setzt aber die Dauer nicht. Der Cooldown ist aber abhängig von dem Interval zwischen Beats. Wenn du durch den Sync das Interval nie setzt, ist das bei einer größerem Dauer und der Beat geht u.U. durch diesen Cooldown verloren. Daher bitte den Learn verwenden.
Hallo und herzlich willkommen im Forum,
ein guter Punkt zu sehen, was an einem DDF nicht passt ist der Kernel. Dieser ist ein Teil von DMXControl 3 und führt u.a. die ganze Verwaltung und Berechnung durch. Wenn du DMXControl 3 startest, startet er mit, versteckt sich dann aber. Du kannst ihn aber wieder anzeigen, indem du den Launcher (das Fenster, was hoch kommt, wenn du DMXControl 3 startest). Dort gibt es unten "Kernel verstecken":
Da einfach den Schalter umlegen. Das geht auch, wenn DMXControl 3 schon läuft und du den Launcher einfach nochmal öffnest. Dann sollte ein Kommandozeilen-Programm erscheinen (der Kernel) und du solltest einige Logs sehen können. Dabei müsste dann auch unter den Logs eine Info drin stehen, wenn dem Kernel irgendetwas nicht passt bei einem DDF.
Zu den mehreren Sektionen: DMXControl 3 kann (aktuell) nicht wirklich gut mit Multi-Beam-Geräten umgehen. Daher ist es besser, diese als einzelne Geräte anzulegen. Sprich du hast dann ein Haupt-DDF, in dem alle Funktionen enthalten sind, die alle Sektionen betreffen. Zusätzlich erstellst du dann ein DDF, welches eine Sektion widerspiegelt bzw. schaust mal in den Generic DDF, ob eines dieser DDFs schon gleich ist wie eine Sektion. Dann fügst du dieses DDF so häufig ein, wie es Sektionen gibt und wichtig! lässt eine Gerätegruppe (automatisch) erstellen. So bekommst du dann die volle Funktionalität. Uns ist bewusst, dass dieser (schon länger bestehende Zustand) nicht so optimal ist. Aber wie gesagt bekommst du nur mit dieser Variante die volle Flexibilität und Funktionalität. Wenn dich das noch etwas mehr interessiert, kannst du mal in mein "Let's build a Project" schauen:
Dort erkläre ich die Problematik noch einmal etwas genauer und zeige auch, wie ich da mit entsprechenden LED-Bars umgehe.
Viele Grüße
JP
Hallo,
Leider musste ich feststellen, dass die Tutorial-Videos ab B4-02 (speziell der Bereich Audio Analyzer) nicht mehr verfügbar sind oder als "nicht verfügbar" angezeigt werden
Tatsächlich sind diese Videos noch nicht verfügbar. Hintergrund ist, dass die Produktion der Tutorial-Videos sehr aufwändig ist. So wurden die bisherigen Videos von 4 Leuten über etwa ein halbes Jahr hinweg produziert (immer in den freien Freizeitstunden). Daher haben wir damals Themen, bei denen wir wussten, dass sie sich nochmal ändern (z.B. das Input Assignment) nicht weiter intensiv betrachtet. Seitdem hatten wir noch nicht wieder Zeit, für die weiteren Themen Videos zu produzieren. Deshalb gibt es diese Lücken.
Zu deiner Frage, was es da gibt: Wir haben im Wiki eine Seite für den Audioanalyzer https://wiki-de.dmxcontrol-projects.org/index.php?titl…oanalyzer_DMXC3 Dort sind allgemeine Infos.
Und zu deinem konkreten Problem: Wie hast du denn den Analyzer konfiguriert? Wenn wir das wissen und nachstellen können, dann können wir dir ein paar Tipps geben.
Viele Grüße
JP
Hallo,
nein, das wird aktuell nicht persistiert und daher immer wieder auf den Standard zurückgesetzt.
Viele Grüße
JP
Ah öhm könntet du bitte ein Ticket aufmachen? Dann geht es nicht verloren und wir können es uns anschauen
Hi,
Maybe there is something I am missing internally as I don't understand or am familiar with the core architecture.
I am sorry to say this but in short: Yes, you do Thank you very much for your thoughts and I really appreciate that you try to help But without knowledge of the code it is almost impossible to present a working solution for this problem And even with knowledge of it (the founder of this part of the software was in the team which tried to implement the fanned mapping) every solution we tried did not work as intended. I can assure you that we (obviously) know the internal structure and yes, we also tried the way with groups. There are reasons, why the Position Mapping is a device and why the way with groups did not work as planed. As I said, we will work on it again in the future and try to find a better way.
DMXControl 3 supports RGBW matrixes. So maybe the definition of your DDF is not in the way DMXControl 3 expects. Could you maybe attach your DDF here so that we can see, what needs to be changed in it so that you can patch it correctly.
is it true and correct that a Pan/Tilt Fanning (Like 0>90) for a Position Mapping with 3 heads will not spread them across a wall?
I.e. I understood correctly that it is not implemented/by design?
This is actually the same problem as with the position fanning. Both are not implemented yet and we are trying to find a way to implement that. We tried to find this way already on our annual club meeting two weeks ago. But all tries failed so far. The issue is that a fanning is only broken down to every device, if the fanning is applied to a group. If it is applied to a device, the first fanning value is taken. Thus, at the point I am doing the mapping calculation I only get a single target value (for a single device) and not the whole fanning. Thus we need to find a way to get both worlds. But this is not so easy.
However, what you can do is to create multiple Position Mapping devices and map only one moving head in it but all on the same area. Then you can put those Position Mappings into a group and then you can apply fannings onto this group. So this is currently a (not so convenient) workaround to get the fanning working.
Hallo,
dass es sich dabei um Beta-Features handelt.
Erst einmal grundsätzlich. Nein, dabei handelt es sich nicht um ein Beta-Feature. Die von Stefan genannten Punkte sind während der Benutzung aufgefallen und wurden eben noch nicht korrigiert. Aber Stefan hat dir einen Workaround geliefert, mit dem du erst einmal arbeiten kannst.
Ich finde es ein wenig ungünstig, wenn diese Funktionen an den entsprechenden Stellen im Wiki totgeschwiegen werden. Wenn ihr solche Features im Wiki noch nicht aufnehmen wolltet, weil sie noch in der Entwicklung sind oder ihr noch nicht zu einer vollständigen Dokumentation gekommen seid, würde sicherlich nicht nur mir schon ein kleiner Hinweis an den entsprechenden Stellen helfen, dass es sich dabei um Beta-Features handelt.
Gleiches gilt auch für andere Funktionen, wie etwa Subdevices
Danke für deinen Wunsch, was sich bei unserer Dokumentation / in der Software ändern soll. Es ist uns jedoch durchaus bewusst, dass nicht alles im Wiki dokumentiert ist und damit "totgeschwiegen" wird. Um das alles glatt zu ziehen benötigen wir aber die für uns wichtigste Ressource, von der wir am wenigsten haben: Zeit. Die Menge an zur Verfügung stehender Zeit wird dabei hart durch zwei Faktoren limitiert: Die Menge an Zeit, die jeder individuell an Freizeit zur Verfügung hat und freiwillig dem Verein geben möchte. Hier ist entscheidend, wie viel Zeit man man neben Beruf, Familie und anderen Hobbies aufbringen kann. Aber es ist auch sehr wichtig, dass diese Person die Lust hat diese aufzubringen. Zum anderen ist es die Anzahl an Leuten, die sich für das Projekt aktiv einsetzen. Wenn wir nun einmal die Situation analysieren: Stefan ist momentan mehr oder weniger der einzige, der an der Dokumentation von DMXControl 3 arbeitet. Er hätte also statt dir zu helfen auch 2-3 Sätze im Wiki schreiben können. Da ist aber halt immer die Frage: Hilft man lieber einer Person im Forum, die gerade ein aktives Problem hat damit diese weiterarbeiten kann und wenn weitere Leute über diesen Post stolpern auch diesen. Oder hilft man ihr nicht und schreibt lieber Doku / bzw. programmiert an DMXControl 3 und hilft dabei einer unbekannten Anzahl an Personen. Genauso mein Post hier: Wenn ich fertig bin mit diesem Post, werde ich etwa 45min meiner Zeit investiert haben, unsere Zeitproblematik zu erklären. Diese hätte ich auch in neue Features für DMXControl 3 stecken können. Deshalb ist nun das DMXControl 3 Feature, an dem ich gerade arbeite, weniger weit vorangeschritten. Aber vielleicht erreiche ich ja mit dieser investierten Zeit doch etwas. Denn wo wir gerade beim wünschen sind:
Ich wünsche mir, dass sich mehr Leute finden, die wie Stefan, ich und die anderen Vereinsmitglieder gerne ihre Freizeit in das Projekt DMXControl und allem drum herum stecken. Damit sorgen wir dafür, dass sehr viele Nutzer von DMXControl 3 davon profitieren. Das würde auch helfen, die veränderte Lebenssituation (und damit einhergehend weniger zur Verfügung stehende Zeit) mancher Vereinsmitglieder abzufangen. Denn Zeit ist wie beschrieben das, was uns fehlt. Dabei hilft auch schon aktives unterstützen anderer Nutzer hier im Forum besonders aber eben auch das Commitment, sich bei der Doku, der Softwareentwicklung oder den anderen Themen des Vereins einzusetzen
Viele Grüße
JP
Die Antwort ist für mich plausibel, da… wenn ich Prozeduren korrekt verstanden habe… lediglich ein DMX-Wert kurzzeitig getriggert wird —> korrekt?
Ja, das ist genau so wie du das geschrieben hast.
Diese Pause, die du beobachtest, kommt von dem Unterschied zwischen der Überblendung von 5s und der Überblendung ausgehend von 10s. Beides betrifft ja wie du nun herausgefunden hast das Verhalten beim Einblenden einer Cue. Aber die aufdimmenden Werte wenden eben in deinem Fall eine Einblendzeit von 5s und die herunterdimmenden Werte eine Einblendzeit von 10s an. Du hast aber in deiner ersten Cue keine heruterdimmenden Werte, weil alle von 0 (dem Default) in der ersten Cue auf 100% aufdimmen. Trotzdem muss DMXControl 3 immer die längere der beiden Zeiten abwarten (also in deinem Fall 10s). Du siehst also nur die 5s (das Aufdimmen), aber DMXControl 3 muss 10s die Cue einblenden, denn wie bei jeder anderen Cue könnte es den Fall geben, dass Dimmerwerte heruntergedimmt werden müssen und dann greifen dort die 10s. Da das eben bei allen Cues konsistent sein soll, siehst du diese 10s in Form der 5s Einblendzeit und 5s Wartezeit.
Edit: Ah jetzt sehe ich erst die weiteren Nachrichten. Dieses versetzte Verhalten kommt dadurch zustande, dass diese beiden Zeiten pro Scheinwerfer arbeiten können was für Fannings wichtig ist. So können tatsächlich mehrere Cues in einer Cuelist gleichzeitig aktiv sein. Eben nur immer eine pro Scheinwerfer.
JPK
