FFT - ein Fortschritt oder nur ein Zauberwort

[helmsklamm]

aber was mir bei diesen bsp- ens auffällt: cpu-freundlich sind die nun nicht gerade. (zumindest das komplette fft-demo ensemble - für die cores bin ich zu blöde).

nungut, der/die effekte nutzen 72 stimmen, aber mit weniger klingt das aber auch alles echt dürftig.
also, ob fft nun wirklich so FAST ist, wage ich anzuzweifeln (zumindest wenn es auch klingen soll) - aber ich bin auf jeden fall weiter gespannt. nur scheints mir n bissl wie kinderweihnachten: sind die heißgewünschten geschenke erstmal ausgepackt, sind sie auf einmal nich mehr sooooo schön. - hoffentlich irre ich mich.

[herw]

aber was mir bei diesen bsp- ens auffällt: cpu-freundlich sind die nun nicht gerade. (zumindest das komplette fft-demo ensemble - für die cores bin ich zu blöde).

nungut, der/die effekte nutzen 72 stimmen, aber mit weniger klingt das aber auch alles echt dürftig.
also, ob fft nun wirklich so FAST ist, wage ich anzuzweifeln (zumindest wenn es auch klingen soll) - aber ich bin auf jeden fall weiter gespannt. nur scheints mir n bissl wie kinderweihnachten: sind die heißgewünschten geschenke erstmal ausgepackt, sind sie auf einmal nich mehr sooooo schön. - hoffentlich irre ich mich.

Ich denke, dass die vorgestellten Makros als eine Art Aufforderung zu sehen sind an die NI-Entwickler, sich dieses Themas in REAKTOR anzunehmen.
Ich halte davon nicht viel, da das nur einige wenige nutzen werden und der musikalische Wert eher zweifelhaft ist. Spezialprogramme bringen sicherlich mehr (spectral delay könnte man ja vielleicht dahingehend ausbauen). Aber ich wiederhole mich jetzt.

ciao herw

[nq]

ich will nichts sagen, aber max/msp kann es ja auch relativ problemlos

naja ok, dafür hat es bei anderen sachen seine probleme.

[magneton]

(spectral delay könnte man ja vielleicht dahingehend ausbauen)

ich glaube bei SD wird gar nichts mehr ausgebaut. als besitzer der ersten stunde hätte ich da mehr erwartet.

[helmsklamm]

Ich halte davon nicht viel, da das nur einige wenige nutzen werden und der musikalische Wert eher zweifelhaft ist.
ciao herw

bei sätzen dieser art muss ich zwangslläufig an nen sprichwort denken, hat mit essen und der landwirtschaft zu tun
nee, ich glaub schon das das was bringen kann, aber zZ sind die leutz dabei das abc zu erstellen, bis zur stenografie werden da wohl noch n paar versuche nötig sein, aber dann...

ansonsten bin ich aber auch der meinung, das andere dinge vorrang hätten:

1. die gui/ergonomie, die alles andere als zeitgenössich ist
2. die sampler module (die man ja ausgerechnet eben nicht in core nachbauen kann) bedürften dringend eines updates.

[herw]

...ansonsten bin ich aber auch der meinung, das andere dinge vorrang hätten:

...
2. die sampler module (die man ja ausgerechnet eben nicht in core nachbauen kann) bedürften dringend eines updates.

wieso eigentlich nicht? Ist ein sample nicht einfach nur ein abgetastetes Audiosignal, das in einem Speicherarray liegt?

[helmsklamm]

das schon, aber wie willste bspw. den load samplemap dialog realisieren? gibts da irgendwo module die als platten-schnittstelle fungieren???

[herw]

das schon, aber wie willste bspw. den load samplemap dialog realisieren? gibts da irgendwo module die als platten-schnittstelle fungieren???

naja ich denke da anders: jegliche Datenverarbeitung gehört für mich in die Core-Ebene, alles drumherum wie GUI, Hardwarezugriffe etc. auf das primary level. Ich verstehe primary level nur noch als interface zwischen der Außenwelt und dem Inneren von Reaktor. Leider ist das bisher noch nicht konsequent umgesetzt und optimiert. Aber das wäre mein Wunschtraum.

ciao herw

[clapptomaniac]

also ich fänd die einbindung von fft in reaktor spannend. ich weiß nicht, ob ich persönlich jemals so tief einsteige, das ich selbst damit etwas basteln könnte, aber über sample-morph, additiven kram, super-vocoder etc. würde ich mich freuen.
ich denke das wäre für einige sachen eine art schlüssel-feature und was dann dabei rauskommt wenn sich die usergemeinde darauf stürzt ist nicht abzuschätzen. wenn du einem NI-entwickler vor einigen jahren erzählt hättest, dass jemand PONG mit reaktor nachbaut hätte der dich vermutlich für bekloppt gehalten

die frage ob man fft in reaktor BRAUCHT, lässt sich ganz klar mit nein beantworten, aber man BRAUCHT auch kein core. man kann ja auch einfach flöte spielen ...

[herw]

[helmsklamm]

naja ich denke da anders: jegliche Datenverarbeitung gehört für mich in die Core-Ebene, alles drumherum wie GUI, Hardwarezugriffe etc. auf das primary level. Ich verstehe primary level nur noch als interface zwischen der Außenwelt und dem Inneren von Reaktor. Leider ist das bisher noch nicht konsequent umgesetzt und optimiert.

da es aber bislang keine "interface" prim-module gibt, kann man ergo (noch) keinen sampler in core bauen, bestenfalls n "rompler".
ok, wenn core irgednwann sse-optimiert und keine ahnung was noch, aufgeholt hat, stimme ich dir zu. nur dann bräcuhte man eben noch ne ecke "schnittstellen" prim-module, die, wie gesagt, fehlen. das wäre dann konseqeunt - vielleicht liegen wir ganrnich so auseinander.

[herw]

...da es aber bislang keine "interface" prim-module gibt, ... nur dann bräcuhte man eben noch ne ecke "schnittstellen" prim-module, die, wie gesagt, fehlen. das wäre dann konseqeunt - vielleicht liegen wir ganrnich so auseinander.

ein Anfang ist z.B. der simulierte AudioCore-Event-Ausgang von Gerald List (krümelmonster, cookiemonster)

ciao herw

[helmsklamm]

ähm, abgesehen davon, das es vielleicht nem wegweiser entsprechen soll, seh ich den nutzen des bsp. grad nich. wenn es n brainstroming-einwurf, aus dem weiters erwachsen soll ist, einverstanden, aber als selbstzweck macht das wenig sinn, oder? wenn es allerdings der erste schritt zu hybrid-corezellen sein soll, hut ab.

rück zum "thema"
(ich denke jetzt nur laut)

gehn wir mal von aus, das core einestages so "optimiert" , wie der rest von reaktor (haha - den konnt ich mir jetz nich verkneifen ) ist, wo setzt du dann die grenze zur "unter der haube"? bei jedem simplen button muss man ins prim??? - das fänd ich zu viel mausklickerei und zu unübersichtlich.
ich seh das wahrscheinlich exakt andersrum als du: für mich sollte core nix anderes als aufgebohrtes prim sein, resp. beides so zusammenschmelzen, das es keinen unterschied mehr gibt, denn letzendlich kann core (aus anwendersicht) auch als nix anderes als ne tiefere prim-ebene betrachtet werden: reichen mir standardmöglichkeiten eines "modules" nicht, habe ich eben die möglichkeit es zu verändern. oder meine "module" von grund auf neu zu konstrukten.
ich hoffe, wenn irgendwann core ebenfalls sse spricht, das das prim-level als solches abgeschafft wird und alle "module" nur noch als core vorliegen.

die hierachie in reaktior sollte dann so aussehen:

level 1 (gibts bislang noch nicht:)

die interface-ebene: hier wird ganz simple über properties-boxen das verhalten der "module" zur aussenwelt festgelegt, also ob bspw. nen rechtsklick den datei öffenen dialog anzeigt und wo der standardpfad ist, etc. oder ob es bei rechtsklick nen weitern port und alles dazugehörige interne automatisch erzeugt, nach welcher logik dieser port benannt werden soll, etc.

level 2 (ex-prim, non-dsp):

das was wir bisher unter prim verstehen. allerdings ohne zwischen prim/core "modulen" zu unterscheiden. hier gelten noch die übleichen verdrahtungsregeln (niemand muss was über bool oder feedback -z wissen). aber mit der möglichkeit, seine "module" die ne ebene tiefer erstellt wurden, in diesem ist-zustand zu sichern (inklusive der levelhöheren "properties").

level 3 (ex-core, dsp-ebene):

ab hier muss man eben das gewisse extra-studium vollzogen haben denn hier gehts ans eingemachte. und nur hier gibts eben die kleinsten 1bit bausteine, die nich mehr zu modifizieren sind.


die heirachie wäre dann folgende:

bits = nicht mehr teilbar
zellen = funktionsblock aus bit - zZ core-macro
module = funktionsblock aus core-macros - zZ core-cell oder modul

(die nomenklatur is natürlich nur n vorschlag)

alles weitere wie gehabt, nur mit den unterschied, das module nen prop-dialog zum rest bekommen und in variantionen abgespeichert werden können.


wie gesagt: nur laut gedacht.

[helmsklamm]

KEINE AHNUNG,
aber ab nen bestimmten absatz werden längere wörter, die mit f beginnen zum :- ) konvertiert.

bspw. das wort funktionsblock

(so auch hier). ts ts ts....

(in der edit-view erscheints richtig).

[krümelmonster]

...ein Anfang ist z.B. der simulierte AudioCore-Event-Ausgang...

Danke für die Blumen, Herwig ! Freut mich wirklich sehr, daß Du diesen Upload so sehr schätzt. Für mich war er zwar nur die logische Konsequenz aus meiner kleinen Sonde, die ihrerseits eines Updates und ein paar weiterer Hinweise bedarf ( wie macht man das eigentlich, ohne gleich wieder eine neue file-ID zu bekommen ?), aber egal ...
Das ist schon ein wirklich interessanter Thread hier ! Geht zwar thematisch ein bisschen durcheinander, aber das läßt sich oftmals ja auch garnicht vermeiden.
Wichtiger in diesem Zusammenhang ist, das dieser Thread von einer Menge an Unwissenheit geprägt ist. Damit will ich niemandem auf den Schlips treten; bin ja weiß Gott selbst alles andere als ein dsp-Guru.
Trotzdem - es sei dringend die Lektüre des kostenlosen online-Buches "The Scientist and Engineer's Guide to Digital Signal Processing" (http://www.dspguide.com) - empfohlen. Die kann einen zwar dazu bringen, daß man sich einlieferungsbedürftig fühlt, kann aber in hellen Momenten auch für das erhabene Gefühl sorgen, das ein 2d-Männchen haben muß, wenn es zum ersten Mal seinen Kopf aus der Ebene reckt und feststellt: "Mein Gott, es gibt einen Raum !"
Für alle weitere dsp-Beschäftigung ( täte mir auch sehr gut ! ) stellt es eine solide Grundlage dar.
"FFT" - Fast Fourier Transform - ist zunächst wirklich nur ein Wort - allerdings eines für etwas sehr Schönes.
FFT ist auch garnicht schnell, wie es der Begriff vorgaukelt - es ist sogar (sorry PrinzThomas) kreuzlahm - es läßt sich nur relativ "schnell" berechnen.
Und damit ist - meiner Meinung nach, bitte belehrt mich, falls ich da falsch liege - zunächst einmal klar, wofür sich FFT nicht (!) anbietet: Live-Effekte mit schneller Ansprache lassen sich damit nicht bauen.
FFT und Latenzfreiheit schließen einander aus. Deswegen habe ich meinen Kopf auch zunächst einmal wieder in die Ebene zurückgezogen. Falls ich tatsächlich aus dem Spektrum eines Signals in Real-Time Befehlsstrukturen ableiten möchte, werde ich mich wohl eher eines ausreichend feinbändrigen Analyzers wie dem von programchild bedienen.
Es sei in diesem Zusammenhang der NI-Thread "FFT at last !" empfohlen, in welchem Robin Davies, von dem die letzte Reaktor-Implementation stammt, ein paar Anwendungsgebiete anführt.
Der gute Mr.Davies scheint ein erschreckend cleveres Kerlchen zu sein. Noch gar nicht lange Reaktor-User, dafür mit ungemein viel dsp-Kenntnissen vorbelastet.
Weshalb die ganze community jetzt so begeistert ist und von Gabriel Mulzers Implementation kaum weiter Notiz genommen hat, verstehe ich, ehrlich gesagt, nicht.
Gabriel selbst ist offensichtlich sehr von Robins Version angetan. Muß ihn mal fragen, worin die Hauptunterschiede liegen. Hinsichtlich CPU-Belastung liegen da doch keine Welten zwischen. Vielleicht hat es was damit zu tun, daß Robins Version nur eine (!) voice benötigt und somit praktischer in der "Weiterverarbeitung" ist.
Seine Version habe ich übrigens noch garnicht verstanden. Habe sie auch noch nicht wirklich analysiert. Dafür fehlen mir im Moment die Nerven: Zum Einen hakt es gerade sehr hinsichtlich meines eigenen Werkes, zum Anderen muß ich in zwei Tagen unters Messer. Möge mir dabei nicht nur der Reaktor-Gott beistehen !
Verdammt, ich fasele doch sonst nicht so viel.
Eine Anwendung, für die man um FFT nicht herumkommt, liegt schon mal auf der Hand:
Wer Filter bauen möchte und sich hinsichtlich des korrekten, gewollten Verhaltens vergewissern will, braucht es einfach !
PrinzThomas hat es völlig einleuchtend formuliert. So viele Bandpass-Filter kann man garnicht verkabeln, um auf die gleiche Auflösung zu kommen, ohne daß einem der Rechner frühzeitig wegbricht.
Und damit darf ich mich denn auch am Wunschkonzert, daß hier stattgefunden hat ( ist überhaupt nicht kritisch oder gar böse gemeint ) beteiligen:
Ich will noch viel, viel, viel schnellere Rechner !
Man stelle sich vor, daß die Diskrete Fourier Transformation (DFT), auf welcher FFT basiert, mal so "nebenbei" berechenbar wäre; dann hätte man beides:
Feine Bändchen latenzfrei !
Ich weiß, ein frommer Wunsch !
Aber - und damit sind die dsp-Gurus wieder um Rat gefragt - ist es nicht vielleicht möglich, ein Signal in eine Handvoll Bändchen zu splitten, diese einem 32-Punkt-DFT ( der ja CPU-günstiger als ein 32-Punkt-FFT ausfällt ) zu unterziehen und daraus in real-time Befehlsstrukturen abzuleiten ?
Wahrscheinlich geht es leider nicht, sonst wäre schon irgendein kluger Mensch darauf gekommen und jeder würd es so machen.
Jetzt muß ich aber schlafen.
Ciao, Gerald.

P.S.: Schickt ein paar Stoßgebete nach oben, wenn mir übermorgen beide Kiefer aufgemeißelt werden.
P.P.S.: Helmsklamm, Deine Gehirnjogging-Lösung scheint, da keine feinere zeitliche Auflösung benötigt wird, die mit Abstand sinnvollste weil CPU-günstigste zu sein.
P.P.P.S.: Herwig, ich bin gerade praktisch wieder bei Dir "umme Ecke". Nette Konversation tete-a-tete wird aus erwähnten Gründen zunächst nicht möglich sein.