selector interpolieren?

sellotape · Beitrag von **sellotape** » 29. September 2007, 09:57

kann mir jemand sagen wie ich in corecell einen selector interpoliere damit ich daraus ein scanner machen kann?

toxonic · Beitrag von **toxonic** » 29. September 2007, 23:18

hmm, ich steh auf'm schlauch....
frage a:wo gibt's in core nen vorgefertigten selector?
frage b: warum nimmst du nicht ein x-fader? oder willst du zwischen mehr als 2 eingängen scannen?

sellotape · Beitrag von **sellotape** » 1. Oktober 2007, 03:21

hehe
a: garnich, siehe core cell manual - da wird beschrieben wie man sich den bastelt
b: ja ich will mehr als zwei eingänge

toxonic · Beitrag von **toxonic** » 3. Oktober 2007, 00:53

zu a: wo? welche seite?

sellotape · Beitrag von **sellotape** » 3. Oktober 2007, 11:50

Selector.zip

s.122 (8.2 "Building an audio signal selector")

toxonic · Beitrag von **toxonic** » 4. Oktober 2007, 18:55

ah, jo - das hilft weiter! mhh, also is glaube ich etwas kniffliger, hab im moment nicht die zeit mir das reinzuziehen - werde aber am we mal schauen, würde mich auch interessieren!
falls du schon vorher ne lösung parat hast, dann poste sie hier, ok?

sellotape · Beitrag von **sellotape** » 10. Oktober 2007, 20:16

ich hab zumindest ne idee dafür aber ich glaub schon das man das wesentlich besser lösen könnte. wenn sich das mal jemand anschauen könnte...

Scanner.zip

herw · Beitrag von **herw** » 11. Oktober 2007, 16:07

sellotape hat geschrieben:ich hab zumindest ne idee dafür aber ich glaub schon das man das wesentlich besser lösen könnte. wenn sich das mal jemand anschauen könnte...

ja sieht schon logisch aus.
Zum besseren Testen habe ich dem Drehknopf 300 steps und Mausauflösung 301 spendiert. Dann kann man gut mit den Cursortasten hochsteppen.
Die Konstanten habe ich auf 0, 5, 10 und 20 geändert, um die Auswirkungen beobachten zu können, sonst bekommt man nur dasselbe angezeigt wie der Regler.
Jetzt würde ich mal mit langsamen LFO-Schwingungen unterschiedlicher Frequenz als Audiosignale arbeiten, um zu sehen, wie der Speicher arbeitet.

sellotape · Beitrag von **sellotape** » 11. Oktober 2007, 17:37

das ich da die selben werte wie bei dem regler hab war absicht damit ich seh obs auch korrekt funktioniert. danke fürs testen wenn du fehler findest dann bitte hier posten.
ich hab jetzt zwei arrays genommen und einen crossfader hinten drangehangen. jetzt braucht man egel wieviele eingänge immer nur ein crossfader was sich in der cpu last doch deutlich bemerkbar macht. den kann man bei belieben auch mit dem parabloic crossfader ersetzen wenn man die sinus "interpolation" von dem primary scanner haben will. sicherlich gibt es einen besseren das ganze zu lösen aber ich bin nunmal ein logischer reaktor bauer und kein mathematischer. deshalb mag ich corecell auch nicht besonders und würde mich echt riesig freuen wenn ni ma mit nem corecell library update rausrücken würde damit auch leute wie ich ma wieder was fertig machen können ohne tage-/wochenlang an so nem simplen module rumbasteln zu müssen!

sellotape · Beitrag von **sellotape** » 11. Oktober 2007, 17:39

aso! vor lauter frust das modul vergessen

Scanner.zip

helmsklamm · Beitrag von **helmsklamm** » 12. Oktober 2007, 12:10

is hier zwar n bissl deplaziert, sollte aber nich unerwähnt bleiben:

@herw:
dein numstep/mausreso-tip, bei dem du vörschlägst, die mausreso +1 zur numstep zu setzen ist schlichtweg falsch. teste das mal: mach dir n knob mit 300 und maus 301 und lass diesen von nem ICsend mit korrelierender range "mastern". er wird hin und wieder danebenliegen.
die einzige bugfreie lösung ist folgende: numstep/maus müssen identisch oder maustep eine peinlich exakte vilefache sein.

herw · Beitrag von **herw** » 12. Oktober 2007, 14:27

helmsklamm hat geschrieben:is hier zwar n bissl deplaziert, sollte aber nich unerwähnt bleiben:

@herw:
dein numstep/mausreso-tip, bei dem du vörschlägst, die mausreso +1 zur numstep zu setzen ist schlichtweg falsch. teste das mal: mach dir n knob mit 300 und maus 301 und lass diesen von nem ICsend mit korrelierender range "mastern". er wird hin und wieder danebenliegen.
die einzige bugfreie lösung ist folgende: numstep/maus müssen identisch oder maustep eine peinlich exakte vilefache sein.

Versuche mal mit range 0 .. 300 und Mausauflösung 300 den Wert 89 einzustellen (cursor oder Maus).

helmsklamm · Beitrag von **helmsklamm** » 12. Oktober 2007, 19:25

ok, das stimmt.

aber folgendes stimmt auch: wenn ich ne höherer mausreso wünsche (bspw. weil die range nur 0-16 ist und damit per maus einfach nicht jeder schritt sauber getroffen wird) wäre 128 ne vielfache davon.

dann würde die master/slave geschichte klappen.

bei deinem vorschlag aber (beide resos auf 129) überspringt der der geslavte knob die 7 und springt stattdessen gleich zur 8 und bleibt auch darüber stets einen vorneweg (ausser bei 16, quasi der "führungs 16"

(und, damit es zumindest vorne richtig ist, habe ich ein plus1 vor das send geschaltet).

ich finde dieses verhalten noch fataler als die übersrungene 89. stell dir ne extreme logik-varschaltung vor, bei du erwartest das ne gesendete 8 auch UNBEDINGT ne empfangene 8 darstellt. hier kann dich die fehlersuche schier zur verwzeiflung bringen.
im falle der überspriungenen" 89 sieht man wenigstens den fehler direkt und sie ist somit das kleinere übel.

wir sehen, wir haben beide recht und beide unrecht.
das problem bleibt nach wie vor nicht vollständig gelöst.

sellotape · Beitrag von **sellotape** » 12. Oktober 2007, 21:04

boah ich komm jetzt nich ganz mit (vieleicht weil freitag abend ist).

aber bei dem von mir gegebenen beispiel darf die range von dem pos-regeler auf garkeinen fall größer als 3 sein. die wrap funktion wie bei dem primary is hier noch nicht mit drin. also sollte die range immer genau so groß sein wie die anzahl der eingänge (bei 0 angefangen).

herw · Beitrag von **herw** » 12. Oktober 2007, 21:40

helmsklamm hat geschrieben:...ich finde dieses verhalten noch fataler als die übersrungene 89. stell dir ne extreme logik-varschaltung vor, bei du erwartest das ne gesendete 8 auch UNBEDINGT ne empfangene 8 darstellt. hier kann dich die fehlersuche schier zur verwzeiflung bringen.
im falle der überspriungenen" 89 sieht man wenigstens den fehler direkt und sie ist somit das kleinere übel.
...

Es wird nicht nur die 89 "übersprungen" sondern noch mindestens fünf andere (bei 200 habe ich aufgehört das zu überprüfen).
Allerdings habe ich etwas verheimlicht. Die 89 wird nur scheinbar übersprungen; wenn man die 88 erreicht, muss man zweimal den Cursor drücken, d.h. der 89. Wert wird lediglich mit 88 angezeigt. Die Anzeige und der Ausgang des Reglers geben den falschen Wert aus. Wenn man durch einen IC-Send den Regler steuert wird durch den Wert 89 zwar der Reglerwert 88 angezeigt, überträgt man dagegen diesen Ausgangswert wieder an ein Receive, so wird tatsächlich 89 angezeigt.
Hier ist wohl in der Implementation etwas schief gegangen. Das liegt auch an der ulkigen Einteilung von MausAreas etc. was ich schon mal an anderer Stelle ausführlich beschrieben habe.
Ich arbeite eigentlich fast nur noch mit MausAreas. Dort sind die Eigenarten stark eingeschränkt bzw. besser zu beherrschen; einzuges Manko ist die Nicht-Midifizierbarkeit, die man zwar umgehen kann aber einfach unpraktisch ist.

Aber um auf das ursprüngliche Thema zurückzukommen, REAKTOR ist - auch wenn es oft nicht den Anschein hat - eine (grafische) Programmierumgebung. Jede Programmierumgebung oder auch Programmiersprache muss die Eigenheiten der Sprache und der Plattform beachten. Je tiefer man eindringt, desto mehr Einschränkungen oder Eigenheiten tun sich auf, also auch bei Reaktor.

Man merkt dem Programm an, dass es durch die mehrfachen Major-Updates doch einige Unstimmigkeiten mit sich herumträgt.
Es wäre gut, wenn es mal ab und zu ein Minorupdate gäbe, das diese abstellen oder mindern würde.