Bugtracker DMXControl 3

Möchte ich im Add Device Dialog die DMX-Adresse für ein neu zu patchendes Gerät korrigieren und lösche mittels der Backspace-Taste oder der Entf-Taste meine Eingabe, so werden immer zwei Zeichen entfernt. Im Eingabefeld für Device Name tritt dieses Phänomen nicht auf.

Da dieses Problem ein reines GUI-Problem ist, kann ich hierzu keine Logs zur Verfügung stellen. Dies muss daher direkt in der Software nachvollzogen werden.

Im Ticket FS#4790 hatte ich beiläufig berichtet, dass sich Kernel und GUI nicht mit dem Umbra verbinden, wenn der PC mit zwei Netzwerken verbunden ist. Was mir aber auch mehr oder minder regelmäßig passiert, wenn ich die Netzwerkkonfiguration ändere. Damit meine ich, dass

• der Laptop erst noch per WLAN und per Kabel mit einem Netzwerk verbunden war, ich aber dann die WLAN-Verbindung getrennt bzw. sogar den WLAN-Adapter abgeschaltet habe.
• ich aus bestimmten Gründen die Netzwerkkonfiguration ändere, sowohl Wechsel der statischen IP oder auch Wechsel von statischer IP-Adresse hin zu DHCP oder umgekehrt.

Auf meinem Laptop kann ich es mit der Beta 3 wie folgt reproduzieren:

• Variante 1: Meine Laptops sind per WLAN verbunden (Adresszuweisung per DCHP). Ich stelle eine kabelgebundene Verbindung zum gleichen Netzwerk her (Sowohl feste IP-Adresse über Zuteilung vom Router als auch DCHP) und deaktiviere die WLAN-Verbindung über den Infobereich in der Taskleiste. Diese Variante kann ich sowohl unter Windows 10 als auch Windows 11 nachvollziehen. (Zugehörige Logs unter Windows 10 siehe DMXControl3Logs_20221120_184500.zip)
• Variante 2: Bei meinem Laptop war das WLAN noch über Windows aktiv. Ich habe mein Handy per USB-Kabel angeschlossen, um darüber einen mobilen Hotspot zu erhalten. Dabei wird ein neues “kabelgebundenes” Netzwerk erstellt. Ich hatte dann erst das WLAN abgeschaltet und DMXC3.3 in der Beta 5 gestartet. Nach dem Start stellten GUI und Kernel keine Verbindung zum Umbra her. Auch ein Neustart von DMXC3 mit über Windows eingeschalten WLAN reichte nicht.

In dem genannten Fall muss ich meinen Laptop immer neu starten, wenn ich DMXC wieder nutzen möchte. Ob es noch weitere Randbedingungen gibt, versuche ich weiter herauszufinden. Vielleicht reicht aber diese Beschreibung bereits zum Lösen des Problems.

Das Ticket betrachtet das Problem des Verbindungsaufbaus unabhängig zum Ticket FS#4790.

Softdesk hat Anzeigefehler nachdem er verschoben wurde. Screenshot im Anhang.

Fehlerbeschreibung

Erwartetes Verhalten

Log-Nachricht

2023-05-31 18:04:53,748 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Die Sequenz enthält keine Elemente.
System.InvalidOperationException: Die Sequenz enthält keine Elemente.
   bei System.Linq.Enumerable.Max(IEnumerable`1 source)
   bei System.Linq.Enumerable.Max[TSource](IEnumerable`1 source, Func`2 selector)
   bei Lumos.GUI.Windows.Softdesk.Softdesk.ScaleTransformer_Changed(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 209.
   bei System.Windows.Freezable.FireChanged()
   bei System.Windows.Freezable.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
   bei System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
   bei System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
   bei System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal)
   bei System.Windows.DependencyObject.SetValueInternal(DependencyProperty dp, Object value)
   bei System.Windows.Media.ScaleTransform.set_ScaleX(Double value)
   bei Lumos.GUI.Windows.Softdesk.Softdesk.zoomOut() in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 750.
   bei Lumos.GUI.Windows.Softdesk.Softdesk.Softdesk_OnPreviewMouseWheel(Object sender, MouseWheelEventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 1114.
   bei System.Windows.Input.MouseWheelEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
   bei System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   bei System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   bei System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   bei System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
   bei System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
   bei System.Windows.Input.InputManager.ProcessStagingArea()
   bei System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
   bei System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
   bei System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
   bei System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.Run(Form mainForm)
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Program.cs:Zeile 198.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Program.cs:Zeile 154.
2023-05-31 18:06:26,671 [Log-Thread] INFO  DMXControl 3 GUI - GUI closing!

Kopiere ich in der Stageview Werte, auf denen bestimmte Effekte wie unter anderem der PWM-Effekt angewendet ist, von einem Gerät / Gerätegruppe zu einem anderen Gerät / Gerätegruppe, lässt sich die Stageview bzw. das Device Control nicht mehr bedienen. Siehe hierzu auch die Kommentare.

Die Linke Seitenleiste wird größer, sobald man nach dem Start der GUI das erste mal ein Gerät selektiert.

{Blub 1} > {Blub 2} führt zu Exception

s. Screenshot

Wie immer das gleiche Problem mit den 125% Windows Skallierung

Erzeugt man eine Gruppe von Geräten und wendet ein Fanning zwischen zwei ParameterMastern z.B. auf den Dimmer an (also {ParameterMaster 1} < {ParameterMaster 2}), dann wird das Fanning nicht ausgeführt und es erscheint folgende Fehlermeldung im Kernel:

 ERROR AbstractSceneEntry - Error when getting fanned property values: Fanning not possible for that Type: System.String
 org.dmxc.lumos.Kernel.Exceptions.UnsupportedConvertionException: Fanning not possible for that Type: System.String
 bei org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue.getFannedValues(Int32 count) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Fanning\LinearFannedValue.cs:Zeile 78.
 bei org.dmxc.lumos.Kernel.Scene.Entry.AbstractSceneEntry.getFannedPropertyValue(IRealtimeTimestamp realTimestamp, Boolean includeDisabledDevices) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 462.
 bei org.dmxc.lumos.Kernel.Scene.Entry.AbstractSceneEntry.insertOutputValues(Dictionary`2 values, HALTimestamp timestamp, OutputValuesContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 722.

Das lässt sich unter anderem mit folgenden Fannings reproduzieren:
<,>,<>,?,…

Interessanterweise ist das | Fanning nicht von dem Problem betroffen

Danke fürs Release der 3.2!!!
folgende erste Probleme:
- im Channeloverview überdecken die Gerätebalken die Adressnummern zu 2/3
- alle GUI-Texte sind winzig, (zumindest bei 2736×1824 Auflösung und 200% Skalierung)
- Die Schaltflächen sind daraus folgend so klein dass ich es vergessen kann den Touch zu nutzen. zB am linken rand Projectexplorer und Bühnenansich zusammen sind <8mm

Danke im Voraus!

Hallo,

Ich habe einen Fader über USB-MIDI angeschlossen und über die neuen Input Assignments mit der Intensity vom Programmer verbunden.
Wenn ich in der Stage View eine Lampe auswähle und den Fader hochziehe, wird sie erwartungsgemäß heller. Wenn ich es aber abwähle und den Fader direkt wieder runterziehe werden die Werte vom Fader trotzdem noch für einige ms auf das Gerät angewendet.

Die InputAssignments scheinen erst später zu merken, dass inzwischen ein anderes Gerät ausgewählt ist und dementsprechend eines anderen Geräts Intensity geändert werden soll.

Zur Zeit ist es nicht möglich, im Standard-Theme zwischen absoluten Werten (ABS) und relativen Werten (REL) umzuschalten. Dies klappt nur im Dark Theme.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Lege ich einen bump effekt mit einer releasetime an - z.b. einen blinder - kommt es bei der verwendung eines tem buttons wenn ich den temp button wieder drücke während die cuelist gerade noch releaste - was man bei einem blinder effekt gerne mal macht - zu einem kurzen snao auf black bevor sie wieder voll angeht.

Projekt zum selber testen ist angehängt. einfach auf die exec page “live page background” gehen und irgendeinen der beiden temp buttons nehmen und in die stage view schauen (liegt nicht an der stage view, habe hier zum prepen nen reales gerät, da tritt das ganze genau so auf).

Der Pfad zur MEVP.dll wird im Ausgabeplugin zwar übernommen, gespeichert und ist nach dem Neustart ebenfalls vorhanden. Aber irgendwie fehlt der Verweis auf die MEVP.dll, da ich im Ausgabeplugin nur den reinen Pfad angebe und (gefühlt) nicht mehr wie in einer der vorherigen Versionen auch den Namen der DLL mit eingebe. Dies hat zur Folge, dass Easy View trotz aktiviertem Interface und DMX-Out nicht starten mag.

Getestet mit Build 1581

Beim Starten des Kernels ist mit folgende Fehlermeldung aufgefallen. Im gleichen Zusammenhang frage die Windows Firewall nach, ob die den Datenverkehr zulassen soll.

2019-02-03 15:10:52,754 [Main] ERROR LumosLIB.Kernel.Input.Macroboard.AbstractMacroBoardManager - 
System.Net.Sockets.SocketException (0x80004005): Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden
   bei System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   bei System.Net.Sockets.Socket.Bind(EndPoint localEP)
   bei System.Net.Sockets.UdpClient..ctor(Int32 port, AddressFamily family)
   bei System.Net.Sockets.UdpClient..ctor(Int32 port)
   bei org.dmxc.DMXDude.DMXDudeReceiver.StartRecieverThread(IPAddress ListenerIP) in C:\Users\Grote\Source\Repos\Arduino_DMXC_Streamdeck\DMXDude_VirtualControls_Board\DMXDude_VirtualControls_Board\UDPNetwork.cs:Zeile 33.
   bei LumosLIB.Kernel.Input.Macroboard.AbstractMacroBoardManager.initializeManager() in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Input\MacroBoard\AbstractMacroBoardManager.cs:Zeile 219.

Projekt und Logs siehe  FS#3362 .

Ich habe bereits mit einer der Alpha-Versionen (Build 1554 und 1572) nach der Implementierung von MIDI ein Rule Set erstellt und dieses mit den genannten Versionen bearbeitet und ergänzt.

Füge ich das existierende Rule Set einem neuen, leeren Projekt hinzu und nehme anschließend nur eine einzige Änderung im Rule Set vor, wird das Projekt insofern fehlerhaft geladen, als dass alle Verbindungen im Input Assignment zu dem MIDI-Controller nicht mehr funktionieren. Setze ich die MidiSettings.xml manuell auf den Ursprungszustand zurück, sprich tausche die geänderte Fassung gegen die Initialfassung aus, kann das Projekt wieder vollständig und fehlerfrei geladen werden.

Der Auszug aus den Log sieht wie folgt aus:

2019-03-16 18:47:19,486 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Project.ProjectManager - Error when loading Project Temp\b5f1742c-653f-4a34-b83c-46ad462a3f21.tmp: Warnings in Project
ProjectLoad: WARNING: Unable to load project in MIDIManager(null)org.dmxc.lumos.Kernel.Exceptions.ProjectLoadException: Warnings in Project
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 68.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 139.
   bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   bei System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
2019-03-16 18:47:19,508 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to load project in MIDIManager
2019-03-16 18:47:19,509 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to load project in MIDIManager
2019-03-16 18:47:19,971 [Log-Thread] INFO  org.dmxc.lumos.Kernel.GUISession.Session - Failed to load Project from GUI SKI-DSK-M4A89GA, Path F:\Verein\DMXControl Projects\Software\DMXControl 3\Testprojekte\DMXC 3.2\Beta-Test V3.2 Beta 1 (Testprojekt 1).zip

Im Anhang ist das Projekt mit den defekten MidiSettings sowie separat die MidiSettings.xml in der unveränderten Fassung zu finden. Zusätzlich sind die Logfiles beigefügt.

Im angehängten kaputten DDF führt der Support-Handler zu einer Exception. Dabei ist bei mir auch beim Wechsel zwischen den Funktionen (RGB und Farbtemperatur) die GUI eingefroren. Mit der anderen Variante funktioniert es ohne Probleme (wie heute per TS besprochen).

Beta 1

Die Visualisierung des Cuelist Status funktioniert nicht richtig. Es werden derzeit mehrere Cuelists als Aktiv markiert, wenn das Tracking aktiv ist und dort noch Fragmente enthalten sind. Ebenfalls wird immer nur die letzte Cue aktualisiert.

Patrick kennt den Fehler und sagt dass es der Fehler nicht bei der Visualisierung liegt, sondern an der Art, dass Cues noch teil aktiv sind.

Ich hab ein Umfangreiches DDF geschrieben, in dem Meiner Meinung nach das Gobo-Rad so funktionieren muss, weil ich es von einem Anderen Movinghead der selben Firma kopiert habe, und ledigtlich die .pngs und dmx-Werte angepasst habe.

Doch immer wenn ich in DMXC3 ein Gobo anwähle wird immer das Letzte also Gobo7 in der StageView angezeigt und auch per DMX außgegeben.
Die DMX-Werte hab ich im DDF nochmal gecheckt, das sollte so so passen.

Aus FS#3715 entstanden, folgende Vorschläge (weitere gerne willkommen)

• Link / Connection (DE: Verbindung) (Aktuell)
• Graph (DE: Graph) (missverständlich)
• Assignment (DE: Zuordnung) ⇒ Gefällt mir am besten. Dann wäre Verknüpfung / Verbindung zwischen zwei Knoten und Assignment / Zuordnung der ganze Graph

Dazu passend:  FS#3271 

Beim laden eines Projektes mit dem Node Speedmaster wird der Beatwert nicht ausgegeben, obwohl der Ausgang verwendet wird. Das bedeutet, auf meinem Streamdeck wird es nicht visualisiert. Erst wenn ich die Geschwindigkeit änder, funktioniert es.

Ist die Anzahl der Geräte im Ordner Devices oder in einer Device Group so groß, dass man in dem Ordner scrollen muss, wird bei einer Verlängerung der Gerätebezeichnung immer nur die Länge der Zeichenkette als Referenz genommen, die sich im sichtbaren Teil der Liste befindet. Haben Geräte im unteren Teil der Liste eine (deutlich) längere Bezeichnung, so wird diese nicht vollständig angezeigt - obwohl die Spalte Name diese längere Bezeichnung zum Teil bereits registriert.

Im Anhang ist ein entsprechendes Beispielprojekt zu finden.

Aktiviere ich die Einstellung “Show Taskbar Icon for floating windows” kann ich diese Fenster zwar auf jedem beliebigen Bildschirm maximieren, aber nicht in die Taskleiste minimieren. Letzteres wäre aber gerade für das Arbeiten mit nur einem Bildschirm hilfreich. Zur Zeit muss ich die Fenster immer aus dem Bildschirm “herausschieben”, um im Hauptfenster zu arbeiten.

Durch die neuen Master kamen weitere Icons in der sowieso extrem breiten Menüleiste des Project Explorers hinzu. Dadurch rutschen häufiger benötigte Icons noch weiter nach rechts.

Daher wäre der Wunsch unabhängig vom Ticket FS#3360, dass diese vier Icons für die vier Master in ein Dropdown-Menü zusammengefasst werden, dessen Obertitel “Add Master” ist.

Das 3Dconnexion Plugin muss auf DMXControl 3.3 portiert und dann wieder dem Installer hinzugefügt werden.

Ich finde es unpraktisch, dass sowohl Konsole als auch GUI das selbe Icon tragen, da in der Taskleiste von Windows 7 nur die Icons dargestellt werden. Super wäre es zum Beispiel, wenn das Icon der Konsole so ein kleines schwarzes Konsolenfenster in der Ecke tragen würde. Also so wie das Icon von CMD irgendwo in der Ecke.

Zoom und Position und Drehung

Meiner Meinung nach sollte überlegt werden, wie sich vor allem das Group Handling schneller erreichen lässt. Ich finde es ein richtig starkes Feature, was aber aktuell ein wenig zu sehr versteckt ist und deswegen beim produktiven Arbeiten über das Dropdown-Menü etwas umständlich zu erreichen ist. Überlegungen wären hier:

• Das Group Handling erhält einen eigenen Reiter innerhalb des Device Controls (neben den Reitern Properties und Effects).
• Für das Group Handling wird ein komplett separetes Fenster losgelöst vom Device Control geschaffen, sodass (genügend Bildschirmfläche vorausgesetzt) Group Handling und Device Control neben- oder untereinander angezeigt werden können.

Von der Usability her ist es einem User nicht zu vermitteln, dass er bei einem Lauflicht mit einer einzelnen aktiven Lampe den Chaser-Effekt nehmen soll, während er bei mehr als einer aktiven Lampe einen Rechteck-Effekt auf den Dimmer legen muss (siehe Diskussion hier: https://forum.dmxcontrol-projects.org/index.php?thread/14067-2er-oder-3er-chaser-in-dmx-control-3/ ) Daher sollte der Chaser-Effekt einen Anzahl-Parameter erhalten, mit dem die Anzahl der nebeneinander aktiven Lampen pro Chaser-Step eingestellt werden können.

Bei den Opionen zu den Cuelistgruppen gibt es den Eintrag “One ends all”. Ich würde den umbennen zu “Master/One ends all”. Bei stop dementsprechend.

Der Counter kann hoch und runter zählen. Ich stelle mir da einen Encoder vor der bei Vor und bei Zurück den Counter hoch oder runter zählen lassen kann. Bei Klick oder ä. muss der Counter wieder zurück gesetzt werden. Dazu wäre ein “Reset” Input nötig und eine Option “reset value”

Wie wir gestern bei der Teamspeak-Konferenz herausgefunden haben, lässt der Audio-Analyzer die GUI nach einem Neustart einfrieren.
Dieses Verhalten wurde durch Joseph auf seinem rechner bestätigt. Auch auf einem zweiten Rechner konnte ich diesen Bug nachstellen. Es gibt keine Einträge in den Logs.

Dies passiert unabhängig vom Dark-Theme und deutscher Übersetzung.

Oft passt die neue Anzeige vor den Cues nicht. Mal ist ein Feld hellrot, mal dunkelrot. SIehe Bilder( zu zwei verschiedenen Zeitpunkten ist Cue1 einmal hellrot und einmal dunkelrot)

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

Damit in Zukunft bei Controls die größer sind und wenn weitere Eigenschaften bei den Softdesk Controls hinzu kommen, sollte es eine Gruppierung in:
-Position/Rotation (besserer Name willkommen “Allgemein?” )
-Styling (für Style und Farben und in Zukunft vielleicht auch Bilder)
- Funktionsweise
Etc. Stattfinden

s.o.

Meine Matrix wird über sACN angesteuert (i Gerät, 4 Universen). Manuell kan ich 4 einzelne Interfaces einrichten und dann auch Werte darüber ausgeben.

Nach Neustart von DMXControl ist nur noch eines der 4 Interfaces verfügbar. Die anderen 3 sind nicht aktiv (Interface not available). Ich kann die anderen 3 Interfaces löschen und neu anlegen, danach sind die alle wieder aktiv.

Bilder siehe Anhang.

Lösung auf 3.3 verschoben, da auch die Performance der Matrix-Effekte/Matrix-Ausgabe überarbeitet werden muss.
Beispiel: Plasma-Effekt 34x20Pixel, DMXControl3 → 45%CPU : JINX → 3%CPU

Wenn man einen Effekt auf Pan/Tilt legt,
schaltet sich dieser ab wenn man im
Positions-Fenster die Position verschieben
möchte.

http://www.dmxcontrol.de/forum/index.php?page=Thread&threadID=8740

Gruß Uwe

hab 40 Generic RGB Pars hinzugefügt und lumos gedrückt weiß eungestellt und strobe hoch gezogen.
un der liveVuew blinkts, aber due echten lampen nicht(dmxausgabe fehlerhaft)

MfG
Patrick

Die GUI stürzt ab, wenn der besagte Haken deaktiviert ist und dennoch der Wert über den Schieberegler verändert wird.

• Entweder Regler mit deaktivieren

• Wertebereich prüfen / Register?

16 Generic RGB anlegen

Gruppe auswählen

Saturation auf 255

Effect auf Saturation legen mit Intensity -255

Phase 0<360

Preset(Nur Saturation) speichern

ClearProgrammer

Doppelklick auf Preset

Am Colorkreis ne farbe wählen ⇒ CRASH

MfG
Qasi

Edit:

Project laden
Ersten Geric RGB anwählen und das 2. Preset per doppelklick in dem Row-Header starten.
Crash

Hallo zusammen,

folgendes Szenario ist mir aufgefallen:
In DMXC3 habe ich 40 Generic Dimmers angelegt. Automatisch wird jedem Dimmer eine neu DMX-Adresse zugewiesen. Gleichzeitig wird eine dazugehörige Gruppe angelegt. Soweit so gut.

Versuche ich jetzt einige der Generic Dimmer auf ein und die selben Kanäle zu “patchen” wird bei der Übernahme der Kanalwert DMXC3 extrem langsam. Die ersten Dimmer lassen sich noch normal umbenenen und den Knaälen zuweisen, später ist das nicht so ohne Weiteres möglich. Je mehr Dimmer man umbenennt und zuweist (einzeln, wohl bemerkt!) um so länger dauert es bis diese Werte übernommen werden. Nach dem 15 Dimmer lag die Wartezeit schon bei 40 Sekunden.

Noch extremer gestaltet sich das Szenario wenn man die Gruppe (sprich alle 40 Dimmer) z.B. auf einen Dimmerwert von 70% stellt und dann versucht diese um zu benennen und anderen DMX-Kanälen zu zuordnen.

Vermutlich wird hierbei immer mehr Speicher verbraten.

Startet man die GUI und den Kernel neu, läuft wieder alles flüssig.