DMX In/Visualisierung - Problem

DJTJ · January 24, 2017 at 9:49 AM

Hallo Community,
Ich versuche mit DMXC3 in Verbindung mit Magic 3D mein Licht zu visualisieren, indem ich ein Interface mit DMX-In verwende. Allerdings werden die Werte nicht übergeben, obwohl ich sie im Input Assignment auf die Kanäle ziehe. Z.B. bei Pan/Tilt wird nur Pan übergeben (auch in 16 bit), aber der Tilt-Wert nicht. Um dies zu umgehen arbeite ich momentan damit, im DDF-Editor die DMX-Belegung zu löschen und dafür "Raw" Kanäle anzulegen. Dies funktioniert auch nicht 100%, aber zumindest wird die Intensität und Pan/Tilt richtig übergeben.

Ich arbeite mit einem Surface Book auf dem Serato DJ läuft. Mit SoundSwitch gebe ich ein DMX-Signal an ein Digital Enlightment Interface an einem Stand-PC weiter. Die Werte kommen laut dem DMX-In Fenster richtig an, werden aber nicht ausgegeben, bzw visualisiert.
Wenn ich das DMX-Signal einfach durchschleife, wird es nicht visualisiert, bzw kommen nicht bei Magic 3D an.
Daher meine Frage: Warum kommen die DMX-Werte nicht durch?

Vielen Dank für euren Support

***JPK*** · January 24, 2017 at 11:10 AM

Hallo,
kannst du mal bitte folgendes probieren: Setze auf alle entsprechenden Kanäle Dimmer-Geräte (parallel zu deinen bisherigen Geräten) und nutze diese als Output im Input Assignment (versuchs vielleicht erst einmal an wenigen Geräten). Ich dachte, wir hätten da mal Probleme gehabt, das Durchzuschleifen. In der 3.1 kann man auch ein einfaches 1:1-Routing durchführen. Das geht mit der 3.0.2 noch nicht.
Viele Grüße
JP

DJTJ · January 24, 2017 at 4:43 PM

Danke für die schnelle Antwort,
Die Kanäle mit Dimmer-Geräten zu ersetzen hat nichts gebracht.
Bzw. mir ist aufgefallen das nur die Werte durchgegeben werden, die sich ändern. Ein Kanal wie "Shutter" bekommt allerdings einen konstanten Wert

Grüße TJ

**LightningBrothers** · January 24, 2017 at 5:15 PM

Hallo!

Das dürfte an den DDFs liegen und wie DMXControl damit umgeht. Wenn im DDF beim Shutter nur zwei Zustände definiert sind (sprich auf und zu), sendet DMXControl auch nur die zugehörigen Werte bei einer Zustandsänderung. Dabei spielt es keine Rolle, dass du den Fader auf dem DMX-Pult langsam hochziehst. Der Fader ist nämlich mit einer Funktion eines Gerätes (hier dem Shutter) verknüpft und nicht mit einem DMX-Kanal. Dies mal so als Hintergrund zur Arbeitsweise von DMXControl 3.

Hast du bei deinem Test alle Geräte rausgeschmissen und nur mit Dimmern gearbeitet? Wenn nein, könnte das nicht-funktionieren daraus resultieren, dass es bei der Ausgabe zu Überschneidungen kam.

Ich hoffe, ich konnte dir ein wenig weiter helfen. Viele Grüße, Stefan von den LightningBrothers.

DJTJ · January 24, 2017 at 6:31 PM

Hallo LightningBrothers,
Vielen Dank für die Antwort.
Leider hat dein Rat nicht funktioniert. Ich habe eine neue Show angelegt und nur Dimmer-Fixtures hinzugefügt. Die Werte wurden trotzdem nicht übergeben.

Wenn ich DMX Control starte und dann erst das DMX-In Kabel reinstecke, werden alle Werte übergeben, da DMX-In erst auf "0" steht und dieser Wert dann verändert wird.

Grüße TJ

***JPK*** · January 24, 2017 at 11:21 PM

Dann öffne bitte ein Ticket im Bugtracker und beschreibe dort noch einmal genau die Problematik. Dann sehen das die Entwickler direkt und können das gut nachvollziehen.
Viele Grüße
JP

**Soon5** · January 25, 2017 at 9:25 AM

Hallo,

Es wird keine DMX-IN Visualisierung geben.

Hintergrund ist folgender:

1. Das StageView ist kein Visualizer, sondern nur ein fancy Steuergerät.
2. Es existiert keine Verbindung zwischen DMX-In und den Werten. Hintergrund ist, dass die ganze Visualisierung und DMXControl 3 auf Abstrakten Eigenschaften (Farbe, Position,...) basieren. Diese Eigenschaften werden in der HAL auf DMX Werte umgerechnet, aber das geht nicht Rückwerts, weil es Mathematisch gesehen eine Relation und keine Funktion ist.

Gruß

Arne

***Stefan Krupop*** · January 25, 2017 at 9:28 AM

@Arne:
Ich glaube aber, hier geht es um das Durchreichen der DMX-Werte an Magic3D, um sie dort zu visualisieren - nicht darum, aus dem DMX-Input wieder Device-Properties zu machen...

Stefan

DJTJ · January 25, 2017 at 11:43 AM

Danke für euer Feedback!
Stefan liegt genau richtig, es ging mir eigentlich nur darum mit DMXC3 zu visualisieren, also DMX-Werte nach Magic 3D durchzuschleifen. Mir fiel keine bessere (kostenlose) Visualisierungsmöglichkeit ein. Einzig die begrenzten FPS von ~22 sind etwas schade
Da Soundswitch allerdings ein paar Funktionen fehlen (Gobos, Zoom etc.) möchte ich das mit DMXC3 nachrüsten, was aber kein Problem darstellt. Ich warte erstmal die 3.1 Version ab, vielleicht funktioniert es ja einwandfrei mit dem neuen Input-Assignment.

Grüße TJ

**Soon5** · January 25, 2017 at 7:59 PM

Ah...

Mit der 3.1 wird es ein DMX-IN nach DMX-OUT Mapping geben.

Damit sollte sowas machbar sein.

Gruß

Arne

DJTJ · April 4, 2017 at 8:27 PM

Hallo Community,
Da das Update (3.1) jetzt draußen ist, möchte ich meine Problematik nachbessern, bzw noch einmal schildern:

Das Visualisieren mit EasyView ist mit dem DMX In & Out Mapping kein Problem mehr, dies wurde also behoben
Allerdings ist es nicht möglich, einen einkommenden DMX-In Wert zu überschreiben. Ich weiß, der Anwendungszweck für diese Situation ist nicht gegeben. Allerdings frage ich mich, warum es so ist, dass ein Wert von DMXControl ausgegeben wird, wenn er höher als der Wert des DMX-In Signals ist. Es wird also immer der höhere DMX Wert ausgegeben - klingt auch irgendwie logisch, ist aber trotzdem schade, das diese nicht einfach überschrieben werden können. (Um Missverständnisse vorzubeugen: Ich nutze das Digital Enlightment USB DMX Interface mit einem Surface Book 256GB Nvidia940m, und habe alle Interface Modi ausprobiert)

Grüße TJ

**LightningBrothers** · April 4, 2017 at 9:07 PM

Hallo!

Ich habe das DMX-In-DMX-Out-Mapping zwar noch nicht ausprobiert, ich stand aber am letzten Wochenende vor einem ähnlichen Problem. DMXControl sendet standardmäßig unter anderem für Positionen von MovingLights und für Farben für LED-Scheinwerfer anfangs immer Werte, wenn du nur dein Projekt geöffnet, aber zum Beispiel in der StageView noch nichts gemacht hast. Wo Werte gesendet werden, kannst du gut in der Channel Overview sehen.

Diese Werte werden im Interface (und vermutlich auch im Softpatch) dann per HTP gemischt werden. Das bedeutet, dass immer der höchste Wert durchgereicht wird.

Möchtest du also, dass alle Werte durchgereicht werden, musst du dir zum Beispiel für deine LED-Scheinwerfer einen Effekt (Cuelist) mit einem Cue anlegen, wo du die Farbe schwarz drin abspeicherst. Ähnlich verfährst du dann mit allen anderen Geräten.

Ich hoffe, du konntest mir soweit folgen. Viele Grüße, Stefan von den LightningBrothers.

DJTJ · April 5, 2017 at 7:40 AM

Hallo LightningBrothers,
Danke für deine schnelle Antwort

Ich kann dir allerdings nicht folgen.

Ich erkläre eben die Situation:

Ich nutze ein anderes Lichtprogramm (SoundSwitch), welches seit dem letzten Update auch Zoom, Gobos, Prisma etc. beherrscht. Allerdings ist dies etwas umständlich, speziell wenn ich MHs auf eine Spiegelkugel scheinen lassen will.

Immer wenn der Wert von Soundswitch höher ist als der Wert der die MHs auf die Spiegelkugel leuchten läst, bewegen sie sich wieder.
Ich wüsste nicht, das es helfen sollte eine Cuelist zu erstellen mit schwarzen RGB Fixtures.
Was helfen würde, wenn man das DMX-In Signal von HTP zu LTP umstellen könnte.

Grüße TJ

**Soon5** · April 5, 2017 at 8:11 AM

Hm.

Spannend, ich glaube den Fall, das jemand Geräte + DMX In Mapping auf den gleichen Kanal legt habe ich gar nicht gesondert in der Software betrachtet.

Das da ein HTP Mapping entsteht ist glaube ich eher Zufall

Muss ich mal probieren, auch wie kompliziert das wäre da eine HTP / LTP Mischung ein zu bauen.

Generell sehe ich da 4 Mögliche Mappings:

* LTP
* HTP
* IN-Prio (bedeutet wenn IN > 0 wird IN verwendet, ansonsten DMXC)
* DMXC-Prio (bedeutet wenn DMXC > 0 wird DMXC verwendet ansonsten IN)

Gruß

Arne

***JPK*** · April 5, 2017 at 8:31 AM

Hallo,
da möchte ich mal .rhavin zitieren

Quote from .rhavin

Verschiedene Möglichkeiten, konkurrierende Werte aufzulösen: HighestTakesPrecedence, LowestTakesPrecedence, FirstTakesPrecedence, LastTakesPrecedence, AverageOfActives

Das sollte pro Kanal einstellbar sein (am besten einen Kanalbereich auf einmal wechselbar)
Viele Grüße
JP

**Soon5** · April 5, 2017 at 9:13 AM

Also, hier müssen wir 2 Dinge unterscheiden.

Das was du schreibst würde ich auf Eigenschaftenebene Erledigen, also pro Eigenschaft einstellbar.

Ein Ähnliches Mapping brauchen wir aber für DMX-In und DMXC auf DMX Ebene.

Letzteres ist einfacher zu realisieren, deshalb fange ich damit an

Was ich nicht verstehe, was ist das zu erwartende Verhalten von "FirstTakesPrecedence"? Also wie funktioniert das?

**LightningBrothers** · April 5, 2017 at 9:50 AM

Kurze Zwischenfrage: ist geplant, den Punkt DMX-In-DMX-Out (sprich den Softpatch) ins neue Input-Layer-System zu integrieren?

***JPK*** · April 5, 2017 at 10:07 AM

Quote from Soon5

Was ich nicht verstehe, was ist das zu erwartende Verhalten von "FirstTakesPrecedence"? Also wie funktioniert das?

Oh stimmt, hatte das nicht gesehen. Joa, da muss dann rhavin sagen, was er damit meint. Aber die "IN-Prio" und "DMXC-Prio" würde ich auf jeden Fall auch nehmen

Edit: Ist zwar ein spontanes Hingespinst, aber vielleicht ganz cool: Dimmerkurven für den Übergang bei LTP. Denn diese Übergänge haben immer das Problem, dass sie sprunghaft sind. Das ist z.B. beim Theater doof, weil man so nicht einfach einzelne zu helle oder zu dunkle Scheinwerfer per Pult nachregeln kann. Mit einem einstellbaren Übergang wäre das aber möglich und ein echt cooles Feature.
Viele Grüße
JP

**LightningBrothers** · April 5, 2017 at 10:56 AM

Deine Idee, @JPK, spricht umso mehr dafür, das Thema über das Input-Layer-System laufen zu lassen. Vielleicht kann man hier ein oder mehre entsprechende Templates vorbereiten:

DMX-In direkt nach DMX-Out
DMX-In über "Dimmerkurve" nach DMX-Out

Hätte ingesamt den Charme, dass man nicht an zwei Stellen gucken muss, wie es aktuell noch der Fall ist und man hat ingsamt eine konsitentere Bedienung.

Viele Grüße, Stefan von den LightningBrothers.

**Soon5** · April 5, 2017 at 12:35 PM

Die Idee über den Input Layer zu gehen finde ich aus folgendem Grund nicht gut. Der Input Layer ist primär für Niederfrequente Änderungen gedacht, also vor allem User Änderungen.

Das DMX-In > Out Mapping ist primär dafür gedacht verschiedene DMX Steuerungen zu verbinden. Hier werden potentiell sehr viele Kanäle auf einmal und sehr schnell geändert. Hier nochmal jeden Kanal durch DMXControl nachbearbeiten zu lassen ist nicht besonders effizient.

Die Anfrage war auch primär dahingegen Kontrolle zu haben, wie die Konflikte beim Mapping aufgelöst werden können.

DMX In/Visualisierung - Problem

JPK April 9, 2018 at 8:31 PM

Tags

JPK April 9, 2018 at 8:31 PM

Tags

JPK April 9, 2018 at 8:31 PM