Problem mit IC Send Modulen

[herw]

Tja, herw - dann hast Du wohl den ursprünglichen Anlass dieses Threads fehlinterpretiert. Es geht hier nicht um Fehlverhalten von Eventschaltungen, sondern schlicht um Ausreisser bei der Verwendung von IC Sends zur Werteübermittlung. Dass beim Benutzen von Maus Areas die von Dir angedeuteten Probleme auftreten, ist mir bekannt. Dass der Wert von 0,53 bei 100 Steps Auflösung nicht eingestellt werden kann, auch. Nur: das ist in diesem Thread komplett irrelevant, denn auch wenn es neun Zustände bei 8 Steps gibt, so ist eine Mouseresolution von 9 genau der Fall, bei dem es zu dem von toxonic bemängelten Verhalten kommt.

richtig und das sollte meine Formel belegen.

In letzter Konsequenz liegt hier tatsächlich ein Bug vor: wenn nämlich (um bei Deinem Beispiel zu bleiben) tatsächlich erforderlich ist, den Wert 0,53 einstellen zu können und somit eine Maus-Auflösung von Steps+1 eingestellt werden muss, dann werden bei gleichzeitiger Verwendung eines IC Sends bestimmte Werte falsch übertragen.

ja, das ist richtig; d.h. man kommt in einen Konflikt, einerseits sollen mit der EventTable Werte angesteuert und per IC-send übermittelt werden, andererseits muss dann die Anzahl der Steps und die Mausauflösung übereinstimmen bzw. Vielfache voneinander sein. Andererseits passen dann die von Hand einzustellenden Werte des Reglers eventuell nicht zusammen - ja ich gebe zu, das ist nicht passend (ich sage mal nicht bug, sondern nicht richtig bedacht).
ok ich geb mich geschlagen

[tymes2]

...richtig und das sollte meine Formel belegen.

Ah, okay... das hab' ich da nicht so direkt rauslesen können. Aber schön dass wir mal drüber geredet haben ;o)

[herw]

... Aber schön dass wir mal drüber geredet haben ;o)

jo - und ich werde mir eine Lösung überlegen, so dass beides klappt. Dazu muss man aber wohl die bisherigen Regler über Bord werfen und eine MausArea und ein Multipicture benutzen. R6 wird ja sicherlich noch einige Zeit dauern.

[herw]

... und ich werde mir eine Lösung überlegen, so dass beides klappt. ...

oh nein - es ist SOOOO einfach, beides unter einen Hut zu bekommen:

nun kann man mit dem Regler jeden gewünschten Wert einstellen und gleichzeitig wird auch der korrekte Wert von der EventTable übertragen!
Würde man den Summand 0,5 weglassen, würde für die unteren 50 Werte der Regler auf eine falsche Stelle gestellt (um 1 zu niedrig). Die Problematik der Mausauflösung 100 haben wir oben schon erläutert.

ciao herw

[helmsklamm]

was wäre denn, wenn du beim table gleich die range auf 0.5 - 100.5 setzen würdest?

also ehrlich: wenn man zu derartigen konstrukten greifen muss, ist in den ganzen IC zeux irgendwas grundlegend falsch konzipiert. how!

[herw]

was wäre denn, wenn du beim table gleich die range auf 0.5 - 100.5 setzen würdest?

also ehrlich: wenn man zu derartigen konstrukten greifen muss, ist in den ganzen IC zeux irgendwas grundlegend falsch konzipiert. how!

gute Idee, muss ich mal ausprobieren; mit Deiner zweiten Bemerkung bin ich nur bedingt einverstanden, da ich REAKTOR über R2.3 R3, R4 und R5 kenne und es auch historisch sehe. Im Laufe der Zeit sammeln sich halt interne Inkompatilitäten an, die solche Konstrukte erfordern.
Man sollte sie im Forum immer wieder erwähnen, am besten in der Wunschliste, damit NI sie beseitigt.

[helmsklamm]

ich muss nochmal GRUNDLEGEND deiner these von mausreso +1 widersprechen. sie ist definitiv falsch! vielleicht stimmt sie bei werten <127 aber darüberhinaus eindeutig nicht!
gib mal bspw. 133 range und 134 maus ein und versuche mit den hoch/runter tatsen den bereich zu durchfahren: du wirst feststellen, das es irgendwann hakt und einfach nicht weitergeht. (das gleiche bei 133 für beide, oder 200/201 oder oder oder)

meiner erfahrung zufolge ist das einzige mittel ne range/reso die exakt ein vielfaches von 32 ist: bspw. 192, 256 oder 348...
und hierbei sollten range/maus übereinstimmen oder die maus ein vielfaches der range sein. nur dann funzt das anstandslos.

>folgt wiederum, das entweder das IC zeux bugy ist, oder deine argumentation/experimente fehlerhaft sind.

[herw]

ich muss nochmal GRUNDLEGEND deiner these von mausreso +1 widersprechen. sie ist definitiv falsch! vielleicht stimmt sie bei werten <127 aber darüberhinaus eindeutig nicht!
gib mal bspw. 133 range und 134 maus ein und versuche mit den hoch/runter tatsen den bereich zu durchfahren: du wirst feststellen, das es irgendwann hakt und einfach nicht weitergeht. (das gleiche bei 133 für beide, oder 200/201 oder oder oder)
meiner erfahrung zufolge ist das einzige mittel ne range/reso die exakt ein vielfaches von 32 ist: bspw. 192, 256 oder 348...
und hierbei sollten range/maus übereinstimmen oder die maus ein vielfaches der range sein. nur dann funzt das anstandslos.

>folgt wiederum, das entweder das IC zeux bugy ist, oder deine argumentation/experimente fehlerhaft sind.

tut mir leid das kann ich überhaupt nicht bestätigen; gerade dein Beispiel mit dem Rangebereich 133 offenbart und bestätigt meine These:
Das sollten wir jetzt hier ein für alle mal klären, sonst diskutieren wir ständig hin und her:
also folgende beiden Test-"ensembles"
A: B:
Ich teste auf einem Mac mit R5.1.2

Ensemble A:
Der Regler wird mit 0 beginnend und der Cursor-Auf-Taste deutlich einzeln drückend bewegt.
Dabei beobachte ich, dass die Cursortaste die Werte 5, 10, 20, 40, 80 und 107 jeweils um 1 zu niedrig anzeigt (du würdest sagen es hakt, in Wahrheit wird z.B. der Wert 9 zweimal angezeigt; einmal für die 9 und dann für die 10)
Ensemble B:
Jeder Cursor liefert genau den vorgesehenen Wert!

Ich beziehe mich in diesem Test ausschließlich auf das Verhalten des Reglers bei gleichen bzw. unterschiedlichen Einstellungen von Range und Mausauflösung, stepweite jeweils 1.

Übrigens was meinst Du mit ... hakt und "irgendwann nicht weitergeht"?

[helmsklamm]

ähm, sorry, ich hatte mich oben falsch ausgedrückt: ich hatte range und numsteps verwechselt - fataler fehler.

mach mal range 0-1 (die ja in der praxis wohl am häufigsten vorkommt) und belass den rest so. dann wirst du auch erfahren, was ich mit "hakt" meine und was ein deutlicher indikator dafür ist, das irgendwas nicht stimmt.

[herw]

ähm, sorry, ich hatte mich oben falsch ausgedrückt: ich hatte range und numsteps verwechselt - fataler fehler.

mach mal range 0-1 (die ja in der praxis wohl am häufigsten vorkommt) und belass den rest so. dann wirst du auch erfahren, was ich mit "hakt" meine und was ein deutlicher indikator dafür ist, das irgendwas nicht stimmt.

das kann kein anderes Ergebnis liefern. Ich habe mit den oben genannten Einstellungen den Range auf 0..1 gestellt. Ensemble A zeigt wieder die falschen Werte beim 5, 10, 20, 40, ... Wert, Ensemble B arbeitet wie vorhergesehen völlig korrekt.
Bitte prüfe das konkret nach; vielleicht sind ja die Regler in der Mac-Version anders programmiert als in der Windows-Version. Hast Du auch das neueste Update (für windows) geladen?

[helmsklamm]

ja, du hast recht, bei knobs SOLO ist das nicht der fall.

abermals sorry: ich hatte keinen knob, sondern ne mausarea und auch diese arbeitet "solo" sauber. nun habe ich aber das Y über snap wieder zurück an BY geführt. was in der praxis häufig vprkommt und soweit auch ein völlig sauberer vorgang ist und kein! eventloop verursacht. man kann in diesem falle das Y als meister begreifen und das BY als knecht, also ziemlich analog zu IC send/slave-knob geschichten.

und hierbei passiert das oben beschreibende. probiers aus: mausarea; Y in merge und wieder zurück an BY. sowohl identische werte für num step/mausreso als auch deine +1 geschichte funzen in den meisten fällen nicht und es hakt irgendwann KOMPLETT (definitiv bei 133 beide, bzw. +1 und auch bei 200, bzw. +1). EINZIG identische werte mit 32er vielfache gehen sauber.

wie gesagt, ich halte das Y/BY "feedback" für nix anderes als ne ICsend/knob-slave geschichte. und wahrscheinlich werden (deine;-) - ich bin mir sicher, DAS wird dir keine ruhe lassen:-)) weiterführenden experimente das bestätigen.

[herw]

...wie gesagt, ich halte das Y/BY "feedback" für nix anderes als ne ICsend/knob-slave geschichte. und wahrscheinlich werden (deine;-) - ich bin mir sicher, DAS wird dir keine ruhe lassen:-)) weiterführenden experimente das bestätigen.

das müsste man wiederum testen - aber NICHT ICH, denn über dieses Stadium bin ich schon hinaus; wenn ich mit MausArea arbeite, dann nicht mit einem Loop nach BY; denn es ist dann nicht klar, wie die MausArea nach einer Initialisierung arbeitet. Ich leite von der MausArea ausschließlich ganze Zahlen her oder sogar nur +1 bzw. -1 und nehme die Werteberechnung selbst in einem eigenständigen Speicher durch. Das Arbeiten mit ganzen Zahlenwerten ist viel überschaubarer.

ciao herw

[helmsklamm]

wieso ist BY nach init nicht klar? idR hängt ja nen snap-modul "dazwischen", das merge hab ich jetzt nur der schnelligkeit wegen vorgeschlagen.

meine vermutung, das dem IC send/slaveknob ein ähnliches prinzip zugrunde liegt, war wohl nich ganz korrekt. bzw. äussert es sich nicht so offensichtlich. hier wird es, wie von dir behauptet bei maus +1 scheinbar korrekt übertragen. scheinbar, weil der erste step "verschluckt" wird, aber danach ist es zumindest sauber.
bei numstep/maus vielfache von 32 (bspw. 192) ist dies NICHT der fall und es wird sogar der erste schritt korrekt mit ünbernommen. es bleibt also dabei, das das die einzig wirklich saubere lösung ist.

(range in beiden fällen 0-1)

[herw]

wieso ist BY nach init nicht klar? idR hängt ja nen snap-modul "dazwischen", das merge hab ich jetzt nur der schnelligkeit wegen vorgeschlagen.

meine vermutung, das dem IC send/slaveknob ein ähnliches prinzip zugrunde liegt, war wohl nich ganz korrekt. bzw. äussert es sich nicht so offensichtlich. hier wird es, wie von dir behauptet bei maus +1 scheinbar korrekt übertragen. scheinbar, weil der erste step "verschluckt" wird, aber danach ist es zumindest sauber.
bei numstep/maus vielfache von 32 (bspw. 192) ist dies NICHT der fall und es wird sogar der erste schritt korrekt mit ünbernommen. es bleibt also dabei, das das die einzig wirklich saubere lösung ist.

(range in beiden fällen 0-1)

warum liest nur keiner meine Post (siehe 2. Februar). Der erste Wert wird nicht verschluckt sondern auf 0 gerundet. Daher musst Du bei ganzen Werten immer 0,5 addieren. (siehe obige Post).

Das grundsätzliche Verständnisproblem liegt darin, dass man nicht sauber Steps und Auflösung (Zustände) unterscheidet:
n Steps erfordern n+1 Zustände (ähnlich wie bei einem nicht geschlossenen Zaun: 10 Zaungatter erfordern 11 Pfähle).
Nochmals meine Empfehlung: nur mit ganzen Zahlen arbeiten und bei der Übertragung mit IC-Send beachten, dass man die Zwischenräume addressiert (Zaungatter!), indem man 0,5 addiert. Die Werteberechnung sollte man nach der Übertragung erst durchführen.

ciao herw

[helmsklamm]

aber warum so umständlich, wenn es bei 32er schrittweiten OHNE geht??? ausserdem impliziert dein nötiges zusatzklimbin doch nen ganz offensichtlichen fehler im getriebe: wenn ich mein auto nur sauber schalten kann, wenn ich mir ne +0.5 schnecke am schalthebel zwischenklemme liegt irgendwas zeimlich im argen.
abgesehen davon bleibt der 32er vorschlag deutlich elegnater.

und was deinen zaun angeht: ich will ja nicht die zwischenräume adressieren, sondern die latten. und wenn ich 11 latten habe und mit 0 anfange zu zählen, möchte ich bei 0 auch die erste latte "selektiert haben" und nicht erst, bei 0.5, genauso wie ich die 4 latte bei 3 und die letze latte bei 10 ausgewählt haben möchte und nicht bei 10.5. (0-10 sind 11 zustände, ergo genauso so viele zustände wie mein zaun latten hat, womit also jede latte eine EINDEUTIGE numerische zuordnung besitzt - und dabei spielt es keine rolle, ob ich die latten persönlcih zähle oder mir jemand nummern zuruft - in beiden fällen sollte ich bei entsprechender nummer vor der korrespondierenden latte stehen.).