Deutsches Reaktor Forum

Hallo Freunde der Nacht,
als Neuling hier möchte ich euch erstmal ganz ganz herzlich für eueren krassen Input danken. Ich lese schon länger mit, aber von mitreden kann bisher leider nicht wirklich die Rede sein...
Deshalb stelle ich hier auch nur eine Frage, bzw möchte auf ein Problem in Reaktor 5.5.1 aufmerksam machen, falls es nicht schon jemand anderes getan hat. ich konnte zumindest nichts darüber finden.

Behauptung:
Die Event Bit-Auflösung reicht nicht aus, um Song Position 96a über mehr als ein paar wenige Takte hinweg sauber zu halten. Sprich es werden mit der Zeit zunehmend in mehreren Samples von 96a hintereinander gleiche Positionswerte geliefert (fehlende Nachkommastellen?). Und das betrifft wohl nicht nur Song Pos 96a sondern auch einfache Rechenoperationen, bzw Reaktor komplett.

Ich hänge mal ein Beispielensemble an.
Der Effekt ist im unteren Teil des Panels ("Des Rätsels Lösung") nocheinmal anhand eines SR.C getriggerten Accumulators (Eingang ist 96tel Wert eines Sample, Ausgangswert ist 0-1) mit addierbarem Value von 0 - 1.000.000 schön erkennbar. Das Scope "Test accu..." visualisiert die Schrittweite zwischen jedem Sample. Dreht mal an "Add Value", und ihr werdet sehen, wie die Schrittweite zwischen den einzelnen Samplen immer mehr auseinander läuft und aber auch gleiche Samplewerte nacheinander geliefert werden.
Im oberen Teil des Panels, von links nach rechts, mein ursprünglicher Versuchsaufbau mit Song Pos 96a und der Triggerung eines Lookup Samplers mit nem gerendereten Sinus zur akkustischen und optischen verdeutlichung (Scope rechts).

Hintergrund des ganzen ist ein Live-Looper Projekt, in dem Tapedecks samplegenau "hardgedriven" werden um Reverse zu ermöglichen. Das funktioniert auch wunderbar, bis auf oben genannten Fehler.
Ich habe die Tapedecks auch mit 96event und der daraus entsprechenden Speed angefahren. Was dabei interessant auffällt ist, daß bei Tempi, in welchen 1/96 einer nicht integeren Anzahl (integer = Zahl ohne Kommastellen, richtig?) an Samples entspricht, das eine hin und her zappelnde Versatzsample unter gewissen Umständen gut hörbar ist (44,1KHz, Sinuston). Sprich, das 1/96 ist mal ein Sample zu lang und dann wieder zu kurz --> Sprünge in der Ausgangswellenform des Tapedecksamples bei jedem neuen 96e.

Das Standard Song Pos Modul funktioniert übrigens wunderbar. Standalone, in Live 8 und in Cubase5. Die Song Pos Fixes, die ich ausprobiert habe, verschlimmbessern das ganze noch (mehr Knackser). Ich vermute mal, daß die in aktuellen Reaktor/Host Versionen nicht mehr nötig sind.

Habt ihr ne Lösung oder eine Bestätigung für dieses Problem? Hat vielleicht jemand zufälligeerweise ne Meldung von Stephan Schmitt dazu?
Weil, wenn es so ist, wie ich vermute:
Warum gibt es überhaupt 96a, wenn es doch bedingtermaßen falsche Werte liefert?

gespannte Grüße,
Mark

Moin.

Das sieht nach Float-Rundung in IEEE 754 aus. Vermute, auf Primary läuft alles über 32bit Fließkommazahlen. Immer wenn der Exponent in der Zahl im um 1 hochspringt, sinkt die absolute Genauigkeit der Mantisse. Hatte so ein ähnliches Problem bei einem SampleNr-Zähler in Core (für einen Tapeplayer, der ab einer gewissen Spielzeit eigenartig langsam gespielt hat), da brachte dann Wechsel zu Integer bzw. Hochschalten auf 64bit Abhilfe, aber auf Primary, puuh.

Noch am Nachdenken.

Grüße vom Jan

Danke für deine Antwort Jan
- und die Bestätigung...!
Hätte nie gedacht, daß das Zusammenzuppeln eines Ensembles sooo tief und an die Grenzen digitaler Rechentechnik geht. Meine Überschrift war etwas überzogen, denn für Sequenzerbedürfnisse ist die Auflösung von 96a natürlich ausreichend, aber ganz astrein funktionierts halt nicht. Ich vermute mal, daß 96a noch aus der Pre-Core-Ära stammt, in der es noch keine SR.C gab. Somit heute in Core ersetzbar (mit dem selben Rundungsfehler sobald es nach Primary verdrahtet wird).
Ich habe inzwischen einen Workaround für mein Ensemble geschaffen, indem für jeweils 4 Takte eine SR.C von Null an 96/sample aufwärts addiert. So beschränkt sich der Rundungsfehler auf den letzten Teil von vier Takten x Audiosamples. Gewisse Artefakte sind zwar immer noch über das Tapedeck zu hören, aber das liegt hier vor allem daran, daß das Tapedeck den Ausgang LEN scheinbar auf ganze Millisekunden abrundet. Was man hört (z.B. mit Sinuston) ist die Interpolation des Tapedeck. Nur mal so am Rande. Ein SinusSample mit ganzer ms-Länge klingt jetzt immer sauber über 4 Takte bei Original Speed.

Primary arbeitet übrigens immer mit 32bit maximal. Hab ich vorhin irgendwo im Core-Handbuch gelesen.

Gruß Mark

Quietschboy hat geschrieben:Danke für deine Antwort Jan
- und die Bestätigung...!
Hätte nie gedacht, daß das Zusammenzuppeln eines Ensembles sooo tief und an die Grenzen digitaler Rechentechnik geht. Meine Überschrift war etwas überzogen, denn für Sequenzerbedürfnisse ist die Auflösung von 96a natürlich ausreichend, aber ganz astrein funktionierts halt nicht. Ich vermute mal, daß 96a noch aus der Pre-Core-Ära stammt, in der es noch keine SR.C gab. Somit heute in Core ersetzbar (mit dem selben Rundungsfehler sobald es nach Primary verdrahtet wird).
Ich habe inzwischen einen Workaround für mein Ensemble geschaffen, indem für jeweils 4 Takte eine SR.C von Null an 96/sample aufwärts addiert. So beschränkt sich der Rundungsfehler auf den letzten Teil von vier Takten x Audiosamples. Gewisse Artefakte sind zwar immer noch über das Tapedeck zu hören, aber das liegt hier vor allem daran, daß das Tapedeck den Ausgang LEN scheinbar auf ganze Millisekunden abrundet. Was man hört (z.B. mit Sinuston) ist die Interpolation des Tapedeck. Nur mal so am Rande. Ein SinusSample mit ganzer ms-Länge klingt jetzt immer sauber über 4 Takte bei Original Speed.

Primary arbeitet übrigens immer mit 32bit maximal. Hab ich vorhin irgendwo im Core-Handbuch gelesen.

Gruß Mark

Haloo Quietschboy,

hast Du mal mit dem Audioausgang des Song-Position-Moduls gearbeitet?
Ich habe auch ein entsprechendes verändertes Makro in die User-Library gesetzt. Vielleicht hilft dies.
Die Rundung ist in der Tat zu beachten. 64-bit-Auflösung gibt es erst in der nächsten Reaktor-Version 5.6. Ich denke mal, dass diese bald herauskommen wird, da ja die Ankündigung im englischen Forum schon einige Zeit steht.

Mit Core kommt man in der Tat sehr nah an den Rechner heran; das ist ja gerade das Faszinierende.

ciao herw

Hi Herw,

das wär natürlich klasse, wenn in 5.6 primary 64bit integriert ist! Weißt du das genau? Gibts irgendwo ne hochauflösenderere "Version History" als die im englischen Forum?
Ansonstend find ichs eher abtörnend als faszinierend an solche Grenzen stoßen zu müssen
Weil mer will ja ferdisch wern und endlich so richtig Mucke damit machen. Aber Spaß machts trotzdem doch...sonst hätt ich schon längst aufgegeben. Mit meinem Workaround klappts im Moment super.
Freu mich schon aufs Reverse-Engeneering mit Reaktor 5.6

Gruß, MArk

Quietschboy hat geschrieben:Hi Herw,

das wär natürlich klasse, wenn in 5.6 primary 64bit integriert ist! [...]

Gruß, MArk

das ist ja der Hauptgrund der neuenVersion R5.6 und steht entsprechend lange schon im Forum: http://www.native-instruments.com/forum ... p?t=114767

ciao herw