Having an issue converting primary to core

gentleclockdivider
gentleclockdivider Member Posts: 79 Sine
edited December 2022 in Reaktor

There is this old adsr tutorial for phase distortion , primarly altering the ramp wave .

I have some issues when implementing the algo in core for when the ramp input is higher D , lower then D wo

THe yellow bounding box algo works fine in core , the red one doesn't

The compare module is not yet implemented in core ,I want to make sure bot phase dist algo are correct

Osciloscope shows phase distotorted ramp in cosine left channel , and directly to out in right channel

Some screenshots , and ensemble



Comments

  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    edited December 2022

    This really weird ,

    I got the phase distortion working but

    Where in the primary I had to do (1-D) , in core it is (D-1 ) , why is it reversed ?

    ALso , the phase distortion works , but the output of the distorted phasor without the cos is nothing like the primary counterpart .


  • colB
    colB Member Posts: 355 Saw

    You are using the mod macros wrong. In the not working example you need an x div a, not an a div x.

    The way to have it in the first example, the only a time it processes an event is on initialisation when the constant 1 generates an initial event.

    For those mod macros, the input with the arrow is a slave, so there needs to be an event stream at the other input. That's why there are two versions of each!

  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    edited December 2022

    Edit , got it working

    Constant into subtraction had to be latched by SR.C


  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine

    Why did I have to latch the constant before going into the subtractin ?

    There is already latching going on in the subtraction itself

  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    edited December 2022

    Sorry , am not following you

    Are you talking about this division ?

    The upper input is divided by the lower input , both in primary and core.


    They are identical , the only thing I had to do was to latch the constant before subtraction (which still puzzles me )

  • colB
    colB Member Posts: 355 Saw
    edited December 2022

    They are not identical. The primary version responds to an input event at either input port. The core one responds only to events at the lower port.

    The same thing with the subtraction. You are using an 'x sub a' that only responds to events at the upper port, which in your case is a constant, so only functions during initialisation - thats why it works when you drive it with SR.C

    If you use an 'a sub x' for the subtraction, and an 'x div a' for the division, your original version should work, shouldn't need that SR.C latch hack

    (assuming the X input is an audio stream, or some similar regular event stream)

  • colB
    colB Member Posts: 355 Saw
    edited December 2022

    Here's a pic to clarify:


  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    edited December 2022

    OK , so the division is read out-triggered by an event

    Still the subtraction nees latching , otherwise I get this ..( left channel is not good )


  • colB
    colB Member Posts: 355 Saw

    You are using the wrong subtraction mod macro and the wrong division mod macro

    There are two subtraction modules in the mod macros, and two division modules:


    You need to understand how they work and choose the correct one for the situation. In your case, you chose the wrong one for the subtraction and the wrong one for the division. You used the 'x - a' and the 'a div x' when you needed the 'a - x' and the 'x div a'

    Your main event stream that you want to be driving the process with is coming from your X input (I'm assuming?), but using the 'a div x' means that those events are blocked, only the value is stored and the macro waits for an event at the lower input. Similarly the subtraction you used will respond only to events at its upper input, which is a constant, so nothing doing.

    Swap these out for the correct mod macros and it will all work. You don't need to hack SR.C in anywhere. That might give you a bodge fix, but is also likely to cause problems in the future... and it's really important to understand how and why those mod macros work, and how to use them correctly.

  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    edited December 2022

    I had a look in the x div a and it is essentially just the same as an a div x .

    The only difference is that it takes the reciprocal of a and multiply it with X ( signal ) and also using as the memory read

    .Why not use this in the A div X , and use sr.c for read out ?

    ColB , can you just upload the ens with your alterations , that woud simpler

    Edit , solved


  • colB
    colB Member Posts: 355 Saw
    edited December 2022

    I don't have the ensemble, so I can't upload it with changes.

    I had a look in the x div a and it is essentially just the same as an a div x .

    x div a is not essentially the same as a div x.

    x div a divides the value at the top input port with the most recent value at the bottom input port only when there is an event at the top input port.

    a div x divides the most recent value at the top input port with the value at the bottom input port only when there is an event at the bottom input port.

    That is a fundamental difference!

  • colB
    colB Member Posts: 355 Saw

    try this macro in place of what you had:



Back To Top