Reaktor - schroeder allpas

13

Comments

  • colB
    colB Member Posts: 945 Guru

    Here's an edit of your midiverb.

    I set the various delay and all pass mosules to non solid to remove that annoying orange implicit feedback unit delay

    I changed the delays in the feedback loop to add a couple of taps each.

    I set all the delay tap times to mutually prime values (just one option to reduce beating effects and smooth things out)

    The allpass settings were just selected at random.

    I used some appropriate gain settings per section to account for the delay time and the allpass delay time in order to achieve a 1.6 second decay (roughly)

    Result is a passable? reverb sound. seems like this model would be absolutely usable given well tuned parameters. Getting the all-pass components tuned better, and the feedback filtering. And maybe some more interesting early reflections, this could be ok.

    It still has some noticeable repeating echo type artefacts at some frequencies, but I think that is due to the simplicity of the model. The Dattorro model removes a lot of that with it's figure 8 feedback setup.


  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper
    edited April 5

    NO I don't have the freq coefficients for the alpasses , but the gain coefficients are all 0.5 because of hardware restricitions , at least according to the video posted above.

    Yes the outputs are indeed from multiple taps , that what I did in my ensemble

    A tap is taken Pre delay and post delay , so two outputs per delay

    All pre-delay taps are summed and go to the right channel , all post delay taps are summed and go to the left channel .

    I had a chat with the guy who made the video , and pre-delay taps are indeed the outputs of the tank diffusers , and in the first delay the pre delay tap = output of the lowpas filter

  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper
    edited April 5

    Damn , I haven't updated reaktor , still on 6.4.3

    Can't read your file

  • colB
    colB Member Posts: 945 Guru

    ouch!

    here's a .wav of the latest version with a few extras that aren't in the edit03 version:

    I hope this gives some incentive to persevere with this model :)

  • colB
    colB Member Posts: 945 Guru

    WHat's also weird , while modelling the tank which needs feedback , when set to solid the orange feedback feedback lines dissapeared , but now they are always orange regarless solid setting or not

    That's because the all-pass and delay macros inside that macro are still set to solid, they all need the solid parameter to be unchecked.

  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper

    There is a great thread at gearslutz called reverbsubculture where user acreil posts a lot of schematics (this one is not a midiverb though )

    ONe thing is not really clear , here he mentions 6 combs with two taps each .

    quote

    Here's one that I like. It's not perfect, but it sounds pretty good. It's not the same model as the other 32 kHz reverb I posted previously. 12 early reflection taps, 4 allpasses, 6 combs with 2 taps each.

    unquote

    How does one get two tabs from a comb , aren't these just 12 combs then ?

    Since one comb is a tuned feedback delay , 2 taps at different frequencies would require two delay lines .


    Colb , the file sounds nice , did you add more taps ?

  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper
    edited April 6

    Here's an example of the alesis midifex , the big blocks are independent delay values , multitaps .


    This one is even more ridiculous , midiverb algo 59 ;...91 delay taps


    How wold one implement this in reaktor , use of the voice module set to 91 to adress multiple delay times from one delay device ?

    Really curious

  • colB
    colB Member Posts: 945 Guru

    How does one get two tabs from a comb , aren't these just 12 combs then ?

    Since one comb is a tuned feedback delay , 2 taps at different frequencies would require two delay lines .

    I think you would get two outputs of the same thing but out of phase with each other... like how your ears experience the same sound with a very small phase difference if it's not directly in from or behind.

    If you do the math, it works out that the maximum difference from one ear to the other would be something like 80 samples at 44.1KHz

    So this could give some spacialization fx.

    With a bigger gap, it could give the phasing effect that you might get if a sound bounced off different parts of a room, so travelled different distances...

    Just mushing things up more. One delay with two taps is cheaper then two delays. It's good to have multiple copies of the same thing but slightly different in a reverb.

  • colB
    colB Member Posts: 945 Guru

    Colb , the file sounds nice , did you add more taps ?

    Thanks, I added two taps to each delay, like in the diagram. I also watched the vid, and it seemed to me that the guy contradicts himself, at one point he says that there are two taps taken from the delay, then at another, he seems to suggest that the 'taps' are taken from before and after the delay...

    Both options work though, and you get a similar sound at similar cpu. What the extra tap gives you is better control over the phase difference between the left and right outputs, so with headphones and some careful tuning, this should allow a slightly more 'realistic' spacialization illusion... maybe?

    It really doesn't effect the basic sound of the reverb effect though, that is more due to carefully chosen delay times and gain values that match the delay times.

  • colB
    colB Member Posts: 945 Guru

    How wold one implement this in reaktor...

    First thing I would try is to build a delay line with 91 taps. There are a lot of details missing from that diagram though :-)

    As long as you remove the extra code in the basic delays read process, it can be really cheap, might be cheaper than using a polyphony based hack... you'd have to test both.

    The only thing to watch is that you would need to add some support code to handle different sample rates or your Reaktor version will not be portable. It would be a pain to have to retro-fit that to 91 different macros :)

  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper

    When ctrl clicking we can create dynamic inputs on adder modules etc.old news ..

    but ..

    Just found out this also works on macros , both for inputs and outputs .

    Is this a new feature ?

  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper
    edited April 6

    He doesn't contradict himself .

    A tap can be taken at the input of the delay and at the output .

    At the input corrsesponds to the output of the preceding module , in reaktor that is .

    In hardware I guess it's a little but different .

    quote

    Q:

    THe taps are taken from the start and end of the delay , but isn't the start of the delay the same as the output of the diffuser before it ?

    A:Not necessarily. It can be 1 sample past, up to wherelever the code 'allows' based on the total number of instructions and the total reverb tail. Usually, you are right, it starts immediately after a APF and ends (like here) ~16% of the way through. There is a total of ~ 3.3sec of delay possible, so algorithms with 1.6sec (like the example) commonly have the structure AP+DELAY+AP+DELAY+AP +DELAY

    unquote


    About the taps , I stopped at value 32 , for stuff like this text based environments like supercolider are the way to g .

    just fill an aray [.... ] and boom , done

  • gentleclockdivider
    gentleclockdivider Member Posts: 187 Helper

    O.K back to nested allpas because I simpy don't know if it's correct or not .

    Some people say that just a feedforward-feedback gain structure around an allpas is already considered nested .

    So this is an alpass , and the macro below it

    Would the picture below be considered a nested allpas , by inserting an allpas in the feedback structure of an allpass

    Or , building a feedforward-feedback around an allpass


  • colB
    colB Member Posts: 945 Guru

    Have you read the Gardner paper I linked to yet?

    That explains it better than I can. He uses fancypants Math to prove correctness, but you don't need to understand the math to understand the concept (assuming you are willing to accept his word).

    basically he gives us this diagram for a single all-pass filter:

    he then explains that G(z) is a delay line.

    Then he uses some math to prove that if the magnitude of G(z) is unity, then the magnitude of the whole thing is unity... which translates to , if G(z) is an all-pass, then the whole thing is an all pass....

    The consequence is that you can stick any all-pass structure into that G(z) box, and you still have an all-pass, which you can then stick in the G(z) box of another and so on..., so you can build arbitrarily complex structures with multiple depth of nesting, and you will still end up with an 'all-pass'.

    In Reaktor you can build his basic all-pass like:


    That 'T int delay' is the G(z) part...

    but that means that you can make this whole all-pass into the G(x) part... and its still an all pass... so that's one level of nesting:

    ...there's a problem here, the feedforward part of the inner all-pass doesn't have any delay, so it causes an implicit z^-1 when incorporated into the feedback loop of the outer structure. Probably the easies way to fix this is with a unit delay directly on the output of the inner all-pass (just like in the primary version)). Unit delays are all-pass, so it should be just fine to do this :)

    ...it makes sense that multiple all-passes in series is still all-pass (each has unity magnitude), so we can do this too:


    and it's still an all-pass... if we call that whole thing 'triple whammy', then we can nest a couple of those in series with a single inside another all-pass and maybe a delay line, like this:

    And it's STILL an all-pass... and so on...

    In the Dattorro paper, his all-pass looks like

    this looks like a different structure with the feedforward path coming from inside the lop instead of directly from the input etc.... however (I think?) it is really just a 'transposed form' of the same thing...

    here's a link that explains transposition in DSP:

    https://spinlab.wpi.edu/courses/ece503_2014/8-3transposed_forms.pdf

    (transposition is cool, you can do things like taking a filter model that has a single input and multiple outputs... like a moog style ladder with output taps for LP, HP and BP, and use transposition to turn it into one that has separate inputs for HP LP and BP and a single output...)

  • colB
    colB Member Posts: 945 Guru

    He doesn't contradict himself .

    A tap can be taken at the input of the delay and at the output .

    At the input corrsesponds to the output of the preceding module , in reaktor that is .

    Maybe contradict is the wrong word, but he is ambiguous.

    What I means is that you can take multiple 'taps' from the overall structure (I would call these outputs, but in a hardware system, maybe not?), so a 'tap' from before or after one of the delay lines. Or you could take multiple taps from a tapped delay line, so taking outputs from different offsets within the delay line. Both of these uses of 'taps' are legit, but there is a difference between the two uses, and if you are using both in the same discussion, I think you need to disambiguate. Personally, looking at the diagram, and listening to the description, I really think we are talking about both types at different times, but it's not completely clear, there must be multi tapped delay lines otherwise the diagram is wrong... but the verbal description is a bit woolly in this respect as though he's not totally sure (it just seems that way, he clearly knows his stuff)...

    Whatever, as I pointed out, both approaches do work, but the tapped delay approach is more flexible, and still cheap enough to be basically free (cpu not $$$) from an implementation POV, so unless it was technically or financially impossible, that would have been the way to do it.

This discussion has been closed.
Back To Top