Deutsches Reaktor Forum

hi!

Ich bin gerade (schon sehr lange) an einem Mammutprojekt bei dem ich jetzt versuche einige (schon funktionierende) Teilbereiche soweit zu kriegen dass sie in einem Subroutinen Kontext allgemein funktionstüchtig sind. Das Ziel ist eine komplette Grafiklibrary für Reaktor core zu erstellen. Das schöne ist, dass das Grundsystem (Iterationsalgo, dynamische Speicherzuweisung usw) mit allen Anforderungen nun funktioniert. Grundlage des ganzen ist die Regel, dass alles auf wenigstmögliche Funtionsgruppen zu reduzieren. So wird ein system mit bspw. 10 Fadern den gleichen umfang haben wie eines mit 1000.

Dazu musss natürlich jeder einzelne Fader anhand eines Datensatzes beschrieben werden. In diesem Datensatz sind Eigenschaften festgehalten wie Koordinaten, Erscheinungsbild und Wertebereich. Das Problem das ich hier veranschaulichen will muss ich lösen um die neue Version meiner Wertebereichsfestlegung zu verwirklichen. Dazu muss noch gesagt werden, dass diese Datensätze komplett Integer gehalten werden da sie fast vollständig mit BIT operationen Codiert werden. Gerade bei der Koordinatenberechnung des Grafischen outputs spart mir das immens viel code. Ferner wird dieser Speicher auch über Primary versendet um eine Funktionalität für zukünftige Versionen des systems zu ermöglichen: Der User malt sich mit der Maus die Bedienelemente die er gerade haben will. Aber das ist noch in weiter Ferne. Displayseitig funktioniert das schon problemlos aber im Audiopart stehen da noch einige Versuche aus. Das ganze system werde ich in einem "projekt" Thread mal vorstellen, dazu will ich aber die neue Version meines Datensatzes erst implementiert haben.

Wertebereich eines Faders:
bisherige Version:

rmx = realer maximalwert
mx = maximalwert des Integerspeichers

rmx bestimmte so den wertebereich und mx die stepsize
stepsize = rmx/mx

beispiel
rmx = 130 (filter cutoff)
mx = 1300

stepsize 0.1

so ging der Wertebereich immer von 0 - Max
ein weiteres BIT konnte dann das ganze noch 2 polig machen.

Beispiel
2pol?=1
rmx = 2
mx = 2000

Wertebereich von -1 bis 1 Stepsize 0.001

das klappt sauber und ich muss sagen das das ziemlich Prazisorientiert ist für 90%(?) aller Fälle. Doch wie einen Wertebereich von -3.5 bis 5 Beschreiben was ja mit den Standartbedienelementen von Reaktor möglich ist? Und dazu folgende mir wichtige Frage (die aber immernochnichts mit der eigentlichen Problematik zu tun hat.):
dazu noch: es geht hier um den Tatsächlichen Wertebereich der in der corezelle am ende ankommen soll und mit dem gerechnet werden soll. da ich diesen auch in der Grafikausgabe brauche (Realwertinformation) soll eine Standartisierung der Wertebereiche nicht erfolgen. (ich hoffe nicht dass mich jemand deswegen ausschimpft )

FRAGE:
Wie oft ist es euch passiert, dass ihr ein Bedienelement gebraucht habt welches nicht ganzzahlige min und maxwerte hat?
Wie oft ist es euch passiert, dass ihr ein bipolares Bedienelement gebraucht habt dessen min und maxwerte nicht den gleichen Betrag |x| haben?

wenn jetzt zB Herwig sagt: sogut wie nie! dann würd ich mir echt überlegen mein altes system zu behalten weil es sehr codearm ist.

und jetzt hab ich soviel geschrieben und es ist auch schon so spät, dass ich mit dem eigentlichen Problem erst morgen oder übermorgen anfange

also die Thread wird dem Titel noch nicht ganz gerecht aber das wird... antwort auf beide oberen Fragen wäre sehr gerngesehen

gruss D

MvKeinen hat geschrieben:[...]
FRAGE:
Wie oft ist es euch passiert, dass ihr ein Bedienelement gebraucht habt welches nicht ganzzahlige min und maxwerte hat?
Wie oft ist es euch passiert, dass ihr ein bipolares Bedienelement gebraucht habt dessen min und maxwerte nicht den gleichen Betrag |x| haben?

wenn jetzt zB Herwig sagt: sogut wie nie! dann würd ich mir echt überlegen mein altes system zu behalten weil es sehr codearm ist.

und jetzt hab ich soviel geschrieben und es ist auch schon so spät, dass ich mit dem eigentlichen Problem erst morgen oder übermorgen anfange

also die Thread wird dem Titel noch nicht ganz gerecht aber das wird... antwort auf beide oberen Fragen wäre sehr gerngesehen

gruss D

zu 1: Ganzzahlige min und max-Werte sind sicherlich Standard zum Beispiel [0...1] oder [-1...+1] für Modulationen
zu 2: häufig: zum Beispiel für logarithmische Werte von Hüllkurven [-20...+80]; ein Bereich von [-80..+80] wäre etwas unsinnig und [-20..+20] ganz klar zu klein im oberen Bereich.

Aber das ist ja kein Hinderungsgrund, die Bedienelemente nicht trotzdem symmetrisch auszulegen, da man ja den Wertebereich leicht umrechnen kann; aber ich denke, es geht dir darum, die Zahl der Parameter eines Bedienelementes möglichst klein zu halten. Das stößt wegen der Universalität, die du offenbar anstrebst, an Grenzen. Auch die REAKTOR-Entwickler müssen sich immer wieder Gedanken darüber machen, welche Parameter in den Properties einstellbar sind. Man denke nur an das gequälte Gewurste bei den Fine-Einstellungen im Zusammenhang mit IC-sends. So wie ich es einschätze, brauchst du doch lediglich einen Parameter mehr, um den Wertebereich zu verschieben? Der kann ja mit deiner Methode auch wieder ganzzahlig sein.

ciao herw

Danke für die Antwort..

Ja, ich glaube ich kann es mir da wirklich etwas einfacher machen. Frage 1 bezog sich zB auf feedbackparameter die gerne nur bis 0.99 gehen. wenn es sich da allerdings um seltene ausnahmen handelt glaube ich kann man dann ruhig ne korrektur dazwischenschalten oder man sagt eben 99% und hat dann wieder einen integerwert.

Frage 2 ist wie Du schon sagst einfach zu lösen.

ich beschreib trozdem mal das Problem, da das in der Grafischen Ausgabe wieder relevant ist.
der obere Teil der Schaltung ermittelt die Nachkommastellen. und hier ergibt sich bei dem Wert $=0.50001 ein fehler (siehe debug-werteausgabe)

MvKeinen hat geschrieben:Danke für die Antwort..

Ja, ich glaube ich kann es mir da wirklich etwas einfacher machen. Frage 1 bezog sich zB auf feedbackparameter die gerne nur bis 0.99 gehen. wenn es sich da allerdings um seltene ausnahmen handelt glaube ich kann man dann ruhig ne korrektur dazwischenschalten oder man sagt eben 99% und hat dann wieder einen integerwert.

Frage 2 ist wie Du schon sagst einfach zu lösen.

ich beschreib trozdem mal das Problem, da das in der Grafischen Ausgabe wieder relevant ist.

<Anhang>

der obere Teil der Schaltung ermittelt die Nachkommastellen. und hier ergibt sich bei dem Wert $=0.50001 ein fehler (siehe debug-werteausgabe)

Ich habe mich mal in die Schaltung hineingedacht: die Übersetzung einer Fließkommazahl in eine integer-message scheitert im gezeigten Beispiel an der Rechengenauigkeit jeder CPU: die Abfrage nach der Gleichheit und Ungleichheit beim Runden einer Fließkommazahl mit dem (passenden) integer-Werte hadert mit der Genauigkeit der CPU-internen Umrechnung.

Eine gängige Alternative des Testens auf Gleichheit ist die übliche Abschätzung, ob die Differenz kleiner als z.B. 1e-10 ist. Dann wäre dein Algorithmus wieder anwendbar: Die numerische Anzeige zeigt allerdings nur wieder ungefähre Werte an, intern bleibt 5,0001 erhalten.

ciao herw

Ich möchte mal grundsätzlich fragen, wie feinfühlig ein Fader sein muss? Ich weiß ja nicht, welche Spezial-GUI-Elemente du bauen möchtest, aber ich persönlich finde eine Einstellung von 200 steps das äußerste, was ich ertragen möchte, da eine weite Mausbewegung nervig ist. Ich habe mir angewöhnt, entweder nur 100, höchstens 200, steps zuzulassen und bei einer höheren Auflösung in irgendeiner Form einen neuen Regler oder einen Mausbereich dafür extra bereitzustellen.
Bei diesen Einstellungen kann man nur mit integer-Werten arbeiten. Erst in der Core-Anwendung rechne ich dann in die gewünschten Werte um.

D.h. ich würde bei einem von dir gewünschten Universalelement lediglich die Parameter übersenden und entsprechend dann in der Corecell die Parameter der message zur Werteberechnung benutzen. Somit ersparst Du dir eine Verschlüsselung des floatwertes beim Senden der GUI-Element-message (oder habe ich das falsch verstanden?).
Soweit ich das sehe ist der einzige Wert, der nicht als integer in deiner message vorkommt, die Stepweite (z.B. 0,001), das ist aber leicht als 10er-Logarithums (hier -3) zu übertragen.
Also liegen lediglich integer-Werte vor.

Für die grafische Ausgabe eines float-Wertes muss man schon wissen, wie viele Stellen du maximal angeben möchtest. Um Rundungen wird man in jedem Fall nicht herumkommen.
Bleibt noch die Beschreibung des Wertebereiches z.B. [-3.5 ... 5]. Hier kann man auch mit einer integer-Zahl (-35) und der Kommaverschiebung (-1) arbeiten:
-3.5=-35·10^(-1) .

ciao herw