Deutsches Reaktor Forum

im core-handaus steht ne sache, die ich niet recht begreifen will (defacto sinds einige sachen die ich partout nich begreife, aber für heute solls erstmal nur die sein).

latching vs. routing:

die aussage is in etwa folgende: wenn möglich verwendet latches anstelle router, da letztere entschieden mehr cpu verbrauchen. wie dass?? sofern ich den rest halbwegs verstanden hab is n latch doch nix anderes als n speicher und ne write/read einheit, die den lesebefehl erst sendet, wenn ein dafür dezidiertes "event" eintrifft.. was ist aber dann ein router? für mein verständniss doch exakt dasgleiche, nur eben in mehrfacher ausführung (ergo ein latch mit mehreren array-feldern): er verzögert die geschriebenen (gehaltenen) werte, bis zum zeitpunkt eines expliziten triggers (dem wert am "pos" eingang). wo ist da der unterschied???

bzw. kann man diesen tip auf primary übersetzen (llieber ne armada an order, seperator, value module anstelle eines routers???)

ich bin verwirrt. beim ca. handuch-gleichseitigen tip bezüglich des merge-modules würde mein laien-verstand das ja noch einsehen (irgend ne art clock taktet permanent und vergleicht pro schlag 2 oder mehr anliegende werte auf veränderung, bzw. neusendung und öffnet bei übereinstimming n anderes "gate"), aber beim router??? das sind ist doch reinste ein-bit entscheidungen und im falle "event" doch unhabhängig jedglicher taktungsnotwendigkeiten, alles reines ja/nein, oder überseh ich was?

latches sollte man benutzen, um eintreffende events in audio-core-Zellen z.B. mit der sample-rate-clock oder Eingangssignalen zu synchronisieren. Damit kann man die Gleichzeitigkeit sicherstellen.

deine aussage impliziert doch aber, das latches mit der SR getaktet werden, ergo müssten sie doch mehr cpu verbraten als n simpler router, der seine entscheidung nur trifft, wenn sich der pos-zuastand ändert, also entschieden "diskreter" rechnet, oder?

helmsklamm hat geschrieben:deine aussage impliziert doch aber, das latches mit der SR getaktet werden, ergo müssten sie doch mehr cpu verbraten als n simpler router, der seine entscheidung nur trifft, wenn sich der pos-zuastand ändert, also entschieden "diskreter" rechnet, oder?

Latch und Router sind in ihrer Funktion nicht identisch, denn ein Router verzweigt ja, während ein latch nur kontrolliert Werte weiterleitet. Warum ein Router so viel CPU-intensiver können wir von außen nicht bewerten, da wir ja nicht die Kompilierung kennen.

was heisst das nun fürs prim? sooft wie möglich latchen (value-modul) anstelle router zu nutzen??

helmsklamm hat geschrieben:was heisst das nun fürs prim? sooft wie möglich latchen (value-modul) anstelle router zu nutzen??

das weiß ich auch nicht; ich finde event-Verarbeitung in core wesentlich einsichtiger als auf prim-Seite, deshalb habe ich mir angewöhnt, alle event-Rechnungen möglichst in Core-durchzuführen und die prim-Ebene möglichst nur für das GUI zu benutzen. Ich denke darauf wird es auch wohl in Zukunft hinauslaufen.