Softdesk-Slider reagiert nicht auf Input

Hi Sansibar,

Ein ähnliches Probem hatte ich auch schon: Strobe-nicht verwendbar.

bau doch mal einen Format-Node zwischen Programmer (Intensität) und dem Slider. In dem Format-Node gibst du nur {0} an und nutzt dementsprechend nur den ersten Eingang. Dann kommt auch was auf dem Softdesk an (zumindest bei mir).

Wenn du PassThrough an hast entsteht eine Schleife. Du änderst den Wert, der Wert wird an den Slider zurückgegeben, und dann sendet dieser den Wert wieder. Das hört nur auf, da der Wert sich ja nicht ändert und somit LTP nicht reagiert. (Wenn ich falsch liege, bitte korrigiert mich)

Beste Grüße, Ludwig

Hallo Sascha,

Bei dem Strobel ist es wohl so, dass der Programmer/DMXCMixer ein Objekt übergeben will und das nicht alle lesen können. Der Format-Node nimmt dann einfach den Text und gibt den weiter, was dann auch das Output-Node versteht. Ich denke ähnlich ist das auch mit der Intensität. Ich hab das noch nicht weiter untersucht, aber könnte auch sowas sein wie: ist das dezimaltrennzeichen ein punkt oder Komma?

Beste Grüße, Ludwig

Hallo,

Quote from sansibar24

Ich habe deinen Thread zum Strobe zwar gesehen, aber weil ich die Lösung nicht ganz verstanden habe, dann ausser Acht gelassen...

Und ich muss ehrlich sagen, dass ich die Lösung immer noch nicht ganz verstehe. Sieht für mich eher aus, wie ein Workaround für einen Bug...

Die Format-Node gibt ja genau dieselben Werte aus, die sie reinbekommt und die der Slider ohne Format-Node auch schon bekommen hat.

Aber was solls, Hauptsache es funktioniert.

ich habe mir das mal angesehen und tatsächlich ist das kein direkter Bug, aber eine Unvollständigkeit. Um zu verstehen, warum das so ist, hier einmal ein paar Hintergründe dazu. Das Input Assignment kann mit vielen verschiedenen Inputs umgehen und diese an irgendwelche Informationssenken (also Komponenten von DMXControl 3 oder auch externe Geräte, die dann damit weiterarbeiten) weiterleiten. Dabei steht man fast unweigerlich vor dem Problem der Datentypen. Jeder Wert in einer Software ist von einem gewissen Datentyp. Standard-Datentypen sind z.B. Integer (ganze Zahlen), Float (Kommazahlen), String (eine Zeichenkette), Binär (Ja oder Nein) und noch ein paar Abwandlungen davon. Warum gibt es da jetzt unterschiedliche Typen? Naja, weil jeder Typ seine eigenen Eigenschaften hat. Z.B. kann man mit Variablen des Typs Integer oder Float rechnen, was mit Strings nicht funktioniert. Integer und Float werden unterschieden, weil man manchmal gar nicht will, dass man Kommawerte zulässt. Es gibt eben z.B. bei Listen immer nur eine ganze Zahl an Einträgen, "..,7" Einträge gibt es nicht. Nun kommt es aber leider immer mal wieder z.B. vor, dass man auch mit einem Wert rechnen will, den man nur als String vorliegen hat. Dann muss man ihn erst in einen Integer oder Float konvertieren. Zum Glück gibt es bei den Standarddatentypen schon einige Konvertierungsfunktionen, die z.B. aus einer Zeichenfolge versuchen, eine Zahl zu machen. Ein anderes Problem könnte auftreten, wenn man intelligentere Datentypen braucht, die mehr als nur einen einzigen Wert speichern. Beispiele hierfür sind etwa die Maus-Position, die eine X- und eine Y-Komponente besitzt. Hiermit kann ich jetzt nicht direkt rechnen, sondern ich muss wissen, wie das Mausobjekt aufgebaut ist und kann dann z.B. nur mit der X- oder Y-Komponente alleine rechnen.

Bei vielen der Werte im Programmer haben wir auch keine Standarddatentypen. Stattdessen ist dieser häufiger mal ein eigens für DMXControl 3 geschriebener Datentyp. Im konkreten Fall ist das einer, der deutlich intelligenter ist als die Standarddatentypen, denn dieser kann auch das Fanning sauber abbilden. Sprich man gibt in der Gerätesteuerung ein Fanning (als String ) ein und es geschieht dann eine Konvertierung, die z.B. alle wichtigen Werte des Fannings (die Zahlen, die man eingibt) herauszieht. Diese werden zusammen mit der Art des Fannings separat in dem Objekt gespeichert, damit andere Softwarekomponenten in DMXControl 3 einfach darauf zugreifen und damit rechnen können. Schlägt die Konvertierung an dieser Stelle fehl, dann meckert DMXControl 3 entsprechend in einem Popup.

Es fällt also eine Fanning-Variable bei dem Intensitätsausgang des Programmers heraus. Der Slider erwartet aber eigentlich eine Zahl (weil er ja auch wieder intern für die Darstellung rechnen muss). Nun gibt es im Input Assignment zwar schon sehr viele versteckte Konvertierungen. So macht es nämlich nichts aus, ob man einen String oder eine Zahl in den Slider schiebt. Dieser kommt mit beidem zurecht. Mit einer Fanningvariable weiß er aber halt leider doch nichts anzufangen. Daher reagiert er nicht darauf. Wenn man den Wert nun durch einen Format-Knoten schiebt, dann wird die Fanning-Variable in einen String konvertiert. Mit diesem weiß der Slider-Knoten aber wieder etwas anzufangen, konvertiert entsprechend und stellt den Wert dar. Das ist der Grund, warum die Werte zwar angezeigt werden (das Input Assignment kennt für die Darstellung auch die Konvertierung von der Fanningvariable in String), aber der Slider-Knoten damit nichts anfangen kann. Nun könnte man ja auf die Idee kommen, dass man nur einfach die Funktion des Format-Knotens in den Slider-Input einbauen muss und gut ist. Das klappt aber leider so nicht. Die von Scarffac3 gezeigte Lösung funktioniert nämlich nur solange, wie man nur einfache Werte im Gerätemanager verwendet. Sobald man ein Fanning eingibt, konvertiert der Format-Knoten zwar fleißig auch das in einen String. Nun kann der Slider daraus aber keinen Wert mehr herausziehen, denn nun stehen da mindestens zwei Zahlen, ganz zu schweigen von dem komischen Fanning-Operator Nun bleibt der Slider also wieder auf seinem alten Wert. Wenn das umgebaut werden soll, muss erst noch überlegt werden, was der Slider dann anzeigen soll (Mittelwert, alle Fanning-Parameter,...) und dann auch befähigt werden, das zu tun (z.B. kann er gerade nicht mehrere Werte gleichzeitig anzeigen).

Lange Rede kurzer Sinn, der Softdesk-Slider müsste erst entsprechend aufgebohrt werden, damit auch die Fanning-Variablen verwendet und dargestellt werden können. Das ist der Grund, warum eine direkte Verknüpfung (aktuell) nicht funktioniert.

Quote from Scarffac3

dass der Programmer/DMXCMixer ein Objekt

Das ist nicht ganz richtig Der DMXCMixer gibt nämlich keine gefannten Werte mehr aus, denn dies ist eine der Aufgaben des DMXCMixers Das kannst du ganz einfach probieren, indem du den Intensitätsausgang des DMXCMixers an den Slider hängst. Das zeigt der Slider ohne Probleme an. Allerdings kommt da dann eben zum Tragen, dass der Ausgang des DMXCMixers der endgültig für ein Gerät ausgerechnete Wert ist, also auch die Werte aller Cuelists etc. hier mit hinein spielen.

Ich hoffe, ich konnte die Problematik hinter dem Thema (mit dem zugegebenermaßen sehr langen Text) etwas beleuchten

Viele Grüße

JP