Deutsches Reaktor Forum

Hallo ihr lieben Leute,
eigentlich wollte ich hier eine Frage zum Bit Multiplexing stellen, aber beim vielen rumprobieren hat sich (leider) eine Erkenntnis eingeschlichen
Diese möächte ich hier gerne teilen, und vielleicht habe ich ja dann doch noch eine Frage

Ich fang mal so an:

Aufgabenstellung:
Bit-multiplexe 5 Event-Leitungen in einer Audio Core Zelle auf eine Leitung, um diese dann mittels GLists AudioCoreEventOutput nach draußen, also nach Primary zu führen.
Wozu das ganze? Ich bin ja (ehr-)geizig und will CPU sparen. GLists Lösung bedarf 3 Ports an der Audio Core Cell und zwei AtoE anstelle von den jetzigen 5 Ports + 5 AtoEs. Eigentlich sind es sogar 7 Ports, da für eine Eventleitung der AudioCoreEventOutput unabdinglich ist (Events mit ausschließlich Wert 0 und das auch noch zeitkritisch). Außerdem sollen die Werte sowieso idealerweise sofort, also im "jetzigen" Sampletick in Primary zur Verfügung stehen.

Idee:
man nehme die 32 zur Verfügung stehenden Bits einer Zahl und schütte da die einzelnen EventWerte rein, die in meinem Fall meißt nur 1 bit (0/1)oder auch mal 8bit (0-255) benötigen. Zusammen mit den 5 Flag Bits, die dem Demuxer mitteilen, ob ein Event für den entsprechenden Ausgang anliegt oder nicht, paßt auf jeden Fall alles in 32bit rein.

OK, soweit so gut, Multiplexer und Demultiplexer funktionieren, aber jetzt kommts:
1) bit 32 gehört bei integer nicht mehr zum Wert, sondern stellt das Vorzeichen dar --> nur noch 31bit zur Verfügung (bit 0-30)
2) verläßt meine schöne gemuxte Zahl die AudioCoreCell wird sie nach FLOAT gewandelt.
zurück nach Integer im Demuxer sind Bitwerte im unteren Bereich (0-8 oder so) futsch, sobald im Muxer Bits oberhalb des 23ten Bits auf 1 gesetzt werden.
schwer zu erklären, deshalb ist ein Beispiel Ensemble angehängt.

http://de.wikipedia.org/wiki/Gleitkomma erklärt mir, daß bei float das oberste bit (31) also für das Vorzeichen zuständig ist. Dann kommen 8bit Exponent und die restlichen 23bit sind Mantisse.
Bei der Umwandlung von Integer nach Float findet ein Verlust der Genauigkeit zugunsten von großen Zahlen statt. Wieder zurück nach Integer fehlen dann also bitwerte im unteren Bereich.

Fazit:
Ein Bitmuxer / Demuxer innerhalb Core kann 31bit eines Wertes verwenden.
Ein Bitmuxer / Demuxer von Core nach Primary funktioniert mit nur 23 genutzten bits

Für meine konkrete Anwendung nutzt das jetzt nicht mehr allzu viel. Muß dann wohl doch es so lassen wie es ist, oder 2 AudioCoreEventOuts verwenden (mit BitMux). Geil wäre natürlich wenn Primary auch Integer könnte, oder es möglich wäre irgendwie eine Integerleitung durch Primary hindurchzutunneln.
Eine andere Variante wäre natürlich, die 5 Eventleitungen ganz "normal" zu muxen (mit Puffer), und über einen AudioCoreEventOut rauszuschicken. Funktioniert aber für mich nicht, da ein zeitliches Delay von mindestens einem Sampletick nicht vertretbar ist (1.Tick: idx, 2.Tick: value)!

Wie macht ihr das denn eigentlich so? Wie führt ihr eure lieben Events aus der AudioCell raus?

ciao

Hab erst vor kurzem damit angefangen, Events aus Audiocells zu mogeln. Ist ja schon nervig, dass das nicht generisch geht. Vermutlich war die Sorge, dass eine Audio-Clock-getriggerte Eventkanone alles lahmlegt. Hab bislang den Eventout genommen, aber den Flipflop mehrfach verwendet. Also nur einen für mehrere Streams.

Kenne Max/MSP nicht, aber da gibt es offenbar einen Objekttyp Liste, den man einfach hinundherschicken kann, das wäre manchmal sehr praktisch.

hm, du meinst also so wie in den Bildschers hier?
Das ist mal keine schlechte Idee! Allerdings werden dann immer gleich alle Leitungen "ausgelesen" sobald in Core auch nur an einer ein Event anliegt. Aber wenn keine gleichen Werte hintereinander folgen müssen, kann man ja problemlos mittels Step Filter die "Ghostevents" wegfiltern.

Also man spart Ausgänge und somit Arbeit und erhöht auch die Übersicht.
Aber was ist mit der CPU Last? Klar, man spart auch an der Grundlast (der Menge der Audio-Outs). Trotzdem sind ja in diesem Fall hier mit 4 Eventleitungen nun gleich acht AtoE Trigger Module vorhanden!
Wie ist das denn mit den AtoEs? Verbraten die nur dann CPU-Power, wenn eine Abfrage des Audio Inputs stattfindet? Also mal davon abgesehen, daß beim AtoE Permanent z.B. ja wohl auch noch ein interner SampleClock-Counter hinzugerechnet werden müßte.? Es scheint zumindest so, da z.B. bei Permanents, die Cpu Last mit der Auslesefrequenz steigt.

Ja, genau wie das in den Bildern, man kann noch die Makros hinter der Cell zusammenlegen zu einem und hat noch ein paar Kabel weniger. Ist schon ein wenig ein cpu-Kauer, geb ich zu. Da kann man eigentlich auch gleich einen Perma-Event-Generator bauen, der mit jedem Audiocyclus ein Event erzeugt. Hab das bisher nur in dieser Art gebraucht. Ein generischer Ausgang wäre schon schöner.

OOPS, sieben Jahre schon rum?
Es wird Zeit den Bit Multiplexer mal fertig zu machen
Thala brachte mich drauf, da er gerade auf der Suche nach Multiplex-Systemen für die Core Cell ist. Raus nach Primary - versteht sich.

Ich hatte den Bitmuxer schon noch etwas weiter gebastelt, aber nie ganz fertig gemacht.
Es funktionierte für meine eigenen Ansprüche soweit ausreichend, aber die Notwendigkeit den Bitmuxer richtig schick zu machen hielt sich doch in Grenzen. Und heute, mit Reaktor 6, erst recht.
Reaktor 6 vereint die lästige Audio Core Cell mit der Event Core Cell und es gibt Event Ausgänge die auch "Audio", also SR.C synchrone Events, nach Primary ausführen können. Die Core Cell erlaubt 40 In- und Outports. Das sollte für die meisten Fälle reichen.

Aber trotzdem bleibt das Multiplexing aus Core heraus generell interessant:
In erster Linie möchte man natürlich die Übersicht in der Struktur bewahren. Da hilft nur Ports sparen und Ausgangsevents gruppieren. Also Multiplexing.
Hierzu gibt es eigentlich nur zwei Möglichkeiten:
- Bit-Multiplexing
- Serielles Multiplexing

Das serielle Multiplexing ist i.d.R. einfacher zu verwenden und bietet in sich auch wieder verschiedene Optionen. Insbesondere für die Ausgabe an das GUI ist serielles Multiplexing interessant. Der große Nachteil des seriellen Multiplexing ist das Delay, also der zeitliche Versatz, der damit zwingend verbunden ist. Für die Ausgabe auf dem GUI ist das aber nicht relevant, da das Delay dann normalerweise an die DClk gebunden ist, welche wiederum an die Refresh Rate des GUI gebunden ist. In diesem Fall gibt es also keine zusätzliche Verzögerung.
Siehe auch das Multiplexing im 2018 X-mas Gift TRK Bass. Hier werden per DClk und Iteration ständig alle auszugebenen Ports auf Veränderung abgefragt und entsprechend dem Standardformat [], $ (Index, Value) ausgegeben.

Was aber, wenn zeitkritische Steuerbefehle aus Core nach Primary übertragen werden sollen? Zeitkritisch heißt: Sofort! Möglicherweise auch für Init.
Und davon noch mehrere gleichzeitig?
Dann kann man nur einzeln über die Core Cell Ports raus oder man nutzt eben Bit-Multiplexing.
Bit-Multiplexing ist insbesondere von Vorteil, wenn mehrere SR.C synchrone Events gleichzeitig aus der Core Cell herausgeführt werden müssen. Event-Outports mit "enable Audio" sind ja schließlich nicht ganz billig. Da könnte das Mischen mehrerer Werte in eine einzige auzugebende Zahl über 1 (oder 2) Ports von Vorteil sein. Auch eine Ausgabe von Initialisierungswerten noch während der Initialisierung ist mit seriellen Muxern nicht möglich.

Also, es gibt doch noch ein paar Nischenanwendungen, für die Bit-Multiplexing interessant sein kann.

Ich habe das System heute etwas gepimpt. Es können nun die vollen 24bit der Float-Mantisse für Werte von bis zu 24 Inports gemuxed werden. Test steht noch aus. Resultate und Doku folgt dann in Kürze...

vielen lieben dank mal wieder...
schick endlich mal deine adresse per pm, damit ich dir ne kiste bier oder eine schoene flasche zukommen lassen kann.

wirklich interessant ist aber auch, wie sich deine artikulation in den jahren veraendert hat.
du konntest mal ganz normal kommunizieren!
wie es ausschaut, hat die thematik ihren tribut bekommen...

bin schon sehr gespannt auf den upload.
ich selber hab mir angewoehnt, wann immer es moeglich ist primary events nur in core zu routen. alle latches vermeiden, damit die dinger es auch selbststaendig wieder aus einem core event output raus schaffen.
unter dieser vorraussetzung kann man evtl auch eine einfachere plex geschichte verwenden?

Thala hat geschrieben: wirklich interessant ist aber auch, wie sich deine artikulation in den jahren veraendert hat.
du konntest mal ganz normal kommunizieren!
wie es ausschaut, hat die thematik ihren tribut bekommen...

Ja, das ist schon schlimm...man stumpft irgendwie ab mit der Zeit...
Nerdige Grüße

OK, ich hab mich dazu entschlossen hieraus einen kleinen Workshop zu machen, da das Thema nicht ganz einfach zu verstehen ist.

BIT MULTIPLEXING in Reaktor 6

1. Der Grundgedanke:
- Es sollen Core Cell Outports gespart werden
- Das Multiplexing System soll ohne Zeitversatz arbeiten
- Es soll Event-Sensitiv sein; D.h. gleiche Werte sollen durchaus am Ausgang wiederholt werden!

Die Idee ist, mehrere integere Zahlen in Reaktor Core in eine einzige integere Zahl zu mischen (hab ich schon mal erwähnt, oder?).
Der Demultiplexer sitz dann in einer anderen Core Cell.

Die Anzahl der binären Bits der Eingangszahlen darf in Summe nicht die maximal möglichen Bits der gemischten Integerzahl übersteigen. D.h. die Bits sollen "nebeneinander" in der Multiplexzahl platziert werden. Eine bildliche Darstellung kommt später. Theoretisch nutzbar wären also 31Bits bei einer 32bit Integer und 63bit bei einer 64bit Integer.

Da die Zahl aber über das Primary Level zur anderen Core Cell übertragen werden muss, wird sie automatisch in eine 32bit Fließkommazahl gewandelt. In der Empfangs-Core Cell kann diese Fließkommazahl dann wieder in eine Integerzahl gewandelt werden, damit mit den Bit-Operatoren darauf zugegriffen werden kann.
Und da haben wir schon das erste Problem:

2. Die Fließkommazahl
Wer mit diesem Mysterium noch nichts anfangen kann, kann sich ja mal diese super Einführung von Bartek Szopka reinziehen. Kann ich nur empfehlen!
https://2013.jsconf.eu/speakers/bartek- ... d-ask.html

Ansonsten gibt´s ja noch Wikipedia (auch auf englisch...) und Google...

Quietschboy hat geschrieben:OK, ich hab mich dazu entschlossen hieraus einen kleinen Workshop zu machen, da das Thema nicht ganz einfach zu verstehen ist.

BIT MULTIPLEXING in Reaktor 6

1. Der Grundgedanke:
- Es sollen Core Cell Outports gespart werden
- Das Multiplexing System soll ohne Zeitversatz arbeiten
[...]

Was heißt das genau? Heißt das, dass alle Teil-integer-Zahlen, bevor sie die erste Corecell verlassen, zeitgleich sind, dann sind sie in primary, werden irgendwie verarbeitet und wieder in die zweite Corecell geschleust und dort formell wieder als zeitgleich dargestellt?

Soweit ich mich erinnere, hattest du die Übernahme des Bussystems in core auch für primary vorgeschlagen; das wurde durchaus wohlwollend von den Entwicklern angenommen und als (leicht) übertragbar beurteilt. Vielleicht sollte man das nochmals anmahnen?

Hi Herwig!

herw hat geschrieben:Was heißt das genau? Heißt das, dass alle Teil-integer-Zahlen, bevor sie die erste Corecell verlassen, zeitgleich sind, dann sind sie in primary, werden irgendwie verarbeitet und wieder in die zweite Corecell geschleust und dort formell wieder als zeitgleich dargestellt?

Ja, fast: - Events an den Inports des Multiplexers dürfen simultan/zeitgleich sein, müssen aber nicht.
- In Primary geschieht nichts mit der Multiplexzahl. Zumindest fällt mir nichts ein, was und wie man sinnvolles damit anstellen könnte.
- Nach der Ausgabe vom Core DEmultiplexer an Primary sind die Output-events nicht mehr simultan, sondern unterliegen der normalen Top-Down Reihenfolge der Core Cell Outports. Genauso wie wenn die Zahlen/Events von der Ursprungs Core Cell direkt einzeln an Primary übergeben werden.
- Und da es ein event-sensitives System sein soll, werden nur die Kanäle am Outport ausgegeben, die auch am Inport ein Event erhalten haben. So wie das normale Multiplexing System ja auch.

2. Die Fließkommazahl (Fortsetzung):

Eine in seine 32 Bits aufgelöste Ansicht einer Fließkommazahl nach IEEE-754 sieht also folgendendermaßen aus:
Quelle: Wikipedia
Die Mantisse wird hier "fraction" genannt. Ansonsten ist wohl eher "significant" die korrekte Bezeichnung...und im deutschen findet man den Begrtiff Mantisse....
Das mit dem Hidden Bit der Mantisse lass ich hier mal weg, weil das interessiert uns an dieser Stelle nicht.

3. Die Integerzahl
Bei der Integerzahl steht auch das linkeste Bit (#31) für das Vorzeichen (signed integer), die restlichen Bits stehen zur Auflösung der Zahl zur Verfügung.
Sie entsprechen also der Mantisse, Fraction oder Significant oder was auch immer hierfür die korrekte Bezeichnung ist.
Würde auch der Demultiplexer in der selben Core Cell wie der Multiplexer sein, könnte man wohl die vollen 32 Bit inklusive des Vorzeichenbits nutzen. Allerdings ist das mit den Bundles und Scoped Busses in Reaktor 6 sowas von obsolet...

4. Das "Tunneln" einer Integer durch Float
Da ja nun, wie schon erwähnt, die im Multiplexer (Core) zusammengebastelte Integer durch Primary hindurch muss (Primary kann nur Float), muss der kleinste gemeinsame Nenner gefunden werden, der eine fehlerfreie Umwandlung von Integer nach Float erlaubt. Die Wandlung von Float zurück nach Integer ist dann für unseren Anwendungsfall kein Problem.
Um´s kurz zu machen:
Die ersten 23 Bit stehen zur Verfügung. Das ist genau die Länge der Float-Mantisse. Das Hidden Bit lassen wir ausser acht.
Nutzen wir nur die ersten 23 Bit der Integer, bleibt bei der Umwandlung nach Float der Exponent = 0. Und 2 hoch 0 = 1. D.h. die Float ist dann 1xMantisse.
Das mit dem Exponent = 0 stimmt nicht wirklich, da noch eine "Normalisierung" für die Float stattfindet, aber ich denke so läßt es sich als Modell ganz gut verstehen.

Quietschboy hat geschrieben: - In Primary geschieht nichts mit der Multiplexzahl. Zumindest fällt mir nichts ein, was und wie man sinnvolles damit anstellen könnte.

1. die fliesskomma macht keine probleme oder? sie is uns erstmal schnurz? ich kann die zahl 1254 problemlos von einem core zum anderen hier bringen. oder überseh ich da etwas?
2. ich hoffe bordinterne hilfsmittel sind erlaubt und greife deshalb zu einem meiner lieblings(lern)tools und aktiviere die versteckte scale correction des kodiak shift sequencers:
https://youtu.be/fW7YIOSVKM8
wie im video zu sehen, ist jedem bit (hier stellvertretend eine klaviatur zum visualisieren benutzt) ein fester zahlenwert zugeordnet. wodurch man bei dem zusammen addiertem (integer) ergebnis (die multiplex summe im numeric readout) hinterher klar sagen kann, welche werte range zu welchem bit gehört und man kann es entsprechend wieder auseinander klamüstern.
die jungs von NI setzen dem ganzen aber die krone auf. diese gemuxten einzelwerte (-> bits zu EINER grossen zahl zusammengefasst) lassen sich herrlich snapshotten und presetten!
die abgespeicherten preset scales sind zB nummern, die in einem snap array gespeichert sind. die werden einfach nur abgerufen anstatt berechnet oder zusammengesetzt.

ich seh hier evtl einen performance boost für den init zeitraum? ich mein es macht doch sicherlich einen unterschied ob 31 buttons auf der GUI initiiert werden (und die gesamten daten auf einen core einprasseln), oder man diese per router ausschaltet und während des init genüsslich eine einzige snapshot zahl in den core leitet und dort direkt walten lässt?
wenn man alle buttons bit-muxed, und diese zahl snapshottet müsste doch das snapshot eigentlich reichen?

3. aber die brücke zu floating point fehlt mir noch komplett irgendwie
- was ich mir vorstellen kann: je mehr float zahlen man gleichzeitig übertragen will, um so mehr qualität büßt man ein?
heisst man könnte eine ankommende float mit 50% quali übertragen (min 1 bit für administrative zwecke?) und mehrere müssen sich die "bandbreite leider teilen, wenn gleichzeitig".
-eine weitere möglichkeit wären ultraschnelle iterationen von primary aus gestartet? -> das haut gut auf die cpu, wenn ich mich recht erinnere und low latency ist gleich mal raus?

ja das video hat kein ton
schönen freitag abend noch

oh da haben wohl 2 gleichzeitig ...

Quietschboy hat geschrieben: Das mit dem Exponent = 0 stimmt nicht wirklich, da noch eine "Normalisierung" für die Float stattfindet, aber ich denke so läßt es sich als Modell ganz gut verstehen.

wie bitte?
bis zum letzten satz konnte ich dir folgen, und nun ist alles wieder verpufft
oder soll ich das einfach ignorieren?

zu 1.:
Naja, die Umwandlung nach Float stellt eine Hürde, eine Einschränkung dar. Darauf wollte ich ja hinaus. Die Zahl 1254 läßt sich noch locker 1:1 nach Float und zurück nach integer wandeln, aber für die Zahl 2 hoch 31 minus 1 sieht es schlecht aus.

zu 2:
Oh ja! Das ist ein sehr schönes Beispiel des Bitmultiplexings.
Hier wird (ohne in die Struktur gesehen zu haben...) wohl das Mischen per BIT OR der 1-Bit Werte (An/Aus) gemacht. Genau das und auch das Mischen von höheren Zahlen mit mehreren Bits soll der Bit Multiplexer können. Genau dieses System wird beispielsweise auch im "synchronous Write" Macro vom Partial Framework zur Erstellung der Inport Flags verwendet. Ebenso im ACEW (=synchronous write...) und es wird auch im Bit Multiplexer für die Flags genutzt werden.

Warum das der Programierer vom Kodiak Shift Sequenzer eingesetzt hat kann ich dir ohne reingeschaut zu haben nicht sagen, aber es ist auf jeden Fall eine smarte Lösung. Spart zumindest schonmal Speicherplatz.
Ob sich das bei Init in der Performance gut macht kann man schlecht sagen, da ja auch das Demultiplexing wieder etwas Power kostet.
Ah Ok, man möchte mehrere solcher Scales (1 Scale = mehrere Werte/Noten/OnOff) in einem Snap Array speichern. D.h. die komplette Scale muss in eine Array Zelle passen. Klar.

Zu dem Exponent = 0:
nun ja...
Die Zahl 1254 wird, wenn man mal im Dezimalsystem bleibt, als 1,254 x 10 hoch 3 geschrieben. Das heißt der Exponent ist 3. Allerdings muss man das vorher noch ins Binärsystem umrechnen, wo die Basis dann 2 nicht 10 ist. Der tatsächliche Exponent ergibt sich dann auch noch.
---> Wikipedia
oder
---> vergessen
is hier nich so wichtig