Bugtracker DMXControl 3

1. es wäre toll, wenn es ein State-Ausgang geben würde.(aktiv?)

2.In den Einstellungen des cue-Nodes kann man zuerst die Cuelist und dann die Cue auswählen. Es sind dann aber ALLE Cues aus dem Projekt vorhanden. Es wäre hier angebracht, nur die Cues anzuzeigen, die in der ausgewählten Cuelist vorhanden sind.

Da die Funktionen zum Klonen und Verschieben eines Connectionset (CS) aktuell nur über das Kontextmenü eines gewählten CS (Bild 1) erreichbar und somit gefühlt recht versteckt sind, würde ich es begrüßen, wenn diese im Menü zum Eintrag Connectionset (Bild 2) ergänzt werden. Der Eintrag zum Löschen eines CS ist ja dort bereits vorhanden, allerdings noch nicht funktionsfähig.

Ich stehe vor dem Problem, dass ich eine etwas aufwendigere Logikfunktion in verschiedenen Connectionsets benötige. Das Klonen funktioniert, ist aber eigentlich unnötig und sollte ich da mal Änderungen dran machen, muss ich alle 16 Sets immer wieder neu anfassen. Hier wäre ein “Interner Speicher” extrem nützlich.

Ich stelle mir ein Node vor, den ich Parametrieren kann mit z.b. “Merker 1” oder “DefaultBackroundColor” oder so und da schiebe ich in den Eingang einen RGB Wert rein und kann in einem 2. Connectionset diesen Wert mithilfe des Nodes verwenden.

wäre schön, wenn man Nodes mit ihren eingestellten Parametern kopieren könnte…

Von Einzelnen Inputs Outputs umbauen in Nodes wie alles andere auch

Vielleicht mache ich das auch falsch,

bei mir werden in der Sekunde an die 100 Einträge in die Konsole ausgegeben: in:63489
dazwischen manchmal ein anderer wenn ich eine Taste drücke.
Ich konnte die learn funktion jetzt so austricksen das ich die “Learn” Taste/Button so lange mit meiner
Klaviertaste gedrückt habe bis sich eine Änderung in Data 1 gezeigt hat.
Ansonsten scheint Learn einfach die Nulldaten interpretiert zu haben.

Vor allem wenn DMXC mit mehreren Monitoren genutzt wird, wäre es wünschenswert, wen sich vom Dockingcontainer gelöste “Floating Windows” Maximieren lassen.
Wie dies mit der DockpanelSuite umzusetzen ist, ist unter Doku maximizable floatwindow beschrieben.
Viele Grüße

Da bei einem schmalen Cuelist-Editor-Fenster vor allem die Slider für Intensity, Speed und Face Factor schwierig zu bedienen sind, soll die gesamte Menüleiste in mehrere Gruppen aufgeteilt werden, sodass diese frei und auch in mehreren Zeilen frei positioniert werden können. Mögliche Gruppen können sein:

1. Go, Pause, Stop
2. Add Cue, Edit, Up, Down,
3. Mode, Options, Autoscroll
4. Intensity, Time (Fade Factor), Speed

Als zum Ticket  FS#3167  ergänzende Funktion soll es möglich sein, bei einem beliebigen DMX-Ausgabe-Plugin nachträglich die Ausgangs- und Eingangs-Universen neu zu patchen, ohne dabei das betreffende und bereits konfigurierte DMX-Ausgabe-Plugin entfernen zu müssen. Angedacht ist hier ein Fenster, in dem man angeben kann, ab welchen DMX-Universium bzw. DMX-Adresse die verfügbaren Ports entsprechend fortlaufend belegt werden sollen. Sprich soll das Art-Net-Ausgabeplugin fortlaufend ab DMX-Universum 3 Werte ausgeben oder erst ab dem 5. DMX-Universum.

Toll wäre, wenn man “allgemeine” Cues (oder Presets) schreiben könnte. Die dort gespeicherten Eigenschaften werden dann auf die Geräte angewendet, die gerade in der StageView markiert sind.

Umsetzbar wäre das z.B. mit einer Checkbox im “Save Cue”-Dialog (da, wo man die gespeicherten Eigenschaften auswählen kann). Wird diese Checkbox markiert, werden nur die Eigenschaften, nicht die Devices (bzw. Device Groups) gespeichert. Wenn die Cue dann aufgerufen wird, werden diese Eigenschaften auf die zur Zeit ausgewählten Geräte angewandt.

In Verbindung mit den Softdesks könnte man so sehr kreative Funktionen basteln.

In den Einstellungen eines Gerätes in DMXC3 können nur alternative Dimmerkurven gewählt werden, wenn das Gerät einen einzelnen Dimmerkanal hat. Hat es allerdings nur Farbkanäle (R, G, B), fehlt der ganze “Dimmer”-Aufzählungspunkt, obwohl Dimmerkurven ja auch auf Farbkanäle angewendet werden können sollten.

Ich wünsche mir also alternative Dimmerkurven auch ohne Dimmerkanal. Die können dann auch gerne alle Farbkanäle gleichzeitig beeinflussen.

Aus Gründen der Konsequenz könnte man Preheat und Limit (die beiden anderen Punkte unter “Dimmer”) auch gleich übernehmen, braucht zwar kaum ein LED-PAR, aber ist trotzdem schick zu haben.

Wenn ich z.b. mehrere Buttons markiert habe, die unterschiedlich groß sind, kann ich im Editierbereich die Breite/Höhe nicht mehr eingeben. Dies wäre aber sinnvoll.
Dies gilt ebenso für unterschiedliche Farben usw..

Füge ich das Art-Net-Ausgabeplugin neu hinzu, werden die Send- und Recieve-Universen aus meiner Sicht ungünstig adressiert. Im konkreten sieht das wie folgt aus:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 4 - 7

Device 2

• Send U5 - U7: Universes 8 - 11
• Revice U5 - U7: Universes 12 - 15

Möchte ich nun ein 8-Port Art-Net-Node ansprechen, muss ich hier im Device 2 mindestens die Universen für Send neu sortieren. Ich könnte zwar mein Art-Net-Node auch irgendwie umkonfigurieren, aber persönlich finde ich diese Stückelung innerhalb eines Subnet nicht geschickt. Mein erster Vorschlag wäre folgende Standard-Konfiguration:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 8 - 11

Device 2

• Send U5 - U7: Universes 4 - 7
• Revice U5 - U7: Universes 12 - 15

Wenn ich den graphen einer Verbindung geöffnet habe, sollte der Name der Verbindung irgendwo angezeigt werden.

Wenn ich in einem Blade als Maximalen trust 0.8 (80%) angebe, wird dies auch für die DMX-Ausgabe zwar beachtet, aber die InputControls und das StageView-Icon zeigen immer noch 100%

    <blades>
      <bladeindex dmxchannel="37">
        <range range="120" mindmx="0" maxdmx="255" />
      </bladeindex>      
      <bladetop dmxchannel="38">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladetop>
      <bladetopangle dmxchannel="39" pointofrotation="center">
        <range range="50" mindmx="0" maxdmx="255" />
      </bladetopangle>
      <bladeleft dmxchannel="40">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladeleft>
      <bladeleftangle dmxchannel="41" pointofrotation="center" >
        <range range="50" mindmx="0" maxdmx="255" />
      </bladeleftangle>
      <bladebottom dmxchannel="42">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladebottom>
      <bladebottomangle dmxchannel="43" pointofrotation="center">
        <range range="50" mindmx="0" maxdmx="255" />
      </bladebottomangle>
      <bladeright dmxchannel="44">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladeright>
      <bladerightangle dmxchannel="45" pointofrotation="center" >
        <range range="50" mindmx="0" maxdmx="255" />
      </bladerightangle>
    </blades>

s.o.

Wenn der Project Explorer horizontal gescrollt wird, verschwinden die Symbole vor den Einträgen. Wenn man mit der Maus einmal über die Symbole fährt, erscheinen sie wieder.

wenn ich im Inputassignment nodes verschieben möchte muss ich diese vorher einmal mit der Maus anklicken (auswählen) bevor ich sie per drag&drop verschieben kann.

ist es evtl. möglich die nodes schon mit dem ersten Mausklick (gedrückt halten) zu markieren?

Der Powermeter Name verdeckt das Powermeter.

wird das noch geändert?

Das Nodle-Plugin zeigt im Config-Dialog immer die die Default-Timings.
Es sollten aber die aktuellen Einstellungen des Nodle angezeigt werden.

Die nodle.dll gibt das her:

DLL_EXPORT unsigned long DLL_STD GetInterfaceConfig (TSERIAL Serial, unsigned char *pControl, unsigned short *pBreaktime, unsigned short *pMarktime, unsigned short *pInterbytetime, unsigned short *pInterframetime, unsigned short *pChannelcount, unsigned short *pStartbyte);

wenn das Fenster der Powermeter verkleiner und wieder vergrössert wird, spinnt die darstellung der Meter.
erst ein minimieren und maximieren hilft.

wenn ich ein Gerät in eine Elektrizität Gruppe hinzufüge wird mir dieses Gerät nicht automatisch im Baum Angezeigt.
Keine Rückmeldung ob Gerät hinzugefügt wurde, erst das Aktuallisieren der Ansicht (F5 oder ähnliches) lässt das Gerät erscheinen.

Bei “Buttons” wird immer nur die Funktion zu Verfügung gestellt die nötig ist. ( Eingang oder Ausgang)
Bei “Programmer” werden immer alle Funktionen (Eingang und Ausgang) Verfügbar gemacht.

Will man also einen Button beleuchten muss dieser 2 mal hinzugefügt werden.

Es sollte egal ob ich den Node ausm Eingang oder Ausgang auswähle immer alle Funktionen (Eingänge & Ausgänge) zur Verfügung stehen.

Analog zu den Cuelists sollte auch bei Softdesks durch Copy & Paste eine Kopie des zuvor ausgewählten Softdesks angelegt werden.

Für Theateraufführungen oder anderweitige Programme mit fester Abfolge wäre es sehr praktisch zu sehen was im nächsten Cue passiert. Dies könnte entweder grafisch oder in Form einer Tabelle wie z.B. im Programmer dargestellt werden. Welche Form der Darstellung gewählt wird oder beide oder gar keine Implementierung des Features, wäre noch zu entscheiden.

s. Überschrift
passend zur Disskusion im Forum:
https://forum.dmxcontrol-projects.org/index.php?thread/14319-konzepterl%C3%A4uterung-und-verst%C3%A4ndnisfragen-zum-neuen-input-assignment/&postID=121109#post121109

Aus Nutzersicht wäre es super, “virtuelle” Eingänge (z.B. Go / Stop  FS#3321 ) zu haben, die im Hintergrund einen Graphen generieren. Dadurch könnten viele Standard Fälle abgedeckt werden, ohne das Input Assignment zu verschandeln.

Für die Kommunikation mit Energiezählern wird standardmäßig die Kommunikation über Modbus RTU / TCP hergestellt. Z.b. Siemens Sentron
Die Register für die einzelnen Adressen sind allerdings nicht bei jedem Gerät identisch. Somit muss für jeden Datenpunkt der Datentyp und die Registeradresse eingegeben werden können.

Die Reihenfolge der Einträge

• Name
• Objekt-Nummer (Group Number, Executor Number)
• Image (sofern vorhanden)

fällt in den Properties für

• Cuelist (siehe hier auch Ticket  FS#3628 )
• Device Group
• Executor
• Executor Page

unterschiedlich aus. Hier wäre der Wunsch, die Reihenfolge dieser Einträge aus Gründen der Konsistenz zu vereinheitlichen und sie ggf. einer eigenen Untergruppe mit dem Titel “Information” oder “Name” zuzuordnen.

Zur besseren Übersichtlichkeit und möglicherweise auch schnelleren Änderungsmöglichkeit sollten folgende Objekt-Nummern im Project Explorer als zusätzliche Spalte anzeigt werden:

• Cuelist Group Number
• Executor Number
• Executor Page Number

Die Einträge im Fenster Cuelist Properties sind in Bereich mit den “allgemeinen” Kernel Properties aktuell recht unstrukturiert. Insbesondere sind Einstellungen rund um das Timing der Cuelist bunt verteilt, wie im beigefügten Screenshot zu sehen ist.

Im Zusammenhang mit dem Ticket  FS#3628  sollten diese Einträge nach Möglichkeit neu strukturiert und sinnvoll gegliedert werden, wie es bereits für das GoNext-Verhalten, die Ansichtseinstellungen der Spalten und die Defaults gemacht wurde.

Ich habe die Cuelists A, B und C. Die Cuelists A und C sind bereits einer Cuelist Group zugeordnet. Nun lege ich noch Cuelist D an. Alle Cuelists A bis D möchte im Anschluss nun der gleichen Cuelist Group zuordnen, wähle dazu alle aus und ziehe die Cuelists auf die Cuelist Group. Nun sperrt mir die GUI das Ablegen der Auswahl, da ja bereit eine Cuelist (hier A und C) innerhalb der Auswahl bereits im Ziel (also der Cuelist Group) enthalten ist.

Das “Sperren” ist in dem Sinne unschön (weswegen ich das Ticket als Fehler gekennzeichnet habe) und vom Workflow her ineffektiv ist, dass ich immer vorher erst schauen muss, was ist im “Zielordner” (meist Cuelist Group, Device Group, Stage View und Eletricity Management) bereits enthalten. Im zweiten Schritt muss ich über eine Mehrfachauswahl die Cuelists o. ä. anwählen, die ich dem Zielordner hinzufügen möchte. Hierbei laufe ich aber Gefahr, entweder Cuelists zu vergessen oder ich erwische doch nochmal eine, die bereits in der Cuelist Group enthalten ist, worauf ich die Auswahl nochmal ändern oder möglichst alle Cuelists einzeln der Cuelist Group zuordnen muss.

An dieser Stelle wünsche ich mir einen Workflow, bei dem diese “Vorabkontrolle” entfällt, ob eine Cuelist in einer Cuelist Group enthalten ist oder nicht.

Auch wenn das Verhalten bereits in der 3.1 schon so war, habe ich das Ticket mal mit zur 3.2 gepackt, weil es hier nun nochmal explizit aufgefallen ist.

Ausgangssituation: Es gibt mehrere Moving Heads, die zeitversetzt eine Welle (Sinus auf Tilt) durchlaufen sollen. Hierzu gibt es drei Cues, einen mit dem Sinus auf dem Tilt, die One Shot-Cue und eine statische Cue, um die Welle zu beenden. Da es ein gefanntes Delay für alle drei Cues eingetragen ist, bin ich davon ausgegangen, dass nun auch alle Heads die Welle zeitversetzt durchlaufen und jeder mit seinem entsprechenden Delay wieder zum stehen kommt. Das ist aber nicht der Fall. Nachdem der erste Moving Head die Welle durchlaufen hat, beenden alle die Welle irgendwo mitten drin und gehen gleichzeitig direkt auf die statische Stimmung.

Folgender Aufbau einer Cuelist:
- Cue1 Follow, Triggervalue 0ms Fadetime 2s
- Cue2 Follow, Triggervalue 0ms Fadetime 4s
- Cue3 Wait, Triggervalue 500ms Fadetime 0ms
- Cue4 Wait, Triggervalue 500ms Fadetime 0ms
- Cue5 Wait, Triggervalue 500ms Fadetime 0ms

Die Cue2 braucht also länger, als Cue3 - Cue5 zusammen. Nun wird die Cuelist nach dem Ende von Cue5 released, auch wenn Cue 2 noch läuft.

Legt man Beispielsweise eine Gruppe PARs an, weisst der Dimmer Eigenschaft den Chaser Effekt zu um ein Lauflicht zu realisieren und Legt die GO und STOP Funktion im Input Assignment auf zwei Hotkeys, starte die Cue und stoppt diese dann wieder, kann die CUE nicht sofort wieder neu gestartet werden.

Die im Screenshot dargestellte Eingabe wird mir als fehlerhaft gekennzeichnet, obwohl ich gemäß des Tooltipps im richtigen Wertebereich liege.

Zahlreiche MIDI-Controller bieten Tasten, deren Farbe ich über bestimmte MIDI-Werte festlegen kann. Diese Werte sind für eine Reihe von Tasten oftmals gleich. Möchte ich nun für ein Feedback verschiedene Farben einer Taste nutzen, muss ich aktuell den Button (oder ein anderes Element) im RuleSet mehrfach anlegen, damit mit im Input Assignment die Outputs des Buttons mit den verfügbaren Farben ausgeführt werden.

Ich würde mir hier eine Möglichkeit wünschen, zum einen die Definition im Rule Set zu vereinfachen, zum anderen im gleichen Atemzug die Übersichtlichkeit im Output-Baum des Input Assignments zu erhöhen.

Hallo,

ich benutze unter Win10 das Lixada USB-DMX512 Dongle mit dem Illutzmination Treiber um ein RGB Par zu steuern. Funktioniert zunächst wie gewünscht, aber nach einiger Zeit (wenige Sekunden bis Minuten) kommen an der Lampe keine Änderungen mehr an (Display an der Lampe blinkt nicht mehr). Der USB-Stick flackert dann auch nicht mehr orange. Wenn ich unter DMX-Interfaces das Häkchen für “Enable” entferne und wieder setzte läuft es kurz wieder weiter, bis es wieder stoppt. Im Lumos Log steht:

2019-04-20 21:47:36,610 [56] INFO org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Set timing values to Break 0, MAB 243, IB gap 254
2019-04-20 21:47:36,612 [56] INFO org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Successfully enabled uDMX interface with serial ‘ILLUTZMINATOR001’ 2019-04-20 21:48:18,288 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:18,489 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:18,690 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:18,891 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:19,092 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:19,293 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:19,494 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:19,695 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:19,896 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:20,098 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 3 bytes, wrote 0
2019-04-20 21:48:20,299 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 2 bytes, wrote 0
2019-04-20 21:48:20,512 [Main-Process-Chain] WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 1 bytes, wrote 0

Kann man evt. an Timing-Konfigurationen etwas Entspannteres einstellen? Der Test der Hardware mit Freestyler zeigt bisher keine solchen Abbrüche.

Danke für Feedback.

Ich würde mir ein Softdesk Control für das Electricity Feature wünschen.
Hintergrund ist die Anzeige der Verschachtelung der Sources. Dies ist im aktuellen Fenster nicht Erkennbar. Außerdem kann man die Amperemter nicht frei positionieren, wodurch die Anzeige schnell unübersichtlich werden kann.

In einem Beispiel habe ich mal meine Standard Stromverteilungen angelegt und als Screenshot hier eingefügt:

Es wäre ein tolles Feature, wenn man im fullscreen Mode mehre Seiten hätte, durch die man wischen kann.

Sortiere ich mir die Tabelle im Input Assignment nach einer bestimmten Spalte und wechsele durch die Bänke oder in einen Graphen und wieder zurück, wird die Sortierung nicht beibehalten.

Lege ich in einem einzigen Graphen mehrere Slider / Fader auf einen Eingang eines Nodes (zum Beispiel auf den Fade Factor des Cuelist-Nodes), so werden die Werte immer nur von einem Slider / Fader verarbeitet. Über die momentan verfügbaren Nodes kann ein solcher Graph aktuell nicht zusammengebaut werden.

Dieses Ticket lege ich hier vornehmlich der Vollständigkeit halber an zur bereits am Samstag nach dem Live-Q&A geführte Diskussion.

Wenn ich wie im beigefügten Projekt zwischen mehreren Cuelist mit Hilfe einer Cuelist Group direkt (also hart und ohne Fades) wechseln möchte, so erfolgt beim Umschalten kurzzeitig keine Ausgabe. Dies ist sowohl in der Stage View als auch in der Channel Overview zu beobachten.

Im Anhang befindet sich ein entsprechendes Testprojekt. Um das Problem zu reproduzieren, einfach über die Executoren zwischen den drei verlinkten Cuelists wechseln.

Das Ticket entstammt aus einer Rückfrage im Forum, wo das Problem auch schon bei DMXControl 3.1.3 aufgefallen ist.

Ich übergebe dem node eine DeviceID/BeamID und bekomme am Ausgang den aktuellen Wert des in den Parameter ausgewählten Propertys zurück
So kann mann diese werte im InputAssignment benutzen und bsp. eine Matrix als Bitmap an Buttons senden

Case 1: Matrix Highlight flackert wenn ich ein Natives Matrix-Device selektiere

Case 2: Matrix Highlight belibt in Output aus, wenn ich eine gemapte Matrix selektiere

Live Q&A Stream

Hinweise zum dark theme:
-Im Project Explorer sind die Spaltenüberschriften(Name, Anzahl Szenen, usw) nicht dunkel
-Scrollbalken sind hell

In einem mir zur Verfügung gestellten Testprojekt ist folgender Fehler im GUI-Log aufgetaucht:

2019-03-28 22:32:43,413 [Log-Thread] WARN  org.dmxc.lumos.XNAViews.GraphicsDeviceControl - Failed to Draw!
System.InvalidOperationException: An unexpected error has occurred.
   bei Microsoft.Xna.Framework.Graphics.GraphicsDevice.CreateDevice(GraphicsAdapter adapter, PresentationParameters presentationParameters)
   bei Microsoft.Xna.Framework.Graphics.GraphicsDevice..ctor(GraphicsAdapter adapter, GraphicsProfile graphicsProfile, PresentationParameters presentationParameters)
   bei org.dmxc.lumos.XNAViews.GraphicsDeviceService.ResetDevice(Int32 width, Int32 height, Boolean withoutEvent, Nullable`1 handler, Boolean hardReset) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\XNA\GraphicsDeviceService.cs:Zeile 146.
   bei org.dmxc.lumos.XNAViews.GraphicsDeviceControl.OnPaint(PaintEventArgs e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\GraphicsDeviceControl.cs:Zeile 449.

Das zugehörige Projekt kann ich bei Bedarf intern zur Verfügung stellen.

Ich öffne Kernel+GUi. Dabei wird ein neues(leeres) Projekt erstellt. Nun lade ich mein Projekt. Dann fragt er mich,ob ich das neue(leere) Projekt speichern will. Die Abfrage ist überflüssig.

Aus meiner Sicht könnte es hilfreich sein, wenn die automatischen Regeln zum Erstellen eines Graphen nicht nur im Hintergrund in der Tabellenansicht angewendet werden, sondern auch in der Graphenansicht selbst.

Beispiel: ich ziehe in der Graphenansicht den Button eines Softdesks auf das GO einer Cuelist und einen Slider auf die Intensity. Die erste Verbindung wird gemäß der Standardvorgaben automatisch um den Binary Switcher erweitert, die zweite um einen Rule of Three.

Aktiviere ich bei einem Executor Auto Stop, so wird bei loslassen des Flash Buttons, die Cuelist nicht beendet.