Bugtracker DMXControl 3

  • Status Closed
  • Percent Complete
    100%
  • Task Type Wunsch / Idee
  • Category GUI & Server
  • Assigned To
    Patrick Grote
  • Operating System All
  • Severity Low
  • Priority Medium
  • Reported Version 3.2
  • Due in Version 3.2.1
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: DMXControl 3
Opened by Patrick Grote - 21.10.2019
Last edited by Patrick Grote - 21.10.2019

FS#3885 - ParameterMaster/SpeedMaster Faktoren

Folgendes sollte möglich sein:
{SpeedMaster 1:/4} SpeedMaster 1 Double-Values und Beat-TImer durch 4
{SpeedMaster 1:*4} -…- mal 4
{SpeedMaster 1:/3} -…- durch 3
{SpeedMaster 1:*5} -…- mal 5
{SpeedMaster 1:/8.5} -…- durch 8.5

Edit:

{SpeedMaster 1:*COUNT} -…- mal Anzahl der Geräte laut GroupHandling
{SpeedMaster 1:/COUNT} -…- durch Anzahl der Geräte laut GroupHandling
{SpeedMaster 1:*FANNING}
{SpeedMaster 1:/FANNING} … {SpeedMaster 1:/FANNING*2} … {SpeedMaster 1:/FANNING*COUNT} …

copy paste bei ParameterMastern

Closed by  Patrick Grote
21.10.2019 19:04
Reason for closing:  Implementiert
Additional comments about closing:  

Aber ohne FANNING Variable

Admin
Jens-Peter Kühn commented on 21.10.2019 14:57

Das hier soll ja das Problem beheben, dass wenn man einen Effekt auf eine Gruppe legt und diesen fanned, dass man dann die Geschwindigkeit des Speedmasters durch die Anzahl der Geräte teilen muss, um eine Weiterschaltung mit den angegebenen BPM zu erreichen. An sich finde ich eine Rechenmöglichkeit wichtig, weil man so mehrere Effekte mit unterschiedlicher Geschwindigkeit auf den gleichen Speedmaster synchronisieren kann. Zusätzlich würde ich aber mal fragen, ob man nicht auch das grundlegende Problem angehen müsste. Es wurde ja beschlossen, dass die Geschwindigkeit eines Effekts gleich bleibt, unabhängig davon, ob sich die Gruppengröße ändert. Aber vielleicht muss man das nochmal unter diesem neuen Hintergrund der Speedmaster/Parametermaster bewerten und einen bool-Parameter "Device is Step" (wie man das auch immer benennt) in den Effekten einfügen, mit dem man zwischen dem bisherigen Verhalten und dem Verhalten "BPM/Frequency definiert Zeit zwischen zwei Geräten in einer Gruppe" umschalten kann. Ich weiß natürlich nicht, wie viel Aufwand dieser Vorschlag ist und vielleicht zu viel. Das kann ich aber natürlich nicht entscheiden.
Viele Grüße
JP

Project Manager
Patrick Grote commented on 21.10.2019 15:07

Nein…..
Nein…..
Das kommt daher, das hier alle nur licht in irgendwelchen Clubs, oder ähnlichem machen.
Leute die eine Show für eine Tour einer Band oder so programmieren, sind damit so zufrieden wie es ist.

grrrr.

Joseph Noetzel commented on 21.10.2019 17:00

@Patrick: nöö…

Dmx Control nimmt mir alles mögliche aus der Hand. DMX Werte egal, Hat das Teil nen Dümmer Kanal egal… Warum macht man das bei mal Effekt jetzt so "kompliziert". Du hast jetzt eine Mathematische Herangehensweise gewählt. ist nicht schlecht, könnte aber für den User einfacher sein…

mit deiner Version, müsste man immer wenn neue Geräte zur Gruppe hinzugefügt werden, der Faktor neu angepasst werden. kommt natürlich aufs Fanning an…

Project Manager
Patrick Grote commented on 21.10.2019 17:16

WAS WOLLT IHR!

Joseph Noetzel commented on 21.10.2019 17:43

ok nehmen wir uns mal den Chaser Effekt heraus.
Ich habe einen Gruppe mit 4 Geräten und eine Gruppe mit 6 Geräten. Wenn ich auf beide Gruppen den gleichen Speedmaster packe, ist die Gruppe mit den 6 Geräten triolisch zu der 4er Gruppe.

Hier wäre es natürlich ein Traum, wenn die gleich Synchron wären.

Soll ja nur nen Ansatz sein was ich mir dabei wünschen würde. Wenn DMXC automatisch nen Faktor ermittelt hätte ich z.b. auch kein Problem damit.

Joseph Noetzel commented on 21.10.2019 17:44

oder meinst du das mit Fanning Count???

Project Manager
Patrick Grote commented on 21.10.2019 17:54

COUNT= Geräte oder Gruppenanzahl, abhängig vom Grouphandling
FANNING= bsp. 0#180#270 → 3 0'180 → 2 bei 10 geräten mit 0<180 →10

Ein Chaser hat als Zeitangabe ms alles mit ms arbeitet in einzelschtirren
Sinus z.b. arbeitet mit frequenz

Wenn ich das selbe mit sinus mache, das du mit Chaser gemacht habe, ist das ergebniss, das beide Gruppen synchron laufen.

Stefan Kistner commented on 21.10.2019 18:00

Kann man die Speed- und Parametermaster nicht wie einen "Effekt" handhaben und diesen dann auf die entsprechenden Parameter des eigentlichen Effekts ziehen, quasi als "Subeffekt"? (Wenn es nicht verständlich ist, baue ich gerne auch mal was zusammen.)

Diese "Subeffekte" bekommen dann wie die normalen Effekte und Filter auch alle möglichen Parameter mit an die Hand. Die Zuordnung des gewünschten Masters könnte dann auch mittels eines Dropdownmenüs erfolgen. Vielleicht erreichen wir hier so dann eine konsistente Bedienung, ohne den Syntax "aufzubauschen" und können bei Bedarf beliebig weitere Parameter hinzufügen.

Project Manager
Patrick Grote commented on 21.10.2019 18:00

Und der 3.
Müssen hier gleich alle reingrätschen?

Stefan Kistner commented on 21.10.2019 19:00

Mit meinem Einmischen hatte ich nicht die Absicht, die Funktion schlecht zu reden, sondern wollte mit meinem Kommentar darauf abzielen, die schöne Funktion mit etwas weniger benötigten Hintergrundwissen hierzu mehr Leuten einfacher zugänglich zu machen.

Project Manager
Arne Lüdtke commented on 21.10.2019 19:52

Dieses Thema ist für mich ein Paradebeispiel, dass wir einen Modus schaffen müssen in dem ein Entwickler einfach mal ein Ticket anlegen kann, ohne dass es gleich von allen Kommentiert wird, sondern man sich über das Ergebnis unterhält und dann über Mögliche Verbesserungen spricht. Es ist stark unbefriedigend (und ihr könnt das sicher auch in Patricks posts lesen) wenn Instant Feedback kommt ohne das man fertig ist.

Das ist wie wenn alle nach den ersten 2 Sätzen einer News schon drauf los schrieben würden "Unvollständig, Unverständlich, Es muss noch XYZ rein,….". Ja, es muss ein Review statt finden aber wir haben uns drauf geeinigt das der Entwickler den Zeitpunkt bestimmt, und ob man besser mal eine 1. Implementierung macht oder auf Konzeptebene diskuttiert. Was in die Finale Software kommt oder ob das Feature nochmal angepasst wird wird im QRM besprochen.

Patrick Meyer commented on 03.01.2020 20:07

Getestet in der Beta2:
{Parametermaster 1:*0.2}
dann gibt es folgenden Eintrag im DevControl:

Der Typ "org.dmxc.lumos.Kernel.Scene.Fanning.StaticFannedValue" in Assembly "Lumos, Version=3.2.576.1, Culture=neutral, PublicKeyToken=null" ist nicht als serialisierbar gekennzeichnet.

Außerdem folgenden Kernel-Eintrag:

21:04:59 ERROR IPropertyValue -
org.dmxc.lumos.Kernel.Exceptions.WrongValueTypeException: Value is no Double Value: String

 bei org.dmxc.lumos.Kernel.PropertyType.DoubleType`1.set_Value(Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyType\DoubleType.cs:Zeile 57.
 bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.set_Value(Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 150.
Project Manager
Patrick Grote commented on 03.01.2020 20:21

Etwas genauer beschreiben bitte, bei mit geht es

Patrick Meyer commented on 03.01.2020 20:42

Hab nen Video gemacht

Project Manager
Patrick Grote commented on 03.01.2020 20:53

Kanns trotsdem nicht reproduzieren

Joseph Noetzel commented on 03.01.2020 21:54

Das passiert bei mir, wenn ich {Parametermaster 1:*0.2} unter Dimmer eingebe:

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing