Deutsches Reaktor Forum

Hallo Leute!

Bin neu hier und gleich mal 'ne Frage an euch:

Hab in der Vergangenheit sehr gern den Resynth aus dem Sampler Pack von Herrn Walker-Hall verwendet. Da ich mir letztens endlich mal einen Controller zugelegt hab und damit live Sachen machen möchte, such ich nach 'ner Alternative in Echtzeit, ohne jedes Mal ein Audiofile in das Ensemble laden zu müssen, bzw. vorher erstmal das Tempo anzupassen. Zwei hab ich gefunden. Einmal den GrainFXv2 und den GrainPerception. Allerdings vermiss ich beim ersten einen "Tempo-Knopf" für Timestretch Geschichten und beim zweiten is die Fernsteuerung per Controller ziemlich umständlich.

Kennt von euch noch eine Alternative?

Grüße

auch wenn der thread schon leicht veraltet ist, ich antworte mal einfach, vielleicht liest den noch einer...
ein timestretching für ein audioeingangssignal ist meines wissens nach technisch nicht möglich. man kann kurze passagen daraus stretchen aber ein eingangssignal permanent zu stretchen, würde bedeuten das du einen schier unbegrenzten puffer brauchst, da das audiomaterial ja erstmal zwischengespeichert werden muss um langsamer abgespiel werden zu können.in reaktor kann der speicher dafür auch nicht dynamisch alloziert werden, sondern ein puffer muss von anfang an in seiner grösse festgelegt sein (etwa beim delay, bei dem man die maximale delayzeit in den properties einstellt. slebst wenn man dafür dynmisch speicher allozieren könnte, wäre es spätestens dann vorbei, wenn dein speicher vollgelaufen ist, bei ca. 10 mb/minute stereo audioeingangsmaterial (bei 44.1 khz) kannst du dir ja selber ausrechnen wielange das geht.
bei einem sampler ist das logischerweise anders, der audiofile wird komplett in den speicher geladen und dann kann man damit machen, was man will....

Diese Form von Live-Timestretching widerspricht der allgmeinen Relativitätstheorie.
Jedoch gäbe es da einen gewissen Ansatz………

KlangRaum hat geschrieben:Diese Form von Live-Timestretching widerspricht der allgmeinen Relativitätstheorie.
Jedoch gäbe es da einen gewissen Ansatz………

Gruppengeschwindigkeit, Tunneleffekt ?


PS: @Eddie: ach ja:

herw hat geschrieben: ;)Gruppengeschwindigkeit, Tunneleffekt ?

…hat was mit antimaterie, spin und zeitpfeil zu tun

KlangRaum hat geschrieben:

herw hat geschrieben: ;)Gruppengeschwindigkeit, Tunneleffekt ?

…hat was mit antimaterie, spin und zeitpfeil zu tun

nee - Quantenmechanik, Schrödinger Gleichung

naja, das problem stellt einfach nur die große menge an audiomaterial dar, die gepuffert werden muss. kleine passagen lassen sich schon mal auf knopfdruck für ne weile stretchen - wird in manchen effekten auch so angewandt, etwa in glitch vst. aber man kann natürlich nicht dauerhaft ein eingangssignal stretchen. ist also eine reine anwendungsfrage.... wenn man vorhat nur mal zwischendurch nen snareschlag in nem drumloop in echtzeit zu stretchen is das kein ding aber wenn man nach nem time-stretching wie in diversen samplern und loopern sucht, dann sucht mal vergeblich, fürchte ich.

stretching setzt voraus, das die „daten“ bereits vorliegen. es kann demensprechend nie in echter echtzeit ablaufen…

mit einem delay von einem sample ist in meinen augen echtzeit genug, da muss man doch keine haare spalten!

edit: beim timestretching wird langsamer abgespielt als gepuffert. ich habe selber auch schon einen timestretching effekt in reaktor realisiert, allerdings mit einer maximalen puffergrösse (in meinem besipiel 2 sekunden)... kann ja mal ein tutorial erstellen!

und gleich mal ein beispiel, hab mal kurz ein graindelay mit timestretching funktion gebastelt, kann im moment nur auf halbe geschwindigkeit stretchen und nur mit einer pufferlänge von 4 sekunden, also einer effektiven stretchingzeit von 8 sekunden.
das kann man natürlich ausreizen bis der ram glüht, aber ne minute puffer is mit sicherheit ohne weiteres drin.....

oops, da is mir ja ein fehlerchen passiert, hab den phase reset am sync eingang des "stretch"-ramp-oscs falsch verdrahtet. und weil ich schon dabei war habe ich auch gleich den buffer auf 1 minute hochgedreht und die entsprechenden konstanten angeglichen.
kleiner schönheitsfehler: nach etwa 1/5 der abgelaufenen bufferzeit verändert sich die tonhöhe um etwa einen 1/4 halbton je nach grain einstellungen. ehrlich gesagt ist mir der grund dafür schleierhaft, falls jemand ne idee hat, raus damit!
ansonsten ist klar, das "volllaufen" des puffers von vorne begonnen wird und damit die leseposition resettet wird.
aber dennoch: live-timestretching trotz relativitätstheorie!