Istgleich-compair mit fuzzy-logic

[Eventmanager]

Wie baut man ein "Istgleich" compair, das nicht einen exakten Wert sondern auch Werte innerhabl eine Range als GLEICH akzeptiert, also bspw. statt nur 0.2436 = gleich ist, sondern auch alles was zwischen 0.242 und und 0.244 liegt als GLEICH eingestuft wird. In Prim brauch ich dafür x-Module (ein simples Quantify tuts eben nicht, eher ein GRÖSSER und ein KLEINER Modul+++)... In Core geht das doch bestimmt eleganter, aber bitte nicht die ganze Lösung verraten, lieber nen kleinen Tipp welches Macro oder Modul sollte ich mir da mal genauer anschauen sollte! Danke.

[herw]

Wie baut man ein "Istgleich" compair, das nicht einen exakten Wert sondern auch Werte innerhabl eine Range als GLEICH akzeptiert, also bspw. statt nur 0.2436 = gleich ist, sondern auch alles was zwischen 0.242 und und 0.244 liegt als GLEICH eingestuft wird. In Prim brauch ich dafür x-Module (ein simples Quantify tuts eben nicht, eher ein GRÖSSER und ein KLEINER Modul+++)... In Core geht das doch bestimmt eleganter, aber bitte nicht die ganze Lösung verraten, lieber nen kleinen Tipp welches Macro oder Modul sollte ich mir da mal genauer anschauen sollte! Danke.

Das ist noch nicht genau genug beschrieben.
Soll es ein Vergleich bei der dritten Stelle nach dem Komma sein, oder soll es ein Vergleich in der dritten Stelle insgesamt sein, also zum Beispiel 2436 und vergleich innerhalb das Interfvalls 2420 und 2440?
Ich vermute mal nur für Zahlen zwischen 0 und 1?
Core ist für solcher Art Event-Vergleiche sehr gut geeignet.

Tipp 1: Stelle unbedingt vorher klar dar, welche Intervalle die Fuzzy-Logik benötigt (feste Intervalle?). Also sollen die Vergleichsintervalle in festen Schritten ansteigen?
Tipp 2: Kann man mit Rundungen arbeiten? Falls ja, dann schaue dir unbedingt die Makros in Partials Framework an:

Rundungen.png

Du findest diese unter partials_framework_1.1/standard_library/core/math.
Tipp 3: Falls es wirklich nur um die dritte Stelle geht, dann kann man die Eingangswerte entsprechend multiplizieren, so dass die relevanten Stellen vor dem Komma liegen und man durch entsprechende Rundungen nur mit integer-Zahlen arbeitet.
Tipp 4: Erstelle wenn möglich sofort ein allgemeines core-Makro, so dass du es für deine Zwecke mehrfach verwenden kannst. Vergiss nicht das Makro in den Infos zu beschreiben, so dass du (und andere) auch nach Monaten noch erkennen könne, was eigentlich passiert.
Tipp 5: Wenn die Logik auch für Audio-Events benutzt werden soll, dann arbeite mit möglichst wenigen Vergleichen.

Ich hoffe, das war erstmal allgemein genug.

Zum Training würde ich tatsächlich sowohl ein primary- als auch ein Core-Makro erstellen, um einfach die primary-Krücken zu erkennen.
Vielleicht gibt es mehrere core-Lösungen. Benutze unbedingt ACEW als Kontrolle.

[Eventmanager]

Die Lösung in Prim ist eigentlich auch ganz simple, lässt sich ja auch ziemlich exakt in Core nachbilden, aber darum gehts ja hier nicht, ich will ja neue Wege kennenlernen. Ich schau mir dir Module mal in Ruhe an. Danke.

Bildschirmfoto 2019-08-06 um 10.15.26.jpg

[herw]

Bin gerade noch auf der Autobahn. Da kann ich Reaktor nicht aufrufen - noch ca. 500km. Morgen habe ich Zeit.
Natürlich bin ich im Moment nur Beifahrer.
Übrigens hänge mal anstelle der Lampe den ACEW an.

[Eventmanager]

Übrigens hänge mal anstelle der Lampe den ACEW an.

Ja doch Papi, gewöhn ich mir grad an;-) Ebenso wie als "default" IMMER nen step-filter hinten dran zu klemmen. (ausser ich weiss genau, das auch IDENTISCHE values "triggern" sollen). Für ultra-schnell-test verfall ich halt immer noch in schnelle "Kontrollgewohnheiten". Aber grad auch hier schön zu sehen wieviel Müll ohne step-filter ankommen würde. Dazu brauch man idT nen ACEW und 2 ports einmal mit und einmal ohne steppy bestückt...
(Bin übrigens so dankbar über die Send-Variante des ACEW --- endlich ist das Teil auch aus stack-macros heraus relativ schnell nutzbar... .

#####
BTW: gibts für die table-wire(ports) auch ein step/-init-filter? Mein core-init-filter und Core-router allgemein akzeptieren diese Kabel jedenfalls nicht, und der prim-step-filter auch nicht, der prim-router schon....!

####

Ich find in der (UL kein partials framework 1.1 - nur son 8 jahre altes Teil von stephan schmitt himself und ein add-one von dir (3 Jahre alt oder so).... meinst du das????
Das klassische core-"round" ist doch nur ein float to integer Hart-QUANTIZIERER, ganz simple via port-einstellungen gelöst. Elegant! Kann man ja auch mit Zusatzmodulen weiter ausdehnen (vor dem float-IN bspw. mit 100 multiplizieren und nach dem "Integer"-Out dann wieder mit 0.01 multiplizieren (oder 100 dividieren).... am Ende ist das halt ein QUANTIZIERER der noch kleinere Nachkommastellen (in diesem Fall auf 0.01) "rundet". Aber wie immer bleibt das Problem der unbestimmten 0.5, egal um wieviele Nachkommastellen verschoben, am Ende ist es Zufall ob X.xxxxxxxxxxx......5 nun auf- oder abgerundet wird?????
Bei meinem Pseudo "IstGleich" ist jedenfalls sichergestellt das alles plus(minus (ergp fuzzy) als "istgleich" akzeptiert wird....

####
Ach und ganz blöde Frage, liegst an meiner R6 Library???? In R5 kann ich jedenfalls schnell ein core-Macro einfügen (und hier auch markierte/kopierte Teile + ports aus dem Eltern-Macro einfügen... ) in R6 gibts dieses core-macro nicht mehr, jedenfalls find ich es nicht.... liegt mglw. an meiner sültsamen "Library" Structure, oder ist das auch wieder weg-"aufgeräumter" worden, wie bspw. das Fehlen von Macros>, Cells>, Instruments>... per einfachem structure-rechtsklick????? FALLS es an meiner Library liegt, bitte mal nen Screeni, einer sauberen Library... den rest fitzel ich dann schon raus... aber scheinbar muss hier jedes warhaft jedes I seinen VORGESEHEN strich und im korrekt bnannnten Zentralordner plus hochnotpeinlich penibel benannter Unterordner haben...

####
So viele Fragen und wir haben noch nicht mal wirklich angefangen;-) Upsala, das kann ja heiter werden;-)

[herw]

Übrigens hänge mal anstelle der Lampe den ACEW an.

Ja doch Papi, gewöhn ich mir grad an;-)

trag erst mal dein Geburtsdatum ein

Ebenso wie als "default" IMMER nen step-filter hinten dran zu klemmen. (ausser ich weiss genau, das auch IDENTISCHE values "triggern" sollen). Für ultra-schnell-test verfall ich halt immer noch in schnelle "Kontrollgewohnheiten". Aber grad auch hier schön zu sehen wieviel Müll ohne step-filter ankommen würde. Dazu brauch man idT nen ACEW und 2 ports einmal mit und einmal ohne steppy bestückt...
(Bin übrigens so dankbar über die Send-Variante des ACEW --- endlich ist das Teil auch aus stack-macros heraus relativ schnell nutzbar... .

#####
BTW: gibts für die table-wire(ports) auch ein step/-init-filter? Mein core-init-filter und Core-router allgemein akzeptieren diese Kabel jedenfalls nicht, und der prim-step-filter auch nicht, der prim-router schon....!

####

Ich find in der (UL kein partials framework 1.1 - nur son 8 jahre altes Teil von stephan schmitt himself und ein add-one von dir (3 Jahre alt oder so).... meinst du das????

ja - acht Jahre heißt in dem Fall nichts, da es immer noch hoch aktuell ist. Das Multiplexing ist genial und lässt sich kaum verbessern, wenn überhaupt. Die Umschiffung der fehlenden Iteration in Core ist ebenfalls (leider) immer noch aktuell.

Das klassische core-"round" ist doch nur ein float to integer Hart-QUANTIZIERER, ganz simple via port-einstellungen gelöst. Elegant! Kann man ja auch mit Zusatzmodulen weiter ausdehnen (vor dem float-IN bspw. mit 100 multiplizieren und nach dem "Integer"-Out dann wieder mit 0.01 multiplizieren (oder 100 dividieren).... am Ende ist das halt ein QUANTIZIERER der noch kleinere Nachkommastellen (in diesem Fall auf 0.01) "rundet". Aber wie immer bleibt das Problem der unbestimmten 0.5, egal um wieviele Nachkommastellen verschoben, am Ende ist es Zufall ob X.xxxxxxxxxxx......5 nun auf- oder abgerundet wird?????

Die Rundungen sind durch die Norm IEEE 754 festgelegt und absolut sauber programmiert. Wenn du eine mathematische Rundung (wie in der Schule) wünschst, dann kann ich dazu morgen mein Makro unter der Kategorie Fundgrube liefern (tricky und einfach).

Bei meinem Pseudo "IstGleich" ist jedenfalls sichergestellt das alles plus(minus (ergp fuzzy) als "istgleich" akzeptiert wird....

####
Ach und ganz blöde Frage, liegst an meiner R6 Library???? In R5 kann ich jedenfalls schnell ein core-Macro einfügen (und hier auch markierte/kopierte Teile + ports aus dem Eltern-Macro einfügen... ) in R6 gibts dieses core-macro nicht mehr, jedenfalls find ich es nicht.... liegt mglw. an meiner sültsamen "Library" Structure, oder ist das auch wieder weg-"aufgeräumter" worden, wie bspw. das Fehlen von Macros>, Cells>, Instruments>... per einfachem structure-rechtsklick????? FALLS es an meiner Library liegt, bitte mal nen Screeni, einer sauberen Library... den rest fitzel ich dann schon raus... aber scheinbar muss hier jedes warhaft jedes I seinen VORGESEHEN strich und im korrekt bnannnten Zentralordner plus hochnotpeinlich penibel benannter Unterordner haben...

####
So viele Fragen und wir haben noch nicht mal wirklich angefangen;-) Upsala, das kann ja heiter werden;-)

naja - wird schon

[herw]

Falls jemand an diesem Thread Interesse hat und noch nie etwas von Fuzzylogik gehört hat, der findet eine grundsätzliche und in den ersten Abschnitten einfache Einweisung hier: Fuzzylogik (Unschärfelogik)
Wenn ich mir die Schaltung von Eventmanager ansehe, dann ist der prinzipielle Ansatz, das Ergebnis des Vergleichs in Boolesche Algebra umzuwandeln, nicht im Sinne von Fuzzylogik.
Aber das ist natürlich Erbsenzählerei, wenn man die Intention der ursprünglichen Frage sieht: es geht darum, Näherungswerte als „noch gleich” mit einer vordefinierten „Genauigkeit” zu akzeptieren.

[herw]

Soll ich da wirklich ein Fass aufmachen? Dann wird es länger.
Also bitte umgehend Interesse bekunden und am Ball bleiben (Thema auf „beobachten” schalten), sonst ist es vergebliche Mühe.

[Eventmanager]

Hab jetzt erstmal das framework gelutscht - is ja ne Menge Dokumentation dabei. Sehr löbliich. Muss ich erstmal durchackern. Bis demnächst!
Deinen letzten Post versteh ich nicht????

[herw]

Hab jetzt erstmal das framework gelutscht - is ja ne Menge Dokumentation dabei. Sehr löbliich. Muss ich erstmal durchackern. Bis demnächst!
Deinen letzten Post versteh ich nicht????

Ich würde folgende Themen ansprechen wollen:

• Analyse deines fuzzy-Vergleichs anhand deiner Grafik
• Vergleich von primary und core
• mögliche Optimierung und Grenzen der Struktur
• grundsätzliche Probleme beim Vergleich

[Eventmanager]

Sprich gerne alle Themen an, meinen Segen hast du Jedenfalls hab ich nix dagegen wenn freds ne "offttopic"- eigendynamik entwickeln

Speziell thema prim vs core und optimierung leigen mir derzeit am Herzen. Das ich mit fuzzylogic nur halbkorrekt einen "geschützten" Term verwendet habe, ist ja nun klar: Ich meinte "nährungsweise Gleichheit".
Erste Frage zu prim und core. Generell ist wohl konsens sowenig zwischen prim- und core herumzuwurscgteln, aber betrifft das auch reine Event-Cells, oder nur Sachen wo ne Sample-Clock oder ähnliches verwendet werden muss?
Ich zähle 5 Dup Fit Macros... der Unterscheid zwischen I(nterger) und und non-I (ergo float) ist schon klar, ebenfalls die Toleranzversion, aber was unterscheidet die anderen beiden Varianten?????

###
Hab mir die Round-Nacros mal angeschaut, für obige Verwendung sehe ich da keine Hilfe, allerdings kann so dezidiertes Round-Up/dwn hin und wieder sehr nützlich sein, statt die prim-stunts die sonst dafür von Nöten wären.
BTW: wenn bspw. sowas wie im Bild haben will, also einen 0.01-Quantizierer, A) bekomme ich das eleganter hin und B) wäre das irgendwie von Vorteil (zumindest nicht nachteilig) wenn ich mir dergleichen in Core-Cells bastel? Vorteil wäre auf jeden Fall, zu bestimmen wo "gerundet" wird bei also bei entsprechenden Nachkomma 0, 0.5 oder 1.... zumindest wenn das korrekt implementiert ist, mit dieser Krücke wird dann wieder bei jedem 0.005 gerundet statt erst bei 0.01

[herw]

Mann oh Mann, manchmal bist du echt schwer zu verstehen. Ich würde gerne schnell antworten, aber ich brauche mehrere Minuten, um zu kapieren, was du meinst. (sorry), wenn ich es überhaupt kapiere.

[...]
Erste Frage zu prim und core. Generell ist wohl konsens sowenig zwischen prim- und core herumzuwurscgteln, aber betrifft das auch reine Event-Cells, oder nur Sachen wo ne Sample-Clock oder ähnliches verwendet werden muss?

(???) Nach einer (realen) Dusche und ca. 15 Minuten habe ich es gerafft:

Also: Ist es sinnvoll, so wenig wie möglich zwischen der primary-Ebene und core-Ebene zu wechseln? (sorry, ich muss die Frage zunächst mal für mich selbst sortieren. )
Ja es ist sinnvoll, und zwar insbesondere auch bei reinen primary events. Der Grund ist das unterschiedliche Initialisierungsverhhalten und zwar in den einfachsten Fällen. Die primary-Ebene kann im Gegensatz zur core-Ebene selbständig events von Panelelementen und Konstanten erzeugen. In core gibt es als einzige Quelle die SampleRateClock SRC. Alle anderen Quellen stammen von den CoreCell-Eingängen ab. Core-Konstante erzeugen keinen event!
Core unterscheidet im Gegensatz zu primary nicht zwischen audio-events (SRC-synchronisierte events) und events, die über das primary-GUI über die Eingänge importiert werden.
Ein häufiger Wechsel zwischen primary und core kann zum Beispiel bewirken, dass durch die zwischengeschalteten primary-Makros eventuell zusätzliche events in die folgenden CoreCells gelangen, die nicht erwünscht sind oder einer anderen Synchronisation unterliegen. Bei überschaubaren Ensembles, die vor allem unkritisch gegenüber GUI-event-Initialisierungen sind, wird das keine große Sache sein.
Die Frage ist natürlich, warum man überhaupt zurück zu primary wechseln soll, wenn man eh schon vorhat, Berechnungen in core vorzunehmen. Nun, die Berechnungen in primary sind verglichen mit den Möglichkeiten in core (64-bit Rechengenauigleit) ohnehin schon arg beschränkt. Bei einfachen Berechnungen mag das unwichtig sein, aber ich kann dir gerade an dem Beispiel des fuzzy-Vergleichs grundlegende Unterschiede aufzeigen, die ein völlig unterschiedliches Verhalten nach sich ziehen.
Will man ernsthaft in die Core-Programmierung für große Projekte einsteigen, dann ist die strikte Trennung von GUI-Bearbeitung (in primary) und Signalverarbeitung (in core) absolut Pflicht. Primary verwendet man dann nur als Datenquelle aus dem GUI und zur Anzeige (EventTables, numerische Anzeigen etc.).
Man umgeht dann Schwierigkeiten bei der Initialisierung.
Es gibt eine wundervolles kleines essay (siehe Anhang) von Max zum Thema threads in Reaktor - einfach zu lesen und eindrucksvoll.

huh.jpg

Ich zähle 5 Dup Fit Macros...

wo? wieso 5?

der Unterscheid zwischen I(nterger) und und non-I (ergo float) ist schon klar, ebenfalls die Toleranzversion, aber was unterscheidet die anderen beiden Varianten?????

also: bitte lieber langsamer, dafür aber verständlicher schreiben, wenn möglich mit einem kleinen screenshot, wie du es ja weiter unten machst, damit ich weiß, worüber wir reden.
Übrigens kannst du die angefügeten screenshots direkt an der passenden Textstelle einfügen und im Beitrag anzeigen, indem du ...

im Beitrag anzeigen.jpg

...kurz anklickst.

[herw]

[...]
Hab mir die Round-Nacros mal angeschaut, für obige Verwendung sehe ich da keine Hilfe, allerdings kann so dezidiertes Round-Up/dwn hin und wieder sehr nützlich sein, statt die prim-stunts die sonst dafür von Nöten wären.
BTW: wenn bspw. sowas wie im Bild haben will, also einen 0.01-Quantizierer, A) bekomme ich das eleganter hin und B) wäre das irgendwie von Vorteil (zumindest nicht nachteilig) wenn ich mir dergleichen in Core-Cells bastel? Vorteil wäre auf jeden Fall, zu bestimmen wo "gerundet" wird bei also bei entsprechenden Nachkomma 0, 0.5 oder 1.... zumindest wenn das korrekt implementiert ist, mit dieser Krücke wird dann wieder bei jedem 0.005 gerundet statt erst bei 0.01

doch, doch, du wirst schon sehen. Ich wollte aber wissen, ob überhaupt Interesse an einer Erläuterung besteht.
Generell kann man nicht Fragen wie ...

• Gibt es einen Vorteil oder gar Notwendigkeit, ob man zum Beispiel ein dup-Filter einfügt oder nicht
• braucht man ein latch-Makro
• ist eine Umwandlung von integer in float wünschenswert?
• etc.

... beantworten.
Das hängt Alles unmittelbar mit dem Konsens der gesamten (gewünschten) Struktur und deren Verhalten ab. Man kann nur Spezialfälle erläutern und wird aus Erfahrung später auf eventuelle Ungereimtheiten vorbereitet sein.
Da dir offenbar die Rundung sehr am Herzen liegt, gehe ich in den nächsten Stunden darauf dirket ein. Die Programmiersprache REAKTOR orientiert sich an den Konventionen (hier speziell der Datentypen integer und float) aller Programmiersprachen. Daher gebe ich in solchen Fällen auch die Links zu den entsprechenden Hintergrundartikeln in Wikipedia an.

[Eventmanager]

Jo, manchmal versteh ich mein Geschreibsel selbst nicht mehr;-)
Ich hab einstweilen nicht vor, meine über Jahre gewachsenen (prim) Strukturen auf absehbare Zeit nach Core zu translaten.... Das würde mich ja wieder Jahre kosten.... zumal ich sowieso bei größeren Blöcken an X- Stellen wieder und wieder "raus" muss, weil es da neuen Display-Kram benötigt, oder Teile davon, kilometerweit woanders verarbeitet werden....
Also ich werds wohl, einstweilen wie in der Vergangenheit halten und CORE nur "kleinformatig" einsetzen, wenns nicht anders geht oder wenn init-kritisch....
Aber ich acker erstmal das Thread-PDF durch um überhaupt zu sehen und zu entscheiden wo ich meine Init-Frickelein besser von vornherein auf Core umswitche, das sind manchmal abenteuerliche mit x Order, Boolschen, Routern.... etc. Umwegen... irgendwie krieg ich es am Ende, alles sauber funzend hin, aber ich schätze das geht deutlich eleganter und irgendwie auch universeller... also das wäre ein Goal von mir bzgl. core. Extrem tiefer will ich aber einstweilen nicht einsteigen...
Ich zähle hier 5 mal Dup Flt - ist das bei dir (deiner LIB) anders?

[herw]

[/quote]

Jo, manchmal versteh ich mein Geschreibsel selbst nicht mehr;-)
Ich hab einstweilen nicht vor, meine über Jahre gewachsenen (prim) Strukturen auf absehbare Zeit nach Core zu translaten.... Das würde mich ja wieder Jahre kosten.... zumal ich sowieso bei größeren Blöcken an X- Stellen wieder und wieder "raus" muss, weil es da neuen Display-Kram benötigt, oder Teile davon, kilometerweit woanders verarbeitet werden....
Also ich werds wohl, einstweilen wie in der Vergangenheit halten und CORE nur "kleinformatig" einsetzen, wenns nicht anders geht oder wenn init-kritisch....
Aber ich acker erstmal das Thread-PDF durch um überhaupt zu sehen und zu entscheiden wo ich meine Init-Frickelein besser von vornherein auf Core umswitche, das sind manchmal abenteuerliche mit x Order, Boolschen, Routern.... etc. Umwegen... irgendwie krieg ich es am Ende, alles sauber funzend hin, aber ich schätze das geht deutlich eleganter und irgendwie auch universeller... also das wäre ein Goal von mir bzgl. core. Extrem tiefer will ich aber einstweilen nicht einsteigen...
Ich zähle hier 5 mal Dup Flt - ist das bei dir (deiner LIB) anders?

ach das meinst Du.
Da habe ich mir noch nie groß Gedanken gemacht. Ich finde aber die jeweiligen Infos völlig klar. Dort wird immer ausführlich erklärt, was das jeweilige Makro macht.

Dup Flt.jpg

Warum gibt es mehrere Versionen? Nun, im Gegensatz zu primary kann core die Datentypen integer und float unterscheiden, zumal man noch die Genauigkeit der floats zwischen 32 bit und 64 bit umschalten kann. Das ist in manchen Fällen (Stimmgenauigkeit eines Oszillators beispielsweise) wichtig. Primary ist da ungenauer.
Das Makro Dup Flt (Tol) finde ich schon sehr luxuriös.

Alte funktionierende Ensembles aus primary (teilweise) in core umzuwandeln, ist in der Tat langweilig.
Am besten ist ein Projekt, das nicht zu schwierig ist, aber doch für core geeignet ist.
Du kennst mein englisches Tutorial im englischen Forum? (REAKTOR RIDDLES)
Zunächst gehe ich auf REAKTOR Blocks und die Umsetzung in primary ein mit absoluten Beginner-Tipps. Ab Riddle 2 geht's aber sofort hinein in core.
Es endet mit Riddle 9 wo ein kompletter Synth aufgebaut wird. Leider musste ich den letzten Abschnitt unvollendet beenden, da es mir in den letzten vier Jahren gesundheitlich sehr schlecht ging und ich keine Kraft hatte. (Jetzt ist Alles gut) . Das gesamte Tutorial gibt es in der User-Library mit Dokumenten und allen benutzten ensembles und Lösungen.