Making a core envelope output data as quickly as an Iterator

Discussion in 'REAKTOR' started by mike_jm, Sep 9, 2017.

  1. mike_jm

    mike_jm Member

    Messages:
    130
    I am attempting some projects which require an envelope to run as fast or faster than an Iterator. That is, the envelope must output numbers as fast as the Iterator in order to get "pairs" of data such as:

    Iterator output (1) --> Envelope output (0.9)
    Iterator output (2) --> Envelope output (0.89)
    Iterator output (3) --> Envelope output (0.88)

    etc.

    So basically, I need the envelope data to be interspersed with the Iterator's.

    In practice, the core envelopes based off the core library toolkit are far too slow. By the time they start putting any data out at all, the iterator has completely finished running an entire iteration.

    Here is a sample project demonstrating this (also attached). The iterator is in green and the envelope data is in red. The first envelope data is entry #101:

    env speed.PNG

    The iterator is running at 1000 iterations per second. I am not sure how to set the envelope output speed. This core envelope has a section titled "Speed" as follows:

    env speed speed.PNG

    I am not sure if there's something in there I can change to help this envelope output at the necessary speed.

    How might I accomplish this?

    Thanks.
     

    Attached Files:

  2. herw

    herw NI Product Owner

    Messages:
    5,779
    see here and set f=1000Hz
     
  3. mike_jm

    mike_jm Member

    Messages:
    130
    Hey Herw,

    I just saw your other reply and thanks a bunch! That helps slow it down when needed to event rate perfectly.

    But for speeding it up, it's still not working as expected/hoped.

    Even with a speed of up to 1,000,000 (here shown at 10,000), and using an order module to trigger the envelope first, the Iterator is finishing an entire iteration before the envelope outputs a single data point:

    env speed 10000.PNG

    Any further thoughts?
     

    Attached Files:

    Last edited: Sep 9, 2017
  4. colB

    colB NI Product Owner

    Messages:
    1,835
    Why are you using an iterator?
    If you want a count to go at the same speed as an event stream, just use an event driven counter and add some logic to turn it off and/or reset it when it reaches a threshold.
     
  5. mike_jm

    mike_jm Member

    Messages:
    130
    The iterator is for running a modal or sine bank. The only way I know how to do that is with an iterator, and that is essentially what iterators are designed for. To replace the iterators in my Modal/Sine bank projects with DIY versions would be a bit overwhelming and like re-inventing the wheel.

    I also don't want my iterators running abnormally slow, as this will cause other problems. I want the core envelope to output data faster so it can keep up.

    I'd like to at least understand first WHY an iterator runs so fast compared to a core envelope. If you can control the rate of the Iterator (iterations per second) and you can control the core envelope rate (as herw posted), shouldn't we be able to get the two to match or co-operate?

    [​IMG]

     
  6. drb

    drb NI Product Owner

    Messages:
    33
    from the R5 Docs:

    Per default, all Events are sent before the next audio sample is processed. If the Limited Speed checkbox in the Function page is engaged, the Event generation rate can be set limited to the rate set with the Iteration Speed edit field in the Function page.

    (end from R5 docs)

    In other words, by design, once triggered all iterations and their downstream event processing are executed between samples. The limited speed option is to spread the iterations out over multiple audio samples if necessary.

    In general all event processing is between audio sample processing. The control rate is not the event rate. There is no event rate in general. Events happen as quickly as they can -- given the CPU capabilities. If too many events are executed between audio samples, you get audio drop outs.

    The control rate clock is only used by a few modules. E.g. (in primary) LFO and A to E.

    The net implication of this for what you are saying above is you want the real time audio events from an envelope synchronized with the non real time events of an iteration module.

    Maybe you could try to implement something like an envelope "clocked" by the iteration events. I put clocked in quotes because the time parameters for the envelope will no longer be related to real time.

    Perhaps you should read the above with a grain of salt until the gurus speak (if they do).
     
  7. mosaic_

    mosaic_ Active Member

    Messages:
    259
    That's exactly what I would suggest. What are you trying to do with this @mike_jm ?
     
  8. mike_jm

    mike_jm Member

    Messages:
    130
    Hey drb & mosaic,

    Thanks. Clicking the "limited speed" button of the iterator does fix this "problem" but I fear it will cause other problems elsewhere in my ensembles. The whole point of the Iterator is to be so fast that it is never interrupting sounds or events as it runs. I get that.

    Here it is at limited speed, finally with envelope data interspersed:

    env speed limited.PNG

    There are two applications I am trying to apply this principle to.

    1) Adding a "Hold" to Modal Bank
    I am unhappy with the lack of fluid control over decay times in the modal bank. I would like an initial "hold" period of a few milliseconds at the start before the decay kicks in. I would like to recreate a "hold" function in the modal bank's decay curve by having a much longer decay for the first few milliseconds applied to notes (ie. +120 Reaktor time added to the standard assigned decay), then, after those few milliseconds, the regular programmed decay gets applied, and the notes decay like usual. With a long decay like adding 120 in Reaktor time, for a few milliseconds, this would basically simulate a hold as it would basically be "flat" decay.

    I was attempting to do this by using an envelope triggered by gate, multiplied by the time constant, and adding that to the otherwise programmed decays. But as stated, the envelope wasn't fast enough to "perform" the math in time for each Idx input.

    Is there another way I could do this in Core? ie. with a timer that starts triggered by gate, outputting a number to be added to the decays continuously (ie. 120) until the timer hits a certain time, and then the number to be added is 0? Zero output would then have to trigger a re-iteration to apply the new decays.

    I think this is possible as described. I have built a timer clock in the past from SalamanderAnagram's tutorials for envelope use:

    timer.PNG

    Any further direction on how to apply this principle to my usage and if it would work?

    2) Creating Musical Noise from the Modal/Sine Bank
    I would like to have noise bursts for which I can control the per frequency levels and decays based on mathematical curves (and not just simple sweeping LPFs). The modal and sine banks are ideal choices for this.

    I proved already that you can make noise from the modal/sine banks by having randomly assigned ratios for the partials and have those ratios randomly change continuously at about 2000 Hz or so. I was having trouble getting the time-based results I wanted though as I was trying to use an envelope to guide the "decays" of the partials, and the envelope wasn't fast enough.

    In this application, using the "limit speed" of the Iterator will likely solve my problem. Since it's randomized noise I'm creating anyway, I don't think having the Iterator run "slow" won't cause any unexpected problems. I will have to test it, but I expect this application should be "solved" by this button.

    Thanks again guys. Fun stuff. What I'm finding really neat about Reaktor is how pretty much anything you can imagine you can do if you can just find the right approach.
     
    • Like Like x 1