Bit Multiplexing, integer vs float

[Quietschboy]

Leute, Leute, Stop!
Der eigentliche Multiplexer fehlt da noch.
Den hab ich erstmal rausgelöscht um nicht unnötig zu verwirren.
Na das ist mir ja richtig gut gelungen...

In dem Beispiel geht´s erstmal nur drum zu zeigen, wie der Umweg über Float eine Integer Zahl verfälscht!
Aktiviert doch mal für die gesendete Integer die Bits ab #23 und seht selbst was hinten wieder raus kommt (untere Anzeige).

Die Iteration habe ich hier nur zum Auslesen für die bitweise Anzeige benötigt. Für den eigentlichen BitMux-Bus ist keine Iteration oder sonstige hilfe aus Primary nötig.

Das Macro "Build Int" zeigt aber in der Tat schon das Grundprinzip des Mixens einzelner Bits zu einer Zahl.

[Thala]

In dem Beispiel geht´s erstmal nur drum zu zeigen, wie der Umweg über Float eine Integer Zahl verfälscht!
Aktiviert doch mal für die gesendete Integer die Bits ab #23 und seht selbst was hinten wieder raus kommt (untere Anzeige).

das hab ich heut morgen beim wach werden schon nach 2 klicks bemerkt. habs als gegeben angenommen und gedacht, na dann pfeiffen wir halt auf die oberen bits
mein ziel ist es ja die niederen bits zu beeinflussen und die oberen wieder unverändert ins paket zu tun.

@herw ich hab halt anscheined mit ein paar fragen ein altes thema wachgerüttelt, welches sich hier überschneidet.
grob gesagt waren diese fragen:
kann man in core multiplexen?
kann ich eine float zahl aus dem audiostream auspacken, die niedrigsten bits randomisieren, alles wieder zusammen packen und als normalen audiostream weiterschicken?
wozu ja quasi mux und demux von float hinzugehört.
machts nun sinn?

[Quietschboy]

So,die Kiddies sind im Bett, jetzt habe ich wieder etwas Ruhe...

Ich muss ehrlich sagen, dass ich die Problematik nicht erkenne: Solange ich nur die unteren 24 Bit benutze, kann die zugehörige Ganzzahl als Gleitkommazahl in primary übertragen werden. In der zweiten Corecell kann ich sie ohne weiteres wieder als Ganzzahl bitweise auslesen.
Will man auch die oberen 8 Bits auch übertragen, dann muss man diese extra übertragen. Das geht also insgesamt mit einer zweistelligen Nachricht.

Yeah, nur genau das wollte ich erst mal zeigen. Du bist im Kopf auch schon wieder meilenweit vorraus, oder?

...Und Thala auch...

[Thala]

wieder zu schnell, sorry hab editiert anstatt 2. post zu machen

[Thala]

aber wie ich selbst grad bemerke:
die bits floaten ja... je nach kommastelle. dh randomisieren der letzten bits hätte mal 1,25% oder auch mal 2,5% oder auch mal 5% effekt auf das audiosignal, je nachdem wie laut es grad ist.
und ich bin schon gespannt ob dafür eine lösung kommt, aber glaube es nicht.
moment mal, man weiss ja wo die kommastelle grad steht und könnte randomisieren, nur wenn es im richtigen bereich ist !?!

normalerweise wird wohl minimal rauschen dem signal hinzugefügt um den dither effekt zu erzeugen.
ich hingegen würde gern mehr grit und drift in den karplus strong circuit bringen. und wenn man kontinuierlich auch kleinste mengen rauschen diesem feedbackloop hinzufügt, können sich einige bits ganz schön addieren und hörbar werden. deshalb würde ich gern plain die letzten bits randomisieren anstatt rauschen hinzuzufügen, um für den effekt eine natürliche limitierung zu bekommen
es rauscht x amount im feedback loop. immer. leichtes rauschen belebt den karplus strong circuit extrem und macht die saite viel lebendiger.

[Thala]

Jetzt kann ich schon 28 Bit direkt übertragen. Drei schaffe ich auch noch.

du bist mein mann!!! zieh herw, zieh!

und ich denke, wenn ihr es habt, kommt mir auch grad die letzte fehlende idee

[Quietschboy]

er die nachricht gelöscht..
NEIIIIIN

zu früh gefreut?

[Thala]

er die nachricht gelöscht..
NEIIIIIN

zu früh gefreut?

was ist passiert? wurd der teilnehmer wegen unlauterem wettbewerb entfernt?

[herw]

er die nachricht gelöscht..
NEIIIIIN

zu früh gefreut?

was ist passiert? wurd der teilnehmer wegen unlauterem wettbewerb entfernt?

Nun ich hatte alle 32 Bit benutzt und mir nach der Übertragung als Gleitkommazahl und dem bitweisen Auslesen in der zweiten Corecell plötzlich 28 Bits, die ich an-und ausschalten und auslesen konnte. Leider verhalten sich die Bits 24-31 sehr eigentümlich.
Da war ich an einer Stelle hereingefallen. Also muss man doch wohl die Bits 0-23 und die Bits 24-31 jeweils zu zwei Ganzzahlen zusammenfassen und in einer Nachricht übertragen.
Naja, besser als jedes Biot einzeln.
Wenn nur 24 Bits gebraucht werden, geht es direkt. Das Aussenden und Empfangen ist ziemlich einfach. Falls das genügt, kann ich ein Testenemsble morgen hier hochladen.
Das ist aber auch nur der allererste Einstieg in das multiplexing von Binärnachrichten.

[Quietschboy]

Uff, ich dachte auch schon sie hätten dich wegen Fake News direkt eingebuchtet
Ich frag mal das:
Wie willst du zwei Zahlen weiter in eine Nachricht ohne Delay zusammenfassen?
No-Delay ist in diesem Zusammenhang schließlich bindend, ansonsten kannste ja auch jedes andere geclockte Multiplexing verwenden.

Die 24 Bit müssen also reichen. Für den seltenen Anwendungsfall sollte es ja i.d.R. auch absolut ausreichend sein.
Damit kann man also z.B. 24 einzelne 0-1 Werte (On/Off) oder auch z.B. 4x 0-127 (6 bit) übertragen. Oder einmal 0-16777215 (24bit), was nicht ganz so viel Sinn macht.

- Also eher kleine einzelne Wertebereiche sind es, für die sich das Bit-Multiplexing lohnt.

Edit:
Was mir selbst die Tage noch als "seltener Anwendungsfall" kam, ist die manchmal wirklich lästige Tatsache, dass der Standard Primary Bus, ob nun der von Partial Framework oder der Basic [],$ Bus, keine Init Values sofort übertragen kann. Stichwort Order 2!
Mit einem Bit-Multiplexing System wär das kein Problem, das überträgt Initwerte noch sofort während der Initialisierung.

[Quietschboy]

Weiter im Programm:

5. Das Mischen mehrerer kleiner Integer zu einer großen Integer

Das Bitmultiplexing hat einen Nachteil gegenüber anderen Multiplexverfahren:
Man muss selbst mitdenken und Hand anlegen, denn für jeden Inport muss die Auflösung (Range) in Bits angegeben werden. Zudem muss die maximale Summe aller Inports im Hinterkopf behalten werden (24Bits). Die aktuell reservierte Anzahl an Bits kann aber auch nach Primary ausgegeben werden um dort (auf dem Panel) Alarm zu schlagen, falls die 24 erlaubten Bits überschritten werden.

Hier im Beispiel werden für Port 1 4Bit, Port 2+3 jew. 3Bit reserviert.
Die Inports 4-8 bleiben mit jew. 0Bit unberücksichtigt:

Bit Mux - Forum 02 set Bit Range.JPG

(Das Multiplexer-Macro habe ich momentan in einer verkettbarer Variante mit 8 Inports gestaltet)

Lästigerweise muss man dieselben Werte auch händisch dem Demultiplexer mitteilen: (Den Demuxer habe ich erstmal nur in einer Single-Variante für die vollen 24 möglichen "Kanäle" gebaut)

Bit Mux - Forum 02r set Bit Range.JPG

Es müssen also die Zahlen in die Constant Modules eingetippt werden, oder man copy/pastet die Constants komplett von einer Seite zur anderen - inkl. Neuverkabelung versteht sich.
Alternativ könnte man natürlich auch Core Tables verwenden, die sich Schnell kopieren und einbinden lassen, jedoch fallen einem dabei die Werte für jeden Port nicht sofort ins Auge, wenn man ein Muxer Macro öffnet. Man muss zusätzlich noch den Table Editor öffnen.

Bit Mux - Forum 02a set Bit Range.JPG

Sind die Bit Ranges der Ports im Muxer und Demuxer aber erstmal korrekt gesetzt, dann kann es auch schon losgehen.

[Quietschboy]

Mit den Bit-Ranges pro Inport haben wir nun auch schon alle Parameter die wir brauchen.
Und wie die mitlesende Gemeinschaft bestimmt auch schon festgestellt hat, werden Bits von rechts nach links geschrieben/gelesen.
Das ist wichtig um die Funktion des BIT SHIFT zu verstehen.

Die erste Integer, also die Zahl vom ersten Inport, die in die auszugebende Integer integriert werden soll, wird also an die rechteste Stelle der gemultiplexten Integer gesetzt.
Die Stelle, oder das Startbit, ist Bit 0. Man fängt bei Null an zu zählen.
Die Bit-Nummerierung entspricht übrigens auch dem binären Exponent:
Bit 0 ist 2 hoch 0 = 1,
Bit 1 ist 2 hoch 1 = 2,
Bit 2 ist 2 hoch 2 = 4,
Bit 3 ist 2 hoch 3 = 8, usw.

Da im Beispiel für die erste Integer die Range =4bit festgelegt wird, muss die zweite Integer (Inport 2) bei Bit 4 anfangen. Das heißt für sie: das Startbit ist Bit 4. Für die dritte Integer vom dritten Inport ist das Startbit 7 (4bit + 3 bit).
Das heisst also, jede Integer der Inports muss per BIT SHIFT LEFT (SHIFT<<) an die richtige Position der auszugebenden Integer gerückt werden.
In Reaktor Core umgesetzt sieht das also so aus:

Bit Mux - Forum 03 Mux integer.JPG

Die Eingangsinteger $ wird um ihr individuelles Offset (Startbit) nach links verschoben und zur Multiplexinteger hinzugemischt. Das hinzumischen geschieht mittels des nachfolgenden BIT OR (|). Das Ergebnis wird an den nächsten Inport-Muxer weitergegeben.
Das Startbit wird in diesem Macro um die definierte Range der Integer erweitert und auch der nächsten Instanz weitergegeben.

[Thala]

müssen es konstanten innerhalb des cores sein (zum setzen der ranges), oder würde auch eine GUI funktionieren (knöppgens oder multidisplay/mousearea). die gui elemente könnte man nach erledigter eingabe per macro visibility schnell ausschalten.
so wirklich viele unterschiedliche und sinnvolle möglichkeiten der bitverteilung gibts ja eh nicht. weshalb so eine tablevariante mit "presets", schnell umschaltbar...
und mit einer gui könnte man mux und demux in einem rutsch editieren?

[Quietschboy]

Und damit´s nicht langweilig wird, hier mein komplettes Test-Ens. (Musste nur zwei ACEWs löschen, wegen Dateigrößeneinschränkung hier im Forum)

Auf die Flags und den Demultiplexer gehe ich dann die Tage noch ein.

[Quietschboy]

müssen es konstanten innerhalb des cores sein (zum setzen der ranges), oder würde auch eine GUI funktionieren (knöppgens oder multidisplay/mousearea). die gui elemente könnte man nach erledigter eingabe per macro visibility schnell ausschalten.
so wirklich viele unterschiedliche und sinnvolle möglichkeiten der bitverteilung gibts ja eh nicht. weshalb so eine tablevariante mit "presets", schnell umschaltbar...
und mit einer gui könnte man mux und demux in einem rutsch editieren?

Ich sach mal so:
Dem persönlichen Geschmack sind ja keine Grenzen gesetzt. Es gibt außerdem noch mindestens ein oder zwei andere Punkte in dem Plex-System, wo der eigene Geschmack auch eine eigene Umsetzung erfordert. Ich würde mich eher schwer tun hier ein "That´s it" Framework rauszuhauen.
Ich mache den Erklärbär hier ja auch für die nachfolgenden Neulinge, so dass das Prinzip hoffentlich nachvollzogen und eben die individuelle Umsetzung machbar ist.
Ich bin mir selbst ja auch noch nicht ganz sicher, wie ich es haben möchte, bzw. unglücklich über das ein oder andere Detail. Insofern bin ich über kreativen Input auch happy.


Die optionale GUI Editierung der Ranges finde ich persönlich eigentlich gar nicht so schlecht. Wichtig wäre mir hauptsächlich, dass die Ranges nur einmal editiert werden müssen. Das dürften zur Not auch Primary Constants sein. Hauptsache sie sind zu Init an Ort und Stelle (in den Mux-Macros)!