Bugtracker DMXControl 3

Ich habe festgestellt, dass der Parameter “Play Mode” des Color Chasers sich ausschließlich auf die Wiedergabereihenfolge der zugeordneten Color List bezieht. Ich habe bei aktiviertem “Use Device Index” aber keine Möglichkeit, eben diesen zu beeeinflussen. Egal ob Play Mode “Normal”, “Bounce” oder “Reverse”: die optische Laufrichtung des Color Chasers bleibt immer die selbe.

Daher wünsche ich mir für den Color Chaser im Endeffekt alle Parameter zusätzlich, die in den neuen Chaser Einzug erhalten haben:

• Fade Curve
• Break Steps
• Break Time
• Size
• Step Size
• Play Direction (Play Mode für Device Index)

Hinter dem Parameter Play Direction versteckt sich zum einen eben die bis dato fehlende Ansteuerung des Device Index, zum anderen aber auch die bereits für den einfachen Chaser implementierten Play Modes inklusive der Möglichkeit, per csv-Datei weitere eigene zu hinterlegen. Wenn ich dies richtig überblicke, können die Play Modes des neuen Chasers 1:1 auf den Color Chaser zur Ansteuerung des Device Index übertragen werdem.

Durch dieses Update könnte es eventuell sein, dass der bis dato vorhandene Parameter “Index Offset” überflüssig wird, weil er in einer der neuen aus dem neuen Chaser übergeht.

Stand heute gibt es beim PWM Static nur die Möglichkeit, eine Gruppe von Geräten entsprechend der Position des zugeordneten Parameter Masters “aufzufüllen”. An dieser Stelle wünsche ich mir die Möglichkeit, eine feste Anzahl von Geräten (zum Beispiel 3) mittels des Parameter Masters innerhalb der Gerätegruppe hin- und herzuschieben. Beim Minimal- bzw. Maximalwert des Parameter Masters leuchten dann immer drei Geräte am entsprechend korrespondierenden Ende der Gerätegruppe. Bei 50% würden in der Mitte vier Geräte leuchten (die beiden mittleren mit 100%, die äußeren mit je 50% leuchten), wenn Fade auf True gesetzt ist und die Gruppe eine gerade Anzahl von Geräten umfasst.

Hierzu bedarf es neben dem zusätzlichen Parameter für “Size” auch einen weiteren Eintrag für den Parameter “Direction”, der beispielsweise “Group” lauten könnte. In diesem Zusammenhang wäre zu überlegen, ob nicht eine Umbenennung des Parameters “Direction” in “Play Mode” erfolgt.

Im dynamischen PWM-Effekt müssen diese Ergänzungen nicht vorgenommen werden, weil sich dieses Szenario mit dem neuen Chaser abbilden lässt, sofern der Effekt eben automatisch laufen soll.

Beim Verfassen des Tickets FS#4759 ist mir aufgefallen, dass der neue Chaser um vier weitere Play Modes erweitert werden kann:

• Fill from left (>)
• Fill from right (<)
• Fill from center (<>)
• Fill to center (><)

Diese vier zusätzlichen Play Modes stammen aus dem dynamischen PWM-Effekt. Aus meiner Sicht sind diese vier anderen Play Modes der einzige Unterschied, der zwischen dem neuen Chaser und dem dynamischen PWM-Effekt existiert. Von daher würde ich in diesem Zusammenhang vorschlagen, den dynamischen PWM-Effekt nach der Übernahme der oben genannten Play Modes in den neuen Chaser zu entfernen.

Im Zuge der Freischaltung der Funktion “Gruppen in Gruppen” (siehe  FS#674 ) soll das Group Handling dahingehend erweitert werden, dass

• eine nachvollziehbare Ansteuerung auch über n Ebenen möglich ist und dabei nicht für jeden Anwendungsfall eine neue Gruppe angelegt werden muss
• ggf. auf unterschiedlichen Ebenen ein unterschiedliches Group Handling ausgewählt werden kann
• das Group Handling weitere Funktionen anbietet

Das beigefügte Projekt soll einen exemplarischen Aufbau zeigen, bei dem die Ansteuerung der insgesamt 100 Beam-MHs und 12 Spot-MHs am Ende durch ein verbessertes und erweitertes Group Handling deutlich variantenreicher erfolgen soll, ohne zusätzliche Gruppen anliegen zu müssen. Insgesamt gibt es bis zur Device-Ebene drei Gruppen-Ebenen. Folgende Szenarien sollten exemplarisch anhand eines Lauflichts einfach darstellbar sein, wobei sich diese Liste ggf. bei weiteren Überlegungen noch beliebig weiterspinnen lässt:
* Lauflicht innerhalb eine gesamte Zeile über die 25 Spalten hinweg (25 Geräte, Laufrichtung links rechts), egal ob nur bezogen auf eine Zeile oder ein paralleles Lauflicht über alle fünf Zeilen
* Lauflicht innerhalb eines Blocks, beginnend oben links, endend unten rechts
* Lauflicht über die fünf / sechs Zeilen hinweg (Laufrichtung oben unten), egal ob nur bezogen auf eine Spalte oder parallel auf allen 20 Spalten
* Lauflicht über alle 24 Einzel-Zeilen, wo immer fünf bzw. drei Geräte gemeinsam ein- und ausgeschaltet werden
* Lauflicht über die vier Blöcke, wo immer 28 Geräte gemeinsam ein- und ausgeschaltet werden
* Gegenläufige Lauflichter aus der oberen Gruppe heraus, wo Zeilen 1, 3 und 5 links-rechts und Zeilen 2 und 4 rechts-links wiedergegeben werden

Hallo Zusammen,
wie im Stream von euch angeboten das Tickes zu einem Zusätzlichen Effekt wie Sparkle.

Unter Wave/ Lauflicht (Chaser/PWM) verstehe ich einen Effekt der auf der Farbe liegt und diese beeinflusst.

Erstmal die Attribute:

• Fade-In Time (ms): Zeit wie lange der Farbwechsel beim einfaden dauert

• On Time (ms): Zeit wie lange die Farbe gehalten wird

• Fade-Out Time (ms): Zeit wie lange der Farbwechsel beim ausfaden dauert

• Duration (ms): Zeit zwischen dem Start der ersten Lampe und dem Start der nächsten Lampe, Idealerweise mit dem „Speed master“ steuerbar, wird nicht von Fade-In Time beeinflusst

• Run: bei loop, der Durchlauf wird wiederholt, bei single, wird nurch einmal durchgelaufen

• Revers: bei nein, ablauf der Schritte hochzählend (1-2-3-4), bei ja, ablauf der Schritte Rückwärts (4-3-2-1)

• Ping-Pong: nein, der Ablauf beginnt wieder von Vorne (1-2-3-4|1-2-3-4|1-2-3-4|…), bei ja läuft der Ablauf einmal Vorwärts und danach rückwärts und dann wieder vorwärts usw. (1-2-3-4-3-2-1-2-3-4)

Revers und Ping-Pong sind ähnlich dem Play Mode im Chaser

Ablauf:
Start bei Beginn der Gruppe
1: X|0|0|0
2: 0|X|0|0
3: 0|0|X|0
4: 0|0|0|X

Start Mittig der Gruppe
1: 0|0|0|X|X|0|0|0 / 0|0|0|X|0|0|0
2: 0|0|X|0|0|X|0|0 / 0|0|X|0|X|0|0
3: 0|X|0|0|0|0|X|0 / 0|X|0|0|0|X|0
4: X|0|0|0|0|0|0|X / X|0|0|0|0|0|X

Bei “Beginn der Gruppe” wurden weniger Lampen gewählt als bei “Mittig der Gruppe”, damit die Anzahl der Schritte gleich sind.

Wenn das Lauflicht sich einholt, dann soll wieder vom aktuellen Punkt wieder Einfaden, hier würden sich die Zeitkurven einer Lampe überlagern, ähnlich der Zeitkurve im Bild 010.png zu sehen. Blau ist der erste Durchlauf, grün der zweite Durchlauf und rot sich der ergebene Ablauf. Falls der überschneidende Bereich nicht existiert, dann bleibt die eingestellte Farbe gleich und der Lampe fehlt Zeit zurück zufaden.

Wenn sich zwei verschiedene Lauflichter sich überlagern, soll vom jetzigen Zeitpunkt, vom ersten Lauflicht in das zweite hineingefadet werden, ähnlich Bild 020.png

Das fanning der Farbe könnte sich nicht auf den Beginn der Grupe bis Ande der Gruppe legen, sondern Beginn des Lauflichtes Schitt 1 bis zum letzten Schritt

Gruß
Max

Edit 1: genauere Beschreibung ergänzt

Following discussion with JP on the forum, I’m posting this feature request here.

It would be useful to be able to achieve the following effect using the chaser effects:

https://vimeo.com/676900437/6d03543b2e

JP suggested this could be implemented as a ‘Fill’ option on the chasers.

As an example using the Colour chaser, the chaser should change the colour of each device to the next colour on the colour list, in selection order, until all devices have been changed, and then repeat with the next colour on the list.

This should work in combination with the play mode to set the direction that the fill happens in - forward, reverse, bounce or random.

This could also work with the standard chaser to apply the fill effect to dimmer intensity.

s.o. (Reminder für JPK, siehe Projekt SpeedMaster Slider Beispiel)

Hällt alle daten cuelists exexutoren, alles und ist im project umschaltbar und kann usern zugeordnet werden

Eine Cueliste die den i halt einer anderen Cueliste 1 zu eins als refferenz übernimmt, aber seperat ausgeführt werden kann

Selection Grid siehe MA
Als Diskussionsgrundlage

S.o.

s.o.

Ein Lauflicht im Außenkreis wobei der erste Pixel immer der hellste ist und dahinter immer dunkler sind:
https://ak.picdn.net/shutterstock/videos/1034400863/thumb/5.jpg?ip=x480

“Linienscanner” - Ein Senkrechter Strich, der von links nach rechts durchwandert. Der Strich kann im Winkel gedreht werden, sodass bei 90° der Strich waagerecht von oben nach unten durchläuft

I have a simple preset (dimmer and colour values for LED Pars), and this preset is used in a number of cues. When I ‘Edit in programmer’ the preset, change the colour values and then ‘Update’ the preset, the next time I go to play the cuelist the cues won’t play and a series of error reports appear in the kernel output. I’m also unable to save the project after this.

I can’t see a way to attach a log file to this report, but here’s a Dropbox link to the log zip file: https://www.dropbox.com/s/i6we4ho0szycprv/DMXControl3Logs_2022430_213811.zip?dl=0

Regelmäßig unregelmäßig kam es in bei mir im York vor, dass ein Tastendruck im Softdesk teilweise mit mehreren Sekunden Verzögerung umgesetzt werden. Dieses Problem kommt und geht über den Abend, ohne dass nicht explizit Änderungen am ausgeführten Projekt durchgeführt werden.

@patme hat in der heutigen Beta-Testerrunde berichtet, dass ihm dieses Problem bei einem seiner letzten Langzeit-Testläufe mit DMXControl 3.3.0 Beta 2 ebenfalls unter die Finger gekommen ist.

Ich baue mir aktuell mehrere Cuelists mit einer höheren Priorität, bei ich laufende Cuelists gezielt für folgende Lichtstimmungen überschreibe:

• Moderationslicht
• Einmarsch
• Siegerehrung
• Spiegelkugel-Ambiente

In allen Fällen nutze ich für die jeweiligen Lichtstimmungen meist die gleichen Geräte, die sonst auch für die allgemeine Show mitlaufen. Habe ich nun solche Mehrfachverwendungen, muss ich aktuell immer manuell dafür sorgen, dass ich in den zugehörigen Cuelists zum Beispiel die Gobos und Prismen herausnehme oder den Strobe gezielt auf 0 setze, wenn ich eine “saubere” Ausgabe haben möchte. Sprich: auch wenn ich einen Strobe-Effekt abfeuere, soll das Gerät für das Moderationslicht nicht mit stroben. Dies wird insbesondere bei Moving Heads mit ein paar mehr Funktionen immer aufwendig.

Um die Programmierung zu vereinfachen, würde ich mir eine Möglichkeit wünschen, bei der ich gezielt festlegen kann, dass für in der Cuelist nicht verwendete Funktionen automatisch die Grundwerte von den verwendeten Geräten herangezogen werden. So müsste ich dann für das Spiegelkugel-Ambiente nur Dimmer, Position, Farbe und Iris festlegen. Andere Funktionen wie Gobo oder Prisma werden beim Starten auf die Werte gesetzt, die die Geräte als Default einnehmen (Gobo offen, kein Prisma, kein Strobe).

Fehlerbeschreibung

{ParameterMaster 1:*360/COUNT*(COUNT-1)}

Erwartetes Verhalten

Hinweise

Wie bereits im Forum mit @JPK besprochen (https://forum.dmxcontrol-projects.org/index.php?thread/16686-probleme-bei-benutzung-berechneter-phase) wäre es praktisch eine Konstante zu haben, die den (Phasen-)Winkel zwischen den Geräten einer Gruppe angibt. Um das umzusetzen müssten folgende Punkte implementiert werden:

* Erlauben von Berechnungen im Device Control
* Einführung der Konstante DEVICEANGLE (wäre wohl als 360/AnzahlAnGeräten zu definieren?)

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Folgender Test-Aufbau:
Softdesk, Colorbar mit Colormaster verdrahtet.
Colormaster mittels “Bitmap from Color” auf Button visualisert. Funktioniert wie erwartet. Lade ich das Projekt neu ist der Button wieder grau, der Colormaster hat weiterhin die zuvor eingestellte Farbe. Gleiches Verhalten wenn die Colorbar in “Bitmap from Color” verschaltet wird. In der 3.2.3. funktioniert dies noch einwandfrei.

Hallo,
bei mir funktioniert der One Shoot Trigger nicht. Ich beginne mit einem Lauflicht über 8 RGB PARs. Danach folgt die Cue mit dem One Shoot Trigger, gefolgt von einer Cue, die die PARs auf eine Farbe einfadet.
Wenn ich die List starte, wird die One Shoot Cue sofort auf gelb gesetzt und das Einfaden beginnt. Währenddessen kann man sehen, dass das Lauflicht läuft bis es von der dritten Cue überschrieben ist.
Es gibt keine Fehlermeldung, weswegen ich auch keine Screenshots beisteuern kann. Ich habe lediglich das letzte Log File und das Projekt zum Anhängen.

Gruß, Herbert

P.S.: Sorry, die untenstehende Verknüpfung war ein Versehen. Ich dachte hier fügt man Verknüpfungen zu anderen Trackern ein, und jetzt kann ich sie nicht mehr löschen

Aktuell ist der zulässige Höchstwert für die Phase bei 1080° festgesetzt. Dieser ist mittlerweile zu gering und sollte hochgesetzt werden.

In diesem Zusammenhang wäre dieser Wert als zentrale Konstante zu definieren, statt ihn einzeln in den Effekten zu hinterlegen.

Hallo,
folgendes Szenario:

Ich möchte in der Stage View einen Effekt mit dem Color Chaser bauen.
Mache den Dimmer auf 100 und füge den Color Chaser der Color hinzu.
Ich ändere ein paar Einstellungen und mir fällt auf das ich noch eine Item List erstellen möchte.
Also wird eine Color Item List erstellt.

Diese neue Item List wird mir unter dem Device Control im Color Chaser aber nicht angezeigt.
Ich muss erst mit dem X den Color Chaser entfernen und neu hinzufügen, erst jetzt wird die neue Color Item List angezigt und kann verwendet werden.
Es sind dann aber alle Einstellungen die gemacht wurden zurückgesetzt und man muss diese neu einstellen.

Es wäre doch schön wenn neue Color Item Lists sofort angezeig werden würden.
Dies ist mir in der 3.3.0 Beta 8 aufgefallen, das ist aber auch in der 3.2.3 so.

Gruss Steff

Hallo,
ich habe mir in meinem “großen Projekt” eine Matrix angelegt und hierzu Device Groups für das Gesamte und Teile der Matrix hinterlegt. Das Projekt wird soweit ohne Probleme geladen. Aber beim beenden hängt sich die GUI auf.

Ich habe das dann etwas kleiner nachgebaut und etwas getestet. Projekt hier von im Anhang.

Ich habe dann Objekte aus den Device Groups gelöscht und wieder hinzu gefügt. Danach kommen beim beenden diverse Fehlermeldungen im Kernel. Logfiles sind angehängt.

Gruß Steff

- Projekt laden, Fensteranordnung laden
- Preset “Flüstern - Strophe” → Im Programmer bearbeiten
- “Pixel Col 1” aus Programmer löschen
- “Pixel” aus Programmer löschen
- Gruppe Pixel in Main-Stageview auswählen

Nach kurzer Zeit im Umbra:

19:33:22 ERROR ServerCallHandler - Error when executing service method 'CanAttachTo'.
System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at Umbra.Bridge.UnaryToStreamBridge`2.ClientSideTaskProvideClient(TRequest request, UmbraClient u, Nullable`1 deadline, CancellationToken contextCancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\UnaryToStreamBridge.cs:line 0
   at Umbra.Bridge.UnaryToStreamBridge`2.ClientSideTaskProvideClient(TRequest request, UmbraClient u, Nullable`1 deadline, CancellationToken contextCancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\UnaryToStreamBridge.cs:line 208
   at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle)
   at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle)
   at Grpc.AspNetCore.Server.Internal.CallHandlers.UnaryServerCallHandler`3.HandleCallAsyncCore(HttpContext httpContext, HttpContextServerCallContext serverCallContext)
   at Grpc.AspNetCore.Server.Internal.CallHandlers.ServerCallHandlerBase`3.<HandleCallAsync>g__AwaitHandleCall|8_0(HttpContextServerCallContext serverCallContext, Method`2 method, Task handleCall)
19:33:25 ERROR ServerCallHandler - Error when executing service method 'CanAttachTo'.
System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at Umbra.Bridge.UnaryToStreamBridge`2.ClientSideTaskProvideClient(TRequest request, UmbraClient u, Nullable`1 deadline, CancellationToken contextCancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\UnaryToStreamBridge.cs:line 0
   at Umbra.Bridge.UnaryToStreamBridge`2.ClientSideTaskProvideClient(TRequest request, UmbraClient u, Nullable`1 deadline, CancellationToken contextCancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\UnaryToStreamBridge.cs:line 208
   at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle)
   at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle)
   at Grpc.AspNetCore.Server.Internal.CallHandlers.UnaryServerCallHandler`3.HandleCallAsyncCore(HttpContext httpContext, HttpContextServerCallContext serverCallContext)
   at Grpc.AspNetCore.Server.Internal.CallHandlers.ServerCallHandlerBase`3.<HandleCallAsync>g__AwaitHandleCall|8_0(HttpContextServerCallContext serverCallContext, Method`2 method, Task handleCall)

- PWM-Effekt auf Pixel-Dimmer in Gerätesteuerung ziehen
→ Effekt steht
→ Effekt lässt sich nicht mehr löschen

Ich habe mich mit dem PC 1 in einer 1:1-Verbindung auf dem Umbra verbunden, der gemeinsam mit dem Kernel auf PC 2 läuft. Nun ändere ich währenddessen die IP-Adresse des PC 2. Nach einem kleinen Moment stürzt die GUI ab.

Die Verbindung zwischen Umbra und Kernel bleibt auf dem PC 2 bestehen und auch beide Programme laufen weiter. Nach einem Neustart der GUI war ein direktes Verbinden und weiterarbeiten mit dem ggf. aktuell geladenen Projekt möglich.

Das erwartete Verhalten wäre an dieser Stelle, dass die GUI es zumindest abfangen kann, wenn die ursprüngliche Verbindung unterbrochen wird - was ja auch in anderen Konstellationen vorkommen kann.

Die Logfiles sind für beide PCs (PC 1: GUI, PC 2: Umbra und Kernel) im Anhang beigefügt.

Ich habe in einem geladenen Projekt ein MIDI Ruleset importiert, dies soweit problemlos. Nach speichern und danach neu laden des Projekts crashte mir die GUI (siehe Bild im Anhang).

Dieses Verhalten konnte ich nicht reproduzieren.

Logs im Anhang.

Beim Bearbeiten einer Szenenliste hatte ich zwei Einträge (Strophe / Refrain) in die Zwischenablage kopiert, um sie mehrfach einzufügen. Das hatte ich in der Vergangenheit auch schon mal ohne Probleme getan. Dieses Mal (natürlich wenn man in Eile ist…) ist dabei aber DMXC ziemlich komplett abgeschmiert, auch der Kernel war nicht mehr zu gebrauchen.
Im Kernel-Log findet sich auch die Zeile

Main Runnable seams stuck in an endless loop! You might have to restart DMXC... Please report this!

Das ganze passiert so etwa um 18:09.
Im Projekt gab es hinterher auch eine Version 0.0.122, die aber scheinbar nur in den Metadaten existiert, aber nicht auf Disk geschrieben wurde. Daher habe ich die 121 angehängt. Gearbeitet hatte ich in der Szenenliste “Sturm auf die Hausi”.
Passiert in 3.3 Beta 9 (Komma 1, JPK hatte die Anzeige der Presets noch gefixt).

Parameter Master in Group Handling ermöglichen. In Verbindung mit Effekten die z.B. ein Fanning von 0#100 haben würden sich viele odd and even Effekte in deutlich weniger Cuelisten bauen lassen.

Fehlerbeschreibung

Erwartetes Verhalten

Ich ändere ein existierendes Preset über “Edit in Programmer”. Das Preset ist dabei in der Liste nicht ausgewählt. Um die gewünschten Änderungen nun wieder zurück zu speichern, muss ich das richtige Preset auswählen, um dann über “Add Preset” den entsprechenden Befehl hierfür auszuführen.

Den Schritt des “Auswählens” des Presets, welches sich gerade im Programmer befindet, würde ich mir gerne sparen, indem dieses automatisch ausgewählt wird, sobald ich “Edit in Programmer” aufrufe.

Lege ich ein neues Preset an, sollte innerhalb des Fensters immer automatisch zu diesem neuen Preset gesprungen werden, dass ich nicht durch die Liste scrollen muss. Im Idealfall wird es auch noch automatisch ausgewählt.

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

    <Rule Name="1-1 input" UseBacktrack="false" Threshold="126" IsToggle="false" EnableMessage="2134413313" EnabledBacktrack="0" DisableMessage="2134409217" DisabledBacktrack="0">
      <Type>Lumos.GUI.MIDI.ButtonRule</Type>
    </Rule>

     <TreeItem Name="Rule">
        <Attribute Name="Type" Type="Primitive" ValueType="String" Value="Lumos.GUI.MIDI.ButtonRule" />
        <Attribute Name="Name" Type="Primitive" ValueType="String" Value="1-1 input" />
        <Attribute Name="GUID" Type="Primitive" ValueType="String" Value="0e001dac-84c0-4cd5-9dc8-1d5e99b22533" />
        <Attribute Name="UseBacktrack" Type="Primitive" ValueType="Boolean" Value="False" />
        <Attribute Name="State" Type="Primitive" ValueType="Boolean" Value="False" />
        <Attribute Name="Threshold" Type="Primitive" ValueType="Byte" Value="126" />
        <Attribute Name="IsToggle" Type="Primitive" ValueType="Boolean" Value="False" />
        <Attribute Name="EnableMessage" Type="Primitive" ValueType="Int32" Value="2134413313" />
        <Attribute Name="EnabledBacktrack" Type="Primitive" ValueType="Int32" Value="2134413313" />
        <Attribute Name="DisableMessage" Type="Primitive" ValueType="Int32" Value="2134409217" />
        <Attribute Name="DisabledBacktrack" Type="Primitive" ValueType="Int32" Value="0" />
    </TreeItem>

    <Rule Name="1-1 output aus" UseBacktrack="true" Threshold="126" IsToggle="false" EnableMessage="0" EnabledBacktrack="3706881" DisableMessage="0" DisabledBacktrack="0">
      <Type>Lumos.GUI.MIDI.ButtonRule</Type>
    </Rule>

    <TreeItem Name="Rule">
        <Attribute Name="Type" Type="Primitive" ValueType="String" Value="Lumos.GUI.MIDI.ButtonRule" />
        <Attribute Name="Name" Type="Primitive" ValueType="String" Value="1-1 output aus" />
        <Attribute Name="GUID" Type="Primitive" ValueType="String" Value="efd45d5e-33da-4132-bad2-2b184f844e6d" />
        <Attribute Name="UseBacktrack" Type="Primitive" ValueType="Boolean" Value="True" />
        <Attribute Name="State" Type="Primitive" ValueType="Boolean" Value="False" />
        <Attribute Name="Threshold" Type="Primitive" ValueType="Byte" Value="126" />
        <Attribute Name="IsToggle" Type="Primitive" ValueType="Boolean" Value="False" />
        <Attribute Name="EnableMessage" Type="Primitive" ValueType="Int32" Value="0" />
        <Attribute Name="EnabledBacktrack" Type="Primitive" ValueType="Int32" Value="0" />
        <Attribute Name="DisableMessage" Type="Primitive" ValueType="Int32" Value="0" />
        <Attribute Name="DisabledBacktrack" Type="Primitive" ValueType="Int32" Value="0" />
    </TreeItem>

Autosave ist standardmäßig deaktiviert. Bei neuen Installationen ist dies dementsprechend nicht aktiv und führt zu Problemen wenn mans vergisst zu aktivieren.

Fehlerbeschreibung

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

 at org.dmxc.lumos.Kernel.Master.MultimediaTimer.Start() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\SpeedMaster.cs:line 557
 at org.dmxc.lumos.Kernel.Master.SpeedMaster.set_Interval(Int32 value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\SpeedMaster.cs:line 187
 at org.dmxc.lumos.Kernel.Master.SpeedMaster.SetMasterSpeed(Double ms, Boolean throwEvent) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\SpeedMaster.cs:line 214
 at org.dmxc.lumos.Kernel.Master.SpeedMaster.set_FaderValue(Double value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\SpeedMaster.cs:line 253
 at org.dmxc.lumos.Kernel.Master.SpeedMaster.LoadFromManagedTree(ManagedTreeItem m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\SpeedMaster.cs:line 434
 at org.dmxc.lumos.Kernel.Master.MasterManager.LoadBeforeContainer(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\MasterManager.cs:line 776
 at org.dmxc.lumos.Kernel.Master.MasterManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\MasterManager.cs:line 747   at org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass51_1.<LoadProjectFromStream>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 426
 at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
 at org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:line 142
 at org.dmxc.lumos.Kernel.Project.ProjectManager.LoadProjectFromStream(ProjectVersionID id, Stream projectStream, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 421

Da gerade im Forum die Frage nach der Performance von DMXControl 3 hoch kam, drängte sich für mich eine Idee geradezu auf: Einen internen Benchmark-Test von DMXControl 3. Sprich ein mitgelieferter, immer gleicher Ablauf typischer Dinge, um herauszufinden, wie performant ein PC ist. Passende Szenarien könnten folgende sein:

• Dauer Programmstart
• Dauer des Ladens eines Demo-Projekts
• Dauer für Hinzufügen von einer gewissen Anzahl an Geräten
• Update-Rate bei paralleler Ansteuerung von verschiedener Anzahl an Geräten (z.B. 10, 50, 100, 500)
• Update-Rate von mehreren Mastern

etc. Diese Liste ist erst einmal zum Brainstorming gedacht und ist weder vollständig noch voll durchdacht, ob ein Punkt wirklich sinnvoll ist. Aber mal so als Idee. Das Ganze kam mir auch vor allem vor dem Hintergrund, dass fast alle modernen Spiele mittlerweile einen solchen Test eingebaut haben.

Ergänzend zum Benchmark entsprechend FS#5250 wäre es interessant, ein paar Zahlen, Daten, Fakten zu dem aktuellen Projekt aufrufen zu können - sprich Statistik. Dazu könnte unter anderem aufgeführt werden die Anzahl

• Devices
• Device Groups
• Cues
• Presets
• Cuelists
• Cuelist Groups
• Master (ggf. auch unterteilt nach den Typen)
• Executoren (ggf. belegt und unbelegt)
• Bänke im Input Assignment (ggf. aktiv und inaktiv)
• Graphen (ggf. aktiv und inaktiv)
• Timecodeshows
• …

Teilweise sind diese Zahlen ja bereits bekannt und können beim Laden des Projekts beobachtet werden. Allerdings laufen die wiederum zu schnell durch als dass man sie sich notieren könnte. Daher wäre ein entsprechendes Infofenster nett.

Hallo,
beim testen einiger Funktionen der 3.3.0 RC1 ist mir folgendes aufgefallen:
Wenn ich ein neues Projekt anlegen möchte, springt der Curser in die Zeile Name und ich kann dort einen Name eingeben.
Der dort voreingestellte Name (New Project) wird aber nicht automatisch gelöscht.
Diesen muss ich händisch noch löschen.

Erwartetes Verhalten

Error Description

Expected behavior

Notes

Fehlerbeschreibung

lch fände es gut wenn eine Möglichkeit implementiert werden würde (Node oder ähnliches) mit der es möglich wird über das Input Assignment zwischen Soft-Desks umzuschalten.
Dann könnte man mit Buttons im Softdesk, über DMX-In, Midi-In, wegen bestimmten Bedingungen usw. zwischen den angelegten Soft-Desks umschalten.

lch fände es gut wenn eine Möglichkeit implementiert werden würde (Node oder ähnliches) mit der es möglich wird über das Input Assignment zwischen Stage Views umzuschalten.
Dann könnte man mit Buttons im Softdesk, über DMX-In, Midi-In, wegen bestimmten Bedingungen usw. zwischen den angelegten Stage Views umschalten.

3.3 RC2

Fehlemreldung im Kernel und keine Reaktion mehr von DMXC nachdem Cue 19 in den Programmer geladen wurde und anschließen gereplacet wurde.

Kernel ließ sich mit den Befehlen nicht schließen - auch nicht nach einem von JP angeregten Rechtsklick - und wurde dann via Task Maneger hart beendet.

Logs und Projekt im Anhang.
0.2.61 = letztes gespeichertes Projekt, lässt sich aber nicht mehr laden
0.2.60 = letzter Stand vor Fehler

Wunsch: Fanning Operatoren in Release-Time von Cuelists nutzen.

Will ich z.B. einen Sweep bauen, dessen delay time der cuelist z.b. 0<>200ms ist und will nun, dass diese auch genau so wieder ausgehen, muss ich das Tracking der Cuelist deaktivieren, eine zweite dummy cue erstellen die leer ist und dieser wieder eine delay time von 0<>200ms geben. Die Möglichkeit Fanning Operatoren in der Release Time zu nutzen würde hier vieles verinfachen und viel Arbeit sparen.

Wunsch: Parameter-/Speed-Master in Release Time von cuelists ermöglichen.

Hallo,
Ich habe etwas mit der 3.3.0 RC 2 getestet.
Unter anderem auch mit dem neuen Timer Node.
Dieser ist wirklich gut geworden.
Er vereinfacht und reduziert einiges an Aufwand.

Was mich daran nur etwas stört ist:
Das wenn ich den Timer Modus verwende er mit Low 0 anfängt.

Ich habe ihn z. B. Verwendet um ein Signal Lamp blinken zu lassen. Enable ich den Node ist die Leuchte erst Dunkel und geht erst nach der eingestellten Zeit an und blinkt.
Schöner wäre es wenn der Ausgang sofort nach dem Enable auf High gesetzt wird, auch der Ausgang sofort auf High geht und dann weiter blinkt.

Man hätte bei einer Änderung sofort eine sichtbare Ausgabe und das nicht erst nach der eingestellten Zeit.

Gruß Steff

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise