audio crackle when reading from an audio table. What am I doing wrong?

iLex Member Posts: 7 Member
edited April 13 in Building With Reaktor

Hi! It's been a long time since I did anything in Reaktor (besides building Racks). I am looking to create a simple rewind plugin.

Basic operation:

  • audio is recorded into an audio table. Settings in two screenshots attached.
  • whenever the 'reverse' button is pressed (which comes in at the REV input in my screenshot) the audio plays backwards from the last write position
  • (the REV button re triggers the top Ramp Osc, while triggering the last value of the bottom Ramp Osc)
  • Speed controls the rewind speed (multiplier)

Whenever I rewind with Reaktor inserted on an audio track in Logic Pro, there is a lot of crackle (digital too low buffer-size style crackle).

I've tried:

  • different buffer sizes
  • having the ensemble stop recording when rewinding
  • different rewind speeds

Anything I am overlooking? Does anyone know how to fix this?

Thanks in advance!


  • colB
    colB Member Posts: 670 Guru

    It would be easier if you posted the ensemble.

    Does it work with Reaktor in stand alone mode?

  • iLex
    iLex Member Posts: 7 Member

    Thank you for your reply!

    Yes of course! It makes sense to add the ensemble😂

    It does the same thing (arguably worse) in standalone mode.

  • colB
    colB Member Posts: 670 Guru
    edited April 12

    Try putting both ramps into 'hi-res' mode.

    I think what is happening is that in normal or sync mode, because the scaling is so high (x480000), a single sample tick is too small, and write sometimes skips a sample here and there... but the playback sometimes plays one of those samples that were missed.

    I guess what 'hi-res' does is switch to 64bit processing (just guessing)

    This is easier to analyse in core where things like 32bit vs 16bit are explicit, and you can use integers for table indices, making it easier to guarantee correct functionality.


    If you rig this test up, it demonstrates that the difference between the current and previous indices is often greater than 1 causing the write position to skip over some table slots. When switched to high res, it is often just less than 1, and occasionally greater than 1.

    IMO it would be better to build this in core. In core, you can guarantee that you always hit every index!

    If not, then still better to build it using some sort of counter for the write index instead of using a ramp.

  • iLex
    iLex Member Posts: 7 Member

    Thank you so much for your help!

    Sadly I don't have the knowledge to code something like this (or anything else) in core. I'm a composer who likes to dabble in things like this, mostly to 'program' things I need for my projects (like a 7 speaker panner and such things).

    I'll try what you said, including a counter. Maybe it would also be functional if I switch to milliseconds, which at least brings the resolution back to 10.000.

    I'll let you know if I figured it out!

  • colB
    colB Member Posts: 670 Guru

    I'll try what you said, including a counter

    Hmm, counter is tricky in Primary, because counter is not an audio rate object in primary.

    Don't be scared of core, it's really not much different, and where it is different it's usually in a good way ;)

    I had a quick go at a core rebuild. Maybe I'll do a mini step by step once you taken some time to try and solve it yourself. It's actually a really good project for an 'introduction to core!'

  • iLex
    iLex Member Posts: 7 Member

    Cool! I'll take your challenge.

    See you in ehh... less than half a year I hope...

  • iLex
    iLex Member Posts: 7 Member

    Okay, so that was easier than I thought. A little help from a tutorial, well, a lot of help from a tutorial , and some customisation and I got my counters.

    It works perfectly, no glitches!

    I am kinda tempted to see if I can manage to make the table in core too. Will post here if I do.

    Thanks again!

Back To Top