Bugtracker DMXControl 3

s.o.

Da das kleine Tool durchaus öfters zum Einsatz kommt und ja sowohl für das DE- als auch für das Nodle-Interface funktioniert, dürfte es meiner Meinung nach hilfreich sein, wenn der Installer eine entsprechende Verknüpfung im Startmenü hinzufügt.

Getestet mit Build 1402

Der Installer legt aktuell noch nicht die Verknüpfung im Startmenü zu den eigenen DDFs an.

Ich habe mittlerweile DMXControl 3.2 und DMXControl 3.1.3 auf dem gleichen PC, aber in getrennten Verzeichnissen installiert. Bei der Installation hat der Installer nun aber den Pfad im Registry-Eintrag für DMXControl 3 geändert, sodass ich DMXControl 3.1.3 nicht im No-Network-Modus starten kann. Hier wird nun der Kernel der 3.2 aufgerufen. Starte ich GUI und Kernel getrennt, klappt aber alles.

Im Zuge des anstehenden Beta-Tests schlage ich daher vor, bei der Installation von DMXControl 3.2 einen neuen Registry-Eintrag anzulegen, um beide Version auf dem gleichen PC noch weiter voneinander “zu trennen”. Ich könnte mir hier auch vorstellen, dass es bei einer späteren Deinstallation von DMXControl 3.1.3 Probleme entstehen, sondern der Uninstaller auf die entsprechenden Einträge zurückgreift.

#19 EasyView Geräte übergeben/bekommen

Laut API-Beschreibung der (schon wieder überholten BETA (Dec 2012) kann man EasyView Geräte übergeben/bekommen. Ist das nützlich? Oder geht das nur in der Vollversion?

MIDI-Plugin aus GitHub abhohlen und gegen 3.1.x Bauen und mit ausliefern

Bei dem PlugIn MidiOutput fehlen die Dll dateien midiplugin.dll und midiplugin.rules.dll deshalb kann ich es nicht installieren

Moving Heads und anderes Bewegtes Licht mit Joystick steuern.

Da es scheinbar immer aus verschiedenen Gründen wieder Probleme gibt, Plugins nachzuinstallieren, schlage ich vor, einen kleine Installerfunktion im Pluginmanager zu integrieren, die wie folgt arbeitet:

1. Alle Plugins erhalten entweder eine Hilfsdatei mit Verzeichnisangaben für die Daten oder vorgeschriebene Verzeichnisse, in denen die erforderlichen Daten ablegt werden müssen.
2. Der User lädt das entsprechende Plugin als ZIP-Archiv herunter.
3. Der Plugin-Manager erhält einen zusätzlichen Button mit den Namen “Add plugin”
4. Der User wählt das Plugin aus dem Dateisystem aus und bestätigt die Auswahl.
5. Die Installerfunktion verschiebt die Daten des Plugins in die richtigen Verzeichnisse.
6. Nach dem “Installationsvorgang” fordert DMXControl 3 den User zum Neustart der Software auf.
7. Nach dem Neustart ist das installierte Plugin automatisch aktiviert.

⇒ Plugins werden aus Sicherheitsgründen nicht über DMXControl selber installiert, sondern über ein separates Programm

Das Plugin übernimmt nicht die Werte aus dem Programmer, hat man als erstes eine Auswahl von Geräten positioniert, verändert die Position eines einzelnes Geräts dieser Auswahl und wählt dann wieder die ursprünglichen Geräte wieder erneut aus. Der Programmer wird bei der Position auf den Wert 0 zurückgesetzt.

Für genaue Fehlerbeschreibung siehe Thread Pan/Tilt Ausgangsposition verändern im Forum.

Manuelles Überfaden in Szenenliste einbauen über InputLayer Regler

Werte von Effekten faden (anstelle des Effektwertes).

Dadurch wären z.B. “Beschleunigungen” möglich.

Frage: Wie wird entschieden, wann der Effekt als ganzes und wann die Parameter gefaded werden.

Ich würde mir beim Chaser noch folgende Features wünschen:
1. Auswahl wie lange eine “Scene” gehalten wird
2. Ein/Ausfadezeit einstellbar
3. Größe des Chasers z.B. 1er, 2er, 3er etc.
4. beim Zufalls Modus einstellbar wieviele Geräte min und max an sind.
5. anstatt Duration bzw zusätzlich eine Triggerzeit z.b. 3000, dann würde alle 3Sek ein Schritt weitergeschaltet der Schritt sollte schon weiterschalten unabhängig, ob die Haltzeit + Ein und Ausblendzeit des vorherigen Schrittes abgelaufen ist.

Ein Kontextmenu für die Windows wie “Project Explorer”,”Channel Overview” usw. erstellen um diese mit “Rechtsklick”→“Schließen” auf deren Reiter schließen zu können.

So würde ich mir die Funktion vorstellen

Grob gesagt, linkto gibt an, an welche Stelle gesprungen werden soll und loopcount gibt an, wie oft das passieren soll (0 = infinite)

id    | trigger | value | linkto | loopcount

Cue 1 | manual  |       |        |
Cue 2 | manual  |       |        |
Cue 3 | follow  | 1     |        |
Cue 4 | follow  | 1     |        |
Cue 5 | follow  | 1     |        |
Cue 6 | follow  | 1     | Cue 3  | 0
Cue 7 | manual  |       |        |

1. Go, Cue 1 wird eingeblendet
2. Go, Cue 2 wird eingeblendet
3. Go, Cue 3 wird eingeblendet.
Durch den Trigger follow läuft die Liste automatisch weiter (natürlich kann auch manual, oder ... benutzt werden) nachdem Cue 6 eingeblendet wurde, wird wieder Cue 3 eingeblendet. Ist loopcount > 1 wird der Sprung entsprechend oft ausgeführt.
Bei 0 passiert das unendlich oft. Dann könnte man zwei Fälle unterscheiden:
Alle Cues haben einen automatischen Trigger: GO beendet den Loop und blendet das erste Cue nach dem LinkTo Cue ein
Nicht alle Cues haben einen automatischen Trigger: Da GO bereits verwendet wird um im Loop die Cues durchzufahren könnte z.B. Load Cue 7, GO den Loop beenden.

Die Funktion ist sehr sehr praktisch, wenn auf der Bühne etwas gleiches wiederholt wird. Man hat hier weiterhin die Kontrolle mit GO bzw. (später dann hoffentlich Crossfade ;) ) sowie die gleiche Struktur wie andere Cues.
Außerdem ist man mit dieser Funktion schneller bei einfachen Chasern. Wenn ich weiß, dass die 6er Bar nur kurz während einer Szene ein bisschen blinken soll, muss ich nicht extra einen Chaser dafür anlegen und in die Cuelist einbinden.

Auf FS#280 setz ich noch einen drauf:

Split Crossfade.
Das sind zwei Überblendsteller. Einer zusändig für das aktuell eingeblendete Cue (ich nenns jetzt mal stage) und der zweite für das nächste (preset).

Normalstellung ist Stage 100, Preset 0.
Werden nun beide Steller gleichzeitig bewegt, ergänzen sich beide zu 100%. Es kommt ein ganz normaler Crossfade zu stande. Stage 80% + Preset 20%
Werden diese nun unterschiedlich schnell bewegt, kann z.B. ein Blackout realisiert werden. Stage 0%, Preset 0%

Kreise, die in Preset aber nicht in Stage enthalten sind werden vom PresetSteller ganz normal eingeblendet (Preset 50%, Kreise 50%)
Kreise, die in Stage aber nicht in Preset enthalten sind werden vom StageSteller ausgeblendet.

Eine Überblendung ist abgeschlossen, wenn Stage 0% und Preset 100% sind.

Es sollte eine Taste geben z.B. Ignore (allgemein benannt, hab noch ne Funktion dafür :) ), die beim nächsten GO die Cuelist veranlasst, nicht einen Schritt weiterzugehen, sondern eine evtl. laufenden Timer, Follow/Wait zu ignorieren und mit dem Einblenden des nächsten Cues zu beginnen. (Usecase: Probe, Zeit zu lang, etc...)

Arne:
=⇒ Eine funktion, welche bei der Cue die aktuell einfaded den Fade auf 100% setzt. Der Rest läuft normal ab.

Es sollte die Möglichkeit geben (wenn Cossfade funktioniert), dass sowohl

-ein mit GO begonnener Fade mit dem/den Crossfader(n) fortgesetzt werden kann/können (damit das nicht versehentlich, z.B. durch berühren der Fader passieren kann, muss vorher die in FS#490 erwähnte Ignore Taste gedrückt werden. Die Fader übernehmen ab dem Punkt, an dem sie den aktuellen Einblendstatus erreicht haben, Fade 40%, Fader übernehmen ab 40% Stellung),

-als auch ein manuell begonnener Crossfade mit GO fortgesetzt werden kann.

Es wäre schön, wenn man für eine komplette Cueliste das Timing + die Trigger abschalten und danach mit GO durchlaufen könnte.
Dafür sollte eine konfigurierbare standard Fade Zeit zwischen den Cues verwendet werden (Scheinwerfer schonen)

Weis nicht ob das jetzt überflüssig ist aber ich würd gerne auf das Brainstorming:Gerätefunktionen.
Wäre echt geil wenn dasd alles balt gehen würde.

Export and import App Settings as zip archive. (backup)

Es sollte die Möglichkeit geben einen Wert einer Eigenschaft, z.B. Intensität von Kreis 1 in allen ausgewählten Cues zu ändern. Die solte bedingt erfolgen: Replace Where Value = 80 With 60, oder so.

Es sollte die Möglichkeit geben Command Cues einzufügen.
Diese sind in der Lage, hinterlegte Befehle auszuführen.
z.B. MIDI → SEND GO, etc.
Cuelist xyz → GO
vergleichbar mit Befehlen in der 2.x und Makros auf Konsolen.

Könnte man doch über den Input Layer lösen?

Cue blind editieren, sollte schon gehen.
Inhalte direkt im Programmer editieren.

Will ich ein Default Projekt hinterlegen, wo z.B. nur ein Patch hinterlegt ist, aber alles andere soll neu Initialisert werden (z.B. Einstellungen), muss ich die Dateien von Hand aus dem Projektarchiv löschen.

Man hat die Möglichkeit Gruppen erneut zu gruppieren.
Die Tiefe ist auf 2 Gruppen begrenzt. Gruppe - Gruppe - Gerät
Auf diese oberste Gruppe koennen auch Effekte gelegt werden.
Ist ein Gerät in mehreren Gruppen, werden nur die Werte aus der ersten Gruppe verwendet.

Ich bin mir gerade nicht sicher, ob das ein Thema für die virtuellen Master ist, oder ob da was anderes sinnvoller wäre.

Folgendes Szenario:
Manuelles Flackern mit einer Farbrampe. Nach einiger Zeit Zurücknehmen und Ausblenden der Intensität aller Kammern.

Die angedachte Lösung wäre also: Die Apprate auf Submaster legen und einen virtuellen Master über entweder die Submaster oder die Apprate an sich zu legen.

s.o.

s.o.

Scheinbar haben Geräte auch logarithmische Funktionen. Siehe  FS#720  Goborotation, ...
Es würde m.M. nach reichen, wenn man dann die Fader Controls auf log umstellt.

Das Control ist viel zu ungenau. (Auch mit ALT gedrückt)
Geraten: bei 540° ist der kleinste Schritt 5.4°?
Wir müssten idealerweise eine Schrittweite erreichen, die zu einer veränderung des LSB von 1 führt (0.00824° in diesem Beispiel)

Folgendes Szenario:

In Cue 4 wir MH 1 auf Position 1 gefahren.
Nun soll die Position ab dort per Hand verändert werden (relatives Eingabegerät wie Trackball oder Encoder)
Ab Cue 10 soll die Cueliste wieder die Kontrolle über die Positionseigenschaft haben. Allerdings ausgehend von der per Hand eingestellten Position

Gemäß Diskussion:

(vorerst)
Zuletzt gespeichertes Projekt wird für Kernel zugreifbar gespeichert.
Option: einstellbar, ob vor dem Beenden des Kernels nochmal der aktuelle Stand gespeichert werden soll.
Option: dieses Projekt automatisch beim Start wieder zu laden.

Weiterhin beliebiges Projekt per Startparameter.
=⇒ AL: Started

EDIT/ERGÄNZUNG MARCEL 27.11.2018:

Ich habe zu dem ganzen Projekthandling folgende Idee wie man das Konzept mMn besser gestalten koennte.
DMXC3 wurde als Client/Server konzipiert und ist mMn ein wichtiges Feature, wenn auch (noch) wenig genutzt.

Aktuell wird beim Speichern immer dort eine Kopie erstellt, an deren Ort das Speichern ausgelösst wird. Angenommen wir haben 1 Server und 2 GUIs/Clients:

Client 1 speichert bei sich aus der GUI heraus. Client 2 arbeitet weiter, Client 1 lädt wieder und überschreibt alle Änderungen von Client 2. Und das ohne Rückfrage → Doof

Besser sollte es so sein:

“Projekt speichern” ist bei jedem Client nur noch ein Remote-Befehl an den Server das dieser bei sich in seinem Workdir das Projekt speichern soll.
Ebenso “Projekt laden” öffnet eine Liste und zeigt die auf dem Server abgelegten Projekte an, welche dann auf dem Server geladen werden können.

Neu hinzukommen sollten zwei Einträge:
“Projekt Downloaden/Exportieren” → Packt das Projekt in aktuellem Zustand als ZIP auf dem Server und schickt es an den entsprechenden Client zum runter laden.
“Projekt Hochladen/Importieren” → Lädt ein ZIP und transferiert es auf den Server in das Workdir und macht es somit in der “Remoteliste” zum öffnen verfügbar.

In diesem Zuge kann man darüber nachdenken auf dem Server nicht mehr als ZIP zu speichern und jedes Projekt optional sogar in ein lokales GIT oder ähnlich zu packen. Dann hat man sogar eine Versionierung.

MIDI Timecode

MIDI Show Control

Hy,

Folgende Settings werden noch benötigt:

1. STRG Funktion beim Speichern von Scenen / Presets =⇒ Ist Filter anzeigen Default Ja / Nein
2. STRG bei Presets Drag & Drop =⇒ Wird das Preset nur auf die gespeicherten Geräte angewendet oder auf alle
3. done — Programmer Priorität einstellbar machen =⇒ (Programmer.cs –> CreateNewRegister() –> Priorität entweder “DMXCMixer.EMixerPriorityDefaults.NORMAL” oder “DMXCMixer.EMixerPriorityDefaults.PROGRAMMER”

Weiter ergänzen

Gruß Arne

Es wird immernoch nicht der Node für Random in Gobowheel und Colorwheel gelesen bzw. wird nich angezeigt und kann deshalb nicht drauf zugreifen.

MfG
Patrick

Es sollte die Möglichkeit geben einen Executor global zu schalten. (Bleibt für jede Seite gleich)

Die BringToFront Funktion sollte fadebar sein.
FadeFactor pro Property (mal wieder)

eine skriptengine wäre wünschenswert mit der es möglich ist cuelisten zu starten und zu stoppen sowie auf andere programmfunktionen zuzugreifen.
das würde die möglichkeiten die mit midi gegeben sind um ein vielfaches erweitern

hier ein kleines beispiel:
skript triggert bei midi note events
skript prüft midi kanal
prüft dann controler der gesendet hat
prüft value (bei wert >=1 (also gedrückter taste) cue starten, bei 0 (also loslassen der taste cue stoppen)

für dieses einfache szenario reichen die möglichkeiten bereits aus, jedoch lassen sich damit wesentlich komplexere strukturen bauen wie beispielsweise toggles die von anderen tasten abhängen usw sowie die möglichkeit basierend auf encoderstellungen verschiedene aktionen auszuführen (zb umschalten von verschiedenen nebelerzeugern bei verschiedenen intensitäten)

Um eine beatgesteuerte Cue-List zu bauen muss als Trigger “beat” ausgewählt werden. Soweit so gut.
An der Stelle sollte aber bei der Einstellerei schon Schluß sein. Leider muss man über “Application Settings” > “Input Assignment” erst noch weitere Einstellungen vornehmen.

Vielleicht gibt es ja die Möglichkeit der Cue-List mit der Zuweisung des Triggers “beat” zu sagen ‘nimm den Beat aus dem “Manuell Beat”-Panel’ und fertig.

Das erspart zumindest weitere Klickerei. Wäre das eine Idee?

MfG
Jelu

Hy,

es fehlt irgendwie der Restart-Befehl im Kernel.

Das wäre sehr hilfreich, fals der Kern irgendwie hängt, oder überladen ist.

Einfach “restart” eingeben und enter, und schon wird der Kernel runtergefahren, neugestartet und das Projekt wieder automatisch geladen.

Das ist viel einfacher als den Kernel Runterfahren zu müssen, ihn alleine wieder zu starten und dann noch das zu ladene project eingeben zu müssen.

Würde mich freuen, wenn ihr das einbaut.

Ich brauche klassische Submaster.

Ein Submaster ist ein Element mit einem Steller, einem Select Button und einem Flashbutton.

Auf einem Submaster kann genau ein Cue oder Preset liegt.

Es kann x Submaster geben, deren Ausgabe LTP, bzw. bei Intensitäten HTP oder LTP gemixt wird.

Es gibt y Pages mit Submastern.

Weiterhin möchte ich den Inhalt eines Submasters direkt editieren können. z.B. Select → Cue/Preset wird in den Programmer geladen, Änderungen machen, Record, Record → speichert.
Ich möchte Fade Zeiten direkt ändern können. Select, UpTime 10 DownTime 5 Record Record

Der Steller kontrolliert je nach Einstellung die Intensitäten oder die gesamte Cue (Intensity Master, Proportional, etc.)

Der Flash Button kann unter anderem die Intensität flashen, oder es können nicht Intensitätswerte auf die im Cue gespeicherten Werte gebracht werden.

tbc.

Vorerst nur als Eingabe (Steuerung von DMXControl über MIDI)

Inputs können mit den Steuerelementen verbunden werden, indem das Steuerelement ausgewählt und der Eingabewert des Inputs verändert wird.

Neben dem Grandmaster wird es einen Speed (Effektgeschwindigkeit) und einen Timingmaster (Fade/Delay Zeiten) geben.

Es wird für den Anfang einen rumimentären Audioplayer geben. Dieser wird dann sukzessive weiter ausgebaut.

Es wäre cool, wenn ihr Globale Buttons einbauen würdet.
Für den anfang wären die Buttons:
GO+
GO-
ON
OFF
Pause
Select
,ausreichend.

Und zwar stelle ich mir vor, dass wenn ich auf einen dieser Buttons drücke und in folge dessen auf einen Executor klicke(egal welcher seiner Buttons) wird seine Funktion ausgeführt.
Das sollte dann auch DURCH das Input-Assingment funktionieren.
sprich ich kann die Buttons per Input-Assingment drücken, und wenn ich dann z.B. auf dem Pult den Button vom Executor1 mit der funktion Flash drücke, wird nicht geflascht, sondern dir funktion des zuvor gedrückten globalen Buttons ausfgeführt (z.B. GO-)

Von der GrandMA kenne ich es so, dass ein Executor-Fader auch die Intensität der Bewegung beeinflussen kann. Also analog zu dem, was bereits beim Einfaden der Intensität einer Cueliste mit den Bewegungen passiert, also dass diese eben nicht sofort bei 100% anfangen wie wild durch den Raum zu zuckeln, sondern entsprechend gedämpft/beschränkt sind.
Es wäre super, wenn dieses Verhalten optional auch auf den Executor-Fader einstellbar wäre.

Hab beim Jahrestreffen vergessen was anzusprechen, und zwar den Single Flash bei Strobes.

Ich fänds gut, wann mann den auch ordentlich Visualisiert in der LiveView einbauen würde.

Am beispiel von Henne’s Strobo Mod.