Demux - irgendwas buggt

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

Moderator: herw

Demux - irgendwas buggt

Beitragvon Eventmanager » Mo 15. Dez 2014, 14:06

Vielleicht mach ich grundlegend was falsch: Zum MUXEN nutze ich ganz einfach Prim-Merges und da ich 24 Quellen habe, benötige ich 48 Ports, also 8 mehr als ein Merge erlaubt.
Das Ganze sieht dann so aus


Die grundlegende Frage: ist das als Muxer brauchbar (sauber)?
Zum entmuxen nutze ich diese Cell.

Prinzipiell tut der Verbund seinen Dienst, Problem kommt auf, wenn der Demuxer mit einer default-0-Quelle versehen wird, die keine weiteren Events erzeugt.
Das liegt wahrscheinlich am Router. Wenn er analog zu Prim funzt, wird er ein neues Event nur durchschleusen, wenn es NACH dem Umschalten generiert wurde, was die default-0-Quelle aber nur bei Initialisierungsvorgängen tut, folglich behält er den letzen "aktiven" Wert einer nicht mehr aktuellen ID.

Jawoll, das Problemchen liesse sich schnell lösen, indem man diese Def-0 permanent mit ControlRate triggert oder den Router mit ner Art Relais ersetzt. Beim zweiten Lösungsvorschlag, der mir lieber wäre, bin ich mir aber nicht sicher. Beim Eintauchen in den Demuxer ist mir aber aufgefallen, das die ID am Eingang und die ID am Ausgang der Cell selten überstimmt, was bei 24 parallelen Signalen wohl auch einleuchtend ist. Ein Watcher zeigt auch, das alle IDs, die neue Events erzeugen "parallel" abgearbeitet werden. Und anscheinend nur diese, die IDs, welche keine neuen Events generieren bleiben anscheinend unbeachtet. Ich vertraue einfach darauf das zur richtigen Zeit am Compair die passenden IDs verglichen werden.
Die Frage ist nun, ob ich den Router mit nem Relais oder Selektor ersetzen kann oder geht dabei das ID/Value Paar flöten?

Ich hab einige "statische" Quellen, die über lange Zeiträume keine neuen Events erzeugen, ich will die nicht alle CR-triggern müssen. Ich will aber auch beim switchen nicht ständig neu-initialiiseren müsssen. Was also am effektivsten tun?
Und die letzte Frage, habe ich das Demux so grundlegend verstanden, ist mein Prim-Merge-Mux sauber?
Dateianhänge
Bildschirmfoto 2014-12-15 um 11.55.28.png
Bildschirmfoto 2014-12-15 um 11.55.28.png (46.05 KiB) 2849-mal betrachtet
Bildschirmfoto 2014-12-15 um 12.12.15.png
Bildschirmfoto 2014-12-15 um 12.12.15.png (6.11 KiB) 2849-mal betrachtet
Eventmanager
meister
 
Beiträge: 178
Registriert: Di 25. Jun 2013, 16:26

Re: Demux - irgendwas buggt

Beitragvon herw » Mo 15. Dez 2014, 17:08

Du willst also beim Intialisieren 24 konstante Werte in eine CoreCell einschleusen? Wie sieht die corecell automata innen aus?
Am einfachsten ist, du lädst ein kleines Ensemble hier hoch!

Prinzipiell tut der Verbund seinen Dienst, Problem kommt auf, wenn der Demuxer mit einer default-0-Quelle versehen wird, die keine weiteren Events erzeugt.
Das liegt wahrscheinlich am Router. Wenn er analog zu Prim funzt, wird er ein neues Event nur durchschleusen, wenn es NACH dem Umschalten generiert wurde, ...

eben nicht, core kennt die Gleichzeitigkeit!

ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 3045
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Demux - irgendwas buggt

Beitragvon Eventmanager » Mo 15. Dez 2014, 18:44

herw hat geschrieben:Du willst also beim Intialisieren 24 konstante Werte in eine CoreCell einschleusen?


Nicht zwingend, mir ist lediglich wichtig das der aktuell anliegende Wert der korrespondierenden ID hinten rauskommt. Und zwar ohne nötige Werteänderung. Im Gegenteil versuche ich ein INIT zu vermeiden.
Der Switch dient nur der Demonstration das es MIT Init funzt, aber eben nicht ohne.
Die meisten Ports sind unbestückt, Vorliegendes sollte aber zu Tetszwecken genügen.
Dateianhänge
MUXcrux.ens
(846.24 KiB) 132-mal heruntergeladen
Eventmanager
meister
 
Beiträge: 178
Registriert: Di 25. Jun 2013, 16:26

Re: Demux - irgendwas buggt

Beitragvon herw » Mo 15. Dez 2014, 21:21

Eventmanager hat geschrieben:
herw hat geschrieben:Du willst also beim Intialisieren 24 konstante Werte in eine CoreCell einschleusen?


Nicht zwingend, mir ist lediglich wichtig das der aktuell anliegende Wert der korrespondierenden ID hinten rauskommt. Und zwar ohne nötige Werteänderung. Im Gegenteil versuche ich ein INIT zu vermeiden.
Der Switch dient nur der Demonstration das es MIT Init funzt, aber eben nicht ohne.
Die meisten Ports sind unbestückt, Vorliegendes sollte aber zu Tetszwecken genügen.

hmm: du vermischst aufgrund der Ensemble-Struktur sehr stark primary Denkweise und core-Denkweise (primary value-Module).

Ich habe mal eine Lösung mit partials framework hinzugefügt; vielleicht kannst du das ja benutzen.
ciao herw
Dateianhänge
MUXcrux 2.ens
(892.96 KiB) 138-mal heruntergeladen
Benutzeravatar
herw
moderator
 
Beiträge: 3045
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Demux - irgendwas buggt

Beitragvon Eventmanager » Mo 15. Dez 2014, 23:29

Vielleicht übersehe ich was, aber deine Lösung ist keine. Zumindest nicht gemäss der Aufgabenstellung.
Ich tendiere dazu, mich unnötig verblümt auszudrücken, Ich wiederhole nochmal was ich möchte:
Ein Ausgeben des aktuellen Wertes der aktuell durchgeschalteten, korrespondierenden ID-Quelle, sobald diese definiert wurde, also direkt nach dem Umschalten.

Das leistet weder deine, noch meine Schalte.
Deine scheint aber generell "robuster" zu sein, denn sobald deine und meine am ACEW hängen, macht meine garnix mehr, wohingegen DEINE zumindest das tut, was MEINE ohne dem "nachschalten" DEINER Lösung tut.
Klingt nach Wünschelroute und Azsendenten im 7ten Haus?
Init-sette "Meine" Lösung mal mit und mal ohne deine "Lösung" (mute port 3/4).
Mein Vokabular präferiert dafür einen Term: obskur!!!

Selbst wenn deine Zusatzmodule einen versteckten Init oder das Gegenteil provozieren - dann müsste meine Schalte irgendwie reagieren. Entweder ist der ACEW im Popo oder es geschen doch Dinge, lieber Horatio, die wir nie ergründen werden?

Hey, aber abgesehen davon: Vielen Dank
Eventmanager
meister
 
Beiträge: 178
Registriert: Di 25. Jun 2013, 16:26

Re: Demux - irgendwas buggt

Beitragvon Quietschboy » Mi 17. Dez 2014, 00:10

Also ich kann beim Beispiel MUXcrux keinen ACEW im Popo erkennen.
Ich bin mir aber auch nicht ganz sicher, ob ich dich richtig verstanden habe?!?
Möchtest du, daß beim Umschalten der ID, also beim Betätigen des ID-Reglers, der zuletztempfangene Wert am entsprechenden Eingang deines Muxers vom Demuxer abgerufen und ausgegeben wird? So wie beim Selector/Scanner?
Dann brauchst du einen Zwischenspeicher!
Wenn dein Demuxer sowieso schon in Core läuft, bau doch gleich ein Array rein und schreibe die ankommenden Werte darein (oder Event Table in Primary). Mit deinem ID-Regler rufst du lediglich die entsprechende Speicherzelle für die Ausgabe auf.

War es das, was du wolltest?
Quietschboy
meister
 
Beiträge: 178
Registriert: Mi 6. Apr 2011, 21:31
Wohnort: Wiesbaden

Re: Demux - irgendwas buggt

Beitragvon Eventmanager » Mi 17. Dez 2014, 00:52

Hi Kwitschkommode;)

Mittlerweile haben wir hier 2 Fragestellungen, ich schlage vor, die separiert zu behandeln.

1.
Lade mal bitte den Muxcrux2, also das Teil das Herw hier reingestellt hat.
Dann mute mal die Ports 3und4 am ACEW, ändere die ID und betätige den Switch.
Meine Schalte, die vom ACEW 1 und 2 detektiert wird, wird sich ändern.

Nun resette und aktiviere am ACEW auch die Ports 3 und 4 (Herws Verdrahtung).
Wenn du nun exakt das gleiche wie oben vollführst, wirst du festellen das am ACEW 1 und 2 keine Daten ankommen, zumindest nicht ausgegeben werden.

Das ist mysteriös.

------------------

2.
Ja, ich wünsch mir einen Demuxer, der hinten ähnlich einem Selektor arbeitet, also sobald die ID geändert wird, schleust er auch das korrespondierende Value durch. Dein Array-Vorschlag klingt pfiffig und ist sicherlich effizienter als das Table (ich brauch das Ding dutzendfach und mit seperaten Tables).
Was ich nicht verstehe - wenn die ID nicht aktiv ist, wie kann dann das Table/Array die aktuellen Daten empfangen???? Oder wird das Ganze woanders abgefangen?
Mux ist schon ne echte Geisterbahn, ich "mux" wohl mein serielles Strippen-Denken komplett updaten.

Dein Satz "wenn dein Demuxer sowieso schon in Core läuft...." impliziert für mich eine Möglichkeit, das das auch in Prim realisierbar ist????
Eventmanager
meister
 
Beiträge: 178
Registriert: Di 25. Jun 2013, 16:26

Re: Demux - irgendwas buggt

Beitragvon Quietschboy » Mi 17. Dez 2014, 02:04

Eventmanager hat geschrieben:1.
Lade mal bitte den Muxcrux2, also das Teil das Herw hier reingestellt hat.
Dann mute mal die Ports 3und4 am ACEW, ändere die ID und betätige den Switch.
Meine Schalte, die vom ACEW 1 und 2 detektiert wird, wird sich ändern.

Nun resette und aktiviere am ACEW auch die Ports 3 und 4 (Herws Verdrahtung).
Wenn du nun exakt das gleiche wie oben vollführst, wirst du festellen das am ACEW 1 und 2 keine Daten ankommen, zumindest nicht ausgegeben werden.

Das ist mysteriös.

Also ich habe deine und Herwigs Inports am ACEW aktiviert, ändere die ID und habe nach dem Re-Init (Switch gedrückt) auf allen 4 Eingängen Init-Events anliegen. Alles gut. Hast du im ACEW schon den dicken, fetten Scrollbalken oben rechts entdeckt, geschweige denn das Manual dazu gelesen? :wink:

Eventmanager hat geschrieben:2.
Ja, ich wünsch mir einen Demuxer, der hinten ähnlich einem Selektor arbeitet, also sobald die ID geändert wird, schleust er auch das korrespondierende Value durch. Dein Array-Vorschlag klingt pfiffig und ist sicherlich effizienter als das Table (ich brauch das Ding dutzendfach und mit seperaten Tables).
Was ich nicht verstehe - wenn die ID nicht aktiv ist, wie kann dann das Table/Array die aktuellen Daten empfangen???? Oder wird das Ganze woanders abgefangen?
Mux ist schon ne echte Geisterbahn, ich "mux" wohl mein serielles Strippen-Denken komplett updaten.

Was heißt denn, "wenn die ID nicht aktiv ist"? Das Array muß ALLES empfangen und speichern. Du hast doch mit deinem Muxer/Demuxer bisher alles richtig gemacht. Die ID, oder besser gesagt den Index, zum Adressieren der Speicherzelle liefert dein Bus-System selbst! Der Bus liefert zuerst den Index und danach folgt der Wert (Value). Fertig ist der Lack. Den Rest zum Core Array kannst du nachlesen.
Ob das Core Array nun effizienter ist als das Primary Event Table kann ich nicht beurteilen. Das Schema zum Schreiben / Lesen ist auf jeden Fall fast gleich. Geschmacksache oder Zwangsläufigkeit. Je nach dem.

Wenn du mehr zum Thema Multiplexing lernen möchtest, kann ich dir nur Max´s PDFs vom Partial Frameworks empfehlen. Dort wird auch (zu Beginn :lol: ) eine simple Primary-Demuxer Variante aufgeführt.
Grüße, QB
Quietschboy
meister
 
Beiträge: 178
Registriert: Mi 6. Apr 2011, 21:31
Wohnort: Wiesbaden

Re: Demux - irgendwas buggt

Beitragvon Eventmanager » Mi 17. Dez 2014, 20:11

Quietschboy hat geschrieben:. Hast du im ACEW schon den dicken, fetten Scrollbalken oben rechts entdeckt, geschweige denn das Manual dazu gelesen? :wink:



Hier saß das Problem eindeutig vor dem Rechner;) Da ich den ACEW immer vor jedem Start resette, dachte ich das reicht - es kommen natürlich mehr Daten an, als in einer Zeile darstellbar sind. ><:
Da gibts ein Manual zu?

---------------

Da werd ich wohl mal mein Kore-handbuch ausgraben müssen.
Zanglers PDF sollte ich mir vielleicht auch mal antun, aber sowas Abstraktes auch noch auf englisch???? - puh!

Vielen Dank einstweilen.
Eventmanager
meister
 
Beiträge: 178
Registriert: Di 25. Jun 2013, 16:26


Zurück zu REAKTOR (kreativ)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron