DISKUSSION zum WORKSHOP 3

[herw]

...Meinst Du, dass IC Send-Receive mit den Werte nicht immer praezies umgehen? Das allerdings habe ich auch erfahren! Ich habe halt nicht mit so extremen Wechel ausprobiert, einfach ein Knopf solle der Bewegung vom einem anderen durch internen Verbindung folgen... und oft ist die zweite Wert (eins) daneben....

Das hat einen anderen Grund: wenn Du zum Beispiel die Range für einen Regler auf 0..100 einstellst und die Stepweite 1 wählst, dann zeigen Dir die Properties richtig 100 steps an. Die Mausauflösung muss aber auf 101 gestellt werden, da es 101 Zustände gibt.

ciao herw

[carloskleiber]

Ok, ich habe sofort gecheckt: Programchild hat aus irgendeinem Grund jeden Knopf auf Aufloesung 256 gestellt. Auf 127 habe ich schon versucht, zu wechseln, weil wegen MIDI das am haeufinsten vorkommt. Jetzt versuche ich zum beispiel "noise decay", der Grenzwerte 0 und 80 hat, Stepsize 1, Num Steps 80, mit Aufloesung 81.
...der "Bahn" wurde viel kuerzer, aber mein Problem gibt es weiter Selten, aber ab und zu geht das Wert falsch durch.
Auf dem Empfangsknopf habe ich auch rumvariiert. Obwohl ich mit dem Maus im Prinzip nich hin muss...

[herw]

Ok, ich habe sofort gecheckt: Programchild hat aus irgendeinem Grund jeden Knopf auf Aufloesung 256 gestellt. Auf 127 habe ich schon versucht, zu wechseln, weil wegen MIDI das am haeufinsten vorkommt. Jetzt versuche ich zum beispiel "noise decay", der Grenzwerte 0 und 80 hat, Stepsize 1, Num Steps 80, mit Aufloesung 81.
...der "Bahn" wurde viel kuerzer, aber mein Problem gibt es weiter Selten, aber ab und zu geht das Wert falsch durch.
Auf dem Empfangsknopf habe ich auch rumvariiert. Obwohl ich mit dem Maus im Prinzip nich hin muss...

kannst Du den Strukturteil, um den es geht, auf ein Minimum reduzieren, dass man das nachvollziehen kann?

[carloskleiber]

Ok, ich lade hier das gezippte Ensemble, ohne Sequencer-Teil auf...

[herw]

Ok, ich lade hier das gezippte Ensemble, ohne Sequencer-Teil auf...

ach Du schreck, wo geht es denn hier lang, sagte der Blinde


konnte ich mir nicht verkneifen. Ich versuche mich durchzuwühlen; ganz so schlimm wird es nicht werden; kannst Du noch einen kleinen Kommentar geben, was Du genau bezweckst?

Die Stelle ist ja auch gemein! Da musste ich dreimal hinschauen.

[tymes2]

IC sends & receive... sehr tückische Geschichte, das. Ich habe (wie wahrscheinlich viele Andere) da auch öfter unerklärliches Verhalten entdeckt. Ausgehend von Deiner Anregung, Herwig, die min/max Werte der ICs sehr gross zu wählen, stellte ich fest dass diese einen nicht unerheblichen Einfluss auf die Ausgabe haben. Simple Anordnung (Knob->IC send / IC receive->Numeric) zeigte, dass a) zur Ausgabe sämtlicher Knob-Werte die Maus-Resolution auf Anzahl der Steps + 1 gestellt werden muss. ABER: die Einstellungen in den Properties der ICs sind hier nicht minder kritisch (ist ja auch bekannt), und interessanterweise ergab sich Folgendes: der sendende Knob hatte einen Wertebereich von 0-2,5 in 100 steps (Mausreso = 101). Wenn ich nun in den IC Props die Werte 9999 / -9999 für die Max/Min Range einstellte, gab es beim Knobwert von 2.45 am Numeric die Ausgabe 2.451 (das Kabel selbst übertrug einen Wert von 2.4507, welcher vom Numerical offensichtlich gerundet wird) sowie des Öfteren Knobwerte, die mit einem Fehler von 0.001 am Numeric ausgegeben wurden! Lässt man den Mauszeiger über dem Kabel schweben, sieht man dass eigentlich ALLE Werte falsch sind, aber vom Numeric gelegentlich auf die "korrekten" Werte gerundet werden. Änderte ich die Range der ICs auf +/- 999, war die Ausgabe korrekt. Auch bei einer willkürlichen Range von 283 / -261 war die Ausgabe korrekt!! Ich vermute, als Richtwert sollte die Range immer etwas grösser sein als der maximal zu übertragende Wert, aber eben nicht zu gross.

[herw]

IC sends & receive... sehr tückische Geschichte, das. Ich habe (wie wahrscheinlich viele Andere) da auch öfter unerklärliches Verhalten entdeckt. Ausgehend von Deiner Anregung, Herwig, die min/max Werte der ICs sehr gross zu wählen, stellte ich fest dass diese einen nicht unerheblichen Einfluss auf die Ausgabe haben. Simple Anordnung (Knob->IC send / IC receive->Numeric) zeigte, dass a) zur Ausgabe sämtlicher Knob-Werte die Maus-Resolution auf Anzahl der Steps + 1 gestellt werden muss. ABER: die Einstellungen in den Properties der ICs sind hier nicht minder kritisch (ist ja auch bekannt), und interessanterweise ergab sich Folgendes: der sendende Knob hatte einen Wertebereich von 0-2,5 in 100 steps (Mausreso = 101). Wenn ich nun in den IC Props die Werte 9999 / -9999 für die Max/Min Range einstellte, gab es beim Knobwert von 2.45 am Numeric die Ausgabe 2.451 (das Kabel selbst übertrug einen Wert von 2.4507, welcher vom Numerical offensichtlich gerundet wird) sowie des Öfteren Knobwerte, die mit einem Fehler von 0.001 am Numeric ausgegeben wurden! Lässt man den Mauszeiger über dem Kabel schweben, sieht man dass eigentlich ALLE Werte falsch sind, aber vom Numeric gelegentlich auf die "korrekten" Werte gerundet werden. Änderte ich die Range der ICs auf +/- 999, war die Ausgabe korrekt. Auch bei einer willkürlichen Range von 283 / -261 war die Ausgabe korrekt!! Ich vermute, als Richtwert sollte die Range immer etwas grösser sein als der maximal zu übertragende Wert, aber eben nicht zu gross.

Ich vermute eher, dass das IC-Send eine obere und untere Grenze hat, die noch niedriger ist als meine angegebenen 9999; ich habe das gestern nur ganz kurz getestet. Es wird wohl so etwas sein wie 1024, 2048 etc. bis zu der die übertragenen Werte exakt sind, dann wird in der Tat so komisch "gerundet" (wahrscheinlich Rundung mit binären Stellen, daher die krummen Werte).

Kann das mal jemand testen?

[tymes2]

Das scheint noch komplizierter zu sein als man sich vorstellen kann - ich habe jetz mal in dem oben beschriebenen Setup einen Knob mit der Range 0-10 (100 Steps) genommen: schon stimmt meine gemachte Aussage nicht mehr. Das Numeric Display zeigt zwar die korrekten Werte an, übertragen wird aber ein abweichender Wert (z.B. 8,29998 statt 8,3). Das gilt auch für eine wesentlich kleinere Range für die IC send/receive, bspw. 200 / -200 (oder auch 100 / -100). In dem Moment, wo ich allerdings für die untere Range der ICs hier 0 eintrage, ist Alles korrekt.

Nächstes Scenario: Knob -1 bis 10 (number of steps = 91 damit auch mal schräge Werte übertragen werden müssen). Max bei send/rec 999, Min auf -100. Schon treten Abweichungen in der letzten Stelle auf (Numeric rundet wieder auf den korrekten Wert), die man durch Schweben des Mauszeigers überm Kabel angezeigt bekommt. Verringern des Max der ICs auf 100 (Range ist jetzt 100 / -100): selber Fehler (der sich übrigens bei Knob-Werten < 1 auf die letzten beiden Stellen erweitert). Weiter - der Min-Wert der send/rec wird auf -10 eingestellt. Jetzt scheint Alles korrekt übertragen zu werden BIS AUF die Werte < 1, hier treten wieder minimale Abweichungen auf. Wenn ich nun den Min Wert der ICs auf den Min Wert des Knobs einstelle (hier also -1), dann arbeitet die Übertragung anscheinend fehlerlos, auch bei Werten nahe 0. Das auch, wenn der Max Wert der ICs auf 999 gesetzt wird (oder auch 9999!). Offensichtlich ist der untere Wert hier kritisch. Ich hänge das kleine Test-Ensemble mal an. ACHTUNG: beim Ausprobieren immer den Mauszeiger zum Überprüfen der Werte benutzen, das Knob-Display ist generell auf zwei Nachkommastellen gerundet!! Und auch ganz kleine Werte nahe 0 prüfen - manchmal scheint im Bereich >1 alles okay zu sein, im Bereich <1 ist es das nicht! Das Ensemble ist übrigens in R5.1.1 erstellt (OS X 10.4.8).

Edit: die Fehler sind allerdings soo gering, dass ich mich frage, ob man die nicht vernachlässigen kann?!?

[carloskleiber]

konnte ich mir nicht verkneifen. Ich versuche mich durchzuwühlen; ganz so schlimm wird es nicht werden; kannst Du noch einen kleinen Kommentar geben, was Du genau bezweckst?

Die Stelle ist ja auch gemein! Da musste ich dreimal hinschauen.

Bild 1 ist wohl Programchilds Originellensemble.. Factory Library Ensemble.
Bild 2, ja, sorry, ich weiss, aber sieht immer noch besser aus als Bild 1...
Aber ist doch klar wozu ich es bauen will, nein?
Ich lese aufmerksam eure Posts ueber IC-Praezision..
Gruss,
carloskleiber

[herw]

konnte ich mir nicht verkneifen. Ich versuche mich durchzuwühlen; ganz so schlimm wird es nicht werden; kannst Du noch einen kleinen Kommentar geben, was Du genau bezweckst?

Die Stelle ist ja auch gemein! Da musste ich dreimal hinschauen.

Bild 1 ist wohl Programchilds Originellensemble.. Factory Library Ensemble.
Bild 2, ja, sorry, ich weiss, aber sieht immer noch besser aus als Bild 1...
Aber ist doch klar wozu ich es bauen will, nein?
Ich lese aufmerksam eure Posts ueber IC-Praezision..
Gruss,
carloskleiber

programchilds Struktur sieht schon arg schlimm aus; ich weigere mich einfach solchen Spaghetti-Code nachzuvollziehen. Manchmal glaube ich, dass nachträglich aus unnötigen Verschleierungsgründen die Strukturen bewusst verfremdet werden. So ein Quatsch.
Zu Bild 2,; ja das ganze 16 mal nebeneinander zu sehen wäre nicht schön. Ich vermeide so etwas, indem ich ein zusätzliches Makro anlege. Mit dem Eventbus ist das natürlich viel einfacher: Zwei Leitungen für alles; und die auch noch kabellos (geht aber auch mit Kabel.

[herw]

Das scheint noch komplizierter zu sein als man sich vorstellen kann - ich habe jetz mal in dem oben beschriebenen Setup einen Knob mit der Range 0-10 (100 Steps) genommen: schon stimmt meine gemachte Aussage nicht mehr. Das Numeric Display zeigt zwar die korrekten Werte an, übertragen wird aber ein abweichender Wert (z.B. 8,29998 statt 8,3). Das gilt auch für eine wesentlich kleinere Range für die IC send/receive, bspw. 200 / -200 (oder auch 100 / -100). In dem Moment, wo ich allerdings für die untere Range der ICs hier 0 eintrage, ist Alles korrekt.

Nächstes Scenario: Knob -1 bis 10 (number of steps = 91 damit auch mal schräge Werte übertragen werden müssen). Max bei send/rec 999, Min auf -100. Schon treten Abweichungen in der letzten Stelle auf (Numeric rundet wieder auf den korrekten Wert), die man durch Schweben des Mauszeigers überm Kabel angezeigt bekommt. Verringern des Max der ICs auf 100 (Range ist jetzt 100 / -100): selber Fehler (der sich übrigens bei Knob-Werten < 1 auf die letzten beiden Stellen erweitert). Weiter - der Min-Wert der send/rec wird auf -10 eingestellt. Jetzt scheint Alles korrekt übertragen zu werden BIS AUF die Werte < 1, hier treten wieder minimale Abweichungen auf. Wenn ich nun den Min Wert der ICs auf den Min Wert des Knobs einstelle (hier also -1), dann arbeitet die Übertragung anscheinend fehlerlos, auch bei Werten nahe 0. Das auch, wenn der Max Wert der ICs auf 999 gesetzt wird (oder auch 9999!). Offensichtlich ist der untere Wert hier kritisch. Ich hänge das kleine Test-Ensemble mal an. ACHTUNG: beim Ausprobieren immer den Mauszeiger zum Überprüfen der Werte benutzen, das Knob-Display ist generell auf zwei Nachkommastellen gerundet!! Und auch ganz kleine Werte nahe 0 prüfen - manchmal scheint im Bereich >1 alles okay zu sein, im Bereich <1 ist es das nicht! Das Ensemble ist übrigens in R5.1.1 erstellt (OS X 10.4.8).

Edit: die Fehler sind allerdings soo gering, dass ich mich frage, ob man die nicht vernachlässigen kann?!?

Bei Wert 1,05 (send wire : 1,05495, receive wire : 1,05494).
Ich denke mal folgendes: Die IC-Send und IC-Receive bekommen durch ihre Range-Einstellungen eine Auflösung mit der die ankommenden Daten "gerastert" werden; mit diesem "Trick" habe ich zum Beispiel im ModularMini erreicht, dass ich auch beim Einfügen von neuen Modulen nicht ständig die IC-Sends und IC-Receive Properties umändern muss.
Generell glaube ich aber, dass die IC-Verbindungen eigentlich vorrangig für ganzzahlige Werte, besser eindeutig diskrete Werte, also Rundungs unempfindliche Werte gedacht sind, da sie ja andere Module steuern sollen. Früher (R3.3) gab es diese Möglichkeit der Steuerung ja auch bei anderen Modulen (Knobs etc.). Das war immer zweideutig, daher wurde das in R5 (glaube ich) geändert. IC-Verbindungen sind eigentlich dazu da andere Elemente (z.B. Switches) in definierte Zustände zu bringen (Schalterposition).
Daher sind diese Rundungsfehler eher unbedeutend. Natürlich muss man dies wissen, wenn man "empfindliche" Daten übersendet. Ich würde versuchen, alle Daten so zu "verschlüsseln", dass sie ganzzahlig sind und beim Empfang wieder zurückrechnen; dann ist man auf der sicheren Seite, abgesehen davon, dass die anschließende Logik viel einfacher zu bewältigen ist. CPU-mäßig ist der zusätzliche Aufwand eh unerheblich, da ja IC-Verbindungen keine Audiodaten senden können (leider).

Ich würde aber im Fall des Ensembles von CarlosKleiber IC-Verbindungen ganz vermeiden und einfach eine Datenleitung (Eventbus kommt in ein paar Tagen) zwischen die beiden Instrumente legen. Das ist eine saubere und auch übersichtliche Lösung. Abgesehen davon würde man auch diesen Bus polyphon verwenden können; alle Voice-Module entfallen. Das ist viel einfacher.

Wer schreibt mir übrigens eine englische Übersetzung zum Eventbus (ca. eine Seite)? Das ist für mich der häufigste Grund, nicht schnell zu veröffentlichen; ich tue mich darin so schwer und nur dreist einen deutschen Text beizulegen (ohne den geht es nicht) traue ich mich nicht.

ciao herw

[herw]

...Uebrigens, ja, es stimmt, was ich zu bauen versuche: ein Instrument, einfach um Events (Werte.. Parameter..) zu sparen, und durch interne Verbindung hin und zurueck zu senden.
...

so, wie ich Deine Andeutungen verstehe, willst Du nicht events einsparen, sondern Schalter- und Reglerbewegungen synchronisieren?
Das ist nicht unproblematisch, da ja oft additive Parametermischungen auftauchen (siehe die Verknüpfungen in Aerobic.) Dort werden Parameterwerte einfach addiert. Das ist ein beliebtes Modulationsschema. Schickt man allerdings zusätzlich "von außen" Daten hin und her, dann gibt es Probleme durch Eventsprünge (woher weiß das sendende Instrument, welche Daten gerade im anderen Instrument anliegen?). Das kann man nur konkret von Fall zu Fall lösen, je nachdem, wie man die gesendeten Daten übermittelt.
Man kann das umgehen, indem man nicht die absoluten Werte übermittelt, sondern nur deren Veränderungen (also ein erweitertes Inkrement-Dekrement); da benötigt man für jedes Steuerelement einen eigenen Speicher. Das ist mit einigem Denkaufwand aber nicht so schwer, wenn man es nicht zum ersten Mal macht.. Das verwende ich bei dem beigefügten Beispiel-Ensemble zum Eventbus. Da hatte ich lange dran zu knabbern, bis ich eine einfache Lösung gefunden habe (Wert empfangen - alten Speicherwert senden - Werte vergleichen - Differenz aussenden - neuen Wert speichern).

Greift man auf ein Modulationselement von mehreren Seiten zu, kann man dies zum Beispiel auch über ein normales Receive-Modul lösen; ein Receive-Modul kann von mehreren Quellen aus parallel mit Daten beschickt werden. Aber das muss man selbst für das jeweilige Ensemble austesten und eine Lösung finden. Schnelle Antworten gibt es darauf nicht, macht aber in der Eigen-Entwicklung mehr Spaß, wie Du das weiter oben richtig erwähnst.

[tymes2]

...Bei Wert 1,05 (send wire : 1,05495, receive wire : 1,05494)...Generell glaube ich aber, dass die IC-Verbindungen eigentlich vorrangig für ganzzahlige Werte, besser eindeutig diskrete Werte, also Rundungs unempfindliche Werte gedacht sind, da sie ja andere Module steuern sollen. Früher (R3.3) gab es diese Möglichkeit der Steuerung ja auch bei anderen Modulen (Knobs etc.). Das war immer zweideutig, daher wurde das in R5 (glaube ich) geändert. IC-Verbindungen sind eigentlich dazu da andere Elemente (z.B. Switches) in definierte Zustände zu bringen (Schalterposition)...

Ich benutze die ICs um Kabelgewirr zu vermeiden und halte meine Modulationen immer im Bereich +1/-1, die dann nach Bedarf "vor Ort" skaliert werden, von daher sind ganzzahlige Werte mindestens sperrig, wenn nicht unmöglich, denn die offensichtlich limitierte Range der ICs ist ja fast 'unberechenbar' - zumindest ohne ausreichende Dokumentation. Soll ich jetzt Alles erst mal mit 10.000.000 multiplizieren? Neee...

Was die Übersetzung angeht - mach ich Dir, kein Problem. Schicksma.

[herw]

...
Was die Übersetzung angeht - mach ich Dir, kein Problem. Schicksma.

Danke ich werde darauf zurückkommen.
Im Moment muss ich zwei Projekte betreuen: den Eventbus und den Modular.

[tymes2]

Carlos will übrigens keine Events "sparen", sondern Werte abspeichern. Vom Englischen "to save" (im Sinne von saving snapshots), denn Deutsch ist nicht seine Muttersprache glaube ich zu erinnern.