doppeltes Auslesen AudioTable/Lookup

[Triton]

Moin.

Gibt es eine Möglichkeit, in einem Audio-Tic zwei oder mehr Werte aus einer Lookup-Table bzw. einer Audio-Table auszulesen? Alternativ zwei LookUp-Tabellen ein gemeinsames Sample nutzen lassen (eher ein Feature-Wunsch, so eine Art OBC zwischen Sample-Modulen).

Würde nämlich gerne z.B. einen Loopfader bauen und spiele bereits mit dem Gedanken, diesen in eine CoreCell auszulagern (Sample vorher in Array in einer Cell streamen, der ultimative Feature-Wunsch wäre natürlich eine OBC aus einer Cell raus in eine Audiotabelle/Lookup, ooooh und das noch in zwei Richtungen, uiuiui).

Grüssle

ps: waren die gemeinen hacker wieder unterwegs? heute morgen war das layout kaputt.

[toxonic]

hi,

ich kann dir nicht ganz folgen, was du willst - möchtest du 2 unterschiedliche loops in einen table laden und gleichzeitig abspielen und dann am ausgang via fader zwischen den beiden loops hin und her faden?
also, das geht jedenfalls. du kannst auf eine abtastung im audiotable mehrere werte gleichzeitig auslesen, da der audiotable ja 2-dimensional nutzbar ist. dazu musst du aber mit to-voice /from-voice modulen arbeiten, damit du gleichzeitig die 2 reihen (y rows im table) auslesen kannst. alle audio eingänge sind ja polyphon, du kannst also unabhängig voneinander mehrere reihen im table in unterschiedlichen geschwindigkeiten und längen abspielen, du musst sie nur entsprechend mit den to-voice modulen ansteuern und am ausgang wieder mit den from voice modulen aufsplitten.
grüssle,

joe

[Triton]

Ah, danke. Mit zwei Voices auslesen, das werd ich probieren, das hatt ich gar nicht aufm Schirm.

In die Tabelle geht nur ein Eingangs-Sample, wo dann aber blockweise, immer zwei Blöcke gleichzeitig, ausgelesen werden soll. Ziel ist ein extremer Timestretcher, der ein Signal fast schon einfrieren lassen können soll.

Sry, war etwas konfus geschrieben von mir, das mit den Cells und OBC ist eher was für die Feature-Wunsch-Liste. Hatte das auch mal mit Cells probiert (Audiostream rein und dann dort abspeichern und auslesen, also eine Art Audiotable in einer Cell), aber für so große Datenmengen ist das glaub ich nicht gedacht.

Gruits,

jan

[toxonic]

ah, ok - du willst im prinzip ein sample im table abspielen und die lesegeschwindigkeit bis zum stillstand verringern (tonhöhe konserviert). geht natürlich mit granular synthese. wahrscheinlich hast du das schon entdeckt, falls nicht - ich hab hier im forum ein tutorium geschrieben zu thema granularsynthese. da hab ich im prinzip sowas gebastelt (vorausgesetzt, ich hab dich richtig verstanden). im tutorium selber verwende ich für das overlapping zwei tables, aber ich habe ein paar posts später nochmal die elegantere variante mit nur einem table und der ansteuerung der 2 overlapping grains über 2 voices als ensemble hochgeladen. kannste dir ja mal runterladen, evtl. hilft dir das!? hier der link zum tut: http://reaktor.approx.de/phpbb3/viewtopic.php?f=8&t=653
lg,

joe

[Triton]

Super, danke für den Link. Hab das Tutorial gleich verschlungen und experimentiere ein wenig mit dem Stretcher-Ensemble daraus. Der Kniff mit den zwei Voices ist chef.

Ahem. Kannte das noch nicht, die Workshop-Rubrik hab ich ehrlich gesagt bisher noch gar nicht richtig gelesen (Schande über meinen Kopp), hatte mal reingeguckt, aber bei dem Thema Granular dachte ich an diese in den Reaktor eingebauten Granular-Sampler-Module, die mir ziemlich unheimlich sind.

Ist auf jeden Fall genau die Technik, die ich suche. Soll ein fft-basierter Stretcher werden (da sollen die fft-Blöcke immer abwechselnd und wegen Overlap versetzt reingestreamt werden). Fenstern muss ich die Blöcke zum Glück nicht, obwohl man das dann der fft-Cell abnehmen könnte, was vielleicht gar nicht schlecht ist (nur verstehe ich deren Inneres überhaupt gar nicht). Baue hier fleißig an meiner "Stretching Machine" (deren Namen ich ziemlich doof finde, aber mir fällt einfach nix besseres ein), die im Moment alles über einen Pitchshifter regelt und bei extremen Verlangsamungen doch ziemlich an die Grenze kommt (weil dann ein ultratiefes Sample reingeht und die fft überfordert, so dass gerade Bass und irgendwann alles matscht).

Thx a lot.

Grüße vom Jan

[KlangRaum]

Wenn die Struktur auch als MONO laufen soll, kommt eine Ansteuerung über mehrere Voices nicht in Frage. Wenn Du aber eine Table einrichtest und abspeicherst, kannst Du sie anschliessend kopieren. In den Properties siehst Du im Feld Clients 2. Du hast dann 2 Tables, die sich den Datenblock teilen -schreibend werden alle Änderungen übernommen egal wo Du sie vornimmst, aber lesend kannst Du unabhängig drauf zugreifen.

Gruss
Peter

[toxonic]

jap, das entspricht dann der variante, wie sie im tutorial beschrieben wurde, also mit 2 tables die sich den selben inhalt teilen. ich habe erst einige posts danach die variante mit voices hochgeladen, weil's einfach eleganter ist. ich glaube, cpu technisch nehmen sich beide varianten nicht viel, hab aber auch noch nicht drauf geachtet.

[KlangRaum]

Auf die CPU-Last hin hab ich das noch nicht genauer untersucht, bisher hab ich diese Variante nur Events bei einem Suequencer benutzt

Alternativ lässt sich das auch mit Core via Table/Array umsetzen...

Gruss
Peter

[Triton]

Riesenarrays gehen mit Core glaub ich nicht. Bei ca. 1 Mio. ist Schicht, ein paar Sekunden bekommt man schon unter, aber Abspeichern oder zumindest bei Unterbrechungen im Speicher halten ist dann wieder das Ding.

Im Moment probier ich's mit einem kleinen Puffer in Core und verzweifel an dem richtigen Berechnen von der Aufteilung aus dem Puffer raus. Von außen kommt ein Stream mit vollem Tempo und springt alle 2048 Werte einen ganzen Satz entsprechend der gewählten Verlangsamung zurück. Ein CoreMakro speichert die Werte und soll daraus vier gleich-versetzte Streams - immer aus 1024-er Blöcken - erzeugen. Naja, mal gucken, ob das was wird.

[KlangRaum]

In Arrays ist bei 1.048.576 Einträgen Schluss, dh. mit 32Bit Float/Int hätte das Array dann 4 MB.
Tables können maximal 10.000.000 (?Hä?) Einträge verwalten
(Reaktor 5.12)

Kleine Meditations-Runde:
Über den Sinn dieser Begrenzenzungen konnte mir das Orakel der Matrix keine Antwort geben, es scheint mir besonders bei Tables etwas willkürlich gesetzt. Mit einem unsigned 32Bit-Pointer ginge schon etwas mehr zu verwalten, damit hätte man thoretisch 4.294.967.296 (4GB)..... Scheint vielleicht momentan noch etwas hoch gegriffen solche Bereiche zu nutzen, aber wenn man mal überlegt was sich alles mit Core und Arrays/Tables schon jetzt umsetzen lässt, sollte man nichts ausschliessen.
Ich bastel grade an einem Coremacro, das Arrays und Tables nutzt, um komplexes Signalrouting zu ermöglichen und durch Speicherung von Kennlinien die Berechnung von Funktionen zu erleichtern, dabei geht die CPU-Last deutlich nach unten. Speichert man zB eine Sinustabelle, auf die innerhalb der Tonerzeugung vielfach zugegriffen wird statt an allen möglichen Stellen die Funktion zu berechnen, fällt der Rechenaufwand für die Indizierung auch bei sehr vielen Oszillatoren kaum ins Gewicht. Wählt man dann noch eine entsprechend „feine und logische Auflösung“ erspart man sich das Interpolieren und macht man sich auch noch einige Gedanken über die Parameternormalisierung bzw. Abstimmung auf die Samplingrate und benutzt an einigen Stellen Binär- Integerarithmetik, lassen sich sogar viele Strukturen komplett als Integer auslegen, was dann auch noch mal schneller abzuarbeiten geht. Der Einzige Wermitstropfen wäre der „erhöhte“ Speicherbedarf (...aber was solls...) und eine Schaltungslogik, die so abstrakt wird das sie für Aussenstehende nur noch schwer zu durchschauen ist und mit den ehemaligen 3-OSC.ens aus den frühen Reaktor-Tagen absolut nichts mehr gemeinsam hat

Vielleicht wird das „Speichervolumen“ ja irgendwann mal ein Stück erweitert, ich denke mal bei heutigen Speichergrössen sollten bis zu 256/512MB problemlos möglich sein. Die Trennung von Arrays (Read/Write) und Tables (Read only) finde ich mittlerweile unpassend, man sollte das in den Properties einsprechend einstellen und später auch umstellen können... und auf die Master/Slave OBC Connenctions sollten auch über die Core-Macrogrenzen hinweg zugegriffen werden können vielleicht via OBC-Send/Recieve? Ich würde mir an dieser Stelle auch eine weitergehende Manipulationsmöglichkeit der OBC-Daten wünschen, um zb Indices und Offsets auf diese Speicherbereiche zu bilden und weiterzugeben, momentan geht das nur mit einigen Kunstgriffen bei denen man aufpassen muss um nicht in eine Sackgasse zu laufen... Aber das geht jetzt bei diesem Thread ins Offtopic.... also an dieser Stelle mal *schnippppp*

Gruss Peter

[herw]

In Arrays ist bei 1.048.576 Einträgen Schluss, dh. mit 32Bit Float/Int hätte das Array dann 4 MB.
Tables können maximal 10.000.000 (?Hä?) Einträge verwalten
(Reaktor 5.12)
[...]
Gruss Peter

R5.1.2? Sag bloß, du hast dir noch nicht R5.5 heruntergeladen?
Beim Array werde ich mal „oben” anmahnen, ob man die Grenze nicht hochschrauben könnte, da 4GB RAM ja mittlerweile wohl Standard ist.

zu den tables
Tables können ja auch zweidimensional sein. Also ich habe ganz locker 999999·100 einstellen können. Oder passt das hier nicht als Argument?

ciao herw

[KlangRaum]

R5.1.2? Sag bloß, du hast dir noch nicht R5.5 heruntergeladen?

Beim Array werde ich mal „oben” anmahnen, ob man die Grenze nicht hochschrauben könnte, da 4GB RAM ja mittlerweile wohl Standard ist.
Meine Dosenbüxen haben noch Win2000 - die lassen sich nicht weiter uppen, laufen aber (ohne Internetz) absolut zuverlässig. Deswegen bleib ich damomentan mal stehn Never touch a running Dingsda and ever run a touched Dingsda

Neue Rechner kommen irgendwan.....

Tables können ja auch zweidimensional sein. Also ich habe ganz locker 999999·100 einstellen können. Oder passt das hier nicht als Argument?

ciao herw

Coretables nicht, oder ? (zumindest <R5.5) - darum gings im letzten Beitrag

...Riesenarrays gehen mit Core glaub ich nicht. Bei ca. 1 Mio. ist Schicht, ein paar Sekunden bekommt man schon unter, aber Abspeichern oder zumindest bei Unterbrechungen im Speicher halten ist dann wieder das Ding. Im Moment probier ich's mit einem kleinen Puffer in Core...

Gruss
Peter

[herw]

ich hab's mal an NI weitergegeben.

ciao herw