Posts by namezero111111

Vielen Dank nochmals für eure Antworten.

Ein Position Master kann tatsächlich manuell so eingestellt werden, dass er -270; 270 zulässt, jedoch nicht über die GUI; diese ist auf -180; 180 beschränkt.
Beachte jedoch, dass die Position auf -180; 180 zurückgesetzt wird, sobald das Feld in der GUI bearbeitet wird..
Aber warum funktioniert es nicht, wenn ich einen Rule-of-Three-Knoten verwende und -270;270 vorher in -180;180 umwandle, bevor ich es so zuführe!?

LightningBrothers:
Ja, aber das würde andere Teile des Projekts beeinträchtigen.

Ich benötige dies, da ich externe Positionsdaten für eine Person mit einem Tag erhalte.

Diese Position wird dann verwendet, um den Schwenk-/Neigewinkel des Moving Heads zu berechnen, der der Person folgt.

Ich berechne alle drei möglichen Schwenk-/Neigekombinationen (primär, alternativ und Überschreitung) und wähle diejenige aus, bei der der Kopf die Überschreitungsgrenze nicht überschreitet.
Dies geschieht empirisch, da der Bewegungsbereich zwar begrenzt ist, aber außerhalb der Grenze von -180; 180 liegen könnte.

Ich habe einen Screenshot des Diagramms angehängt. Ich glaube, ich nutze die IA für Dinge, die an die Grenzen dessen gehen, wofür sie ursprünglich gedacht war, aber im Moment scheint es zu funktionieren.

Sry, das forum verkleiners den Screenshot hier auf fast unlesbar.

Diese Frage entstand im Anschluss an meinen vorherigen Thread.

Wie kann ich über den Position Master eine Position zuweisen, die tatsächlich berechnete Schwenk-/Neigebewegung? Der Position Master akzeptiert nur Eingaben im Bereich von -180° bis 180°. Innerhalb dieses Bereichs funktioniert die Zuweisung einwandfrei, außerhalb jedoch nicht. Wenn ich einen „Regel der Drei“-Knoten verwende, wird die falsche Position angefahren.

Okay vielen Dank das zu klarifizieren.

FS#4982 macht hoffnung, aber FS#3784 scheint ja wohl tot zu sein.

aber davon, dass sämtliche Werte inklusive Effekte an einer anderen Stelle generiert werden: nämlich auf dem Hilfsgerät. Dieses Hilfsgerät kann ein einfacher Generic Dimmer sein. Der einzige Unterschied ist, dass es kein reales Gerät gibt, was auf diese Werte reagiert. Stattdessen rangiert es mit einer komplett abgelegenen DMX-Adresse auf einem anderen DMX-Universum im Projekt. Auf diesen Generic Dimmer "packst" du halt alles, was du haben möchtest - inklusive Effekte. Wenn du diese Werte über den DMXC-Mixer ausliest und im Position Mapping Device ausschließlich den Parameter Master hinterlegst (und nicht noch zusätzlich Effekte ergänzt), dann gibt es keine Abweichung zwischen den Werten im Parameter-Master und dem Wert für die Funktion "Normal Offset".

Kannst du mir folgen?

Ja, den weg habe ich auch schon gegangen. Das Hilfsgeraet sollte aber alle parameter haben, daher dann das gleiche wie das "original" spaeter, ja? Denn der Dimmer z.b. Hat natuerlich nur dimmer & strobe.
Und dazu eine Cuelist die Dimmer (oder position, etc) and das reale Geraet weitergibt vom Parameter Master ja?

Zu den Masters: Da waere es schon sehr geholfen falls man bei der auswahl (z.b. Input Asssignment) den DisplayName anzeigen kann. Der "Name" ist immer "ParameterMaster XX"; das hilft natuerlich sehr wenig bei 100 oder so.
Fantastisch fuer meine Anwendung waeren natuerlich auch sowas wie "Generic Masters" die mehrere werte zusammenhalten koennen (I.e. 3 double, 1 string + color) nur um zwischen Input assignment connection sets daten auszutauschen. Zur zeit benutze ich Position & Color masters da diese 2 oder 3 werte halten koennen.

Quote

Doch, auch das funktioniert, weil du den Eintrag "Normal offset" nämlich ausschließlich per Parameter Master steuern solltest. Das meinte ich mit

Ich meinte z.B. Position. Falls ich einen Circle effect darauf habe dann kann ich doch nur via DMXCMixer die Position feststellen, auch falls ein PositionMaster angegeben ist. (Weil diese ja staendig aendert).
Das gleiche gilt doch auch fuer "Normal" dann, falls ich z.B. ein Bump effect drauf habe. Der ParameterMaster gibt mir ja dann nicht die "wirkliche" Wert.

Oder reden wir aneinander vorbei?

Von der DMXCMixer beschreibung her von deinem Link ist es doch genau dafuer gedacht um z.b. Position zu bekommen:

Quote

Man benötigt in einem Softdesk oder auf dem Stream Deck die aktuellen Werte für Dimmer oder Farbe für ein bestimmtes Gerät.

Faellt der "Normal" hier unter "Werte für Sonderfunktionen"?

Quote from LightningBrothers

Sobald aber eben so arbeitest, hast du automatisch auch den aktuellen Wert für "Normal Offset" und kannst damit dann weiter rechnen

Hi, ja das ist klar, aber sobald ein effect auf einem Wert ist funktioniert das dann so nicht mehr.
Im fall von "Normal" zur Zeit nicht dramatisch weil keine effekte, aber im fall von Position werde ich daher wohl weiter den DMXC Mixer verwenden (muessen), korrekt?
I.e. ich benoetige den wert egal ob der von einem Softdesk, effekt, oder sonst wo herkommt oder wie es errechnet wurde; um zu jeder zeit zu sehen wo immer ein moving head am boden landet.

Waere toll falls der extra "Normal" wert irgendwann auch via DMXC oder vom Device node verfuegbar waere!

Quote

Programmer: Damit kannst du dir quasi eine eigene Konsole / Pult mittels Softdesk oder externe Steuerelementen wie MIDI-Controller, Stream Deck bauen. Die so gesetzten Werte kannst du dann wieder in Szenen abspeichern.

Okay, also falls ich eine Position von einem Input Assignment forcieren moechte, ich sollte am besten ein PositionMaster nehmen und eine Cuelist mit hoher prioritaet starten wo die Position dann benutzt wird, ja?

Hallo,

ich möchte den Wert nicht steuern, sondern ihn auslesen, um Berechnungen damit durchzuführen (wo oder wer auch immer den gesetzt hat) – genauer gesagt, um das Gerät mit den Koordinaten eines Positionierungssystems abzugleichen.

Wozu dienen die Bedienelemente DMXMixer und Programmer sonst?

Außerdem bereitet mir die Vielzahl an Parameter-/Positions-Mastern Sorgen, insbesondere da diese nur als „Parameter Master XX“ anstatt ihres eigentlichen Namens angezeigt werden. Jeder Master kann nur einen einzigen Wert speichern.

Hallo nochmal. Wie kann ich bei einem Position Mapping-Gerät den Wert für den „Normal Offset“ in der Eingangszuweisung mithilfe bestimmter Komponenten zugänglich machen? Gibt es dafür vielleicht einen McGyver-Knoten oder Ähnliches?

Okay vielen dank fuer die Erklaerung von euch beiden, es macht sinn, denn ich kann keine fehlerhafte Ausfuehrung erkennen.
Ich hatte diese messages nur vorher nicht gesehen, und habe jetzt viele connection sets mit hunderten Elementen (implementation von tag ID tracking und Spielen mit licht).
Wegen der Meldungen werde ich einmal ein leeres Projekt machen und sehen ob ich die Meldungen provozieren kann wie hier beschireben.
Mir sind durch diese intensive Nutzung kleine bugs und usability Sachen mit dem Input Assignment aufgefallen; ich werde dazu vielleicht Tickets bei ruhiger Minute aufmachen.

Vielen Dank fuer eure Geduld!

Guten Abend,

ich möchte gerne wissen, ob ich mir beim Laden eines Projekts Gedanken über die folgenden Kernel-Meldungen machen muss. Falls ja, wie kann ich die Meldung einem Eingangszuweisungsknoten zuordnen? Alles scheint zu funktionieren, aber mir sind diese Meldungen aufgefallen. (Ich habe die Ausgabe gekürzt, da sie zu lang war, um sie hier vollständig wiederzugeben.)

20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.BinarySwitcher could not be loaded: Input
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.Converter.TimerNode could not be loaded: Enabled
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.FormatNode could not be loaded: 1, 0
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.OutputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.InputSelectorNode could not be loaded: Select
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.BinarySwitcher could not be loaded: Input
20:32:32 INFO GrpcTools - Type LumosLIB.Tools.ParameterValueContainer uses BinaryFormatter for GrpcSerialization.
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.InputSelectorNode could not be loaded: Select
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.InputSelectorNode could not be loaded: Select
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name
20:32:32 WARN ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.InputNode could not be loaded: Name

20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.ExpressionNode could not be loaded: m6, m5, m4, m3, m2, m1
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.ExpressionNode could not be loaded: m6, m5, m4, m3, m2, m1
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.ExpressionNode could not be loaded: m6, m5, m4, m3, m2, m1
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.Converter.TimerNode could not be loaded: Time2, Time1
20:32:32 INFO  GrpcTools - Type LumosLIB.Tools.ParameterValueContainer uses BinaryFormatter for GrpcSerialization.
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.Converter.TimerNode could not be loaded: Time2, Time1
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.Converter.TimerNode could not be loaded: Time2, Time1
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.LogicNode could not be loaded: 0
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.MathNode could not be loaded: 0
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.LogicNode could not be loaded: 5, 4, 3, 2, 1, 0
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.LTPNode could not be loaded: 5, 4, 3, 2
20:32:32 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Input.v2.Worker.Split could not be loaded: Input
20:32:32 INFO LoadedProjectVersion - Loaded 18 Items in Connection sets
20:32:32 INFO LoadedProjectVersion - Loaded 3 Items in Banks

Hello,

I have tracked the problem down to a fixture issue. The dimmer is 0-255, but if reducing to below 5 (especially quickly, like during a 0ms release), the dimmer turns on briefly regardless of shutter!

I have fixed it in the DDF:

    <!-- Dimmer -->
    <!-- It is 0-255, but between 0-5 the light will flash on briedly even with the shutter closed -->
    <dimmer dmxchannel="4" defaultvalue="0">
      <range type="linear" mindmx="5" maxdmx="255" minval="0" maxval="100"/>
    </dimmer>

Good morning again folks,

I have one more question regarding why a light turns on during cuelist release.

I have a single cuelist in the project, so no background list or anything.

The cuelist even has a final cue with "shutter off".

However, when the cuelist releases, the light turns on briefly, resets all settings, and then turns off again. I want this to happen with the shutter closed so there are no unsightly effects.

I have even tried a second "end" cue that sets shutter off and then shutter and dimmer off. This causes the light to turn on between the last two cues and then fade back to 0.

This cannot possibly be standard behavior; what am I doing wrong??

Guten Morgen zusammen,

ich habe noch eine Frage: Warum geht beim Loslassen einer Cuelist eine Lampe an?

Ich habe nur eine Cuelist im Projekt, also keine Hintergrundliste oder Ähnliches.

Die Cuelist hat sogar einen letzten Cue mit „Shutter aus“.

Wenn die Cuelist jedoch losgelassen wird, geht die Lampe kurz an, setzt alle Einstellungen zurück und geht dann wieder aus. Ich möchte, dass dies bei geschlossenem Verschluss passiert, damit keine unschönen Effekte entstehen.

Ich habe sogar einen zweiten „End“-Cue ausprobiert, der „Shutter aus“ und anschließend „Shutter und Dimmer aus“ auslöst. Dadurch geht die Lampe zwischen den letzten beiden Cues an und dimmt dann wieder auf 0.

Das kann unmöglich das normale Verhalten sein; was mache ich falsch?

Thank you both for your suggestions. SInce the cuelist ends itself after "a while", the Play connection makes most sense in that case.

LightningBrothers Did you mean the following as in the attachement below? That seems to work and do the same as dragging the node onto the connection set. Why is one allowed but not the other!?

Hello again DMXcontrol experts.

I have a question about a cyclic input assignment.

In the below input assignment (only the orange part is important I think), I want to start a cuelist from a softdesk button only if the cuelist is not already running.
I cannot, however, make the red connection; the kernel complains about a cyclic input error. I am also unable to add the cuelist to the graph twice, or even add only the relevant subelements (Input GO, output STATE).
Surely there must be a way around this problem; please advise!

Hallo DMXcontrol-Experten,

ich habe eine Frage zu einer zyklischen Eingangszuweisung.

In der untenstehenden Eingangszuweisung (ich denke, nur der orangefarbene Teil ist relevant) möchte ich eine Cuelist über einen Softdesk-Button nur dann starten, wenn die Cuelist noch nicht läuft. Ich kann jedoch die rote Verbindung nicht herstellen; der Kernel meldet einen Fehler wegen einer zyklischen Eingangszuweisung. Ich kann die Cuelist auch nicht zweimal zum Diagramm hinzufügen oder nur die relevanten Unterelemente (Eingang GO, Ausgang STATE). Es muss doch eine Lösung für dieses Problem geben; bitte um Hilfe!

Quote

09:14:43 ERROR Input_gService -
System.InvalidOperationException: Adding this edges would create a cyclic graph. This is not allowed.
at org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdges(IEnumerable`1 edges, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:line 321
at org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:line 308
at org.dmxc.lumos.Kernel.Net.gService.Input_gService.AddEdge(IGraph g, GraphNodePortID from, GraphNodePortID to) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Input_gService.cs:line 862

Hello folks,

(German down below)

I am playing with the new position mapping in the 3.3.2. It is a fantastic feature and will be extremely useful for me. Thank you!
I have a room layout as shown below.

- The moving heads are symmetrically on both sides of the room.
- They have been calibrated in a position mapping to corners 1-4 to overlap (in both lower as well as upper reference planes)
- Then set to the center position in the programmer and turned
- In that position, they shine into the respective spots, but do not overlap at all (especially side to side, there are meters in between the two rows.
- In the corner positions they overlap well.

So my question is what am I doing wrong that they are not overlapping better in the middle positions?
I can get the two rows to overlap a bit better by adjusting the "normal" value, but that of course throws off the corner mappings.
I have also tried using cartesian or polar coordinates in the mapping but cartesian does "weird things" compared to polar.
Understandably the side-to-side offset *could* be alignment error, but it is about half a meter off or more.
There is no way I got the front-to-back alignment between both rows of heads far enough off to cause several meters of distance.

So again, what am I misunderstanding and how could I fix that?

Thanks in advance!

Hallo zusammen,

ich teste gerade die neue Positionszuordnung in Version 3.3.2. Sie ist fantastisch und wird mir sehr nützlich sein. Vielen Dank!
Mein Raumlayout sieht wie folgt aus:

– Die Moving Heads sind symmetrisch auf beiden Seiten des Raums angeordnet.

- Die Scheinwerfer wurden so kalibriert, dass sie sich in den Ecken 1-4 überlappen (sowohl in der unteren als auch in der oberen Referenzebene).

- Anschließend wurden sie im Programmer in die Mittelposition gebracht und gedreht.

- In dieser Position leuchten sie zwar in die jeweiligen Bereiche, überlappen sich aber überhaupt nicht (insbesondere seitlich; zwischen den beiden Reihen besteht ein Abstand von mehreren Metern).

- In den Eckpositionen überlappen sie sich gut.

Meine Frage ist also: Was mache ich falsch, dass sie sich in den mittleren Positionen nicht besser überlappen? Ich kann die Überlappung der beiden Reihen etwas verbessern, indem ich den Wert für „Normal“ anpasse, aber das verändert natürlich die Eckzuordnungen. Ich habe auch versucht, kartesische und polare Koordinaten für die Zuordnung zu verwenden, aber kartesische Koordinaten verhalten sich im Vergleich zu polaren merkwürdig. Verständlicherweise *könnte* der seitliche Versatz auf einen Ausrichtungsfehler zurückzuführen sein, aber er beträgt mindestens einen halben Meter. Ich kann unmöglich die Ausrichtung der beiden Scheinwerferreihen so weit verstellt haben, dass ein Abstand von mehreren Metern entsteht.

Also nochmal: Was mache ich falsch? Ich habe ein Missverständnis festgestellt und wie kann ich es beheben?

Vielen Dank im Voraus!

Okay, I trust it will be made very good and obviously cannot understand the code without having looked at it.
I know the feeling when you are the author of a code and fail multiple attempts at modifying something :}

But I think you already figured out the actual problem - and solution.
- A position mapping (as a device) logically should only represent a single device: allowing a single mapping represent multiple devices will likely cause other unintended side effects in addition to only getting one fanning value
- Your workaround of one mapping per device and then grouping the mappings is actually how it should be (imho).

The best (abstract) solution might be:
- Allow only a single device in a mapping (1 to 1)
- Use device groups (manually created as with normal devices) to fan and do other things with position mappings
- Modify the calibration dialog to allow showing multiple mappings at the same time if desired (as it shows all devices in a single mapping now) : This would allow calibrating them all at once, as it is now

This would retain the proper structure (separating devices and groups) and thereby not break fanning or other logic, allow the convenience of calibrating multiple mappings/fixtures at once, and still allow multiple different mappings to be used on a single device.

Hi,

It seems like the device group or "shadow mapping" could work as the workaround does the exact same thing. A device group would also allow for multiple position mappings because I could still create multiple groups with the same devices, and the group could have the "Patching Field", no? Maybe there is something I am missing internally as I don't understand or am familiar with the core architecture.

Regarding the merging, I meant only in the stage view/programmer.

- Create 3 devices 1,2,3

- Create 2 Device groups (Devs 1,2 and Devs 2,3)

- Create a fanned position in Group 1, then Group2. Switch back and forth and only one groups has a superposition of all.

I have attached a sample project and a steps recorder PDF. I somehow cannot record a video in the VM...

Thank you for the cursory overview of the underlying issue.
What is the purpose of being able to apply a fanning to a single device? Are there any useful scenarios or just a byproduct of the logic?

I suspect there was a very good technical reason for this, but:
Why is the position mapping implemented as a device rather than a device group?
Maybe when creating a position mapping it should create an automatic "shadow group" that could be used to apply the fanning? This should be analog to the workaround of multiple mappings inside a single group.

I am not super familiar with DMXcontrol or DMX in general (new to this and only as a little side thing), but it seems to be possible to apply different fannings to device groups containing the same devices (like overlapping fannings).
These fannings are then somehow merged into the last edited group, is that correct?
In that case such a shadow group might work (as multi-group spanning fannings are already handled in "some way"), but I am not 100% sure how these overlapping/conflicting fannings are merged.

Does that make sense or it is too obscure to understand what I'm trying to say?

One more follow up question as I was playing with that:

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?

Apologies for the late reply,

I finally had time to look give the position mapping in 3.3.2 a cursory look and must say it is already fantastic.
The implementation via the mapping is so elegant because it allows to use multiple or no mappings!
This is already a great step; I hope in the next version the position fanning will also work.

Thank you very much; this wait was well worth it!