Bit Multiplexing, integer vs float

Diskussionsforum für Fragen zur Struktur und Implementation in REAKTOR, auch DSP, Literatur und begleitende Software

Moderator: herw

Bit Multiplexing, integer vs float

Beitragvon Quietschboy » Mi 4. Jan 2012, 01:36

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. :lol:
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
Dateianhänge
bit multiplexing - int vs float.ens
(168.08 KiB) 123-mal heruntergeladen
Quietschboy
meister
 
Beiträge: 177
Registriert: Mi 6. Apr 2011, 21:31
Wohnort: Wiesbaden

Re: Bit Multiplexing, integer vs float

Beitragvon Triton » Di 10. Jan 2012, 23:22

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.
Benutzeravatar
Triton
synthesist
 
Beiträge: 58
Registriert: So 1. Aug 2010, 18:22
Wohnort: Gießen

Re: Bit Multiplexing, integer vs float

Beitragvon Quietschboy » Fr 20. Jan 2012, 08:51

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.
ACEO Multiout Core Part.jpg
ACEO Multiout Core Part.jpg (33.35 KiB) 1803-mal betrachtet
ACEO Multiout Primary.jpg
ACEO Multiout Primary.jpg (18 KiB) 1801-mal betrachtet
Quietschboy
meister
 
Beiträge: 177
Registriert: Mi 6. Apr 2011, 21:31
Wohnort: Wiesbaden

Re: Bit Multiplexing, integer vs float

Beitragvon Triton » Sa 28. Jan 2012, 01:37

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.
Benutzeravatar
Triton
synthesist
 
Beiträge: 58
Registriert: So 1. Aug 2010, 18:22
Wohnort: Gießen


Zurück zu REAKTOR (kreativ)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron