IC send-skalierungs trash

[helmsklamm]

ich versteh einfach nich, warum die kack teile nich einfach, wie ihre brüder, die midi CC, ganz simpel IN SICH die anleigenden werte prozentual auf die empfänger weiterleiten?

jeder midi CC kann das schliesslich auch. und selbst wenn er mehrere klienten bedient, kann man sich drauf verlassen das jeder "recieve" die korrekt skalierten werte erhält. sthet der midi cc auf 0.5 (64) wird, sofern die knobs standardiesiert sind, pitch ne 0, DCY ne 40 und RES ne 0.5 empfangen, uswusf.
so simpel, einfach und gut kann es sein. warum nicht hier?

warum können die beknackten IC teile das nicht? warum muss man da peinlichst genau händisch nachjustieren? wie verslavet man eigentlich mehree empfänger, die unterschieldiche ranges haben?
wo ist hier der fortschritt?

[herw]

ich habe die Teile jetzt vollständig durchschaut und kenne die dahinter stehende Logik; ob sie sinnvoll ist, kann ich aber trotzdem nicht sagen. Leider ist es schon spät, aber du kriegst eine schlüssige Beschreibung, wie die Wertebereiche behandelt werden. Danach kann man eine Logik entwickeln, damit sie so eingängig funktionieren wie Du Dir (und ich glaube auch alle anderen) das vorstellst und wünschst.

ciao herw

[helmsklamm]

nee, ich hab kein prob das zum laufen zu kriegen, es ist nur ne menge unützer zusatzarbeit. und, falls man das mal vergisst, ne bugqeulle, wo man erstmal (tage später vielleicht) überlegt - hä, wieso das jetzt.

was mich interessiert, ist warum das so sein "muss"?

[herw]

nee, ich hab kein prob das zum laufen zu kriegen, es ist nur ne menge unützer zusatzarbeit. und, falls man das mal vergisst, ne bugqeulle, wo man erstmal (tage später vielleicht) überlegt - hä, wieso das jetzt.

was mich interessiert, ist warum das so sein "muss"?

Ob es genau so sein muss, wie es ist oder ob nicht eine andere Implementation für den User eingängiger ist, kann ich nicht beurteilen; ich nehme einfach mal an, dass es eine programmiertechnische Besonderheit ist, die man nicht ohne Insiderwissen nachvollziehen kann. Ich kann aber eine schlüssige Antwort darauf geben, wieso das angeblich komische Verhalten so ist und das es völlig logisch ist.
Zunächst mal die Beschreibung des Verhaltens: Benutzt man ein IC-Send, um Reglerposition zur Steuerung zum Beispiel eines Schalters oder eines Distributors zu übertragen und stimmen die Wertebereiche nicht überein, dann erwartet man, dass diese proportional reagieren, also in gleichen Abständen zu Werteänderungen führen. Das passiert aber nicht; an den Rändern sind die Bereiche etwa halb so groß wie in der Mitte.
Dieses komische Verhalten zeigen auch zum Beispiel MouseAreas, Multipictures und andere Panel-Elemente.
Stimmen die Wertebereiche und die Mouse-Auflösung überein, dann funktioniert alles wie gewünscht und gedacht. Warum also nicht bei Nicht-Übereinstimmung. Folgenden Versuchsaufbau (von Rick Scott) findest Du im englischen Forum, das gerade diesen "Bug" ausdiskutierte:
http://www.native-instruments.com/forum ... 1189086430
Ich erläutere das (logische) Verhalten mit drei Experimenten:

erstes Experiment
setze die Mausauflösung des Reglers auf 13 und die Anzahl der Steps auf 12 (stepweite 1)

Jetzt steppe alle Reglerpositionen von 0 ausgehend mit den Cursortasten nach oben und beobachte, wann der IC-Send einen neuen Wert sendet.
Du erhälst die folgenden Schalterpositionen (der Schalter zählt seine Schalterstellungen rückwärts (bzw. von unten nach oben).

5544433322211

zweites Experiment
setze jetzt die Mausauflösung auf 21 und die Anzahl der Steps auf 20 und zähle nochmals:

555444443333322222111

drittes Experiment
setze jetzt die Mausauflösung auf 37 und die Anzahl der Steps auf 36 und zähle

5555544444444433333333322222222211111

Ich hoffe, Du erkennst das Prinzip: jede innere Schalterposition (z.B. 4) hat eine "Bandweite" von 2m+1 Positionen (m natürliche Zahl). Denke Dir, dass jede Hauptposition in der Mitte des jeweiligen Intervalle mit gleichen Zahlen steht (fette Zahlen).
Am linke und rechten Ende hast Du eine halbe Bandweite und die "Mittelposition" am Rand. Dies ist auch sinnvoll, da ja an der letzten und der ersten Position eine Schalterstellung sein soll.

Um die jeweils "richtigen" Positionen und Bandweiten zu erhalten, muss man folgende Rechnung anstellen: z.B. Bandweite einer Schalterposition soll 25 sein (d.h. man mus 25 Pixel mit der Maus oder 25 mal mit der Cursortaste klicken, um einen Schalterwechsel zu erreichen.
Dann brauchst du für die inneren Schalterpsotionen 3·25 und für die äußeren 2·13, also insgesamt 101 Reglerpositionen. Also setzt man die Mausauflösung auf 101 und die step-Weite auf 100.
das Ergebnis

5555555555555444444444444444444444444433333333333333333...

Das ist ein bisschen schwer zu verstehen; das Handbuch schweigt sich da völlig aus. Ich denke mal, dass eigentlich daran gedacht war, dass der User die entsprechenden Regelbereiche entsprechend einrichtet, also möglichst ganzzahlige Werte wählt und alle Bereiche anpasst. Das ist nicht praxisnah und für Anfänger eine große Hemmschwelle. Gut, ich nehme mal an, dass bei der Programmerstellung an solche Anwendungen auch nicht gedacht wurde, sondern das IC-Send ausschließlich dazu gedacht war, Controllerdaten mit ganzzahligen Werten und der Bandweite 1 zu übermitteln, und da funktioniert das IC-Send genauso, wie es gedacht ist.

die allgemeinen Formeln lauten:

n Schalterpositionen
b=2m+1 Bandweite (am besten man wählt hier m=0)

daraus ergeben sich k=(n-2)·b+2·(b+1)/2 Reglerpositionen (Mausauflösung)und k-1 Step-Schritte
alle anderen Einstellungen werden gerundet.

ciao herw

PS: wie man das vermeidet, findest du weit drinnen im MM2 im folgenden Modul:
AUSGÄNGE/EINGÄNGE - EINGÄNGE - EINGANG - MOUSE - SCHALTERSTELLUNG